[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-rosenberg-sip-target-uri-delivery) 00

SIPCORE                                                     J. Rosenberg
Internet-Draft                                                     Cisco
Intended status: Standards Track                           J. van Elburg
Expires: December 11, 2009                                   C. Holmberg
                                                                Ericsson
                                                             F. Francois
                                                                  Nortel
                                                       S. Schubert (Ed.)
                                                                     NTT
                                                            June 9, 2009


             Delivery of Request-URI Targets to User Agents
             draft-rosenberg-sipcore-target-uri-delivery-00

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 11, 2009.




Rosenberg, et al.       Expires December 11, 2009               [Page 1]


Internet-Draft                 Target URI                      June 2009


Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   When a Session Initiation Protocol (SIP) proxy receives a request
   targeted at a URI identifying a user or resource it is responsible
   for, the proxy translates the URI to a configured URI, or to a
   registered contact URI, of an agent representing that user or
   resource.  In the process, the original URI is removed from the
   request.  Numerous use cases have arisen which require this
   information to be delivered to the user agent.  This document
   describes these use cases and defines an extension to the History-
   Info header field which allows it to be used to support those cases.





























Rosenberg, et al.       Expires December 11, 2009               [Page 2]


Internet-Draft                 Target URI                      June 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  mapping translation  . . . . . . . . . . . . . . . . . . .  4
     3.2.  routing translation  . . . . . . . . . . . . . . . . . . .  5
     3.3.  addressed target . . . . . . . . . . . . . . . . . . . . .  5
     3.4.  address-of-record (AOR)  . . . . . . . . . . . . . . . . .  5
   4.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Unknown Aliases  . . . . . . . . . . . . . . . . . . . . .  5
     4.2.  Unknown GRUU . . . . . . . . . . . . . . . . . . . . . . .  6
     4.3.  Limited Use Addresses  . . . . . . . . . . . . . . . . . .  6
     4.4.  Sub-Addressing . . . . . . . . . . . . . . . . . . . . . .  6
     4.5.  Service Invocation . . . . . . . . . . . . . . . . . . . .  7
     4.6.  Toll Free Numbers  . . . . . . . . . . . . . . . . . . . .  8
   5.  Architectural Roots of the Problem . . . . . . . . . . . . . .  8
   6.  Solution Overview  . . . . . . . . . . . . . . . . . . . . . . 10
   7.  Detailed Semantics . . . . . . . . . . . . . . . . . . . . . . 12
     7.1.  Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 13
     7.2.  UA Behavior  . . . . . . . . . . . . . . . . . . . . . . . 14
       7.2.1.  Determining the addressed target . . . . . . . . . . . 14
       7.2.2.  Determining the last AOR used to reach it  . . . . . . 14
   8.  The difference to P-Called-Party-Id  . . . . . . . . . . . . . 15
   9.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
     11.2. Informative References . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17





















Rosenberg, et al.       Expires December 11, 2009               [Page 3]


Internet-Draft                 Target URI                      June 2009


1.  Introduction

   A key part of the behavior of proxy servers and B2BUA in the Session
   Initiation Protocol (SIP) [RFC3261] is that they rewrite the Request-
   URI of requests as the request moves from the User Agent Client (UAC)
   to the User Agent Server (UAS).  This is particularly true for
   requests outside of a dialog; requests within a dialog have their
   path dictated primarily by the Route header fields established by the
   Record-Routes when the dialog was initiated.

   The most basic instance of this behavior is the processing executed
   by the "home proxy" within a domain.  The home proxy is the proxy
   server within a domain which accesses the location information
   typically generated by REGISTER messages, and uses it to forward a
   request towards a UA.  Based on the rules in [RFC3261], when a home
   proxy receives a SIP request, it looks up the Request-URI in the
   location database or mapping table, and translates it to configured
   URI(s), or to registered contact(s).  This new contact URI replaces
   the existing Request URI, and causes the request to be forwarded
   towards the target UA.  Consequently, the original contents of the
   Request URI are lost.

   Over the years, this practice of rewriting the Request-URI has proven
   problematic.  Section 4 describes the problems with this mechanism.
   Section 5 analyzes the architectural issues which drive these
   problems.  Section 6 overviews a mechanism to solve this problem by
   extending the History-Info header field.  Section 7 describes
   detailed procedures for user agents and proxies.


