5278
PROPOSED STANDARD
IANA Registration of Enumservices for Voice and Video Messaging
Authors: J. Livingood, D. Troshynski
Date: July 2008
Area: rai
Working Group: enum
Stream: IETF
Updated by:
RFC 6118
Abstract
This document registers the Enumservice named "vmsg", which is used to facilitate the real-time routing of voice, video, and unified communications to a messaging system. This vmsg Enumservice registers three Enumservice types: "voicemsg", "videomsg", and "unifmsg". Each type also registers the subtypes "sip", "sips", "http", and "https", as well as the subtype "tel" for the "voicemsg" type. [STANDARDS-TRACK]
RFC 5278
PROPOSED STANDARD
Updated by: 6118
Network Working Group J. Livingood
Request for Comments: 5278 Comcast Cable Communications
Category: Standards Track D. Troshynski
Acme Packet
July 2008
<span class="h1">IANA Registration of Enumservices for Voice and Video Messaging</span>
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.
Abstract
This document registers the Enumservice named "vmsg", which is used
to facilitate the real-time routing of voice, video, and unified
communications to a messaging system. This vmsg Enumservice
registers three Enumservice types: "voicemsg", "videomsg", and
"unifmsg". Each type also registers the subtypes "sip", "sips",
"http", and "https", as well as the subtype "tel" for the "voicemsg"
type.
<span class="grey">Livingood & Troshynski Standards Track [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc5278">RFC 5278</a> VMSG Enumservice July 2008</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Selected Use Cases for Illustrative Purposes ...............<a href="#page-4">4</a>
<a href="#section-1.2">1.2</a>. Consideration of Other Existing Enumservices ...............<a href="#page-5">5</a>
<a href="#section-2">2</a>. Distribution of Data ............................................<a href="#page-5">5</a>
<a href="#section-3">3</a>. Security Considerations .........................................<a href="#page-5">5</a>
<a href="#section-4">4</a>. ENUM Service Registration for voicemsg ..........................<a href="#page-6">6</a>
<a href="#section-4.1">4.1</a>. Registration for "voicemsg" with Subtype "sip" .............<a href="#page-6">6</a>
<a href="#section-4.2">4.2</a>. Registration for "voicemsg" with Subtype "sips" ............<a href="#page-7">7</a>
<a href="#section-4.3">4.3</a>. Registration for "voicemsg" with Subtype "tel" .............<a href="#page-7">7</a>
<a href="#section-4.4">4.4</a>. Registration for "voicemsg" with Subtype "http" ............<a href="#page-8">8</a>
<a href="#section-4.5">4.5</a>. Registration for "voicemsg" with Subtype "https" ...........<a href="#page-9">9</a>
<a href="#section-5">5</a>. ENUM Service Registration for videomsg .........................<a href="#page-10">10</a>
<a href="#section-5.1">5.1</a>. Registration for "videomsg" with Subtype "sip" ............<a href="#page-10">10</a>
<a href="#section-5.2">5.2</a>. Registration for "videomsg" with Subtype "sips" ...........<a href="#page-10">10</a>
<a href="#section-5.3">5.3</a>. Registration for "videomsg" with Subtype "http" ...........<a href="#page-11">11</a>
<a href="#section-5.4">5.4</a>. Registration for "videomsg" with Subtype "https" ..........<a href="#page-12">12</a>
<a href="#section-6">6</a>. ENUM Service Registration for unifmsg ..........................<a href="#page-13">13</a>
<a href="#section-6.1">6.1</a>. Registration for "unifmsg" with Subtype "sip" .............<a href="#page-13">13</a>
<a href="#section-6.2">6.2</a>. Registration for "unifmsg" with Subtype "sips" ............<a href="#page-13">13</a>
<a href="#section-6.3">6.3</a>. Registration for "unifmsg" with Subtype "http" ............<a href="#page-14">14</a>
<a href="#section-6.4">6.4</a>. Registration for "unifmsg" with Subtype "https" ...........<a href="#page-15">15</a>
<a href="#section-7">7</a>. Selected Examples for Illustrative Purposes ....................<a href="#page-16">16</a>
<a href="#section-7.1">7.1</a>. Example Using a 'sip' URI .................................<a href="#page-16">16</a>
<a href="#section-7.2">7.2</a>. Example Using a 'tel' URI .................................<a href="#page-16">16</a>
<a href="#section-7.3">7.3</a>. Example Using a Backreference .............................<a href="#page-16">16</a>
<a href="#section-7.4">7.4</a>. Example Using a 'sip' URI without a Telephone Number ......<a href="#page-17">17</a>
<a href="#section-7.5">7.5</a>. Example of Failover Using E2U+videomsg:sip ................<a href="#page-17">17</a>
<a href="#section-8">8</a>. Implementation Recommendations .................................<a href="#page-17">17</a>
<a href="#section-8.1">8.1</a>. Call Processing When Multiple Records Are Returned ........<a href="#page-17">17</a>
<a href="#section-8.2">8.2</a>. NAPTR Configuration Issues ................................<a href="#page-18">18</a>
<a href="#section-9">9</a>. IANA Considerations ............................................<a href="#page-18">18</a>
<a href="#section-10">10</a>. Acknowledgements ..............................................<a href="#page-18">18</a>
<a href="#section-11">11</a>. Contributors ..................................................<a href="#page-19">19</a>
<a href="#section-12">12</a>. References ....................................................<a href="#page-19">19</a>
<a href="#section-12.1">12.1</a>. Normative References .....................................<a href="#page-19">19</a>
<a href="#section-12.2">12.2</a>. Informative References ...................................<a href="#page-20">20</a>
<span class="grey">Livingood & Troshynski Standards Track [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc5278">RFC 5278</a> VMSG Enumservice July 2008</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
ENUM (E.164 Number Mapping, <a href="./rfc3761">RFC 3761</a> [<a href="#ref-1" title=""The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)"">1</a>]) is a technology that
transforms E.164 numbers (the International Public Telecommunication
Numbering Plan, ITU-T Recommendation E.164 [<a href="#ref-2" title=""The International Public Telecommunication Numbering Plan"">2</a>]) into domain names and
then uses DNS (Domain Name System, <a href="./rfc1034">RFC 1034</a> [<a href="#ref-3" title=""Domain names - concepts and facilities"">3</a>]) delegation through
NS records and Naming Authority Pointer (NAPTR) records (Dynamic
Delegation Discovery System (DDDS) Part Three: The Domain Name System
(DNS) Database, <a href="./rfc3403">RFC 3403</a> [<a href="#ref-4" title=""Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database"">4</a>]) to look up what services are available
for a specific domain name.
This document registers Enumservices according to the guidelines
given in <a href="./rfc3761">RFC 3761</a> [<a href="#ref-1" title=""The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)"">1</a>] to be used for provisioning in the services
field of a NAPTR [<a href="#ref-4" title=""Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database"">4</a>] resource record to indicate the types of
functionality associated with an end point and/or telephone number.
The registration is defined within the DDDS (Dynamic Delegation
Discovery System [<a href="#ref-4" title=""Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database"">4</a>][5][<a href="#ref-6" title=""Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm"">6</a>][7][<a href="#ref-8" title=""Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures"">8</a>]) hierarchy, for use with the "E2U"
DDDS Application defined in <a href="./rfc3761">RFC 3761</a>.
Voice messaging systems are used widely with telephony and voice
communication services. The need for a voice messaging service type
has become clear in order to provide certain applications with direct
access to various voice messaging services (for example, voicemail),
most typically via the use of SIP.
The authors considered the use of Voice Profile for Internet Mail
(VPIM) [<a href="#ref-14" title=""Voice Message Routing Service"">14</a>] but found that VPIM was best suited to the non-real-time
and non-session-based routing of a voice message once it had been
deposited into a voice messaging system. Thus, VPIM was a good
solution for the non-real-time and non-session-based routing of voice
messages between and within domains, but it did not enable real-time
interaction with a voice messaging system.
Thus, a need has been identified for this voice messaging service
type that would enable, for example, some of the use cases listed in
this section.
Video messaging systems, sometimes called visual voice messaging
systems, are beginning to be used with real-time communication
services. The need for a video messaging service type has become
clear in order to provide certain applications with direct access to
various video messaging services, most typically via the use of SIP.
Thus, a need has been identified for this video messaging service
type that would enable, for example, some of the use cases listed in
this section.
<span class="grey">Livingood & Troshynski Standards Track [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc5278">RFC 5278</a> VMSG Enumservice July 2008</span>
Finally, several service providers and software developers have
indicated that their system for voice messaging and video messaging
either have been or soon will be unified into a single system. As
such, they desired to have the option of using an Enumservice type
that represents a subscriber's mailbox as being a so-called unified
messaging repository. Thus, a need has been identified for this
unified voice and video messaging service type that would enable, for
example, some of the use cases listed in this section.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Selected Use Cases for Illustrative Purposes</span>
The following is a partial, non-exclusive list of use cases that the
vmsg Enumservice could address:
* A called party is busy or does not answer a call. A client or
server then determines that a messaging service should be used and
sends the calling party's session to such a service. The client or
server needs to be able to determine which server to direct this
real-time session to, whether that is within or outside of the
called party's domain.
* Similar to the above use case, a real-time session is attempted to
a messaging system, but that system is currently unavailable.
Since multiple service type records may be returned by the original
ENUM query, the client or server could then attempt to initiate a
session with one or more backup messaging servers in a manner that
is transparent to the calling party and that supports better
overall availability of a messaging service.
* Similar to the above use case, this service type could be used to
balance load across multiple messaging servers, whether those are
in the same or in different physical locations.
* A user with an account on a messaging service needs to connect to
the messaging service in order to retrieve messages. They initiate
a real-time session, and an ENUM query is performed to discover the
messaging server that holds its mailbox.
* In the process of invoking and supporting a real-time, automated
and interactive session with a user, whether for message deposit or
retrieval, VoiceXML files are referenced and utilized, via either
HTTP or HTTPS. Multiple VoiceXML servers could be associated with
a user and returned via ENUM query, for the purposes of load
balancing, for example.
<span class="grey">Livingood & Troshynski Standards Track [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc5278">RFC 5278</a> VMSG Enumservice July 2008</span>
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Consideration of Other Existing Enumservices</span>
The authors considered whether this service type could simply use the
SIP Enumservice type [<a href="#ref-19" title=""enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record"">19</a>], but found that it does not satisfy their
voice messaging requirements, particularly given the non-SIP URI sub-
types specified herein. Even with sub-types for SIP URIs, however,
there are challenges to using the SIP Enumservice type. For example,
a request for access to such a service could be extended to the
requesting SIP client, or User Agent Client (UAC), rather than
relying upon the local policy of a SIP server, or User Agent Server
(UAS), which means that special routing logic within a UAS cannot be
relied upon to solve this problem. More importantly, however, the
authors have found that without this service type, a UAC or UAS will
be presented with multiple SIP URIs, with no ability other than in
non-standards-based routing rules or application logic to recognize
which one is related to a voice messaging, video messaging, or
unified voice and video messaging service.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Distribution of Data</span>
The authors believe that it is more likely that these records will be
distributed on a purely private basis, but they may also be
distributed in public ENUM trees. Distribution of this NAPTR data
could be either (a) on a private basis within a service provider's
internal network, (b) on a private basis between one or more parties
using a variety of security mechanisms to prohibit general public
access, or (c) openly available.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Security Considerations</span>
DNS, as used by ENUM, is a global, distributed database. Should
implementers of this specification use e164.arpa or any other
publicly available domain as the tree for maintaining voicemsg
Enumservice data, this information would be visible to anyone
anonymously. While this is not qualitatively different from
publication in a Telephone Directory, it does open or ease access to
such data without any indication that such data has been accessed or
by whom it has been accessed.
Such data harvesting by third parties is often used to generate lists
of targets for unsolicited information. Thus, a third party could
use this to generate a list that it can use to make unsolicited
telemarketing phone calls, or so-called SPAM over Internet Telephony
(SPIT). Many countries have do-not-call registries or other legal or
regulatory mechanisms in place to deal with such abuses.
<span class="grey">Livingood & Troshynski Standards Track [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc5278">RFC 5278</a> VMSG Enumservice July 2008</span>
As noted earlier, carriers, service providers, and other users may
simply choose not to publish such information in the public e164.arpa
tree, but may instead simply publish this in their internal ENUM
routing database that is only able to be queried by trusted elements
of their network and/or partner networks, such as softswitches and
SIP proxy servers. They may also choose to publish such information
in a carrier-only branch of the e164.arpa tree, should one be
created.
Although an E.164 telephone number does not appear to reveal as much
identity information about a user as a name in the format
sip:username@hostname or email:username@hostname, the information is
still publicly available; thus, there is still the risk of unwanted
communication.
An analysis of threats specific to the dependence of ENUM on the DNS
and the applicability of DNSSEC [<a href="#ref-16" title=""Protocol Modifications for the DNS Security Extensions"">16</a>] to this is provided in <a href="./rfc3761">RFC 3761</a>
[<a href="#ref-1" title=""The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)"">1</a>]. A thorough analysis of threats to the DNS itself is covered in
<a href="./rfc3833">RFC 3833</a> [<a href="#ref-17" title=""Threat Analysis of the Domain Name System (DNS)"">17</a>].
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. ENUM Service Registration for voicemsg</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Registration for "voicemsg" with Subtype "sip"</span>
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 <a href="#section-3">Section 3</a>.
Intended Usage: COMMON
Authors:
Jason Livingood ([email protected])
Don Troshynski ([email protected])
<span class="grey">Livingood & Troshynski Standards Track [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc5278">RFC 5278</a> VMSG Enumservice July 2008</span>
Any other information the author deems interesting:
Implementers should review a non-exclusive list of examples below in
<a href="#section-7">Section 7</a>.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Registration for "voicemsg" with Subtype "sips"</span>
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 <a href="#section-3">Section 3</a>.
Intended Usage: COMMON
Authors:
Jason Livingood ([email protected])
Don Troshynski ([email protected])
Any other information the author deems interesting:
Implementers should review a non-exclusive list of examples below in
<a href="#section-7">Section 7</a>.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Registration for "voicemsg" with Subtype "tel"</span>
Enumservice Name: "voicemsg"
Enumservice Type: "voicemsg"
Enumservice Subtype: "tel"
URI Schemes: 'tel:'
<span class="grey">Livingood & Troshynski Standards Track [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc5278">RFC 5278</a> VMSG Enumservice July 2008</span>
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 <a href="#section-3">Section 3</a>.
Intended Usage: COMMON
Authors:
Jason Livingood ([email protected])
Don Troshynski ([email protected])
Any other information the author deems interesting:
Implementers should review a non-exclusive list of examples below in
<a href="#section-7">Section 7</a>.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Registration for "voicemsg" with Subtype "http"</span>
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:' [<a href="#ref-11" title=""Hypertext Transfer Protocol -- HTTP/1.1"">11</a>] 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 <a href="#section-3">Section 3</a>.
Intended Usage: COMMON
<span class="grey">Livingood & Troshynski Standards Track [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc5278">RFC 5278</a> VMSG Enumservice July 2008</span>
Authors:
Jason Livingood ([email protected])
Don Troshynski ([email protected])
Any other information the author deems interesting:
Implementers should review a non-exclusive list of examples below in
<a href="#section-7">Section 7</a>.
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. Registration for "voicemsg" with Subtype "https"</span>
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:' [<a href="#ref-12" title=""HTTP Over TLS"">12</a>] 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 <a href="#section-3">Section 3</a>.
Intended Usage: COMMON
Authors:
Jason Livingood ([email protected])
Don Troshynski ([email protected])
Any other information the author deems interesting:
Implementers should review a non-exclusive list of examples below in
<a href="#section-7">Section 7</a>.
<span class="grey">Livingood & Troshynski Standards Track [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc5278">RFC 5278</a> VMSG Enumservice July 2008</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. ENUM Service Registration for videomsg</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Registration for "videomsg" with Subtype "sip"</span>
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 <a href="#section-3">Section 3</a>.
Intended Usage: COMMON
Authors:
Jason Livingood ([email protected])
Don Troshynski ([email protected])
Any other information the author deems interesting:
Implementers should review a non-exclusive list of examples below in
<a href="#section-7">Section 7</a>.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Registration for "videomsg" with Subtype "sips"</span>
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.
<span class="grey">Livingood & Troshynski Standards Track [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc5278">RFC 5278</a> VMSG Enumservice July 2008</span>
Security Considerations: See <a href="#section-3">Section 3</a>.
Intended Usage: COMMON
Authors:
Jason Livingood ([email protected])
Don Troshynski ([email protected])
Any other information the author deems interesting:
Implementers should review a non-exclusive list of examples below in
<a href="#section-7">Section 7</a>.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Registration for "videomsg" with Subtype "http"</span>
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:' [<a href="#ref-11" title=""Hypertext Transfer Protocol -- HTTP/1.1"">11</a>] 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 <a href="#section-3">Section 3</a>.
Intended Usage: COMMON
Authors:
Jason Livingood ([email protected])
Don Troshynski ([email protected])
<span class="grey">Livingood & Troshynski Standards Track [Page 11]</span><span id="page-12" ></span>
<span class="grey"><a href="./rfc5278">RFC 5278</a> VMSG Enumservice July 2008</span>
Any other information the author deems interesting:
Implementers should review a non-exclusive list of examples below in
<a href="#section-7">Section 7</a>.
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. Registration for "videomsg" with Subtype "https"</span>
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:' [<a href="#ref-12" title=""HTTP Over TLS"">12</a>] 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 <a href="#section-3">Section 3</a>.
Intended Usage: COMMON
Authors:
Jason Livingood ([email protected])
Don Troshynski ([email protected])
Any other information the author deems interesting:
Implementers should review a non-exclusive list of examples below in
<a href="#section-7">Section 7</a>.
<span class="grey">Livingood & Troshynski Standards Track [Page 12]</span><span id="page-13" ></span>
<span class="grey"><a href="./rfc5278">RFC 5278</a> VMSG Enumservice July 2008</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. ENUM Service Registration for unifmsg</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Registration for "unifmsg" with Subtype "sip"</span>
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 <a href="#section-3">Section 3</a>.
Intended Usage: COMMON
Authors:
Jason Livingood ([email protected])
Don Troshynski ([email protected])
Any other information the author deems interesting:
Implementers should review a non-exclusive list of examples below in
<a href="#section-7">Section 7</a>.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Registration for "unifmsg" with Subtype "sips"</span>
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.
<span class="grey">Livingood & Troshynski Standards Track [Page 13]</span><span id="page-14" ></span>
<span class="grey"><a href="./rfc5278">RFC 5278</a> VMSG Enumservice July 2008</span>
Security Considerations: See <a href="#section-3">Section 3</a>.
Intended Usage: COMMON
Authors:
Jason Livingood ([email protected])
Don Troshynski ([email protected])
Any other information the author deems interesting:
Implementers should review a non-exclusive list of examples below in
<a href="#section-7">Section 7</a>.
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Registration for "unifmsg" with Subtype "http"</span>
Enumservice Name: "unifmsg"
Enumservice Type: "unifmsg"
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:' [<a href="#ref-11" title=""Hypertext Transfer Protocol -- HTTP/1.1"">11</a>] 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 <a href="#section-3">Section 3</a>.
Intended Usage: COMMON
Authors:
Jason Livingood ([email protected])
Don Troshynski ([email protected])
<span class="grey">Livingood & Troshynski Standards Track [Page 14]</span><span id="page-15" ></span>
<span class="grey"><a href="./rfc5278">RFC 5278</a> VMSG Enumservice July 2008</span>
Any other information the author deems interesting:
Implementers should review a non-exclusive list of examples below in
<a href="#section-7">Section 7</a>.
<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>. Registration for "unifmsg" with Subtype "https"</span>
Enumservice Name: "unifmsg"
Enumservice Type: "unifmsg"
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:' [<a href="#ref-12" title=""HTTP Over TLS"">12</a>] 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 <a href="#section-3">Section 3</a>.
Intended Usage: COMMON
Authors:
Jason Livingood ([email protected])
Don Troshynski ([email protected])
Any other information the author deems interesting:
Implementers should review a non-exclusive list of examples below in
<a href="#section-7">Section 7</a>.
<span class="grey">Livingood & Troshynski Standards Track [Page 15]</span><span id="page-16" ></span>
<span class="grey"><a href="./rfc5278">RFC 5278</a> VMSG Enumservice July 2008</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Selected Examples for Illustrative Purposes</span>
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.
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Example Using a 'sip' URI</span>
$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
NAPTR 10 100 "u" "E2U+voicemsg:sip"
"!^.*$!sip:[email protected]!".
In this example, a calling party has attempted a session that has
gone unanswered after a certain period of time. The calling party's
session is sent to the appropriate voice messaging server, a
personalized greeting is played to the calling party, after which it
records a voice message to the called party.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Example Using a 'tel' URI</span>
$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!".
In this example, a calling party has attempted a session that has
gone unanswered after a certain period of time. The calling party's
session is sent to the appropriate voice messaging server, a
personalized greeting is played to the calling party, after which it
records a voice message to the called party.
<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>. Example Using a Backreference</span>
$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
NAPTR 10 100 "u" "E2U+voicemsg:sip"
"!(^.*)$!sip:\[email protected]!".
In this example, a backreference is used to reduce the size of the
NAPTR record. The sip URI uses "\1", which would dynamically replace
the expression with the TN, in this case +12155550123.
<span class="grey">Livingood & Troshynski Standards Track [Page 16]</span><span id="page-17" ></span>
<span class="grey"><a href="./rfc5278">RFC 5278</a> VMSG Enumservice July 2008</span>
<span class="h3"><a class="selflink" id="section-7.4" href="#section-7.4">7.4</a>. Example Using a 'sip' URI without a Telephone Number</span>
$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
NAPTR 10 100 "u" "E2U+voicemsg:sip"
"!^.*$!sip:[email protected]!".
In this example, a calling party has attempted a session that has
gone unanswered after a certain period of time. The calling party's
session is sent to the appropriate voice messaging server, a
personalized greeting is played to the calling party, after which it
records a voice message to the called party. The URI that this
session is directed to does not include a telephone number, as this
user has multiple service that are not particularly tied to telephone
numbers whereby text, audio, video and other multimedia messages can
be received and accessed.
<span class="h3"><a class="selflink" id="section-7.5" href="#section-7.5">7.5</a>. Example of Failover Using E2U+videomsg:sip</span>
$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
NAPTR 10 100 "u" "E2U+videomsg:sip"
"!^.*$!sip:[email protected]!".
$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
NAPTR 10 200 "u" "E2U+videomsg:sip"
"!^.*$!sip:[email protected]!".
In this example, the preference indicates that gw1.example.com is
used first (100), and if this is unreachable, then the next higher
preference (200) is used and gw2.example.com is contacted. While out
of scope for this document, a service provider could thus mirror or
cluster a message store and fail from the primary to secondary using
the DNS in an active-standby mode.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Implementation Recommendations</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Call Processing When Multiple Records Are Returned</span>
It is likely that both E2U+sip and E2U+voicemsg, E2U+videomsg, and/or
E2U+unifmsg Enumservice type records will be returned for a given
query. In this case, this could result in what is essentially
E2U+sip records for real-time communications with an end user, while,
for example, the E2U+voicemsg records will be used for real-time
communications with a voice messaging service, when the called party
is not available or does not wish to be disturbed. Therefore, the
network element that receives the results of this ENUM query will
need to know enough information in order to select the voicemsg
service type, rather than the sip service type.
<span class="grey">Livingood & Troshynski Standards Track [Page 17]</span><span id="page-18" ></span>
<span class="grey"><a href="./rfc5278">RFC 5278</a> VMSG Enumservice July 2008</span>
In addition, it is likely that multiple E2U+voicemsg, E2U+videomsg,
and/or E2U+unifmsg Enumservice type records will be returned for a
given query. In this case, multiple 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, as with multiple records resulting from a typical ENUM query
of the e164.arpa tree, it is up to the application using an ENUM
resolver to determine which record(s) to use and which record(s) 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.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. NAPTR Configuration Issues</span>
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.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. IANA Considerations</span>
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 <a href="./rfc3761">RFC</a>
<a href="./rfc3761">3761</a>. Details of this registration are provided in <a href="#section-4">Section 4</a> 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 <a href="./rfc3761">RFC 3761</a>. Details
of this registration are provided in <a href="#section-5">Section 5</a> 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 <a href="./rfc3761">RFC 3761</a>. Details
of this registration are provided in <a href="#section-6">Section 6</a> of this document.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Acknowledgements</span>
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.
<span class="grey">Livingood & Troshynski Standards Track [Page 18]</span><span id="page-19" ></span>
<span class="grey"><a href="./rfc5278">RFC 5278</a> VMSG Enumservice July 2008</span>
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Contributors</span>
Tong Zhou
Comcast Cable Communications
Email: [email protected]
Richard Ferrise
Comcast Cable Communications
Email: [email protected]
Chris Harvey
Comcast Cable Communications
Email: [email protected]
Hadriel Kaplan
Acme Packet
Email: [email protected]
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. References</span>
<span class="h3"><a class="selflink" id="section-12.1" href="#section-12.1">12.1</a>. Normative References</span>
[<a id="ref-1">1</a>] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", <a href="./rfc3761">RFC 3761</a>, April 2004.
[<a id="ref-2">2</a>] ITU-T, "The International Public Telecommunication Numbering
Plan", Recommendation E.164, May 1997.
[<a id="ref-3">3</a>] Mockapetris, P., "Domain names - concepts and facilities", STD
13, <a href="./rfc1034">RFC 1034</a>, November 1987.
[<a id="ref-4">4</a>] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The Domain Name System (DNS) Database", <a href="./rfc3403">RFC 3403</a>,
October 2002.
[<a id="ref-5">5</a>] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS", <a href="./rfc3401">RFC 3401</a>, October 2002.
[<a id="ref-6">6</a>] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Two: The Algorithm", <a href="./rfc3402">RFC 3402</a>, October 2002.
[<a id="ref-7">7</a>] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Four: The Uniform Resource Identifiers (URI)", <a href="./rfc3404">RFC 3404</a>,
October 2002.
<span class="grey">Livingood & Troshynski Standards Track [Page 19]</span><span id="page-20" ></span>
<span class="grey"><a href="./rfc5278">RFC 5278</a> VMSG Enumservice July 2008</span>
[<a id="ref-8">8</a>] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Five: URI.ARPA Assignment Procedures", <a href="https://www.rfc-editor.org/bcp/bcp65">BCP 65</a>, <a href="./rfc3405">RFC 3405</a>,
October 2002.
[<a id="ref-9">9</a>] Schulzrinne, H., "The tel URI for Telephone Numbers", <a href="./rfc3966">RFC 3966</a>,
December 2004.
[<a id="ref-10">10</a>] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", <a href="./rfc3261">RFC 3261</a>, June 2002.
[<a id="ref-11">11</a>] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", <a href="./rfc2616">RFC 2616</a>, June 1999.
[<a id="ref-12">12</a>] Rescorla, E., "HTTP Over TLS", <a href="./rfc2818">RFC 2818</a>, May 2000.
<span class="h3"><a class="selflink" id="section-12.2" href="#section-12.2">12.2</a>. Informative References</span>
[<a id="ref-13">13</a>] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using E.164
numbers with the Session Initiation Protocol (SIP)", <a href="./rfc3824">RFC 3824</a>,
June 2004.
[<a id="ref-14">14</a>] Vaudreuil, G., "Voice Message Routing Service", <a href="./rfc4238">RFC 4238</a>,
October 2005.
[<a id="ref-15">15</a>] Brandner, R., Conroy, L., and R. Stastny, "IANA Registration
for Enumservices email, fax, mms, ems, and sms", <a href="./rfc4355">RFC 4355</a>,
January 2006.
[<a id="ref-16">16</a>] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Protocol Modifications for the DNS Security Extensions", <a href="./rfc4035">RFC</a>
<a href="./rfc4035">4035</a>, March 2005.
[<a id="ref-17">17</a>] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
System (DNS)", <a href="./rfc3833">RFC 3833</a>, August 2004.
[<a id="ref-18">18</a>] Foster, M., McGarry, T., and J. Yu, "Number Portability in the
Global Switched Telephone Network (GSTN): An Overview", <a href="./rfc3482">RFC</a>
<a href="./rfc3482">3482</a>, February 2003.
[<a id="ref-19">19</a>] Peterson, J., "enumservice registration for Session Initiation
Protocol (SIP) Addresses-of-Record", <a href="./rfc3764">RFC 3764</a>, April 2004.
<span class="grey">Livingood & Troshynski Standards Track [Page 20]</span><span id="page-21" ></span>
<span class="grey"><a href="./rfc5278">RFC 5278</a> VMSG Enumservice July 2008</span>
Authors' Addresses
Jason Livingood
Comcast Cable Communications
One Comcast Center
1701 John F. Kennedy Boulevard
Philadelphia, PA 19103
USA
EMail: [email protected]
Donald Troshynski
Acme Packet
EMail: [email protected]
<span class="grey">Livingood & Troshynski Standards Track [Page 21]</span><span id="page-22" ></span>
<span class="grey"><a href="./rfc5278">RFC 5278</a> VMSG Enumservice July 2008</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, 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, THE IETF TRUST 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 <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
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
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
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
[email protected].
Livingood & Troshynski Standards Track [Page 22]
Annotations
Select text to annotate