Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

CUSP changing transport to TCP from UDP in VIA headers

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

3 REPLIES
New Member

Hi. Did you ever find out the

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.

New Member

We never did find out the

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

New Member

It is working as designed. If

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]

374
Views
0
Helpful
3
Replies