2.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


3.  Definitions

3.1.  mapping translation

   A Request-URI rewrite operation is considered to be a mapping
   translation if the name or address of a user or resource is
   translated to a name or address belonging to a different user or
   resource.






Rosenberg, et al.       Expires December 11, 2009               [Page 4]


Internet-Draft                 Target URI                      June 2009


3.2.  routing translation

   A Request-URI rewrite operation is considered to be a routing
   translation if the name or address of a user or resource is
   translated to an address that is a hop for reaching that user.

3.3.  addressed target

   The addressed target is the address or name that was used by the
   initiator of an initial request, except when it is changed by one or
   more mapping translations.  As by definition mapping translations
   change the addressed target.

3.4.  address-of-record (AOR)

   See [RFC3261].


4.  Problem Statement

   Several problems arise from the practice of rewriting the request
   URI.

4.1.  Unknown Aliases

   SIP user agents are associated with an address-of-record (AOR).  It
   is possible for a single UA to actually have multiple AOR associated
   with it.  One common usage for this is aliases.  For example, a user
   might have an AOR of sip:john@example.com but also have the AORs
   sip:john.smith@example.com and sip:jsmith@example.com.  Rather than
   registering against each of these AORs individually, the user would
   register against just one of them, and the home proxy would
   automatically accept incoming calls for any of the aliases, treating
   them identically and ultimately forwarding them towards the UA.  This
   is common practice in the Internet Multimedia Subsystem (IMS), where
   it is called implicit registrations and each alias is called a public
   identity.

   It is a common requirement for a UAS, on receipt of a call, to know
   which of its aliases was used to reach it.  This knowledge can be
   used to choose ringtones to play, determine call treatment, and so
   on.  For example, a user might give out one alias to friends and
   family only, resulting in a special ring that alerts the user to the
   importance of the call.

   However, based on the procedures in [RFC3261], when an incoming call
   hits the home proxy, the request URI (which contains the alias) is
   rewritten to the registered contact(s).  Consequently, the alias that



Rosenberg, et al.       Expires December 11, 2009               [Page 5]


Internet-Draft                 Target URI                      June 2009


   was used is lost, and cannot be known to the UAS.

4.2.  Unknown GRUU

   A variation on the problem in Section 4.1 occurs with Globally
   Routable User Agent URI (GRUU) [I-D.ietf-sip-gruu].  A GRUU is a URI
   assigned to a UA instance which has many of the same properties as
   the AOR, but causes requests to be routed only to that specific
   instance.  It is desirable for a UA to know whether it was reached
   because a correspondent sent a request to its GRUU or to its AOR.
   This can be used to drive differing authorization policies on whether
   the request should be accepted or rejected, for example.  However,
   like the AOR itself, the GRUU is lost in translation at the home
   proxy.  Thus, the UAS cannot know whether it was contacted via the
   GRUU or its AOR.

4.3.  Limited Use Addresses

   A limited use address is a SIP URI that is minted on-demand, and
   passed out to a small number (usually one) remote correspondent.
   Incoming calls targeted to that limited use address are accepted as
   long as the UA still desires communications from the remote target.
   Should they no longer wish to be bothered by that remote
   correspondent, the URI is invalidated so that future requests
   targeted to it are rejected.

   Limited use addresses are used in battling voice spam [RFC5039].  The
   easiest way to provide them would be for a UA to be able to take its
   AOR, and "mint" a limited use address by appending additional
   parameters to the URI.  It could then give out the URI to a
   particular correspondent, and remember that URI locally.  When an
   incoming call arrives, the UAS would examine the parameter in the URI
   and determine whether or not the call should be accepted.
   Alternatively, the UA could push authorization rules into the
   network, so that it need not even see incoming requests that are to
   be rejected.

   This approach, especially when executed on the UA, requires that
   parameters attached to the AOR, but not used by the home proxy in
   processing the request, will survive the translation at the home
   proxy and be presented to the UA.  This will not be the case with the
   logic in RFC 3261, since the Request-URI is replaced by the
   registered contact, and any such parameters are lost.

