SIP Fragmentation on UDP

What is SIP Fragmentation?

Every link on the internet has a Maximum Transfer Unit (MTU) size which determines the maximum size of a packet that can traverse the link, in bytes on Layer 2. For Ethernet, this is usually1500 bytes. One packet of data can be transmitted across a standard Ethernet network that is smaller or equal to 1500 bytes.

What if I need to send more data? Internet Protocol has a fragmentation standard that everyone has to follow so that the messages will fit inside the MTU.

For example, with an MTU of 1500 bytes, a single 2500 byte SIP message can fit in two frames, or IP datagrams: one fragment may have 1500 bytes, and the remaining 1000 bytes (plus some bytes for headers) will be in the second fragment.

The small fragments will be travel as separate IP datagram packets after being fragmented from the large message. These messages can be lost. Since IP will have no way to detect nor recover the packet, these messages will simply discard all the other fragments which managed to reach the receiver as well. This is how UDP works.

TCP does not use IP fragmentation, but rather, segmentation, in which the missing segment will be re-transmit if it is lost.

SIP protocol utilizes UDP, and that is why SIP will often face challenges for fragmentation.

Let us look at one example here –

We can see that this is a pretty standard SIP INVITE message from extension 1020 to 1002. But why do we get an error of 401 Unauthorized?

If we quickly expand the Message Header for this SIP INVITE, you will be seeing tons of headers. Having tons of headers is not good in SIP, especially when it MIGHT cause fragmentation.

Well, just by looking at the headers under message headers, there is too much data, and after looking at the length of this message (1373 bytes), we can deduct that this is an issue with fragmentation.

According to Section18.1.1 in RFC3261 –

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 [43] 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.

      The 200 byte "buffer" between the message size and the MTU
      accommodates the fact that the response in SIP can be larger than
      the request.  This happens due to the addition of Record-Route
      header field values to the responses to INVITE, for example.  With
      the extra buffer, the response can be about 170 bytes larger than
      the request, and still not be fragmented on IPv4 (about 30 bytes



Rosenberg, et. al.          Standards Track                   [Page 142]

 
RFC 3261            SIP: Session Initiation Protocol           June 2002


      is consumed by IP/UDP, assuming no IPSec).  1300 is chosen when
      path MTU is not known, based on the assumption of a 1500 byte
      Ethernet MTU.

In short, the maximum length for SIP UDP messages should be a maximum of 1300 bytes; otherwise, it has to be sent in TCP. In real life, most endpoints do support TCP, but practically, many don’t, or don’t have it enabled, or it isn’t reachable. So TCP is not a viable option here.

What can we do here?

We can simply disable all the custom SIP headers from the client to reduce the length of the message so that it can be lower than 1300 bytes and does not undergo any fragmentation and everything will be good after!