02-10-2015 04:45 AM - edited 03-17-2019 01:55 AM
Experts,
Following is the call flow;
CIPC1 --> CUCM --> SIP Trunk --> Router/CME --> CIPC2
Configuration:
Media flow around in Router/CME and SIP delayed offer in CUCM
In the above case, when CIPC2 answers the call and Router/CME sends SDP offer in 200 OK, contact IP in SDP is 0.0.0.0 and in result, CUCM never responds with SDP answer in ACK and call fails. Following is SDP offer in 200 OK sent by Router/CME to CUCM.
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.15.10:5060;branch=z9hG4bK4f75085710
From: <sip:601@192.168.15.10>;tag=396~233834fe-a72b-4338-a652-2dcca84d7d54-23558791
To: <sip:2630555@192.168.15.31>;tag=5CEE8C-318
Date: Tue, 10 Feb 2015 18:00:59 GMT
Call-ID: a6911880-4d91f9fe-24-a0fa8c0@192.168.15.10
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:2630555@192.168.15.31:5060;transport=tcp>
Supported: replaces
Session-Expires: 1800;refresher=uac
Require: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 237
v=0
o=CiscoSystemsSIP-GW-UserAgent 8913 7155 IN IP4 192.168.15.31
s=SIP Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 0 RTP/AVP 8 0 18
c=IN IP4 0.0.0.0
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
Any hint?
Regards,
Vivek
Solved! Go to Solution.
02-11-2015 01:33 AM
A more recent link had some more details regarding this:
Media flow around is supported in the following scenarios:
Media is forced to flow through on different types of call flows including the SIP to SIP trunk call with asymmetric flow mode configurations or symmetric flow through configuration. In asymmetric flow mode configurations, one SIP leg is configured in the media flow around mode and another SIP leg is configured in the media flow through mode. In such cases, media is forced to flow through Cisco Unified CME.
Media is forced to flow through Cisco Unified CME for the following types of call flows:
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucme/admin/configuration/guide/cmeadm/cmesystm.html#pgfId-1046249
That's pretty much what i can make out of it, looks like your CME is running an old IOS and version, you need 8.5 or above for flow-around functionality to support the call scenarios listed above.
HTH
Manish
02-10-2015 06:11 AM
Hello Vivek,
Is there any IOS Xcoder/ MTP involved on this call flow?
Can you please provide ccsip debugs and CUCM logs to check the call from beginning?
Thank you,
Shadi
02-10-2015 07:44 AM
Hi Shadi,
Please find below the SIP traces. No transcoder is involved here as I want to have direct RTP between both two phones and both of them supports G711. Region settings in CUCM is done accordingly.
I think the problem lies in CME which is sending incorrect IP in SDP offer (200OK) but not sure what forcing CME to send incorrect IP.
Thanks
Vivek
Received:
INVITE sip:2630555@192.168.15.31:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168.15.10:5060;branch=z9hG4bK53155c0fb6
From: <sip:601@192.168.15.10>;tag=595~233834fe-a72b-4338-a652-2dcca84d7d54-23558797
To: <sip:2630555@192.168.15.31>
Date: Tue, 10 Feb 2015 15:36:31 GMT
Call-ID: 94bc6f00-4da1257f-26-a0fa8c0@192.168.15.10
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM9.1
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback,X-cisco-original-called
Call-Info: <sip:192.168.15.10:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Cisco-Guid: 2495377152-0000065536-0000000016-0168798400
Session-Expires: 1800
P-Asserted-Identity: <sip:601@192.168.15.10>
Remote-Party-ID: <sip:601@192.168.15.10>;party=calling;screen=yes;privacy
R1#=off
Contact: <sip:601@192.168.15.10:5060;transport=tcp>
Max-Forwards: 70
Content-Length: 0
*Feb 10 21:06:36.138: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/TCP 192.168.15.10:5060;branch=z9hG4bK53155c0fb6
From: <sip:601@192.168.15.10>;tag=595~233834fe-a72b-4338-a652-2dcca84d7d54-23558797
To: <sip:2630555@192.168.15.31>;tag=106DD38-174F
Date: Tue, 10 Feb 2015 21:06:36 GMT
Call-ID: 94bc6f00-4da1257f-26-a0fa8c0@192.168.15.10
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Allow-Events: telephone-event
Content-Length: 0
*Feb 10 21:06:36.234: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP 192.168.15.10:5060;branch=z9hG4bK53155c0fb6
From: <sip:601@192.168.15.10>;tag=595~233834fe-a72b-4338-a652-2dcca84d7d54-23558797
To: <sip:2630555@192.168.15.31>;tag=106DD38-174F
Date: Tue, 10 Feb 2015 21:06:36 GMT
Call-ID: 94bc6f00-4da1257f-26-a0fa8c0@192.168.15.10
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDA
R1#TE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:2630555@192.168.15.31:5060;transport=tcp>
Content-Length: 0
R1#
*Feb 10 21:06:38.634: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.15.10:5060;branch=z9hG4bK53155c0fb6
From: <sip:601@192.168.15.10>;tag=595~233834fe-a72b-4338-a652-2dcca84d7d54-23558797
To: <sip:2630555@192.168.15.31>;tag=106DD38-174F
Date: Tue, 10 Feb 2015 21:06:36 GMT
Call-ID: 94bc6f00-4da1257f-26-a0fa8c0@192.168.15.10
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:2630555@192.168.15.31:5060;transport=tcp>
Supported: replaces
Session-Expires: 1800;refresher=uac
Require: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 235
v=0
o=CiscoSystemsSIP-GW-UserAgent 126 648 IN IP4 192.168.15.31
s=SIP Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 0 RTP/AVP 8 0 18
c=IN IP4 0.0.0.0
a=rtpmap:8 PCMA/8000
a=rtpmap
R1#:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
*Feb 10 21:06:39.138: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.15.10:5060;branch=z9hG4bK53155c0fb6
From: <sip:601@192.168.15.10>;tag=595~233834fe-a72b-4338-a652-2dcca84d7d54-23558797
To: <sip:2630555@192.168.15.31>;tag=106DD38-174F
Date: Tue, 10 Feb 2015 21:06:36 GMT
Call-ID: 94bc6f00-4da1257f-26-a0fa8c0@192.168.15.10
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:2630555@192.168.15.31:5060;transport=tcp>
Supported: replaces
Session-Expires: 1800;refresher=uac
Require: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 235
v=0
o=CiscoSystemsSIP-GW-UserAgent 126 648 IN IP4 192.168.15.31
s=SIP Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 0 RTP/AV
R1#P 8 0 18
c=IN IP4 0.0.0.0
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
*Feb 10 21:06:40.138: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.15.10:5060;branch=z9hG4bK53155c0fb6
From: <sip:601@192.168.15.10>;tag=595~233834fe-a72b-4338-a652-2dcca84d7d54-23558797
To: <sip:2630555@192.168.15.31>;tag=106DD38-174F
Date: Tue, 10 Feb 2015 21:06:36 GMT
Call-ID: 94bc6f00-4da1257f-26-a0fa8c0@192.168.15.10
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:2630555@192.168.15.31:5060;transport=tcp>
Supported: replaces
Session-Expires: 1800;refresher=uac
Require: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 235
v=0
o=CiscoSystemsSIP-GW-UserAgent 126 648 IN IP4 192.168.15.
R1#31
s=SIP Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 0 RTP/AVP 8 0 18
c=IN IP4 0.0.0.0
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
*Feb 10 21:06:42.138: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.15.10:5060;branch=z9hG4bK53155c0fb6
From: <sip:601@192.168.15.10>;tag=595~233834fe-a72b-4338-a652-2dcca84d7d54-23558797
To: <sip:2630555@192.168.15.31>;tag=106DD38-174F
Date: Tue, 10 Feb 2015 21:06:36 GMT
Call-ID: 94bc6f00-4da1257f-26-a0fa8c0@192.168.15.10
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:2630555@192.
R1#168.15.31:5060;transport=tcp>
Supported: replaces
Session-Expires: 1800;refresher=uac
Require: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 235
v=0
o=CiscoSystemsSIP-GW-UserAgent 126 648 IN IP4 192.168.15.31
s=SIP Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 0 RTP/AVP 8 0 18
c=IN IP4 0.0.0.0
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
R1#
*Feb 10 21:06:46.146: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.15.10:5060;branch=z9hG4bK53155c0fb6
From: <sip:601@192.168.15.10>;tag=595~233834fe-a72b-4338-a652-2dcca84d7d54-23558797
To: <sip:2630555@192.168.15.31>;tag=106DD38-174F
Date: Tue, 10 Feb 2015 21:06:36 GMT
Call-ID: 94bc6f00-4da1257f-26-a0fa8c0@192.168.15.10
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:2630555@192.
R1#168.15.31:5060;transport=tcp>
Supported: replaces
Session-Expires: 1800;refresher=uac
Require: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 235
v=0
o=CiscoSystemsSIP-GW-UserAgent 126 648 IN IP4 192.168.15.31
s=SIP Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 0 RTP/AVP 8 0 18
c=IN IP4 0.0.0.0
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
R1#
*Feb 10 21:06:50.146: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.15.10:5060;branch=z9hG4bK53155c0fb6
From: <sip:601@192.168.15.10>;tag=595~233834fe-a72b-4338-a652-2dcca84d7d54-23558797
To: <sip:2630555@192.168.15.31>;tag=106DD38-174F
Date: Tue, 10 Feb 2015 21:06:36 GMT
Call-ID: 94bc6f00-4da1257f-26-a0fa8c0@192.168.15.10
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:2630555@192.
R1#168.15.31:5060;transport=tcp>
Supported: replaces
Session-Expires: 1800;refresher=uac
Require: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 235
v=0
o=CiscoSystemsSIP-GW-UserAgent 126 648 IN IP4 192.168.15.31
s=SIP Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 0 RTP/AVP 8 0 18
c=IN IP4 0.0.0.0
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
R1#
*Feb 10 21:06:54.146: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.15.10:5060;branch=z9hG4bK53155c0fb6
From: <sip:601@192.168.15.10>;tag=595~233834fe-a72b-4338-a652-2dcca84d7d54-23558797
To: <sip:2630555@192.168.15.31>;tag=106DD38-174F
Date: Tue, 10 Feb 2015 21:06:36 GMT
Call-ID: 94bc6f00-4da1257f-26-a0fa8c0@192.168.15.10
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:2630555@192.
R1#168.15.31:5060;transport=tcp>
Supported: replaces
Session-Expires: 1800;refresher=uac
Require: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 235
v=0
o=CiscoSystemsSIP-GW-UserAgent 126 648 IN IP4 192.168.15.31
s=SIP Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 0 RTP/AVP 8 0 18
c=IN IP4 0.0.0.0
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
R1#
*Feb 10 21:06:55.818: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:2630555@192.168.15.31:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 192.168.15.10:5060;branch=z9hG4bK5433202759
From: <sip:601@192.168.15.10>;tag=595~233834fe-a72b-4338-a652-2dcca84d7d54-23558797
To: <sip:2630555@192.168.15.31>;tag=106DD38-174F
Date: Tue, 10 Feb 2015 15:36:31 GMT
Call-ID: 94bc6f00-4da1257f-26-a0fa8c0@192.168.15.10
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: presence, kpml
Content-Length: 0
*Feb 10 21:06:55.878: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
BYE sip:601@192.168.15.10:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 192.168.15.31;branch=z9hG4bK151189
From: <sip:2630555@192.168.15.31>;tag=106DD38-174F
To: <sip:601@192.168.15.10>;tag=595~233834fe-a72b-4338-a652-2dcca84d7d54-23558797
Date: Tue, 10 Feb 2015 21:06:55 GMT
Call-ID: 94bc6f00-4da1257f-26-a0fa8c0@192.168.15.10
User-Agent: Cisco-SIPGateway/IOS-12.x
Max-Forwards: 70
Time
R1#stamp: 1423602415
CSeq: 101 BYE
Reason: Q.850;cause=16
Content-Length: 0
*Feb 10 21:06:55.902: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.15.31;branch=z9hG4bK151189
From: <sip:2630555@192.168.15.31>;tag=106DD38-174F
To: <sip:601@192.168.15.10>;tag=595~233834fe-a72b-4338-a652-2dcca84d7d54-23558797
Date: Tue, 10 Feb 2015 15:36:51 GMT
Call-ID: 94bc6f00-4da1257f-26-a0fa8c0@192.168.15.10
CSeq: 101 BYE
Content-Length: 0
02-10-2015 08:21 AM
is this happening only for inbound calls to CIPC? or other models also affected?
what happens if the CIPC makes call to phones in CUCM?
have you tried changing CIPC version & check?
Also, CUCM did respond with ACK to CME but only for the 7th 200 OK.
you may also crosscheck the CIPC settings Preferences>Audio>Network (Detect automatically)
02-10-2015 10:22 AM
Hi Suresh,
With in CUCM, calls are working perfectly and too within CME. Issue is only when call is made from CUCM extension to one of CME extension and viceversa.
I haven't tried changing the CIPC version b/c I felt something wrong is in CME and that is the reason CUCM not responding with SDP answer in ACK.
One point I would like to mention that if I use "Media Flow Through" command in CME, CME sends its own interface IP address in SDP offer (200 OK) to CUCM and call works fine as RTP flows from CUCM extension to CME to CME extension (and viceversa) however problem exists only if I issue command "Media Flow Around". Doing so, CME should actually send it's CIPC extension IP address in SDP offer to CUCM but sending 0.0.0.0 IP address.
Regards,
Vivek
02-11-2015 12:47 AM
Hi Vivek,
As per the following link:
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucme/admin/configuration/guide/cmeadm/cmenetwk.html
Also check the following post
https://supportforums.cisco.com/discussion/11483306/rtp-media-flow-between-cucm-and-cme-endpoints
HTH
Manish
02-11-2015 01:05 AM
Thanks for the info Manish :)
02-11-2015 01:21 AM
Hi Manish,
Thanks for highlighting hidden information.
1. Media Flow-around configured with the media flow-around command is not supported by Cisco Unified CME with SIP phones.
Does this means that media flow through works with SCCP phones? In my call flow, there is no SIP phone attached with CME, instead it's SCCP phone (CIPC) and a SIP trunk connecting CUCM to CME. Is above statement still valid? Following is the flow;
CIPC1 -> SCCP -> CUCM -> SIP Trunk -> CME -> SCCP -> CIPC2
-------------------------------------------------------------------------------------------------------------
2. https://supportforums.cisco.com/discussion/11483306/rtp-media-flow-between-cucm-and-cme-endpoints>>
Above discussion conclude that media flow around is not supported for external calls at all (going through dial-peer). Doesn't it contradicts with another statement which says that media flow around is not supported by CME with SIP phones, implicit means that supports for all other phones.
Regards,
Vivek
02-11-2015 01:33 AM
A more recent link had some more details regarding this:
Media flow around is supported in the following scenarios:
Media is forced to flow through on different types of call flows including the SIP to SIP trunk call with asymmetric flow mode configurations or symmetric flow through configuration. In asymmetric flow mode configurations, one SIP leg is configured in the media flow around mode and another SIP leg is configured in the media flow through mode. In such cases, media is forced to flow through Cisco Unified CME.
Media is forced to flow through Cisco Unified CME for the following types of call flows:
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucme/admin/configuration/guide/cmeadm/cmesystm.html#pgfId-1046249
That's pretty much what i can make out of it, looks like your CME is running an old IOS and version, you need 8.5 or above for flow-around functionality to support the call scenarios listed above.
HTH
Manish
02-11-2015 02:08 AM
Hi Manish,
Seems direct RTP (media flow around) is not supported when SCCP phone attached to CME makes external call. Thanks for getting this information.
Regards,
Vivek
02-11-2015 02:10 AM
Just a thought, if it's not supported, CME should drop the call with valid SIP cause instead of putting invalid IP in SDP offer and try to complete the call which will eventually fail.
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