Hi Andrew...Its me again
Okay Something weird is going on with your CUBE...
+++When you disconnected the call, your ITSP sends a CANCEL to CUBE (A CANCEL is used to terminate a session that has not been established)++
035351: Feb 24 22:34:20.250: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
CANCEL sip:17772253754@192.168.1.203:5060 SIP/2.0
v: SIP/2.0/UDP 204.11.192.159:5080;branch=z9hG4bK-7287140da0675948b39913337b8b5f45
f: <18165297500>;tag=3602291657-766086
t: <>18452055544@ss.callcentric.com>
i: 2322552-3602291657-766054@msw2.telengy.net
CSeq: 1 CANCEL
Max-Forwards: 10
l: 0
+++What should happen next is that CUBE needs to send a 200 OK back to ITSP+++
This is what we see here
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 204.11.192.159:5080;branch=z9hG4bK-7287140da0675948b39913337b8b5f45
From: <18165297500>;tag=3602291657-766086
To: <>18452055544@ss.callcentric.com>
Date: Tue, 25 Feb 2014 04:34:20 GMT
Call-ID: 2322552-3602291657-766054@msw2.telengy.net
CSeq: 1 CANCEL
Content-Length: 0
+++Next CUBE should send a CANCEL to CUCM, This is where evrything breaks++++
CUBE appears to send a CANCEL to CUCM and then A CANCEL back to ITSP
035438: Feb 24 22:34:20.274: //12657/EC6D16FC86E4/SIP/Msg/ccsipDisplayMsg:
Sent:
CANCEL sip:17772253754@192.168.1.200:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.203:5060;branch=z9hG4bK32C91376
From: <>18165297500@callcentric.com>;tag=2B6FE9F4-3A1
To: <17772253754>
Date: Tue, 25 Feb 2014 04:34:18 GMT
Call-ID: EC79E80D-9D0C11E3-86EAE4C3-DC5CB4B2@192.168.1.203
CSeq: 101 CANCEL
Max-Forwards: 70
Timestamp: 1393302860
Reason: Q.850;cause=16
Content-Length: 0
035439: Feb 24 22:34:20.278: //12656/EC6D16FC86E4/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 487 Request Cancelled
Via: SIP/2.0/UDP 204.11.192.159:5080;branch=z9hG4bK-7287140da0675948b39913337b8b5f45
From: <18165297500>;tag=3602291657-766086
To: <>18452055544@ss.callcentric.com>;tag=2B6FEA14-9A4
Date: Tue, 25 Feb 2014 04:34:20 GMT
Call-ID: 2322552-3602291657-766054@msw2.telengy.net
CSeq: 1 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Reason: Q.850;cause=16
Content-Length: 0
We never got a 200 OK back from CUCM for the CANCEL.Whic suggests either that CUCM didnt receive the CANCEL or something has gone AWOL!
+++ This is what we get back from CUCM to the CANCEL CUBE sent to it, +++
CUCM cant find the call....
Received:
SIP/2.0 481 Call Leg/Transaction Does Not Exist
Via: SIP/2.0/UDP 192.168.1.203:5060;branch=z9hG4bK32C91376
From: <>18165297500@callcentric.com>;tag=2B6FE9F4-3A1
To: <17772253754>
Call-ID: EC79E80D-9D0C11E3-86EAE4C3-DC5CB4B2@192.168.1.203
CSeq: 101 CANCEL
Content-Length: 0
+++However later on, CUCM sends an UPDATE on the same call+++
Call seem to be ringing on extension 2000..So CUCM thinks this call is still alive...
Received:
UPDATE sip:18165297500@192.168.1.203:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.200:5060;branch=z9hG4bK6153f19d98
From: <17772253754>;tag=110~06cd0c53-1787-41cc-a9bc-50779945ad4e-18923534
To: <>18165297500@callcentric.com>;tag=2B6FE9F4-3A1
Date: Tue, 25 Feb 2014 04:13:06 GMT
Call-ID: EC79E80D-9D0C11E3-86EAE4C3-DC5CB4B2@192.168.1.203
User-Agent: Cisco-CUCM8.6
Max-Forwards: 70
Supported: timer,resource-priority,replaces
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 UPDATE
Supported: X-cisco-srtp-fallback
Supported: Geolocation
P-Asserted-Identity: <2000>
Remote-Party-ID: <2000>;party=calling;screen=yes;privacy=off
Contact: <18165297500>;isFocus
Content-Length: 0
+++But the CUBE disagress...Says I no longer have this call+++
Sent:
SIP/2.0 481 Call Leg/Transaction Does Not Exist
Via: SIP/2.0/UDP 192.168.1.200:5060;branch=z9hG4bK6153f19d98
From: <17772253754>;tag=110~06cd0c53-1787-41cc-a9bc-50779945ad4e-18923534
To: <>18165297500@callcentric.com>;tag=2B6FE9F4-3A1
Call-ID: EC79E80D-9D0C11E3-86EAE4C3-DC5CB4B2@192.168.1.203
CSeq: 101 UPDATE
Content-Length: 0
So this is a typical example of finger pointing...Its you, its not me, you have it, no I dont! LOL. Never knew codes can accuse each other...
Okay so what do we do...We have another strange one on our hands..
1. Enable detailed tracing on CUCM. Do a test call and send the cucm SDI or (SDL logs if you are on cucm9.x) along with only debug ccsip messages.
2. Use RTMT to download CUCM logs. Ensure that the call is present in the log before sending over..
Please rate all useful posts
"The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
035351: Feb 24 22:34:20.250: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
CANCEL sip:17772253754@192.168.1.203:5060 SIP/2.0
v: SIP/2.0/UDP 204.11.192.159:5080;branch=z9hG4bK-7287140da0675948b39913337b8b5f45
f: <18165297500>;tag=3602291657-766086
t: <>18452055544@ss.callcentric.com>i: 2322552-3602291657-766054@msw2.telengy.netCSeq: 1 CANCEL
Max-Forwards: 10
l: 0
Please rate all useful posts
