Movatterモバイル変換

Network Working Group                                         E. CandellRequest for Comments: 3773                                      ComverseCategory: Informational                                        June 2004High-Level Requirements for Internet Voice MailStatus of this Memo   This memo provides information for the Internet community.  It does   not specify an Internet standard of any kind.  Distribution of this   memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (2004).Abstract   This document describes the high-level requirements for Internet   Voice Mail (IVM) and establishes a baseline of desired functionality   against which proposed MIME profiles for Internet Voice Messaging can   be judged.  IVM is an extension of the Voice Profile for Internet   Mail (VPIM) version 2 designed to support interoperability with   desktop clients.  Other goals for this version of VPIM include   expanded interoperability with unified messaging systems, conformance   to Internet standards, and backward compatibility with voice   messaging systems currently running in a VPIM enabled environment.   This document does not include goals that were met fully by VPIM   version 2.1.  Introduction   Until recently, voice mail and call answering services were   implemented as stand-alone proprietary systems.  Today, standards   such as the Voice Profile for Internet Mail (VPIM) enable   interoperability between such systems over the Internet.  VPIM   version 1 [VPIM1] was experimental and was a first attempt at a Voice   Profile for Internet Mail, but is now classified as Historical.  VPIM   Version 2 [VPIM2] is an improvement on VPIM version 1 that was   originally intended to provide interoperability between voice   messaging systems only.  It describes a messaging profile that   standardizes the exchange of voice mail over an IP messaging network   using SMTP [DRUMSMTP] and MIME [MIME1].   Because the number of desktop boxes is growing rapidly and will soon   approach the number of desktop telephones, it is essential to   consider the requirements of desktop email client applicationsCandell                      Informational                      [Page 1]

RFC 3773          Requirements for Internet Voice Mail         June 2004   (including, but not limited to, MIME-compliant email clients).  With   the trend toward integration of voice mail and email through unified   messaging (UM), it is now necessary to define a profile that supports   the needs of desktop applications and unified messaging systems   (including Internet Facsimile [EXFAX]).  This profile is being   referred to as Internet Voice Mail (IVM).   This document defines the goals for Internet Voice Mail.  This   standard will support the interchange of voice messages between voice   mail systems, unified messaging systems, email servers, and desktop   client applications.  The desktop client application is of particular   and important interest to IVM.  This document will also expand the   offerings of service providers by facilitating access to voice mail   from a web client.2.  Conventions used in this document   The following terms have specific meaning in this document:   "service"      An operational service offered by a service provider   "application"  A use of systems to perform a particular function   "terminal"     The endpoint of a communication application   "goal"         An objective of the standardization process   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 inBCP 14,RFC 2119   [RFC2119].3. Goals for Internet Voice Mail3.1.  Interoperability   Enhanced interoperability is the primary goal of IVM.  The profile   MUST facilitate interoperability between voice mail systems, unified   messaging systems, Internet email servers, and desktop client   applications.  Such interoperability MUST support systems which   combine multiple media types in a single message, as well as legacy   voice mail and email systems.  It MUST allow the ability to   accommodate varying capabilities of the voice mail, unified   messaging, and email systems.  Furthermore, IVM MUST be compatible   with Internet Fax (extended mode) proposed standards and VPIM   messages that contain fax body parts.Candell                      Informational                      [Page 2]

RFC 3773          Requirements for Internet Voice Mail         June 2004   To have "interoperability" means that an IVM compliant sender   attempting to send to a recipient will not fail because of   incompatibility.  IVM MUST support interoperability amongst the   systems listed below:      - Desktop Email client applications      - IVM-capable Voice Mail systems      - IVM-capable unified messaging systems      - Traditional email servers   IVM SHOULD also support interoperability with VPIM version 2 Voice   Mail Systems.   IVM MUST include new functionality to facilitate access to voice mail   messages from desktop applications.   Overall interoperability requires interoperability for all message   elements: body parts deemed essential for message validity MUST be   preserved, essential information MUST be provided in a form that is   accessible by the users, status codes [CODES] MUST be understood, and   operations that are standard for each system SHOULD be supported.3.1.1.  Interoperability with Desktop Email Client Applications   Desktop email applications are typically text based.  The abilities   to listen to, reply to, forward, and generate voice mail messages   from a traditional desktop environment are relatively new   developments.  To accommodate current use and future developments in   this area, IVM MUST provide features to support access to voice mail   messages from the desktop and other email-reading devices.  Also, web   access to voicemail SHOULD be supported from the desktop.   IVM SHOULD NOT require desktop email applications to possess a large   amount of processing power, and a base level implementation MUST   interoperate, even if it does not offer complex processing.  In order   to support interoperability, at least one mandatory codec MUST be   defined.  The mandatory codec(s) SHOULD be widely available on   desktops.  For interoperability with VPIM version 2 systems, IVM   applications MAY also support the VPIM v2 mandatory codec, 32KADPCM   [ADPCM and G726-32].   Any codecs included in the IVM specification SHOULD meet the   following criteria:      -  Availability on desktops: Codecs SHOULD be available on most         platforms.Candell                      Informational                      [Page 3]

