SIP Packet Size at Fault?

[UrbanPeasant]

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.

[TONY SMITH]

Are you using TCP or UDP talking to the ITSP?   If UDP then that oversized packet should be fragmented, and that's perfectly normal.  I have a few installs where it works this way.  You should see the fragmentation in your Wireshark capture.

[UrbanPeasant]

Hi @TONY SMITH ,
We use UDP to the ITSP. I've now got the ISR3925 back in service (for inbound calls), and have dropped the second vCUBE that I created to test with. But I've not go much further than that because of other work going on presently. So my query isn't 'cold,' I'm just tied-up elsewhere. I didn't notice any fragmentation, but wasn't looking either, as I don't know what fragmentation looks like. All I do recall is that the vCUBE sends an initial frame that is much smaller than that of the ISR. I'll take another look with fragmentation in mind now though.

Cheers

Nathan.

[TONY SMITH]

Here's a snippet from Wireshark showing an INVITE sent as fragmented UDP.  I strictly it's the IP that's fragmented.  But either way it was sent in two packets, the first 1514 bytes and the second 68.  Reassembled they form the original UDP message containing the INVITE.  Note that if you set "sip" as a display filter, it only shows the final packet not the prior fragment(s).  That trace was from a working call.  Due to the particular header requirements, all authenticated INVITES to this ITSP go out fragmented.

If you're having problems with oversized packets then maybe either something isn't fragmenting them properly, or your gateway Ethernet interface is set to jumbo frames or something.