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 <http://www.faqs.org/rfcs/rfc2914.html> [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.
Doesn't the second part of the paragraph contradict the first part? Why should the receiving side's implementation accept the large packet if the sender is not supposed to send it? [Chris Boulton] Not really - guidelines are provided for requests that are approaching the MTU BUT to be robust you should be able accept more than 1500. The third party SBC doesn't send any response for the message other than 100 Trying. Should it accept my INVITE? [Chris Boulton] At the very least it should complete the INVITE transaction. what response should it send in this case? [Chris Boulton] It should really accept the request and process. One last thing - the third party SBC doesn't support TCP. Is there any other "correct" way to send the INVITE? is TCP support mandatory in RFC 3261? [Chris Boulton] Yes it is mandatory. Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Ubiquity Software Corporation plc, a company registered under the laws of England and Wales, Registration 2719723, registered offices at Eastern Business Park, Building 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United Kingdom. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
