cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6701
Views
0
Helpful
5
Replies

Cause i = 0x80FF - Interworking error; unspecified

Hi All,

 

I am getting "Cause i = 0x80FF - Interworking error; unspecified" code in isdn debug.

 

Call flow is : IP PHONE --> CUCM 8.5 --> SIP TRUNK --> CUCM 9.1 --> MGCP GW --> E1 --> PBX --> Phone CfdAll to intra cluster DN

 

Called DN : 87061725

 

Calling DN : 87031717

 

 

The issue is intermittent but most of the time the call failes and the success rate is out of 5 it is 1.

 

I have attanched the "debug isdn q931" and "debug mgcp packets".

 

Could some one help me here?

 

Thanks,

Lajith P

5 Replies 5

Nishant Savalia
Level 4
Level 4

Hi Lajith,

From the debug it seems that call is being released from CUCM but we have to identify which CUCM is releasing the call. And for that below data is required for the failed call:-

  • detail trace of both cucm for failed call (of same time stamp)
  • "debug isdn q931" and "debug mgcp packets" of gateway for the same failed call.

Make sure before making call and collecting traces, detail trace is enabled for both MGCP & SIP.

Also do send the snapshot of SIP Trunk configuration at both CUCM.

Regards,
Nishant Savalia

Regards, Nishant Savalia

Hi Nishant,

 

Thanks for looking into this issue.

 

I have attached traces and logs which you have requested.

 

Gateway debugs and CUCM8.5 traces are attached here, CUCM9.1 traces I was able to upload the particular subsriber traces here since it's size exceeded the limit.

 

Please download full traces from the below link.

 

http://snk.to/f-chkszq2f

 

 

ANI : 87031717 - configured in CUCM8.5, time stamp GMT+1

 

DNIS : 87061725 - Going through E1 to PBX from CUCM9.1, Timestamp GMT

 

Time of the call : between 02:35:05.920 UTC Thu Feb 13 2014 and 02:38:39.103 UTC Thu Feb 13 2014

 

 

Kindly look into it.

 

Thanks.

Lajith,

The logs are too much. You need to send the log files that contain only the call we are interedsted in from both cucm9 and cucm8. Before you send the logs, check using the calling, called and time of call that the call exist in the log file

Please rate all useful posts

"The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

Please rate all useful posts

MOHIT SINGH
Level 1
Level 1

Hi Lajith,

As per logs call was disconnected by CUCM 8.6 with cause code 127.

CUCM 8.6 sends SIP PRACK (CSeq 103) to CUCM 9

03:35:33.655 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 19.106.214.58 on port 5060 index 16159

[8527234,NET]

PRACK sip:87061725@19.106.214.58:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 19.175.128.92:5060;branch=z9hG4bK22980c6c26dde6

From: "HCL TEST PHONE" <87031717>;tag=2818981~48c4acdf-6046-4a2a-90e9-fd8cc09fbdab-217713125

To: <87061725>;tag=3581846~b10d38e7-8ca2-4ffe-b6b0-7a7f1855603c-178442776

Date: Thu, 13 Feb 2014 02:35:33 GMT

Call-ID: 810ef780-2fc12f74-14ec1e-5c80af13@19.175.128.92

CSeq: 103 PRACK

CUCM9 responds with Call leg/Transaction does not exist.

03:35:33.755 |//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 19.106.214.58 on port 5060 index 16159 with 453 bytes:

[8527240,NET]

SIP/2.0 481 Call Leg/Transaction Does Not Exist

Via: SIP/2.0/TCP 19.175.128.92:5060;branch=z9hG4bK22980c6c26dde6

From: "HCL TEST PHONE" <87031717>;tag=2818981~48c4acdf-6046-4a2a-90e9-fd8cc09fbdab-217713125

To: <87061725>;tag=3581846~b10d38e7-8ca2-4ffe-b6b0-7a7f1855603c-178442776

Date: Thu, 13 Feb 2014 02:35:33 GMT

Call-ID: 810ef780-2fc12f74-14ec1e-5c80af13@19.175.128.92

CSeq: 103 PRACK

NOW CUCM 8.6 disconnects the call.

03:35:33.756 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 19.106.214.58 on port 5060 index 16159

[8527242,NET]

CANCEL sip:87061725@19.106.214.58:5060 SIP/2.0

Via: SIP/2.0/TCP 19.175.128.92:5060;branch=z9hG4bK22980a6414c3b7

From: "HCL TEST PHONE" <87031717>;tag=2818981~48c4acdf-6046-4a2a-90e9-fd8cc09fbdab-217713125

To: <87061725>

Date: Thu, 13 Feb 2014 02:35:33 GMT

Call-ID: 810ef780-2fc12f74-14ec1e-5c80af13@19.175.128.92

CSeq: 101 CANCEL

Max-Forwards: 70

Reason: Q.850;cause=127

Content-Length: 0

Cause 127 means interworking error.

I will suggest you to try disabling PRACK on both CUCM SIP trunks. To disable

Go to Device -> Device settings -> SIP profile -> Select the profile used by trunk -> Required Field -> Set it to disable. -> Save and Reset the trunk.

Regards,

Mohit Singh

Hi Mohit,

Thanks, thats wonderful.

CUCM 9.1 is an SME and it connects all our clusters, since we have number of devices and other pbx systems connected I am worried if the setting change causes any other issue. Do you need to review CCM9.1 SIP debugs and MGCP traces as well to conclude the issue

Regards,

Lajith