Re-INVITE UDP fragmentation

Problem
The client sends SIP re-INVITEs over UDP that exceed the standard MTU (e.g. 1529 bytes > 1500 bytes). The re-INVITE is fragmented at the IP layer. On your side, re-INVITEs do not appear in traces; the client receives no response, and the call ends. Initial INVITE is within MTU and works; only the larger re-INVITE is affected.

Root cause
Fragmented UDP packets are dropped by your NAT/firewall (or possibly by the server interface). Only the first fragment or no fragments are delivered, so the proxy (M4) never sees the full re-INVITE and does not respond.

Solution

1. Review network equipment
Check NAT and firewall settings for handling of fragmented UDP packets. Allow or correctly reassemble fragmented UDP so that re-INVITEs reach the M4 server. If you cannot change how fragmented UDP is handled, use the TCP option below.

2. Use TCP for SIP (workaround)
If fragmented UDP cannot be fixed on the network side, use TCP for SIP instead of UDP. TCP may be handled differently by your NAT/firewall.

• On M4: enable TCP for SIP in the Operator Panel (OP): Advanced (or advanced section) → enable TCP for SIP. Verify the exact menu label in the application.
• On the client: configure the SIP stack to send signaling over TCP to M4 (same destination IP/port, TCP instead of UDP).

3. Verify with tests
To confirm that oversized UDP is fragmented and that fragments are dropped on your side, use the following from a client machine and capture on the server.

• From the client (replace xx.xx.xx.xx with the M4/server IP, use a port that nothing listens on, e.g. 1234):
  
  • Non-fragmented (payload 1472 + 28 = 1500 bytes, within MTU): hping3 -p 1234 -c 3 --udp -d 1472 xx.xx.xx.xx
    
  • Fragmented (payload 1473 + 28 = 1501 bytes, over MTU): hping3 -p 1234 -c 3 --udp -d 1473 xx.xx.xx.xx
• Interpretation: if UDP is delivered, the host will respond with ICMP “port unreachable,” and you will see 0% packet loss. If only the 1472-byte test shows 0% loss and the 1473-byte test shows loss, fragmented UDP is being dropped.
• On the server, to see what actually arrives (replace yy.yy.yy.yy with the client IP): tcpdump -i any -nn 'host yy.yy.yy.yy and not tcp'. The not tcp filter prevents your SSH session from being captured. Compare what you see when sending 1472 vs 1473 bytes from the client.

Example where red is oversized packets and green are good UDP packets:

Related
If the initial INVITE is also too large (e.g., many codecs in SDP), reducing the SDP size (e.g., only needed codecs) can keep packets under MTU; see MOR does not send Contact header. For NAT and port forwarding in general, see M4 under NAT.

See also

• MOR does not send Contact header