RFC 4415

RFC 4415: IANA Registration for Enumservice Voice 💖

okay bestie, RFC 4415 is giving "register a brand new ENUM service called voice" 🎀 this is part 1 of 2!

The title block, the important bits 📋

• Number and title: RFC 4415, IANA Registration for Enumservice Voice
• Authors: R. Brandner (Siemens AG), L. Conroy (Siemens Roke Manor Research), and R. Stastny (Oefeg)
• Category: Standards Track
• Date: February 2006
• Obsoletes or updates: the header doesn't list anything it obsoletes or updates 🙅

Status of This Memo

This document specifies an Internet standards track protocol for the Internet community and asks 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 (2006) ✨

Abstract

This doc registers the Enumservice "voice" (which has a defined subtype "tel") through the IANA registration process from the ENUM spec, RFC 3761 🦋 The service says the contact in the generated Uniform Resource Identifier (URI) can be used to start an interactive voice (audio) call 📞

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.  Voice Service Registration  . . . . . . . . . . . . . . . . . . 3
4.  Example of voice:tel Enumservice  . . . . . . . . . . . . . . . 4
5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
    7.1.  Normative References  . . . . . . . . . . . . . . . . . . 6
    7.2.  Informative References  . . . . . . . . . . . . . . . . . 6

1. Introduction ✨

Okay so ENUM (E.164 Number Mapping, RFC 3761 [1]) is the system that turns E.164 numbers [2] into domain names. Then it uses DNS (RFC 1034 [3]) stuff like delegation through NS records and Naming Authority Pointer (NAPTR) records [4] to look up which communication services are available for that domain name 🔍 main character energy for phone numbers, honestly 💖

This doc registers an Enumservice following the guidelines in RFC 3761 🎀 It goes in the services field of a NAPTR [4] resource record and tells you what class of functionality an endpoint offers. The registration lives inside the Dynamic Delegation Discovery System (DDDS, [5] [6] [4] [7] [8]) hierarchy, and it's meant for the "E2U" DDDS application defined in RFC 3761 🧚

Enumservices have a type and a subtype 💅 The subtype is optional because it can be implied by the service type. The type defines what kind of communication session can be started using the contact in the URI that the enclosing NAPTR generates. In telecom terms, this is the "teleservice" 📞

The subtype says which subsystem gets used to start that session 🫶 It's usually tied to the URI scheme being used, so they go together like peanut butter and jelly 🍓

There are a bunch of DDDS applications besides ENUM (see [7] and [8], for example) 🌈 But an Enumservice indication only works inside the "E2U" (ENUM) DDDS Application. No exceptions, bestie 🙅

The protocol elements that make up ENUM are defined in the documents above and in this one. Other documents give more examples of what they can be used for, like ETSI TS 102 172 [11] 🦋

Now the actual main event: this doc registers the Enumservice "voice" (which has a defined subtype "tel") through the IANA registration process in the ENUM spec, RFC 3761 💖 The service says the contact in the generated URI can be used to start an interactive voice (audio) call 📞

2. Terminology 🎀

Here's the key word list. These words are interpreted as described in BCP 14, RFC 2119 [9] ✨ The words are "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 💅

3. Voice Service Registration 📞

Here's the registration template with its short fields, bestie 💖

Enumservice Name: "voice"

Enumservice Type: "voice"

Enumservice Subtype: "tel"

URI Scheme: 'tel:'

Functional Specification: the kind of communication this Enumservice indicates is "Interactive Voice" 🎧 From a protocol point of view, it's expected to involve bidirectional media streams carrying audio data. Literally two-way audio, no cap 🔥

A client may imply that the person who controls the population of a NAPTR holding this Enumservice is saying they can do an interactive voice session when someone contacts them through the URI generated by this NAPTR 🌸

Security Considerations: see Section 5 🔐

Intended Usage: COMMON 💅

Authors: Rudolf Brandner, Lawrence Conroy, and Richard Stastny (for author contact details, see the Authors' Addresses section) 🫶

Any other information the author deems interesting: this Enumservice says the person responsible for the NAPTR can be reached over the Public Switched Telephone Network (PSTN) or the Public Land Mobile Network (PLMN), using the value of the generated URI 📱 It's giving "call me on the phone" energy 💜

The subsystem you need to start a Voice Enumservice with this subtype is a "Dialer" 🎀 A Dialer either gives you a local connection to the PSTN or PLMN, or it gives you an indirect connection to those networks. It uses the telephone number in the generated URI to place the voice call, and the call goes to a network that uses E.164 numbers to route calls to the right destination ☎️

The PSTN/PLMN connection can be indirect, and that's lowkey the interesting part 👀 The end user who receives this NAPTR might have a deal with a Communications Service Provider. That provider accepts call initiation requests from the Dialer over an IP-based protocol like SIP or H.323, then places the call to the PSTN through a remote gateway service. In that setup, the provider either accepts requests using "tel:" URIs, or it has a defined way to convert "tel:" URI values into a "protocol-native" form 🌈

The "tel:" URI value SHOULD be fully qualified, using the "global phone number" form from RFC 3966 [10] 💖 A "local phone number" as defined in that doc SHOULD NOT be used unless the controller of the zone where the NAPTR appears is sure that every client who can access the resource record can tell it apart unambiguously, and that a call from their network access points can get routed to that destination 🙈

Part 2 picks up at Section 4 🧚✨

7.2. Informative References ✨

Okay bestie, here are the informative references (the "good to know" reading list 📚):

• [11] ETSI, "Minimum Requirements for Interoperability of ENUM Implementations", ETSI TS 102 172, January 2005. 💅
• [12] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004. 🔥

Authors' Addresses 🎀

Okay, the people who wrote this doc, and how to reach them 💌

Rudolf Brandner 🇩🇪

Siemens AG
Hofmannstr. 51
81359 Munich
Germany

Phone: +49-89-722-51003
EMail: rudolf.brandner@siemens.com

Lawrence Conroy 🇬🇧

Siemens Roke Manor Research
Roke Manor
Romsey
United Kingdom

Phone: +44-1794-833666
EMail: lwc@roke.co.uk

Richard Stastny 🇦🇹

Oefeg
Postbox 147
1103 Vienna
Austria

Phone: +43-664-420-4100
EMail: Richard.stastny@oefeg.at

---

Full Copyright Statement 🌈

Copyright (C) The Internet Society (2006).

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 provided by the IETF Administrative Support Activity (IASA). 💜