RFC 3773          Requirements for Internet Voice Mail         June 2004      -  Source code availability: Source code SHOULD be readily         accessible.      -  Decoding complexity: All codecs MUST be low complexity to         decode.      -  Encoding complexity: Some of the codecs MUST be low complexity         to encode.      -  Bit rate: IVM SHOULD specify a codec with low bit rate for         devices (i.e., wireless) that do not have much space/bandwidth.      -  Voice Over IP support: IVM SHOULD specify a codec that supports         Voice over IP implementations.   Voice Content MUST always be contained in an audio/basic content-   type unless the originator is aware that the recipient can handle   other content.  To enable future support of other formats, IVM SHOULD   provide identification of the codec used without requiring   interpretation of an audio format.  IVM MAY allow audio encodings and   formats that are not identified in the IVM specification to support   environments in which the sender is aware of the optimal encoding and   format for the recipient.   To address performance and bandwidth issues, IVM MAY support   streaming of IVM audio to the desktop.  IVM MAY explicitly support   formats other than raw audio to facilitate streaming.   Because most email readers are text/html based and because many   devices are not capable of recording audio content, IVM MUST allow   inclusion of text body parts in a voice message.  IVM SHOULD NOT   explicitly prohibit other media types as long as critical content is   identified and minimal discard rules are specified.   To support devices that have applications dedicated to specific media   types or that are not capable of handling specific content, IVM   SHOULD define a way to describe the content of the message,   indicating how the content can be accessed.   Desktop implementation of IVM MUST support attachments of any media   type.Candell                      Informational                      [Page 4]

RFC 3773          Requirements for Internet Voice Mail         June 20043.1.2.  Interoperability with IVM-capable Voice Messaging Systems   Voice messaging systems are generally implemented as special-purpose   machines that interface to a telephone switch and provide call   answering and voice messaging services.  VPIM version 2 was designed   to support interoperability between such systems and remains the best   messaging profile for this purpose.   To support interoperability between IVM voice messaging systems and   other compliant systems, IVM SHOULD have a minimum set of required   features that will guarantee interoperability, and also provision for   additional functionality that may be supported by more complex   systems.  IVM MUST define a mechanism for identifying essential   content and status codes [CODES] indicating that a message could not   be delivered due to capability differences.   NOTE: IVM SHOULD provide some level of interoperability with VPIM   version 2 voice messaging systems.  In order to support minimal   interoperability between IVM and VPIM version 2, IVM systems MAY be   able to receive the VPIM version 2 32KADPCM codec [ADPCM and G726-   32], and MUST gracefully handle the case where a legacy receiving   system does not support the IVM codecs.3.1.3.  Interoperability with IVM-capable Unified Messaging Systems   Unified messaging solutions typically leverage common store,   directory, and transport layers to provide greater interoperability   and accessibility to a variety of media content.  They support   creation of and access to voicemail, email, and fax messages from a   single user interface.   To accommodate the common functionality of unified messaging systems,   IVM MUST support the inclusion of body parts containing different   media types.  It MUST also handle messages that contain VPIM messages   as attachments to messages of another type (such as multipart/mixed),   and VPIM messages that contain attachments of another type.   To provide interoperability with systems that cannot handle a   particular content type, IVM MUST provide a mechanism for identifying   critical content and MAY define media specific status codes and   strings to handle non-delivery of these body parts.Candell                      Informational                      [Page 5]

RFC 3773          Requirements for Internet Voice Mail         June 20043.1.4.  Interoperability with Traditional Email Servers   Traditional email servers are those that support only textual media   as inline content.  IVM MUST interoperate consistently with the   current Internet mail environment.  If an IVM message arrives in   users' mailboxes, IVM MUST provide a mechanism to interoperate with   common user practices for mail messages: storing them in databases,   retransmission, forwarding, creation of mail digests, and replying to   messages using non-audio equipment.3.2.  Conformance to Existing Standards   It is the goal of IVM to conform as closely as possible to existing   standards while meeting the other goals defined in this document.   -  Restrictions: The profile SHOULD impose as few restrictions as      possible to existing Internet mail standards.  In particular, it      MUST support all elements ofRFC 2822 [DRUMSIMF], except those      that prevent the profile from meeting other IVM goals.   -  Additions: The profile SHOULD make as few additions as possible to      existing internet mail standards.  It SHOULD adhere to existing      desktop conventions in desktop-related areas such as file      extensions.  If it is necessary to define new MIME types or sub-      types, the IVM work group SHOULD propose terms that are already      standard or in common use in the desktop environment.3.3.  Backward Compatibility   This profile SHOULD provide backward compatibility with VPIM version   2 to the extent that the functionality required to meet the goals of   this profile is not compromised.  Where backward compatibility is not   possible, IVM SHOULD provide and define a minimal set of rules and   status codes for handling non-delivery of IVM messages resulting from   interoperability with VPIM version 2 systems and other legacy   systems.3.4.  Robustness   IVM MUST be usable in an environment in which there exist legacy   gateways that do not understand MIME.  Core features and critical   data MUST not be lost when messages pass through AMIS gateways   [AMIS-A and AMIS-D].  IVM SHOULD allow interoperability with   recipient devices and gateways that have limited buffering   capabilities and cannot buffer all header information.Candell                      Informational                      [Page 6]

RFC 3773          Requirements for Internet Voice Mail         June 20043.5.  Security Considerations   To facilitate security, IVM MUST support authenticated and/or   encrypted voice messages.  In addition, IVM MUST adhere to the   security issues identified in VPIM v2 [VPIM2] and in the other RFCs   referenced by this document, especially SMTP [DRUMSMTP], Internet   Message Format [DRUMSIMF], and MIME [MIME1].4.  References4.1.  Normative References   [ADPCM]    Vaudreuil, G. and G. Parsons, "Toll Quality Voice - 32              kbit/s ADPCM: MIME Sub-type Registration",RFC 2422,              September 1998.   [AMIS-A]   Audio Messaging Interchange Specifications (AMIS) - Analog              Protocol Version 1, Issue 2, February 1992.   [AMIS-D]   Audio Messaging Interchange Specifications (AMIS) -              Digital Protocol Version 1, Issue 3 August 1993.   [CODES]    Vaudreuil, G., "Enhanced Mail System Status Codes",RFC3463, January 2003.   [DRUMSMTP] Klensin, J., "Simple Mail Transfer Protocol",RFC 2821,              April 2001.   [DRUMSIMF] Resnick, P., "Internet Message Format",RFC 2822, April              2001.   [EXFAX]    Masinter, L. and D. Wing, "Extended Facsimile Using              Internet Mail",RFC 2532, March 1999.   [G726-32]  CCITT Recommendation G.726 (1990), General Aspects of              Digital Transmission Systems, Terminal Equipment - 40,              32,24,16 kbit/s Adaptive Differential Pulse Code              Modulation (ADPCM).   [MIME1]    Freed, N. and N. Borenstein, "Multipurpose Internet Mail              Extensions (MIME) Part One: Format of Internet Message              Bodies",RFC 2045, November 1996.   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate              Requirement Levels",BCP 14,RFC 2119, March 1997.   [VPIM2]    Vaudreuil, G. and G. Parsons, "Voice Profile for Internet              Mail, Version 2",RFC 2421, September 1998.Candell                      Informational                      [Page 7]

RFC 3773          Requirements for Internet Voice Mail         June 20044.2.  Informative References   [VPIM1]    Vaudreuil, Greg, "Voice Profile for Internet Mail",RFC1911, February 1996.   [VPIM3]    Silvestro, L. and R. Miles, "Goals for Voice Profile for              Internet Mail, Version 3", Work in Progress, March 2000.5.    Acknowledgments   This document is the final result of an evolving requirements   document that started with VPIM v3 and evolved into an alternative   specification for a different (i.e., end-to-end instead of server-   to-server) application.  The basis for this document was written by   Laile Di Silvestro and Rod Miles [VPIM3].   The author gratefully acknowledges the authors of [VPIM3], and the   input and feedback provided by the members of the EMA and IETF VPIM   work groups.6.  Author's Address   Emily Candell   Comverse   200 Quannapowitt Parkway   Wakefield, MA 01803   Phone: +1-781-213-2324   EMail: emily.candell@comverse.comCandell                      Informational                      [Page 8]

RFC 3773          Requirements for Internet Voice Mail         June 20047.  Full Copyright Statement   Copyright (C) The Internet Society (2004).  This document is subject   to the rights, licenses and restrictions contained inBCP 78, and   except as set forth therein, the authors retain all their rights.   This document and the information contained herein are provided on an   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Intellectual Property   The IETF takes no position regarding the validity or scope of any   Intellectual Property Rights or other rights that might be claimed to   pertain to the implementation or use of the technology described in   this document or the extent to which any license under such rights   might or might not be available; nor does it represent that it has   made any independent effort to identify any such rights.  Information   on the procedures with respect to rights in RFC documents can be   found inBCP 78 andBCP 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 athttp://www.ietf.org/ipr.   The IETF invites any interested party to bring to its attention any   copyrights, patents or patent applications, or other proprietary   rights that may cover technology that may be required to implement   this standard.  Please address the information to the IETF at ietf-   ipr@ietf.org.Acknowledgement   Funding for the RFC Editor function is currently provided by the   Internet Society.Candell                      Informational                      [Page 9]