09-19-2013 06:29 AM - edited 03-16-2019 07:27 PM
How does CUSP decide when to use TCP vs UDP when forwarding INVITES to CUCM when both UDP and TCP are configured on the Network Listen Ports? We have two different calls flows coming from our SBC to CUSP. Both INVITES have UDP as the transport. CUSP forwards one call flow to CUCM with TCP as the transport and the other as UDP. Is there something unique to the first INVITE below that would signal CUSP to use TCP?
Invite from SBC that CUSP adds TCP as the transport in the VIA header towards CUCM
40:13.979 On [2:245]10.XXX.XXX.XXX:5060 sent to 10.240.XXX.X:5060
INVITE sip:XXXXXXXXXX@cusplab:5060 SIP/2.0
Via: SIP/2.0/UDP 10.XXX.XXX.XXX:5060;branch=z9hG4bKm2u8f32038e12is8p3v1.1
From: "Test User 1" <sip:5045824230@12.194.11.53:5060>;tag=SDi82if02-13984769016573306_c2b04.1.2.1378274120440.0_1121221_2220804
To: <sip:+1XXXXXXXXXX@32.252.49.186>
Call-ID: SDi82if02-2664bc8b12611edfd30a0552529e0b90-cggngq0
CSeq: 2 INVITE
Session-Expires: 1800
Min-SE: 1800
Allow-Events: telephone-event
Cisco-Guid: 3327242752-0000065536-0000181788-1640976394
Acme-Call-ID: 9AA7C362-1BBC11E3-81019B0F-C8BF5371
Timestamp: 1379084661
Expires: 180
Supported: timer,replaces,sdp-anat
P-Asserted-Identity: "Test User 1" <sip:5045824230@12.194.11.53>
Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK
User-Agent: Cisco-SIPGateway/IOS-12.x
Max-Forwards: 59
Contact: <sip:10.XXX.XXX.XXX:5060;transport=udp>
Content-Length: 325
Content-Disposition: session; handling=required
Content-Type: application/sdp
v=0
o=CiscoSystemsSIP-GW-UserAgent 2487 3295 IN IP4 10.XXX.XXX.XXX
s=SIP Call
c=IN IP4 10.XXX.XXX.XXX
t=0 0
m=audio 55178 RTP/AVP 18 100 101
c=IN IP4 10.XXX.XXX.XXX
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
INVITE from SBC that CUSP adds UDP as the transport in the VIA header
15:14.881 On [2:245]10.XXX.XXX.XXX:5060 sent to 10.240.XXX.X:5060
INVITE sip:XXXXXXXXXX@cusplab:5060 SIP/2.0
Via: SIP/2.0/UDP 10.XXX.XXX.XXX:5060;branch=z9hG4bKg04f5a105040ei4764o1.1
From: "Test User 2" <sip:XXXXXXXXXX@12.194.137.181:5060>;tag=SDdeh1202-125657148404519E-4_c2b09.2.1.1376631876821.0_2507555_4963634
To: <sip:XXXXXXXXX@32.252.49.186>
Call-ID: SDdeh1202-c8199578035cb96793dbe0fb6ef98d84-cggjoq2
CSeq: 2 INVITE
P-Asserted-Identity: "WIRELESS CALLER" <sip:XXXXXXXXXX@12.194.137.181:5060>
Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed
Max-Forwards: 64
Contact: <sip:10.XXX.XXX.XXX:5060;transport=udp>
Content-Length: 266
Content-Disposition: session; handling=required
Content-Type: application/sdp
v=0
o=Sonus_UAC 12183 15514 IN IP4 10.XXX.XXX.XXX
s=SIP Media Capabilities
c=IN IP4 10.XXX.XXX.XXX
t=0 0
m=audio 55134 RTP/AVP 18 0 100
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=sendrecv
a=maxptime:30
02-19-2015 12:54 AM
Hi. Did you ever find out the reason and a solution to this problem. I am having the same issue where CUSP decides to change the transport type to TCP (from UDP) when talking to CUCM on certain invites from Acme SBC. On some invites from the same Acme SBC, CUSP doesn't change the transport type and leaves it as UDP.
Thank you.
04-07-2015 06:34 AM
We never did find out the root cause. In the ACME SBC, we created two SIP-Ports on the SIP Interface. One for UDP and the other for TCP. This allowed the call flow to succeed. Were you able to find a solution.
Bill
07-17-2015 07:11 AM
It is working as designed. Check also your path MTU (Unknown vs 1500) As per the RFCs you need to have the packet within 200 bytes so it does not get changed. Unknown path automatically switches to TCP if the initial INVITE coming from the SBC is 1300bytes or higher CUSP will switch over to TCP as per RFCs 3261 section 18 and 2914[43]
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