[Sip] RPORT and TCP
"Sarit Galanos" <Sarit@radvision.com> Tue, 24 February 2004 07:56 UTC
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05380 for <sip-archive@odin.ietf.org>; Tue, 24 Feb 2004 02:56:38 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvXQJ-0006Vn-6B for sip-archive@odin.ietf.org; Tue, 24 Feb 2004 02:56:11 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O7uBf0024952 for sip-archive@odin.ietf.org; Tue, 24 Feb 2004 02:56:11 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvXQB-0006SB-4O; Tue, 24 Feb 2004 02:56:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvXPx-0006RT-Bf for sip@optimus.ietf.org; Tue, 24 Feb 2004 02:55:49 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05372 for <sip@ietf.org>; Tue, 24 Feb 2004 02:55:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvXPt-0006a7-00 for sip@ietf.org; Tue, 24 Feb 2004 02:55:45 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvXOx-0006Wt-00 for sip@ietf.org; Tue, 24 Feb 2004 02:54:48 -0500
Received: from [80.74.106.10] (helo=rvil-mail.radvision.com) by ietf-mx with esmtp (Exim 4.12) id 1AvXOE-0006Tc-00 for sip@ietf.org; Tue, 24 Feb 2004 02:54:02 -0500
Received: from rvil-mail.radvision.com [172.20.2.102] by rvil-mail.radvision.com with XWall v3.28 ; Tue, 24 Feb 2004 09:55:26 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1255"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 24 Feb 2004 09:55:26 +0200
Message-ID: <10DA2C035FE3BC4FA8D73EC55FC43D9B0479F9@rvil-mail.radvision.com>
Thread-Topic: RPORT and TCP
Thread-Index: AcP6q5ANss4LKXxKTByLwpyT0NZaoQ==
From: Sarit Galanos <Sarit@radvision.com>
To: sip@ietf.org
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Subject: [Sip] RPORT and TCP
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Hi, RFC 3581-Symmetric Response Routing specifies that the rport parameter should be used only if the transport is unreliable. "When a server attempts to send a response, it examines the topmost Via header field value of that response. If the "sent-protocol" component indicates an unreliable unicast transport protocol, such as UDP, and there is no "maddr" parameter, but there is both a "received" parameter and an "rport" parameter, the response MUST be sent to the IP address listed in the "received" parameter, and the port in the "rport" parameter. The response MUST be sent from the same address and port that the corresponding request was received on. This effectively adds a new processing step between bullets two and three in Section 18.2.2 of SIP [1]." As I see it, the same problem that rport solves in UDP can happen in TCP. This can happen if the connection is broken between the request and the response. If for example the Via header in the request is: Via: SIP/2.0/TCP proxy.example.com;branch=z9hG4bKkjsh77 and proxy.example.com was resolved to a port different then 5060, the server will not be able to establish a new connection in order to send the response since 5060 will be used. Why do we have the UDP limitation in the standard? How can such a problem be solved. Regards, Sarit. _______________________________________________ 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
- [Sip] RPORT and TCP Sarit Galanos
- Re: [Sip] RPORT and TCP Jonathan Rosenberg