[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 11:05 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 1JF65i-0005xy-A0; Wed, 16 Jan 2008 06:05:54 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JF65h-0005xs-3b for sip-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 06:05:53 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF65g-0005xk-Mu for sip@ietf.org; Wed, 16 Jan 2008 06:05:52 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF65e-0002d9-GO for sip@ietf.org; Wed, 16 Jan 2008 06:05:52 -0500
Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C90E820A2E; Wed, 16 Jan 2008 12:05:49 +0100 (CET)
X-AuditID: c1b4fb3c-ae794bb0000030cf-30-478de50d1741
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9DE252076F; Wed, 16 Jan 2008 12:05:49 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 12:05:49 +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
Date: Wed, 16 Jan 2008 12:05:48 +0100
Message-ID: <CA9998CD4A020D418654FCDEF4E707DF04173AE9@esealmw113.eemea.ericsson.se>
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0593C0E@GBNTHT12009MSX.gb002.siemens.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Delivering request-URI and parameters to UAS via proxy - new version of the draft-holmberg-sip-target-uri-delivery draft
Thread-Index: AchXnY+F82ywc0SeQiGSlvvV9WnM7QAZ7COQAAVV9CAAASbeoAAD/kcg
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> A <CA9998CD4A020D418654FCDEF4E707DF0413D6C2@esealmw113.eemea.ericsson.s e> <0D5F 89FAC29E2C41B98A6A762007F5D0593C0E@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 11:05:49.0417 (UTC) FILETIME=[C05E4590:01C8582F]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
Cc: Paul Kyzivat <pkyzivat@cisco.com>, "DRAGE, Keith \(Keith\)" <drage@alcatel-lucent.com>, Francois Audet <audet@nortel.com>
Subject: [Sip] RE: Delivering request-URI and parameters to UAS via proxy - new version of the draft-holmberg-sip-target-uri-delivery draft
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

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