RFC 5278

IANA Registration of Enumservices for Voice and Video Messaging

📅 published July 2008, from ietf

RFC 5278 💖 IANA Registration of Enumservices for Voice and Video Messaging

Okay bestie, this is RFC 5278, IANA Registration of Enumservices for Voice and Video Messaging, dated July 2008 ✨. Two authors wrote it: J. Livingood from Comcast Cable Communications and D. Troshynski from Acme Packet. It's a Standards Track document, and its title block doesn't list anything it obsoletes or updates 🎀. It came out of the Network Working Group 🦋.

Status of This Memo 📜

So this section is the legal-ish bit, but it's giving: this document specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements 💅. If you want the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1) 🌸. Distribution of this memo is unlimited 🌈.

Abstract 🦋

Okay so the big idea is that this document registers an Enumservice named "vmsg" 💜. Its job is to help real-time routing of voice, video, and unified communications over to a messaging system 📞. The vmsg Enumservice registers three Enumservice types: "voicemsg", "videomsg", and "unifmsg" 🍓. Each type also registers the subtypes "sip", "sips", "http", and "https" ✨. The "voicemsg" type gets an extra subtype too, "tel" 🎀.

Table of Contents 🗂️

   1. Introduction ....................................................3
      1.1. Selected Use Cases for Illustrative Purposes ...............4
      1.2. Consideration of Other Existing Enumservices ...............5
   2. Distribution of Data ............................................5
   3. Security Considerations .........................................5
   4. ENUM Service Registration for voicemsg ..........................6
      4.1. Registration for "voicemsg" with Subtype "sip" .............6
      4.2. Registration for "voicemsg" with Subtype "sips" ............7
      4.3. Registration for "voicemsg" with Subtype "tel" .............7
      4.4. Registration for "voicemsg" with Subtype "http" ............8
      4.5. Registration for "voicemsg" with Subtype "https" ...........9
   5. ENUM Service Registration for videomsg .........................10
      5.1. Registration for "videomsg" with Subtype "sip" ............10
      5.2. Registration for "videomsg" with Subtype "sips" ...........10
      5.3. Registration for "videomsg" with Subtype "http" ...........11
      5.4. Registration for "videomsg" with Subtype "https" ..........12
   6. ENUM Service Registration for unifmsg ..........................13
      6.1. Registration for "unifmsg" with Subtype "sip" .............13
      6.2. Registration for "unifmsg" with Subtype "sips" ............13
      6.3. Registration for "unifmsg" with Subtype "http" ............14
      6.4. Registration for "unifmsg" with Subtype "https" ...........15
   7. Selected Examples for Illustrative Purposes ....................16
      7.1. Example Using a 'sip' URI .................................16
      7.2. Example Using a 'tel' URI .................................16
      7.3. Example Using a Backreference .............................16
      7.4. Example Using a 'sip' URI without a Telephone Number ......17
      7.5. Example of Failover Using E2U+videomsg:sip ................17
   8. Implementation Recommendations .................................17
      8.1. Call Processing When Multiple Records Are Returned ........17
      8.2. NAPTR Configuration Issues ................................18
   9. IANA Considerations ............................................18
   10. Acknowledgements ..............................................18
   11. Contributors ..................................................19
   12. References ....................................................19
      12.1. Normative References .....................................19
      12.2. Informative References ...................................20

1. Introduction 🧚

Okay, so first the basics. ENUM (E.164 Number Mapping, RFC 3761 [1]) is a technology that turns E.164 numbers (the International Public Telecommunication Numbering Plan, ITU-T Recommendation E.164 [2]) into domain names 🌐. Then it uses DNS (Domain Name System, RFC 1034 [3]) delegation through NS records and Naming Authority Pointer (NAPTR) records (Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database, RFC 3403 [4]) to look up which services are available for a specific domain name 🔍.

This document registers Enumservices following the guidelines in RFC 3761 [1] 💅. They go in the services field of a NAPTR [4] resource record, to show what kind of functionality is tied to an end point and/or telephone number 📞. The registration lives inside the DDDS hierarchy (Dynamic Delegation Discovery System [4][5][6][7][8]), and it's meant for the "E2U" DDDS Application defined in RFC 3761 💜.

