inbound call get fast busy signal after pick up the phone

[shouyisun]

Scenario: CCM 3.33 centralized cluster, 3725 as GW running MGCP. with NI2 PRI protocol

Issue: Inbound call to the IP phone and rings, but as soon as pick the phone , both caller and called hear fast busy tone. Turn on Q931 debug saying "Cause i = 0x80E5 - Message not compatible with call state".

[shouyisun]

In case somebody will run into the same issue with me, here is result of that: Telco's PRI switch is DMS500 and the PRI module is SPM, however this module has some compatbility issue with Cisco at this moment. So they swapped this with DTCI PRI card, after that works fine.

[carl.newman]

Sounds like you need to change the calling and called party switch type in the mgcp config for the gateway. I know that I have ran into issue with the default setting of "callmanager". Try setting it to unknown/unknown. Then try to set it national/standard. This would show up in the debugs on the gateway.

[pbarman]

I am seeing the same disconnect cause 80E5 when using 6608 blade with CCM 3.3.3. However, the problem is only for calls that reach Unity via the 6608 blade. Calls not involving Unity work fine. Only when the call strikes Unity, the calling party receives fast busy. The call strikes a Unity port and then drops.

[gillins]

has any one checked to make sure that the codecs are correct in your regoins or that you have enough transcoder resources?

[borisdecout]

I'm now getting the same disconnect with CM3.3.3 and 6608. Just happens after we changed our provider from SBC to AT&T.

Did you find a solution?

I tried the change mentioned above but it doesn't help

thanks

[dgiddings]

This issue is occuring with certain Telco's that implement switches that require "Strict" NI2 adherence. We're sending a legacy command to the switch and it hiccups. The way to fix this is to modify the Cisco CallManager Service Parameters for OverlapReceivingForPriFlag by changing it from the default of False to True. Sometimes it can also be an issue with the call type so it's also a good idea to follow the previous recomendation to set them to Unknown. As always, it's wise to check with TAC to verify that they concur before changing this setting.