One document matched: draft-ietf-enum-vmsg-00.txt


ENUM Working Group                                         J. Livingood 
Internet-Draft                             Comcast Cable Communications 
Expires: May 2008                                         D. Troshynski 
Intended Status: Proposed Standard                          Acme Packet 
                                                       November 9, 2007 
    
    
                     IANA Registration of Enumservices 
                  for Voice Messaging and Video Messaging 
                          draft-ietf-enum-vmsg-00 
    
    
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 May 12, 2008.  
    
Copyright Notice 
    
   Copyright (C) The IETF Trust (2007). 
    
    
Abstract 
    
   This document registers the Enumservice named "vmsg", which is used 
   to facilitate the real-time routing of voice and/or video 
   communications to a messaging system.  This vmsg Enumservice 
   registers three Enumservice types; "voicemsg", "videomsg", and 
   "unifmsg". 
    

 
 
Livingood et. al.        Expires May 12, 2008                 [Page 1] 
Internet-Draft             vmsg Enumservice              November 2007 
 
 
   This vmsg Enumservice registers the Enumservice type "voicemsg" with 
   the subtype "sip" using the URI scheme 'sip', the subtype "sips" 
   using the URI scheme 'sips', the subtype "tel" using the URI scheme 
   'tel', the subtype "http" using the URI scheme 'http', and the 
   subtype "https" using the URI scheme 'https', as per the IANA 
   registration process defined in the ENUM specification, RFC 3761.  
    
   This vmsg Enumservice also registers the Enumservice type "videomsg" 
   with the Enumservice subtype "sip" using the URI scheme 'sip',  the 
   subtype "sips" using the URI scheme 'sips', the subtype "http" using 
   the URI scheme 'http', and the subtype "https" using the URI scheme 
   'https', as per the IANA registration process defined in the ENUM 
   specification, RFC 3761.  
    
   Finally, this vmsg Enumservice also registers the Enumservice type 
   "unifmsg" with the Enumservice subtype "sip" using the URI scheme 
   'sip',  the subtype "sips" using the URI scheme 'sips', the subtype 
   "http" using the URI scheme 'http', and the subtype "https" using the 
   URI scheme 'https', as per the IANA registration process defined in 
   the ENUM specification, RFC 3761.  
 




























 
 
Livingood et. al.        Expires May 12, 2008                 [Page 2] 
Internet-Draft             vmsg Enumservice              November 2007 
 
 
Table of Contents 
    
   1. Terminology....................................................4 
   2. Introduction...................................................4 
      2.1 Voice Messaging Use Cases for "voicemsg"...................5 
      2.2 Video Messaging Use Cases for "videomsg"...................6 
      2.3 Unified Voice and Video Messaging Use Cases for "unifmsg"..6 
      2.4 Consideration of Other Existing Enumservices...............7 
   3. Distribution of Data...........................................8 
   4. ENUM Service Registration for voicemsg.........................8 
      4.1 ENUM Service Registration for "voicemsg" with Subtype "sip"8 
      4.2 ENUM Service Registration for "voicemsg" with Subtype "sips"8 
      4.3 ENUM Service Registration for "voicemsg" with Subtype "tel"9 
      4.4 ENUM Service Registration for "voicemsg" with Subtype "http"10 
      4.5 ENUM Service Registration for "voicemsg" with Subtype "https"
      ..............................................................10 
   5. Examples for voicemsg.........................................11 
      5.1 Example of a calling party send to a voice messaging system, 
      Using a 'sip' URI Scheme......................................11 
      5.2 Example of a calling party send to a voice messaging system, 
      Using a 'tel' URI Scheme......................................12 
      5.3 Example Using a Regular Expression........................12 
      5.4 Example of a calling party send to a voice messaging system, 
      Using a 'sip' URI Scheme where the URI does not contain a 
      telephone number..............................................12 
   6. ENUM Service Registration for videomsg........................12 
      6.1 ENUM Service Registration for "videomsg" with Subtype "sip"12 
      6.2 ENUM Service Registration for "videomsg" with Subtype "sips"13 
      6.3 ENUM Service Registration for "videomsg" with Subtype "http"14 
      6.4 ENUM Service Registration for "videomsg" with Subtype "https"
      ..............................................................14 
   7. Examples for videomsg.........................................15 
      7.1 Example of a calling party sent to a video messaging system, 
      Using a 'sip' URI Scheme......................................15 
      7.2 Example Using a Regular Expression........................16 
      7.3 Example of a calling party sent to a video messaging system, 
      Using a 'sip' URI Scheme where the URI does not contain a 
      telephone number..............................................16 
   8. ENUM Service Registration for unifmsg.........................16 
      8.1 ENUM Service Registration for "unifmsg" with Subtype "sip"16 
      8.2 ENUM Service Registration for "unifmsg" with Subtype "sips"17 
      8.3 ENUM Service Registration for "unifmsg" with Subtype "http"17 
      8.4 ENUM Service Registration for "unifmsg" with Subtype "https"18 
   9. Examples for the vmsg Enumservice.............................19 
      9.1 Example of a calling party sent to a video messaging system, 
      Using a 'sip' URI Scheme......................................19 
      9.2 Example of a calling party sent to a video messaging system, 
      Using a 'tel' URI Scheme......................................19 
      9.3 Example Using a Regular Expression........................20 
 
 