Voice messaging systems are everywhere in telephony and voice communication services 🎀. There's a clear need for a voice messaging service type so certain apps can directly reach voice messaging services, like voicemail, and that's mostly going to happen through SIP 🦋.

The authors looked at using Voice Profile for Internet Mail (VPIM) [14] 🤔. But VPIM fits best for non-real-time, non-session-based routing of a voice message after it's already been dropped into a voice messaging system 📬. So VPIM is a great fit for that non-real-time, non-session-based routing of voice messages between and within domains. It just doesn't let you have real-time interaction with a voice messaging system 🙈.

So yeah, a need was identified for this voice messaging service type, which would enable things like some of the use cases in this section 🌸.

Video messaging systems (sometimes called visual voice messaging systems) are starting to show up alongside real-time communication services 📹. There's a clear need for a video messaging service type so apps can directly access video messaging services, mostly via SIP 🌈. So a need was identified for this video messaging service type too, to enable things like some of the use cases in this section ✨.

Last but not least, lots of service providers and software developers said their voice messaging and video messaging systems either have already been, or soon will be, unified into one system 🫶. They wanted the option to use an Enumservice type that treats a subscriber's mailbox as a so-called unified messaging repository 👑. That's the unified voice and video messaging service type, and it's needed for some of the use cases in this section too 💖.

1.1. Selected Use Cases for Illustrative Purposes 🎀

This is a partial, non-exclusive list of use cases the vmsg Enumservice could address 💅:

  • A called party is busy or doesn't answer a call. A client or server then decides a messaging service should be used, and sends the calling party's session to that service. The client or server needs to be able to figure out which server to point this real-time session at, whether it's inside or outside the called party's domain 📞.
  • It's kind of like the one above, except a real-time session is tried against a messaging system, and that system is down right now 💀. Since the original ENUM query can return multiple service type records, the client or server could try to start a session with one or more backup messaging servers. That happens transparently to the calling party, and it helps keep messaging service more available overall 🛟.
  • Same vibe as above: this service type could also balance load across multiple messaging servers, whether they're in the same physical location or in different ones ⚖️.
  • A user with an account on a messaging service needs to connect to it to get their messages. They start a real-time session, and an ENUM query is done to find the messaging server holding their mailbox 📥.
  • While a real-time, automated, and interactive session with a user is being set up and run (for message deposit or retrieval), VoiceXML files get referenced and used, over either HTTP or HTTPS 🧃. Multiple VoiceXML servers could be linked to one user and returned by an ENUM query, for things like load balancing 🍓.

1.2. Consideration of Other Existing Enumservices 🔎

Okay so the authors asked whether this could just use the SIP Enumservice type [19] 🤨. Short answer: no. It doesn't meet their voice messaging requirements, especially with the non-SIP URI subtypes specified in this document 🙅‍♀️. Even with subtypes for SIP URIs, there are still problems with using the SIP Enumservice type 😩. For example, a request for access to such a service could be pushed to the requesting SIP client (the User Agent Client, or UAC), instead of depending on the local policy of a SIP server (the User Agent Server, or UAS). That means special routing logic inside a UAS can't be counted on to solve this 🫠.

The biggest problem, though, is that without this service type, a UAC or UAS gets handed multiple SIP URIs. Without non-standards-based routing rules or application logic, it has no way to tell which one is for voice messaging, video messaging, or unified voice and video messaging 🥲.

2. Distribution of Data 📦

The authors think these records are more likely to be distributed on a purely private basis 🔒. They could also be published in public ENUM trees 🌳. The NAPTR data could be distributed (a) privately within a service provider's internal network, (b) privately between one or more parties using a variety of security mechanisms to block general public access, or (c) openly available 🌸.

3. Security Considerations 🔐

okay so this is the part where we get serious bestie 🥺 DNS is a global, distributed database, which means ENUM rides on something everyone can look into. If you use e164.arpa or any other publicly available domain for voicemsg Enumservice data, anyone can see it, and nobody gets an anonymous tap on the shoulder saying "hey, someone just looked you up." 👀

It's not totally new, because phone numbers in a telephone directory are already public. But ngl it makes the data way easier to get at, and there's zero signal about whether it's been accessed or by who. 🫣

