SIP Over UDP, TCP, or TLS: The 1300-Byte Rule and What Fragmentation Actually Costs You

Most operators inherit UDP as the SIP transport because that is what the registrar was set to years ago and nobody touched it. Then one day a new codec gets added to the offer, or an SBC starts inserting a longer History-Info, and INVITEs to one peer start vanishing - not with a 408, not with a 503, but with no response at all. The originator retransmits, the destination never sees the retransmissions, and the call clears with a cause code that tells you nothing.

This is fragmentation, and it is the single most common production failure caused by transport choice. RFC 3261 §18.1.1 wrote the rule in 2002 - if a request is within 200 bytes of the path MTU, or larger than 1300 bytes if the MTU is unknown, the element MUST send the request over a congestion-controlled transport like TCP - and half the deployed estate still ignores it. This post is about why the rule exists, how to spot a fragmentation failure in a trace, and what to do about it.

Why 1300 bytes is the line

The number is not arbitrary. The most common Layer-2 MTU on the public internet is 1500 bytes (Ethernet), leaving 1480 bytes after a 20-byte IPv4 header. RFC 3261 reserves a 200-byte margin for the headers downstream proxies will add - extra Via, extra Record-Route, an inserted P-Asserted-Identity - so the working budget on the wire is 1300 bytes for the message the originator emits.

Then the real network gets involved. Every tunnel shrinks the path MTU further: IPsec ESP adds 50-80 bytes depending on cipher; GRE adds 24; MPLS 4 bytes per label with 2-4 labels typical in a core; 802.1Q 4 bytes; PPPoE 8; WireGuard 32. Stack two or three of these and the effective MTU drops below 1400 bytes, and a SIP message that fit comfortably leaving the UA gets fragmented at a hop nobody bothered to draw.

The 1300-byte rule is conservative on purpose. A long codec list with ICE candidates for both address families, DTLS-SRTP a=fingerprint lines, and a few a=rtcp-fb entries can blow past 1300 bytes in SDP alone, before the SIP headers are even counted.

What actually fails, and how it shows up in a trace

When a UDP datagram exceeds the path MTU, IPv4 fragments it at the offending hop (assuming DF is not set; many SIP stacks do not set it). IPv6 does not fragment at all - it generates ICMPv6 Packet Too Big back to the source. The fragmented IPv4 path is what fails in production, because three things go wrong on the way:

1. Stateful firewalls and NATs often drop non-first fragments. The first fragment carries the UDP header with destination port 5060; the rest do not. A rule that says "allow UDP/5060" matches the first fragment and discards the others. The destination either parses a truncated INVITE or sits waiting for the rest until its reassembly timer expires.

2. Some SBCs drop fragmented SIP regardless of source. Several major SBC families have an explicit "drop fragmented UDP at the SIP listener" knob that defaults to enabled in security-hardened profiles.

3. PMTUD black holes are the rule, not the exception. When DF is set and a downstream hop cannot forward the packet, it is supposed to emit ICMP Fragmentation Needed (Type 3, Code 4). Many firewalls filter all ICMP, so the source never learns the MTU dropped. Retransmissions keep going out at the same size and keep getting black-holed.

The fingerprint in a paired capture is distinctive. The originator capture shows the INVITE leaving as two IP fragments - frame N with flags=MF and offset 0, frame N+1 with flags=0 and offset 1480. The destination capture shows only frame N. Wireshark's reassembly machinery will helpfully say "Reassembled IPv4 in frame: (none)" - a polite way of telling you the rest is gone.

Common things that push SIP messages past 1300 bytes: large SDP offers (a WebRTC offer can be 3000+ bytes in SDP alone); stacked Record-Route from multi-hop proxies; SIP-T / SIP-I bodies (RFC 3204 / RFC 3372 - 100-400 bytes of application/ISUP inside a multipart/mixed body); History-Info chains; long Authorization credentials under layered challenge-response; and Identity headers carrying signed PASSporT JWTs for STIR/SHAKEN, which alone can add 800-1200 bytes per call.

STIR/SHAKEN is the one quietly killing UDP: carrier-mandated attestation pushes every originating INVITE through the 1300-byte threshold, and most operators do not realise until they migrate to TCP and the silent-failure rate drops by an order of magnitude.

How to move to TCP or TLS without breaking things

The fix is transport=tcp or transport=tls - straightforward in principle, full of edge cases in practice. Three points to keep in mind:

Connection reuse (RFC 5923) is what makes TCP for SIP scalable. Without it, every dialog would tear down and re-establish a TCP connection. With it, the registrar (or SBC) keeps the connection from REGISTER alive and re-uses it for inbound INVITEs. The alias parameter in the Via - Via: SIP/2.0/TCP 198.51.100.10:5060;alias;branch=z9hG4bK-... - tells the next hop "re-use this connection if you need to send me a request." SBCs in 2026 should support it; if yours does not, schedule the firmware upgrade.

Double-Record-Route is mandatory for split-transport deployments. If the originating side is UDP and the terminating side is TCP, the in-between B2BUA has to insert two Record-Route headers - one per transport - so mid-dialog requests (re-INVITE, BYE) go out the way they came in. A single Record-Route will route the BYE to the wrong transport and the call hangs until session-timer expiry (covered in the top-10 failure modes post from 2026-05-04).

TLS does not solve fragmentation by itself; it requires TCP underneath. A common misconfiguration is "UDP everywhere except where security matters, then TLS." If the path-MTU problem hits before the operator has any TLS need, the answer is plain TCP. Once TCP is the transport, layering TLS on top is a per-peer policy decision.

What to look for in a paired capture

A short diagnostic checklist when you suspect fragmentation:

• On the originator capture, filter ip.flags.mf == 1 or ip.frag_offset > 0 and confirm whether the INVITE is being fragmented at the originator.
• Run the same filter on every downstream hop's capture. The hop where the second fragment disappears is the offending node.
• Compare the IPv4 Total Length of the first fragment against the next-hop egress MTU. If the datagram is larger than that MTU and DF is set, you should see ICMP Type 3 Code 4 going back upstream - if you do not, ICMP is filtered and PMTUD is broken.
• Run ping -M do -s 1472 <peer> (Linux) or ping -f -l 1472 <peer> (Windows) along the path. Decrement by 28 bytes (8 UDP + 20 IPv4) until you get a reply; that is the path MTU.
• Check whether the SBC or registrar is announcing Allow: UDP, TCP, TLS in its OPTIONS response. If not, downstream peers will not know a transport switch is even an option.

The general rule: if you see INVITE retransmissions at the originator with no response, and the INVITE is larger than 1300 bytes, you have a fragmentation problem until proven otherwise. Switching that peer to TCP will either fix it immediately or expose the next problem in the chain (usually a firewall rule that allows UDP/5060 but not TCP/5060).

Closing the loop

Transport choice on SIP is the kind of decision that seems like it can be deferred indefinitely - right up until it cannot. Operator after operator discovers the 1300-byte rule the same way: a feature gets enabled, message sizes creep up, and one Monday a peer's call-completion rate quietly drops by 2%. Engineers who understand the rule, the fingerprint, and the migration pattern fix it in an afternoon. Engineers who do not spend a week chasing ghosts in the dial-plan.

SIP Train's SIPT-101 - SIP Fundamentals for Working Engineers covers transport selection, the 1300-byte rule, RFC 5923 connection reuse, and the paired-capture diagnostic workflow, with annotated PCAPs from real fragmentation incidents. If your team is staring down STIR/SHAKEN or any other change about to push message sizes up, that is the course to put on the calendar.