Re: [Sip] Vocabulary and problem statement for Request-URI, retargeting, and SIP routing (long, but read it!)

Dean Willis <dean.willis@softarmor.com> Fri, 18 January 2008 05:34 UTC

Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFjrj-0008Mr-Bw; Fri, 18 Jan 2008 00:34:07 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFjrh-0008Jc-9P for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 00:34:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFjrg-0008Ht-UV for sip@ietf.org; Fri, 18 Jan 2008 00:34:04 -0500
Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFjrg-0006ff-D4 for sip@ietf.org; Fri, 18 Jan 2008 00:34:04 -0500
Received: from [206.176.144.213] (206-176-144-213.waymark.net [206.176.144.213]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m0I5XtNj027388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Jan 2008 23:33:57 -0600
Message-ID: <47903A44.4070009@softarmor.com>
Date: Thu, 17 Jan 2008 23:33:56 -0600
From: Dean Willis <dean.willis@softarmor.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: "Sanjay Sinha (sanjsinh)" <sanjsinh@cisco.com>
Subject: Re: [Sip] Vocabulary and problem statement for Request-URI, retargeting, and SIP routing (long, but read it!)
References: <5C5630E45267B642894988A97570D3220D2841@xmb-rtp-215.amer.cisco.com>
In-Reply-To: <5C5630E45267B642894988A97570D3220D2841@xmb-rtp-215.amer.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
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>
Errors-To: sip-bounces@ietf.org

Sanjay Sinha (sanjsinh) wrote:
> Inline ...
>
>   
>>> whereas the
>>> upstream proxy or UAC getting that 3xx is not doing redirection, but 
>>> in fact "recursing".
>>>
>>>       
>> The upstream node is just generating a new request. It really 
>> doesn't know where that request is going, except that the new 
>> request URI was obtained during an attempt to reach the old 
>> one. 
>>     
> Not sure what you mean here? The next request-uri is taken from Contact
> of the redirect response. So it knows where the request is going.
>   

It knows the URI that the request is going to. It doesn't know "who" 
that URI will reach, or what their relationship to the original URI is 
(unless perhaps "History-Info" explains it). However, this is at least 
enough knowledge to be able to prevent the unanticipated response 
problem sometimes, because we can at least check that the identity 
expressed in the eventual response matches that received in the 302. 
Assuming, of course, that the new URI doesn't go through some sort of 
retargeting operation that does not preserve the request identity.

>   
>> We'd actually have more information from a REFER request.
>>     
> How is the Refer-To header different that Contacts in redirect response?
>
>   
We're not really sure where the 3xx response came from. All we know is 
that it was generated somewhere along the path towards the original 
request-URI. REFER, however, is a request instead of a response, so we 
can use the various request-authentication techniques to figure out who 
sent it.


--
Dean



_______________________________________________
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