Buy or Renew
Buy or Renew
Cisco + Splunk: It’s a new day for your data. Learn more.
 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
1556
Views
5
Helpful
6
Replies

CUBE modifies unexpectedly SIP Headers

Paul Freiberg
Level 1
Level 1

‎01-05-2016 12:36 AM - edited ‎03-18-2019 05:22 AM

Hi all,

I have an for me unexpected behaviour of my CUBE. It modifies FROM and Contact headers if UCM sends a INVITE with Diversion Header. I think thats why my ITSP answers my INVITE with message too large.

As you will see in the received INVITE (from UCM) the FROM and Contact Header are filled with +494515005413 and Diversion and PAI are filled with +4945131012012.

007698: Jan  4 09:23:43.782: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:+4917662059124@141.83.xx.xx:5061 SIP/2.0
Via: SIP/2.0/TLS 172.xx.xx.xx:5061;branch=z9hG4bKc5f76e5c9ac0
From: <sip:+494515005413@172.xx.xx.xx>;tag=820157~4498ec3c-29e8-4cb2-abe3-b65eefebc6a9-35392719
To: <sip:+4917662059124@141.83.xx.xx>
Date: Mon, 04 Jan 2016 08:23:43 GMT
Call-ID: 76181700-68a12c0f-c294-650116ac@172.xx.xx.xx
Supported: timer,resource-priority,replaces
User-Agent: Cisco-CUCM11.0
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
Supported: Geolocation
Call-Info: <urn:x-cisco-remotecc:callinfo>; security= Unknown; gci= 2-93188; isVoip
Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=MIXED
Session-ID: d010182a106420aa0ac64d1eab820155;remote=00000000000000000000000000000000
Cisco-Guid: 1981290240-0000065536-0000000102-1694570156
Session-Expires:  28800
Diversion: <sip:+4945131012012@172.xx.xx.xx>
Min-SE:  28800
P-Asserted-Identity: <sip:+4945131012012@172.xx.xx.xx>
Remote-Party-ID: <sip:+494515005413@172.xx.xx.xx>;party=calling;screen=yes;privacy=off
Contact: <sip:+494515005413@172.xx.xx.xx:5061;transport=tls>
Max-Forwards: 53

Content-Length: 345
Content-Type: application/sdp

v=0
o=CiscoSystemsCCM-SIP 820157 1 IN IP4 172.xx.xx.xx
s=SIP Call
c=IN IP4 141.83.xx.xx
b=TIAS:64000
b=AS:64
t=0 0
m=audio 18904 RTP/SAVP 9 8 101
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:msYSRrE36dExBVg5WUH64ADllpsZG7rZ8Te3dwPy
a=ptime:20
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

007699: Jan  4 09:23:43.798: //384436/761817000000/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/TLS 172.xx.xx.xx:5061;branch=z9hG4bKc5f76e5c9ac0
From: <sip:+494515005413@172.xx.xx.xx>;tag=820157~4498ec3c-29e8-4cb2-abe3-b65eefebc6a9-35392719
To: <sip:+4917662059124@141.83.xx.xx>
Date: Mon, 04 Jan 2016 08:23:43 GMT
Call-ID: 76181700-68a12c0f-c294-650116ac@172.xx.xx.xx
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.4.3.M3
Content-Length: 0

And in the Sent INVITE to ITSP the FROM and Contact Header are now filled with +4945131012012 too.

007700: Jan  4 09:23:43.798: //384437/761817000000/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:+4917662059124@141.39.xx.xx:5062 SIP/2.0
Via: SIP/2.0/TLS 141.83.xx.xx:5061;branch=z9hG4bK4798265
From: <sip:+4945131012012@141.83.xx.xx>;tag=883965A0-191
To: <sip:+4917662059124@141.39.xx.xx>
Date: Mon, 04 Jan 2016 08:23:43 GMT
Call-ID: 4D5F9165-B1F311E5-B34EBC22-DAEABB57@141.83.xx.xx
Supported: 100rel,timer,resource-priority,replaces
Min-SE:  28800
Cisco-Guid: 1981290240-0000065536-0000000102-1694570156
User-Agent: Cisco-SIPGateway/IOS-15.4.3.M3
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1451895823
Contact: <sip:+4945131012012@141.83.xx.xx:5061;transport=tls>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 52
P-Asserted-Identity: <sip:+4945131012012@141.83.xx.xx>
Diversion: <sip:+4945131012012@172.xx.xx.xx>
Session-Expires:  28800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 374

v=0
o=CiscoSystemsSIP-GW-UserAgent 4523 1201 IN IP4 141.83.xx.xx
s=SIP Call
c=IN IP4 141.83.xx.xx
t=0 0
m=audio 18912 RTP/SAVP 9 8 101
c=IN IP4 141.83.xx.xx
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:msYSRrE36dExBVg5WUH64ADllpsZG7rZ8Te3dwPy
a=rtpmap:9 G722/8000
a=fmtp:9 bitrate=64
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

a=ptime:20

007701: Jan  4 09:23:43.810: //384437/761817000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/TLS 141.83.xx.xx:5061;branch=z9hG4bK4798265
From: <sip:+4945131012012@141.83.xx.xx>;tag=883965A0-191
To: <sip:+4917662059124@141.39.xx.xx>
Call-ID: 4D5F9165-B1F311E5-B34EBC22-DAEABB57@141.83.xx.xx
CSeq: 101 INVITE
Timestamp: 1451895823
Content-Length: 0


007702: Jan  4 09:23:44.022: //384437/761817000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 513 Message Too Large
Via: SIP/2.0/TLS 141.83.xx.xx:5061;branch=z9hG4bK4798265
From: <sip:+4945131012012@141.83.xx.xx>;tag=883965A0-191
To: <sip:+4917662059124@141.39.xx.xx>;tag=aprqngfrt-u6rjvc20000a6
Call-ID: 4D5F9165-B1F311E5-B34EBC22-DAEABB57@141.83.xx.xx
CSeq: 101 INVITE
Timestamp: 1451895823
Content-Length: 0

How can I avoid the modification?

Thanks a lot.

Labels:
Preview file
2 KB
0 Helpful
6 Replies 6

Venkatesh Perumal
Level 7
Level 7

‎01-05-2016 05:57 PM

Hi,

You need to remove some information from the SIP Invite message originating from : <User-Agent: Cisco-SIPGateway/IOS-15.4.3.M3>.  the MTU size for this invite message must be exceeding 1300 bytes.

You can refer the RFC 3261, section 18.1.1, which contains a requirement to measure the size of an outbound SIP request before sending it out on UDP. If the request size is within 200 bytes of the path MTU, it is sent using TCP instead of UDP. The path MTU value is available in the configuration and defaults to a value of 1500. This default value allows 1300 bytes for outbound UDP messages.

can you create a SIP Profiles to remove the diversion header in question and apply the SIP profile in Dial-peer and test, you can refer below docs for the same.

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube_fund/configuration/xe-3s/cube-fund-xe-3s-book/voi-sip-param-mod.html#task_0DC87B03479A4DD9A81AD2E405CA8EC9

https://supportforums.cisco.com/discussion/12213711/removing-diversion-header-inbound-sip-call-cube

regards,

-Do rate helpful posts.

0 Helpful

Paul Freiberg
Level 1
Level 1
In response to Venkatesh Perumal

‎01-05-2016 11:49 PM

Hi Thanks for the answer, but I think the size is not the probleme, because my ITSP told me that they will remove the size limitation. And the communication is encrypted SIPS/SRTP -> TCP.

My real probleme is the modification of the From and Contact header.

Because now the the party that receives the call, will see the forwarding number instead of the orginating.

0 Helpful

vasank
Cisco Employee
Cisco Employee

‎01-06-2016 09:08 AM

Hi Paul,

debug ccsip all for a test call would help understand the logic of manipulation.

Thanks,

Vasanth

0 Helpful

Paul Freiberg
Level 1
Level 1
In response to vasank

‎02-16-2016 11:56 PM

Hi vasank,

we fixed it with a copy-list on the incoming dial-peer and a peer-header copy and a sip header modify on the outgoing dial-peer:

voice class sip-copylist 2
 sip-header From
 sip-header Contact

voice class sip-profiles 100
 request INVITE peer-header sip From copy "\+(.*)@" u01
 request INVITE peer-header sip Contact copy "\+(.*)@" u02
 request INVITE sip-header From modify "\+(.*)@" "+\u01@"
 request INVITE sip-header Contact modify "\+(.*)@" "+\u02@"

So we could overwrite the modified headers.

But if you like I attached a debug ccsip all which was made after restriction of too large pakets was removed from itsp.

The session timer mismatch was fixed, if you see something besides the modification of the from and contact header, please let me know.

Preview file
570 KB

vasank
Cisco Employee
Cisco Employee
In response to Paul Freiberg

‎02-18-2016 01:42 AM

Hi Paul

Did I miss anything , I still see the same behaviour in the logs.

Incoming Call-ID

Call-ID: 6d5e5b00-69f1efb7-6849-650116ac@172.x.x.x

Outgoing Call-ID

Call-ID: 44A32D58-BEEC11E5-83E2BC22-DAEABB57@142.x.x.x

Outgoing call has From and Contact header same as Diversion/PAI. Looks like it has been sanitized to remove IP octed 3and 4. 

I don't see any modification as such other that what was posted in original thread.

Thanks,

Vasanth

0 Helpful

Paul Freiberg
Level 1
Level 1
In response to vasank

‎02-18-2016 02:15 AM

Hi vasank,

thanks for searching:

At 063046: Jan 20 21:36:07.737 is an INVITE received

with:

INVITE sip:+4917662059124@142.x.x.x                            --- forwared number

From: <sip:+4945097996199@172.x.x.x                           --- calling number

To: <sip:+4917662059124@142.x.x.x                               --- forwarded number

Diversion: <sip:+4945131012012@172.x.x.x                    --- forwarding number

P-Asserted-Identity: <sip:+4945131012012@172.x.x.x     --- forwarding number

Contact: <sip:+4945097996199@172.x.x.x                       --- calling number

If this INVITE is send out the headers were modified to

at 063716: Jan 20 21:36:07.785

INVITE sip:+4917662059124                         --- forwared number

From: <sip:+4945131012012                        --- forwarding number

To: <sip:+4917662059124                            --- forwarded number

Contact: <sip:+4945131012012                    --- forwarding number

P-Asserted-Identity: <sip:+4945131012012  --- forwarding number

Diversion: <sip:+4945131012012                 --- forwarding number

Thats why forwarded party sees forwarding number instead of calling number.

As we fixed it with sip-copylist and sip-profile all was fine, but why the cube modifies the INVITE?

0 Helpful
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Customers Also Viewed These Support Documents