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> Wed, 16 January 2008 11:19 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 1JF6Iu-0004IJ-0V; Wed, 16 Jan 2008 06:19:32 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JF6Ir-0004Be-Va for sip-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 06:19:30 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF6Ir-0004BS-ID for sip@ietf.org; Wed, 16 Jan 2008 06:19:29 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF6Ip-0002su-LH for sip@ietf.org; Wed, 16 Jan 2008 06:19:29 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JUQ00783I4EKU@siemenscomms.co.uk> for sip@ietf.org; Wed, 16 Jan 2008 11:19:26 +0000 (GMT)
Date: Wed, 16 Jan 2008 11:19:25 +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 <CA9998CD4A020D418654FCDEF4E707DF04173AE9@esealmw113.eemea.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>, sip@ietf.org
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0593C68@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/kcgAACRbVA=
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> <"0D5F 89FAC29E2C41B98A6A762007F5D0593C0E"@GBNTHT12009MSX.gb002.siemens.net> A <CA9998CD4A020D418654FCDEF4E707DF04173AE9@esealmw113.eemea.ericsson.se>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196
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,

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.

John 

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