Harvesting is the real villain here. Third parties love scraping this stuff to build target lists for unsolicited messages. So someone could build a list and use it for unsolicited telemarketing calls, or what's called SPAM over Internet Telephony (SPIT). 📞🚫 Lots of countries have do-not-call registries or other legal or regulatory mechanisms to deal with this kind of abuse, so it's not a free-for-all. 💅

Here's the fix, and it's giving protection. As noted earlier, carriers, service providers, and other users can simply choose not to publish this info in the public e164.arpa tree. Instead they can keep it in an internal ENUM routing database that only trusted elements of their network and/or partner networks can query, such as softswitches and SIP proxy servers. 🏰 They can also publish in a carrier-only branch of the e164.arpa tree, should one be created. 🌸

Also, an E.164 telephone number doesn't reveal as much identity info as a name in the format sip:username@hostname or email:username@hostname. But the number is still publicly available, so the risk of unwanted communication is still there. 😬

If you want the deep dive, the threats specific to ENUM's dependence on the DNS and the applicability of DNSSEC [16] are covered in RFC 3761 [1]. A thorough look at threats to the DNS itself is in RFC 3833 [17]. 🧠✨

4. ENUM Service Registration for voicemsg 🎀

okay the registrations are where the magic happens 🪄 each subtype gets its own template, and the field names and values have to stay exact so the registry stays clean. Here's how it goes.

4.1. Registration for "voicemsg" with Subtype "sip" 📞

Enumservice Name: "voicemsg"

Enumservice Type: "voicemsg"

Enumservice Subtypes: "sip"

URI Schemes: 'sip:'

Functional Specification:

This Enumservice indicates that the remote resource identified can be
addressed by the associated URI scheme in order to initiate a voice
communication session to a voice messaging system.

Security Considerations: See Section 3.

Intended Usage: COMMON

Authors:

Jason Livingood (jason_livingood@cable.comcast.com)
Don Troshynski (dtroshynski@acmepacket.com)
Any other information the author deems interesting:

Implementers should review a non-exclusive list of examples below in
Section 7.

4.2. Registration for "voicemsg" with Subtype "sips" 🔒

Enumservice Name: "voicemsg"

Enumservice Type: "voicemsg"

Enumservice Subtypes: "sips"

URI Schemes: 'sips:'

Functional Specification:

This Enumservice indicates that the remote resource identified can be
addressed by the associated URI scheme in order to initiate a voice
communication session to a voice messaging system.

Security Considerations: See Section 3.

Intended Usage: COMMON

Authors:

Jason Livingood (jason_livingood@cable.comcast.com)
Don Troshynski (dtroshynski@acmepacket.com)

Any other information the author deems interesting:

Implementers should review a non-exclusive list of examples below in
Section 7.

4.3. Registration for "voicemsg" with Subtype "tel" 📱

Enumservice Name: "voicemsg"

Enumservice Type: "voicemsg"

Enumservice Subtype: "tel"

URI Schemes: 'tel:'
Functional Specification:

This Enumservice indicates that the remote resource identified can be
addressed by the associated URI scheme in order to initiate a voice
communication session to a voice messaging system.

Security Considerations: See Section 3.

Intended Usage: COMMON

Authors:

Jason Livingood (jason_livingood@cable.comcast.com)
Don Troshynski (dtroshynski@acmepacket.com)

Any other information the author deems interesting:

Implementers should review a non-exclusive list of examples below in
Section 7.

4.4. Registration for "voicemsg" with Subtype "http" 🌐

Enumservice Name: "voicemsg"

Enumservice Type: "voicemsg"

Enumservice Subtype: "http"

URI Schemes: 'http:'

Functional Specification:

This Enumservice indicates that the remote resource identified by the
associated URI scheme is capable of being a source of information.

Note that the kind of information retrieved can be manifold. Usually,
contacting a resource by an 'http:' [11] URI provides a document.
This document can contain references that will trigger the download
of many different kinds of information, such as text, audio, video,
executable code, or even voice message files.  Thus, one cannot be
more specific about the kind of information expected when contacting
the resource.

Security Considerations: See Section 3.

Intended Usage: COMMON
Authors:

