Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06741 for ; Tue, 25 Jan 2005 02:52:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtLls-0005Ki-J2 for sip-web-archive@ietf.org; Tue, 25 Jan 2005 03:09:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtLSs-0001TL-BP; Tue, 25 Jan 2005 02:50:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtLQE-0000xk-9I for sip@megatron.ietf.org; Tue, 25 Jan 2005 02:47:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06466 for ; Tue, 25 Jan 2005 02:47:32 -0500 (EST) Received: from csmail.cs.ccu.edu.tw ([140.123.101.188] helo=mail.cs.ccu.edu.tw) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtLgs-00059U-1W for sip@ietf.org; Tue, 25 Jan 2005 03:04:47 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ccu.edu.tw (Postfix) with ESMTP id 6C8045DD48 for ; Tue, 25 Jan 2005 15:47:20 +0800 (CST) Received: from mail.cs.ccu.edu.tw ([127.0.0.1]) by localhost (mail.cs.ccu.edu.tw [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44700-11 for ; Tue, 25 Jan 2005 15:47:19 +0800 (CST) Received: from 11092010202 (csie0.cs.ccu.edu.tw [140.123.101.220]) by mail.cs.ccu.edu.tw (Postfix) with ESMTP id 6332E5DD47 for ; Tue, 25 Jan 2005 15:47:19 +0800 (CST) From: "Tai-Hsing Yu" To: Date: Tue, 25 Jan 2005 15:47:12 +0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 thread-index: AcUCshROK8itc5kwSlK99H7jgUIGMQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-Id: <20050125074719.6332E5DD47@mail.cs.ccu.edu.tw> X-Virus-Scanned: by amavisd-new at cs.ccu.edu.tw X-Spam-Score: 0.7 (/) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 Subject: [Sip] Questions about request message larger than 1300 bytes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fhubert@ms37.hinet.net List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1616295453==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: f460acdc4aacf7fc5e6f9bd32f8fd8c6 This is a multi-part message in MIME format. --===============1616295453== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01C502F5.23EFAC40" This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C502F5.23EFAC40 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hello, I have some questions about handling SIP msgs that are larger = than 1300 bytes. RFC 3261, chapter 18 as listed, mentions that if request message is larger than 1300 bytes, it MUST be sent using TCP = because of the meesage size constraints. But I don=A1=A6t know how to handle the following scenarios, could anyone help me?=20 1. The UA1 registers to Proxy/Registrar with =A1=A7transport=3Dudp=A1=A8 = or without =A1=A7transport=A1=A8 parameter. According to RFC3261, the = proxy should try to send the request message to UA1 using default transport, = which means UDP. Now suppose that a request comes and is larger than 1500, what should the proxy do? Still try UDP first or = always use TCP to send the request to UA1? If the proxy selects the first stretagy, and, unfortunately, the message is splitted into = more than one pieces and only the first one is received by UA1. The received message is incorrect and might cause UA1 to do incorrect = response. Can the proxy select the second stretagy, i.e, using TCP, even the client only registers with =A1=A7transport=3Dudp=A1=A8? = Which stretagy is correct or better? =20 2. The UA2 sends the request to proxy using UDP with request message = size smaller than 1300 bytes. The Via header in the request is UDP. But the response backs to the proxy is larger than 1500 bytes. What = should the proxy do? Using TCP or UDP to transmit the response to UA2? =20 Any acknowledgement will be deeply appreciated. Sincerely, Fish =20 =A1=A7If 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. If an element sends a request over TCP because of these message size = constraints, and that request would have otherwise been sent over UDP, if the attempt to establish the connection generates either an = ICMP Protocol Not Supported, or results in a TCP reset, the element SHOULD retry the request, using UDP. This is only to provide = backwards compatibility with RFC 2543 compliant implementations that do not support TCP. It is anticipated that this behavior will be = deprecated in a future revision of this specification.=A1=A8 =20 =20 =20 ------=_NextPart_000_0047_01C502F5.23EFAC40 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable

Hello,<= /o:p>

        I have some questions about handling SIP msgs that are larger than 1300 = bytes. RFC 3261, chapter 18 as listed, mentions that if request message is = larger than 1300 bytes, it MUST be sent using TCP because of the meesage size = constraints. But I don=A1=A6t know how to handle the following scenarios, could anyone help me? =

1. The UA1 = registers to Proxy/Registrar with =A1=A7transport=3D= udp=A1=A8 or without =A1=A7transport=A1=A8 parameter. According to RFC3261, the proxy should try to send the request message = to UA1 using default transport, which means UDP. Now suppose that a request = comes and is larger than 1500, what should the proxy do? Still try UDP first or = always use TCP to send the request to UA1? If the proxy selects the first = stretagy, and, unfortunately, the message is splitted into more than one pieces = and only the first one is received by UA1. The received message is incorrect and = might cause UA1 to do incorrect response. Can the proxy select the second = stretagy, i.e, using TCP, even the client only registers with =A1=A7transport=3D= udp=A1=A8? Which stretagy is correct or better?

 <= /o:p>

2. The UA2 = sends the request to proxy using UDP with request message size smaller than 1300 = bytes. The Via header in the request is UDP. But the response backs to the = proxy is larger than 1500 bytes. What should the proxy do? Using TCP or UDP to = transmit the response to UA2?

 <= /o:p>

Any = acknowledgement will be deeply appreciated.

Sincerely,

Fish

 <= /o:p>

=A1=A7If 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.

If an = element sends a request over TCP because of these message size constraints, and that = request would have otherwise been sent over UDP, if the attempt to establish the connection generates either an ICMP Protocol Not Supported, or results = in a TCP reset, the element SHOULD retry the request, using UDP. This is only to = provide backwards compatibility with RFC 2543 compliant implementations that do = not support TCP. It is anticipated that this behavior will be deprecated in = a future revision of this specification.=A1=A8<= /span>

 <= /o:p>

 <= /o:p>

 

------=_NextPart_000_0047_01C502F5.23EFAC40-- --===============1616295453== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1616295453==--