02-12-2014 12:03 AM - edited 03-16-2019 09:42 PM
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
02-12-2014 02:26 AM
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:-
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
02-12-2014 06:56 PM
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.
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.
02-13-2014 03:59 AM
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"
02-13-2014 07:17 AM
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-21771312587031717>
To: <87061725>;tag=3581846~b10d38e7-8ca2-4ffe-b6b0-7a7f1855603c-17844277687061725>
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-21771312587031717>
To: <87061725>;tag=3581846~b10d38e7-8ca2-4ffe-b6b0-7a7f1855603c-17844277687061725>
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-21771312587031717>
To: <87061725>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 -> -> Set it to disable. -> Save and Reset the trunk.
Regards,
Mohit Singh
02-16-2014 03:49 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide