One document matched: draft-rosenberg-rai-phone-names-numbers-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 01:47:59 |