[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-livingood-enum-voicemsg) 00 01 02 RFC 5278

ENUM Working Group                                         J. Livingood
Internet-Draft                             Comcast Cable Communications
Expires: October 2008                                     D. Troshynski
Intended Status: Proposed Standard                          Acme Packet
                                                         April 16, 2008


                     IANA Registration of Enumservices
                       for Voice and Video Messaging
                          draft-ietf-enum-vmsg-02


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 18, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).


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.


Livingood et. al.      Expires October 18, 2008               [Page 1]

Internet-Draft             vmsg Enumservice                 April 2008


Table of Contents

   1. Terminology....................................................2
   2. Introduction...................................................3
      2.1 Selected Use Cases for Illustrative Purposes...............4
      2.2 Consideration of Other Existing Enumservices...............4
   3. Distribution of Data...........................................5
   4. Security Considerations........................................5
   5. ENUM Service Registration for voicemsg.........................6
      5.1 Registration for "voicemsg" with Subtype "sip".............6
      5.2 Registration for "voicemsg" with Subtype "sips"............6
      5.3 Registration for "voicemsg" with Subtype "tel".............7
      5.4 Registration for "voicemsg" with Subtype "http"............8
      5.5 Registration for "voicemsg" with Subtype "https"...........8
   6. ENUM Service Registration for videomsg.........................9
      6.1 Registration for "videomsg" with Subtype "sip".............9
      6.2 Registration for "videomsg" with Subtype "sips"...........10
      6.3 Registration for "videomsg" with Subtype "http"...........10
      6.4 Registration for "videomsg" with Subtype "https"..........11
   7. ENUM Service Registration for unifmsg.........................12
      7.1 Registration for "unifmsg" with Subtype "sip".............12
      7.2 Registration for "unifmsg" with Subtype "sips"............13
      7.3 Registration for "unifmsg" with Subtype "http"............13
      7.4 Registration for "unifmsg" with Subtype "https"...........14
   8. Selected Examples for Illustrative Purposes...................15
      8.1 Example Using a 'sip' URI.................................15
      8.2 Example Using a 'tel' URI.................................15
      8.3 Example Using a Backreference.............................15
      8.4 Example Using a 'sip' URI Without a Telephone Number......16
      8.5 Example of Failover Using E2U+videomsg:sip................16
   9. Implementation Recommendations................................16
      9.1 Call Processing When Multiple Records Are Returned........16
      9.2 NAPTR Configuration issues................................17
   10. IANA Considerations..........................................17
   11. Acknowledgements.............................................17
   12. Contributors.................................................18
   13. References...................................................18
      13.1 Normative References.....................................18
      13.2 Informative References...................................19
   Authors' Addresses...............................................19
   Intellectual Property and Copyright Statements...................20

1. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC-2119 [1].




Livingood et. al.      Expires October 18, 2008               [Page 2]

Internet-Draft             vmsg Enumservice                 April 2008


2. Introduction

   ENUM (E.164 Number Mapping, RFC 3761 [1]) is a technology that
   transforms E.164 numbers (The International Public Telecommunication
   Numbering Plan, ITU-T Recommendation E.164 [2]) into domain names and
   then uses DNS (Domain Name System, RFC 1034 [3]) delegation through
   NS records and NAPTR records (Dynamic Delegation Discovery System
   (DDDS) Part Three: The Domain Name System (DNS) Database, RFC 3403
   [4]) to look up what services are available for a specific domain
   name.

   This document registers Enumservices according to the guidelines
   given in RFC 3761 [1] to be used for provisioning in the services
   field of a NAPTR [4] 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 [4][5][6][7][8]) hierarchy, for use with the "E2U"
   DDDS Application defined in RFC 3761.

   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 VPIM [14] 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.

   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


Livingood et. al.      Expires October 18, 2008               [Page 3]

Internet-Draft             vmsg Enumservice                 April 2008


   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.

2.1 Selected Use Cases for Illustrative Purposes

   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 which is
   transparent to the calling party, and which 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 their 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.

2.2 Consideration of Other Existing Enumservices

   The authors considered whether this service type could simply use the
   SIP Enumservice type [19], 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,


Livingood et. al.      Expires October 18, 2008               [Page 4]

Internet-Draft             vmsg Enumservice                 April 2008


   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.

3. Distribution of Data

   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.

4. Security Considerations

   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 they 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.

   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.




Livingood et. al.      Expires October 18, 2008               [Page 5]

Internet-Draft             vmsg Enumservice                 April 2008


   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 [16] to this is provided in RFC 3761
   [1].  A thorough analysis of threats to the DNS itself is covered in
   RFC 3833 [17].

5. ENUM Service Registration for voicemsg

5.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 4.

   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 8.

5.2 Registration for "voicemsg" with Subtype "sips"

   Enumservice Name: "voicemsg"

   Enumservice Type: "voicemsg"



Livingood et. al.      Expires October 18, 2008               [Page 6]

Internet-Draft             vmsg Enumservice                 April 2008


   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 4.

   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 8.

5.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 4.

   Intended Usage: COMMON

   Authors:

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



Livingood et. al.      Expires October 18, 2008               [Page 7]

Internet-Draft             vmsg Enumservice                 April 2008


   Any other information the author deems interesting:

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

5.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 4.

   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 8.

5.5 Registration for "voicemsg" with Subtype "https"

   Enumservice Name: "voicemsg"

   Enumservice Type: "voicemsg"

   Enumservice Subtype: "https"


Livingood et. al.      Expires October 18, 2008               [Page 8]

Internet-Draft             vmsg Enumservice                 April 2008



   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 4.

   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 8.


6. ENUM Service Registration for videomsg

6.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.


Livingood et. al.      Expires October 18, 2008               [Page 9]

Internet-Draft             vmsg Enumservice                 April 2008



   Security Considerations: See Section 4.

   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 8.

6.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 4.

   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 8.

6.3 Registration for "videomsg" with Subtype "http"

   Enumservice Name: "videomsg"



Livingood et. al.      Expires October 18, 2008              [Page 10]

Internet-Draft             vmsg Enumservice                 April 2008


   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 4.

   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 8.

6.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.



Livingood et. al.      Expires October 18, 2008              [Page 11]

Internet-Draft             vmsg Enumservice                 April 2008


   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 4.

   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 8.

7. ENUM Service Registration for unifmsg

7.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 4.

   Intended Usage: COMMON

   Authors:

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



Livingood et. al.      Expires October 18, 2008              [Page 12]

Internet-Draft             vmsg Enumservice                 April 2008


   Any other information the author deems interesting:

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

7.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 4.

   Intended Usage: COMMON

   Authors:

   Jason Livingood (jason_livingood@cable.comcast.com)

   Any other information the author deems interesting:

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

7.3 Registration for "unifmsg" with Subtype "http"

   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.



Livingood et. al.      Expires October 18, 2008              [Page 13]

Internet-Draft             vmsg Enumservice                 April 2008


   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 4.

   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 8.

7.4 Registration for "unifmsg" with Subtype "https"

   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:' [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 4.

   Intended Usage: COMMON


Livingood et. al.      Expires October 18, 2008              [Page 14]

Internet-Draft             vmsg Enumservice                 April 2008



   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 8.

8. 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.

8.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!".

   In this example, a calling party has attempted a session which 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
   they record a voice message to the called party.

8.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!".

   In this example, a calling party has attempted a session which 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
   they record a voice message to the called party.

8.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!".





Livingood et. al.      Expires October 18, 2008              [Page 15]

Internet-Draft             vmsg Enumservice                 April 2008


   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.

8.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!".

   In this example, a calling party has attempted a session which 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
   they record 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.

8.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 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.

9. Implementation Recommendations

9.1 Call Processing When Multiple Records Are Returned

   It is likely that 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


Livingood et. al.      Expires October 18, 2008              [Page 16]

Internet-Draft             vmsg Enumservice                 April 2008


   need to know enough information in order to select the voicemsg
   service type, rather than the sip service type.

   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.

9.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.


10. 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 5 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 6 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 7 of this document.

11. 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


Livingood et. al.      Expires October 18, 2008              [Page 17]

Internet-Draft             vmsg Enumservice                 April 2008


   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.


12. 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

13. References

13.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 Number Plan",
   Recommendation E.164, May 1997.

   [3] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", 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.





Livingood et. al.      Expires October 18, 2008              [Page 18]

Internet-Draft             vmsg Enumservice                 April 2008


   [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", RFC 3405, October 2002.

   [9] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
   December 2004.

   [10] Rosenberg, J., et al., "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.

13.2 Informative References

   [13] Peterson, J., et al., "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] Bradner, et al., "IANA Registration for Enumservices email, fax,
   mms, ems and sms", RFC 4355, January 2006.

   [16] Arends, R. and et al., "Protocol Modifications for the DNS
   Security Extensions", RFC 4035, March 2005.

   [17] Atkins, D. and Austein, R., "Threat Analysis of the Domain Name
   System (DNS)", RFC 3833, August 2004.

   [18] Foster, M., McGarry, T., and Yu, J., "Number Portability in the
   GSTN: An Overview", RFC 3482, February 2003.

   [19] Peterson, J., "enumservice Registration for Session Initiation
   Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004.

   [20] Bradner, et al., "IANA Registration for Enumservice 'web' and
   'ft', RFC 4022, February 2005.

Authors' Addresses

   Jason Livingood
   Comcast Cable Communications


Livingood et. al.      Expires October 18, 2008              [Page 19]

Internet-Draft             vmsg Enumservice                 April 2008


   One Comcast Center
   1701 John F. Kennedy Boulevard
   Philadelphia, PA 19103
   USA
   Email: jason_livingood@cable.comcast.com

   Donald Troshynski
   Acme Packet
   Email: dtroshynski@acmepacket.com

Intellectual Property and Copyright Statements

   Full Copyright Statement

   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.

  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 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.



Livingood et. al.      Expires October 18, 2008              [Page 20]

Internet-Draft             vmsg Enumservice                 April 2008



  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.


   Acknowledgment

   Funding for the RFC Editor function is currently provided by the IETF
   Administrative Support Activity (IASA).






































Livingood et. al.      Expires October 18, 2008              [Page 21]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/