Livingood et. al.        Expires May 12, 2008                 [Page 3] 
Internet-Draft             vmsg Enumservice              November 2007 
 
 
      9.4 Example of a calling party sent to a video messaging system, 
      Using a 'sip' URI Scheme where the URI does not contain a 
      telephone number..............................................20 
   10. Implementation Recommendations...............................20 
      10.1 Call Processing When Multiple Records Are Returned.......20 
      10.2 NAPTR Configuration issues...............................21 
   11. Security Considerations......................................21 
   12. IANA Considerations..........................................22 
   13. Acknowledgements.............................................22 
   14. Contributors.................................................22 
   15. References...................................................23 
      15.1 Normative References.....................................23 
      15.2 Informative References...................................24 
   Authors' Addresses...............................................24 
   Intellectual Property and Copyright Statements...................25 
    
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]. 
    
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 [11] but found that VPIM was 
   best suited to the non-real-time and non-session-based routing of a 
 
 
Livingood et. al.        Expires May 12, 2008                 [Page 4] 
Internet-Draft             vmsg Enumservice              November 2007 
 
 
   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 
   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 Voice Messaging Use Cases for "voicemsg" 
    
   The following is a partial, non-exclusive list of use cases that the 
   vmsg Enumservice type "voicemsg" could address: 
    
    
    
   * A called party is busy or does not answer a call. A client or 
   server then determines that a voice 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 voice messaging system, but that system is currently unavailable.  
   Since multiple voice messaging 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 voice messaging servers 
   in a manner which is transparent to the calling party, and which 
   supports better overall availability of a voice messaging service. 
 
 
Livingood et. al.        Expires May 12, 2008                 [Page 5] 
Internet-Draft             vmsg Enumservice              November 2007 
 
 
     
   * Similar to the above use case, this voice message service type 
   could be used to balance load across multiple voice messaging 
   servers, whether those are in the same or in different physical 
   locations. 
    
   * A user with an account on a voice messaging service needs to 
   connect to a voice messaging service in order to retrieve voice 
   messages.  They initiate a real-time session and an ENUM query is 
   performed to discover the voice messaging server that holds their 
   mailbox. 
    
2.2 Video Messaging Use Cases for "videomsg" 
    
   The following is a partial, non-exclusive list of use cases that the 
   vmsg Enumservice type "videomsg" could address: 
    
   * A called party is busy or does not answer a call. A client or 
   server then determines that a video 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 video messaging system, but that system is currently unavailable.  
   Since multiple video messaging 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 video messaging servers 
   in a manner which is transparent to the calling party, and which 
   supports better overall availability of a video messaging service. 
     
   * Similar to the above use case, this video message service type 
   could be used to balance load across multiple video messaging 
   servers, whether those are in the same or in different physical 
   locations. 
    
   * A user with an account on a video messaging service needs to 
   connect to a video messaging service in order to retrieve video 
   messages.  They initiate a real-time session and an ENUM query is 
   performed to discover the video messaging server that holds their 
   mailbox. 
    
    
