Skip to main content

Using E.164 numbers with the Session Initiation Protocol (SIP)

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 3824.
Authors Jon Peterson , Hong Liu , Ben Campbell , James Yu
Last updated 2013-03-02 (Latest revision 2003-09-02)
RFC stream Internet Engineering Task Force (IETF)
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state RFC 3824 (Informational)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Allison J. Mankin
Send notices to (None)
SIPPING WG                                                   J. Peterson
Internet-Draft                                                    H. Liu
Expires: March 2, 2004                                             J. Yu
                                                             B. Campbell
                                                       September 2, 2003

     Using E.164 numbers with the Session Initiation Protocol (SIP)

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-

   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://

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on March 2, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.


   There are a number of contexts in which telephone numbers are
   employed by SIP applications, many of which can be addressed by ENUM.
   Although SIP was one of the primary applications for which ENUM was
   created, there is nevertheless a need to define procedures for
   integrating ENUM with SIP implementations.  This document illustrates
   how the two protocols might work in concert, and clarifies the
   authoring and processing of ENUM records for SIP applications.  It
   also provides guidelines for instances in which ENUM, for whatever

Peterson, et al.         Expires March 2, 2004                  [Page 1]
Internet-Draft               SIPPING E.164                September 2003

   reason, cannot be used to resolve a telephone number.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Handling Telephone Numbers in SIP  . . . . . . . . . . . . . .  4
   4.  Design Principles  . . . . . . . . . . . . . . . . . . . . . .  5
   5.  Authoring NAPTR Records for SIP  . . . . . . . . . . . . . . .  6
   5.1 The Service Field  . . . . . . . . . . . . . . . . . . . . . .  7
   5.2 Creating the Regular Expression: Matching  . . . . . . . . . .  7
   5.3 Creating the Regular Expression: The URI . . . . . . . . . . .  8
   5.4 Setting Order and Preference amongst Records . . . . . . . . .  8
   5.5 Example of a Well-Formed ENUM NAPTR Record Set for SIP . . . .  9
   6.  Processing ENUM Records  . . . . . . . . . . . . . . . . . . .  9
   6.1 Contending with Multiple SIP records . . . . . . . . . . . . .  9
   6.2 Processing the Selected NAPTR Record . . . . . . . . . . . . . 10
   7.  Compatibility with RFC2916 . . . . . . . . . . . . . . . . . . 11
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
       Normative References . . . . . . . . . . . . . . . . . . . . . 12
       Informative References . . . . . . . . . . . . . . . . . . . . 13
   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15

Peterson, et al.         Expires March 2, 2004                  [Page 2]
Internet-Draft               SIPPING E.164                September 2003

1. Introduction

   ENUM (E.164 Number Mapping, RFC2916bis [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 [9]), like ''.  ENUM
   exists primarily to facilitate the interconnection of systems that
   rely on telephone numbers with those that use URIs to route
   transactions.  E.164 [10] is the ITU-T standard international
   numbering plan, under which all globally-reachable telephone numbers
   are organized.

   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 routing in accordance with
   the traditional DNS resolution procedures standardized for SIP (see
   [14]), 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 (RFC3403 [6]) 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; these procedures do not update or override
   the NAPTR or ENUM core documents.

   Note that the ENUM specification has undergone a revision shortly
   before the publication of this document, driven by the update of the
   NAPTR system described in RFC2915 [12] to the Dynamic Delegation
   Discovery System (DDDS) family of specifications (including RFC3403).
   This document therefore provides some guidance for handling records
   designed for the original RFC2916 [16].

Peterson, et al.         Expires March 2, 2004                  [Page 3]
Internet-Draft               SIPPING E.164                September 2003

   The remainder of this document is organized as follows: Section 3
   suggests general behavior for SIP user agents that encounter
   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.

2. Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in RFC2119 [3] and indicate requirement levels for
   compliant SIP implementations.

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 most cases, these are requests for
   a telephony session (voice communication), though numerous other
   services are also reached through telephone numbers (including
   instant messaging services).

   Unlike a URI, a telephone number does not contain a host name, or any
   hints as to where one might deliver a request targeting a telephone
   number on the Internet.  While SIP user agents or proxy servers could
   be statically provisioned with a mapping of destinations
   corresponding to particular telephone numbers or telephone number
   ranges, considering the size and complexity of a complete mapping, it
   would be preferable for SIP user agents to be able to query as needed
   for a destination appropriate for a particular telephone number.

   In such cases a user agent might use ENUM to discover a URI
   associated with the E.164 number - including a SIP URI.  URIs
   discovered through ENUM can then be used normally to route SIP
   requests to their destination.  Note that support for the NAPTR DNS
   resource record format is specified for ordinary SIP URI processing
   in [14], and thus support for ENUM is not a significant departure
   from baseline SIP DNS routing.

Peterson, et al.         Expires March 2, 2004                  [Page 4]
Internet-Draft               SIPPING E.164                September 2003

   Most of the remainder of this document provides procedures for the
   use of ENUM, but a few guidelines are given in the remainder of this
   section for cases in which ENUM is not used, for whatever reason.

   If a user agent is unable to translate an E.164 number with ENUM, 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 [8] 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;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 support for ENUM, or if ENUM requests return no
   records corresponding to a telephone number, local policy can be used
   to determine how to forward SIP requests with an E.164 number in the
   Request-URI.  Frequently, such calls are routed to gateways that
   interconnect SIP networks with the PSTN.  These proxy server policies
   might be provisioned dynamically with routing information for
   telephone numbers by TRIP [15].  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.

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 contain capability information - numerous questions have
   arisen around 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

Peterson, et al.         Expires March 2, 2004                  [Page 5]
Internet-Draft               SIPPING E.164                September 2003

      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 [13], the use of Require/Supported to
      negotiate extensions in RFC3261, and callee capabilities [11]);
      providing more limited capability information within ENUM is at
      best redundant and at worst potentially misleading 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, ideally, 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

      User agents, rather than proxy servers, should process ENUM
      records.  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 to know the enumservices supported by the
      originator of a SIP request.

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.