Jason Livingood (jason_livingood@cable.comcast.com)
Don Troshynski (dtroshynski@acmepacket.com)

Any other information the author deems interesting:

Implementers should review a non-exclusive list of examples below in
Section 7.

4.5. Registration for "voicemsg" with Subtype "https" 🔐

Enumservice Name: "voicemsg"

Enumservice Type: "voicemsg"

Enumservice Subtype: "https"

URI Schemes: 'https:'

Functional Specification:

This Enumservice indicates that the remote resource identified by the
associated URI scheme is capable of being a source of information,
which can be contacted using TLS or the Secure Socket Layer protocol.

Note that the kind of information retrieved can be manifold. Usually,
contacting a resource by an 'https:' [12] URI provides a document.
This document can contain references that will trigger the download
of many different kinds of information, such as text, audio, video,
executable code, or even voice message files.  Thus, one cannot be
more specific about the kind of information expected when contacting
the resource.

Security Considerations: See Section 3.

Intended Usage: COMMON

Authors:

Jason Livingood (jason_livingood@cable.comcast.com)
Don Troshynski (dtroshynski@acmepacket.com)

Any other information the author deems interesting:

Implementers should review a non-exclusive list of examples below in
Section 7.

5. ENUM Service Registration for videomsg 📹

same energy as voicemsg, just with video vibes 🎥✨ the templates below keep every field exact.

5.1. Registration for "videomsg" with Subtype "sip" 📞

Enumservice Name: "videomsg"

Enumservice Type: "videomsg"

Enumservice Subtypes: "sip"

URI Schemes: 'sip:'

Functional Specification:

This Enumservice indicates that the remote resource identified can be
addressed by the associated URI scheme in order to initiate a video
communication session to a video messaging system.

Security Considerations: See Section 3.

Intended Usage: COMMON

Authors:

Jason Livingood (jason_livingood@cable.comcast.com)
Don Troshynski (dtroshynski@acmepacket.com)

Any other information the author deems interesting:

Implementers should review a non-exclusive list of examples below in
Section 7.

5.2. Registration for "videomsg" with Subtype "sips" 🔒

Enumservice Name: "videomsg"

Enumservice Type: "videomsg"

Enumservice Subtypes: "sips"

URI Schemes: 'sips:'

Functional Specification:

This Enumservice indicates that the remote resource identified can be
addressed by the associated URI scheme in order to initiate a video
communication session to a video messaging system.

Security Considerations: See Section 3.

Intended Usage: COMMON

Authors:

Jason Livingood (jason_livingood@cable.comcast.com)
Don Troshynski (dtroshynski@acmepacket.com)

Any other information the author deems interesting:

Implementers should review a non-exclusive list of examples below in
Section 7.

5.3. Registration for "videomsg" with Subtype "http" 🌐

Enumservice Name: "videomsg"

Enumservice Type: "videomsg"

Enumservice Subtype: "http"

URI Schemes: 'http:'

Functional Specification:

This Enumservice indicates that the remote resource identified by the
associated URI scheme is capable of being a source of information.

Note that the kind of information retrieved can be manifold. Usually,
contacting a resource by an 'http:' [11] URI provides a document.
This document can contain references that will trigger the download
of many different kinds of information, such as text, audio, video,
executable code, or even video message files.  Thus, one cannot be
more specific about the kind of information expected when contacting
the resource.

Security Considerations: See Section 3.

Intended Usage: COMMON

Authors:

Jason Livingood (jason_livingood@cable.comcast.com)
Don Troshynski (dtroshynski@acmepacket.com)
Any other information the author deems interesting:

Implementers should review a non-exclusive list of examples below in
Section 7.

5.4. Registration for "videomsg" with Subtype "https" 🔐

Enumservice Name: "videomsg"

Enumservice Type: "videomsg"

Enumservice Subtype: "https"

URI Schemes: 'https:'

Functional Specification:

This Enumservice indicates that the remote resource identified by the
associated URI scheme is capable of being a source of information,
which can be contacted using TLS or the Secure Socket Layer protocol.

