[Sip] Questions on draft-rosenberg-sip-ua-loose-route-01.txt

Hadriel Kaplan <HKaplan@acmepacket.com> Fri, 18 January 2008 05:04 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 1JFjOu-0004zu-Fi; Fri, 18 Jan 2008 00:04:20 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFjOt-0004zf-B1 for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 00:04:19 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFjOs-0004zU-W8 for sip@ietf.org; Fri, 18 Jan 2008 00:04:19 -0500
Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFjOs-000785-JW for sip@ietf.org; Fri, 18 Jan 2008 00:04:18 -0500
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 18 Jan 2008 00:04:14 -0500
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 18 Jan 2008 00:04:11 -0500
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Jonathan Rosenberg <jdrosen@cisco.com>
Date: Fri, 18 Jan 2008 00:01:23 -0500
Thread-Topic: Questions on draft-rosenberg-sip-ua-loose-route-01.txt
Thread-Index: AchZjyv6dvLVMVd5SbqtJg2n4wglvQ==
Message-ID: <E6C2E8958BA59A4FB960963D475F7AC306E4ED4733@mail.acmepacket.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: IETF SIP List <sip@ietf.org>
Subject: [Sip] Questions on draft-rosenberg-sip-ua-loose-route-01.txt
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

If I read the draft correctly, the proposed solution is that rerouting action leaves the req-uri alone, and pushes a Route for the resolved target's URI (contact/whatever).  Whereas a retargeting action replaces the req-uri with the new target, and possibly pushes the previous req-uri into History-Info.  The draft proposes retargeting be defined as when the proxy determines the new target could not claim the previous req-uri as its Identity.  In other words, if the new target were to originate a request using the previous req-uri as its From addr-spec, would its domain sign it using rfc4474 - if so then it's a reroute, if not then it's a retarget.  Correct?

The draft also describes several cases, some of which don't seem to follow the above rules.

For example, Section 5 example 3 says:
   3.  When a proxy receiving a request identifies a next hop server
       that is needed to process the request, that next hop server is a
       route.  A next hop server is not a UA and would never be able to
       claim its identity.  Its URI is pushed into a Route header field
       and the Request-URI is retained.  An important use case for this
       are proxies that select PSTN gateways for call egress to the
       PSTN.  Such selection would place the SIP URI of the gateway into
       the topmost Route header field value and retain the Request-URI.

So this says a PSTN gateway could not claim the identity, yet the behavior is still rerouting?

Another example of this is in Section 2.6 for Emergency Numbers.  It states the SOS URN needs to stay in place in the req-uri all the way to the call-taker.  I'm not sure if such a call-taker could claim Identity to an SOS URN, and furthermore the odds are the call-taker is in another domain, which per this draft would constitute a retargeting and change the req-uri.  No?

This draft should also describe what happens for service invocation, which is a stated problem space in section 2.5.  Again, a voicemail system or IVR or App Server could not claim Identity for the req-uri, and thus it would be a retarget per the draft's definition.

-hadriel


_______________________________________________
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