SIPPING Working Group J. Peterson
Internet-Draft H. Liu
Expires: August 9, 2002 J. Yu
NeuStar
B. Campbell
dynamicsoft
February 8, 2002
Using ENUM for SIP Applications
draft-ietf-sipping-e164-01
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 August 9, 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
Although SIP was clearly one of the primary applications for which
ENUM was created, there is nevertheless widespread uncertainty about
the demarcation of SIP location services from ENUM. This document
attempts to sharpen the distinction between location services
provided by the two protocols, illustrating how the two protocols
might work in concert and clarifying the authoring and processing of
ENUM records for SIP applications.
Peterson, et al. Expires August 9, 2002 [Page 1]
Internet-Draft Using ENUM for SIP Applications February 2002
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. ENUM: Resources and Protocols . . . . . . . . . . . . . . . 5
2.1 Telephone Numbers & the Internet . . . . . . . . . . . . . . 5
2.2 The Space of ENUM . . . . . . . . . . . . . . . . . . . . . 6
3. SIP and ENUM . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 Overview of SIP Capabilities . . . . . . . . . . . . . . . . 8
3.2 E.164 Numbers in SIP Requests . . . . . . . . . . . . . . . 9
3.3 Addresses-of-record in SIP . . . . . . . . . . . . . . . . . 10
3.4 ENUM and SIP Location Services . . . . . . . . . . . . . . . 11
3.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 14
4. Authoring NAPTR records for SIP . . . . . . . . . . . . . . 16
4.1 The Service Field . . . . . . . . . . . . . . . . . . . . . 16
4.2 Flags in NAPTR RR . . . . . . . . . . . . . . . . . . . . . 17
4.3 Creating the Regular Expression: Matching . . . . . . . . . 17
4.3.1 Creating the Regular Expression: The URI . . . . . . . . . . 17
4.4 Provisioning multiple NAPTR records . . . . . . . . . . . . 18
4.4.1 tel URL v. SIP URI . . . . . . . . . . . . . . . . . . . . . 19
4.4.2 Composing SIP services with ENUM . . . . . . . . . . . . . . 20
4.5 Setting Order and Preference amongst Records . . . . . . . . 21
4.6 Example of a Well-Formed ENUM NAPTR Record Set . . . . . . . 22
5. Processing ENUM records . . . . . . . . . . . . . . . . . . 23
5.1 Selecting a number for a query . . . . . . . . . . . . . . . 23
5.2 Examining Service fields . . . . . . . . . . . . . . . . . . 23
5.3 Handling Order and Preference . . . . . . . . . . . . . . . 24
5.4 Contending with multiple SIP records . . . . . . . . . . . . 25
5.5 Processing NATPR records in a client . . . . . . . . . . . . 25
6. Limits of ENUM . . . . . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 32
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 33
References . . . . . . . . . . . . . . . . . . . . . . . . . 31
B. To Do . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Full Copyright Statement . . . . . . . . . . . . . . . . . . 35
Peterson, et al. Expires August 9, 2002 [Page 2]
Internet-Draft Using ENUM for SIP Applications February 2002
1. Introduction
ENUM (E.164 Number Mapping, RFC2916 [1]) is a system that uses DNS
(Domain Name Service, RFC1034 [2]) in order to translate certain
telephone numbers, like '+12025332600', into URIs (Uniform Resource
Identifiers, RFC2396 [3]), like 'sip:user@sipcarrier.com'. ENUM
exists primarily to facilitate the interconnection of systems that
rely on telephone numbers with those that use URIs to route
transactions.
SIP (Session Initiation Protocol, RFC2543 [4]) is a text-based
application protocol that allows two endpoints in the Internet to
discover one another in order to exchange context information about a
session they would like to share. Common applications for SIP
include Internet telephony, instant messaging, video, Internet gaming
and other forms of real-time communications. SIP is a multi-service
protocol capable of initiating sessions involving different forms of
real-time communications simultaneously.
The creators of ENUM quickly recognized its relevance to SIP. SIP is
frequently used in telephony applications in which calls originate
within the PSTN (Public Switched Telephone Network), traverse a PSTN-
SIP gateway and terminate on an SIP endpoint; in these scenarios, the
utility of deriving a SIP URI from a telephone number is pretty
obvious. But moreover the telephone number will undoubtedly continue
to enjoy widespread use for many years to come - even some native SIP
phones have user interfaces that are essentially traditional DTMF
number pads.
Despite the fact that ENUM and SIP provide very different services
there is a small amount of overlap in their capabilities. For
example, SIP can use telephone numbers within URIs instead of
addresses in the 'user@domain' form. Also, SIP supports entities
called 'location services' that facilitate routing based on URIs.
Unfortunately, this overlap has lead to some confusion about how the
two protocols should be used in tandem - some parties have attempted
to implement what amounts to SIP location services in ENUM, while
others have maintained that ENUM provides merely a subset of SIP's
capabilities and is therefore unnecessary for SIP architectures.
This uncertainty is deepened by ambiguities in the ENUM standard that
must be resolved before the structure of records and the logic for
processing records can be well understood.
This document aspires to demarcate the roles of SIP and ENUM by
proposing an architecture in which the two systems can profitably
interact. Guidelines are proposed for the authoring of the DNS
records used by ENUM, and for client-side processing once these DNS
records have been received.
Peterson, et al. Expires August 9, 2002 [Page 3]
Internet-Draft Using ENUM for SIP Applications February 2002
The remainder of this document is organized as follows: sections 2
and 3 provide an informative high-level overview of ENUM and SIP and
discuss their relationship, proposed normative guidelines for ENUM
record authoring and processing in the context of SIP are described
in Sections 4 and 5 respectively, and limitations of ENUM are
discussed in Section 6.
Peterson, et al. Expires August 9, 2002 [Page 4]
Internet-Draft Using ENUM for SIP Applications February 2002
2. ENUM: Resources and Protocols
ENUM is a mechanism for grouping URIs associated with particular
protocols under a common identity, namely an E.164 [5] number. An
E.164 number is a globally-unique, language-independent identifier
for a logical resource in the telephone network. E.164 itself is an
standard for the assignment of telephone numbers within an
international, ubiquitously-reachable framework.
2.1 Telephone Numbers & the Internet
Historically, telephone numbers corresponded directly to physical
resources in the network; the digits of a number literally
corresponded to physical coordinates on a switching plane. Over
time, telephone numbers began to identify logical rather than
physical resources. For example, in order to terminate a call to a
freephone (in the USA, 1-800) number, the network must translate the
freephone number into a regular number, and this translation may
depend on time of day or the location of the caller. Today we take
it for granted that a wireless phone number inevitably identifies
both the wireless device carried by the user and a voicemail
terminal, elsewhere in the network, that is contacted when the user
is unavailable. The introduction of follow-me services allows a call
to a single number to attempt connections to multiple terminals - in
the office, the home, or the car, then maybe a pager - in order to
reach a particular person who moves between these devices. Users of
the telephone network are therefore accustomed to the idea that many
logical destinations may be grouped under an E.164 number.
However, in order to invoke, or even learn about, any of the PSTN
resources under an E.164 number, the originating user must attempt to
place a call. An E.164 number is a relatively opaque identifier -
staring at a telephone number one might be able to get a rough sense
of the geographic location of its (home) network, or the comparative
expense of placing a call to it, but nothing about the resources that
will be reached is obvious from the identifier itself (excepting
perhaps 1-800-FLOWERS and its ilk). Once you launch a call you may
hear a live human, a fax, an voice browser, or a message that the
number has been disconnected.
The Internet adopts, in quite a few respects, a very different
attitude towards reaching resources. Internet endpoints controlled
by end users may be general purpose computers with sophisticated user
interfaces that explicitly establish network connections with
resources selected by the end user. Endpoints listen on standardized
ports for requests associated with application capabilities. These
ports can each accommodate a specific service associated with a
particular protocol. Protocols tend to be customized to a specific
Peterson, et al. Expires August 9, 2002 [Page 5]
Internet-Draft Using ENUM for SIP Applications February 2002
capability of the endpoint; one protocol is optimized for carrying
mail traffic, another for carrying Internet game traffic. One common
way of identifying a resource in the Internet is a URI, and by
inspecting a URI one can commonly ascertain its purpose and even the
logical domain in which the resource exists; for example,
'mailto:jon.peterson@neustar.biz'.
By way of contrast, a PSTN user's endpoint (the venerable 'black
phone') has one real capability - rendering audio media. Similarly,
end users have only one 'protocol' for interacting with the PSTN -
picking up the phone and placing a call. Any and all services in the
PSTN are reachable through this lone 'protocol'. But in the Internet
model, you must choose one of many protocols before you attempt to
create a network connection, and the choice of protocol usually
limits the sorts of services that might be reached.
2.2 The Space of ENUM
ENUM is the intersection of the PSTN convention for naming resources
with the Internet model of protocols. ENUM allows an endpoint to
inspect the Internet protocols that are associated with an E.164
number before attempting to initiate any communication. Among other
things, this allows endpoints to choose appropriate protocols to
communicate with resources grouped under an E.164 number. Once a
protocol has been selected for communication, endpoints derive from
ENUM records a URI that designates the resource with which a network
connection should be established.
ENUM is both a technology and a policy. From its inception, it has
aspired to be a tool for namespace management for the national
numbering administrations participating in the international E.164
system. ENUM mandates that only one record set should correspond to
each E.164 number, and that these records should be delegated from a
single 'golden root' (known as 'e164.arpa'). Much of the utility of
ENUM derives from the fact that there is only a single logical place
in the Internet where clients need to look for information about a
given E.164 number, and that this place provides an authoritative
record set that is sanctioned by the national numbering plan
administrator for that number. With this utility comes a limitation
- clients that perform ENUM queries must know how to render a
telephone number in international form (e.g. if a user in the
Washington D.C. dials '5332600', a client processing this number
must transform it into '+12025332600' before launching an ENUM
query). Also, ENUM cannot operate on private dialing plans or other
numbering systems outside the scope of the E.164 plan.
Although ENUM guarantees that responsibility for the record set
corresponding to a given telephone number descends from policies of
Peterson, et al. Expires August 9, 2002 [Page 6]
Internet-Draft Using ENUM for SIP Applications February 2002
the national numbering authorities, this makes no assumption about
who authors ENUM records, or how they happen to be provisioned.
Governments, carriers, corporations or users could all possibly be
authors of ENUM record sets, subject to local regulatory and market
forces; note that this document has no dependency on which parties
happen to control the population of ENUM records. Similarly, ENUM
makes no assumptions about who consumes ENUM records (between, say,
carriers and end users) - all parties that can use ENUM will have
access to the same records since there is only one ENUM record set
per E.164 number.
Finally, although ENUM records offer a set of protocols that can be
used to reach services, protocols and services in the Internet are
not the same thing. Admittedly, some protocols are very specific
tools that are invariably used for a single service; for example, an
FTP URL found in an ENUM record set isn't likely to be useful for
anything other than file transfer. However, some protocols (like DNS
itself) play a support role, assisting in the invocation of other
protocols. SIP falls into this same category in so far as it is
ultimately a facilitator for other protocols - SIP signaling is used
to establish a session that in turn carries the real data that end
users would like to exchange. As such, a SIP URI could be used to
invoke any of the sorts of sessions that SIP can administer, and
therefore the 'sip' URI scheme, although it designates a protocol,
cannot be said to represent any particular type of service or
resource.
Peterson, et al. Expires August 9, 2002 [Page 7]
Internet-Draft Using ENUM for SIP Applications February 2002
3. SIP and ENUM
3.1 Overview of SIP Capabilities
SIP is not a protocol that offers a direct service to end users, like
access to file transfer or exchange of hypertext documents. Rather,
SIP helps you to find the best way to communicate with a remote
resource. It employs a number of mechanisms, including registration
of the location of endpoints, discovery of endpoints by routing
requests through proxy servers, and various forms of capability
negotiation, to allow a set of endpoints to establish an optimal
communication path.
Typically, a SIP user agent forms a SIP request for a particular
destination URI that advertises its own capabilities and preferences,
and then hands this request over to a proxy server for delivery. In
some respects this is reminiscent of the PSTN user who picks up the
phone and dials without knowing what sort of resource will be
reached. However, SIP represents a substantial improvement over that
model.
First of all, SIP has an innate mechanism for discovering the right
device to field a call for a particular user's identity. A SIP
device can register dynamically (through the use of the REGISTER
request) at the administrative domain of the user's identity when the
user becomes available through the device, and de-register when the
user has departed. Proxy servers take into account the set of
registered devices when determining how to route a request. A SIP-
based follow-me service, for example, would rely on this real-time
availability data in order to find immediately the best place to
reach the end user - without having to cycle through numerous devices
from which the user is not currently registered.
Secondly, SIP has a process for negotiating the sorts of sessions its
users would like to share. Like email messages, SIP requests consist
of headers followed by one or more bodies. A common type of body
contained in a SIP request is SDP (Session Description Protocol,
RFC2327 [10]), which is used to advertise various potential
connections that could be used to send real-time session data. When
creating a request for a session, SIP endpoints frequently offer as
many types of communication in the SDP as possible in order to find
common ground with the remote resource; one SDP could contain, for
example, offers for voice, video and instant messaging channels
simultaneously. The remote resource, when it receives the request,
may accept some or all of these channels as appropriate.
Several logical roles are defined for SIP network entities. The most
significant are those of user agents, which may act for a particular
Peterson, et al. Expires August 9, 2002 [Page 8]
Internet-Draft Using ENUM for SIP Applications February 2002
transaction as either a client or server, and those of proxy servers,
which forwards SIP requests between user agents or one another.
Another significant role is the redirect server, which receives a
request from a user agent and responds with a redirection message
that prompts the user agent to send the same request to a different
destination. Note that a common SIP phone and a PSTN-SIP gateway
both act as SIP user agents.
Any SIP entity could potentially launch an ENUM query when it needs
to operate on an E.164 number. Whether or not it does so is largely
a matter of its capabilities and its local policies; SIP has no
built-in way to route calls based on E.164 numbers, and ENUM
certainly offers one such mechanism. Note that if ENUM is
implemented in a proxy server, it may change the destination of a SIP
session in a manner of which the client would like to be informed;
for example, from a local SIP telephony call to an international
call. ENUM is probably best employed by a user agent prior to the
creation of a request, rather than by proxy servers; this also
simplifies routing and provides the end user with the most
flexibility (especially when their endpoint supports multiple
communications protocols). Also note that when ENUM is invoked by an
intermediary in the network, the selection of a protocol must be made
by the intermediary in ignorance of the client's protocol
capabilities; most likely, a SIP proxy server would be able to deduce
only that the originating user supported SIP.
3.2 E.164 Numbers in SIP Requests
There are a number of reasons why a user might want to initiate a SIP
request that targets an E.164 number. One common reason is that the
user is calling from the PSTN through a PSTN-SIP gateway; such
gateways usually map routing information from the PSTN directly on to
SIP signaling. Or a native SIP user might intentionally initiate a
session addressed to an E.164 number - perhaps because the target
user is canonically known by that number, or the originator's SIP
user agent only supports a traditional numeric telephone keypad. A
request initially targeting a conventional SIP URI might also be
redirected to an E.164 number. In all of these cases a user agent
could use ENUM to discover a SIP URI associated with the E.164
number. But what would the user agent do otherwise?
If a user agent is unable to translate an E.164 number, it can create
a type of SIP Request-URI that contains a telephone number. Since
one of the most common applications of SIP is telephony, a great deal
of attention has already been devoted to the representation of
telephone numbers in SIP. In particular, the tel URL RFC2806 [6] has
been identified as a way of carrying telephone routing information
within SIP. A tel URL usually consists of the number in E.164 format
Peterson, et al. Expires August 9, 2002 [Page 9]
Internet-Draft Using ENUM for SIP Applications February 2002
preceded by a plus sign, e.g: tel:+12025332600. This format is so
useful that it has been incorporated into the baseline SIP
specification; the user portion of a SIP URI contain a tel URL
(without the scheme string, like sip:+12025332600@carrier.com). A
SIP proxy server might therefore receive a request from a user agent
with a tel URL in the Request-URI; one way in which the proxy server
could handle this sort of request is by launching an ENUM query
itself and proxying the SIP request in accordance with the returned
ENUM records.
Why is a URI so much easier to route than an E.164 number? The
'user@domain' composition of a SIP URI suggests how routing should
occur - go to 'domain' and inquire about 'user'. A tel URL, however,
contains no contextual data of this nature. All number blocks (like
'+1202533') may very well belong to some specific service provider,
but the blocks themselves give no indication of who that carrier
might be. Even when a tel URL appears within a SIP URI, as in
'sip:+12025332600@sipcarrier.com', this does not necessarily mean
that sipcarrier.com owns the corresponding number block - it merely
means that one should go to sipcarrier.com, which will presumably
attempt to route the call from there.
One of the most important uses of ENUM is that it provides valuable
context information about a telephone number - specifically, the
means of contacting the administrative domain that is responsible for
the number. When the reverse resolution string is created for an
E.164 number and the request is resolved within the e164.arpa
hierarchy, the request will automatically be delegated to the
nameserver that hosts the record for the number in question. Note
that this context is provided, however, only for E.164 numbers; since
tel URLs can also carry non-geographic numbers, services codes (like
x11 in the United States), and numbers in private dialing plans,
these URLs retain some utility outside ENUM's scope.
In the absence of a mechanism like ENUM, or if ENUM requests return
no records, local policy can be used to determine how to forward
requests for E.164 numbers. These sorts of policies are frequently
used to route calls to gateways that interconnect SIP networks with
the PSTN.
3.3 Addresses-of-record in SIP
When a SIP device (specifically a user agent) sends a registration to
a registrar on behalf of its user, the device associates its contact
address with the user's address-of-record. An address-of-record is a
SIP URI that serves as a permanent identity for a user, for example,
'sip:user@sipcarrier.com'. Upon receiving the registration request,
the registrar will in turn modify the provisioning data in a location
Peterson, et al. Expires August 9, 2002 [Page 10]
Internet-Draft Using ENUM for SIP Applications February 2002
service, creating a mapping between the address-of-record for the
user and the device where the user can currently be reached. When
future requests arrive at the administrative domain of this location
service for the user in question, proxy servers ask the location
service where to find the user.
The difference between a contact address and an address-of-record is
like the difference between a device and its user. A contact address
is associated with a particular device, and may have a very device-
specific form (like sip:10.0.0.1). An address-of-record, however,
represents a permanent identity of the user, and it should not have a
dependency on any device; it can move between devices or even be
associated with multiple devices at one time. A simple URI,
generally of the form 'sip:user@domain' should be used for an
address-of-record.
When a SIP request is created in a user agent, it usually contains
the address-of-record of its destination in its To header field and
Request-URI. Ideally, an address-of-record should be used to
populate the URI field of ENUM records for SIP applications.
When a SIP entity (be it a user agent or proxy server) needs to make
a forwarding decision for a Request-URI containing an address-of-
record, it uses the mechanisms described in the SIP specification
(RFC2543). Basically, it resolves the domain portion of the URI
(sipcarrier.com in the example above) in order to route the call to a
proxy server that is responsible for that domain.
3.4 ENUM and SIP Location Services
Readers familiar with SIP are no doubt already aware that there is a
concept in SIP of a directory that can group multiple URIs under a
single identity - the location service. At first glance, it might
not be clear what the differences are between a specific application
of the location service concept and ENUM. For example, one could
imagine a location service in which the keys are 'tel' URLs (like
'tel:+12025332600') and the values are SIP URIs in address-of-record
form (like 'sip:jon.peterson@neustar.biz') alongside any other URIs
for distinct protocols desired by the user. If this location service
were consulted by a redirect server, then it could be queried in a
fashion similar to ENUM.
Superficially, the two might seem like they provided the same
capabilities. For example, both query mechanisms can express
relative preference within a record set (NAPTR records support a
preference field, while contact addresses in a SIP redirect message
contain 'q' values that suggest a preferred order). However, there
are a number of important respects in which the two differ. Note
Peterson, et al. Expires August 9, 2002 [Page 11]
Internet-Draft Using ENUM for SIP Applications February 2002
that this section makes no judgment about the superiority of either
approach, but it is intended that these distinctions will clarify the
applicability of these mechanisms to potential deployments.
Request vs. Query: Some sort of SIP request must be sent in order to
query a redirect server - generally it is only in the process of
attempting to initiate a session that a SIP client can access a
location service. An ENUM request can be sent independently of
any attempt to initiate a session. This can be a meaningful
difference when the location service would return URI schemes
indicating a protocol other than SIP. If a client wants to learn,
say, the 'mailto' URI associated with a telephone number, it might
not be desirable to have to attempt to initiate a SIP session in
order to discover it.
Authentication: A redirect server can challenge a SIP client to
provide authentication before processing a query. ENUM, like all
DNS systems, returns the same records regardless of the identity
of its client, and therefore has no means nor need for
authentication. Significantly, a redirect server can therefore
make policy decisions about the records it returns based on the
authenticated identity of the client, whereas ENUM cannot.
Registration: SIP supports dynamic registrations of contact addresses
in a location service; in addition to supporting an interface to
query a location service, SIP also supports an interface to
provision a location service in real-time, including ways to
expire and refresh registrations as appropriate, authenticate
registrations, and so forth. ENUM describes only a query system -
how ENUM record sets are uploaded to DNS servers is not in the
scope of DNS. Generally, however, DNS records are not updated in
real-time, and ENUM makes no special provision for real-time
responsiveness. Frequently, DNS records are assigned
comparatively long time-to-live (TTL) values, especially due to
the prevalence of record caching.
Delegation: ENUM is designed to be delegated from the 'golden root'
server to individual country codes, and within these country codes
potentially to carriers or organizations that own individual
numbers or number blocks. ENUM is designed to easily delegate at
the granularity of individual digits in an E.164 numbers (through
the reverse-resolution e164.arpa domain). It isn't clear how this
sort of delegation would occur with 'tel' URLs in a location
service; redirection triggering on a partial URI (like matching
'tel:+1202533*') is in any event not described in baseline SIP.
Moreover, the manner in which delegation might operate in SIP
raises some performance concerns if it involves multiple
redirections. Delegation in DNS is comparatively well understood.
Peterson, et al. Expires August 9, 2002 [Page 12]
Internet-Draft Using ENUM for SIP Applications February 2002
Caching: A redirection message in SIP can contain an Expires header
field that indicates how long the information it contains will be
valid. However, this Expires header field is generally only
processed by endpoints, which means that each endpoint must cache
this data itself. DNS utilizes network-based caching - each ENUM
client would presumably place requests through a local caching
server that would persist redirection addresses when appropriate.
Network-based caching is generally a more scalable architecture
for persisting query responses.
Forking: SIP has a mechanism for exploring multiple possible
destinations for a request called forking. Multiple destinations
can be tried in parallel or sequentially, as specified by local
policy and some elements in signaling. It is common for redirect
servers to return multiple destinations in a redirect message.
However, it is less clear that the multiple URIs that are used in
ENUM records should be forked in this fashion; this is detailed in
Section 4.4.
Policy: ENUM is half a technology and half a policy. While a
location server could be provisioned with a set of E.164 number
keys, nothing prevents any other location server from creating
records for the same set of keys with different values. The
centralized ENUM model prevents this sort of conflict from
arising. ENUM records are also known to be authoritative for the
record in question, which reduces the possibility of slamming or
other forms of service hijacking. However, this policy introduces
some limitations - ENUM can only operate on full E.164 numbers,
not on private dialing plans or numbers that have not been
rendered in an international format. This may also introduce some
complications when dealing with partial numbers (such as when
overlap dialing is used from the PSTN) - SIP, on the other hand,
has a mechanism for contending with an incomplete address.
Query String: When an ENUM query is launched, essentially the only
information that is provided in the query is the would-be Request-
URI of a SIP request, in ENUM cases a telephone number. However,
when a SIP request lands at a redirect server, the redirect server
could, if it were so inclined, consult parts of the request other
than the Request-URI in order to make a routing decision. For
example, the redirect server could inspect the domain of the From
field in hopes of learning the closest destination to which it
could redirect the client.
Performance: DNS is a very lightweight protocol that serves only one
purpose - record retrieval. All processing of these records is
performed locally at the client. SIP, however, is a textual
protocol that requires a great deal of server-side processing.
Peterson, et al. Expires August 9, 2002 [Page 13]
Internet-Draft Using ENUM for SIP Applications February 2002
SIP requires a minimum of three messages to complete a query (e.g.
INVITE/3xx/ACK) whereas DNS requires only two, a query and an
answer. It is widely believed that the DNS server model is very
scalable.
3.5 Conclusions
The distinctions outlined in the preceding section do not address
what happens after either ENUM or a SIP redirect server returns a SIP
URI to a client - namely, the client sends an appropriate SIP request
(such as an INVITE) based on the received URI that expresses the
client device's communication capabilities. The expression of these
capabilities may entail the usage of SDP to list acceptable types of
media supported and favored by the client, the inclusion of
Required/Supported headers to negotiate compatibility of extensions,
and possibly even the usage of optional SIP mechanisms, for example
using caller/callee preferences [7] to communicate request handling
dispositions. Proxy servers or endpoints subsequently return
responses that allow a true bidirectional capability negotiation
process.
It must be acknowledged that the process by which SIP endpoints
negotiate capabilities can overlap (and in some sense compete) with
the primary service provided by NAPTR records: permitting the
originating client to select a particular URI for communications
based on an ordered list of protocols. ENUM's capability management
mechanism is decidedly one-way - the administrator of the telephone
number expresses capabilities (in the form of protocol names) and
preferences that the client must evaluate without negotiation. It is
also not clear that authors of ENUM records will necessarily be able
to anticipate the capability of the particular device to which a URI
will direct communications requests at any given moment - URIs
generally do not always point to the same device (when they do, they
might as well be replaced with an IPv4 address). Listing available
protocols is also not really comparable to the agreement on session
media (down to the codec level) and protocol extension support. The
negotiation capabilities in SIP described above clearly are far more
versatile and useful than the selection of a protocol for
communications.
However, although ENUM's vocabulary for expressing capabilities is
smaller than SIP's, ENUM has a number of strengths that make it
useful for the association of a telephone number with a SIP address-
of-record - such as its foundation in policy, and its scalability and
delegation characteristics. For that reason, it is the contention of
this document that ENUM's primary applicability to SIP is to provide
a SIP address-of-record corresponding to an E.164 telephone number.
Peterson, et al. Expires August 9, 2002 [Page 14]
Internet-Draft Using ENUM for SIP Applications February 2002
Listing SIP contact addresses rather than addresses-of-record in ENUM
is discouraged because it hampers the proper operation of SIP; SIP's
superior dynamic registration capability makes it far better manager
of contact addresses than ENUM, which not only defines no means for
devices to register, but moreover ENUM records generally must have
some longevity in order for the protocol to scale properly. Many
non-SIP URIs associated with real-time communication (tel URLs and
instant messaging URLs, for example) seem more like contact addresses
that should be managed by the SIP registration process, rather than
URIs that might be listed in ENUM. URLs that are not associated with
real-time communications, like email or http URLs, are probably
better candidates to be provisioned directly in ENUM (it is unlikely
that, for example, email addresses would benefit from dynamic
registration capabilities).
The normative language in the following two sections makes
recommendations that follow this view of the relationship and
demarcation of ENUM and SIP. Because of the public nature of ENUM,
it would be wrong-headed to assume that only clients interested in
SIP will attempt to use ENUM records - in any event authors of ENUM
records cannot guarantee that only a limited group of users will
attempt to contact them. That much said, the primary existing use of
telephone numbers is telephony (or more generally real-time
communications), and therefore it isn't especially unreasonable to go
forward on the assumption that SIP is ENUM's primary customer, nor to
create records that are intended for use by SIP clients. For that
reason, the recommendations that follow frequently suggest that SIP
records be preferred, in various ways, to records of other protocols.
Peterson, et al. Expires August 9, 2002 [Page 15]
Internet-Draft Using ENUM for SIP Applications February 2002
4. Authoring NAPTR records for SIP
The guidelines in this section are oriented towards authoring records
specifically for SIP applications. These guidelines assume that the
reader is familiar with RFC2915 [9]) and RFC2916 [1]). Only those
aspects of NAPTR record authoring that have special bearing on SIP,
or that require general clarification, are covered in this document;
otherwise the procedures in the appropriate RFCs should be followed.
This document makes no assumptions about who authors NAPTR records
(service providers or end users), nor about any mechanisms by which a
record, once it is authored, may be uploaded to the appropriate DNS
servers. Authorship in the context of this document concerns only
the processes by which the NAPTR records themselves are constructed.
There are a few general guidelines which are applicable to the
authoring of DNS records that should be considered by the authors of
ENUM NAPTR record sets. The most important is that authors SHOULD
keep record sets relatively small - DNS is not optimized for the
transference of large files. Having five or six NAPTR records is
quite reasonable, but policies that encourage records sets of
hundreds of NAPTR records are not appropriate. Also, DNS records are
relatively permanent; authors SHOULD NOT use ENUM NAPTR records to
express relationships between E.164 numbers and URIs that potentially
exist for only a short time. DNS is most scalable when it can assume
records will be valid for a reasonable length of time (at least
several hours).
4.1 The Service Field
The Services field of a NAPTR record contains a string that is
composed of two subfields: a 'protocol' subfield and a 'resolution
service' subfield. The examples used in RFC2915 suggest that the
protocol subfield commonly corresponds to the name of a URI scheme
(i.e. 'tel', 'sip', 'mailto'). ENUM in particular defines an 'E2U'
(E.164 to URI) resolution service.
In all of the examples in RFC2915 and RFC2916 in which a SIP URI is
the result of a NAPTR transformation, the 'sip+E2U' token is present
in the service field. It is strongly RECOMMENDED that authors of
NAPTR records use the 'sip+E2U' service field whenever the regexp
contains a SIP URI.
Implementers of ENUM have argued in the past that new service fields
need to be created that provide a greater level of granularity than
the existing 'sip+E2U' token. Some of the motivation for providing
granular service fields for SIP is predicated on the use of multiple
SIP records in a single ENUM record set to characterize different
Peterson, et al. Expires August 9, 2002 [Page 16]
Internet-Draft Using ENUM for SIP Applications February 2002
services associated with an identity. This motivation is analyzed
below in Section 4.4.2.
4.2 Flags in NAPTR RR
Authors of NAPTR records MUST use the terminal "u" flag when any
'E2U' based service field, including 'sip+E2U', is specified.
4.3 Creating the Regular Expression: Matching
The authorship of the regular expression (henceforth regexp) in a
NAPTR record intended for use by ENUM is vastly simplified by the
absence of an antecedent in the substitution (i.e. the section
between the first two delimiters). It is RECOMMENDED that
implementations use an exclamation point as a delimiter, since this
is the only delimiter used throughout the ENUM examples in RFC2915
and RFC2916.
Ordinarily, when a NAPTR record is processed, the expression in the
antecedent is matched against the starting string (for ENUM, the
telephone number); however, in ENUM applications, since the desired
record set is located through a reverse resolution in the e164.arpa
domain that is based on the starting string, further analysis of the
starting string on the client side would be redundant. Therefore,
the antecedent of the regular expression is always 'greedy' - it uses
the regexp '^.*$', which matches any query string. Authors of
records intended to be used for SIP applications SHOULD always use a
greedy regexp.
Example: "!^.*$!sip:info@tele2.se!"
Although the antecedent of the regexp is not factored into ENUM
applications, that does not mean that the replacement field provides
a viable alternative. Authors of NAPTR records for ENUM MUST NOT use
the replacement field in records with an 'E2U' service field.
4.3.1 Creating the Regular Expression: The URI
The consequent side of a regexp contains a URI; NAPTR records that
are intended to be used for session initiation (including SIP
telephony) SHOULD use a SIP URI. While this may not sound especially
controversial at first hearing, there are other sorts of URIs that
might be considered appropriate for SIP applications: 'tel' URLs,
'im' or 'pres' URLs, or others that describe specific services that
might be invoked through SIP are all potentially candidates. While
the use of these URLs might seem reasonable under some circumstances,
including these in NAPTR records rather than SIP URIs could weaken
the proper composition of services and negotiation of capabilities in
Peterson, et al. Expires August 9, 2002 [Page 17]
Internet-Draft Using ENUM for SIP Applications February 2002
SIP.
While there is no hard law in any of the existing literature that
states that authors of a NAPTR record for ENUM should match the
protocol subfield of the service field with the scheme of the URI in
the regexp, this practice is followed in all of the examples, and
therefore it is RECOMMENDED that authors of ENUM records should
always use the SIP URI scheme when the service field is 'sip+E2U'.
SIP URIs within NAPTR record SHOULD contain an address-of-record (as
described in Section 3.3) rather than a URI that depends on
particular hosts (like an IP address or hostname). Users can
register one or more contact addresses with a registrar that will be
used by the proxy infrastructure of an administrative domain to
contact the end user when requests are received for their address-of-
record. Putting URIs corresponding to devices through which a user
is sometimes available into NAPTR records is NOT RECOMMENDED. Much
of the benefit of using a URI comes from the fact that it represents
a logical service associated with a user rather than a device -
indeed, if ENUM needed to target devices, 'sip+E2IPv4' would be a
more appropriate resolution service to define.
4.4 Provisioning multiple NAPTR records
In all of the examples in RFC2916, a single NAPTR record with an
'sip+E2U' service field appears in each set of records. However,
this 'sip+E2U' record always appears in conjunction with at least one
other record. The circumstances under which authors of records
should supply multiple NAPTR records, especially multiple records for
the same service field value, are not clear. What would it mean if
multiple SIP records were present?
The most important question to consider is the rationale for
including multiple ENUM records for SIP. One possible reason is that
a user might wish to include a NAPTR record corresponding to each SIP
device they use regularly - this would however be a mistake. The SIP
registration mechanism provides a much more appropriate way to group
multiple devices under a single identity; for one thing, registration
allows particular devices to represent their availability
dynamically. ENUM records are not designed to be updated in real
time, and therefore ENUM is not a good mechanism for managing
particular devices.
Another possibility is that a user may have one or more SIP
identities, each of which has its own address-of-record. This could
be the case if the user subscribes to SIP services from multiple
service providers (with URIs like 'sip:user@sipcarrier1.com' and
'sip:user@sipcarrier2.com'), or has different identities for work and
Peterson, et al. Expires August 9, 2002 [Page 18]
Internet-Draft Using ENUM for SIP Applications February 2002
for home. How would authors of NAPTR records select only one of
these addresses-of-record? Should each be placed in its own NAPTR
record in the record set, possibly differentiated by preference?
This is a sort of pseudo-problem, since the real issue is where the
devices employed by the user will register. If device registrations
are distributed across the two addresses-of-record, and this
circumstance is for whatever reason outside the user's control, then
unfortunately placing both addresses-of-record in ENUM wouldn't help,
because the client that originated the ENUM query would have no basis
to choose between the two NAPTR records in order to find some
particular sort of device. The preferred thing for the NAPTR record
author to do in this circumstance is to register one address-of-
record under the other (like a work identity registered under a home
identity), and then to treat the umbrella address-of-record as the
one that should be provisioned within ENUM.
Finally, ENUM records are accessible to the public, and therefore the
author of a NAPTR record set for ENUM cannot assume that any
particular sort of client will be the sole consumer of their NAPTR
records. The intention behind the use of multiple NAPTR records for
SIP cannot be communicated by ENUM, and thus the author of a record
set cannot assume any specific local policy will be applied to the
interpretation of these records by any given ENUM client.
For these reasons, rather than supplying multiple SIP URIs for an
ENUM service, authors of NAPTR record sets for ENUM SHOULD use only
one SIP URI.
4.4.1 tel URL v. SIP URI
Authors of ENUM record sets might want to include tel URLs and
'tel+E2U' service fields when no SIP service is associated with a
given E.164 number. Translating between one telephone number and
another via ENUM could be used as a mechanism for implementing
permanent call forwarding or various PSTN number translation
services.
Even when a 'sip+E2U' record is created to correspond to a SIP
service, some users may wish to have a separate URI for plain
telephony that is not associated with SIP for the benefit of non-SIP
clients. In this instance a 'tel+E2U' record MAY also be provisioned
alongside a 'sip+E2U' record in order to provide a back-up PSTN URI
at which the user can be reached. However, it is probably best to
treat a tel URL as a contact address, rather than an address-of-
record, and thus implementers are advised to register tel URLs with a
SIP location service rather than provisioning them in ENUM. If tel
URLS are used in ENUM as a back-up, it is RECOMMENDED that they be
Peterson, et al. Expires August 9, 2002 [Page 19]
Internet-Draft Using ENUM for SIP Applications February 2002
less preferred than SIP records.
Note that returning a telephone number in an ENUM record may very
well lead to a subsequent ENUM query. For that reason, authors of
NAPTR records SHOULD NOT, in an ENUM record set for a given E.164
number, include a 'tel+E2U' record that translates to that same
number - although hopefully, ENUM clients will have some mechanism
for detecting potential query loops caused by the receipt of a 'tel'
URL. Authors should also be mindful that further queries may
compound call setup delays, degrading the overall performance of the
system.
Although handling fax is outside the scope of this document, similar
practices could be recommended for the 'fax' URL and a 'fax+E2U'
service field, especially when for whatever reason fax capabilities
are not available as part of a user's SIP service.
4.4.2 Composing SIP services with ENUM
Some implementers of ENUM systems have suggested that the 'sip+E2U'
service field is not sufficiently specific to capture SIP's
capabilities - that new service fields should be created
corresponding to particular services that might be invoked by a SIP
user. Several formats for these new service fields have been
proposed, including specifying the communications service that will
be used by SIP in the protocol subfield (e.g. 'im+E2U', 'pres+E2U')
or as part of the resolution service subfield (e.g. 'sip+E2IM',
'sip+E2PRES'). These proposals raise a couple of concerns.
Registration and Negotiation: The first and most serious problem with
this approach is that it blurs the demarcation between ENUM and
SIP. SIP has its own capabilities for discovering the devices
associated with an address-of-record and then negotiating the best
way to communicate with these devices (see Section 3.1). Pushing
this capability forward into ENUM impoverishes SIP without
providing comparable functionality in return. Consider for
example that a SIP client can attempt to negotiate, within SDP,
both audio and video communications simultaneously for a single
request. What should a client do if it downloads an ENUM record
set that has different NAPTR records for 'sip+E2VIDEO' and
'sip+E2VOICE'? Which should it choose? Exposing through ENUM the
contact address of a device (which necessarily has a limited set
of capabilities), rather than an address-of-record, will always
significantly hamper SIP's capabilities. Mapping an E.164
identity to a device, rather than to another identity under which
devices are intelligently managed, does ENUM a disservice.
Proliferation: It is also not clear where the proposed taxonomy of
Peterson, et al. Expires August 9, 2002 [Page 20]
Internet-Draft Using ENUM for SIP Applications February 2002
SIP services should begin and end. If clients need to be able to
identify URIs that are associated with multiple services, then
composite service fields will be required with values like
'sip+E2VOICE+E2VIDEO'. Theoretically, support for N services
might entail support for N-factorial service fields. But
perfectionists could argue that even this doesn't go far enough:
if you want to advertise the capabilities of endpoints, why
specify merely that they support voice - why not also specify each
of the codecs that a particular device supports for voice
communications ('sip+E2VOICE.G711')? Any degree of proliferation
would obviously make ENUM resolvers more complex to implement, and
it isn't clear how slippery the slope of proliferation might be.
And again, it's not clear how exactly this taxonomy would surpass
the native SIP capabilities for discovering the best way for
endpoints to communicate.
Use of any service fields for SIP records other than 'sip+E2U' is,
again, NOT RECOMMENDED.
4.5 Setting Order and Preference amongst Records
Some additional confusion arises from the use of order and preference
in NAPTR records. The NAPTR algorithm dictates that once a client
has ascertained the lowest order that does not contain an
'inappropriate' NAPTR record for this query, the client MUST choose a
NAPTR record of this order.
'Appropriateness' is not defined in the standard, but we might
generously assume that the determination of the 'appropriateness' of
a NAPTR record hinges on the contents of the service field. The
draft does note that ascertaining the lowest order record depends on
whether or not the antecedent of the regular expression in the record
matches the query. But as we've already seen, the regular expression
used in NAPTR records for ENUM is always greedy, and therefore
according to the NAPTR algorithm the lowest order is, barring a more
specific interpretation of appropriateness, the only order that can
be used.
So in short, the language surrounding the NAPTR algorithm in RFC2915
is somewhat confusing, and it isn't exactly clear how order should be
used, especially since there is also a preference field that should
also be taken into consideration when selecting a NAPTR record.
Consider that in the following example from RFC2916 (where order is
the third field from the left and preference the fourth)
Peterson, et al. Expires August 9, 2002 [Page 21]
Internet-Draft Using ENUM for SIP Applications February 2002
$ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:info@tele2.se!" .
IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:info@tele2.se!" .
... the 'mailto' URI can never be reached if the client believes
both 'sip+E2U' and 'mailto+E2U' records to be 'appropriate' and the
NAPTR algorithm is strictly obeyed.
Regardless of whether or not this requires clarification in future
issues of the standard, for maximal compatibility authors of ENUM
records SHOULD always use the same order value for all NAPTR records
in an ENUM record set. If relative preference among NAPTR records is
desirable, it should be expressed solely with the preference field.
Generally, for record sets that are intended to be used primarily by
SIP clients (perhaps for SIP telephony), when multiple NAPTR records
appear alongside a 'SIP+E2U' record, it is RECOMMENDED that the SIP
record be the most preferred record. Record sets that are intended
for use by versatile clients with multiple protocol capabilities MAY
assign a SIP lesser preference, but authors should note that SIP-
based clients may choose to disregard these preferences.
4.6 Example of a Well-Formed ENUM NAPTR Record Set
$ORIGIN 0.0.6.2.3.3.5.2.0.2.1.e164.arpa.
IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:user@sipcarrier.com!" .
IN NAPTR 100 20 "u" "mailto+E2U" "!^.*$!mailto:user@sipcarrier.com!" .
Peterson, et al. Expires August 9, 2002 [Page 22]
Internet-Draft Using ENUM for SIP Applications February 2002
5. Processing ENUM records
This section addresses only those procedures in RFC2915 and RFC2916
that might pose questions for implementers concerned primarily with
SIP. These guidelines do not by any means exhaustively describe the
NAPTR algorithm or the processing of NAPTR records; implementers
should familiarize themselves with RFC2915 and RFC2916 before
reviewing this section.
Ideally, the recommendations above for authoring NAPTR records will
be followed to the letter; each NAPTR record set will contain a SIP
URI (and if possible nothing else). This section assumes that
implementers must be prepared for more complicated scenarios -
however, just because we recommend that clients should be generous in
what they receive, and try to make sense of potentially confusing
NAPTR records, that does not mean that we recommend any of the
potentially troublesome authoring practices that make this generosity
necessary.
5.1 Selecting a number for a query
Before a starting string (the telephone number to be reversed) can be
constructed in the manner described in RFC2916, the originator of the
query SHOULD make sure that the telephone number it intends to
resolve is a complete E.164 address. Network elements SHOULD have
some means of determining whether an address is complete in the E.164
system, especially when interworking with networks that use overlap
PSTN signaling. In some cases originators of ENUM queries MAY need
to modify telephone numbers before creating a query string; for
example, in North American networks by removing a leading '011' from
the raw number dialed by the end user, or prepending a country code
('1' for North America) or an area code to a national number.
5.2 Examining Service fields
When a set of NAPTR records are received by an ENUM client in
response to a query, the client must first decide which records, if
any, are appropriate for its applications.
According to the NAPTR algorithm, clients are permitted to discard
any 'inappropriate' records at the outset of processing. Here we
will gauge appropriateness by the capabilities of the client;
presumably a client will be provisioned with a set of service fields
which it supports, and all records whose service fields intersect
with this set will be considered appropriate.
ENUM clients acting on behalf of a SIP application will generally be
interested in NAPTR records that contain Service fields of 'sip+E2U';
Peterson, et al. Expires August 9, 2002 [Page 23]
Internet-Draft Using ENUM for SIP Applications February 2002
SIP telephony clients may also be interested in 'tel+E2u'. Clients
MAY make a preliminary pass on all received NAPTR records to
eliminate all records that do not contain one of these two service
fields.
If future NAPTR service fields are defined that are relevant to the
SIP application, they SHOULD also be retained in this preliminary
pass.
5.3 Handling Order and Preference
The purpose of the 'order' field of NAPTR records is related to
delegation, and is therefore not immediately significant to the ENUM
application; there is no particular reason why authors of ENUM
records would want to make use of different orders among multiple
records.
If only a single order is used in the NAPTR record set, then order
may be completely ignored and preference taken as a suggestion for
how the records should be processed. However, if the most preferred
NAPTR record overall does not have a 'sip+E2U' service field, the
ENUM client SHOULD seek out the most preferred NAPTR record that
contains a 'sip+E2U' service field, disregarding 'tel+E2U' or any
other non-SIP schemes.
If different orders are present in the NAPTR record set, then the
NAPTR algorithm forbids the inspection of records of an order other
than the lowest order containing a match for the current query.
However, since the usage of 'order' may be confusing to authors of
ENUM records, ENUM clients should conflate the 'order' and
'preference' fields. The simplest manner of doing so is to place a
decimal point between the 'order' and 'preference' field and to treat
the two so combined as a preference. Consider the following example
(and please keep in mind that this does not follow the authorship
guidelines above):
$ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
IN NAPTR 100 10 "u" "tel+E2U" "!^.*$!tel:info@tele2.se!" .
IN NAPTR 102 10 "u" "sip+E2U" "!^.*$!sip:info@tele2.se!" .
IN NAPTR 102 20 "u" "mailto+E2U" "!^.*$!mailto:info@tele2.se!" .
Following this schema, the 'sip' record would be treated as if it had
a preference of 102.1, the 'tel' record a preference of 100.1, and
the 'mailto' record a preference of 102.2. Note that in this case
the 'sip+E2U' record should still be selected over the 'tel+E2U'
record by a SIP client, despite the preference values.
Peterson, et al. Expires August 9, 2002 [Page 24]
Internet-Draft Using ENUM for SIP Applications February 2002
5.4 Contending with multiple SIP records
If an ENUM query returns multiple NAPTR records that have a service
field of 'sip+E2U', the ENUM client must first determine whether or
not it should attempt to make use of multiple records or select a
single one. The pitfalls of intentionally authoring ENUM record sets
with multiple NAPTR records for SIP are detailed above in Section
4.4.2 and will not be reiterated here.
If the ENUM client is a user agent, then at some point a single NAPTR
record must be selected to serve as the Request-URI of the desired
SIP request. If the SIP NAPTR records have different preferences,
the most preferred record SHOULD be used. If two or more records
share most preferred status, the ENUM client SHOULD randomly
determine which record will be used, though it MAY defer to a local
policy that employs some other means to select a record.
If the ENUM client is a proxy server, then it MAY fork the request
when it receives multiple 'sip+E2U' NAPTR records in an ENUM record
set. Depending on the relative precedence values of the NAPTR
records the proxy may wish to fork sequentially or in parallel.
Alternatively, the proxy server MAY select a single record in
accordance with the NAPTR preference fields (or randomly when no
preference is specified, or in accordance with local policy) and
proxy the request with a Request-URI corresponding to the URI field
of this NAPTR record. Note that there are significant limitations
(detailed at the end of Section 3.1) that arise if a proxy server
processes ENUM record sets instead of a user agent, and that
therefore it is RECOMMENDED that SIP network elements act as redirect
servers rather than proxy servers after an ENUM query.
If the ENUM client is a redirect server, then it MAY return a 3xx
response with more than one Contact header field corresponding to the
multiple 'sip+E2U' NAPTR records in an ENUM record set. If the NAPTR
records have different preferences, then 'q' values may be used in
the Contact header fields to correspond to these preferences.
Alternatively, the redirect server MAY select a single record in
accordance with the NAPTR preference fields (or randomly when no
preference is specified) and send this resulting URI in a Contact
header field in a 3xx.
5.5 Processing NATPR records in a client
Obviously, when an appropriate NAPTR record has been selected, the
URI should be extracted from the regexp field. The URI is between
the second and third exclamation points in the string. Once a URI
has been extracted from the NAPTR record, it SHOULD be used as the
Request-URI of the SIP request for which the ENUM query was launched.
Peterson, et al. Expires August 9, 2002 [Page 25]
Internet-Draft Using ENUM for SIP Applications February 2002
SIP clients should perform some sanity checks on the URI, primarily
to ensure that they support the scheme of the URI, but also to verify
that the URI is well-formed. Clients should also check to make sure
that the Request-URI does not target themselves.
Once an address-of-record has been extracted from the selected NAPTR
record, clients should follow the standard SIP mechanisms for
determining how to forward the request. This may involve launching
subsequent NAPTR or SRV queries in order to determine how best to
route to the domain identified by an address-of-record; clients
however MUST NOT make the same query recursively.
Note that SIP requests based on the use of NAPTR records may fail.
If there are multiple NAPTR records relevant to SIP present in an
ENUM record set, then after a failure has occurred on an initial
attempt with one NAPTR record, SIP clients MAY try their request
again with a different NAPTR record from the ENUM record set.
Peterson, et al. Expires August 9, 2002 [Page 26]
Internet-Draft Using ENUM for SIP Applications February 2002
6. Limits of ENUM
This section documents some of the things that ENUM, as it is
described in RFC2916, does not do. ENUM has intentionally limited
its own scope in order to meet certain policy goals, and as a result
there is some potentially desirable functionality for SIP
implementers that might, at first glance at the standard, seem like
something ENUM provides, but which is actually outside the scope of
ENUM as such.
Because these limitations of ENUM are largely self-imposed rather
than technological restrictions, there are of course other
technologies that do not have these constraints. The underlying
NAPTR technology behind ENUM is very flexible, and could be applied
to all manner of translations beyond ENUM; in time, ENUM may expand
its scope to remove some of the limitations described below.
Currently, however, RFC2916 provides a very narrow scope for ENUM
that allows only one specific form of translation.
Specifically, ENUM is not used to query for translations of any of
the following:
Arbitrary strings: Although NAPTR operates on arbitrary strings, ENUM
operates specifically on numbers (telephone numbers, even). No
sorts of textual names, numeric strings unrelated to telephony,
hostnames, URIs or URNs are resolved and translated by ENUM.
Private dialing plans: Many enterprise telephone systems and private
branch exchanges use private dialing plans for internal calls;
commonly, these are abbreviated numbers (like '82600') in which a
single leading digit indicates that the call is local to the
enterprise. ENUM, however, operates only on 'public' numbers that
are ubiquitously reachable in the PSTN.
National numbers: Numbers that are in a national form (such as
'2025332600') rather than an international form ('+12025332600')
will not resolve properly in ENUM. While it is generally trivial
to convert a national number to an international number, ENUM has
no mechanism for doing so - figuring out the country code that
should be appended to a national number would require some
decision in the network based on the originator of the query
(guessing at their location, or somehow matching them to a known
policy). ENUM does not make origination-based policy decisions
when processing queries.
Incomplete E.164 numbers: ENUM has no defined mechanism for servers
to recognize or indicate that they have received an incomplete
address in a query. This might occur, for example, in 'en bloc'
Peterson, et al. Expires August 9, 2002 [Page 27]
Internet-Draft Using ENUM for SIP Applications February 2002
signaling if a user inputs half of a telephone number to a cell
phone and then accidentally hits the 'Talk' button, or in
'overlap' PSTN signaling if only part of the digits dialed by the
user are communicated to a network element when it launches an
ENUM query. If at all possible, network elements that might make
ENUM queries should take care to operate only on complete
addresses.
E.164 number prefixes: A NAPTR record set grouped under a E.164
number prefix (like '+1202533') might signify any of a number of
things. This might be some sort of master record for a zone. It
might signify a record intended for prefix-based routing. It
might even be there to catch incomplete E.164 number translation
attempts. However, the standard is silent about this matter, and
therefore the meaning of these records would be ambiguous at best.
Neither creating records under partial E.164 numbers nor sending
queries for partial E.164 numbers are standard or meaningful
behavior in ENUM.
Peterson, et al. Expires August 9, 2002 [Page 28]
Internet-Draft Using ENUM for SIP Applications February 2002
7. Security Considerations
DNS does not make policy decisions about the records that it shares
with an inquirer. All DNS records must be assumed to be available to
all inquirers at all times. The information provided within an ENUM
record set must therefore be considered to be open to the public -
which is a cause for some privacy considerations.
Ordinarily, when you give someone your telephone number, you don't
expect that they will be able to trivially determine your full name
and place of employment. If, however, you create a NAPTR record for
use with ENUM that maps your telephone number to a SIP URI like
'sip:julia.roberts@vivendi.com', expect to get a lot of calls from
excited fans.
Unlike a traditional telephone number, the target of a SIP URI may
require that callers provide cryptographic credentials for
authentication and authorization before a user is alerted. In this
respect, ENUM in concert with SIP can actually provide far greater
protection from unwanted callers than the existing PSTN, despite the
public availability of ENUM records.
Users of ENUM who are nevertheless uncomfortable with revealing their
names may, since identities on the Internet are not exactly at a
premium, publish a less revealing SIP URI, like
'sip:anonymous00045@vivendi.com' or even
'sip:anonymous00045@anonymous-redirector.com', which could in turn
point to their internal URI.
Peterson, et al. Expires August 9, 2002 [Page 29]
Internet-Draft Using ENUM for SIP Applications February 2002
8. IANA Considerations
This document introduces no new values for any IANA registries.
Peterson, et al. Expires August 9, 2002 [Page 30]
Internet-Draft Using ENUM for SIP Applications February 2002
References
[1] Faltstrom, P., "E.164 number and DNS", RFC 2916, September
2000.
[2] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
1034, November 1987.
[3] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[4] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
[5] International Telecommunications Union, "Recommendation E.164:
The international public telecommunication numbering plan", May
1997, <http://www.itu.int>.
[6] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April
2000.
[7] Rosenberg, J. and H. Schulzrinne, "SIP Caller Preferences and
Callee Capabilities", draft-ietf-sip-callerprefs-05 (work in
progress), November 2001.
[8] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
1999.
[9] Mealling, M. and R. Daniel, "The Naming Authority Pointer
(NAPTR) DNS Resource Record", RFC 2915, September 2000.
[10] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[11] Rosenberg, J., Squire, M. and H. Salama, "Telephony Routing
over IP (TRIP)", draft-ietf-iptel-trip-09 (work in progress),
August 2001.
[12] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS Standard", draft-ietf-urn-ddds-toc-
00 (work in progress), October 2001.
[13] Bush, R., "How ENUM, SIP URIs, TRIP, and Gateways Relate",
draft-ymbk-enum-trip-00 (work in progress), July 2001.
Peterson, et al. Expires August 9, 2002 [Page 31]
Internet-Draft Using ENUM for SIP Applications February 2002
Authors' Addresses
Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA 94520
USA
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Hong Liu
NeuStar, Inc.
1120 Vermont St
Suite 400
Washington, DC 2005
USA
Phone: +1 202/533-2600
EMail: hong.liu@neustar.biz
URI: http://www.neustar.biz/
James Yu
NeuStar, Inc.
1120 Vermont St
Suite 400
Washington, DC 2005
USA
Phone: +1 202/533-2814
EMail: james.yu@neustar.biz
URI: http://www.neustar.biz/
Ben Campbell
dynamicosft
5100 Tennyson Parkway
Suite 1200
Plano, TX 75024
USA
EMail: bcampbell@dynamicsoft.com
URI: http://www.dynamicsoft.com/
Peterson, et al. Expires August 9, 2002 [Page 32]
Internet-Draft Using ENUM for SIP Applications February 2002
Appendix A. Acknowledgments
The authors would like to thank Richard Shockey for his input on
privacy issues, and Tom McGarry and Rohan Mahy for overall comments
and analysis.
The question of the relationship of ENUM, TRIP and SIP is also
explored in a Internet-Draft by Randy Bush [13].
This draft was authored in the XML format described in RFC2629 [8].
Peterson, et al. Expires August 9, 2002 [Page 33]
Internet-Draft Using ENUM for SIP Applications February 2002
Appendix B. To Do
Update for DDDS: Once the DDDS [12] document-set has been approved by
the IESG, RFC2915 will become obsolete, and RFC2916 will
presumably be updated accordingly. At such a time new practices
for SIP may need to be identified.
Comparison with TRIP: It might be interesting to stage a comparison
of ENUM-based routing with TRIP [11] along the lines of the
analysis in Section 3.4.
Update for RFC 2543bis: The new SIP RFC will incorporate a number of
changes that are material to the demarcation of ENUM and SIP; once
that work is complete, this document should be updated
accordingly.
Peterson, et al. Expires August 9, 2002 [Page 34]
Internet-Draft Using ENUM for SIP Applications February 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Peterson, et al. Expires August 9, 2002 [Page 35]
