[SR-Users] packets exceeding MTU size

[Greg Troxel]

Alex Balashov <abalashov at evaristesys.com> writes:

>>> This should not prevent the INVITE from being parsed; typically in
>>> real-world scenarios with a 1500 byte MTU, the first fragment captures
>>> all SIP headers, and fragmentation slices up the SDP
>>> payload. Fragmentation won’t adulterate the Request Line (first line),
>>> which contains the “INVITE” method verb. I suppose it is conceivable
>>> that a fragmentation boundary could occur in the middle of a SIP
>>> header and/or header value, causing the entire message to be
>>> discarded.
>> 
>> I would expect that if there  is say a 1500-byte fragment and a 700-byte
>> fragment (to make things up) and a firewall drops the 700-byte one, then
>> reassembly at the OS would fail and Kamailio would never see anything.
>
> In principle, that’s right. Practically, this depends on the behaviour
> of various intermediaries. I have seen both behaviours. In the
> scenarios I have troubleshot, receiving only the first fragment on the
> other side of—for example—a NAT gateway is fairly common.

It is not surprising that a broken firewall or NAT causes only the first
fragment to show up at an OS.  It might even be more likely than not
that a given firewall is broken :-(

It would surprise me if an OS delivered a UDP packet that contained the
bytes in the first fragment only, and if so that's an OS bug.  So I
would expect 99.9% the symptom to be that the packets don't arrive.

(All of this is another reason to do TCP signalling, which is able to
negotiate MTU and not end up with IP fragmentation, but I get it that
people have to interoperate with what the peer will do.)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20220818/b1d12dde/attachment.sig>