Call dropped when sent to sign-in

[borisdecout]

We have been using a call routing rule to send caller to sign-in prompt when dialing a specific number.

Now, unity drops the call as soon as it receives it.

Tonight we changed phone carrier and had our DIDs pointed to a new set of PRIs.

The new and previous PRIs are all on a 6608 blade.

So the only thing that has changed in our system is the configuration of those new PRIs on the 6608.

What can cause unity to drop the call instead of playing the sign-in prompt.

This used to work before and the new PRI is configured the same way as the old PRI. They are just from different company

Could the difference of phone carrier be the issue?

We used SBC before and are using ATT now?

[Christopher McAlpin]

This problem sounds familiar. See below for a similiar problem and the resolution:

Call comes into Unity from the PSTN. SETUP hits Call Manager. Call Manager

sends back ALERTING. Unity goes offhook. This all happens in about .08 seconds.

Call Manager sits and waits for any STATUS messages from the service provider,

doesn't get any, so it sends the CONNECT. Everything is great, of course, until

the service provider sends back the STATUS complaining that it doesn't like the

progress indicator we sent in the ALERTING. Call Manager sees the STATUS after

the CONNECT, and so it drops the call.

This happens for every 9 out of 10 calls when dialing Unity directly from the

PSTN. When we call a user directly from the PSTN, everything works fine because

it takes him longer than .08 seconds to answer the call. If we call a phone and

it rolls over to Unity, everything still works fine because we've got plenty of

time to get the STATUS message back from the service provider.

To resolve this, we had to set the disableAlertingPI service parameter on Call

Manager to True.

[Christopher McAlpin]

On each of your

call managers, go to Service > Service Parameters. Select your call manager, and then select the

Call Manager service. Set "disableAlertingPI" to true.

[borisdecout]

That was it. It is now working.

Can this change trigger problems in other areas has a side effect?

For others in the futur looking for that problem, the error in the CM traces associated with this was

DISCONNECT pd = 8 callref = 0x8BF3

Cause i = 0x80E5 - Message not compatible with call

state or protocol error threshold exceeded

Thanks again for solving this.

[Christopher McAlpin]

Not sure of the possible side affects or the exact function of this setting. Perhaps Cisco TAC or someone monitoring this forum from IPCBU can comment.

Here are 3 defects regarding this problem:

pstn caller gets fast busy on Unity and Callmanager

http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCea86958&Submit=Search

Unity TSP Should Allow configurable Delay in Answering Calls

http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCea32524&Submit=Search

CFA or CFB to VM fails when calling from DMS100.

http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCdz17571&Submit=Search