GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3824

Network Working Group J. Peterson Request for Comments: 3824 H. Liu Category: Informational J. Yu

                                                               NeuStar
                                                           B. Campbell
                                                           dynamicsoft
                                                             June 2004
   Using E.164 numbers with the Session Initiation Protocol (SIP)

Status of this Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2004).

Abstract

 There are a number of contexts in which telephone numbers are
 employed by Session Initiation Protocol (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 reason, cannot be used to resolve a
 telephone number.

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
 2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
 3.  Handling Telephone Numbers in SIP  . . . . . . . . . . . . . .  3
 4.  Design Principles  . . . . . . . . . . . . . . . . . . . . . .  5
 5.  Authoring NAPTR Records for SIP  . . . . . . . . . . . . . . .  6
     5.1.  The Service Field  . . . . . . . . . . . . . . . . . . .  6
     5.2.  Creating the Regular Expression: Matching  . . . . . . .  6
     5.3.  Creating the Regular Expression: The URI . . . . . . . .  7
     5.4.  Setting Order and Preference amongst Records . . . . . .  8
     5.5.   Example of a Well-Formed ENUM NAPTR Record Set for SIP.  8
 6.  Processing ENUM Records  . . . . . . . . . . . . . . . . . . .  8
     6.1.  Contending with Multiple SIP records . . . . . . . . . .  8

Peterson, et al. Informational [Page 1] RFC 3824 SIPPING E.164 June 2004

     6.2.  Processing the Selected NAPTR Record . . . . . . . . . .  9
 7.  Compatibility with RFC 3761. . . . . . . . . . . . . . . . . . 10
 8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
 9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     9.1.  Normative References . . . . . . . . . . . . . . . . . . 11
     9.2.  Informative References . . . . . . . . . . . . . . . . . 12
 A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
     Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
     Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16

1. Introduction

 ENUM (E.164 Number Mapping, RFC 3761 [1]) is a system that uses DNS
 (Domain Name Service, RFC 1034 [4]) in order to translate certain
 telephone numbers, like '+12025332600', into URIs (Uniform Resource
 Identifiers, RFC 2396 [9]), 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.  E.164 [10] is the ITU-T standard international
 numbering plan, under which all globally-reachable telephone numbers
 are organized.
 SIP (Session Initiation Protocol, RFC 3261 [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 (RFC 3403 [6]) and ENUM (RFC 3761 [1]).  Only
 those aspects of NAPTR record authoring and processing that have

Peterson, et al. Informational [Page 2] RFC 3824 SIPPING E.164 June 2004

 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 RFC 2915 [12] to the Dynamic Delegation
 Discovery System (DDDS) family of specifications (including RFC
 3403).  This document therefore provides some guidance for handling
 records designed for the original RFC 2916 [16].
 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 RFC 2916 are given in Section 7.

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 RFC 2119 [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

Peterson, et al. Informational [Page 3] RFC 3824 SIPPING E.164 June 2004

 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.
 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 RFC 2806 [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
 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 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.

Peterson, et al. Informational [Page 4] RFC 3824 SIPPING E.164 June 2004

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 document:
    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 [13], the use of Require/Supported to
    negotiate extensions in RFC 3261, 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
    records.

Peterson, et al. Informational [Page 5] RFC 3824 SIPPING E.164 June 2004

    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.
 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 RFC 3403) 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
 URI.

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

Peterson, et al. Informational [Page 6] RFC 3824 SIPPING E.164 June 2004

 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 e164.arpa 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
 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: "!^.*$!sip:user@example.com!"
 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
 SIP.
 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

Peterson, et al. Informational [Page 7] RFC 3824 SIPPING E.164 June 2004

 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.

5.5. 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" "E2U+sip"    "!^.*$!sip:user@example.com!"     .
  IN NAPTR 100 20 "u" "E2U+mailto" "!^.*$!mailto:info@example.com!"  .

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

Peterson, et al. Informational [Page 8] RFC 3824 SIPPING E.164 June 2004

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

Peterson, et al. Informational [Page 9] RFC 3824 SIPPING E.164 June 2004

 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.

7. Compatibility with RFC 2916

 The ENUM specification is currently undergoing a revision in the ENUM
 WG.  The new specification, RFC 3761 [1], is based on the Dynamic
 Delegation Discovery System [5] revision to the NAPTR resource record
 specified in RFC 2915 [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 RFC 3761 is the concept of
 enumservices.  The original ENUM specification, RFC 2916, specified a
 number of "service" values that could be used for ENUM, including the
 "sip+E2U" service field.  RFC 3761 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 RFC 3761 from those in RFC
 2916, the string "E2U" is the leading element in an enumservice
 field, whereas by RFC 2916 it was the trailing element.
 An enumservice for SIP addresses-of-record is described in [7].  This
 enumservice uses the enumservice field "E2U+sip".  RFC 3761-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 SIP.
 Also note that the terminology of DDDS differs in a number of
 respects from the initial NAPTR terminology in RFC 2916.  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 RFC 3761.

Peterson, et al. Informational [Page 10] RFC 3824 SIPPING E.164 June 2004

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
 'julia.roberts@example.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@example.com' or even
 'sip:anonymous00045@anonymous-redirector.example.org', which could in
 turn point to their internal URI.
 An analysis of threats specific to the dependence of ENUM on the DNS,
 and the applicability of DNSSEC [18] to these, is provided in [1].

9. References

9.1. Normative References

 [1]   Faltstrom, P. and M. Mealling, "E.164 to Uniform Resource
       Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
       Application (ENUM)", RFC 3761, April 2004.
 [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", BCP 14, RFC 2119, March 1997.

Peterson, et al. Informational [Page 11] RFC 3824 SIPPING E.164 June 2004

 [4]   Mockapetris, P., "Domain Names - Concepts and Facilities",
       STD13, RFC 1034, November 1987.
 [5]   Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
       One: The Comprehensive DDDS", RFC 3401, October 2002.
 [6]   Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
       Three: The Domain Name System (DNS) Database", RFC 3403,
       October 2002.
 [7]   Peterson, J., "enumservice registration for SIP Addresses-of-
       Record", RFC 3764, April 2004.
 [8]   Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April
       2000.
 [9]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
       Resource Identifiers (URI): Generic Syntax", RFC 2396, August
       1998.

9.2. Informative References

 [10]  International Telecommunications Union, "Recommendation E.164:
       The international public telecommunication numbering plan", May
       1997, <http://www.itu.int>.
 [11]  Rosenberg, J., Schulzrinne, H. and P. Kyzviat, "Indicating User
       Agent Capabilities in the Session Initiation Protocol (SIP)",
       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
       2000.

Peterson, et al. Informational [Page 12] RFC 3824 SIPPING E.164 June 2004

 [17]  Peterson, J., "Enumservice Registration for Presence Services",
       Work in Progress, February 2003.
 [18]  Arends, R., et al., "Protocol Modifications for the DNS
       Security Extensions", Work in Progress, May 2004.

Peterson, et al. Informational [Page 13] RFC 3824 SIPPING E.164 June 2004

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 RFC
 3761.  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 RFC 2916.  Richard
 Stastny and Patrik Faltstrom also provided valuable notes on the
 valid usage of non-greedy regexp antecedents.

Peterson, et al. Informational [Page 14] RFC 3824 SIPPING E.164 June 2004

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/
 Ben Campbell
 dynamicsoft
 5100 Tennyson Parkway
 Suite 1200
 Plano, TX  75024
 USA
 EMail: bcampbell@dynamicsoft.com
 URI:   http://www.dynamicsoft.com/

Peterson, et al. Informational [Page 15] RFC 3824 SIPPING E.164 June 2004

Full Copyright Statement

 Copyright (C) The Internet Society (2004).  This document is subject
 to the rights, licenses and restrictions contained in BCP 78, and
 except as set forth therein, the authors retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at ietf-
 ipr@ietf.org.

Acknowledgement

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

Peterson, et al. Informational [Page 16]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3824.txt · Last modified: 2004/06/24 22:56 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki