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

Dean Willis <dean.willis@softarmor.com> Thu, 17 January 2008 23:26 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 1JFe7i-0006Zq-OR; Thu, 17 Jan 2008 18:26:14 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFe7g-0006Zf-VZ for sip-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 18:26:12 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFe7g-0006ZX-Ju for sip@ietf.org; Thu, 17 Jan 2008 18:26:12 -0500
Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFe7g-0000ZH-80 for sip@ietf.org; Thu, 17 Jan 2008 18:26:12 -0500
Received: from [192.168.2.102] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m0HNQ8Wu025703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Jan 2008 17:26:10 -0600
Message-ID: <478FE5D7.7010707@softarmor.com>
Date: Thu, 17 Jan 2008 17:33:43 -0600
From: Dean Willis <dean.willis@softarmor.com>
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Hadriel Kaplan <HKaplan@acmepacket.com>
Subject: Re: [Sip] Vocabulary and problem statement for Request-URI, retargeting, and SIP routing (long, but read it!)
References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <CA9998CD4A020D418654FCDEF4E707DF040D69C7@esealmw113.eemea.ericsson.se> <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> <CA9998CD4A020D418654FCDEF4E707DF0413D587@esealmw113.eemea.ericsson.se> <"0D5F89FA C29E2C41B98A6A762007F5D0593C68"@GBNTHT12009MSX.gb002.siemen! s .net> A <CA9998CD4A0 20D418654FCDEF4E707DF04173CB8@esealmw113.eemea.ericsson.se> <0D5F89FAC29E2C41B98A6A762007F5D0593CFF@GBNTHT12009MSX.gb002.siemens.net> A <CA9998CD4A020D418654FCDEF4E707DF041743D6@esealmw113.eemea.ericsson.se> <0D5F89FAC29E2C41B98A6A762007F5D0593E13@GBNTHT12009MSX.gb002.siemens.net> <CA9998CD4A020D418654FCDEF4E707DF041C939B@esealmw113.eemea.ericsson.se> <C8D63C78-437F-430E-950C-2E63C69E3CEF@softarmor.com> <E6C2E8958BA59A4FB960963D475F7AC306E4ED44F6@mail.acmepacket.com>
In-Reply-To: <E6C2E8958BA59A4FB960963D475F7AC306E4ED44F6@mail.acmepacket.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
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

Hadriel Kaplan wrote:
> 
>> We also have a related operation:
>> 
>> 4) Request redirection, which informs an upstream node about a new 
>> identity to target instead of the original.
> 
> 
> This is described from the aspect of the downstream node sending the
> 3xx, right?  Vs. what it is for the upstream node recursing on the
> 3xx? (which has no idea if it's performing (2) or (3) when this
> occurs, but I guess could be added to the 3xx contact as a param such
> as described in JR's draft)

right.

> So if a proxy is doing "redirection" it is sending a 3xx,

Right.

> 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. We'd actually
have more information from a REFER request.

We've already seen all sorts of hideous problems related to an upstream
proxy recursing on a 3xx. My take is that we should never do this in a
proxy.

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