Re: [Sip] RE: Delivering request-URI and parameters to UAS via proxy -new version of the draft-holmberg-sip-target-uri-delivery draft
Jonathan Rosenberg <jdrosen@cisco.com> Fri, 25 January 2008 20:49 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 1JIVUZ-000647-Al; Fri, 25 Jan 2008 15:49:39 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JIVUY-00062j-31 for sip-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 15:49:38 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIVUX-00061b-NS for sip@ietf.org; Fri, 25 Jan 2008 15:49:37 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIVUV-0004bC-Vl for sip@ietf.org; Fri, 25 Jan 2008 15:49:37 -0500
X-IronPort-AV: E=Sophos;i="4.25,252,1199692800"; d="scan'208";a="9837422"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 25 Jan 2008 12:49:35 -0800
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0PKnZXY024665; Fri, 25 Jan 2008 12:49:35 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0PKnL3h029131; Fri, 25 Jan 2008 20:49:34 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jan 2008 12:49:33 -0800
Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jan 2008 12:49:33 -0800
Message-ID: <479A4B4D.2090905@cisco.com>
Date: Fri, 25 Jan 2008 15:49:17 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: "Elwell, John" <john.elwell@siemens.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> <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 <"C A9998CD 4A02 0D41 8654FCDEF4E7 07DF04173AE9"@esealmw113.eemea.ericsson.se> <0D5F89FAC29E2C41B98A6A762007F5D0593C68@GBNTHT12009MSX.gb002.siemens.net> A <CA9998CD4A020D418654FCDEF4E707DF04173CB8@esealmw113.eemea.ericsson.se> <0D5F89FAC29E2C41B98A6A762007F5D0593CFF@GBNTHT12009MSX.gb002.siemens.net>
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0593CFF@GBNTHT12009MSX.gb002.siemens.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 25 Jan 2008 20:49:33.0284 (UTC) FILETIME=[C9F00240:01C85F93]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9265; t=1201294175; x=1202158175; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20<jdrosen@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; bh=DqxbGjoqZoPizHnCfJAILKQ9gb1XmiKlSjDs2POQAcI=; b=WvgLWWra/k9s4hrnHfbWNX1U6imI4No4v11x3xt6mfGm/SkhWu+lYj8M/T 2pqonPHMABbBvO2UvjbByUqO4yaGhKzicRLXCo7UQMdXwXW8twb3M9cSlV7Q 2IcdZ2i+vKI1wIK5i1X1GaAAIdjLr/B7bSaNqRTUbpB0N2XYgwwS4=;
Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8
Cc: sip@ietf.org, Paul Kyzivat <pkyzivat@cisco.com>, "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>, Francois Audet <audet@nortel.com>, Christer Holmberg <christer.holmberg@ericsson.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
Sorry for jumping in late here. Trying to clarify some points here and there. The UA-loose mechanism needs to know that the entity which would have previously been reached by the DNS/IP forwarding based on the R-URI, is now prepared for a request which reaches it with that target in the Route header field. In the case of a UA registering through a chain of Path-inserting proxies, it means that only the *UA* has to support UA-loose route. Thats because of the assumption that the intermediate path-inserting proxies weren't being targeted based on the R-URI previously; they were (and still will) forward the request based on Route. The 'next hop' use case that Christer is referring to are cases where we would have done a R-URI translation without a registration. For example, lets say a proxy receives an INVITE with sip:12345@proxy.com, and its using some number-prefix based routing rules, which have been CONFIGURED into the proxy, to determine a next-hop gateway. The UA loose route rules would say that, since this is a routing operation and not a retargeting, the request looks like: INVITE sip:12345@proxy.com Route: sip:ip-of-gateway whereas current rules would require: INVITE sip:12345@ip-of-gateway in this use case, the entity which was previously being reached by the R-URI *is* the next hop. And so, the main limitation that I see of the UA loose route mechanism is, in cases where the next-hop is being reached via a configured routing rule, or by some other non-registration means, and said operation is a re-route and not retarget, the UA_loose-route requires that this configured routing rule include information about whether the next hop uses UA loose routing, and if so, what URI to use in the Route header. This is a limitation, I agree. Whether its significant or not is debatable. I will note that, it is possible to separate these concerns. We could define UA loose route to strictly be used for the registration cases, since that is the specific problem at hand. I agree CHrister's mechanism does not have this configuration limitation, and that this aspect of it is better. My main beef, as others have commented, is that it leaves us with nearly half-dozen header fields which are all awfully similar (To, P-C-ID, Route, History-Info, and now Target). I was hoping to reduce the set and include only the minimum. In that way, I think UA loose route is architecturally better since it gives some clarity to this. -Jonathan R. Elwell, John wrote: > Christer, > > I don't think the entity using the mechanism needs to know about next > hop support for the loose route mechanism - only whether the UAS > supports it. If the UA registers, then the loose route draft provides an > automatic mechanism. If the UA does not register, support would need to > be indicated by provisioning. I am not sure this ranks as a significant > limitation, since a certain amount of provisioning needs to be done > anyway for UAs such as gateways that do not register. > > John > >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: 16 January 2008 11:51 >> To: Elwell, John; sip@ietf.org >> Cc: Paul Kyzivat; DRAGE,Keith (Keith); Francois Audet >> Subject: RE: [Sip] RE: Delivering request-URI and parameters >> to UAS via proxy -new version of the >> draft-holmberg-sip-target-uri-delivery draft >> >> >> 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. >> >> 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 > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ 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] Delivering request-URI and parameters to UA… DRAGE, Keith (Keith)
- VS: [Sip] Delivering request-URI and parameters t… Christer Holmberg
- Re: VS: [Sip] Delivering request-URI and paramete… Jonathan Rosenberg
- VS: VS: [Sip] Delivering request-URI and paramete… Christer Holmberg
- [Sip] RE: Delivering request-URI and parameters t… DRAGE, Keith (Keith)
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- Re: [Sip] RE: Delivering request-URI and paramete… Paul Kyzivat
- RE: [Sip] RE: Delivering request-URI and paramete… Elwell, John
- RE: [Sip] RE: Delivering request-URI and paramete… Francois Audet
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- Re: [Sip] RE: Delivering request-URI and paramete… Paul Kyzivat
- RE: [Sip] RE: Delivering request-URI and paramete… Francois Audet
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- [Sip] Delivering request-URI and parameters to UA… DRAGE, Keith (Keith)
- RE: [Sip] RE: Delivering request-URI and paramete… Francois Audet
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- RE: [Sip] RE: Delivering request-URI and paramete… Elwell, John
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- RE: [Sip] RE: Delivering request-URI and paramete… Elwell, John
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- Re: [Sip] RE: Delivering request-URI and paramete… Paul Kyzivat
- RE: [Sip] RE: Delivering request-URI and paramete… Francois Audet
- Re: [Sip] RE: Delivering request-URI and paramete… Jeroen van Bemmel
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- [Sip] Delivering request-URI and parameters to UA… Christer Holmberg
- [Sip] RE: Delivering request-URI and parameters t… Elwell, John
- [Sip] RE: Delivering request-URI and parameters t… Christer Holmberg
- RE: [Sip] RE: Delivering request-URI and paramete… Elwell, John
- RE: [Sip] Delivering request-URI and parameters t… DRAGE, Keith (Keith)
- RE: [Sip] Delivering request-URI and parameters t… Christer Holmberg
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- Re: [Sip] RE: Delivering request-URI and paramete… Paul Kyzivat
- [Sip] SIP Routers kamalakar.mergu
- RE: [Sip] RE: Delivering request-URI and paramete… Elwell, John
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- RE: [Sip] Delivering request-URI and parameters t… youssef.chadli
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- Re: [Sip] RE: Delivering request-URI and paramete… Joel M. Halpern
- Re: [Sip] Delivering request-URI and parameters t… Enrico Marocco
- Re: [Sip] SIP Routers James M. Polk
- RE: [Sip] RE: Delivering request-URI and paramete… Elwell, John
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- RE: [Sip] RE: Delivering request-URI and paramete… Elwell, John
- [Sip] Vocabulary and problem statement for Reques… Dean Willis
- Re: [Sip] Vocabulary and problem statement for Re… Dean Willis
- RE: [Sip] Vocabulary and problem statement for Re… DRAGE, Keith (Keith)
- RE: [Sip] Vocabulary and problem statement for Re… Hadriel Kaplan
- RE: [Sip] Vocabulary and problem statement for Re… Hadriel Kaplan
- Re: [Sip] Vocabulary and problem statement for Re… Dean Willis
- RE: [Sip] Vocabulary and problem statement for Re… Sanjay Sinha (sanjsinh)
- RE: [Sip] Vocabulary and problem statement for Re… Hadriel Kaplan
- Re: [Sip] Vocabulary and problem statement for Re… Dean Willis
- Re: [Sip] Vocabulary and problem statement for Re… Jeroen van Bemmel
- RE: [Sip] Vocabulary and problem statement for Re… Elwell, John
- Re: [Sip] Vocabulary and problem statement for Re… Paul Kyzivat
- RE: [Sip] Vocabulary and problem statement for Re… Hadriel Kaplan
- RE: [Sip] Vocabulary and problem statement forReq… Elwell, John
- RE: [Sip] Vocabulary and problem statement forReq… Hadriel Kaplan
- Re: [Sip] Vocabulary and problem statement forReq… Paul Kyzivat
- RE: [Sip] Vocabulary and problem statement forReq… Elwell, John
- RE: [Sip] Vocabulary and problem statementforRequ… Elwell, John
- Re: [Sip] Vocabulary and problem statement forReq… Paul Kyzivat
- RE: [Sip] Vocabulary and problem statementforRequ… Christer Holmberg
- Re: [Sip] RE: Delivering request-URI and paramete… Jonathan Rosenberg
- RE: [Sip] Delivering request-URI and parameters t… youssef.chadli
- Re: [Sip] Delivering request-URI and parameters t… Paul Kyzivat
- RE: [Sip] Delivering request-URI and parameters t… youssef.chadli
- RE: [Sip] RE: Delivering request-URI and paramete… Christer Holmberg
- Re: [Sip] Delivering request-URI and parameters t… Paul Kyzivat
- Re: [Sip] Delivering request-URI and parameters t… Hans Erik van Elburg