4.4.  Sub-Addressing

   Sub-Addressing is very similar to limited use addresses.  Sub-
   addresses are addresses within a subdomain that are multiplexed into



Rosenberg, et al.       Expires December 11, 2009               [Page 6]


Internet-Draft                 Target URI                      June 2009


   a single address within a parent domain.  The concept is best
   illustrated by example.  Consider a VoIP service provided to
   consumers.  A consumer obtains a single address from its provider,
   say sip:family@example.com.  However, Joe is the patriarch of a
   family with four members, and would like to be able to have a
   separate identifier for each member of his family.  One way to do
   that, without requiring Joe to purchase new addresses for each member
   from the provider, is for Joe to mint additional URI by adding a
   parameter to the AOR.  For example, his wife Judy with have the URI
   sip:family@example.com;member=judy, and Joe himself would have the
   URI sip:family@example.com;member=joe.  The SIP server provider would
   receive requests to these URI, and ignoring the unknown parameters
   (as required by [RFC3261]) route the request to the registered
   contact, which corresponds to a SIP server in Joes home.  That
   server, in turn, can examine the URI parameters and determine which
   phone in the home to route the call to.

   This feature is not specific to VoIP, and has existing in Integrated
   Services Digital Networking (ISDN) for some time.  It is particularly
   useful for small enterprises, in addition to families.  It is also
   similar in spirit (though not mechanism) to the ubiquitous home
   routers used by consumers, which allow multiple computers in the home
   to "hide" behind the single IP address provided by the service
   provider, by using the TCP and UDP port as a sub-address.

   The sub-addressing feature is not currently feasible in SIP because
   of the fact that any SIP URI parameter used to convey the sub-address
   would be lost at the home proxy, due to the fact that the Request-URI
   is rewritten there.

4.5.  Service Invocation

   Several SIP specifications have been developed which make use of
   complex URIs to address services within the network rather than
   subscribers.  The URIs are complex because they contain numerous
   parameters that control the behavior of the service.  Examples of
   this include the specification which first introduced the concept,
   [RFC3087], control of network announcements and IVR with SIP URI
   [RFC4240], and control of voicemail access with SIP URI [RFC4458].

   A common problem with all of these mechanisms is that once a proxy
   has decided to rewrite the Request-URI to point to the service, it
   cannot be sure that the Request-URI will not be destroyed by a
   downstream proxy which decides to forward the request in some way,
   and does so by rewriting the Request-URI.






Rosenberg, et al.       Expires December 11, 2009               [Page 7]


Internet-Draft                 Target URI                      June 2009


4.6.  Toll Free Numbers

   Toll free numbers, also known as 800 or 8xx numbers in the United
   States, are telephone numbers that are free for users to call
   (although the author will note that such notions are becoming less
   important as billing models evolve, and harken back to an era where
   phone service depended on global agreement on such billing concepts).

   In the telephone network, toll free numbers are just aliases to
   actual numbers which are used for routing of the call.  In order to
   process the call in the PSTN, a switch will perform a query (using a
   protocol called TCAP), which will return either a phone number or the
   identity of a carrier which can handle the call.

   There has been recent work on allowing such PSTN translation services
   to be accessed by SIP proxy servers through IP querying mechanisms.
   ENUM, for example [RFC3761] has already been proposed as a mechanism
   for performing Local Number Portability (LNP) queries [RFC4769], and
   recently been proposed for performing calling name queries
   [I-D.ietf-enum-cnam].  Using it for 8xx number translations is a
   logical next-step.

   Once such a translation has been performed, the call needs to be
   routed towards the target of the request.  Normally, this would
   happen by selecting a PSTN gateway which is a good route towards the
   translated number.  However, one can imagine all-IP systems where the
   8xx numbers are SIP endpoints on an IP network, in which case the
   translation of the 8xx number would actually be a SIP URI and not a
   phone number.  Assuming for the moment it is a PSTN connected entity,
   the call would be routed towards a PSTN gateway.  Proper treatment of
   the call in the PSTN (and in particular, correct reconciliation of
   billing records) requires that the call be marked with both the
   original 8xx number AND the target number for the call.  However, in
   our example here, since the translation was performed by a SIP proxy
   upstream from the gateway, the original 8xx number would have been
   lost, and the call will not interwork properly with the PSTN.

   Similar problems arise with other "special" numbers and services used
   in the PSTN, such as operator services, pay numbers (9xx numbers in
   the U.S), and short service codes such as 311.


5.  Architectural Roots of the Problem

   There is a common theme across all of the problems in Section 4, and
   this theme is the confounding of names, routes, and addresses.

   A name is a moniker for an entity which refers to it in a way which



Rosenberg, et al.       Expires December 11, 2009               [Page 8]


Internet-Draft                 Target URI                      June 2009


   reveals nothing about where it is in a network.  In SIP, tel URI
   which doesn't represent the location of the entity is a name.  An
   address is an identifier for an entity which describes it by its
   location on the network.  In SIP, the SIP URI itself is a form of
   address because the host part of the URI, the only mandatory part of
   the URI besides the scheme itself, indicates the location of a SIP
   server that can be used to handle the request.  Finally, a route is a
   sequence of SIP entities (including the UA itself!) which are
   traversed in order to forward a request to an address or name.

   SIP, unfortunately, uses the Request-URI as a mechanism for routing
   of the request in addition to using it as the mechanism for
   identifying the name or address to which the request was targeted.  A
   home proxy rewrites the Request-URI because that rewriting is the
   vehicle by which the request is forwarded to the target of the
   request.  However, this rewritten URI (a configured URI or a
   registered contact), is not in any way a meaningful name or address
   for the UA.  Indeed, with specifications like SIP outbound
   [I-D.ietf-sip-outbound], even the IP address within the registered
   contact is meaningless since the flow on which the REGISTER is sent
   is used rather than the IP address.  Consequently, the home proxy is
   fundamentally replacing the *address* in the Request-URI with a
   *route* to reach that UA.  This architectural mistake is the cause of
   the problems described above.

   Interestingly, this same mistake was present in [RFC2543] for the
   handling of mid-dialog requests.  It was fixed through the loose
   routing mechanism in RFC 3261, which used Route header fields to
   identify each hop to visit for a mid-dialog request, and separated
   this from the Request-URI, which identified the ultimate target of
   the request (the remote UA), and remained unmodified in the
   processing of the request.

   Unfortunately, application of this same technique to address the
   problem at hand cannot be done in a backwards compatible manner.
   Consequently, some other means is needed to allow the UAS to deduct
   by which name or address its user has been addressed by an upstream
   entity.

   An address itself has not the inherent property of being an addressed
   target, that depends on the history and nature of Request-URI
   rewrites for a particular call.  For example if a user A calls a user
   B, but the B has a forwarding service active that forwards the call
   to user C, then clearly the Request-URI translation peformed on
   behalf of B affects the addressed target.  On the other hand when a
   user A calls a special address Bservice of user B, where Bservice is
   hosted in a dedicated proxy offering such services and for actual
   delivery of the request forwards the request to address of user B,



Rosenberg, et al.       Expires December 11, 2009               [Page 9]


Internet-Draft                 Target URI                      June 2009


   then clearly the Request-URI translation does not affect the
   addressed target.  To distinguish these type of address translations
   we refer to the first one as a mapping translation and to the second
   one as a routing translation.  For a definition see also the
   Section 3.


6.  Solution Overview

   The History-Info header field, defined in [RFC4244], defines a
   mechanism by which an enumeration of the URIs traversed can be passed
   to both the UAC and UAS.  History-Info was designed to provide a
   general purpose mechanism which can support the needs of many
   applications, including diagnostics and traditional telephony
   features like voicemail.  Were a home proxy to implement History-
   Info, it would provide a means for that proxy to deliver the target
   URI to the UAS.

   Unfortunately, History-Info makes no distinction between hi-entries
   that record a URI that are addressed targets and URIs that are merely
   hops.  Consequently, if there were additional proxies downstream of
   the home proxy which modified the Request-URI in any way, the UA
   would have no way to know which URI in the list of History-Info
   values was actually the addressed target.  To remedy that, this
   document defines extensions to the History-Info header field that
   allows the UAS to extract the addressed target.

   When a home proxy receives a request for a user or resource for which
   is abstract location function returns registered contacts or
   configured URIs, the proxy adds two History-Info header field values.
   The first is the incoming request URI.  Since the Request-URI
   identifies a user or resource for which it has a registration or
   configuration, the Request-URI is an AOR and thus an address for the
   user.  The proxy adds a History-Info header field parameter, "aor",
   which indicates this.  Next, the proxy inserts the contact URI which
   will be contained in the outgoing Request-URI.

   For a UAS to determine the last AOR used to reach it, it need only
   walk backwards through the list of HI values, and take the first one
   containing the "aor" parameter.

   However this is not enough to determine the addressed target as an
   AOR may well be an intermediary routing step in particular scenarios.
   The problem arising from this is that a users service number that is
   forwarded to the users regular AOR would all be tagged "aor".  It
   could for example be used to determine the last AOR before the UAS
   was reached.  (Same semantics as P-Called-Party-ID, [RFC3455]).




Rosenberg, et al.       Expires December 11, 2009              [Page 10]


Internet-Draft                 Target URI                      June 2009


   So additionally to determine the addressed target we need to be able
   to distinguish, which translations (Request URI rewrites) do change
   addressed target and which do not.

   When a proxy receives a request for a user or resource for which it
   is responsible, then when a request URI rewrite occurs that is a
   routing translation, then add a History-Info header field parameter
   "routed" to the hi-entry recording the incoming request URI.
   Otherwise when a request URI rewrite occurs that is a mapping
   translation, then add a History-Info header field parameter "mapped"
   to the hi-entry recording the incoming request URI.  In case a proxy
   does not have knowledge if the nature of the translation being a
   mapping or a routing translation it shall assume a routing
   translation and add a "routed" parameter.

   Combining both mechanisms gives hi-entries with the following
   parameter combinations:

   o  aor, mapped: AOR that was translated (using an abstract location
      service) to an AOR belonging to a different user or resource

   o  aor, routed: AOR that was translated (using an abstract location
      service) to a different AOR or contact address belonging to the
      same user or resource

   o  routed: Request URI was rewritten for routing purposes (including
      strict routing, no-op/loose-routing, maddr)

   For a UAS to determine the addressed target, traverse History-Info
   backward until an entry is found that is marked with the parameters
   "aor, mapped", take the entry after that to represent the actual
   target.  If no such entry is found then take the first hi-entry.

   Example case B diverts to freephone, freephone translates to C, C
   translates to a registered contact would give:


History-Info: <sip:+18005551212@example.com;user=phone>;index=1;aor;mapped
History-Info: <sip:032522@example.com>;index=1.1;aor;routed
History-Info: <sip:Carol@example.com>;index=1.1.1;aor;routed
History-Info: <sip:Carol@192.0.2.2>;index=1.1.1.1

             Figure 1: Determine addressed target URI Example

   Another example, consider the architecture in Figure 2.  In the
   example user A calls user B. User B is in example.com.  The call from
   A to B passes through A's outbound proxy, their home proxy, B's home
   proxy, and B's outbound proxy, prior to reaching B. B's home proxy,



