[SIPForum-discussion] Treating packages larger then 1500bytes

[Giscard Fernandes Faria]

Hi all,

 

The RFC is very clear when defining how to send packages over the
network.

 

==================================

The description below (from RFC):

 

If a request is within 200 bytes of the path MTU, or if it is larger

   than 1300 bytes and the path MTU is unknown, the request MUST be sent

   using an RFC 2914 [43] congestion controlled transport protocol, such

   as TCP. If this causes a change in the transport protocol from the

   one indicated in the top Via, the value in the top Via MUST be

   changed.  This prevents fragmentation of messages over UDP and

   provides congestion control for larger messages.  However,

   implementations MUST be able to handle messages up to the maximum

   datagram packet size.  For UDP, this size is 65,535 bytes, including

   IP and UDP headers.

 

      The 200 byte "buffer" between the message size and the MTU

      accommodates the fact that the response in SIP can be larger than

      the request.  This happens due to the addition of Record-Route

      header field values to the responses to INVITE, for example.  With

      the extra buffer, the response can be about 170 bytes larger than

      the request, and still not be fragmented on IPv4 (about 30 bytes

      is consumed by IP/UDP, assuming no IPSec).  1300 is chosen when

      path MTU is not known, based on the assumption of a 1500 byte

      Ethernet MTU.

===================================

 

What I am concerned is: There are implementations that only support UDP,
and such implementation may send fragmented SIP messages over more than
one (generally two) UDP datagram.

So my question is: how your guys are handling such issue?

 

I mean, ino ne hand we could just answer a 413 saying that the message
is too big (more than it is supposed to be for a UDP). In the other hand
we could try to reassemble the datragrams, and treat then properly and
if the datagrams are out of order answer with a 400 bad request.

 

Any further comment is appreciated...

 

Regards

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20080807/89e199a5/attachment-0002.html>