[SR-Users] packets exceeding MTU size

Greg Troxel gdt at lexort.com
Thu Aug 18 13:15:19 CEST 2022


Alex Balashov <abalashov at evaristesys.com> writes:

> Hi Ali,
>
> Kamailio reassembles fragmented UDP just fine. 

Do you really mean that, or "operating systems reassemble fragmented UDP
packets and hand the full packet to Kamailio"?

> However, additional UDP fragments beyond the first packet don’t always
> get to Kamailio, since they don’t have a UDP header. UDP fragments can
> be dropped by stateful firewalls and/or NAT gateways for this reason.

Yes, correctly-behaving firewalls that want to block by port need to
reassemble.

> 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.



Or does Kamailio do some sort of raw socket listening and actually do
fragment reassembly in user space?  That would be very surprising to me.
-------------- 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/14cf8cc5/attachment.sig>


More information about the sr-users mailing list