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

Paul Kyzivat <pkyzivat@cisco.com> Fri, 11 January 2008 19:37 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 1JDPh0-0003ik-P2; Fri, 11 Jan 2008 14:37:26 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JDPgy-0003if-UJ for sip-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 14:37:24 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDPgy-0003iX-KX for sip@ietf.org; Fri, 11 Jan 2008 14:37:24 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDPgx-0003q9-S6 for sip@ietf.org; Fri, 11 Jan 2008 14:37:24 -0500
X-IronPort-AV: E=Sophos;i="4.24,273,1196658000"; d="scan'208";a="83084433"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 11 Jan 2008 14:37:24 -0500
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0BJbN7H004628; Fri, 11 Jan 2008 14:37:23 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0BJbJ6p000928; Fri, 11 Jan 2008 19:37:23 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 14:37:16 -0500
Received: from [161.44.183.181] ([161.44.183.181]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 14:37:16 -0500
Message-ID: <4787C56B.9050002@cisco.com>
Date: Fri, 11 Jan 2008 14:37:15 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [Sip] RE: Delivering request-URI and parameters to UAS via proxy
References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com><CA9998CD4A020D418654FCDEF4E707DF040266B1@esealmw113.eemea.ericsson.se> <47878B1E.3010303@cisco.com> <CA9998CD4A020D418654FCDEF4E707DF04051C96@esealmw113.eemea.ericsson.se>
In-Reply-To: <CA9998CD4A020D418654FCDEF4E707DF04051C96@esealmw113.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Jan 2008 19:37:16.0236 (UTC) FILETIME=[5F1280C0:01C85489]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6048; t=1200080243; x=1200944243; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com> |Subject:=20Re=3A=20[Sip]=20RE=3A=20Delivering=20request-UR I=20and=20parameters=20to=20UAS=20via=20proxy |Sender:=20 |To:=20Christer=20Holmberg=20<christer.holmberg@ericsson.co m>; bh=a4VhrU9dV+6X/IYTgx2VfaYGqxrUO6SATWVwQAhklxg=; b=ISUC3r10SrNAfvgRW/V+TivwJVi0wHsszDFpjbHi95KhawYQo0nzn8viIH CDh/uXmxrVtQLZLW1ka6DLHVjAwXgBezuxUrNNl6SP8bEBadLEMm8RBxRj0D FojWMHEcxS;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f
Cc: sip@ietf.org, "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


Christer Holmberg wrote:
> Hi Paul, 
> 
>> 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.
> 
> As indicated in chapter 3, one of the main issues/limitations with the
> J'draft solution is that the entity wanting to use it must have
> knowledge whether the next hop also supports it. My understanding from
> off-line discussions I had with Jonathan in Vancouver is also that
> Jonathan agrees to that issue/limitation.
> 
> The purpose of the examples is just to show what can go wrong if the
> next hop does not understand the mechanism. But, if we all agree to the
> limitation with the J'draft solution I don't know whether we need to
> spend too much time on the examples.

The limitation is the limitation. It means that you don't use the 
mechanism if you don't know the next hop supports it. So its useless to 
speculate what would go wrong if you use the mechanism with a next hop 
that doesn't support it.

>> - 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.
> 
> No, as far as the alternative to the J'draft solution is concerned, the
> alternative is Target. We believe it can be used for all listed
> use-cases.

I don't understand. Several of them called for using P-CPI.

> Since I myself have been talking about P-CPI as an alternative, we
> wanted to show in which cases it could be used as an alternative, and
> why we think that P-CPI still would have to be used in IMS. 
> 
> But, we have realized that P-CPI as defined and used today probably
> would not solve all the use-cases, and that is the reason we came up
> with the Target header.
> 
>> 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.
> 
> I appologize if the P-CPI text causes confusion. Again, the alternative
> to the J'draft solution we propose is Target.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> 
> 
> 
>> 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-target-uri-d
>>> el
>>> 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