Peterson, et al.         Expires March 2, 2004                  [Page 6]
Internet-Draft               SIPPING E.164                September 2003

   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 RFC3403) contains a string
   token that designates the protocol or service associated with a
   particular record (and which imparts some inkling of the sort of URI
   that will result from the use of the record).  ENUM [1] requires the
   IANA registration of service fields known as "enumservices".

   An enumservice for SIP has been developed in the ENUM working group
   (see [7]) which uses the format 'E2U+sip' to designate that a SIP
   address-of-record appears in the URI field of a NAPTR record.  It is
   strongly RECOMMENDED that authors of NAPTR records use the 'E2U+sip'
   service field whenever the regexp contains a SIP address-of-record

5.2 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 core specification.

   When a NAPTR record is processed, the expression in the antecedent is
   matched against the starting string (for ENUM, the telephone number)
   to assist in locating the proper record in a set; however, in ENUM
   applications, since the desired record set is located through a
   reverse resolution in the domain that is based on the
   starting string, further analysis of the starting string on the
   client side will usually be unnecessary.  In such cases, the
   antecedent of the regular expression is commonly 'greedy' - it uses
   the regexp '^.*$', which matches any starting string.  Some authors
   of ENUM record sets may want to use the full power of regexps, and
   create non-greedy antecedents; the DDDS standard requires that ENUM

Peterson, et al.         Expires March 2, 2004                  [Page 7]
Internet-Draft               SIPPING E.164                September 2003

   resolvers support these regexps when they are present.  For providing
   a trivial mapping from a telephone number to a SIP URI, the use of a
   greedy regexp usually suffices.

   Example: "!^.*$!!"

   Note that when the antecedent of the regexp is greedy, this does not
   mean that the replacement field in NAPTR records provides a viable
   alternative to authoring with a regexp.  Authors of NAPTR records for
   ENUM MUST NOT use the replacement field in records with an 'E2U+sip'
   service field.

5.3 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' URIs,
   'im' or 'pres' URIs, or others that describe specific services that
   might be invoked through SIP are all potentially candidates.  While
   the use of these URIs 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

   It is RECOMMENDED that authors of ENUM records should always use the
   SIP or SIPS URI scheme when the service field is 'E2U+sip', and the
   URIs in question MUST be addresses-of-record, not contact addresses.

   Users of SIP can register one or more contact addresses with a SIP
   registrar that will be consulted by the proxy infrastructure of an
   administrative domain to contact the end user when requests are
   received for their address-of-record.  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 needs
   to target specific devices rather than URIs, then a hypothetical
   'E2IPv4+sip' enumservice would be more appropriate.

5.4 Setting Order and Preference amongst Records

   For maximal compatibility authors of ENUM records for SIP 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.

Peterson, et al.         Expires March 2, 2004                  [Page 8]
Internet-Draft               SIPPING E.164                September 2003

5.5 Example of a Well-Formed ENUM NAPTR Record Set for SIP

      IN NAPTR 100 10 "u" "E2U+sip"    "!^.*$!!"     .
      IN NAPTR 100 20 "u" "E2U+mailto" "!^.*$!!"  .

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 the DDDS algorithm and ENUM before
   reviewing this section.

   Although in some cases, ENUM record sets will consist only a single
   'E2U+sip' record, this section assumes that integrators of ENUM and
   SIP 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 Contending with Multiple SIP records

   If an ENUM query returns multiple NAPTR records that have a service
   field of 'E2U+sip', or other service field that may be used by SIP
   (such as 'E2U+pres', see [17]) 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 given 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 SIP intermediary that can act a redirect
   server, then it SHOULD return a 3xx response with more than one
   Contact header field corresponding to the multiple selected 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

Peterson, et al.         Expires March 2, 2004                  [Page 9]
Internet-Draft               SIPPING E.164                September 2003

   preference fields (or randomly when no preference is specified) and
   send this resulting URI in a Contact header field in a 3xx response.

   Otherwise, if the ENUM client is a SIP intermediary that can act as a
   proxy server, then it MAY fork the request when it receives multiple
   appropriate 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.  However, the proxy MUST build a
   route set from these NAPTR records that consists exclusively of SIP
   or SIPS URIs, not other URI schemes.  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 - though again,
   it MUST select a record that contains a SIP or SIPS URI.  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.