Note that the kind of information retrieved can be manifold. Usually,
contacting a resource by an 'https:' [12] URI provides a document.
This document can contain references that will trigger the download
of many different kinds of information, such as text, audio, video,
executable code, or even video message files.  Thus, one cannot be
more specific about the kind of information expected when contacting
the resource.

Security Considerations: See Section 3.

Intended Usage: COMMON

Authors:

Jason Livingood (jason_livingood@cable.comcast.com)
Don Troshynski (dtroshynski@acmepacket.com)

Any other information the author deems interesting:

Implementers should review a non-exclusive list of examples below in
Section 7.

6. ENUM Service Registration for unifmsg 💌

last stretch of this part, and it's the unified messaging crew 🫶 same deal, exact fields, no cap.

6.1. Registration for "unifmsg" with Subtype "sip" 📞

Enumservice Name: "unifmsg"

Enumservice Type: "unifmsg"

Enumservice Subtypes: "sip"

URI Schemes: 'sip:'

Functional Specification:

This Enumservice indicates that the remote resource identified can be
addressed by the associated URI scheme in order to initiate a unified
communication session to a unified messaging system.

Security Considerations: See Section 3.

Intended Usage: COMMON

Authors:

Jason Livingood (jason_livingood@cable.comcast.com)
Don Troshynski (dtroshynski@acmepacket.com)

Any other information the author deems interesting:

Implementers should review a non-exclusive list of examples below in
Section 7.

6.2. Registration for "unifmsg" with Subtype "sips" 🔒

Enumservice Name: "unifmsg"

Enumservice Type: "unifmsg"

Enumservice Subtypes: "sips"

URI Schemes: 'sips:'

Functional Specification:

This Enumservice indicates that the remote resource identified can be
addressed by the associated URI scheme in order to initiate a unified
communication session to a unified messaging system.

Security Considerations: See Section 3.

Intended Usage: COMMON

Authors:

Jason Livingood (jason_livingood@cable.comcast.com)
Don Troshynski (dtroshynski@acmepacket.com)

Any other information the author deems interesting:

Implementers should review a non-exclusive list of examples below in
Section 7.

6.3. Registration for "unifmsg" with Subtype "http" ✨

  • Enumservice Name: "unifmsg"
  • Enumservice Type: "unifmsg"
  • Enumservice Subtype: "http"
  • URI Schemes: 'http:'
  • Functional Specification:

okay so this Enumservice is saying the remote resource behind the 'http:' URI scheme is able to be a source of information 📚 It's giving "I have stuff for you" energy.

ngl the kind of info you get back can be all over the place 🌈 Usually, poking a resource with an 'http:' [11] URI gets you a document. That document can have links that kick off downloads of all sorts of things: text, audio, video, executable code, or even video message files 🎬 So you literally cannot be super specific about what kind of info to expect when you contact the resource 💅

  • Security Considerations: See Section 3.
  • Intended Usage: COMMON
  • Authors:
    • Jason Livingood (jason_livingood@cable.comcast.com)
    • Don Troshynski (dtroshynski@acmepacket.com)
  • Any other information the author deems interesting:

Implementers should review a non-exclusive list of examples below in Section 7. Bestie, go look 👀🫶

6.4. Registration for "unifmsg" with Subtype "https" 🔒

  • Enumservice Name: "unifmsg"
  • Enumservice Type: "unifmsg"
  • Enumservice Subtype: "https"
  • URI Schemes: 'https:'
  • Functional Specification:

this one is basically the same vibe as the 'http:' one, but it's the secure sibling 🔐 The remote resource behind the 'https:' URI scheme is able to be a source of information, and you can contact it using TLS or the Secure Socket Layer protocol 🧚

Same deal with the info being all over the place. Usually, contacting a resource by an 'https:' [12] URI gives you a document, and that document can have references that trigger the download of many different kinds of information, like text, audio, video, executable code, or even video message files 🎞️ Thus, one cannot be more specific about the kind of information expected when contacting the resource. It's a whole mystery box 📦✨

  • Security Considerations: See Section 3.
  • Intended Usage: COMMON
  • Authors:
    • Jason Livingood (jason_livingood@cable.comcast.com)
    • Don Troshynski (dtroshynski@acmepacket.com)
  • Any other information the author deems interesting:

Implementers should review a non-exclusive list of examples below in Section 7. 🌸

7. Selected Examples for Illustrative Purposes 🧚

the following sub-sections document several examples that implementers may find informative 💖 These examples shall in no way limit the various forms that this Enumservice may take. The sky's the limit, babe ☁️

7.1. Example Using a 'sip' URI 📞

$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
   NAPTR 10 100 "u" "E2U+voicemsg:sip"
   "!^.*$!sip:12155550123@gw.example.com!".

okay so in this example, a calling party tried a session and it just... went unanswered for a while 😭 The calling party's session gets sent to the right voice messaging server, a personalized greeting plays for them, and then they record a voice message for the called party 🎀

7.2. Example Using a 'tel' URI ☎️

$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
   NAPTR 10 100 "u" "E2U+voicemsg:tel"
   "!^.*$!tel:1-215-555-0123!".

this one is giving the same story 💅 A calling party has a session that goes unanswered after a certain period of time. It gets routed to the appropriate voice messaging server, the calling party hears a personalized greeting, and then they leave a voice message for the called party 📨

7.3. Example Using a Backreference 🔁

$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
   NAPTR 10 100 "u" "E2U+voicemsg:sip"
   "!(^.*)$!sip:\1@example.net!".

ooh this one is so clever 🧠 A backreference is used to shrink the size of the NAPTR record. The sip URI uses "\1", which dynamically swaps in the TN, which in this case is +12155550123. Smart and efficient, iconic behavior 👑

7.4. Example Using a 'sip' URI without a Telephone Number 🌟

$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
   NAPTR 10 100 "u" "E2U+voicemsg:sip"
   "!^.*$!sip:johndoe@gw.example.com!".

so in this example, a calling party tries a session, it goes unanswered for a while, and the session goes to the voice messaging server. A personalized greeting plays, and then the caller records a voice message for the called party 🎙️ Here's the twist: the URI doesn't include a telephone number at all, because this user has multiple services that aren't really tied to phone numbers. Text, audio, video, and other multimedia messages can all be received and accessed that way. Main character energy 🦋

7.5. Example of Failover Using E2U+videomsg:sip 🔄

$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
   NAPTR 10 100 "u" "E2U+videomsg:sip"
   "!^.*$!sip:12155550123@gw1.example.com!".

$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
   NAPTR 10 200 "u" "E2U+videomsg:sip"
   "!^.*$!sip:12155550123@gw2.example.com!".

in this one, the preference tells you that gw1.example.com gets used first (100). If it's unreachable, the next higher preference (200) kicks in and gw2.example.com gets contacted 🫶 Failover, but make it cute. Out of scope for this document, sure, but a service provider could mirror or cluster a message store and fail from primary to secondary using the DNS in an active-standby mode. That's the kind of planning I'm obsessed with 😍

8. Implementation Recommendations 🛠️

8.1. Call Processing When Multiple Records Are Returned 📋

it's likely that both E2U+sip and E2U+voicemsg, E2U+videomsg, and/or E2U+unifmsg Enumservice type records will get returned for a given query 👀 So this could basically give you E2U+sip records for real-time communication with an end user, while the E2U+voicemsg records get used for real-time communication with a voice messaging service, when the called party isn't available or doesn't want to be disturbed 🤫 That means the network element that receives the results of this ENUM query needs to know enough to pick the voicemsg service type instead of the sip service type. Very important, very dramatic 💀

Also, it's likely that multiple E2U+voicemsg, E2U+videomsg, and/or E2U+unifmsg Enumservice type records will come back for one query 🧃 In that case, the records may include order and preference to allow recursion or load balancing. Order could be used to designate a primary and a backup voice, video, or unified voice and video messaging service. Preference could be used to load balance across multiple voice, video, and/or unified voice and video messaging servers by weight, for example ⚖️

Finally, just like with multiple records from a typical ENUM query of the e164.arpa tree, it's up to the application using an ENUM resolver to decide which record(s) to use and which to ignore 🙃 Implementers should take this into consideration and build logic into their applications that can select appropriately from multiple records based on business, network, or other rules. Choose wisely, queen 👑

8.2. NAPTR Configuration Issues 🧩

