CUBE Early Offer Not Working

[Suresh Subramanian]

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
 

[Ayodeji Okanlawon]

Suresh,

Can you send us debug ccsip all? and your sh run.

[Suresh Subramanian]

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.

[Ayodeji Okanlawon]

Which call is affected in this log..The first call has EO from CUCM and EO to ITSP

[Suresh Subramanian]

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.

[Ayodeji Okanlawon]

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

[Rajkumar Yadav]

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.

[Manish Prasad]

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

[Suresh Subramanian]

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.

[Suresh Subramanian]

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.

[Ayodeji Okanlawon]

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.

[Manish Prasad]

Thank you.