6.2 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.

   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 MUST at least verify that the
   Request-URI does not target themselves.

   Once an address-of-record has been extracted from the selected NAPTR
   record, clients follow the standard SIP mechanisms (see [14]) 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 [8]).

   Note that SIP requests based on the use of NAPTR records may fail for
   any number of reasons.  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 user agents
   MAY try their request again with a different NAPTR record from the
   ENUM record set.

Peterson, et al.         Expires March 2, 2004                 [Page 10]
Internet-Draft               SIPPING E.164                September 2003

7. Compatibility with RFC2916

   The ENUM specification is currently undergoing a revision in the ENUM
   WG.  The new specification, RFC2916bis [1], is based on the Dynamic
   Delegation Discovery System [5] revision to the NAPTR resource record
   specified in RFC2915 [12].  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.  The original ENUM specification, 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 string "E2U" is the leading element in an enumservice
   field, whereas by RFC2916 it was the trailing element.

   An enumservice for SIP addresses-of-record is described in [7].  This
   enumservice uses the enumservice field "E2U+sip".  RFC2916bis-
   compliant authors of ENUM records for SIP MUST therefore use the
   "E2U+sip" enumservice field instead of the "sip+E2U" field.  For
   backwards compatibility with existing legacy records, however, the
   'sip+E2U' field SHOULD be supported by an ENUM client that support

   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.

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

Peterson, et al.         Expires March 2, 2004                 [Page 11]
Internet-Draft               SIPPING E.164                September 2003

   use with ENUM that maps your telephone number to a SIP URI like
   '', 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
   '' or even
   '', which could in turn
   point to their internal URI.

9. IANA Considerations

   This document introduces no considerations for the IANA.

Normative References

   [1]  Faltstrom, P. and M. Mealling, "E.164 number and DNS", draft-
        ietf-enum-rfc2916bis-06 (work in progress), May 2003.

   [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]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
        One: The Comprehensive DDDS Standard", RFC 3401, October 2002.

   [6]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
        Three: The Domain Name System (DNS) Database", RFC 3403, October

   [7]  Peterson, J., "enumservice registration for SIP Addresses-of-
        Record", draft-ietf-enum-sip-00 (work in progress), February

Peterson, et al.         Expires March 2, 2004                 [Page 12]
Internet-Draft               SIPPING E.164                September 2003

   [8]  Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April

   [9]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

Informative References

   [10]  International Telecommunications Union, "Recommendation E.164:
         The international public telecommunication numbering plan", May
         1997, <>.

   [11]  Rosenberg, J., Schulzrinne, H. and P. Kyzviat, "Indicating User
         Agent Capabilities in the Session Initiation Protocol (SIP)",
         draft-ietf-sip-callee-caps-00 (work in progress), June 2003.

   [12]  Mealling, M. and R. Daniel, "The Naming Authority Pointer
         (NAPTR) DNS Resource Record", RFC 2915, September 2000.

   [13]  Handley, M. and V. Jacobson, "SDP: Session Description
         Protocol", RFC 2327, April 1998.

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

   [15]  Rosenberg, J., Squire, M. and H. Salama, "Telephony Routing
         over IP (TRIP)", RFC 3219, August 2001.

   [16]  Faltstrom, P., "E.164 number and DNS", RFC 2916, September

   [17]  Peterson, J., "Enumservice Registration for Presence Services",
         draft-peterson-enum-pres-00 (work in progress), February 2003.

Authors' Addresses

   Jon Peterson
   NeuStar, Inc.
   1800 Sutter St
   Suite 570
   Concord, CA  94520

   Phone: +1 925/363-8720

Peterson, et al.         Expires March 2, 2004                 [Page 13]
Internet-Draft               SIPPING E.164                September 2003

   Hong Liu
   NeuStar, Inc.
   46000 Center Oak Plaza
   Sterling, VA  20166


   James Yu
   NeuStar, Inc.
   46000 Center Oak Plaza
   Sterling, VA  20166

   Phone: +1 571/434-5572

   Ben Campbell
   5100 Tennyson Parkway
   Suite 1200
   Plano, TX  75024


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.  Thanks are due as well to Juan Heinanen and Lawrence
   E.  Conroy for advice on updating this document to better reflect
   RFC2916bis.  Special thanks are given to Patrik Faltstrom and Michael
   Mealling for significantly reducing the size of this document by
   producing a tight and well-specified successor to RFC2916.  Richard
   Stastny and Patrik Faltstrom also provided valuable notes on the
   valid usage of non-greedy regexp antecedents.

Peterson, et al.         Expires March 2, 2004                 [Page 14]
Internet-Draft               SIPPING E.164                September 2003

Full Copyright Statement

   Copyright (C) The Internet Society (2003).  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

   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


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

Peterson, et al.         Expires March 2, 2004                 [Page 15]