04-09-2014 01:05 AM - edited 03-16-2019 10:25 PM
I have SIP-SIP CUBE with EO offer forced & voice class codec under dial-peers. Randomly the calls going out to ITSP have no SDP at Invite message.
There is no issues observed with this behaviour, as my provider accepts both EO & DO calls and calls are successful without any issues.
CUBE model: 2921 with 15.1.4M3 IOS. any advice on this please?
Thanks
Suresh
04-09-2014 02:32 AM
Suresh,
Can you send us debug ccsip all? and your sh run.
04-09-2014 03:13 AM
I have debug ccsip message & debug voice ccapi inout attached along with the truncated config.
for the DO calls sent to ITSP, we received DO from CUCM, but we've enabled EO on the SIP profile applied to the trunk between CUCM & CUBE. But Irrespective EO/DO inbound leg, the outbound leg to ITSP should be EO as forced in the dial-peer.
04-09-2014 03:27 AM
Which call is affected in this log..The first call has EO from CUCM and EO to ITSP
04-09-2014 03:41 AM
sorry, missed out to mention the time stamp. it is at 07:56:37.204. The last call in the log. from +48222022013 to +48605903660.
04-09-2014 03:55 AM
The INVITE at 7:56:37 is a RE-INVITE. The original call started at 7:56:15 and it had EO on both the CUCM side and the side to the ITSP
459756: Apr 9 07:56:15.560: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:+48605903660@10.224.1.252:5060 SIP/2.0
Via: SIP/2.0/TCP 153.112.49.23:5060;branch=z9hG4bK268eb34f8d90f3
From: "Zagozda Przemyslaw" <sip:+48222022013@153.112.49.23>;tag=12143085~e4066516-2467-4c7d-ae0c-e82ad64dd0c5-114408396
To: <sip:+48605903660@10.224.1.252>
Date: Wed, 09 Apr 2014 06:56:15 GMT
Call-ID: 9bb9700-3441ef0f-20c2cc-17317099@153.112.49.23
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM8.6
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback,X-cisco-original-called
Cisco-Guid: 0163288832-0000065536-0000954180-0389116057
Session-Expires: 1800
P-Asserted-Identity: "Zagozda Przemyslaw" <sip:+48222022013@153.112.49.23>
Remote-Party-ID: "Zagozda Przemyslaw" <sip:+48222022013@153.112.49.23>;party=calling;screen=yes;privacy=off
Contact: <sip:+48222022013@153.112.49.23:5060;transport=tcp>
Max-Forwards: 69
Content-Type: application/sdp
Content-Length: 292
v=0
o=CiscoSystemsCCM-SIP 12143085 1 IN IP4 153.112.49.23
s=SIP Call
c=IN IP4 153.112.49.24
and this is the call to the ITSP
459790: Apr 9 07:56:15.572: //99165/09BB9700000E/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:+48605903660@10.251.253.20:5060 SIP/2.0
Via: SIP/2.0/UDP 10.251.253.1:5060;branch=z9hG4bK92E6BE6
Remote-Party-ID: "Zagozda Przemyslaw" <sip:+48222022013@10.251.253.1>;party=calling;screen=yes;privacy=off
From: "Zagozda Przemyslaw" <sip:+48222022013@10.251.253.1>;tag=2420E974-1025
To: <sip:+48605903660@10.251.253.20>
Date: Wed, 09 Apr 2014 06:56:15 GMT
Call-ID: E0E12442-BEEA11E3-8A22DD7D-36B5601C@10.251.253.1
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 0163288832-0000065536-0000954180-0389116057
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1397026575
Contact: <sip:+48222022013@10.251.253.1:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 68
Session-Expires: 1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 291
v=0
o=CiscoSystemsCCM-SIP 12143085 1 IN IP4 153.112.49.23
s=SIP Call
c=IN IP4 10.251.253.1
b=TIAS:64000
b=AS:64
t=0 0
m=audio 17262 RTP/AVP 0 8 101
a=label:Audio
a=rtpmap:0 PCMU/8000
This is the RE-INVITE without SDP from CUCM. You can see the TO tag: usually once you have a TO tag, this is indicative of a RE-INVITE
459841: Apr 9 07:56:37.204: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:+48605903660@10.224.1.252:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 153.112.49.23:5060;branch=z9hG4bK268ebe7de07ba5
From: "Zagozda Przemyslaw" <sip:+48222022013@153.112.49.23>;tag=12143085~e4066516-2467-4c7d-ae0c-e82ad64dd0c5-114408396
To: <sip:+48605903660@10.224.1.252>;tag=2420F080-86
Date: Wed, 09 Apr 2014 06:56:37 GMT
Call-ID: 9bb9700-3441ef0f-20c2cc-17317099@153.112.49.23
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM8.6
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 102 INVITE
Max-Forwards: 70
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
P-Asserted-Identity: "Zagozda Przemyslaw" <sip:+48222022013@153.112.49.23>
Remote-Party-ID: "Zagozda Przemyslaw" <sip:+48222022013@153.112.49.23>;party=calling;screen=yes;privacy=off
Contact: <sip:+48222022013@153.112.49.23:5060;transport=tcp>
Content-Length: 0
04-09-2014 05:21 AM
Sir,
the contact field address (IP address or DNS) is always used while sending bye message, so it could be that 153.112.49.23 not reacable or something related that.
Contact: <sip:+48222022013@153.112.49.23:5060;transport=tcp>
As suresh suggested that call connected but never disconnected.
04-09-2014 03:43 AM
Here are two paise from my side :)
The call ID is remain same for EO and DO calls.
459620: Apr 9 07:55:39.328: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:+48605903660@10.224.1.252:5060 SIP/2.0
Via: SIP/2.0/TCP 153.112.49.23:5060;branch=z9hG4bK268ea376b03b28
From: "Zagozda Przemyslaw" <sip:+48222022013@153.112.49.23>;tag=12143052~e4066516-2467-4c7d-ae0c-e82ad64dd0c5-114408370
To: <sip:+48605903660@10.224.1.252>
Date: Wed, 09 Apr 2014 06:55:39 GMT
Call-ID: f4466d00-3441eeeb-20c2c5-17317099@153.112.49.23
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM8.6
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback,X-cisco-original-called
Cisco-Guid: 4098256128-0000065536-0000954174-0389116057
Session-Expires: 1800
P-Asserted-Identity: "Zagozda Przemyslaw" <sip:+48222022013@153.112.49.23>
Remote-Party-ID: "Zagozda Przemyslaw" <sip:+48222022013@153.112.49.23>;party=calling;screen=yes;privacy=off
Contact: <sip:+48222022013@153.112.49.23:5060;transport=tcp>
Max-Forwards: 69
Content-Type: application/sdp
Content-Length: 292
v=0
o=CiscoSystemsCCM-SIP 12143052 1 IN IP4 153.112.49.23
s=SIP Call
c=IN IP4 153.112.49.24
b=TIAS:64000
b=AS:64
t=0 0
m=audio 26904 RTP/AVP 0 8 101
a=label:Audio
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
459654: Apr 9 07:55:39.344: //99161/F4466D00000E/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:+48605903660@10.251.253.20:5060 SIP/2.0
Via: SIP/2.0/UDP 10.251.253.1:5060;branch=z9hG4bK92E119F4
Remote-Party-ID: "Zagozda Przemyslaw" <sip:+48222022013@10.251.253.1>;party=calling;screen=yes;privacy=off
From: "Zagozda Przemyslaw" <sip:+48222022013@10.251.253.1>;tag=24205BEC-178
To: <sip:+48605903660@10.251.253.20>
Date: Wed, 09 Apr 2014 06:55:39 GMT
Call-ID: CB48989B-BEEA11E3-8A1BDD7D-36B5601C@10.251.253.1
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 4098256128-0000065536-0000954174-0389116057
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1397026539
Contact: <sip:+48222022013@10.251.253.1:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 68
Session-Expires: 1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 291
v=0
o=CiscoSystemsCCM-SIP 12143052 1 IN IP4 153.112.49.23
s=SIP Call
c=IN IP4 10.251.253.1
b=TIAS:64000
b=AS:64
t=0 0
m=audio 17372 RTP/AVP 0 8 101
a=label:Audio
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
--------------------------------------------------------------------------------------------------------
459705: Apr 9 07:55:49.260: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:+48605903660@10.224.1.252:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 153.112.49.23:5060;branch=z9hG4bK268ea931c48d72
From: "Zagozda Przemyslaw" <sip:+48222022013@153.112.49.23>;tag=12143052~e4066516-2467-4c7d-ae0c-e82ad64dd0c5-114408370
To: <sip:+48605903660@10.224.1.252>;tag=24207888-1599
Date: Wed, 09 Apr 2014 06:55:49 GMT
Call-ID: f4466d00-3441eeeb-20c2c5-17317099@153.112.49.23
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM8.6
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 102 INVITE
Max-Forwards: 70
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
P-Asserted-Identity: "Zagozda Przemyslaw" <sip:+48222022013@153.112.49.23>
Remote-Party-ID: "Zagozda Przemyslaw" <sip:+48222022013@153.112.49.23>;party=calling;screen=yes;privacy=off
Contact: <sip:+48222022013@153.112.49.23:5060;transport=tcp>
Content-Length: 0
459709: Apr 9 07:55:49.264: //99161/F4466D00000E/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:+48605903660@10.251.253.20:5060 SIP/2.0
Via: SIP/2.0/UDP 10.251.253.1:5060;branch=z9hG4bK92E3261E
From: "Zagozda Przemyslaw" <sip:+48222022013@10.251.253.1>;tag=24205BEC-178
To: <sip:+48605903660@10.251.253.20>;tag=as4dce20f6
Date: Wed, 09 Apr 2014 06:55:49 GMT
Call-ID: CB48989B-BEEA11E3-8A1BDD7D-36B5601C@10.251.253.1
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 4098256128-0000065536-0000954174-0389116057
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 102 INVITE
Max-Forwards: 70
Timestamp: 1397026549
Contact: <sip:+48222022013@10.251.253.1:5060>
Expires: 180
Allow-Events: telephone-event
Content-Length: 0
so what happens is that CUCM still thinks the previous call is still hanging in there. I think you need to enable "send send-receive SDP in mid-all INVITE" from the trunk section of sip profile. That will resolve the DO from CUCM.
I think this will also resolve DO from CUBE as well because CUBE is tagging with same tag ID of the previous call.
Thanks
Manish
04-09-2014 04:24 AM
we we trying around 15 test calls during that time for an intermittent caller ID issue, it was just the direct calls to mobile and not sure why Reinvite came from CUCM as I'm sure nothing done at calling party side. may be i need to collect more logs and traces for test calls again using my test phone and see if it happens again.
04-09-2014 04:47 AM
Hello Manish, I just talked to the user. He said, the call call remained active on his calling phone, though he disconnected on his mobile. I believe that is the reason the Reinvite generated from CUCM side. Unfortunately the Bye message was not captured in the CUBE logs collected for the same call, so we don't know whether or not the provider sent the BYE message to CUBE.
04-09-2014 05:02 AM
Manish,
This is simply a RE-INVITE. CUCM is not thinking that the call is active. A RE-INVITE is indicated by the TO tag.
04-09-2014 05:13 AM
Thank you.
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