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:37 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 1JFeIs-0003DK-Cm; Thu, 17 Jan 2008 18:37:46 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFeIq-0003Ch-Vg for sip-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 18:37:44 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFeIq-0003CU-KK for sip@ietf.org; Thu, 17 Jan 2008 18:37:44 -0500
Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFeIq-0000o0-3m for sip@ietf.org; Thu, 17 Jan 2008 18:37:44 -0500
Received: from [192.168.2.102] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m0HNbeBU025767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Jan 2008 17:37:41 -0600
Message-ID: <478FE88B.30501@softarmor.com>
Date: Thu, 17 Jan 2008 17:45:15 -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> <E6C2E8958BA59A4FB960963D475F7AC306E4ED4501@mail.acmepacket.com>
In-Reply-To: <E6C2E8958BA59A4FB960963D475F7AC306E4ED4501@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: 34d35111647d654d033d58d318c0d21a
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:
> 
>>-----Original Message-----
>>From: Dean Willis [mailto:dean.willis@softarmor.com]
>>Sent: Thursday, January 17, 2008 2:13 PM
>>
>>Call for clarity on exactly which problems we're solving with UA-
>>Loose-Routing, target, CPID, etc. Proposed: target identity, end-to-
>>end parameters.
> 
> 
> Not exactly.  I believe the idea in the UALR draft is to get the
> target identity/params created by the nearest re-targeting event
> relative to the UAS, where those created by the UAC is the default
> such event (and thus the logical "farthest").  In other words, what
> you say is true, except if the request got retargeted, the identity
> and params will be those of the new target, and thus not end-to-end
> and not always what the UAC sent.  Right?

AFAIK, the original goal of UALR was to get parameters to applications. 
The last time I thought I understood the draft, these were preserved 
back somewhere on teh route stack so that the application could get them.

The other thing UALR does, and this is kind of neat, is allow different 
sets of parameters to be stuffed in at different places, and for the UAS 
to be able to differentiate where those parameters were inserted (at 
least a little bit -- "original", "middle", and "last hop" being easy to 
parse.).

> 
> For example, given the following, where "RTRG" means Re-Targeting,
"RRT" means Re-Routing, "RT" means Routing, and the single letters
represent connections:
> 
>                     RRT
>                    +---+
>                    |R1 |
>                 B /+---+\ C
>             RT   /       \  RT
>            +---+/         \+---+
>            |P1 |           |P1 |
>         A /+---+           +---+\ D
>          /                       \
>    +---+/                         \+---+
>    |UAC|                           |UAS|
>    +---+                           +---+
> 
> UA-Loose-routing wants the req-uri seen on connection "A" I think.

I think so too.

> To header gives you A.
> PCPID gives you B.
> Hist-Info gives you A,B,C.

and D is directly visible to UAS, should RT have inserted any.


> 
> But in the re-targeting scenario such as:
>                     RTRG                    RRT
>                    +---+                   +---+
>                    |R1 |                   |R2 |
>                 B /+---+\ C             E /+---+\ F
>             RT   /       \  RT      RT   /       \  RT
>            +---+/         \+---+ D +---+/         \+---+
>            |P1 |           |P2 +---+P3 |           |P4 |
>         A /+---+           +---+   +---+           +---+\ G
>          /                                               \
>    +---+/                                                 \+---+
>    |UAC|                                                   |UAS|
>    +---+                                                   +---+
> 
> UA-Loose-routing wants the req-uri seen on connection "C" I think.
> To header gives you A.
> PCPID gives you E.
> Hist-Info gives you A,B,C,D,E,F.

As I thought I understood it, UALR gives us the stack of A and C.

But I may well not understand.


However, this does illustrate that there's another axis of proxy 
operations that can be happening.

In addition to affecting the route, the target, and the identity of the 
target, proxies may also affect parameters.

But "repararametering" is such an ugly word. And it's an ugly concept, 
when you think about the consequences. I'm tempted to think of all 
reparametering as retargeting.

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