Re: [reSIProcate] Max Size of an INVITE message using UDP
This depends on all of the network elements including routers and
gateways along the path. Many residential gateway/routers will not
pass fragmented UDP packets through. There is no way for the user
agent to know if a downstream element will not support fragmented UDP.
On 8/11/06, Mehul Jain <Mehul@xxxxxxxxxxx> wrote:
Am not clear what is the max supported size of SIP Request (INVITE) sent
using UDP.
Went through the RFC 3261 (18.1.1 Sending Requests ). MTU (1500 Bytes for
Windows) looks to be the limiting factor for UDP, while later its written
that implementations must support messages of the max datagram size (65,535
bytes).
Using the resiprocate stack over UDP, Im able to send and receive messages
longer than 1500 bytes (e.g. length 6K bytes) without any issues.
Any pointers as to what is the accepted max length in the proxies, servers
etc.
Mehul.
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.
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel