💾 Archived View for gemini.bortzmeyer.org › rfc-mirror › rfc3824.txt captured on 2023-06-16 at 18:56:52.
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
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 '^.*