RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy -new version of the draft-holmberg-sip-target-uri-delivery draft
"Christer Holmberg" <christer.holmberg@ericsson.com> Wed, 16 January 2008 14:32 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 1JF9Jx-0006He-M3; Wed, 16 Jan 2008 09:32:49 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JF9Jw-0006Dc-Ha for sip-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 09:32:48 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF9Jw-0006DU-50 for sip@ietf.org; Wed, 16 Jan 2008 09:32:48 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF9Jv-0004ml-06 for sip@ietf.org; Wed, 16 Jan 2008 09:32:48 -0500
Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9F8642103C; Wed, 16 Jan 2008 15:32:11 +0100 (CET)
X-AuditID: c1b4fb3c-b0798bb0000030cf-21-478e156b905c
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6594C208AD; Wed, 16 Jan 2008 15:32:11 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 15:32:11 +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 -new version of the draft-holmberg-sip-target-uri-delivery draft
Date: Wed, 16 Jan 2008 15:32:10 +0100
Message-ID: <CA9998CD4A020D418654FCDEF4E707DF041743D6@esealmw113.eemea.ericsson.se>
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0593CFF@GBNTHT12009MSX.gb002.siemens.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy -new version of the draft-holmberg-sip-target-uri-delivery draft
Thread-Index: AchXnY+F82ywc0SeQiGSlvvV9WnM7QAZ7COQAAVV9CAAASbeoAAD/kcgAACRbVAAALp+kAAEi6eAAABgSrA=
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> <CA9998CD4A020D418654FCDEF4E707DF0413D587@esealmw113.eemea.ericsson.se> <0D5F89FAC29E2C41B98A6A762007F5D0593C0E@GBNTHT12009MSX.gb002.siemens.ne t> A <"C A9998CD 4A0 2 0D41 8654FCDEF4E7 07DF04173AE9"@esealmw113.eemea.ericsson.se> <0D5F89FAC29E2C41B98A6A762007F5D0593C68@GBNTHT12009MSX.gb002.siemens.net> A <CA9998CD4A020D418654FCDEF4E707DF04173CB8@esealmw113.eemea.ericsson.se> <0D5F89FAC29E2C41B98A6A762007F5D0593CFF@GBNTHT12009MSX.gb002.siemens.net>
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "Elwell, John" <john.elwell@siemens.com>, sip@ietf.org
X-OriginalArrivalTime: 16 Jan 2008 14:32:11.0256 (UTC) FILETIME=[9484F780:01C8584C]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e367d58950869b6582535ddf5a673488
Cc: Paul Kyzivat <pkyzivat@cisco.com>, "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>, Francois Audet <audet@nortel.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
John, According to the UA-loose-route draft, every proxy in the path need to support the mechanism in order for the "current target" to be retained in the R-URI. A good example is the "Service Invocation" use case in the UA loose route draft. Maybe the "loose route" wording is confusing (I think it is also mentioned in the UA-loose-route draft that a better naming may be needed)? Also, maybe one can assume that a home proxy knows what entities not registering (MGCs etc) support. But, again, we are not only talking about home proxies. Regards, Christer > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: 16. tammikuuta 2008 15:53 > To: Christer Holmberg; 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 > > 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
- [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