2.3 Unified Voice and Video Messaging Use Cases for "unifmsg" 
    
   The following is a partial, non-exclusive list of use cases that the 
   vmsg Enumservice type "unifmsg" could address: 
    
 
 
Livingood et. al.        Expires May 12, 2008                 [Page 6] 
Internet-Draft             vmsg Enumservice              November 2007 
 
 
   * A called party is busy or does not answer a call. A client or 
   server then determines that a unified voice and video 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 unified voice and video messaging system, but that system is 
   currently unavailable.  Since multiple unified voice and video 
   messaging 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 unified voice and video messaging servers in 
   a manner which is transparent to the calling party, and which 
   supports better overall availability of a video messaging service. 
     
   * Similar to the above use case, this unified voice and video message 
   service type could be used to balance load across multiple unified 
   voice and video messaging servers, whether those are in the same or 
   in different physical locations. 
    
   * A user with an account on a unified voice and video messaging 
   service needs to connect to a unified voice and video messaging 
   service in order to retrieve voice and/or video messages.  They 
   initiate a real-time session and an ENUM query is performed to 
   discover the unified voice and video messaging server that holds 
   their mailbox. 
    
    
2.4 Consideration of Other Existing Enumservices 
    
   The authors considered whether this service type could simply use the 
   SIP Enumservice type [16], 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.   
 


 
 
Livingood et. al.        Expires May 12, 2008                 [Page 7] 
Internet-Draft             vmsg Enumservice              November 2007 
 
 
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. ENUM Service Registration for voicemsg 
 
4.1 ENUM Service 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 11. 
    
   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 9. 
 
4.2 ENUM Service Registration for "voicemsg" with Subtype "sips" 
    
   Enumservice Name: "voicemsg" 
    
   Enumservice Type: "voicemsg" 
    
 
 
Livingood et. al.        Expires May 12, 2008                 [Page 8] 
Internet-Draft             vmsg Enumservice              November 2007 
 
 
   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 11. 
    
   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 9. 
    
    
4.3 ENUM Service 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 11. 
    
   Intended Usage: COMMON 
    
   Authors: 
    
   Jason Livingood (jason_livingood@cable.comcast.com) 
   Don Troshynski (dtroshynski@acmepacket.com) 
 
 
Livingood et. al.        Expires May 12, 2008                 [Page 9] 
Internet-Draft             vmsg Enumservice              November 2007 
 
 
    
   Any other information the author deems interesting: 
    
   Implementers should review a non-exclusive list of examples below in 
   Section 9. 
    
4.4 ENUM Service 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 11. 
    
   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 9. 
    
    
4.5 ENUM Service Registration for "voicemsg" with Subtype "https" 
    
   Enumservice Name: "voicemsg" 
    
   Enumservice Type: "voicemsg" 
 
 
Livingood et. al.        Expires May 12, 2008                [Page 10] 
Internet-Draft             vmsg Enumservice              November 2007 
 
 
    
   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 11. 
    
   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 9. 
    
5. Examples for voicemsg 
 
   The following sub-sections document several examples for illustrative 
   purposes.  These examples shall in no way limit the various forms 
   that this Enumservice may take. 
    
5.1 Example of a calling party send to a voice messaging system, Using a 
    'sip' URI Scheme 
    
   $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 
 
 
Livingood et. al.        Expires May 12, 2008                [Page 11] 
Internet-Draft             vmsg Enumservice              November 2007 
 
 
   personalized greeting is played to the calling party, after which 
   they record a voice message to the called party. 
    
5.2 Example of a calling party send to a voice messaging system, Using a 
    'tel' URI Scheme 
    
   $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. 
    
5.3 Example Using a Regular Expression 
    
   $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!". 
    
   In this example, a regular expression replacement function 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. 
    
5.4 Example of a calling party send to a voice messaging system, Using a 
    'sip' URI Scheme where the URI does not contain 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. 
    
6. ENUM Service Registration for videomsg 
 
6.1 ENUM Service Registration for "videomsg" with Subtype "sip" 
    
   Enumservice Name: "videomsg" 
 
 
Livingood et. al.        Expires May 12, 2008                [Page 12] 
Internet-Draft             vmsg Enumservice              November 2007 
 
 
    
   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 11. 
    
   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 9. 
    
6.2 ENUM Service 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 11. 
    
   Intended Usage: COMMON 
    
   Authors: 
    
 
 
Livingood et. al.        Expires May 12, 2008                [Page 13] 
Internet-Draft             vmsg Enumservice              November 2007 
 
 
   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 9. 
    
6.3 ENUM Service 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 11. 
    
   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 9. 
    
    
6.4 ENUM Service Registration for "videomsg" with Subtype "https" 
    
   Enumservice Name: "videomsg" 
 
 
Livingood et. al.        Expires May 12, 2008                [Page 14] 
Internet-Draft             vmsg Enumservice              November 2007 
 
 
    
   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 11. 
    
   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 9. 
    
7. Examples for videomsg 
 
   The following sub-sections document several examples for illustrative 
   purposes.  These examples shall in no way limit the various forms 
   that this Enumservice may take. 
    
7.1 Example of a calling party sent to a video messaging system, Using a 
    'sip' URI Scheme 
    
   $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 
      NAPTR 10 100 "u" "E2U+videomsg:sip" 
      "!^.*$!sip:12155550123@gw.example.com!". 
    

 
 
Livingood et. al.        Expires May 12, 2008                [Page 15] 
Internet-Draft             vmsg Enumservice              November 2007 
 
 
   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 video messaging server, a 
   personalized greeting is played to the calling party, after which 
   they record a video message to the called party. 
    
7.2 Example Using a Regular Expression 
    
   $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 
      NAPTR 10 100 "u" "E2U+videomsg:sip" 
      "!(^.*)$!sip:\1!". 
    
   In this example, a regular expression replacement function 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. 
    
7.3 Example of a calling party sent to a video messaging system, Using a 
    'sip' URI Scheme where the URI does not contain a telephone number 
     
      $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.  
         NAPTR 10 100 "u" "E2U+videomsg: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 video messaging server, a 
   personalized greeting is played to the calling party, after which 
   they record a video message to the called party.  The URI that this 
   session is directed to does not include a telephone number, as this 
   user has multiple services that are not particularly tied to 
   telephone numbers whereby text, audio, video and other multimedia 
   messages can be received and accessed. 
 
8. ENUM Service Registration for unifmsg 
 
8.1 ENUM Service Registration for "unifmsg" with Subtype "sip" 
    
   Enumservice Name: "unifmsg" 
    
   Enumservice Type: "unifmsg" 
    
   Enumservice Subtypes: "sip" 
    
   URI Schemes: 'sip:' 
    
   Functional Specification: 
    

 
 
Livingood et. al.        Expires May 12, 2008                [Page 16] 
Internet-Draft             vmsg Enumservice              November 2007 
 
 
   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 11. 
    
   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 9. 
    
8.2 ENUM Service 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 video 
   communication session to a video messaging system. 
    
   Security Considerations: See Section 11. 
    
   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 9. 
    
8.3 ENUM Service Registration for "unifmsg" with Subtype "http" 
    
 
 
Livingood et. al.        Expires May 12, 2008                [Page 17] 
Internet-Draft             vmsg Enumservice              November 2007 
 
 
   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:' [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 11. 
    
   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 9. 
    
    
8.4 ENUM Service Registration for "unifmsg" with Subtype "https" 
    
   Enumservice Name: "unifmsg" 
    
   Enumservice Type: "unifmsg" 
    
   Enumservice Subtype: "https" 
    
   URI Schemes: 'https:' 
    
   Functional Specification: 
    

 
 
Livingood et. al.        Expires May 12, 2008                [Page 18] 
Internet-Draft             vmsg Enumservice              November 2007 
 
 
   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 11. 
    
   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 9. 
    
9. Examples for the vmsg Enumservice 
 
   The following sub-sections document several examples for illustrative 
   purposes.  These examples shall in no way limit the various forms 
   that this Enumservice may take. 
    
9.1 Example of a calling party sent to a video messaging system, Using a 
    'sip' URI Scheme 
    
   $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 
      NAPTR 10 100 "u" "E2U+unifmsg: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 video messaging server, a 
   personalized greeting is played to the calling party, after which 
   they record a video message to the called party. 
    
9.2 Example of a calling party sent to a video messaging system, Using a 
    'tel' URI Scheme 
    
   $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 
 
 
Livingood et. al.        Expires May 12, 2008                [Page 19] 
Internet-Draft             vmsg Enumservice              November 2007 
 
 
      NAPTR 10 100 "u" "E2U+unifmsg: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 video messaging server, a 
   personalized greeting is played to the calling party, after which 
   they record a video message to the called party. 
    
9.3 Example Using a Regular Expression 
    
   $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 
      NAPTR 10 100 "u" "E2U+unifmsg:sip" 
      "!(^.*)$!sip:\1!". 
    
   In this example, a regular expression replacement function 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. 
    
9.4 Example of a calling party sent to a video messaging system, Using a 
    'sip' URI Scheme where the URI does not contain a telephone number 
     
      $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.  
         NAPTR 10 100 "u" "E2U+unifmsg: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 video messaging server, a 
   personalized greeting is played to the calling party, after which 
   they record a video message to the called party.  The URI that this 
   session is directed to does not include a telephone number, as this 
   user has multiple services that are not particularly tied to 
   telephone numbers whereby text, audio, video and other multimedia 
   messages can be received and accessed. 
 
10. Implementation Recommendations  
 
10.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 May 12, 2008                [Page 20] 
Internet-Draft             vmsg Enumservice              November 2007 
 
 
   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.   
    
10.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.   
    
    
11. 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 
 
 
Livingood et. al.        Expires May 12, 2008                [Page 21] 
Internet-Draft             vmsg Enumservice              November 2007 
 
 
   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 [13] to this is provided in RFC 3761 
   [1].  A thorough analysis of threats to the DNS itself is covered in 
   RFC 3833 [14]. 
    
12. 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 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 8 of this document. 
    
    
13. 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. 
    
    
14. Contributors 
    
   Tong Zhou 
   Comcast Cable Communications 
    
 
 
Livingood et. al.        Expires May 12, 2008                [Page 22] 
Internet-Draft             vmsg Enumservice              November 2007 
 
 
   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 
    
    
15. References 
    
15.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. 
    
   [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 
   Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 
   2002. 
    
 
 
Livingood et. al.        Expires May 12, 2008                [Page 23] 
Internet-Draft             vmsg Enumservice              November 2007 
 
 
   [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. 
    
    
15.2 Informative References 
    
   [11] Vaudreuil, G., "Voice Message Routing Service", RFC 4238, 
   October 2005. 
    
   [12] Bradner, et al., "IANA Registration for Enumservices email, fax, 
   mms, ems and sms", RFC 4355, January 2006. 
    
   [13] Arends, R. and et al., "Protocol Modifications for the DNS 
   Security Extensions", RFC 4035, March 2005. 
    
   [14] Atkins, D. and Austein, R., "Threat Analysis of the Domain Name 
   System (DNS)", RFC 3833, August 2004. 
    
   [15] Foster, M., McGarry, T., and Yu, J., "Number Portability in the 
   GSTN: An Overview", RFC 3482, February 2003. 
 
   [16] Peterson, J., "enumservice Registration for Session Initiation 
   Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004. 
    
   [17] Bradner, et al., "IANA Registration for Enumservice 'web' and 
   'ft', RFC 4022, February 2005. 
    
    
Authors' Addresses 
    
   Jason Livingood 
   Comcast Cable Communications 
   1500 Market Street 
   Philadelphia, PA 19102 
   USA 
    
   Phone: +1-215-981-7813 
 
 
Livingood et. al.        Expires May 12, 2008                [Page 24] 
Internet-Draft             vmsg Enumservice              November 2007 
 
 
   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 (2007).   
    
   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 May 12, 2008                [Page 25] 
Internet-Draft             vmsg Enumservice              November 2007 
 
 
  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 May 12, 2008                [Page 26] 


PAFTECH AB 2003-20262026-04-24 02:39:40