> On Aug 18, 2022, at 7:33 AM, Greg Troxel wrote:
>
>
> Alex Balashov writes:
>
>> 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
Alex Balashov 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
Alex Balashov 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
Hi Ali,
Kamailio reassembles fragmented UDP just fine.
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.
This should not prevent
Hello,
first: 5.2.5 is really old by now and not maintained, it is not easy
anymore to get proper answers for questions related to it. You should
upgrade to a recent release.
Kamailio has nothing to do with defragmentation of incoming UDP packets,
it is the kernel/ip stack doing it. If it is
Hello all,
Lately I faced an issue that Kamailio is not responding to some invite packets
coming from SBC. When investigating I found that these packets exceeds MTU size.
Could this be the issue? Knowing that in Kamailio configuration I have a
condition on is_method("INVITE"). Could be that in
