Anecdotally, the problem seems to be getting more common, as SIP becomes more complex, offering more extensions and capabilities that are represented in some way in the messaging, and more voice codecs are on offer, such as Opus and G.722. Meanwhile, the capacity of many SIP user agents to reassemble fragmented UDP does not seem to have increased much over the last few years. Even where a SIP user agent can handle UDP reassembly, UDP fragments are dropped by braindead routers and NAT gateways. Setting the Don’t Fragment (DF) IP header bit doesn’t help. It’s safe to say that fragmented UDP messages can’t be handled reliably out there in the world.
Kamailio itself handles fragmented incoming UDP messages just fine, but that doesn’t mean we can pass the full message to the destination, where it will be fragmented again and, most likely, disappear into the ether. As you might surmise, it poses a unique challenge for us since Kamailio is at the heart of CSRP’s call processing core, not a Back-to-Back User Agent (B2BUA), as might be the case in a more traditional SBC or softswitch. An inline B2BUA that endogenously originates a new logical B-leg can easily overcome this problem by accepting a wealth of SIP message bloat on the A-leg liberally while emitting headers conservatively on the B-leg.
SIP proxies such as Kamailio participate within one logical call leg, and are for the most part are bound by standards to pass along SIP messaging as received, without adulteration. This poses problems for interoperability, in the sense of “garbage in, garbage out”. Customers choose our platform for its lightweight design and high throughput characteristics, and that’s the trade-off they make.
Nevertheless, the question comes up often enough: can we use Kamailio to remove any SIP headers from obese INVITE messages to tuck them back under the fragmentation threshold of ~1480 bytes implied by the ubiquitous Maximum Transmission Unit (MTU) of 1500 bytes? If so, which ones are safe to remove? What are the implications of doing so?
First, RFC 3261 scripture is quite clear on the true solution to this problem:
If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914  congestion controlled transport protocol, such as TCP. If this causes a change in the transport protocol from the one indicated in the top Via, the value in the top Via MUST be changed. This prevents fragmentation of messages over UDP and provides congestion control for larger messages. However, implementations MUST be able to handle messages up to the maximum datagram packet size. For UDP, this size is 65,535 bytes, including IP and UDP headers.
In other words, if your UDP message is > 1300 bytes or within 200 bytes of the MTU, send it over a TCP channel.
RFC 3261 mandates that all compliant endpoints support TCP, but practically, many don’t, or don’t have it enabled, or it isn’t reachable. While SIP-TCP support is becoming more commonplace and viable for a variety of reasons, driven by improvements in hardware, memory and bandwidth as well as phenomena like WebRTC, it’s neither ubiquitous nor ubiquitously enabled. Then there are intervening factors like NAT. Consequently, it doesn’t represent a viable solution for most operators.
Having ruled out TCP, attention usually turns to SIP headers which are perceived to be nonessential, such as the commonplace:
Date: 17 Dec 2015 12:20:17 GMT Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, REFER, UPDATE User-Agent: SIPpety SIP BigSIP Rev v0.12 r2015092pl14
As well as generous SDP offers:
a=rtpmap:0 PCMU/8000 a=rtpmap:9 G722/16000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000
“Can we just strip some of this stuff out?”
As it turns out, the answer depends on whether you are pure of heart. Will you give into sinful temptation, or are you one of the faithful few who walks with God?
Formally speaking, proxies are not supposed to modify anything in flight. Section 16.6 (“Request Forwarding”) of RFC 3261 says:
The proxy starts with a copy of the received request. The copy MUST initially contain all of the header fields from the received request. Fields not detailed in the processing described below MUST NOT be removed. The copy SHOULD maintain the ordering of the header fields as in the received request. The proxy MUST NOT reorder field values with a common field name (See Section 7.3.1). The proxy MUST NOT add to, modify, or remove the message body.
So, no, you’re not supposed to tinker with the message headers in any way.
For those susceptible to Sirens’ songs, Kamailio has quite a few technical capabilities that go above and beyond what a proxy is formally allowed to do. However, I would urge strong caution. The dominant rule here should be: “Just because you can, doesn’t mean you should.” This is not generally heeded by sales-minded managers and executives. But you, as the hapless engineer, have to deal with the technical fallout.
Do keep in mind that all of these SIP headers (notwithstanding obvious unfiltered custom headers beginning with X-) are standardised, and they serve some purpose. However, some purposes are more important than others, and in Plain Old Call setup, not all purposes served by headers are necessarily important. Some message tampering by proxies is relatively inconsequential, in that removing some headers seems to have no material impact on the planet or on the UAC or UAS.
Still, I advise against a cavalier or presumptuous attitude. Axing data from SIP requests and replies that the proxy has a duty to pass through unmodified should be a last resort option, after you have exhausted all possible configuration changes to the UA(s) which could lead to a reduction in message size. This includes:
- Disable unused or unnecessary codecs so they are not offered in the SDP stanza.
- Enable compact headers, where possible.
- Switch to TCP.
- Increase MTU if signalling is taking place in a controlled LAN environment where you control the path MTU entirely.
But if you must travel down the dark road:
Most header fields should not be removed. Many “MUST NOT” (in the IETF RFC sense of the term) be removed. That said, here are the ones that can be removed relatively safely, in this author’s opinion:
- User-Agent / Server – This is a strictly informational field, and nobody is the wiser if it falls in the forest.
- Codecs in encapsulated SDP body – As long as the two endpoints can still agree on a common codec, what the far end doesn’t know can’t hurt it, and pruning codecs can result in substantial payload economies. Be very sure that all endpoints are going to have at least one codec they can agree on, and that the resulting agreement would yield desirable results in all scenarios.
- Allow – I have not seen any adverse impacts from removing this header in “POTS” INVITE call flows, whose value enumerates every SIP method supported by the endpoint. RFC 3261 itself suggests it can be read as somewhat redundant in non-OPTIONS flows. From Section 20.5:
The Allow header field lists the set of methods supported by the UA generating the message. All methods, including ACK and CANCEL, understood by the UA MUST be included in the list of methods in the Allow header field, when present. The absence of an Allow header field MUST NOT be interpreted to mean that the UA sending the message supports no methods. Rather, it implies that the UA is not providing any information on what methods it supports. Supplying an Allow header field in responses to methods other than OPTIONS reduces the number of messages needed.
- Date – Honestly, nobody cares what time the UA thinks it is. Axe it.
- Timestamp – Same as #4, unless you have an environment which actually uses it for round-trip estimates.
I would be very wary of removing Supported, as you simply cannot be certain that something Supported by one side is not Required by another. I would likewise avoid tinkering with Session-Timer-related headers (RFC 4028) for the same reason.
Under no circumstances should other well-known headers be touched.
This is a bandage that will buy some time, and does not address the fundamental issue. Best-practical solutions to this problem remain:
- Reduce message size through configuration options on the UAs.
- Use of a reliable transport layer that handles reassembly (aka TCP).
- Inline B2BUA (yes, CSRP begrudgingly provides this as an option).