Scenario#29 – Interworking error -0x80FF

I came across this issue with one of  our customer last week where a call was coming in to receptionist at Site ‘A’ but she was not able to transfer the call to someone at Site ‘B’. They had Centralized deployment and all phones on branch sites were registered to Central site. The call was dropping as soon as she would press ‘hold’ to transfer the call. This is what I was getting on Site ‘A’ gateway:

2621-VG01#
.Feb  7 09:25:14.805: ISDN Se1/0:15 Q931: RX <- SETUP pd = 8  callref = 0x0002
Sending Complete
Bearer Capability i = 0x8090A3
Standard = CCITT
Transer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98382
Exclusive, Channel 2
Called Party Number i = 0x81, ‘700481’
Plan:ISDN, Type:Unknown
.Feb  7 09:25:14.837: ISDN Se1/0:15 Q931: TX -> CALL_PROC pd = 8  callref = 0x8002
Channel ID i = 0xA98382
Exclusive, Channel 2
.Feb  7 09:25:14.961: ISDN Se1/0:15 Q931: TX -> ALERTING pd = 8  callref = 0x8002
Progress Ind i = 0x8188 – In-band info or appropriate now available
.Feb  7 09:25:22.877: ISDN Se1/0:15 Q931: TX -> CONNECT pd = 8  callref = 0x8002
.Feb  7 09:25:22.945: ISDN Se1/0:15 Q931: RX <- CONNECT_ACK pd = 8  callref = 0x0002

.Feb  7 09:25:41.934: ISDN Se1/0:15 Q931: TX -> DISCONNECT pd = 8  callref = 0x8002
Cause i = 0x80FF – Interworking error; unspecified
.Feb  7 09:25:42.118: ISDN Se1/0:15 Q931: RX <- RELEASE pd = 8  callref = 0x0002
.Feb  7 09:25:42.122: ISDN Se1/0:15 Q931: TX -> RELEASE_COMP pd = 8  callref = 0x8002

Now this error had no explanation whatsoever and it was quite hard to troubleshoot.

I knew that for a transfer function to work properly across WAN (G729-G729) you need a MTP. The MRGL had a group with MTP as well as transcoder. I noticed MTP was added as part of one group where announciator, CFB etc were added with it as well. Transcoder was added seperately. I think I read somewhere that Call manager sometimes take Transcoder as MTP if MTP is not added in a seperate group. As transcoder can’t do G729-G729, it will fail to provide supplemantary services to the gateway and eventually the call will drop. As a good design approach, always place MTP in a seperate group and at the top of MRGL.

I removed MTP from that group, placed it in a seperate group and prioritized it at MRGL.

Made test calls and they all worked fine.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s