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

"Elwell, John" <john.elwell@siemens.com> Fri, 18 January 2008 16:06 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 1JFtjW-0001FE-Af; Fri, 18 Jan 2008 11:06:18 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFtjS-0001F4-P1 for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 11:06:14 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtjS-0001Ev-8s for sip@ietf.org; Fri, 18 Jan 2008 11:06:14 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFtjR-0007FZ-DQ for sip@ietf.org; Fri, 18 Jan 2008 11:06:14 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JUU00C2KKQCFJ@siemenscomms.co.uk> for sip@ietf.org; Fri, 18 Jan 2008 16:06:12 +0000 (GMT)
Date: Fri, 18 Jan 2008 16:06:12 +0000
From: "Elwell, John" <john.elwell@siemens.com>
Subject: RE: [Sip] Vocabulary and problem statement forRequest-URI,retargeting, and SIP routing (long, but read it!)
In-reply-to: <E6C2E8958BA59A4FB960963D475F7AC306E4ED4A3A@mail.acmepacket.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>, Dean Willis <dean.willis@softarmor.com>, IETF SIP List <sip@ietf.org>
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D05941F2@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: quoted-printable
Thread-Topic: [Sip] Vocabulary and problem statement forRequest-URI,retargeting, and SIP routing (long, but read it!)
thread-index: AchZPU+/dzx0k6eGS1WWuhtw80L2kAADrUvgABZyvrAADtRW8AABPONgAABHrjAAARDLsA==
Content-class: urn:content-classes:message
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <CA9998CD4A020D418654FCDEF4E707DF040266B1@esealmw113.eemea.ericsson.se> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <CA9998CD4A020D418654FCDEF4E707DF04051C9D@esealmw113.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <CA9998CD4A020D418654FCDEF4E707DF040960B7@esealmw113.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <CA9998CD4A020D418654FCDEF4E707DF040D69C7@esealmw113.eemea.ericsson.se> <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> <CA9998CD4A020D418654FCDEF4E707DF0413D587@esealmw113.eemea.ericsson.se> A <"CA9998CD4A0 20D418654FCDEF4E707DF04173CB8"@esealmw113.eemea.ericsson.se> <" 0 D5F89FAC2 9 E2 C41B98A6A762007F5D0593CFF"@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> <0D5F89FAC29E2C41B98A6A762007F5D0594068@GBNTHT12009MSX.gb002.siemens.net> <E6C2E8958BA59A4FB960963D475F7AC306E4ED497B@mail.acmepacket.com> <0D5F89FAC29E2C41B98A6A762007F5D05941CF@GBNTHT12009MSX.gb002.siemens.net> <E6C2E8958BA59A4FB960963D475F7AC306E4ED4A3A@mail.acmepacket.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a
Cc:
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

 

> -----Original Message-----
> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] 
> Sent: 18 January 2008 15:52
> To: Elwell, John; Dean Willis; IETF SIP List
> Subject: RE: [Sip] Vocabulary and problem statement 
> forRequest-URI,retargeting, and SIP routing (long, but read it!)
> 
> Yeah I like STUD because it's explicit.
> But the big difference I see is what happens if R1 supports 
> STUD but P2, or more likely a domain between P2 and P3, 
> Retarget but don't support STUD.  Then R2 gets a Target which 
> is wrong - it's the URI of C vs. D (or something between D).  
> In other words it could be the target uri of a completely 
> different user/domain.
> 
> With UALR, since retargeting proxies already replace the 
> req-uri today, you'd get a req-uri which isn't wrong.  Even 
> if P2 did Rerouting and not UALR (ie, still replaced the 
> req-uri but was not really retargeting), the req-uri received 
> by R2 wouldn't be totally wrong.  It would lose the 
> parameters and info that could have been useful, but it's 
> less likely to cause harm. (maybe?)
> 
> The counter-argument is what happens if P3 doesn't do UALR, 
> but I would think it's far more likely that an operator of a 
> domain has control over the equipment in their domain.
[JRE] And also, P2 should be just routing on the Route header field,
because there is still something in the stack. So it would have to be a
misbehaving proxy to get it wrong.
But in any case, I thought UALR was meant to be applied only on the last
hop (or the last set of hops) from the domain proxy to the UAS, so once
you invoke it there should not be any more retargeting or rerouting
proxies on the path. Maybe the domain proxy is never able to be certain
of this.

John

> 
> Though I'm probably thinking in circles - this whole topic 
> makes my head hurt.  :)
> 
> -hadriel
> 
> > -----Original Message-----
> > From: Elwell, John [mailto:john.elwell@siemens.com]
> > Sent: Friday, January 18, 2008 10:28 AM
> > To: Hadriel Kaplan; Dean Willis; IETF SIP List
> > Subject: RE: [Sip] Vocabulary and problem statement forRequest-
> > URI,retargeting, and SIP routing (long, but read it!)
> >
> > Hadriel,
> >
> > Well, I have been having a side thread with Christer and 
> Hans Erik, and
> > the only difference other than syntax that they could 
> convince me of was
> > support for UAs that do not register, in that with 
> loose-route you would
> > need additional provisioning in the domain proxy to say that the UA
> > (gateway or whatever) supports loose-route. Given that you 
> would need
> > provisioning in the proxy anyway for such UAs, I didn't see 
> this as a
> > big deal, but it is a difference.
> >
> > John
> >
> > > -----Original Message-----
> > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]
> > > Sent: 18 January 2008 15:15
> > > To: Elwell, John; Dean Willis; IETF SIP List
> > > Subject: RE: [Sip] Vocabulary and problem statement
> > > forRequest-URI,retargeting, and SIP routing (long, but read it!)
> > >
> > > Hey John,
> > > Inline...
> > >
> > > > -----Original Message-----
> > > > From: Elwell, John [mailto:john.elwell@siemens.com]
> > > > Sent: Friday, January 18, 2008 2:48 AM
> > > > >
> > > > > 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.
> > > > [JRE] According to Dean's definition of RT, it does not 
> change the
> > > > Request-URI (only the Route header field presumably, or
> > > maybe not even
> > > > that).
> > > > So C, D and E are the same. Also A and B are the same, and
> > > F and G are
> > > > the same.
> > > > So I think:
> > > > - UA-Loose-routing gives you C/D/E
> > > > - To gives you A/B
> > > > - PCPID gives you C/D/E
> > > > - Target gives you C/D/E
> > > > - Hist-info gives you A/B, C/D/E and F/G.
> > >
> > > Yes, I agree that is the *theory*.  :)
> > > I drew it that way though so we could argue about what the
> > > UAS/UALR-draft _wants_ to happen vs. what _will_ happen if P2
> > > or P3 are not purely RT's and didn't support a new draft.
> > > (Since it seemed the conversation was going that way
> > > previously on this list, for example when Christer pointed
> > > out the difference between Target and PCPID)
> > >
> > > For example, I think there is more than just a syntax
> > > difference between Christer's sip-target-uri-delivery draft
> > > (STUD?) and Jonathan's UALR approach.  Though I have no idea
> > > which one is better.
> > >
> > > -hadriel
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
> > >
> 


_______________________________________________
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