Implementers may wish to consider using regular expressions in order to reduce the size of individual NAPTRs. This will have a significant effect on the overall size of the database involved. Tiny regex, big database savings 🤏✨

9. IANA Considerations 📝

This document registers the 'voicemsg' Enumservice type and the subtype "tel", "sip", "sips", "http", and "https" under the Enumservice registry described in the IANA considerations in RFC 3761. Details of this registration are provided in Section 4 of this document 🦋

This document registers the 'videomsg' Enumservice type and the subtype "sip", "sips", "http", and "https" under the Enumservice registry described in the IANA considerations in RFC 3761. Details of this registration are provided in Section 5 of this document 🎬

This document registers the 'unifmsg' Enumservice type and the subtype "sip", "sips", "http", and "https" under the Enumservice registry described in the IANA considerations in RFC 3761. Details of this registration are provided in Section 6 of this document 🌈

10. Acknowledgements 🫶

The authors thank Rich Ferrise, Chris Harvey, Tong Zhou, and Hadriel Kaplan for their detailed assistance in developing the ideas behind this document in numerous brainstorming sessions, with information gleaned from their work to solve real application architecture issues. The authors also thank Lawrence Conroy and Jean-Francois Mule for their feedback in developing this document. Brainstorm squad, you're everything 💖

11. Contributors 🌸

Tong Zhou
Comcast Cable Communications
Email: tong_zhou@cable.comcast.com

Richard Ferrise
Comcast Cable Communications
Email: rich_ferrise@cable.comcast.com

Chris Harvey
Comcast Cable Communications
Email: chris_harvey@cable.comcast.com

Hadriel Kaplan
Acme Packet
Email: hkaplan@acmepacket.com

12. References 📚

12.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] ITU-T, "The International Public Telecommunication Numbering Plan", Recommendation E.164, May 1997.
  • [3] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
  • [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
  • [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 Two: The Algorithm", RFC 3402, October 2002.
  • [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002.
  • [8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", BCP 65, RFC 3405, October 2002.
  • [9] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
  • [10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
  • [11] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
  • [12] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

12.2. Informative References

  • [13] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using E.164 numbers with the Session Initiation Protocol (SIP)", RFC 3824, June 2004.
  • [14] Vaudreuil, G., "Voice Message Routing Service", RFC 4238, October 2005.
  • [15] Brandner, R., Conroy, L., and R. Stastny, "IANA Registration for Enumservices email, fax, mms, ems, and sms", RFC 4355, January 2006.
  • [16] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
  • [17] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
  • [18] Foster, M., McGarry, T., and J. Yu, "Number Portability in the Global Switched Telephone Network (GSTN): An Overview", RFC 3482, February 2003.
  • [19] Peterson, J., "enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004.

Authors' Addresses ✨

okay, meet the two authors who made this whole doc happen 🫶

Jason Livingood is with Comcast Cable Communications 🎀

Jason Livingood
Comcast Cable Communications
One Comcast Center
1701 John F. Kennedy Boulevard
Philadelphia, PA 19103
USA
EMail: jason_livingood@cable.comcast.com

and Donald Troshynski is with Acme Packet 💜

Donald Troshynski
Acme Packet
EMail: dtroshynski@acmepacket.com

Copyright (C) The IETF Trust (2008). 💖

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. So the authors still own their stuff, obviously 💅

Okay, the legal disclaimer, but make it bubbly 😭 This document and the information in it are provided on an "AS IS" basis. The contributor, the organization they represent or are sponsored by (if any), the Internet Society, the IETF Trust, and the Internet Engineering Task Force all disclaim every warranty, express or implied. That includes any warranty that using the information here won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose. No guarantees, bestie 🙈

Intellectual Property 🦋

The IETF takes no position on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or in scope. It also doesn't say whether any license for those rights is or isn't available. And it doesn't claim to have independently searched for any such rights 🔍 If you want the procedures for rights in RFC documents, check out BCP 78 and BCP 79. Those are the real source of truth ✨

Copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses to be made available, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr. You can also find the result of any attempt to get a general license or permission to use those proprietary rights, for implementers or users of this specification 🧚

The IETF invites any interested party to tell it about any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💜 Spill the tea, it helps everyone 🍓

📦 where this page comes from