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

"Christer Holmberg" <christer.holmberg@ericsson.com> Fri, 11 January 2008 19:33 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 1JDPcy-00006Z-LU; Fri, 11 Jan 2008 14:33:16 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JDPcx-0008MS-2K for sip-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 14:33:15 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDPcw-0008K8-MW for sip@ietf.org; Fri, 11 Jan 2008 14:33:14 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDPcv-00017v-Eg for sip@ietf.org; Fri, 11 Jan 2008 14:33:14 -0500
Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C96C92053E; Fri, 11 Jan 2008 20:33:12 +0100 (CET)
X-AuditID: c1b4fb3e-b1ea5bb00000459d-98-4787c478d9f7
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8F732200D8; Fri, 11 Jan 2008 20:33: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); Fri, 11 Jan 2008 20:33: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: Fri, 11 Jan 2008 20:33:11 +0100
Message-ID: <CA9998CD4A020D418654FCDEF4E707DF04051C9D@esealmw113.eemea.ericsson.se>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy
Thread-Index: AchUZtW5bDMRNv3qRbeBDq53RksY6wAC6fXwAAREC3AAAN5tsA==
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>
From: "Christer Holmberg" <christer.holmberg@ericsson.com>
To: "Francois Audet" <audet@nortel.com>
X-OriginalArrivalTime: 11 Jan 2008 19:33:12.0307 (UTC) FILETIME=[CDADE430:01C85488]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8
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,

I answer both John's and Francois' questions in this reply.

>I'm also totally confused now about what is being proposed.
> 
>The Target seems identical to the To header field.

I don't think they are identical. Jonathan's draft describes the issues
with using the To header.

>I tought that what you (Christer) was arguing for is using 
>the P-Called-Header instead of the new loose route proposal, 
>i.e., not for the "initial target", but for the "current target".

Yes, I have.

But, as the P-PCI header is currently defined and used (e.g. in 3GPP) we
are not sure it could be used for all use-cases.

Also, if you read the abstract it does say "current target". I guess the
same wording should be used elsewhere too.

>>In addition to Paul's concerns, I am having difficulty understanding 
>>why the To header field is insufficient for the cases where the Target

>>header field is proposed. The initial source of this confusion was the

>>statement "the Target header field represents the initial target
identity that was used to initiate a 
>>session to the target"
>> 
>>So we now have 4 fields (ignoring Route):
>>- To
>>- Target
>>- P-Called-ID
>>- Request-URI
>>I think it would benefit from a clearer exposition of the semantics 
>>and relationship between these.

That main purpose of the document was to define an alternative to the
solution in Jonathan's draft, and due to time issues that is what we
focused on.

But, I do agree that there are lots of things that could be clarified
and explained - no matter what solution we move forward with.

Regards,

Christer








> > > -----Original Message-----
> > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > > Sent: 11 January 2008 15:29
> > > To: Christer Holmberg
> > > Cc: sip@ietf.org; DRAGE, Keith (Keith)
> > > Subject: Re: [Sip] RE: Delivering request-URI and 
> parameters to UAS 
> > > via proxy
> > > 
> > > Christer,
> > > 
> > > I have some questions and comments:
> > > 
> > > - I don't understand your examples in section 3. They are a bit 
> > > sketchy about the assumptions they are making, and in
> > notation. I get
> > > lost about which referenced component has which address,
> > etc. I am far
> > > from convinced that these are problems with appropriate 
> use of the 
> > > mechanism.
> > > 
> > > - It seems from your analysis of use cases that it is
> > P-Called-Party
> > > that solves many of them, not Target. So both headers seem
> > to be part
> > > of the solution. Its not entirely clear to me at the 
> moment whether 
> > > the R-URI in the loose-route approach aligns with Target or 
> > > P-Called-Party.
> > > Since they are different, it can't align with both. So
> > there must be
> > > some features it doesn't cover. I haven't fully grokked that yet.
> > > 
> > > 	Paul
> > > 
> > > 
> > > Christer Holmberg wrote:
> > > > Hi,
> > > > 
> > > > We have submitted a draft with an alternative proposal.
> > > > 
> > > > It can also be found at:
> > > > 
> > > > 
> > > http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-targ
> > > et-uri-del
> > > > ivery-00.txt
> > > > 
> > > > Regards,
> > > > 
> > > > Christer
> > > > 
> > > >  
> > > > 
> > > >> -----Original Message-----
> > > >> From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]
> > > >> Sent: 9. tammikuuta 2008 18:32
> > > >> To: sip@ietf.org
> > > >> Subject: [Sip] RE: Delivering request-URI and parameters
> > to UAS via
> > > >> proxy
> > > >>
> > > >> A reminder of the deadline on the 11th January for submitting 
> > > >> alternative proposals on the way forward.
> > > >>
> > > >> Regards
> > > >>
> > > >> Keith
> > > >>
> > > >>> -----Original Message-----
> > > >>> From: DRAGE, Keith (Keith)
> > > >>> Sent: Tuesday, December 04, 2007 3:27 PM
> > > >>> To: sip@ietf.org
> > > >>> Subject: Delivering request-URI and parameters to UAS 
> via proxy
> > > >>>
> > > >>> (As WG chair)
> > > >>>
> > > >>> We have a couple of milestones that we generated as a 
> result of 
> > > >>> discussion of
> > > >>>
> > > >>> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo
> > > >>> se-route-01.txt
> > > >>>
> > > >>> Dec 2007    Delivering request-URI and parameters to UAS via 
> > > >>> proxy to WGLC  
> > > >>> Feb 2008    Delivering request-URI and parameters to UAS via 
> > > >>> proxy to IESG (PS)
> > > >>>
> > > >>> This work is currently stalled and the editor needs input.
> > > >>>
> > > >>> The document contains various example scenarios where a
> > > solution is
> > > >>> required, for which there appears to be no dispute that a
> > > >> solution is
> > > >>> needed.
> > > >>>
> > > >>> The document proposes one solution to resolve these example
> > > >> scenarios,
> > > >>> but this solution is not gaining consensus. At least 
> one other 
> > > >>> solution has been talked about, but there is no
> > > >> documentation on the
> > > >>> table.
> > > >>>
> > > >>> This mail is to identify a deadline for other solutions to
> > > >> the example
> > > >>> scenarios to be documented as internet drafts, 
> showing how the 
> > > >>> solution works for those scenarios. This deadline is:
> > > >>>
> > > >>> 	January 11th 2008
> > > >>>
> > > >>> It is appropriate fo these documents to identify any other
> > > >> scenarios
> > > >>> where such a solution is appropriate. Any other input is
> > > >> also welcome
> > > >>> in identifying other scenarios.
> > > >>>
> > > >>> If we have no such internet-drafts by this deadline, we
> > > >> will proceed
> > > >>> with completing the solution we have.
> > > >>>
> > > >>>
> > > >>> Regards
> > > >>>
> > > >>> Keith
> > > >>>
> > > >>>
> > > >>
> > > >> _______________________________________________
> > > >> 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
> > > > 
> > > 
> > > 
> > > _______________________________________________
> > > 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
> > 
> 
> 
> _______________________________________________
> 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