Re: [Sip] RE: Delivering request-URI and parameters to UAS via proxy -new version of the draft-holmberg-sip-target-uri-delivery draft

Paul Kyzivat <pkyzivat@cisco.com> Wed, 16 January 2008 12:59 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 1JF7rN-0007Gr-OP; Wed, 16 Jan 2008 07:59:13 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JF7rM-0007FS-8B for sip-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 07:59:12 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF7rL-0007FK-Rp for sip@ietf.org; Wed, 16 Jan 2008 07:59:11 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF7rL-0001J9-37 for sip@ietf.org; Wed, 16 Jan 2008 07:59:11 -0500
X-IronPort-AV: E=Sophos;i="4.24,293,1196658000"; d="scan'208";a="83496114"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 16 Jan 2008 07:59:09 -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 m0GCx8GM028619; Wed, 16 Jan 2008 07:59:08 -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 m0GCx4ua010366; Wed, 16 Jan 2008 12:59:04 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); Wed, 16 Jan 2008 07:59:03 -0500
Received: from [10.86.240.6] ([10.86.240.6]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 07:59:03 -0500
Message-ID: <478DFF99.4090405@cisco.com>
Date: Wed, 16 Jan 2008 07:59:05 -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 -new version of the draft-holmberg-sip-target-uri-delivery draft
References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.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><CA9998CD4A020D418654FCDEF4E707DF0413D587@esealmw113.eemea.ericsson.se><"0D5F89FAC29E2C41B98A6A762007F5D0593C0E"@GBNTHT12009MSX.gb002.siemens.net>A<CA9998CD 4A020D41 8654FCDEF4E7 07DF04173AE9@esealmw113.eemea.ericsson.se> <0D5F89FAC29E2C41B98A6A762007F5D0593C68@GBNTHT12009MSX.gb002.siemens.net> <CA9998CD4A020D418654FCDEF4E707DF04173CB8@esealmw113.eemea.ericsson.se>
In-Reply-To: <CA9998CD4A020D418654FCDEF4E707DF04173CB8@esealmw113.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Jan 2008 12:59:03.0623 (UTC) FILETIME=[9207D570:01C8583F]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5785; t=1200488348; x=1201352348; 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=0A=20-new=20ve rsion=20of=20the=20draft-holmberg-sip-target-uri-delivery=20 draft |Sender:=20 |To:=20Christer=20Holmberg=20<christer.holmberg@ericsson.co m>; bh=rfnW60DPLotvYvsj2clzPsBPKOadCfzYvrE+O0Tzpi8=; b=okzWZ0BighuFpzpWf/tdazF7EJCeucMD6WzeQIofNwyPCGo4O7ppkRwZ2W ywiXZ+R6L+5wgPQO/gMUedKlbvwVwFvQJ1qAAwRFBo1rulzIh7PgxIMCpMgk 9IRAppr4gn;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48
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


Christer Holmberg wrote:
> Hi, 
> 
>> I hear what you are saying, but I don't really see that the points you
> raised in section 4 are real limitations of the loose route mechanism.
> 
> I think it is a limitation that an entity using the mechanism has to
> know whether the the next hop supports it or not, and that the mechanism
> can only be used if the subsequent hops support it.

In theory it is a problem. Its not at all clear that it is a problem in 
practice. That depends on whether this *will* be known in the places 
where the mechanism is used.

AFAIK the loose route draft requires that the behavior of the next hop 
*be* known before the mechanism is used. So raising issues based on 
problems if it is used inappropriately are not valid. What *would* be 
valid are places where the mechanism is not used because support it not 
known, resulting is less functionality. I remain to be convinced there 
are any such cases.

So I think these two mechanisms are getting close to be just being in a 
beauty contest.

I think the crucial point in both of these is deciding when you are 
retargeting vs rerouting.

	Paul

> Regards,
> 
> Christer
> 
> 
> 
> 
>>> -----Original Message-----
>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
>>> Sent: 16 January 2008 11:06
>>> To: Elwell, John; sip@ietf.org
>>> Cc: Paul Kyzivat; DRAGE, Keith (Keith); Francois Audet
>>> Subject: [Sip] RE: Delivering request-URI and parameters to UAS via 
>>> proxy - new version of the draft-holmberg-sip-target-uri-delivery 
>>> draft
>>>
>>>
>>> Hi John,
>>>
>>>> Thanks for this revision, which makes things somewhat 
>> clearer. I do 
>>>> have a couple of comments:
>>>>
>>>> 1. I am not sure I agree with the assertions in section 4 
>> concerning 
>>>> issues with the mechanisms in loose-route. Taking example 1, the 
>>>> Route header field should contain enough entries to get you to the 
>>>> registered contact, not just to an intermediate proxy. 
>> Therefore this 
>>>> situation should not arise with a correctly implemented 
>> home proxy. 
>>>> It is not clear to me how example 2 could arise either, 
>> for similar 
>>>> reasons. The MGC case can be resolved by taking into account the 
>>>> option tag in the REGISTER request, or if it is permanently 
>>>> registered, through provisioning.
>>> The examples are not meant to show bugs in the loose-route 
>> mechanism.
>>> They are meant to help people understand the limitations with the 
>>> loose-route mechanism.
>>>  
>>>> 2. Comparing the mechanism proposed with the loose-route 
>> mechanism, 
>>>> my understanding is:
>>>> a)When retargeting occurs, the loose-route mechanism 
>> places the new 
>>>> target in the Request URI. Your proposal places the new target in 
>>>> both the Request-URI and the Target header field.
>>>> b) When rerouting, the loose-route mechanism places the new route 
>>>> (i.e., the registered contact) in the Route header field. Your 
>>>> proposal places the new route in the Request-URI (the 
>> latter as per 
>>>> RFC 3261).
>>>> So the two mechanisms solve exactly the same problems using a 
>>>> slightly different mechanism. Correct?
>>> Yes. The two solutions intend to solve the same problem.
>>>  
>>>> 3. How P-Called-Party-ID fits into this is not really 
>> relevant from 
>>>> an IETF perspective - it seems there are some 3GPP-specific 
>>>> situations where the contents of P-Called-Party-ID will 
>> not equal the 
>>>> contents of Target. Correct?
>>> Correct.
>>>
>>>> 4. If my suggestion in point 1 above that the loose-route 
>> mechanism 
>>>> does not suffer from the problems suggested, then each 
>> mechanism will 
>>>> work and each addresses the same problem.
>>>> So it is just down to a beauty contest between the two. Correct?
>>> See question 1.
>>>
>>> We believe that our solution does not have the same 
>> limitations as the 
>>> loose-route solution. But, again, both solutions intend to 
>> solve the 
>>> same problem.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>
>>>
>>>
>>>
>>>>> -----Original Message-----
>>>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
>>>>> Sent: 16 January 2008 08:41
>>>>> To: sip@ietf.org
>>>>> Cc: DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John; 
>> Jeroen van 
>>>>> Bemmel; Francois Audet
>>>>> Subject: Delivering request-URI and parameters to UAS via
>>>> proxy - new
>>>>> version of the draft-holmberg-sip-target-uri-delivery draft
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> We've uploaded a new version (-01) of the Target draft.
>>>>>
>>>>> We've tried to make things more clear. I've also 
>> removed all text 
>>>>> about P-Called-Party-ID, except from one chapter where 
>> we try to 
>>>>> explain the semantical difference between Target and P-CPI.
>>>>>
>>>>> You can also find the draft from:
>>>>> http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-targ
>>>>> et-uri-del
>>>>> ivery-01.txt
>>>>>
>>>>> 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
>>
> 


_______________________________________________
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