summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3764.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3764.txt')
-rw-r--r--doc/rfc/rfc3764.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc3764.txt b/doc/rfc/rfc3764.txt
new file mode 100644
index 0000000..2f544ab
--- /dev/null
+++ b/doc/rfc/rfc3764.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group J. Peterson
+Request for Comments: 3764 NeuStar
+Category: Standards Track April 2004
+
+
+ enumservice registration for Session Initiation Protocol (SIP)
+ Addresses-of-Record
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This document registers an Electronic Number (ENUM) service for the
+ Session Initiation Protocol (SIP), pursuant to the guidelines in RFC
+ 3761. Specifically, this document focuses on provisioning SIP
+ addresses-of-record in ENUM.
+
+Table of Contents
+
+ 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. ENUM Service Registration . . . . . . . . . . . . . . . . . . . 2
+ 3. Addresses-of-record in SIP. . . . . . . . . . . . . . . . . . . 3
+ 4. The 'E2U+SIP' enumservice . . . . . . . . . . . . . . . . . . . 5
+ 5. Example of E2U+SIP enumservice. . . . . . . . . . . . . . . . . 5
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
+ 8. References. . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 8.1. Normative References. . . . . . . . . . . . . . . . . . . 6
+ 8.2. Informative References. . . . . . . . . . . . . . . . . . 7
+ 9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . 7
+ 10. Author's Address. . . . . . . . . . . . . . . . . . . . . . . . 7
+ 11. Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 8
+
+
+
+
+
+
+
+
+
+Peterson Standards Track [Page 1]
+
+RFC 3764 SIP enumservice April 2004
+
+
+1. Introduction
+
+ ENUM (E.164 Number Mapping, RFC 2916 [6]) is a system that uses DNS
+ (Domain Name Service, STD 13, RFC 1034 [3]) to translate telephone
+ numbers, like '+12025332600', into URIs (Uniform Resource
+ Identifiers, RFC 2396 [4]), like 'sip:egar@example.com'. ENUM exists
+ primarily to facilitate the interconnection of systems that rely on
+ telephone numbers with those that use URIs to route transactions.
+ This document applies to the revised version of ENUM described in RFC
+ 3761.
+
+ SIP (Session Initiation Protocol, RFC 3261 [2]) is a text-based
+ application protocol that allows endpoints on the Internet to
+ discover one another in order to exchange context information about a
+ session they would like to share. Common forms of communication that
+ are set up by 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.
+ SIP is a protocol that finds the best way for parties to communicate.
+
+2. ENUM Service Registration
+
+ As defined in [1], the following is a template covering information
+ needed for the registration of the enumservice specified in this
+ document.
+
+ Enumservice Name: "E2U+SIP"
+
+ Type(s): "SIP"
+
+ Subtype(s): N/A
+
+ URI Scheme(s): "sip:", "sips:"
+
+ Functional Specification: see Section 4
+
+ Security considerations: see Section 6
+
+ Intended usage: COMMON
+
+ Author: Jon Peterson (jon.peterson@neustar.biz)
+
+ Any other information that the author deems interesting: See
+ Section 3
+
+
+
+
+
+
+Peterson Standards Track [Page 2]
+
+RFC 3764 SIP enumservice April 2004
+
+
+3. Addresses-of-record in SIP
+
+ This document specifies an enumservice field that is appropriate for
+ SIP addresses-of-record URIs. Various other types of URIs can be
+ present in SIP requests. A URI that is associated with a particular
+ SIP user agent (for example, a SIP phone) is commonly known as a SIP
+ contact address.
+
+ The difference between a contact address and an address-of-record is
+ like the difference between a device and its user. While there is no
+ formal distinction in the syntax of these two forms of addresses,
+ contact addresses are associated with a particular device, and may
+ have a very device-specific form (like sip:10.0.0.1, or
+ sip:edgar@ua21.example.com). An address-of-record, however,
+ represents an identity of the user, generally a long-term identity,
+ and it does not have a dependency on any device; users can move
+ between devices or even be associated with multiple devices at one
+ time while retaining the same address-of-record. A simple URI,
+ generally of the form 'sip:egdar@example.com', is used for an
+ address-of-record.
+
+ When a SIP request is created by a user agent, it populates the
+ address-of-record of its target in its To header field and
+ (generally) Request-URI. The address-of-record of the user that is
+ sending the request populates the From header field of the message;
+ the contact address of the device from which the request is sent is
+ listed in the Contact header field.
+
+ By sending a registration to a registrar on behalf of its user, a SIP
+ device (i.e., a user agent) can temporarily associate its own contact
+ address with the user's address-of-record. In so doing, the device
+ becomes eligible to receive requests that are sent to the address-
+ of-record. Upon receiving the registration request, the registrar
+ modifies the provisioning data in a SIP location service to create a
+ mapping between the address-of-record for the user and the device
+ where the user can currently be reached. When future requests arrive
+ at the administrative domain of this location service for the user in
+ question, proxy servers ask the location service where to find the
+ user, and will in turn discover the registered contact address(es).
+ A SIP-based follow-me telephony service, for example, would rely on
+ this real-time availability data in order to find the best place to
+ reach the end user without having to cycle through numerous devices
+ from which the user is not currently registered. Note that
+ addresses-of-record can be registered with other addresses-of-record;
+ for example, while at home, a user might elect to register the
+ address-of-record they use as their personal identity under their
+
+
+
+
+
+Peterson Standards Track [Page 3]
+
+RFC 3764 SIP enumservice April 2004
+
+
+ work address-of-record in order to direct requests for their work
+ identity to whatever devices they might have associated with their
+ home address-of-record.
+
+ When a SIP entity (be it a user agent or proxy server) needs to make
+ a forwarding decision for a Request-URI containing an address-of-
+ record, it uses the mechanisms described in the SIP specification
+ (RFC 3263) to locate the proper resource in the network. Ordinarily,
+ this entails resolving the domain portion of the URI (example.com in
+ the example above) in order to route the call to a proxy server that
+ is responsible for that domain.
+
+ SIP user agents have specific communications capabilities (such as
+ the ability to initiate voice communications with particular codecs,
+ or support for particular SIP protocol extensions). Because an
+ address-of-record does not represent any particular device or set of
+ devices, an address-of-record does not have capabilities as such.
+ When a SIP user agent sends a request to an address-of-record, it
+ begins a phase of capability negotiation that will eventually
+ discover the best way for the originator to communicate with the
+ target. The originating user agent first expresses capabilities of
+ its own in the request it sends (and preferences for the type of
+ session it would like to initiate). The expression of these
+ capabilities may entail the usage of SDP [8] to list acceptable types
+ of media supported and favored by the client, the inclusion of
+ Required/Supported headers to negotiate compatibility of extensions,
+ and possibly the usage of optional SIP extensions, for example using
+ callee capabilities [7] to communicate request handling dispositions.
+ Proxy servers or endpoints subsequently return responses that allow a
+ rich bidirectional capability negotiation process.
+
+ The process by which SIP endpoints negotiate capabilities can overlap
+ with the primary service provided by NAPTR records: permitting the
+ originating client to select a particular URI for communications
+ based on an ordered list of enumservices. However, ENUM's capability
+ management mechanism is decidedly one-way - the administrator of the
+ telephone number expresses capabilities (in the form of protocol
+ names) and preferences that the client must evaluate without
+ negotiation. Moreover, listing available protocols is not comparable
+ to agreement on session media (down to the codec/interval level) and
+ protocol extension support - it would be difficult to express, in the
+ level of detail necessary to arrange a desired session, the
+ capabilities of a SIP device within a NAPTR service field.
+ Provisioning contact addresses in ENUM rather than addresses-of-
+ record would compromise the SIP capability negotiation and discovery
+ process. Much of the benefit of using a URI comes from the fact that
+
+
+
+
+
+Peterson Standards Track [Page 4]
+
+RFC 3764 SIP enumservice April 2004
+
+
+ it represents a logical service associated with a user, rather than a
+ device - indeed, if ENUM wished to target particular devices,
+ 'E2IPv4' would be a more appropriate resolution service to define
+ than 'E2U'.
+
+ SIP addresses-of-record may use the SIP URI scheme or the SIPS URI
+ scheme. The SIPS URI scheme, when used in an address-of-record,
+ indicates that the user it represents can only be reached over a
+ secure connection (using TLS).
+
+4. The 'E2U+SIP' enumservice
+
+ Traditionally, the services field of a NAPTR record (as defined in
+ [5]) contains a string that is composed of two subfields: a
+ 'protocol' subfield and a 'resolution service' subfield. ENUM in
+ particular defines an 'E2U' (E.164 to URI) resolution service. This
+ document defines an 'E2U+SIP' enumservice for SIP.
+
+ The scheme of the URI that will appear in the regexp field of a NAPTR
+ record using the 'E2U+SIP' enumservice may either be 'SIP' or 'SIPS'.
+ This enumservice is best suited to SIP addresses-of-record.
+
+ When a SIP address-of-record appears in the regexp field of a NAPTR
+ record, there is no need to further qualify the enumservice field
+ with any capability data, since addresses-of-record do not have
+ capabilities.
+
+ There is also generally no need to have more than one NAPTR record
+ under a single telephone number that points to a SIP address-of-
+ record.
+
+ Note that the user portion of a SIP URI may contain a telephone
+ number (e.g., 'sip:+1442079460148@example.com'). Clients should be
+ careful to avoid infinite loops when recursively performing ENUM
+ queries on URIs that result from an ENUM lookup.
+
+5. Example of E2U+SIP enumservice
+
+ The following is an example of the use of the enumservice registered
+ by this document in a NAPTR resource record.
+
+$ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.
+ IN NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:edgar@example.com!" .
+
+
+
+
+
+
+
+
+Peterson Standards Track [Page 5]
+
+RFC 3764 SIP enumservice April 2004
+
+
+6. Security Considerations
+
+ A SIP address-of-record is a canonical address by which a user is
+ known - placing this address in ENUM is comparable to placing an
+ email address or a similar URI in the DNS.
+
+ 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.
+
+ Unlike a traditional telephone number, the resource identified by 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. An analysis of
+ threats specific to the dependence of ENUM on the DNS, and the
+ applicability of DNSSEC [9] to these, is provided in [1].
+
+7. IANA Considerations
+
+ This document registers the 'E2U+SIP' enumservice under the
+ enumservice registry described in the IANA considerations in RFC
+ 3761. Details of the registration are given in Section 2.
+
+8. References
+
+8.1. Normative References
+
+ [1] Faltstrom, P. and M. Mealling, "The 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] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
+ 13, RFC 1034, November 1987.
+
+ [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
+ Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
+
+ [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+ Three: The Domain Name System (DNS) Database", RFC 3403, October
+ 2002.
+
+
+
+Peterson Standards Track [Page 6]
+
+RFC 3764 SIP enumservice April 2004
+
+
+8.2. Informative References
+
+ [6] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
+
+ [7] Rosenberg, J., Schulzrinne, H. and P. Kyzviat, "Indicating User
+ Agent Capabilities in the Session Initiation Protocol (SIP)",
+ Work in Progress.
+
+ [8] Handley, M. and V. Jacobson, "SDP: Session Description
+ Protocol", RFC 2327, April 1998.
+
+ [9] R. Arends, et al., "Protocol Modifications for the DNS Security
+ Extensions", Work in Progress.
+
+9. Acknowledgements
+
+ Thanks to Richard Shockey for comments on the initial draft of this
+ document, and to Allison Mankin for valuable review comments.
+
+10. Author's Address
+
+ 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/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Peterson Standards Track [Page 7]
+
+RFC 3764 SIP enumservice April 2004
+
+
+11. 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 Standards Track [Page 8]
+