Re: [Sip] RPORT and TCP

Jonathan Rosenberg <jdrosen@dynamicsoft.com> Tue, 30 March 2004 23:53 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 SAA07157 for <sip-archive@odin.ietf.org>; Tue, 30 Mar 2004 18:53:13 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rix-0006ZK-AI for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:47 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PK9Ybp002393 for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 15:09:34 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5LJ-0000ae-1b; Wed, 25 Feb 2004 15:09:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5K9-0008BD-6o for sip@optimus.ietf.org; Wed, 25 Feb 2004 15:08:05 -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 PAA09564 for <sip@ietf.org>; Wed, 25 Feb 2004 15:08:01 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5K6-0004t6-00 for sip@ietf.org; Wed, 25 Feb 2004 15:08:02 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw5JQ-0004nr-00 for sip@ietf.org; Wed, 25 Feb 2004 15:07:20 -0500
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Aw5In-0004hC-00 for sip@ietf.org; Wed, 25 Feb 2004 15:06:41 -0500
Received: from dynamicsoft.com ([63.113.46.35]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1PK6KNr009305; Wed, 25 Feb 2004 15:06:22 -0500 (EST)
Message-ID: <403D0025.7070209@dynamicsoft.com>
Date: Wed, 25 Feb 2004 15:05:57 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sarit Galanos <Sarit@radvision.com>
CC: sip@ietf.org
Subject: Re: [Sip] RPORT and TCP
References: <10DA2C035FE3BC4FA8D73EC55FC43D9B0479F9@rvil-mail.radvision.com>
In-Reply-To: <10DA2C035FE3BC4FA8D73EC55FC43D9B0479F9@rvil-mail.radvision.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
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=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
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: 7bit

responses inline.

Sarit Galanos wrote:

> 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.

No, thats not the case. rport is addressing a very specific problem, 
which is that in UDP, responses are sent to the source IP of the 
request, but to the port in the Via. This odd mix of addressing is 
totally incompatible with NAPT. However, with TCP, "standard" connection 
usage applies - the response is sent on the same connection as the request.

> 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.

Thats the desired behavior. The idea is that, as long as the 
"connection" - which includes the TCP connection, but also any NAPT 
binding, still exists, that gets used for the response. However, should 
that connection/binding fail, the response is sent using a new 
connection, opened to the listen port that the client is expecting new 
reuests to arrive on. That generally is NOT an ephemeral port, and the 
re-establishment would only work in absence of NAT or if there are 
configured port forwarding rules.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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