RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy

"Francois Audet" <audet@nortel.com> Tue, 15 January 2008 17:04 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 1JEpD3-0006xc-WE; Tue, 15 Jan 2008 12:04:22 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JEpD2-0006uM-Dj for sip-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 12:04:20 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEpD2-0006uE-3H for sip@ietf.org; Tue, 15 Jan 2008 12:04:20 -0500
Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEpD1-00012T-Gr for sip@ietf.org; Tue, 15 Jan 2008 12:04:20 -0500
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m0FH4GX16732; Tue, 15 Jan 2008 17:04:16 GMT
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy
Date: Tue, 15 Jan 2008 11:04:09 -0600
Message-ID: <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com>
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy
Thread-Index: AchUZtW5bDMRNv3qRbeBDq53RksY6wAC6fXwAAREC3AAAN5tsAAAvlqgAIQb/vAAHhqlMAAKS5DAAAacccAAEIci8A==
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>
From: Francois Audet <audet@nortel.com>
To: "Elwell, John" <john.elwell@siemens.com>, Christer Holmberg <christer.holmberg@ericsson.com>
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a
Cc: sip@ietf.org, Paul Kyzivat <pkyzivat@cisco.com>, "DRAGE, Keith (Keith)" <drage@alcatel-lucent.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

I think we should charge customers per URI in the protocol.

We'd be rich. 

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens.com] 
> Sent: Tuesday, January 15, 2008 01:20
> To: Christer Holmberg; Audet, Francois (SC100:3055)
> Cc: sip@ietf.org; DRAGE, Keith (Keith); Paul Kyzivat
> Subject: RE: [Sip] RE: Delivering request-URI and parameters 
> to UAS via proxy
> 
> Christer,
> 
> 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?
> 
> 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.
> 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. 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.
> 
> John
> 
> > -----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