One document matched: draft-ietf-sipping-e164-02.txt
Differences from draft-ietf-sipping-e164-01.txt
ENUM WG J. Peterson
Internet-Draft H. Liu
Expires: April 26, 2003 J. Yu
NeuStar
B. Campbell
dynamicsoft
October 26, 2002
Using ENUM for SIP Applications
draft-ietf-sipping-e164-02
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 April 26, 2003.
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 use of SIP with ENUM. This document illustrates how the two
protocols might work in concert, and clarifies the authoring and
processing of ENUM records for SIP applications.
Peterson, et al. Expires April 26, 2003 [Page 1]
Internet-Draft Using ENUM for SIP Applications October 2002
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Handling Telephone Numbers in SIP . . . . . . . . . . . . . . 6
4. Design Principles . . . . . . . . . . . . . . . . . . . . . . 7
5. Authoring NAPTR Records for SIP . . . . . . . . . . . . . . . 9
5.1 The Service Field . . . . . . . . . . . . . . . . . . . . . . 9
5.2 Flags in NAPTR RR . . . . . . . . . . . . . . . . . . . . . . 9
5.3 Creating the Regular Expression: Matching . . . . . . . . . . 9
5.4 Creating the Regular Expression: The URI . . . . . . . . . . . 10
5.5 Setting Order and Preference amongst Records . . . . . . . . . 11
5.6 Example of a Well-Formed ENUM NAPTR Record Set for SIP . . . . 11
6. Processing ENUM Records . . . . . . . . . . . . . . . . . . . 12
6.1 Selecting a Number for a Query . . . . . . . . . . . . . . . . 12
6.2 Examining Service Fields . . . . . . . . . . . . . . . . . . . 12
6.3 Handling Order and Preference . . . . . . . . . . . . . . . . 13
6.4 Contending with Multiple SIP records . . . . . . . . . . . . . 14
6.5 Processing the Selected NAPTR Record . . . . . . . . . . . . . 14
7. Updates for rfc2916bis . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
B. To Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 24
Peterson, et al. Expires April 26, 2003 [Page 2]
Internet-Draft Using ENUM for SIP Applications October 2002
1. Introduction
ENUM (E.164 Number Mapping, RFC2916 [1]) is a system that uses DNS
(Domain Name Service, RFC1034 [4]) in order to translate certain
telephone numbers, like '+12025332600', into URIs (Uniform Resource
Identifiers, RFC2396 [5]), 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, RFC3261 [2]) 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 most widespread application for SIP today is Voice-over-IP
(VoIP). As such, there are a number of cases in which SIP
applications are forced to contend with telephone numbers.
Unfortunately, telephone numbers cannot be routed in accordance with
the traditional DNS-based routing procedures standardized for SIP
(see [11]), which rely on SIP URIs. ENUM provides a method for
translating E.164 numbers into URIs, including potentially SIP URIs.
This document therefore provides an account of how SIP can handle
telephone numbers by making use of ENUM. 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.
The guidelines in this document are oriented towards authoring and
processing ENUM records specifically for SIP applications. These
guidelines assume that the reader is familiar with Naming Authority
Pointer (NAPTR) records (RFC2915 [9]) and ENUM (RFC2916 [1]). Only
those aspects of NAPTR record authoring and processing 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.
Note that the ENUM specification is currently under revision,
following the update of the NAPTR system described in RFC2915 to the
Dynamic Delegation Discovery System (DDDS) family of specifications.
This document therefore provides some guidance for using SIP with the
forthcoming specifications as well as the existing RFCs.
The remainder of this document is organized as follows: Section 3
suggests general behavior for SIP user agents that encounter
Peterson, et al. Expires April 26, 2003 [Page 3]
Internet-Draft Using ENUM for SIP Applications October 2002
telephone numbers; Section 4 provides an overview of the intersection
of SIP and ENUM; proposed normative guidelines for ENUM record
authoring and processing in the context of SIP are described in
Section 5 and Section 6 respectively; some considerations relevant to
the revision of RFC2916 are given in Section 7.
Peterson, et al. Expires April 26, 2003 [Page 4]
Internet-Draft Using ENUM for SIP Applications October 2002
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in RFC2119 [3] and indicate requirement levels for
compliant SIP implementations.
Peterson, et al. Expires April 26, 2003 [Page 5]
Internet-Draft Using ENUM for SIP Applications October 2002
3. Handling Telephone Numbers in SIP
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
might use ENUM to discover a SIP URI associated with the E.164
number. Note that support for the NAPTR DNS resource record format
is now specified for ordinary SIP URI processing in [11], which
significantly lessens the burden of ENUM implementation for SIP user
agents. 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 [7] 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
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 can contain a tel URL
(without the scheme string, like
sip:+12025332600@carrier.com;user=phone). 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.
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. These proxy server policies might be informed by TRIP
[12]. As a matter of precedence, SIP user agents should attempt to
translate telephone numbers to URIs with ENUM, if implemented, before
creating a tel URL and deferring the routing of this request to a SIP
proxy server.
Peterson, et al. Expires April 26, 2003 [Page 6]
Internet-Draft Using ENUM for SIP Applications October 2002
4. Design Principles
Although the applicability of ENUM to SIP has always been clear, the
exact way in which the two should cooperate has been a subject of
some controversy. How many SIP URIs should appear in ENUM, what kind
of URIs they are, whether or not the "service" field of NAPTR records
should be more detailed - numerous questions have arisen about the
authoring and interpretation of ENUM records for SIP consumers. The
following, then, is a statement of the particular philosophy that has
motivated the recommendations in this draft:
Address-of-record SIP URIs appear in ENUM, not contact address
URIs. Roughly speaking, an address-of-record is the canonical
identity of a SIP user - it usually appears in the From field of
SIP requests sent by that user; a contact address is the URI of a
device. The process of registration in SIP (using the REGISTER
method), for example, temporarily binds the contact address of a
device to the address-of-record of a user. A DNS record has a
long time-to-live when compared with the timeframe of SIP
registrations. The availability of an address-of-record also
transcends the availability of any single device. ENUM is more
suitable for representing an long-term identity than the URI of
any device with which a user is temporarily associated. If ENUM
were purposed to map to specific devices, it would be better to
translate telephone numbers to IPv4 addresses than to URIs (which
express something richer).
SIP URIs in ENUM do not convey capability information. SIP has
its own methods for negotiating capability information between
user agents (see SDP [10], the use of Require/Supported to
negotiate extensions in RFC3261, and caller preferences [8]);
providing more limited capability information within ENUM is at
best redundant and at worst potentially harmful to SIP's
negotiation system. Also, addresses-of-record do not have
capabilities (only devices registered under an address-of-record
have actual capabilities), and putting contact addresses in ENUM
is not recommended.
Only one SIP URI appears in an ENUM record set for a telephone
number. While it may initially seem attractive to provide
multiple SIP URIs that reach the same user within ENUM, if there
are multiple addresses at which a user can be contacted,
considerably greater flexibility is afforded if multiple URIs are
managed by a SIP location service that is identified by a single
record in ENUM. Behavior for parallel and sequential forking in
SIP, for example, is better managed in SIP than in a set of ENUM
records.
Peterson, et al. Expires April 26, 2003 [Page 7]
Internet-Draft Using ENUM for SIP Applications October 2002
User agents should process ENUM records, not proxy servers. The
assumptions underlying the processing of NAPTR records dictate
that the ENUM client knows the set of enumservices supported by
the entity that is attempting to communicate. A SIP proxy server
is unlikely the know the enumservices supported by the originator
of a SIP request.
For further discussion of these principles and their motivation, see
[14].
Peterson, et al. Expires April 26, 2003 [Page 8]
Internet-Draft Using ENUM for SIP Applications October 2002
5. Authoring NAPTR Records for SIP
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).
5.1 The Service Field
The Service field of a NAPTR record (per RFC2915) 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.
5.2 Flags in NAPTR RR
Authors of NAPTR records MUST use the terminal "u" flag when
'sip+E2U' is specified as a Service field.
5.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
Peterson, et al. Expires April 26, 2003 [Page 9]
Internet-Draft Using ENUM for SIP Applications October 2002
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 starting 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 'sip+E2U' service field.
5.4 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
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 or SIPS URI scheme when the service field is
'sip+E2U'.
SIP or SIPS URIs within NAPTR record SHOULD contain an address-of-
record rather than a contact address URI that depends on particular
hosts or devices. 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
Peterson, et al. Expires April 26, 2003 [Page 10]
Internet-Draft Using ENUM for SIP Applications October 2002
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 specific
devices, 'sip+E2IPv4' would be a more appropriate resolution service
to define.
5.5 Setting Order and Preference amongst Records
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)
$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.
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.
5.6 Example of a Well-Formed ENUM NAPTR Record Set for SIP
$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 April 26, 2003 [Page 11]
Internet-Draft Using ENUM for SIP Applications October 2002
6. Processing ENUM Records
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
or SIPS 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.
6.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 if possible make sure that the telephone number it
intends to resolve is a complete E.164 address. Note that network
elements might not actually have a means of determining whether an
address is complete in the E.164 system, especially when interworking
with networks that use overlap PSTN signaling (this is especially
problematic when dealing with variable-length numbering plans). 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) to a national-specific number.
6.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 April 26, 2003 [Page 12]
Internet-Draft Using ENUM for SIP Applications October 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.
6.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 April 26, 2003 [Page 13]
Internet-Draft Using ENUM for SIP Applications October 2002
6.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.
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
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
performing 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 response.
6.5 Processing the Selected NAPTR Record
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 April 26, 2003 [Page 14]
Internet-Draft Using ENUM for SIP Applications October 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 (see [11])
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 ENUM query recursively (if the
URI returned by ENUM is or contains a tel URL, see [7]).
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 April 26, 2003 [Page 15]
Internet-Draft Using ENUM for SIP Applications October 2002
7. Updates for rfc2916bis
The ENUM specification is currently undergoing a revision in the ENUM
WG. The new specification, RFC2916bis [16], is based on the emerging
Dynamic Delegation Discovery System [13] revision to the NAPTR
resource record specified in RFC2915. For the most part, DDDS is an
organizational revision that makes the algorithmic aspects of record
processing separable from any underlying database format (such as the
NAPTR DNS resource record).
The most important revision in RFC2916bis is the concept of
enumservices. RFC2916 specified a number of "service" values that
could be used for ENUM, including the "sip+E2U" service field.
RFC2916bis introduces an IANA registration system with new guidelines
for the registration of enumservices, which are no longer necessarily
divided into discreet "service" and "protocol" fields, and which
admit of more complex structures. In order to differentiate
enumservices in RFC2916bis from those in RFC2916, the "E2U" is the
leading element in an enumservice field.
An enumservice for SIP addresses-of-record is described in [15].
This enumservice uses the enumservice field "E2U+sip". RFC2916bis-
compliant users of ENUM for SIP should therefore use the "E2U+sip"
enumservice field instead of the "sip+E2U" field. For backwards-
compatibility, however, either field should be recognized by ENUM
client that support SIP.
Also note that the terminology of DDDS differs in a number of
respects from the initial NAPTR terminology in RFC2916. DDDS
introduces the concept of an Application, an Application Specific
String, a First Well Known Rule, and so on. The terminology used in
this document is a little looser (it refers to a 'starting string',
for example, where 'Application Specific String' would be used for
DDDS). The new terminology is reflected in RFC2916bis.
Peterson, et al. Expires April 26, 2003 [Page 16]
Internet-Draft Using ENUM for SIP Applications October 2002
8. 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 April 26, 2003 [Page 17]
Internet-Draft Using ENUM for SIP Applications October 2002
9. IANA Considerations
This document introduces no new values for any IANA registries.
Peterson, et al. Expires April 26, 2003 [Page 18]
Internet-Draft Using ENUM for SIP Applications October 2002
References
[1] Faltstrom, P., "E.164 number and DNS", RFC 2916, September
2000.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, May 2002.
[3] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, March 1997.
[4] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
1034, November 1987.
[5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[6] International Telecommunications Union, "Recommendation E.164:
The international public telecommunication numbering plan", May
1997, <http://www.itu.int>.
[7] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April
2000.
[8] Rosenberg, J. and H. Schulzrinne, "SIP Caller Preferences and
Callee Capabilities", draft-ietf-sip-callerprefs-05 (work in
progress), November 2001.
[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. and H. Schulzrinne, "Session Initiation Protocol:
Locating SIP Servers", RFC 3263, June 2002.
[12] Rosenberg, J., Squire, M. and H. Salama, "Telephony Routing
over IP (TRIP)", RFC 3219, August 2001.
[13] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS Standard", RFC 3401, October 2002.
[14] Peterson, J., "Telephone Addressing and Routing in ENUM, SIP
and TRIP", draft-peterson-tel-addressing-00 (work in progress),
October 2002.
Peterson, et al. Expires April 26, 2003 [Page 19]
Internet-Draft Using ENUM for SIP Applications October 2002
[15] Peterson, J., "enumservice registration for SIP Addresses-of-
Record", draft-peterson-enum-sip-00 (work in progress), October
2002.
[16] Faltstrom, P. and M. Mealling, "E.164 number and DNS", draft-
ietf-enum-rfc2916bis-01 (work in progress), June 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.
46000 Center Oak Plaza
Sterling, VA 20166
USA
EMail: hong.liu@neustar.biz
URI: http://www.neustar.biz/
James Yu
NeuStar, Inc.
46000 Center Oak Plaza
Sterling, VA 20166
USA
Phone: +1 571/434-5572
EMail: james.yu@neustar.biz
URI: http://www.neustar.biz/
Peterson, et al. Expires April 26, 2003 [Page 20]
Internet-Draft Using ENUM for SIP Applications October 2002
Ben Campbell
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, TX 75024
USA
EMail: bcampbell@dynamicsoft.com
URI: http://www.dynamicsoft.com/
Peterson, et al. Expires April 26, 2003 [Page 21]
Internet-Draft Using ENUM for SIP Applications October 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.
Peterson, et al. Expires April 26, 2003 [Page 22]
Internet-Draft Using ENUM for SIP Applications October 2002
Appendix B. To Do
Peterson, et al. Expires April 26, 2003 [Page 23]
Internet-Draft Using ENUM for SIP Applications October 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 April 26, 2003 [Page 24]
| PAFTECH AB 2003-2026 | 2026-04-24 04:15:38 |