Subject: Re: [Sip] RPORT and TCP

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 25 Feb 2004 15:05:57 -0500

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
[email-masked]                     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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip