Calls from PRI to Unity Connection recieve busy signal

Unanswered Question
Dec 10th, 2008

When placing calls into the system from a PSTN number to an IP Phone the calls work as expected. If the user doesn't answer phone the call is properly sent to the voicemail system and the caller may leave a messege. However calls entering through the PRI that are directed to the Unity Attendant Application recieve a fast-busy immediately. Watching the Call Viewer it is possible to see the call enter the sytem and hit the appropriate greeting (port monitor). Calls that do not traverse the PRI are able to successfully engage the greeting without issue.

Router#s#

Dec 10 14:42:02.280: ISDN Se0/1/0:23 Q931: RX <- SETUP pd = 8 callref = 0x1528

Bearer Capability i = 0x8090A2

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA98383

Exclusive, Channel 3

Calling Party Number i = 0x2183, '408XXXXXXX' (number masked here for Privacy)

Plan:ISDN, Type:National

Called Party Number i = 0xC1, '2717'

Plan:ISDN, Type:Subscriber(local)

Dec 10 14:42:02.372: ISDN Se0/1/0:23 Q931: TX -> CALL_PROC pd = 8 callref = 0x9528

Channel ID i = 0xA98383

Exclusive, Channel 3

Dec 10 14:42:02.372: ISDN Se0/1/0:23 Q931: TX -> ALERTING pd = 8 callref = 0x9528

Progress Ind i = 0x8088 - In-band info or appropriate now available

Dec 10 14:42:02.404: ISDN Se0/1/0:23 Q931: TX -> CONNECT pd = 8 callref = 0x9528

Display i = 'VoiceMail'

Dec 10 14:42:02.424: ISDN Se0/1/0:23 Q931: RX <- STATUS pd = 8 callref = 0x1528

Cause i = 0x80E31E - Information element not implemented

Call State i = 0x07

Dec 10 14:42:02.476: ISDN Se0/1/0:23 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x1528

Dec 10 14:42:02.480: ISDN Se0/1/0:23 Q931: RX <- STATUS pd = 8 callref = 0x1528

Cause i = 0x80E328 - Information element not implemented

Call State i = 0x0A

Dec 10 14:42:02.488: ISDN Se0/1/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x9528

Cause i = 0x80E5 - Message not compatible with call state

Dec 10 14:42:02.504: ISDN Se0/1/0:23 Q931: TX -> STATUS pd = 8 callref = 0x9528

Cause i = 0x80E1 - Message type not implemented

Call State i = 0x0B

Dec 10 14:42:02.576: ISDN Se0/1/0:23 Q931: RX <- RELEASE pd = 8 callref = 0x1528

Dec 10 14:42:02.660: ISDN Se0/1/0:23 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x9528

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
jrockhill Fri, 12/12/2008 - 08:11

Sure does and have tried NULL partition, in fact incoming calls that go unanswered to subscribers fail over to Unity without issue. Attempting to forward calls directly to or using a translation pattern seem to be failing however. We have even tried different numbers. Result is the same: fast busy. It almost seems like a codec issue, but we have changed those values as well (tried g711 and g729)

jrockhill Fri, 12/12/2008 - 13:14

already checked (unchecked) that setting, behavior is still the same

review of the CCM trace reveals the following as well:

12/11/2008 00:14:52.607 CCM|Forwarding - getMaskedDn - maskedDn=[2700] dn=[2717] mask=[2700]|

12/11/2008 00:14:52.611 CCM|Forwarding - decodeDivertingLegInfo2APDU - ERROR - Original called Name and diverting name not received, clearing originalCalledName/originalCalledNamePi

Nicholas Matthews Fri, 12/12/2008 - 14:13

You may need to 'no mgcp' 'mgcp' the gateway as well as a reset in CCM.

This:

Dec 10 14:42:02.404: ISDN Se0/1/0:23 Q931: TX -> CONNECT pd = 8 callref = 0x9528

Display i = 'VoiceMail'

looks to be causing the problem.

jrockhill Fri, 12/12/2008 - 14:17

Yes I have reset it a number of times, both through CCM and through the router interface. I realize that 'VoiceMail' is the error, that is the name display of the voice-mail ports.

What really gets me is that this is one of six sites with duplicate configurations and this is the only one with the issue.

All home back to the same Unity server. changes to the recipient callhandler makes no difference. I can see the calls hit the Unity server (call viewer). I can verify that the correct callhandler is accessed (port monitor).

Nicholas Matthews Fri, 12/12/2008 - 17:36

Taking that checkbox off and a reset should fix this. It's possible that they're not sync'd or maybe a different T1.

If it's H323/SIP you can try this command as well:

Serial0/0:23

no isdn outgoing display-ie

If you haven't done the 'no mgcp' 'mgcp' on the gateway it's possible that the resets haven't told the gateway to re-download it's configuration from CCM via tftp. If you have term mon on when you reset the gateway you should see a message indicating that the gateway has been configured.

jrockhill Fri, 12/12/2008 - 18:55

going to try resetting it again this evening, after all I have nothing to lose and everything to gain on it. I will keep you all posted

Actions

This Discussion