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

"Christer Holmberg" <christer.holmberg@ericsson.com> Wed, 16 January 2008 08:12 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 1JF3Nk-0000w4-W0; Wed, 16 Jan 2008 03:12:20 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JF3Nj-0000vx-CN for sip-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 03:12:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF3Ni-0000vo-Ui for sip@ietf.org; Wed, 16 Jan 2008 03:12:18 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF3Ng-0007hM-M6 for sip@ietf.org; Wed, 16 Jan 2008 03:12:18 -0500
Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 150882169C; Wed, 16 Jan 2008 09:12:13 +0100 (CET)
X-AuditID: c1b4fb3e-b06a2bb00000459d-43-478dbc5c7871
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DEC0B2156F; Wed, 16 Jan 2008 09:12:12 +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:12:12 +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:12:11 +0100
Message-ID: <CA9998CD4A020D418654FCDEF4E707DF0413D587@esealmw113.eemea.ericsson.se>
In-Reply-To: <478CEFB4.6070002@zonnet.nl>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy
Thread-Index: AchXnY+F82ywc0SeQiGSlvvV9WnM7QAZ7COQ
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>
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Jeroen van Bemmel <jbemmel@zonnet.nl>, Francois Audet <audet@nortel.com>
X-OriginalArrivalTime: 16 Jan 2008 08:12:12.0435 (UTC) FILETIME=[7F5CF630: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>, Paul Kyzivat <pkyzivat@cisco.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 Jeroen, 

>I think we'll also need a new response code: 4xx I'm confused, too many
URIs in request
> 
>Seriously, a solution based on yet another header with an URI IMHO
introduces more complexity/confusion than solving the 
>issue is worth.
> 
>Better to limit the scope of the problem we're trying to 
>solve and document the known limitations / use cases. If the 
>problem is to deliver the request URI to a UAS which is 
>registered with its home proxy, and there is a mechanism by 
>which the proxy can detect support by the UAS, Jonathan's 
>solution is fine. 

I don't think that is the whole problem (if it was, P-Called-Party-ID
would probably work just fine). To my understanding it is not
necessarily the home proxy of the UAS which rewrites the Request-URI in
the use-cases presented in the drafts. It can be another entity in the
path - an entity which havs no clue about what the UAS supports or not.

Regards,

Christer






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


_______________________________________________
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