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

"Elwell, John" <john.elwell@siemens.com> Thu, 17 January 2008 07: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 1JFPeQ-0001wO-Db; Thu, 17 Jan 2008 02:59:02 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFPeO-0001wH-CQ for sip-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 02:59:00 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFPeN-0001w5-St for sip@ietf.org; Thu, 17 Jan 2008 02:58:59 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFPeM-0004z9-Om for sip@ietf.org; Thu, 17 Jan 2008 02:58:59 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JUS00C043I7F0@siemenscomms.co.uk> for sip@ietf.org; Thu, 17 Jan 2008 07:58:55 +0000 (GMT)
Date: Thu, 17 Jan 2008 07:58:54 +0000
From: "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
In-reply-to: A <CA9998CD4A020D418654FCDEF4E707DF041743D6@esealmw113.eemea.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>, sip@ietf.org
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0593E13@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: quoted-printable
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+kAAEi6eAAABgSrAAJYH44A==
Content-class: urn:content-classes:message
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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> <"0D5F89FA C29E2C41B98A6A762007F5D0593C68"@GBNTHT12009MSX.gb002.siemens.net> A <CA9998CD4A020D418654FCDEF4E707DF04173CB8@esealmw113.eemea.ericsson.se> <0D5F89FAC29E2C41B98A6A762007F5D0593CFF@GBNTHT12009MSX.gb002.siemens.net> A <CA9998CD4A020D418654FCDEF4E707DF041743D6@esealmw113.eemea.ericsson.se>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b
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

Christer,

We still seem to have a disconnect in our understanding. See below.

John 

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] 
> Sent: 16 January 2008 14:32
> 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
> 
> 
> 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.
[JRE] The Service Invocation section in loose-route tells me nothing
about proxies on the path. It simply talks about invocation of a service
at the UAS.

> 
> 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.
[JRE] Surely it is only the home proxy that takes an AoR and determines
a contact URI to route to. Maybe my understanding of home proxy is
different.

> 
> 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 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