RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy
"Christer Holmberg" <christer.holmberg@ericsson.com> Wed, 16 January 2008 08:09 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 1JF3Kr-00082C-Tt; Wed, 16 Jan 2008 03:09:21 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JF3Kp-00081v-Dx for sip-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 03:09:19 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF3Kh-00081Z-Dr for sip@ietf.org; Wed, 16 Jan 2008 03:09:11 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF3Kg-000224-7N for sip@ietf.org; Wed, 16 Jan 2008 03:09:11 -0500
Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7DA0620F8B; Wed, 16 Jan 2008 09:09:09 +0100 (CET)
X-AuditID: c1b4fb3c-af796bb0000030cf-70-478dbba5e88f
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 484BD20703; Wed, 16 Jan 2008 09:09:09 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 09:09:08 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy
Date: Wed, 16 Jan 2008 09:09:07 +0100
Message-ID: <CA9998CD4A020D418654FCDEF4E707DF0413D557@esealmw113.eemea.ericsson.se>
In-Reply-To: <478CAE6C.3040703@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy
Thread-Index: AchXdrbiMugeMAL2SlmteE+kJF0BxQAoEZaQ
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> <CA9998CD4A020D418654FCDEF4E707DF0410E399@esealmw113.eemea.ericsson.se> <478CAE6C.3040703@cisco.com>
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@cisco.com>
X-OriginalArrivalTime: 16 Jan 2008 08:09:08.0564 (UTC) FILETIME=[11C47940:01C85817]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: -1.0 (-)
X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f
Cc: sip@ietf.org, "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>, Francois Audet <audet@nortel.com>, "Elwell, John" <john.elwell@siemens.com>
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
Hi, >I am still confused by the distinction between Target and P-CPI. > >I agree that you have described rules for updating Target >that are different from those for updating P-CPI. But it >seems to me that is a distinction without a significant >difference. For the recipient of the request, the two are >used the same way, toward the same end. If anything I would >view the rules for Target to be just a bug fix on P-CPI. You don't update P-CPI. It's inserted by the home proxy, and nothing else. The headers have differenct semantics. I don't see that as a bug. Maybe we could try to change the semantics of P-CPI, and re-define the header, but that was never my intention when I proposed to use P-CPI. Regards, Christer > Paul > > Christer Holmberg wrote: > > Hi John, > > > >> I guess what still confuses me is, when both Target and P-CPI are > >> used, which comes first, i.e., which represents the > earlier target? > >> When I read the draft, I thought Target was earlier. From various > >> clarifying emails I now get the impression that Target is > later. Can > >> you confirm? > > > > I am not sure what you mean by "earlier" target. > > > > Target, if present, always represents the current target. A > receiving > > entity that receives a request without a Target header has > to assume > > that the Request-URI represents the current target. When no Target > > header is available on the request then the Target is > inserted when a > > reroute is performed. > > > > P-CPI is ONLY used to maintain the R-URI which is rewritten by the > > contact of the UAS. I.e. by the home proxy which is usually > at the end > > of a chain of proxies. > > > > When both Target and P-CPI are used: Target always represents the > > current target. P-CPI always represents the AOR received by > the home > > proxy which may in some cases be the same as the current > target but it > > may also be the last route (not equal to the current > target) taken to > > deliver the request. > > > >> Picking up on Francois' point about History-Info, with the > >> introduction of Target and P-CPI we do indeed have a lot > of URIs, and > >> of course History-Info can already convey all these URIs and any > >> others. The difference is that History-Info does not give > particular > >> semantics to each of the URIs it conveys > >> - they are simply a succession of targets. > > > > Yes, we agree with your analysis regarding History-Info. The > > UA-loose-draft discusses further issues with using History-Info. > > > >> With Target and P-CPI we are aiming to define specific > semantics. I > >> am concerned whether we will be able to define these semantics > >> tightly enough to ensure consistent implementations. > > > > Target always represents the current target. See above. > > > > P-CPI does not represent the current target in all cases. See above. > > > >> The more URIs we try to define, the harder it will be to > assign each > > one a clearly distinguishable meaning. I hope the next > draft will help. > > > > In the next version of the draft I will remove as much as possible > > about P-CPI, in order not to cause confusion. I will only keep some > > text where I describe the semantical difference between > Target and P-CPI. > > > > I also do agree with one of your previous comments, that we should > > clarify the meaning of all the URIs we're using - and that > should be > > done no matter if we adopt Target or not. > > > > Regards. > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> -----Original Message----- > >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >>> Sent: 15 January 2008 08:48 > >>> To: Francois Audet > >>> Cc: sip@ietf.org; DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John > >>> Subject: RE: [Sip] RE: Delivering request-URI and > parameters to UAS > >>> via proxy > >>> > >>> > >>> Hi, > >>> > >>> P-CPI could probably be useful in some cases, in addition > to Loose > >>> Route/Target. And, as the draft says, P-CPI will still have > >> to be used > >>> in IMS, because there are procedures defined for it. > >>> > >>> However, again, the purpose of the draft was to provide an > >> alternative > >>> to the Loose Route alternative, and that alternative is > Target only. > >>> > >>> I am working on an updated version of the draft to make that more > >>> clear. > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> > >>> > >>> > >>> > >>>> Hum. I guess then P-Called-ID would then be useful with > >> Loose-route > >>>> as well (although now I'm thinking that History-Info covers it). > >>>> > >>>> I think explaining all that in great and precise details, with a > >>>> concrete example would be very useful. > >>>> > >>>> And then we could compare P-Target with Loose-route. > >>> > >>> > >>> > >>> > >>>>> -----Original Message----- > >>>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >>>>> Sent: Monday, January 14, 2008 03:56 > >>>>> To: Audet, Francois (SC100:3055) > >>>>> Cc: sip@ietf.org; DRAGE, Keith (Keith); Paul Kyzivat; > >> Elwell, John > >>>>> Subject: RE: [Sip] RE: Delivering request-URI and > >>> parameters to UAS > >>>>> via proxy > >>>>> > >>>>> > >>>>> Hi Francois, > >>>>> > >>>>>> I think what you meant by Target was more the "Current" > >>>>>> target as opposed to the Initiatl Target. > >>>>> Yes. > >>>>> > >>>>>> And if that's the case, then I don't see why it is > >>> different from > >>>>>> P-Called-ID (although I might be missing something > >> with what the > >>>>>> P-Called_ID is supposed to be). > >>>>> In the draft we try to explain the difference. But, we are > >>>> working on > >>>>> the text to make it more clear. > >>>>> > >>>>> The P-CPI is inserted when the R-URI is rewritten by > >> the Contact > >>>>> address of the UAS. RFC3455 calls that operation > >>>> "retargeting", but we > >>>>> don't think that is the definition for retarget used in the > >>>>> ua-loose-route draft, which says: > >>>>> > >>>>> "When a home proxy receives a request and accesses a > >>>> location service, > >>>>> the resulting contact(s) obtained from the location service are > >>>>> considered the last hop in the route towards the entity > >>>> addressed by > >>>>> the Request-URI. Since that target, almost by definition, > >>>> can claim > >>>>> the identity of the URI prior to translation, the operation > >>>> is one of > >>>>> routing and not retargeting." > >>>>> > >>>>> So, if we follow the definitions in the ua-loose-route > >>> draft, P-CPI > >>>>> would be inserted due to a reroute - not retarget. > >>>>> > >>>>> But, no matter whether we call it retarget or reroute, > >>> the point is > >>>>> that the P-CPI is inserted when the R-URI is rewritten with the > >>>>> Contact address of the UAS. The scope of Target is wider > >>> than that, > >>>>> and can be used in any retargeting situation. > >>>>> > >>>>> Regards, > >>>>> > >>>>> Christer > >>>>> > >>>>> > > > _______________________________________________ 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] Delivering request-URI and parameters to UA… DRAGE, Keith (Keith)
- VS: [Sip] Delivering request-URI and parameters t… Christer Holmberg
- Re: VS: [Sip] Delivering request-URI and paramete… Jonathan Rosenberg
- VS: VS: [Sip] Delivering request-URI and paramete… Christer Holmberg
- [Sip] RE: Delivering request-URI and parameters t… DRAGE, Keith (Keith)
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- Re: [Sip] RE: Delivering request-URI and paramete… Paul Kyzivat
- RE: [Sip] RE: Delivering request-URI and paramete… Elwell, John
- RE: [Sip] RE: Delivering request-URI and paramete… Francois Audet
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- Re: [Sip] RE: Delivering request-URI and paramete… Paul Kyzivat
- RE: [Sip] RE: Delivering request-URI and paramete… Francois Audet
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- [Sip] Delivering request-URI and parameters to UA… DRAGE, Keith (Keith)
- RE: [Sip] RE: Delivering request-URI and paramete… Francois Audet
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- RE: [Sip] RE: Delivering request-URI and paramete… Elwell, John
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- RE: [Sip] RE: Delivering request-URI and paramete… Elwell, John
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- Re: [Sip] RE: Delivering request-URI and paramete… Paul Kyzivat
- RE: [Sip] RE: Delivering request-URI and paramete… Francois Audet
- Re: [Sip] RE: Delivering request-URI and paramete… Jeroen van Bemmel
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- [Sip] Delivering request-URI and parameters to UA… Christer Holmberg
- [Sip] RE: Delivering request-URI and parameters t… Elwell, John
- [Sip] RE: Delivering request-URI and parameters t… Christer Holmberg
- RE: [Sip] RE: Delivering request-URI and paramete… Elwell, John
- RE: [Sip] Delivering request-URI and parameters t… DRAGE, Keith (Keith)
- RE: [Sip] Delivering request-URI and parameters t… Christer Holmberg
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- Re: [Sip] RE: Delivering request-URI and paramete… Paul Kyzivat
- [Sip] SIP Routers kamalakar.mergu
- RE: [Sip] RE: Delivering request-URI and paramete… Elwell, John
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- RE: [Sip] Delivering request-URI and parameters t… youssef.chadli
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- Re: [Sip] RE: Delivering request-URI and paramete… Joel M. Halpern
- Re: [Sip] Delivering request-URI and parameters t… Enrico Marocco
- Re: [Sip] SIP Routers James M. Polk
- RE: [Sip] RE: Delivering request-URI and paramete… Elwell, John
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- RE: [Sip] RE: Delivering request-URI and paramete… Elwell, John
- [Sip] Vocabulary and problem statement for Reques… Dean Willis
- Re: [Sip] Vocabulary and problem statement for Re… Dean Willis
- RE: [Sip] Vocabulary and problem statement for Re… DRAGE, Keith (Keith)
- RE: [Sip] Vocabulary and problem statement for Re… Hadriel Kaplan
- RE: [Sip] Vocabulary and problem statement for Re… Hadriel Kaplan
- Re: [Sip] Vocabulary and problem statement for Re… Dean Willis
- RE: [Sip] Vocabulary and problem statement for Re… Sanjay Sinha (sanjsinh)
- RE: [Sip] Vocabulary and problem statement for Re… Hadriel Kaplan
- Re: [Sip] Vocabulary and problem statement for Re… Dean Willis
- Re: [Sip] Vocabulary and problem statement for Re… Jeroen van Bemmel
- RE: [Sip] Vocabulary and problem statement for Re… Elwell, John
- Re: [Sip] Vocabulary and problem statement for Re… Paul Kyzivat
- RE: [Sip] Vocabulary and problem statement for Re… Hadriel Kaplan
- RE: [Sip] Vocabulary and problem statement forReq… Elwell, John
- RE: [Sip] Vocabulary and problem statement forReq… Hadriel Kaplan
- Re: [Sip] Vocabulary and problem statement forReq… Paul Kyzivat
- RE: [Sip] Vocabulary and problem statement forReq… Elwell, John
- RE: [Sip] Vocabulary and problem statementforRequ… Elwell, John
- Re: [Sip] Vocabulary and problem statement forReq… Paul Kyzivat
- RE: [Sip] Vocabulary and problem statementforRequ… Christer Holmberg
- Re: [Sip] RE: Delivering request-URI and paramete… Jonathan Rosenberg
- RE: [Sip] Delivering request-URI and parameters t… youssef.chadli
- Re: [Sip] Delivering request-URI and parameters t… Paul Kyzivat
- RE: [Sip] Delivering request-URI and parameters t… youssef.chadli
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- Re: [Sip] Delivering request-URI and parameters t… Paul Kyzivat
- Re: [Sip] Delivering request-URI and parameters t… Hans Erik van Elburg