[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