Outbound on PRI Fast busy

[kennynitch]

Hello,
First let me say your forums and website are a great resource.

At random times maybe 4-5 times a week for a span of 30 seconds any outbound calls when allowing the PBX to select the trunk will receive a fast busy. If I manually grab any particular trunk and dial out it makes it out fine and it also allows any other calls after that to make it out fine. For every fast busy I get this error in the logs.
09:32 04-23 *** default_trs_t::ti_setup_ind - We received a setup request for a new call while we were on a call.

I have confirmed with AT&T the switch type is correct. I have tested every b-channel to be working correctly as well.
We have a 5000 HX, 5.1 SP4 PR7, with 2 PRI's handed off from AT&T. We have experianced it for 6 months and on 2 older service pack versions for 5.1

Any help or insight to this error would be appreciated.

Thank you
Kenny

[dwayneg]

Verify that the channels are in order in the databse (Chan 1 = 94001, chan 2 = 94002, etc.).  I've seen instance where channels were not in order in the trunk group.  then make sure that you and the carrier hunt in opposite directions.  We typically start at channel 23 on outbound, make sure carrier is starting at 1 on inbound; SMDR can show you if that's right, you should see inbound at one end of the order, outbound at the other.

[kennynitch]

The channels are as you suggest in the DB and I confirmed with our Carrier they do pick starting from the bottom and we are picking out going from the top.

 I just got off the phone with a level 4 tech with AT&T and  he suggested us both trying to switch do a different Switch type. I will have to do this after hours and since the issue cannot be replicated on demand I will just have to wait and see.

Any more suggestions are appreciated.


Thank you
Kenny

[MrNitch]

I have tried both 4ESS and 5ESS and I am still getting 'default_trs_t::ti_setup_ind - We received a setup request for a new call while we were on a call.' errors. All the literature I have looked through, none reference anything close to an error like this. Any thing else I am forgetting to check that effect how the b channels are being assigned?


Thank you
Kenny

[marcolive]

Hi,

This error message is referenced in a Mitel Knowlodge base (Answer ID 2186) :

"Telco may be sending the calls from channel 23 to 1; verify that and have the order switched to 1 to 23 if necessary."

If possible, ask AT&T and see if it resolves the issue.

Hope it helps! 

[MrNitch]

I have confirmed with AT&&T calls are being handed to the PBX from 1-23 on the first PRI then 1-15 on the second, outbound calls the PBX is pulling from the second PRI 15-1, then first PRI 23-1. We are getting the error with 10+ channels available and it only happens on outbound calls, while the error is happening we are still able to receive inbound calls.

[Tech Electronics]

MrNitch,

Have you tried recreating the issue while looking at your setup messages?

Thanks,

TE

[MrNitch]

This is something I am unable to reproduce. But I have viewed all of the logs during the fast busy and the above error is the only thing I find in any logs. Perhaps I am not familiar with the 'setup messages' where are these found?


Thank you
Kenny

[MrNitch]

Marcolive and Dwayneg you may have been correct all along. I started putting pressure on AT&T and I got a call from one of their 'Experienced Tech's', all of the level 3 techs seem like they are just waiting for their shift to end. The cisco router, for some idiotic reason, was handing off incoming calls balanced on both PRI's but on the second doing so in descending order! I guess the 2 times I confirmed with level 3 support they just looked at the first PRI and said ascending and brushed me off. So obviously we are going to have an increased chance of call collision since every other call has a chance of being in my way for an outbound call. I will update in a couple weeks but I think y'all were right all along, it is just hard to get a carrier to consider something on their end to be configured wrong.

[NTEDave]

it is just hard to get a carrier to consider something on their end to be configured wrong.

I once had a PRI that wouldn't support Fax calls, took MONTHS to get the carrier to find the fault!