busy signal

[Telecomboy]

what setting can you change to have the system generate a busy signal vs. just dropping the call when either misdialing or actually calling a busy number?

I have a customer who is dropping alot of outbound calls and want to see if it is happening when they should be getting a busy signal or if it is a bigger problem.

 

[roster]

Make sure offhook station is unchecked under Telephony under user. We had the same problem and that did the trick, we now get busy signals.

 

[Telecomboy]

I checked their programming and it all appears to be set-up properly. any other thoughts as to why a call would drop versus getting a busy signal?

 

[mattKnight]

I've had similar problems

check your incoming routes to make sure that none are pointing to non-existent destinations (or ones with spaces in)

Take Care

Matt
If at first you don't succeed, skydiving is not for you.

 

[CarGoSki]

I have a few thoughts:

I have seen this and in fact have an Avaya case open. The case is new and the circumstances are as follows:

Site A and B: 406 V2 3.0.44

Site A: 2 PRI cards
1-Single-Slot B Line 5 > Provider PRI NI2
1-Dual Slot A Line 1 > Set as PRI-NI2-CPE > Connected to dedicated telephony Point to Point T1
Line 2 >currently not used.

Site B: 1 PRI card
1-Single Slot B Line 5 > Set as PRI-NI2-CO>Other end of P2PT1

No IP trunking!

An external call from Site B Line 5 travels to Site A Line 1 via P2PT1
Site A incoming routing routes calls on Line 1 trunk group to dial out short code for Site A Line 5.

When Site B dials a busy external call, the call appears to drop or disconnect.

On closer inspection Monitor shows that Site A Line 5 received a disconnect - cause code - busy from the central office. Site A Line 1 receives a disconnect- cause code - release from Line 5. Site B Line 5 receives a disconnect- cause code - release from Site A Line 1.

So it appears to be broken by not passing relevant codes between Lines. In this case we see that IPO appears not to host true Tandum mode. Instead Site A "places" the call for Site B. Recall where Site A Line 5 passes the correct cause code however Site A Line 1 does not interprete the correct code and fails to generate a busy signal down the audio path to Site B.

Sounds buggy to me. This should work!


So.. Pri?

Have you looked at Layer 1, 2, 3 Monitor traces for disconnect cause codes?

 

[mytelecoms]

I have a case at Tier 3 with similar issues on V3 with an IP406 (1st edition).

When a user dials out over PRI to a number which is busy or does not exist, they get a ring tone. Traces show the line presenting a busy signal, and if I put them back to 2.1 it all works fine.

We've tried everything, and Avaya can't even crack it yet.

I'll let you guys know if I get any further.