RFC 3764

RFC 3764: enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record ✨

Okay bestie, here's the title block 🎀 It's from the Network Working Group, written by J. Peterson at NeuStar, and published in April 2004 as a Standards Track document, so it's a real protocol spec, not just a chill FYI. It doesn't obsolete or update any other RFCs. 💅

Status of This Memo 📜

This doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). 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), following the guidelines in RFC 3761. Specifically, it 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

1. Introduction 🌸

So 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 mainly to help systems that run on telephone numbers talk to systems 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. It lets endpoints on the Internet find one another so they can swap context info about a session they want to share 💖 Common stuff SIP sets up includes Internet telephony, instant messaging, video, Internet gaming, and other kinds of real-time communications. It's giving multi-service energy: SIP can start sessions with different forms of real-time communication all at once. It's also a protocol that finds the best way for parties to communicate. Iconic. 👑

2. ENUM Service Registration 🎀

Following [1], here's the template with the info needed to register the enumservice in this document. Literally everything you'd need is right here:

   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

3. Addresses-of-record in SIP 🦋

This document specifies an enumservice field that fits SIP addresses-of-record URIs. Other types of URIs can show up in SIP requests too. A URI tied to a particular SIP user agent (like a SIP phone) is commonly called a SIP contact address. 📱

Here's the vibe check: a contact address vs. an address-of-record is like a device vs. its user. There's no formal difference in the syntax of these two, but contact addresses belong to one specific device and can look super device-specific (like sip:10.0.0.1, or sip:edgar@ua21.example.com). An address-of-record, though, represents the user's identity, usually a long-term one, and it doesn't depend on any device. Users can move between devices, or even be linked to several devices at once, and keep 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 user agent creates a SIP request, it fills the address-of-record of its target into the To header field and (usually) the Request-URI. The address-of-record of the user sending the request goes in the From header field of the message, and the contact address of the device sending it goes in the Contact header field. 💌

Now, a SIP device (i.e., a user agent) can send a registration to a registrar on behalf of its user. That temporarily links the device's own contact address with the user's address-of-record. Once that's done, the device can receive requests sent to the address-of-record 🌈 When the registrar gets the registration request, it updates the provisioning data in a SIP location service so there's a mapping between the user's address-of-record and the device where they can be reached right now. When future requests arrive at that location service's administrative domain for the user, proxy servers ask the location service where to find them, and they'll find the registered contact address(es). A SIP-based follow-me telephony service, for example, depends on this real-time availability data to find the best place to reach the end user, so it doesn't have to cycle through a ton of devices the user isn't registered on. Also, addresses-of-record can be registered under other addresses-of-record. For example, while at home, a user might register the address-of-record they use as their personal identity under their work address-of-record, so requests for their work identity go to whatever devices they've linked to their home address-of-record 🏡

When a SIP entity (a user agent or a proxy server) needs to make a forwarding decision for a Request-URI that contains an address-of-record, it uses the mechanisms in the SIP specification (RFC 3263) to find the right resource in the network. Usually that means resolving the domain portion of the URI (example.com in the example above), so the call gets routed to a proxy server responsible for that domain. 🧭

SIP user agents have specific communication capabilities, like starting voice calls with particular codecs or supporting particular SIP protocol extensions. An address-of-record doesn't represent any particular device or set of devices, so it doesn't have capabilities of its own. When a SIP user agent sends a request to an address-of-record, it kicks off a capability negotiation phase that eventually finds the best way for the originator to communicate with the target 🤝 The originating user agent starts by telling the request about its own capabilities (and its preferences for the type of session it wants). Expressing those capabilities might involve SDP [8] to list the acceptable media types the client supports and favors, including Required/Supported headers to negotiate extension compatibility, and maybe optional SIP extensions, like using callee capabilities [7] to communicate request handling dispositions. Then proxy servers or endpoints send back responses, and that makes for a rich, bidirectional capability negotiation process 💅

The capability negotiation process can overlap with the main service NAPTR records provide: letting the originating client pick a particular URI for communication based on an ordered list of enumservices. But ENUM's capability management is totally one-way. The telephone number's administrator states capabilities (as protocol names) and preferences, and the client has to evaluate them without any negotiation. Also, listing available protocols isn't comparable to agreeing on session media (right down to the codec and interval level) and protocol extension support. It would be really hard to express the capabilities of a SIP device in a NAPTR service field at the level of detail needed to set up a desired session 😭 So provisioning contact addresses in ENUM instead of addresses-of-record would compromise SIP's capability negotiation and discovery process. A big part of why URIs are useful is that they represent a logical service tied to a user, not a device. In fact, if ENUM wanted to target particular devices, 'E2IPv4' would be a better resolution service to define than 'E2U' 🔥

SIP addresses-of-record may use the SIP URI scheme or the SIPS URI scheme. When the SIPS URI scheme is used in an address-of-record, it means the user can only be reached over a secure connection (using TLS) 🔐

6. Security Considerations 🔒✨

okay bestie, this section is the spicy one 🌶️ A SIP address-of-record is basically the canonical address a user is known by, so putting it in ENUM is comparable to placing an email address or a similar URI in the DNS 📬

DNS doesn't make policy decisions about the records it hands out to whoever asks 🙈 All DNS records have to be assumed available to all inquirers at all times. So the info in an ENUM record set is considered open to the public, and that's a real reason to think about privacy 🔍

Now the plot twist 🦋 Unlike a traditional telephone number, the resource identified by a SIP URI may require callers to provide cryptographic credentials for authentication and authorization before a user is alerted. Honestly? ENUM with SIP can give way better protection from unwanted callers than the PSTN, even with the records being public 💅 An analysis of threats specific to ENUM's dependence on the DNS, and how DNSSEC [9] applies to them, lives 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.

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 🫶

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

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.