SIPPING                                                     J. Rosenberg
Internet-Draft                                             Cisco Systems
Expires: April 19, 2007                                 October 16, 2006


 An Architecture and Framework for the Usage of Telephone Numbers with
                 the Session Initiation Protocol (SIP)
               draft-rosenberg-rai-phone-names-numbers-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 April 19, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   The Session Initiation Protocol (SIP) is often used for the purposes
   of making and receiving Voice over IP (VoIP) calls, and in many of
   these cases one or both parties in the call is on the Public Switched
   Telephone Network (PSTN).  For this reason, phone numbers are often
   used as part of SIP calls.  Despite numerous small specifications
   describing usage of phone numbers for SIP, there remains a great deal
   of interoperability problems and feature loss.  This document tries
   to address this by providing a general framework for the usage of



Rosenberg                Expires April 19, 2007                 [Page 1]

Internet-Draft               Phone Practices                October 2006


   phone numbers and phone naming and numbering services with SIP.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Names, Numbers and Routes  . . . . . . . . . . . . . . . . . .  4
   3.  Phone Number Processing  . . . . . . . . . . . . . . . . . . .  6
     3.1.  Dial String Processing . . . . . . . . . . . . . . . . . .  8
     3.2.  Source Identity Selection  . . . . . . . . . . . . . . . .  9
     3.3.  Name to Address Translation  . . . . . . . . . . . . . . . 10
     3.4.  Route Determination  . . . . . . . . . . . . . . . . . . . 12
   4.  Number Portability . . . . . . . . . . . . . . . . . . . . . . 13
   5.  Freephone Services . . . . . . . . . . . . . . . . . . . . . . 15
   6.  Short Code Services  . . . . . . . . . . . . . . . . . . . . . 18
   7.  Carrier Selection  . . . . . . . . . . . . . . . . . . . . . . 18
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
     8.1.  URN Namespace  . . . . . . . . . . . . . . . . . . . . . . 19
     8.2.  Service URN Values . . . . . . . . . . . . . . . . . . . . 19
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 20
     11.2. Informative References . . . . . . . . . . . . . . . . . . 21
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
   Intellectual Property and Copyright Statements . . . . . . . . . . 24

























Rosenberg                Expires April 19, 2007                 [Page 2]

Internet-Draft               Phone Practices                October 2006


