Re: [sipcore] #8: It's not clear when a Proxy should/should-not add H-I for "internal" stuff

"Worley, Dale R (Dale)" <dworley@avaya.com> Thu, 02 September 2010 21:12 UTC

Return-Path: <dworley@avaya.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF7AD3A6AA1 for <sipcore@core3.amsl.com>; Thu, 2 Sep 2010 14:12:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.44
X-Spam-Level:
X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Cuyn31u-kZt for <sipcore@core3.amsl.com>; Thu, 2 Sep 2010 14:11:47 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 60DD43A6918 for <sipcore@ietf.org>; Thu, 2 Sep 2010 14:10:45 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.56,310,1280721600"; d="scan'208";a="236044464"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 02 Sep 2010 17:11:14 -0400
X-IronPort-AV: E=Sophos;i="4.56,310,1280721600"; d="scan'208";a="511672642"
Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Sep 2010 17:11:14 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.129]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Thu, 2 Sep 2010 17:11:14 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
Date: Thu, 02 Sep 2010 17:11:14 -0400
Thread-Topic: [sipcore] #8: It's not clear when a Proxy should/should-not add H-I for "internal" stuff
Thread-Index: ActK30vtPLHLxe3CT4yO0nwhSVENXAAAkA4i
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B21FFC79C12@DC-US1MBEX4.global.avaya.com>
References: <064.2fac1c1d9b3ab9e13c8bc32cb433819f@tools.ietf.org>, <C09A3F8C-B220-4FB5-BE45-A0D85C012AE0@ntt-at.com> <CD5674C3CD99574EBA7432465FC13C1B21FFC79C0C@DC-US1MBEX4.global.avaya.com>, <A64D74A5-304F-4CE2-B790-B75D56D2A7DE@acmepacket.com>
In-Reply-To: <A64D74A5-304F-4CE2-B790-B75D56D2A7DE@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
Cc: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] #8: It's not clear when a Proxy should/should-not add H-I for "internal" stuff
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Sep 2010 21:12:32 -0000

________________________________________
From: Hadriel Kaplan [HKaplan@acmepacket.com]

But they're NOT "Request-URIs".  Not yet.  They're abstract target URIs during the internal local policy stages of routing, until such point as the request gets forwarded.  They're just memory blocks in a system, getting munged based on transformation rules, lookup tables, or possibly non-SIP database queries.

For example, a common routing local policy procedure of originating proxies in North America is to perform the following for received request-URIs identified as phone numbers:
1) Normalize the number by removing visual separators, and possibly transform the number to an E.164, by adding a country-code, area-code, leading-plus, etc.
2) Do a number portability dip for the called number.  That changes the target URI to include a 'npdi' and possibly 'rn' param info.
3) Determine whether the portability-corrected target is local or out of region, or if it's out of the local domain altogether (and to which peer).  That can change the target again, for example by changing the domain name, adding trunk-group info, etc.
4) Change the Request-URI to be the new target.
________________________________________

Hmmm....  In the sipX architecture, each of those steps would be done separately, by the proxy sending the request to a redirect server which would return a 302.  So yes, each stage of processing would be represented by a separate hi-entry.

But I see your point, What if a proxy does it all internally?

I'd like to say that it can write hi-entry's *as if* each step was described separately by a 302 from a redirect server.  Or alternatively, as if the request had a series of passes through proxies that performed each step.  Those alternatives would lead to History-Info somewhat like these (where I've changed the use of the tags a bit):

History-Info:
	<sip:5556666@carrier1.com>;index=1,
	<sip:+16175556666@carrier1.com>;index=1.1,
	<sip:+15552340000@carrier1.com;npdi>;index=1.1.1,
	<sip:+15552340000@carrier1.com;npdi>;index=1.1.1.1,
	<sip:+15552340000@carrier2.com;npdi>;index=1.1.1.1.1

History-Info:
	<sip:5556666@carrier1.com>;index=1,
	<sip:+16175556666@carrier1.com>;index=1.1,
	<sip:+15552340000@carrier1.com;npdi>;index=1.2;from=1.1,
	<sip:+15552340000@carrier1.com;npdi>;index=1.3;from=1.2,
	<sip:+15552340000@carrier2.com;npdi>;index=1.4;from=1.3

In general, the recipient of a request containing such a faked H-I wouldn't be able to tell that it had been faked.  However, it would be desirable to have text to explicitly approve such behavior.

Going back to the text of the document, I see how I became misled.  The text in section 5.1 is:

   Retargeting is an iterative process, i.e., a proxy may redirect
   "internally " more than one time.  A typical example would be a proxy
   that redirects a request first to a different user (i.e., it maps to
   a different AOR), and then forwards to a registered contact bound to
   that new AOR.  A proxy that uses such mechanism SHOULD add multiple
   hi-entry fields (e.g., bob@example.com to office@example.com to
   office@192.0.2.5) to provide a logical description of the retargeting
   process.  A Reason MAY be associated with the hi-targeted-to-uri that
   has been retargeted as shown in the example in Appendix B.1.

Given that the word "internally" is not defined in any way, and that the example described would be implemented in sipX through multiple redirect server requests, I did not realize that the process described was performed entirely within one SIP element.  This suggests that the text could stand to be improved.

Dale