Router/CME sending 0.0.0.0 IP address in SIP/SDP offer

[Vivek Batra]

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

[Shadi Shami]

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

[Vivek Batra]

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

[Suresh Subramanian]

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)

[Vivek Batra]

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

[Manish Gogna]

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

• Cisco Unified CME 3.4 and later versions support Media Flow-through mode only; enabling SIP-to-SIP calls is required before you can successfully make SIP-to-SIP calls.
• Media Flow-around configured with the media flow-around command is not supported by Cisco Unified CME with SIP phones.

Also check the following post

https://supportforums.cisco.com/discussion/11483306/rtp-media-flow-between-cucm-and-cme-endpoints

HTH

Manish

[Suresh Subramanian]

Thanks for the info Manish :)

[Vivek Batra]

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

[Manish Gogna · Accepted solution]

A more recent link had some more details regarding this:

Media flow around is supported in the following scenarios:

• Single Numbe Reach (SNR) Push—If an SNR call on a SIP trunk is pushed over to a mobile user over another SIP trunk, the resulting connection is a SIP-SIP trunk call connection. If both SIP trunks are configured for media flow around, the media is allowed to flow around Cisco Unified CME for the resulting call.
• Call Forward—If a SIP trunk call is forwarded over another SIP trunk and both the SIP trunks are configured for media flow around, media flows around Cisco Unified CME for the resulting SIP-SIP trunk call. Media flow around is supported for all types of call forwarding, such as call forward night-service, call forward all, call forward busy, and call forward no-answer.
• Call Transfer—If a SIP trunk call is transferred over another SIP trunk and both SIP trunks are configured for media flow around, media flows around Cisco Unified CME for the resulting SIP-SIP trunk call. Media flow around is supported on both SIP-line-initiated call transfer and SCCP-line-initiated call transfers. It is supported for all types of call transfers, such as blind transfer, consult transfer, and full consult transfer.

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:

• Any calls involving a SIP endpoint, a SCCP endpoint, PSTN trunks (BRI/PRI/FXO), or FXO circuits.
• SIP to SIP trunk call with either asymmetric flow mode configurations or symmetric flow through configurations.
• SIP to SIP trunk call that requires transcoding services on Cisco Unified CME.
• SIP to SIP trunk calls that require DTMF interworking with RFC2833 on one side, and SIP-Notify on the other side.
• SNR pullback to SCCP— When an SNR call is pulled back from a mobile phone to the local SCCP SNR extension, the call is connected to the SCCP SNR extension. Media is required to flow through Cisco Unified CME because one of the calls is from a SCCP SNR extension, which is local to Cisco Unified CME.

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

[Vivek Batra]

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

[Vivek Batra]

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.