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

Paul Kyzivat <pkyzivat@cisco.com> Fri, 18 January 2008 14:51 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 1JFsZA-0004di-Gb; Fri, 18 Jan 2008 09:51:32 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFsZ8-0004WJ-7r for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 09:51:30 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFsZ7-0004Vi-Qi for sip@ietf.org; Fri, 18 Jan 2008 09:51:29 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFsZ7-0005N5-5u for sip@ietf.org; Fri, 18 Jan 2008 09:51:29 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 Jan 2008 09:51:29 -0500
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0IEpSWM031230; Fri, 18 Jan 2008 09:51:28 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0IEp7ui015460; Fri, 18 Jan 2008 14:51:24 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 09:51:14 -0500
Received: from [161.44.174.133] ([161.44.174.133]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 09:51:13 -0500
Message-ID: <4790BCE5.7060603@cisco.com>
Date: Fri, 18 Jan 2008 09:51:17 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Hadriel Kaplan <HKaplan@acmepacket.com>
Subject: Re: [Sip] Questions on draft-rosenberg-sip-ua-loose-route-01.txt
References: <E6C2E8958BA59A4FB960963D475F7AC306E4ED4733@mail.acmepacket.com>
In-Reply-To: <E6C2E8958BA59A4FB960963D475F7AC306E4ED4733@mail.acmepacket.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 Jan 2008 14:51:13.0835 (UTC) FILETIME=[92602FB0:01C859E1]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4143; t=1200667888; x=1201531888; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com> |Subject:=20Re=3A=20[Sip]=20Questions=20on=20draft-rosenber g-sip-ua-loose-route-01.txt |Sender:=20 |To:=20Hadriel=20Kaplan=20<HKaplan@acmepacket.com>; bh=/fQeaXHrag6aWVvZoDsHWYqUg7OSjNXaQlqn/acjeUM=; b=e9dbg0SsamPACzJoz+JG5hfaKsOUtBTVg8aGAvfqDXu1sXryAFrbgCUX3g BD0oK9407d235N33zfnwzGdjbgQd92vc0py52AyakH5kJ3tZOKvPpJ9Eq1Ns +/WsLbODKG;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc: IETF SIP List <sip@ietf.org>
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

I've been busy so I have been only loosely following this discussion.

Hadriel Kaplan wrote:
> 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?

Given dean's terminology the above statement seems a little imprecise. 
It puts things in only two buckets, not the three or more that Dean 
proposes. I think that impacts the following.

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

The above is also less than precise.

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

There is a problem here one way or another. A PSTN GW *is* a UA. And if 
the address is a phone number, then it *can* claim identity to it.

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

I see URNs as much like phone numbers, in that they aren't associated 
with domains. There semantics are intended to be known publicly, and 
there may be many different UAs that can claim to be responsible for 
them. In normal emergency processing, the receiving UA *should* be able 
to claim identity for that URN.

Of course there are technical problems for both phone numbers and URNs 
in that we don't know how to apply sip identity to them.

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

I think it is debatable whether a VM or IVR system can claim identity 
for the r-uri. It depends on the deployment and the policies of the 
owner of that URI.

(If I have a phone in my home, listed as belonging to me, and I attach 
an answering machine to it, that answering machine gets to assert my 
identity as much as I do. If I contract with a SP to provide my 
answering services, it can still claim my identity if I want to allow it 
to do so.

Its the same with a human secretary. I can give a secretary an extension 
on my own AOR, in which case its possible to claim my identity, or I can 
program my proxy to retarget to the secretary, in which case the 
identity is different.)

	Paul

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


_______________________________________________
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