247 - Allow modification of MTU on voice interfaces of ASBCE
Sam Osheroff
It's unlikely that jumbo frames are enabled on the SBC unless somebody has done some undocumented modifications on the SBC. Typically when the SIP message exceeds the size of the UDP frame, the NIC drivers will break the UDP payload into multiple frames. This is definitely an issue for SIP as UDP doesn't have a built-in packet re-assembly method and frames could arrive out-of-order or get dropped. Some SIP stacks do a reasonable job of reassembling the frames but some refuse. It's a good reason why all carriers/peer should support TCP, but I digress.
As you hinted, you can reduce the size of the SIP messages. You don't need SIGMA scripts to do it. In the Session Manager adaptation, for example, you can use the parameter "reduceRtHdrs=true". This removes some of the SM internal hops from the record-route and via list. In the SBC, under Signaling Rules (for the ITSP/peer in question) / Request Headers tab, you can setup a list of headers to remove. You can definitely remove Avaya proprietary headers. I'd look at INVITES in traceSM or traceSBC to get an idea of which ones. We remove, for example, "P-Location", "Endpoint-View", "P-Charging-Vector". Lastly, make sure in the Server Interworking for the ITSP/peer, under Advanced, the Record Route is set to "Both". This causes the SBC to completely obscure inside pathway from outside pathway in the Record Route list. The inside pathway is typical long (Session Manager(s), CM, etc.). The outside pathway (record routes sent to the ITSP) just need the SBC's IP in the list so having the SBC re-write the record route list really drops the size.
Julie Blackwell
Sam Osheroff: Hi Sam, and thank you for your response. I agree with everything you stated, and use several of those methods to reduce outbound SIP traffic in all implementation projects.
However, the problem we are experiencing is related to calls that ingress into the customer network from the external SIP provider. (The SIP provider has no problem with passing UDP jumbo frames.)
Those INVITEs (where the MTU is over 1500) are being dropped by the Avaya SBCE interface and therefore we do not get a chance on our end to make any modifications to the SIP or SDP headers.
In this case, the provider generally only supports UDP as well. They have stated they do support TLS, in theory (which does use TCP transport), but their Tier 3 SME stated they had never seen it implemented.
Thanks!
Sam Osheroff
Julie Blackwell: For the ITSP send you a jumbo frame, your switches and routers would need to support that. If they're delivering your service over the internet, there's pretty much no way they could send you a jumbo frame because the internet, as a rule, doesn't support jumbo frames.
Do you have a IPS/IDS? We had one in the past (can't remember the brand) that when it was configured to support jumbo frames itself, it would happily re-assemble UDP fragmented packets back into a jumbo frame. That was pretty annoying, since things downstream stream did not necessarily support jumbo frames (actually, nothing in our voice infrastructure does). So if your ITSP delivers service over the internet, check with your network folks if there's an IPS/IDS device that could be merging UDP fragments into a jumbo frame.
Sam Osheroff
Another possibility - The SBC will attempt to reassemble UDP fragments and possibly what you're seeing is that the SIP message is so large, the SBC is hitting an upper limit on how many UDP fragments it will reassemble.
So the solution is the ITSP either needs to strip out the extra headers on their side (inside their SBC) or they need to support TCP or TLS.