cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6433
Views
15
Helpful
17
Replies

SIP Packet Size at Fault?

UrbanPeasant
Level 1
Level 1

I've hit a problem where we are able to get UDP 5060 SIP calls out to the PSTN via a CSR1000v (IOS17.3.3) across a primary ISP connection to one of our ITSP SBC end points, but we are not able to get calls out from a CSR3925 (IOS 15.7.3) across a backup ISP connection to the same ITSP second SIP end point.

WORKING:

The CSR1000v sends an INVITE to the ITSP that is 1290 bytes

The ITSP receives, and sends back their 100 Trying, then 407 Proxy Auth Required messages.

To which the CSR1000v responds with the auth details in an INVITE that is 1512 bytes

The ITSP receives and the call progresses.

 

NOT WORKING:

The ISR3925 sends an INVITE to the same ITSP 2nd end point that is 1400 bytes 

The ITSP receives, and sends back their Trying and Proxy Auth Req messages

To which the ISR3925 responds with the auth details (exactly the same as above) and sends out an INVITE that is 1623 bytes.

The ITSP does not receive the new INVITE, the call cannot progress.

 

The transit network between the CSR and the ITSP is an MPLS network with an MTU limit set at 1500. The is no firewall, no ACL, no SIPALG, just a transit router as the default gateway, a 'pure' Internet connection, if you like.

Is the message size likely the reason that the calls can't go out? 

I've not been able to discover why there is such a packet size difference between the CSR and the ISR. Any ideas?

Calls inbound from the PSTN via the ITSP over the ISR3925 are absolutely fine, probably because the authentication information isn't present in the inbound INVITE, it's only needed outbound, so the packet size is kept down.

I'm a bit stuck for ideas how to get calls outbound working via the ISR, and some thoughts would be appreciated.

 

Thanks

Nathan.

17 Replies 17

Sadav Ansari
VIP Alumni
VIP Alumni

Please share debug ccsip in out for both working and non working call for more investigation.

 

Pls rate if its “Helpful”. If this answered your question please click “Accept as Solution”.

Hi Sadav

debug ccsip in out isn't a command so far as I can tell

I've only come across 'in out' when debugging dialpeer or ccapi, but not for the ccsip debugs

Did you mean ccsip messages?

Nathan

How you confined that the The ITSP does not receive the new INVITE, the call cannot progress ? Did ISP informed ?

 

 



Response Signature


Hi Nithin, I've already engaged with the ITSP and they've told me they see the first INVITE but nothing after that. When I look at my own pcap I can see those authenticated INVITES being sent, but they aren't received.

Is there a possibility of changing the MTU and check. Never comes across such scenario.

 

Can you share  the debug ccsip messages from gateway.

 

 



Response Signature


Here are the debugs.