Rosenberg, et al.       Expires December 11, 2009              [Page 11]


Internet-Draft                 Target URI                      June 2009


   H-B, performs the translation of the R-URI to the registered contact
   based on the registration database.  Consequently, it adds two
   History-Info header fields, the first of which represents the
   incoming R-URI and includes the "aor" parameter.


              +-------+    +-------+   +-------+   +-------+
   //--\\     |       |    |       |   |       |   |       |   //--\\
   |  A   |--- | OB-A  |----|  H-A  |---| H-B   |---| OB-B  |--|  B   |
   |      |    |       |    |       |   |       |   |       |  |      |
   \\--//     +-------+    +-------+   +-------+   +-------+   \\--//

       INVITE
       sip:B@example.com
      ------------>
                  INVITE
                  sip:B@example.com
                 ------------>
                              INVITE
                              sip:B@example.com
                             ------------>

                                          INVITE
                                          sip:B@example.com
                              HI: <sip:B@example.com>index=1;aor,routed,
                                   <sip:B@1.2.3.4>;index=1.1
                                         ------------>

                       Figure 2: Target URI Example


7.  Detailed Semantics

   The "aor" parameter in the History-Info header field indicates that
   the URI that it parameterizes was either subject to a lookup in a
   location service created through the registration process of the UA
   or was available through configuration.  Furthermore, if that URI had
   an 'index' of N, the URIs with indices N.M for all M, are registered
   contacts/configured URIs to that URI.

   The "mapped" parameter in the History-Info header field indicates
   that the URI that it parameterizes was subject to a mapping
   translation.

   The "routed" parameter in the History-Info header field indicates
   that the URI that it parameterizes was subject to a routing
   translation.




Rosenberg, et al.       Expires December 11, 2009              [Page 12]


Internet-Draft                 Target URI                      June 2009


7.1.  Proxy Behavior

   A proxy compliant to this specification SHOULD add a History-Info
   header field value to a request under the following conditions:

   o  The proxy is responsible for the domain in the Request-URI

   o  The proxy will be translating the contents of the Request-URI to
      one or more contacts or URIs either based on a location database
      populated through REGISTER requests from user agents or based on
      configurion.

   o  The Request-URI exists in the location database.

   The proxy SHOULD populate the History-Info header field regardless of
   whether there is a Supported header field with value 'histinfo'.  If
   the incoming request already contains a History-Info header field,
   and the last value of that header field is identical to the Request-
   URI of the received request, the proxy MUST add an "aor" attribute to
   that History-Info value.  If the request did not contain a History-
   Info header field, or if it did, but the last value is not identical
   to the Request-URI of the received request, the proxy MUST add
   another History-Info header field value.  The URI MUST be equal to
   the incoming Request-URI, and MUST contain an "aor" attribute.  The
   index is set as defined in [RFC4244].

   Once the proxy has translated the Request-URI into a registered
   contact or configured URI, it SHOULD determine whether the
   translation is a mapping translation or a routing translation.  The
   proxy that is responsible for the domain of the incoming request URI
   is best equipped to make this distinction, either by configured
   policies or by additional support from the abstract location service.
   A Request-URI rewrite operation is considered to be a mapping
   translation if the name or address of a user or resource is
   translated to a name or address belonging to a different user or
   resource.  A Request-URI rewrite operation is considered to be a
   routing translation if the name or address of a user or resource is
   translated to an address that is a hop for reaching that user.  If
   the proxy determines the request URI translation to be a mapping
   translation, then it MUST add a "mapped" attribute to the History-
   Info value that records the request URI of the incoming request; in
   all other cases it MUST add a "routed" attribute to the History-Info
   value that records the request URI of the incoming request.  Note
   that if the proxy can not determine whether a mapping translation or
   a routing translation takes place that it always defaults to adding a
   "routed" attribute.

   Once the proxy has translated the Request-URI into a registered



Rosenberg, et al.       Expires December 11, 2009              [Page 13]


Internet-Draft                 Target URI                      June 2009


   contact or configured URI, it MUST add an additional History-Info
   header field value containing the Contact/URI for each request to be
   forwarded.  The index is set as defined in [RFC4244].

   If the proxy is actually redirecting and not forwarding the request,
   it SHOULD include a History-Info URI in the response for the target.
   That URI, if present, MUST contain the "aor" attribute.  It SHOULD
   NOT add a History-Info URI for the registered contact; the previous
   hop proxy will do that.  Note that, this rule violates a SHOULD-
   strength rule in Section 4.3.4 of [RFC4244].  That section indicates
   that redirections "SHOULD NOT" contain any new History-Info header
   fields, as those will be added by the upstream server.  For this
   application however, only the downstream server knows that the
   request URI was an AOR, and thus the History-Info header field and
   the "aor" attribute must be added by the downstream server.

7.2.  UA Behavior

7.2.1.  Determining the addressed target

   A UAS receiving a request, and wishing to determine the addressed
   target, takes the values in the History-Info header field, and
   traverses through them in reverse order.  Note that, the value of the
   "index" attribute is not relevant; the traversal is in order of the
   header fields values themselves.  The UAS finds the first header
   field value containing both an "aor" parameter and a "mapped"
   parameter, then takes the value following that hi-entry.  If there is
   no entry with a "mapped" parameter, then it takes the first History-
   Info value.  If there is no History-Info header field in the request
   the UAS takes the addressed target from the request URI.

7.2.2.  Determining the last AOR used to reach it

   A UAS receiving a request, and wishing to determine the last AOR used
   to reach it, takes the values in the History-Info header field, and
   traverses through them in reverse order.  Note that, the value of the
   "index" attribute is not relevant; the traversal is in order of the
   header fields values themselves.  The UAS finds the first header
   field value containing an "aor".  If this header also contains a
   "mapped" parameter then the last AOR of the user can not be
   determined reliably, but this can be considered an fault situation
   which should never occur.

   Note: This is the same value that the P-Called-Party-ID header field
   extension [RFC3455] would deliver.






Rosenberg, et al.       Expires December 11, 2009              [Page 14]


Internet-Draft                 Target URI                      June 2009


8.  The difference to P-Called-Party-Id

   As defined in [RFC3455], if a SIP entity, which acts as registrar/
   home proxy for the terminating user, re-writes the Request-URI with
   the contact address of the registered UA it may insert a P-Called-
   Party-ID header field with the previous value of the Request-URI.

   The last hi-entry in History-Info minted with an "aor" attribute and
   P-Called-Party-ID header field have the same semantics.  The last hi-
   entry in History-Info minted with an "aor" attribute represents the
   current target identity, while the P-Called-Party-ID represents the
   last Request-URI value used to reach the user before the Request-URI
   value was re-written with the Contact address of the UAS.  In some
   cases the P-Called-Party-ID may be the same as the addressed target
   but, it may also be the last route taken (not equal to the current
   target) to deliver the request.  Therefore the P-Called-Party-ID can
   not be used in a generic SIP environment to represent the current
   target.

   3GPP has defined procedures for the usage of P-Called-Party-ID, so
   3GPP would need to continue to use the header, in addition to the new
   History-Info header mechanism.  However, both mechanisms can exist in
   parallel.


9.  Syntax

   This specification extends the syntax of hi-param in Section 4.1 of
   RFC 4244:

   hi-param = hi-index / hi-aor / hi-mapped / hi-routed / hi-extension

   hi-aor = "aor"
   hi-mapped = "mapped"
   hi-routed = "routed"


10.  Security Considerations

   The "aor" parameter indicates that a URI was subject to translation
   by a home proxy, and consequently, acts as an explicit indicator that
   a particular URI was an AOR for a user.  This might be useful for
   attackers wishing to farm requests for targettable URIs for purposes
   of spamming.  Of course, such attackers can utilize URIs in History-
   Info even if they lack the "aor" attribute, so "aor" does not really
   exacerbate this.  Nonetheless, since the princpal application of the
   "aor" parameter is delivery of a URI to a UAS within the same domain,
   History-Info values inserted solely for this purpose SHOULD be



Rosenberg, et al.       Expires December 11, 2009              [Page 15]


Internet-Draft                 Target URI                      June 2009


   removed at the domain boundary.


11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC4244]  Barnes, M., "An Extension to the Session Initiation
              Protocol (SIP) for Request History Information", RFC 4244,
              November 2005.

11.2.  Informative References

   [I-D.ietf-sip-gruu]
              Rosenberg, J., "Obtaining and Using Globally Routable User
              Agent (UA) URIs (GRUU) in the  Session Initiation Protocol
              (SIP)", draft-ietf-sip-gruu-15 (work in progress),
              October 2007.

   [RFC5039]  Rosenberg, J. and C. Jennings, "The Session Initiation
              Protocol (SIP) and Spam", RFC 5039, January 2008.

   [RFC3087]  Campbell, B. and R. Sparks, "Control of Service Context
              using SIP Request-URI", RFC 3087, April 2001.

   [RFC4240]  Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
              Media Services with SIP", RFC 4240, December 2005.

   [RFC4458]  Jennings, C., Audet, F., and J. Elwell, "Session
              Initiation Protocol (SIP) URIs for Applications such as
              Voicemail and Interactive Voice Response (IVR)", RFC 4458,
              April 2006.

   [RFC2543]  Handley, M., Schulzrinne, H., Schooler, E., and J.
              Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
              March 1999.

   [RFC3455]  Garcia-Martin, M., Henrikson, E., and D. Mills, "Private
              Header (P-Header) Extensions to the Session Initiation
              Protocol (SIP) for the 3rd-Generation Partnership Project



Rosenberg, et al.       Expires December 11, 2009              [Page 16]


Internet-Draft                 Target URI                      June 2009


              (3GPP)", RFC 3455, January 2003.

   [RFC3761]  Faltstrom, P. and M. Mealling, "The E.164 to Uniform
              Resource Identifiers (URI) Dynamic Delegation Discovery
              System (DDDS) Application (ENUM)", RFC 3761, April 2004.

   [RFC4769]  Livingood, J. and R. Shockey, "IANA Registration for an
              Enumservice Containing Public Switched Telephone Network
              (PSTN) Signaling Information", RFC 4769, November 2006.

   [I-D.ietf-sip-outbound]
              Jennings, C., "Managing Client Initiated Connections in
              the Session Initiation Protocol  (SIP)",
              draft-ietf-sip-outbound-19 (work in progress), June 2009.

   [I-D.ietf-enum-cnam]
              Shockey, R., "IANA Registration for an Enumservice Calling
              Name Delivery (CNAM)  Information and IANA Registration
              for URI type 'pstndata'", draft-ietf-enum-cnam-08 (work in
              progress), September 2008.


Authors' Addresses

   Jonathan Rosenberg
   Cisco
   Edison, NJ
   US

   Email: jdrosen@cisco.com
   URI:   http://www.jdrosen.net


   Hans Erik van Elburg
   Ericsson
   Ericssonstraat 2
   Rijen  5121 ML
   The Netherlands

   Email: ietf.hanserik@gmail.com











Rosenberg, et al.       Expires December 11, 2009              [Page 17]


Internet-Draft                 Target URI                      June 2009


   Christer Holmberg
   Ericsson
   Hirsalantie 11, Jorvas
   Finland

   Email: christer.holmberg@ericsson.com


   Francois Audet
   Nortel

   Email: audet@nortel.com


   Shida Schubert (editor)
   NTT

   Email: shida at ntt-at.com

































Rosenberg, et al.       Expires December 11, 2009              [Page 18]


Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/