1.  Introduction

   The Session Initiation Protocol (SIP) [1] is often used for the
   purposes of making and receiving Voice over IP (VoIP calls.
   Consequently, SIP calls often traverse gateways to the PSTN, and
   frequently end up carrying phone numbers in their messages.  As a
   consequence of this frequent interworking, SIP endpoints end up being
   involved in traditional PSTN services.

   There are many aspects of this interworking which require
   specification.  One broad class of problems are those of protocol
   conversion, between SIP and various SS7 signaling variants.  Those
   are covered in specifications such as [11] and [12].  However, there
   is another aspect of this problem which merits consideration - the
   usage of legacy PSTN addressing concepts with SIP, and more
   specifically, the usage of phone numbers with SIP.  This aspect of
   interworking has the unique property that, once the last PSTN switch
   is disconnected and all calls run over VoIP (and SIP of course), the
   usage of phone numbers within SIP is likely to persist.

   Numerous specifications have been developed to deal with the usage of
   phone numbers in SIP.  RFC 4248 [3] defines a URI scheme for
   telephone numbers.  Numerous extensions have been specified for it,
   including ones for number portability [15] and trunk groups [17].
   The SIP URI can also contain telephone numbers in its user part.
   ENUM itself [13] is concerned primarily about mapping of phone
   numbers to Internet resources, and extensions to ENUM for handling
   PSTN naming and numbering services, such as number portability [18]
   and calling name [19], are under development.

   Despite this, the usage of phone numbers and phone numbering concepts
   with SIP remains a source of interoperability problems.  Some of
   these relate to non-compliance with specifications, but others can be
   attributed to lack of specification.  Some of the problems include:

   o  Interoperability failures when a SIP UA (such as PSTN gateway) is
      expecting to see phone numbers with a tel URI, but instead they
      arrive in SIP URI form, and vice-a-versa.

   o  Interoperability failures when a SIP UA is expecting and receives
      a SIP URI, but doesn't recognize the domain part is its own and
      thus rejects the request.

   o  Interoperability failures when a SIP UA is expecting a tel URI or
      a SIP URI in various SIP header fields (To, From, Route, Request-
      URI, Contact) and receives a form it did not expect.





Rosenberg                Expires April 19, 2007                 [Page 3]

Internet-Draft               Phone Practices                October 2006


   o  Difficulty providing local number portability to users with SIP
      endpoints, and when it is provided, oftentimes with a confused
      transition period.

   o  Interoperability failures when dial plans are used, and a phone
      emits a number that is not in a format understood by the proxy or
      UA.

   All of these problems are related to the usage of telephone numbers
   with SIP.  Indeed, the root cause behind each of these problems is a
   misapplication of the concepts of names, numbers and routes when used
   in conjunction with phone numbers.  This document tries to address
   this problem by defining a framework for usage of phone numbers
   within SIP.  Section 2 defines the concepts of names, numbers and
   routes with VoIP and shows how they map to SIP concepts.  Section 3
   defines a sequence of translation functions which need to be
   undertaken in the processing of a call to any phone number.  Using
   these concepts, Section 4 discusses local number portability and its
   usage within all IP networks and PSTN interoperability.  Section 5
   discusses freephone services.  Section 6 discusses short code
   services.  Section 7 discusses carrier selection.


2.  Names, Numbers and Routes

   A central concept in this document is the distinction between a name,
   a number, and a route.  The general definitions of these terms are:

   Name: An identifier which points to a resource by means of an opaque
      or structured reference that reveals nothing about the location of
      the resource.  In the postal system, this would correspond to a
      person's name, i.e., "Jane Doe".

   Address: An identifier which points to a resource by indicating where
      it can be found.  In the postal system, this would correspond to a
      person's street address, i.e., "500 Main Street, Anytown U.S.A".

   Route: A sequence of addresses, each of which points to a hop to be
      visited in order to deliver a message to a recipient.  In the
      postal system, this would correspond to the set of post offices
      used to relay a letter towards the recipient.

   Based on these definitions, some important conclusions can be drawn
   about SIP identifiers:

   o  A tel URI is a name.  It lacks any information whatsoever about
      the location of the object.  Indeed, a tel URI can be used to
      identify a SIP user, a webpage, or a line on a PSTN switch.



Rosenberg                Expires April 19, 2007                 [Page 4]

Internet-Draft               Phone Practices                October 2006


   o  A service URN [8] is a name.  Like the tel URI, it lacks any
      information about the location of an object.  Indeed, it is
      actually represented by a Universal Resource Name [4], which is
      the standardized way to represent a name.

   o  A SIP URI is an address.  The domain part of the SIP URI is the
      only mandatory portion of the SIP URI, and it identifies the
      namespace within which to interpret the user part, and through RFC
      3263 [2], the place to go to find that resource.

   o  The SIP Route header field is a route.  The Route header field has
      one or more values, and each one contains an address (a SIP URI)
      of an intermediate service (a SIP proxy service) which is visited
      in the delivery of a request to the target recipient.

   Perhaps one of the biggest points of confusion in the usage of phone
   numbers with SIP is the difference between:

   1.  A tel URI with global number X

   2.  A SIP URI with global number X in the user part, with a
       user=phone parameter

   3.  A SIP URI with a global phone number X in the user part, with a
       user=IP parameter or no user parameter

   RFC 3261 is clear that user=phone is used when the user part is
   formatted as a phone number.  However, this document argues that when
   used in a SIP URI there is an additional, deeper meaning.  The domain
   part of the SIP URI serves two important purposes.  First, it
   specifies the host to which the request should be delivered.
   However, this is secondary to its more important meaning - it is an
   identifier for the owner of the namespace from which the user part is
   selected.  Consequently, when the user part is a global phone number,
   it is asserting ownership of that global phone number by that domain.
   Thus, the SIP URI form with user=phone MUST only be used when the
   entity constructing the URI has knowledge from an authoritative
   source that the domain in the URI is the owner of the phone number in
   the left hand side.  Such knowledge comes from databases such as ENUM
   or PSTN-based local number portability tables, in additional to
   localized knowledge within the domain that knows definitively that it
   owns the number.

   For example, if the number +17325551000 is owned by example.com, the
   following URI would represent a SIP address indicating such:


   sip:+17325551000@example.com;user=phone



Rosenberg                Expires April 19, 2007                 [Page 5]

Internet-Draft               Phone Practices                October 2006


   Lack of the user=phone parameter (or usage of a different user value)
   is used when the user part is merely a localized key interpreted in
   the context of the domain in the right hand side.  The primary use
   case of this are for representing dial strings, as discussed below.
   Finally, a tel URI represents a name of a resource when the domain of
   ownership is not known or not within the IP network.

   These definitions permit further clarification on the operations
   performed on these identifiers:

   Translation: Translation is the process of converting a name to an
      address in order to deliver a request to a target.  This
      translation requires the use of translation tables.  ENUM serves
      as one such mechanism.  Indeed, the principal purpose of ENUM is
      to serve as a translation from a name, in the form of a tel URI,
      to an address in the form of a SIP URI.  The LoST protocol [20]
      also serves to translate from a name in the form of a service URN,
      to an address in the form of a SIP URI.

   Retargeting: Retargeting is the process of changing the name or
      address that identifies the target to a different name or address
      that identifies a different target.

   Routing: In SIP, routing is the process of determination of a route
      (which is a series of Route header fields) for delivering a
      request to the current name or address that identifies the target
      of the request.


3.  Phone Number Processing

   With these definitions, the set of processing steps that need to be
   undertaken in the handling of a call to a phone number can be
   described.  These steps are shown in Figure 2

















Rosenberg                Expires April 19, 2007                 [Page 6]

Internet-Draft               Phone Practices                October 2006


                               |
                               |
                               | Dial
                               | String
                               |
                               V
                      +------------------+
                      |                  |
                      |     Process      |<------ Dial Plan
                      |   Dialed Digits  |
                      |                  |<------ Number Plan
                      |                  |
                      +------------------+
                               |
                               | Target
                +--------------+ Name
                |              | (tel or service URN)
                |              |
                |              V
                |     +------------------+
                |     |                  |
                |     |     Name to      |         Translation
                |     |     Address      |<------- Service
                |     |     Translation  |         (ENUM, LoST, etc.)
                |     |                  |
                |     +------------------+
                |              |
                |              | Target
                +--------+     | Address
                         |     | (SIP URI)
                         V     V
                      +------------------+
                      |                  |
                      |     Route        |         Routing Tables
                      |   Determination  |<------- (DNS, TRIP,
                      |                  |         configured, etc)
                      |                  |
                      +------------------+

   Figure 2

   There are three steps in this process.  The first is the collection
   of a dial string, and the conversion of that dial string (either in
   the UA or in a network service) to a target name.  The target name is
   then converted, through a translation service, to a target address.
   In some cases, the target name cannot be translated, or it is known
   that translation has to take place elsewhere, in which case a route
   is determined to reach the target address or a translation service



Rosenberg                Expires April 19, 2007                 [Page 7]

Internet-Draft               Phone Practices                October 2006


   for the target name.

   When combined with the loose route concepts of [9] (which are
   essential to this specification) this processing implies that the
   target name appears in the request URI, and that the process of
   translation and route determination both impact the Route header
   field.

   The subsections which follow explain each step in more detail.

3.1.  Dial String Processing

   The first step is the collection of a dial string.  For user
   interfaces where the user enters in the destination number as a
   sequence of digits, the dial string is the sequence entered by the
   device.  Dial strings are not always used; for user interfaces (such
   as those on a PC or a wireless phone) where the user enters or
   selects an alias for the target, the phone itself would store and use
   the target name or address.

   Once the dial string is obtained, the next step is to convert the
   dial string into the target name (represented by a tel URI or service
   URN).  This conversion is done based on two pieces of context.  One
   is the dial plan, and the other is the number plan.  The number plan
   specifies rules about how the number space is managed and allocated
   to users.  An example of a numbering plans is the E.164 numbering
   plan.  A dial plan is a set of rules about how numbers entered on the
   device map into the number plan.  An example dial plan would specify
   that a user has to dial '9' in order to get an 'outside line', or
   dial '011' for an international number.

   The dial plan processing can occur either in the UA itself, or in a
   server in the network.  When it occurs within the UA, there is never
   a need for a standardized representation of a dial string; it is
   merely an intermediate format within the host prior to producing the
   output - the target name.  However, in some cases, the UAC does not
   have access to the dial plan or numbering plan, and cannot perform
   this function.  In such cases, the UA would send the request to a
   service which can perform the conversion.  In such a case, there is a
   need for representation of the dial string.  Indeed, the request is
   effectively being targeted to a network service.  This network
   service is addressed using the concepts in RFC 3087 [14], whereby the
   URI parameters identify the parameters of the service.  Here, the
   service requires but one parameter - the dial string.  The service
   extracts the dial string from the URI and performs a retargeting
   operation to the name or address of the target based on its knowledge
   of the dial string and number plan.  For this reason, the dial string
   is represented as a SIP URI using the user=dialstring URI parameter



Rosenberg                Expires April 19, 2007                 [Page 8]

Internet-Draft               Phone Practices                October 2006


   [10].

   When a UA emits a request to a dial-string service, it MUST include
   the URI containing the dial string (and invoking the service) in the
   Request-URI.  The domain part SHOULD be configured, and if not
   configured, SHOULD be equal to the domain part of the user's AOR.
   The URI MUST include a phone-context if one was configured with use
   for the dial plan service.  The To header field will echo the
   resulting URI.  This does mean that the recipient of the request can
   inspect the To header field and see that it was reached through a
   dial-string processed by a dial-string service.  Since the dial-
   string service is fundamentally a retargeting operation, it MUST
   rewrite the Request-URI with the target name, and SHOULD include a
   History-Info [5] header field indicating that it retargeted.

   However, it is RECOMMENDED that the dial string processing function
   be done within a user agent.  This avoids the "ugly To header field"
   problem described above, and eliminates the difficulty of binding a
   request to a dial plan within the network (which is what necessitates
   the phone context parameter).  This also produces a consistent format
   for requests emitted from all UA, since "smart" UA will not even use
   dial strings, and instead emit requests directly addressed towards
   the target.

   Regardless of whether the dial string processing is done by the UA or
   in the network by a dial string service, the request that emerges
   from this service will have the target name (as a tel URI or service
   URN) in the Request-URI.  This is not an address at this point, and
   therefore is NOT using the SIP URI format.  For example, a request
   emitted by a UA performing the dial string processing would look
   like, in part:


   INVITE tel:+19735551000 SIP/2.0
   To: tel:+19735551000
   From: sip:joe@example.com
   Route: sip:edge.example.com

3.2.  Source Identity Selection

   Prior to emitting the request (regardless of whether the UA performs
   the dial string processing), the UA will need to select an identity
   for placement in the From header field.  This selection is important,
   since it will be signed by an identity service [6], and presented to
   the called party as a form of "caller ID".  The selection is
   complicated for several reasons.  First, the identity mechanisms of
   RFC 4474 only apply to SIP URI, not a tel URI.  Secondly, the caller
   may have multiple identities, each of which may be applicable in



Rosenberg                Expires April 19, 2007                 [Page 9]

Internet-Draft               Phone Practices                October 2006


   different contexts.  For example, a user within an enterprise may
   have an identity within the local numbering plan
   (tel:5000;phone-context=example.com), a direct-dial number
   (tel:+19735555000) and a multiplicity of SIP AOR
   (sip:joe@example.com, sip:joe.smith@example.com).  Ideally, the From
   header field would contain the internal number when calling within
   the enterprise, would contain the E.164 tel URI when calling a phone
   on the PSTN, and a SIP AOR when calling a SIP endpoint.
   Unfortunately, the caller does not know what the target will be.  How
   then can it select the identity in the From header field?

   [[TODO: I don't have a good solution for this.  The best I've been
   able to think of is to place a canonical identity in the From header
   field that gets signed, and place the remaining ones in Reply-To.
   This raises questions about the verification of Reply-To values, and
   still makes it hard to determine what to place in the From.  More
   consideration of this is needed.]]

3.3.  Name to Address Translation

   Once a target name has been identified, the next step is the
   translation of this name to an address.  Typically this processing is
   done by a proxy server in the domain of the caller, but this need not
   be the case.  The output of the translation service would be a SIP
   URI representing an AOR for the called party.  It can also be a
   telephone number, representing a routing address for the user within
   the PSTN.  [[OPEN ISSUE: Once again, it feels like a new URI scheme
   is needed here.]]

   There are two cases that can be considered.  In the first case, proxy
   that is processing the request cannot perform the translation.  This
   can happen for many reasons:

   1.  The proxy doesn't have access to any kind of translation services
       at all, and will instead have the translation service performed
       elsewhere.  Elsewhere can include the PSTN itself, in which case
       the request is routed towards a PSTN gateway.

   2.  The proxy has access to a translation service, but has discovered
       that the name does not correspond to any entity on the IP
       network.  Thus, the call needs to be routed towards the PSTN,
       since the name corresponds to an entity that resides there.  This
       happens when an ENUM query returns no result, for example.
       [[OPEN ISSUE: Ideally, we'd have a separate way to identify a
       phone number which is an address rather than a name.  The closest
       thing at this point is the ENUM dip indicator [16], but to me it
       feels like we need a new URI scheme of some sort, since the
       concept is really independent of the mechanism for resolution



Rosenberg                Expires April 19, 2007                [Page 10]

Internet-Draft               Phone Practices                October 2006


       (ENUM).  Something like line:<number> feels about right.]]

   3.  The proxy has partial translation services.  In particular, it
       has definitive knowledge about the translation just for the set
       of numbers it is directly serving.  For other numbers, it is not
       certain.  Consequently, it would perform a name to address
       translation process if the name is one it serves (and it knows it
       still serves - see Section 4, and for others, route the request
       towards a translation service elsewhere.

   In the second case, the proxy performing the translation can do it.
   This can happen for several reasons:

   1.  The proxy has accessed a translation service, such as ENUM, which
       has successfully produces an address (in the form of a SIP URI)
       for that number.

   2.  The proxy has localized knowledge that it definitively owns that
       number, and consequently performs a localized translation to a
       SIP URI.

   In cases where the proxy cannot perform the translation, it
   determines a route for reaching a translation service.  Oftentimes,
   this translation service is within the PSTN itself, in which case the
   route that is determined is a route to a PSTN gateway.  As described
   in Section 3.4, this route will appear in the Route header field, and
   the target of the request remains a tel URI in the Request-URI:


   INVITE tel:+19735551000 SIP/2.0
   To: tel:+19735551000
   From: sip:joe@example.com
   Route: sip:gw23.example.com

   If, however, the translation does occur, this translation is NOT a
   retargeting.  As defined in [9], a retargeting only occurs when the
   entity that is reached cannot identify itself with the identity prior
   to the translation.  In this case, it would be able to, since the
   name is a valid identifier for the entity with that address.  This
   means that the request emitted after the translation would look like:


   INVITE tel:+19735551000 SIP/2.0
   To: tel:+19735551000
   From: sip:joe@example.com
   Route: sip:+19735551000@example.org

   Note how the address appears as the topmost Route header field, and



Rosenberg                Expires April 19, 2007                [Page 11]

Internet-Draft               Phone Practices                October 2006


   the Request-URI remains as the target name.  Had the translation
   service produced an address on the PSTN, the request would look like:


   INVITE tel:+19735551000 SIP/2.0
   To: tel:+19735551000
   From: sip:joe@example.com
   Route: tel:+19735559999

   In this case, the number has been ported and the Route header field
   indicates the target address, which is a line on a switch in the
   PSTN, and thus identified by a tel URI [[OPEN ISSUE: ugh again.]].

3.4.  Route Determination

   The next step in the processing of the request is route
   determination.  This process takes the target name and/or address,
   and from it, determines the sequence of additional services (proxies
   or gateways) that must be visited prior to reaching the target, each
   identifed by a SIP URI [[OPEN ISSUE: Need to consider non-SIP URI
   here; for example, specifying hops within the PSTN]].  In cases where
   no additional hops are to be visited, this process yields a null
   output.  These routes, if present, MUST be pushed into the Route
   header field.

   If the target of the request is a name that is a tel URI, or if the
   target is an address within the PSTN, the route determination is
   called gateway routing, and typically involves the selection of an
   egress gateway.  Gateway routing is determined through routing tables
   that are present on the proxy performing the gateway routing.  These
   tables can be created dynamically from routing protocols like TRIP
   [7], or they can be manually configured.  Typically, they are based
   on a "longest prefix match" operation on the target name, though need
   not be.

   Using the example of a translation service which produced a tel URI
   as an address, the routing process would select a PSTN gateway and
   push the result into the request.  The result would look like:


   INVITE tel:+19735551000 SIP/2.0
   To: tel:+19735551000
   From: sip:joe@example.com
   Route: sip:gw334.example.com
   Route: tel:+19735559999

   Which assumes that the result of the gateway selection was sip:
   gw334.example.com.  Elements which perform gateway routing SHOULD be



Rosenberg                Expires April 19, 2007                [Page 12]

Internet-Draft               Phone Practices                October 2006


   capable of outputting any valid SIP URI, and NOT just a hostname or
   IP address.  This allows a gateway to have differentiated processing
   associated with the request based on the value of the remainder of
   the URI (and typically the user part) of the Route header field.  For
   example, if a gateway has different processing for inbound local vs.
   long distance calls, the previous hop could use a different value of
   the user part for each case.

   In essence, the service URI concepts of RFC 3087 [14] apply equally
   well to gateways, and indeed to proxies and other intermediary
   services.  However, as intermediaries, the service treatment is
   specified in the URI in the Route header field.  As described in RFC
   3087, the value for the URI would not be standardized, but rather
   would be opaque to upstream elements and merely configured based on
   the features and configuration of the downstream elements.

   Another way to consider this is that the Route header field URI
   points to an index for the policies that are to be applied in the
   intermediary for processing of the request.  Arguably, this makes the
   topmost Route header field value analagous to the concept of trunk
   groups in the PSTN, which serve this purpose as well (though they
   serve other purposes, such as capacity planning, which are not
   analagous to Route).  Consequently, it is RECOMMENDED that gateways
   and other intermediaries use the user part of Route header fields as
   an index for request processing, as a form of "SIP trunks".  Gateway
   and intermediary vendors SHOULD publish, as part of their product
   specification, valid values for the user parts and their associated
   meanings, when well-known values are used.  Usage of the actual trunk
   group URI parameters for identifying such processing [17] is NOT
   RECOMMENDED, since it is specific to the PSTN concept of trunk
   groups, and not applicable to non-GW intermediaries like SIP proxies.
   However, the Route header field is applicable to all types of
   intermediary, including vanilla SIP proxies.

   [[OPEN ISSUE: This whole concept here seems a little out of place in
   a section on route determination, since its more general than that.
   Maybe move elsewhere?]]

   It is never necessary for the route to a PSTN gateway to contain the
   desired number in the user part; this number will always be present
   in either the next Route header field, or if there is none, the
   Request URI.  Indeed, a URI of the form sip:number@gateway;user=phone
   MUST NOT be used.  As defined above, the user=phone form implies name
   ownership, and the gateway itself does not own the telephone number.


4.  Number Portability




Rosenberg                Expires April 19, 2007                [Page 13]

Internet-Draft               Phone Practices                October 2006


   Number portability (NP), also known as local number portability (LNP)
   is a concept in the PSTN whereby a user can take their existing phone
   number, and move it from one provider to another.  This allows a user
   to have choice in their providers without having to change the number
   by which everyone knows them.

   Local number portability, at its core, is merely specifying that the
   translation of a name (the phone number) to an address (in the PSTN,
   a switch line identifier) can change.  This concept is applicable
   even in a pure SIP network, as long as users can be identified by
   names and not addresses.  If one presumes that phone numbers continue
   to exist as identifiers even after the PSTN has disappeared, LNP
   continues to be important.  Indeed, the LNP service is applicable to
   other forms of names besides phone numbers.  One can imagine names
   based on national identifiers (urn:ssn:123456789 for social security
   numbers in the United States) or human friendly names
   (urn:humannames:jonathan.rosenberg).

   Since LNP is just the ability to change the mapping of a name to
   address over time, it is readily addressed by the model in Section 3.
   The primary complication is how to synchronize the change across
   providers.  If ENUM is used as the name to address translation
   service, and a DNS TTL of zero is used, instantaneous porting is
   possible.  When a user requests a number port, the proxy serving the
   number currently would mark the user's account as "transitioning".
   This means that any localized configuration within the domain mapping
   that users name (in the form of a tel URI) to their address (their
   SIP URI with user=phone) is no longer definitive.  This will require
   the proxy to perform the ENUM query, which returns the new address,
   which will have a domain part of a different provider.  The request
   would then be properly sent to the new provider by placing the
   address in the Route header field.  For example, if the number
   +19735551000 is ported from example.com to example.org, the
   example.com proxy would note that the number needs to be checked in
   the public databases, and once the databases are updated, the
   resulting request would look like:


   INVITE tel:+19735551000 SIP/2.0
   To: tel:+19735551000
   From: sip:joe@example.com
   Route: sip:+19735551000@example.org;user=phone

   Interestingly, this same model applies equally well to numbers that
   reside in the PSTN.  A proxy performing a name to address translation
   would find that the number doesn't exist on the IP network or is not
   reachable through the IP network.  This would happen because the name
   to address translation service yields no results.  So, instead, the



Rosenberg                Expires April 19, 2007                [Page 14]

Internet-Draft               Phone Practices                October 2006


   proxy queries an alternative name to address service, one that
   returns PSTN addressing information.  This can be an SS7 query from
   the proxy, if it has SS7 interfaces, or an IP-based query, such as
   the ENUM query suggested in [18].  The phone number that results from
   the query, represents an address, and would therefore appear in the
   topmost Route header field:


   INVITE tel:+19735551000 SIP/2.0
   To: tel:+19735551000
   From: sip:joe@example.com
   Route: tel:+19735559999

   The subsequent route determination function would use the topmost
   Route header field and find an egress gateway that is ideal for
   reaching this number.

   [[OPEN ISSUE: This INVITE above takes a form different from the
   suggestion in [18], which would have the request URI containing the
   original number and the ported number in the np parameters.  The
   author of this document proposes that doing so confounds names,
   addresses and routes.  Concretely, it would result in a completely
   different format for pure SIP based LNP.  As shown above, the
   mechanism here is unified an applicable even when the name that is
   being ported is not a phone number.  It needs to be considered
   whether to change the format of the LNP records, or keep the format
   and change how the result is used.]]


5.  Freephone Services

   In the PSTN, freephone numbers are numbers that are aliases to an
   actual number, but indicative of a special service towards that
   number - a free call.  In the United States, these are represented by
   800, 888 and other similar prefixes in place of an area code.

   Freephone numbers are just another form of name, and the translation
   of the freephone number to an actual number is just another form of
   name to address translation or name to name translation.  Like number
   portability, the concept of many alias numbers for a user, each of
   which has different service implications, is applicable even in pure
   networks.  Indeed, it is perfectly reasonable for a freephone number
   to resolve to a SIP URI that points to a SIP entity.  This would
   allow a SIP UA to call a freephone number which routes entirely over
   the IP network.  It is outside of the scope of this document as to
   how inter-carrier billing arrangements would be managed to meet the
   expectations associated with freephone numbers.  This document is
   concerned only with the representation and usage of such numbers.



Rosenberg                Expires April 19, 2007                [Page 15]

Internet-Draft               Phone Practices                October 2006


   Considering for a moment the case of freephone specifically, there is
   some controversy as to whether the global tel URI form can even
   represent a name that is a freephone number.  Freephone numbers in
   the U.S. are national numbers, only accessible from within the U.S..
   Freephone numbers are also not considered part of the E.164 numbering
   plan.  Despite this fact, many implementations have been using the
   global tel URI (and its SIP version) to represent freephone numbers.
   Other implementations use a local tel URI
   (tel:18005551212;phone-context=+1).  Though the latter is a valid
   representation, it begs the question of how lookups would be
   processed.  It introduced a new qualifier - phone-context.  How would
   this map to ENUM, for example?  An alternative is to define a new URN
   scheme for freephone numbers (urn:service:freephone:number).  The
   dial plan would translate 8xx numbers (in the U.S. at least) to the
   appropriate URN scheme.  [[OPEN ISSUE: Need to conclude on this and
   give some guidance]].

   The translation service for the freephone name would ideally produce
   the address.  However, in the PSTN today it actually produces one of
   two entries - either a carrier identified by a carrier code) or
   another number (which itself might have been ported) which represents
   an alternative name.  Consequently, an IP-accessible translation
   service for freephone names could return a SIP address, a tel URI
   name, a carrier code, or a SIP URI representing a route to the
   provider that owns the number (which would be followed by a localized
   translation service within that domain).  Currently, there is no URI
   format for representing a carrier code.  There is a tel URI cic
   parameter, but nothing to represent a carrier code alone is
   isolation.  Using the cic parameter confounds the name and the route
   used to get to its owner, and thus a separate URN seems more
   appropriate here.  A carrier code is another form of name, and thus
   is ideally represented with a urn.  Section 8.1 registers the cic URN
   scheme for this purpose.

   Considering each of these use cases, if a freephone translation
   service returns a SIP address, this is not a retargeting (indeed none
   of these are retargeting), and the resulting SIP request would look
   like (we assume the tel URI local form for freephone numbers:


   INVITE tel:8885551000;phone-context=+1 SIP/2.0
   To: tel:8885551000;phone-context=+1
   From: sip:joe@example.com
   Route: sip:+19735551000@example.org;user=phone

   In which case the request can be directly sent to the example.org
   domain.  If the translation service returns a telephone number (a
   name):



Rosenberg                Expires April 19, 2007                [Page 16]

Internet-Draft               Phone Practices                October 2006


   INVITE tel:8885551000;phone-context=+1 SIP/2.0
   To: tel:8885551000;phone-context=+1
   From: sip:joe@example.com
   Route: tel:+19735551000

   A subsequent name to address translation can be performed on this,
   and if that fails, route determination can then be run on the number
   in the Route header field to determine how to reach it, possibly
   through a gateway.  It is very important to note that, once the
   request arrives at the gateway, both the original 8xx number and the
   translated number are available.  Both are required to correctly
   populate the SS7 signaling.

   If the translation service returned a CIC code:


   INVITE tel:8885551000;phone-context=+1 SIP/2.0
   To: tel:8885551000;phone-context=+1
   From: sip:joe@example.com
   Route: urn:cic:87787

   The route determination function would still run on the topmost Route
   header field.  Since the URN is clearly labeled as a CIC, CIC-
   specific routing tables can be used to push the Route of a gateway.
   When this arrives at a gateway, the original 800 number and the
   desired CIC are known.  This allows for proper trunk selection at the
   gateway.  Note however that it does not require a gateway; nothing
   about the CIC URN suggests that it map to a PSTN connected resource.
   If a proxy has configured mappings of a CIC to a SIP URI, those can
   be used.

   If the translation service returns a domain (for example indicating
   that example.com owns the number), this would be done using a SIP URI
   pointing to the domain-local translation service.  For example:


   INVITE tel:8885551000;phone-context=+1 SIP/2.0
   To: tel:8885551000;phone-context=+1
   From: sip:joe@example.com
   Route: sip:local8xx@example.org

   Where sip:local8xx@example.org is a URI service [14] which accesses
   the 8xx translation service stored just within the example.org domain
   (typically in a local database of some sort).  Note that this form is
   identical to the case where the actual address is returned as a SIP
   URI above.





Rosenberg                Expires April 19, 2007                [Page 17]

Internet-Draft               Phone Practices                October 2006


6.  Short Code Services

   Another form of legacy PSTN services are short code services.  These
   are services such as 311 (local emergency assistance in the U.S.),
   and 411 (directory services).  Conceptually, these are very similar
   to freephone services.

   It is RECOMMENDED that short codes be detected as part of dial plan
   processing, and be mapped to service URN for each service.
   Section 8.2 defines a set of registrations for some of the existing
   short code services.

   The name to address translation service will then take the service
   URN and find a service to handle it.  The means for such translation
   will be service specific.  For ones based on location information,
   the LoST protocol SHOULD be used.  For others, which are location
   invariant but localized, local configuration of a name to address
   translation SHOULD be used for IP connected services.  If the service
   resides in the PSTN, route determination will be used instead.  In
   such a case, the request will arrive at the PSTN gateway with a
   Request URI equal to the service URN, and a topmost Route identifying
   the gateway.  [[OPEN ISSUE: Need to mention more about how to convert
   this into SS7]].


7.  Carrier Selection

   Another legacy service of the PSTN is carrier selection.  This is a
   feature which allows users to pick their 'long distance carrier'.
   This selection can be pre-subscribed (meaning that it is part of the
   user's profile, and the user doesn't need to indicate it each time
   they make a call) or a carrier can be selected on a call-by-call
   basis using a code.  In the United States, 101xxx is dialed to select
   a carrier.

   In many respects, this feature is very much legacy, and the entire
   notion of long distance will evaporate with pure VoIP.  However, even
   in a pure VoIP/SIP world, it is very likely that there will be
   numerous providers focused solely on interconnect.  Sometimes, those
   providers will be chosen entirely by the originating and termianting
   providers and not subject to user selection.  However, one can
   imagine that other interconnect providers would provider services
   that are of benefit to the subscriber and thus be something a
   subscriber might wish to elect.  For example, interconnect providers
   could provide specialized anonymization service (consider a SIP
   equivalent of the onion router), specialized logging and accounting
   services, specialized billing rates, and so on.  These are sensible
   even in pure IP interconnect.



Rosenberg                Expires April 19, 2007                [Page 18]

Internet-Draft               Phone Practices                October 2006


   Based on the models described here, carrier selection is nothing more
   than user indication of a desired route.  The route would be in the
   form of a SIP URI which identifies the service that the intermediate
   provider is to offer, and placed in the Route header field.  Again,
   it is important to note that the route selection here is NOT just of
   an IP address, or even of a provider, it is of a service URI that
   identifies a service to be applied at an intermediary.

   The intermediary URI could take the form of a SIP URI, in which case
   it is the address of the intermediary service on the SIP network.  It
   could be a tel URI, in which case it is the name of the service (not
   quite clear what this means).  It could also be a carrier code using
   the cic URN format, implying that the request be routed to that
   carrier.

   In one model, where the user device has the legacy PSTN interface,
   the dial plan processing would detect that a 1010xxx was dialed, and
   insert the appropriate service URI into the topmost Route header
   field.  Any outbound proxies or route sets would be pushed ontop of
   that.  In another model, where the subscriber has a pre-subscribed
   interconnect provider, the same thing could happen - the pre-
   subscribed URI is placed into the request by the UA as the bottom-
   most Route header field values.  Different URI could be used based on
   the fact that the provider was selected explicitly vs. via pre-
   subscription.

   [[OPEN ISSUE: There are many standardized values for the parameters
   of the intermediary service in the PSTN. [21] proposes tel URI
   parameters for each.  This would imply standardized service URI
   formats for this; need to consider that further.]]


8.  IANA Considerations

   This specification defines a new URN namespace for carrier codes, and
   defines several new service URN values.

8.1.  URN Namespace

   TODO.

8.2.  Service URN Values

   TODO.


9.  Security Considerations




Rosenberg                Expires April 19, 2007                [Page 19]

Internet-Draft               Phone Practices                October 2006


   This specification makes extensive use of the loose routing concepts
   of [9].  The primary implication of this is that the Route header
   field becomes the source of explicit and important identifying
   information for the handling of a request.  This introduces the
   possibility of attacks whereby users insert incorrect, malformed, or
   inaccurate Route header fields in order to accomplish a specific
   goal.

   Consequently, a SIP entity MUST verify that the topmost Route header
   field of a request it receives is one that is valid and authorized by
   use from the previous hop.  The use of mutual TLS between servers is
   RECOMMENDED as a means for establishing identity to assist in such
   authorization.  A proxy that receives a request with Route headers
   beyond itself from a client MUST authorize that this is a valid route
   for a user to request.  [[TODO: Should give specific guidance for the
   use cases above where this can happen, such as carrier selection]]


10.  Acknowledgements

   Many of the concepts in this document came out of discussions with
   many people over the years, including Paul Kyzivat, Tasvir Shah, and
   Jon Peterson.


11.  References

11.1.  Normative References

   [1]   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.

   [2]   Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
         (SIP): Locating SIP Servers", RFC 3263, June 2002.

   [3]   Hoffman, P., "The telnet URI Scheme", RFC 4248, October 2005.

   [4]   Moats, R., "URN Syntax", RFC 2141, May 1997.

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

   [6]   Peterson, J. and C. Jennings, "Enhancements for Authenticated
         Identity Management in the Session Initiation Protocol (SIP)",
         RFC 4474, August 2006.




Rosenberg                Expires April 19, 2007                [Page 20]

Internet-Draft               Phone Practices                October 2006


   [7]   Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing
         over IP (TRIP)", RFC 3219, January 2002.

   [8]   Schulzrinne, H., "A Uniform Resource Name (URN) for Services",
         draft-ietf-ecrit-service-urn-05 (work in progress),
         August 2006.

   [9]   Rosenberg, J., "User Agent Loose Routing in the Session
         Initiation Protocol (SIP)",
         draft-rosenberg-sip-ua-loose-route-00 (work in progress),
         October 2006.

   [10]  Rosen, B., "Dialstring parameter for the Session Initiation
         Protocol Uniform Resource  Identifier",
         draft-rosen-iptel-dialstring-04 (work in progress), June 2006.

11.2.  Informative References

   [11]  Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Mapping of
         Integrated Services Digital Network (ISDN) User Part (ISUP)
         Overlap Signalling to the Session Initiation Protocol (SIP)",
         RFC 3578, August 2003.

   [12]  Elwell, J., Derks, F., Mourot, P., and O. Rousseau,
         "Interworking between the Session Initiation Protocol (SIP) and
         QSIG", BCP 117, RFC 4497, May 2006.

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

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

   [15]  Yu, J., "NP Parameters for the "tel" URI",
         draft-ietf-iptel-tel-np-11 (work in progress), August 2006.

   [16]  Stastny, R., "The ENUM Dip Indicator parameter for the "tel"
         URI", draft-ietf-iptel-tel-enumdi-05 (work in progress),
         June 2006.

   [17]  Jennings, C. and V. Gurbani, "Representing trunk groups in tel/
         sip Uniform Resource Identifiers (URIs)",
         draft-ietf-iptel-trunk-group-09 (work in progress),
         October 2006.

   [18]  Livingood, J. and R. Shockey, "IANA Registration for an
         Enumservice Containing PSTN Signaling Information",



Rosenberg                Expires April 19, 2007                [Page 21]

Internet-Draft               Phone Practices                October 2006


         draft-ietf-enum-pstn-05 (work in progress), August 2006.

   [19]  Shockey, R., "IANA Registration for an Enumservice Calling Name
         Delivery (CNAM)  Information and IANA Registration for Media
         type 'application/cnam'", draft-ietf-enum-cnam-04 (work in
         progress), September 2006.

   [20]  Hardie, T., "LoST: A Location-to-Service Translation Protocol",
         draft-ietf-ecrit-lost-01 (work in progress), September 2006.

   [21]  Yu, J., "DAI Parameter for the "tel" URI", draft-yu-tel-dai-00
         (work in progress), October 2006.







































Rosenberg                Expires April 19, 2007                [Page 22]

Internet-Draft               Phone Practices                October 2006


Author's Address

   Jonathan Rosenberg
   Cisco Systems
   600 Lanidex Plaza
   Parsippany, NJ  07054
   US

   Phone: +1 973 952-5000
   Email: jdrosen@cisco.com
   URI:   http://www.jdrosen.net








































Rosenberg                Expires April 19, 2007                [Page 23]

Internet-Draft               Phone Practices                October 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Rosenberg                Expires April 19, 2007                [Page 24]