I obfuscated my numbers a little bit, (don't know if I really needed to, but, the internet...) still perfectly readable though.

Internal phone (Jabber) calls external mobile via the same ITSP.

Working path: CUCM --- vCUBE (CSR1000v) --- ITSP West 87.224.0.66

Failing path: CUCM --- IS-CUBE2 (ISR3925) --- ITSP East 62.133.0.197

 

Despite identical config in the routers for the ITSP the INVITES look different. Can't figure that out. But the first INVITE in each case gets to where it's supposed to get without a problem. It's after that when the problem begins.

Thanks

Nathan.

Scott Leport
Level 7
Level 7

Hi,

 

Is there any possibility of making the outbound calls from the vCUBE go out of the ITSP East service and the ISR go out of the ITSP West service?

Just interested to see if the issue stays with the ISR when it's going out of the working path, or if the issue moves over to the vCUBE when it's going out of the failing path.

 

Hi Scott, I can't do exactly what you suggested, but, in a similar vein, I'm already setting up a second CSR1000v to steal the connection from the ISR and see if the calls connect. I'm really hoping they do connect when I put the CSR in line, at which point I'll open a TAC case w.r.t. the ISR. Should have an update re: the new CSR in the next day or two once I've cleared some more time to progress this investigation.

Did you find out more information regarding this issue? We're experiencing a similar problem in our shop - we're sending multiple Invites to our ITSP and they do not respond until the CUBE sends a 408 Request Timeout back to our caller. It happens intermittently but frequently enough to be a problem. Your post is the first one that I noticed which shows the same behavior and we're curious what's causing it in your case as it could help us troubleshoot too. 

 

Thanks, 

Hi @Jesse3620 

 

You may have a different issue, unless you know that you're sending out packets in excess of 1500 bytes.

 

As a first port of call, check with your ITSP if they're receiving your Invites.

If they're not receiving the Invites, you may want to check that IP routing is in place towards the ITSP and on any equipment you may have upstream of your CUBE and run packet captures on those devices to prove that the call is getting out to the ITSP.

 

Thanks Scott, 

 

I have not confirmed the packet size yet, but we did open a ticket w/ our ITSP to investigate. I believe the IP routing is correct as most outbound calls complete without a hitch. This issue happens randomly and it's akin to chasing a ghost it seems. I just thought this thread was interesting because it showed what we're experiencing and have not seen a similar post. If anything, it has my mind working differently to try and troubleshoot our issue further!

Depending on what options you have enabled on cube the sip message size increases or decreases, applying a sip normalization profile that strips some sip headers can decrease you sip packet size.

 

i.e

voice class sip-profiles 3000

 rule 1 request ANY sip-header User-Agent remove (optional)

 rule 2 response ANY sip-header User-Agent remove (optional)

 rule 3 request ANY sip-header Cisco-Guid remove (optional)

 rule 4 response ANY sip-header Cisco-Guid remove (optional)

 

Since these headers are infomrational only

 

Since the sip messages that compose the sip dialog will be from different size, there might be packets that go above 1500 MTU, but this is just a problem if they dont get fragmented, or any ip equipment along the transmission path does not fragment it or sets the do not fragment bit on. You can check the size of  the packets by capturing the traffic at the ISR3925 level.

 

What is a bit confusing is that you state the circuit is MPLs but then state a pure internet connection, a mpls vpn should be a private tunnel to the ISP, so unsure if are just using the pure internet as an example , however if the transit router is trully is a pure internet with a public ip address, then there is a NAT being done somewhere, so not having ALG/Fixup/STUN etc may cause issues, since the ip information during the media negotiation will not get Natted.

 

UrbanPeasant
Level 1
Level 1

Sorry for the delay in updating this thread, other work problems cropped-up, and getting the new CSR1000v fed with appropriate VLANs too longer than anticipated, with a couple of days of wild goose chases trying to figure out why it wasn't working.

So to @Scott Leport comment about getting call traffic out via vCUBE over SIP East - that is now being done by vCUBE2 and is working fine.

So I now have:

Working path: CUCM --- vCUBE (CSR1000v) --- ITSP West 87.224.0.66

Working path: CUCM --- vCUBE2 (CSR1000v) --- ITSP East 62.133.0.197

 

What's apparent here is that to initiate the call, the vCUBEs put a frame on the 'wire' that is much smaller than that from a physical CUBE.

The ITSP sends back a 407 proxy auth request, to which the vCUBEs respond with a frame that is still under 1500 bytes, and from here onwards we're all good.

 

However, when the ISR3925 is sending out that first INVITE it is already larger than the vCUBE INVITE. And the INVITE with the authentication info is 1623 bytes, which is just too big.

I did another capture off one of the CUBEs that connects to our other ITSP, only this one does not require authentication. It also sends a large INVITE, but that ITSP doesn't mandate the authentication, so the calls just progress.

 

Despite the same configs in a pre-auth sense, it seems the physical devices naturally send bigger frames than the virtual devices

I need to put the IS-CUBE2 device back in line now (reclaiming its original public IP from vCUBE2) to get stuck into working out what to do to make authenticated outbound calls work off a physical device, as that's where our present SIP channel support lies. The vCUBEs are just in test prior to switching over next July.

 

 INVITE Frame (bytes)Authenticated INVITE frame (bytes)
vCUBE (ios 17.3.3)12901512
vCUBE2 (ios17.3.3)12491474
IS-CUBE2 (ios 15.6.3 and 15.7.3)14001623
FA-CUBE2 (ios 15.6.3)1498No auth required. (different ITSP)

Hi Nathan,

 

Good work on this, it's an interesting one for sure. ':-)' Not that it really matters, but is the SIP service with the ISR3925 a brand new service? If not, then presumably it worked with authentication before? If so, then maybe something network side changed? 

 

I am wondering if it's possible to lower the MTU and possibly change the value of the MSS on the transit network? Not sure if this will ultimately sort it, but it might just keep your packet size down before it reaches the UDP leg between ISR and the ITSP, e.g:

 

Site A

int Gi0/0/0

 ip mtu 1400

 ip tcp adjust-mss 1360 

 

Site B

 int Gi0/0/0 

  ip mtu 1400

  ip tcp adjust-mss 1360 

 

 

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: