diff options
Diffstat (limited to 'doc/rfc/rfc3773.txt')
| -rw-r--r-- | doc/rfc/rfc3773.txt | 507 |
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc3773.txt b/doc/rfc/rfc3773.txt new file mode 100644 index 0000000..c192c62 --- /dev/null +++ b/doc/rfc/rfc3773.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group E. Candell +Request for Comments: 3773 Comverse +Category: Informational June 2004 + + + High-Level Requirements for Internet Voice Mail + +Status 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 applications + + + +Candell 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 in BCP 14, RFC 2119 + [RFC2119]. + +3. Goals for Internet Voice Mail + +3.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 2004 + + +3.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 2004 + + +3.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 of RFC 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 2004 + + +3.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. References + +4.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", RFC + 3463, 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 2004 + + +4.2. Informative References + + [VPIM1] Vaudreuil, Greg, "Voice Profile for Internet Mail", RFC + 1911, 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.com + + + + + + + + + + + + + + + + + + + + + + + +Candell Informational [Page 8] + +RFC 3773 Requirements for Internet Voice Mail June 2004 + + +7. Full Copyright Statement + + Copyright (C) The Internet Society (2004). 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 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. + + 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] + |