RFC 3773

High-Level Requirements for Internet Voice Mail

📅 published June 2004, from ietf

RFC 3773: High-Level Requirements for Internet Voice Mail 📞✨

okay bestie, this one is from June 2004 and it's written by E. Candell from Comverse 💅. It came out through the Network Working Group as an Informational doc 🌸. Nothing in its header says it obsoletes or updates anything 🫶.

Status of This Memo 🌷

This memo is here to give the Internet community information 💖. It does not specify an Internet standard of any kind 🙈. Distribution is unlimited, so share it with everyone 🦋.

Copyright (C) The Internet Society (2004) 🎀.

Abstract 🌈

okay so this doc lays out the high-level requirements for Internet Voice Mail (IVM) ✨. It sets a baseline of the features everyone wants, and that's what proposed MIME profiles for Internet Voice Messaging get judged against 👑. IVM is an extension of the Voice Profile for Internet Mail (VPIM) version 2, built to play nicely with desktop clients 🌸. The other goals for this version of VPIM are expanded interoperability with unified messaging systems, conformance to Internet standards, and backward compatibility with voice messaging systems that are already running in a VPIM enabled environment 💜. Also, this document doesn't cover goals that VPIM version 2 already fully met 🧚.

1. Introduction 💖

Until pretty recently, voice mail and call answering services were stand-alone proprietary systems, so they couldn't talk to each other 😭. Now standards like the Voice Profile for Internet Mail (VPIM) let those systems interoperate over the Internet 🌐. VPIM version 1 [VPIM1] was experimental and was the very first attempt at a Voice Profile for Internet Mail, but it's now classified as Historical 🕰️. VPIM Version 2 [VPIM2] improves on version 1, and it was originally meant to get voice messaging systems talking to each other and nothing else 💅. It's a messaging profile that standardizes how voice mail gets exchanged over an IP messaging network, using SMTP [DRUMSMTP] and MIME [MIME1] 🍓.

Here's the tea 🫖: the number of desktop boxes is growing fast and will soon catch up with the number of desktop telephones 📈. So it's essential to think about what desktop email client applications need, including (but not only) MIME-compliant email clients 💜. With voice mail and email merging through unified messaging (UM), we now need a profile that works for both desktop apps and unified messaging systems, including Internet Facsimile [EXFAX] 🔥. That profile is being called Internet Voice Mail (IVM) 🦋.

This document defines the goals for Internet Voice Mail ✨. This standard will support swapping voice messages between voice mail systems, unified messaging systems, email servers, and desktop client applications 🌈. The desktop client application is the big priority for IVM 👑. This doc also widens what service providers can offer, by making it easier to reach voice mail from a web client 🫶.

2. Conventions used in this document 🎀

The following terms have a 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 number one goal of IVM 👑. The profile MUST facilitate interoperability between voice mail systems, unified messaging systems, Internet email servers, and desktop client applications 💖. That interoperability MUST support systems that combine multiple media types in a single message, plus legacy voice mail and email systems 🌈. It MUST allow for the varying capabilities of voice mail, unified messaging, and email systems 🦋. And IVM MUST be compatible with Internet Fax (extended mode) proposed standards and with VPIM messages that contain fax body parts 🧚.

so "interoperability" here means that an IVM compliant sender trying to send to a recipient won't fail because of incompatibility 😭. IVM MUST support interoperability among these systems:

  • 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 that makes it easy to reach voice mail messages from desktop applications 💜.

Overall interoperability means every message element has to interoperate 🫖. So body parts that are essential for message validity MUST be preserved ✨, essential information MUST be provided in a form users can access 🎀, 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 apps are usually text based 📝. Being able to listen to, reply to, forward, and generate voice mail from a traditional desktop is pretty new 😤. To keep up with what people use now and what's coming, IVM MUST provide features that support accessing voice mail from the desktop and from other email-reading devices 💖. Web access to voicemail SHOULD also be supported from the desktop 🌐.

IVM SHOULD NOT require desktop email apps to have a ton of processing power 🙈, and a base level implementation MUST interoperate, even if it doesn't offer complex processing 🫶. For 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 these criteria 👑:

  • Availability on desktops: Codecs SHOULD be available on most platforms.
  • 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 don't have much space or 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 knows the recipient can handle other content 🎀. To allow future support of other formats, IVM SHOULD identify the codec used without needing to interpret an audio format 🧚. IVM MAY allow audio encodings and formats that aren't identified in the IVM specification, for environments where the sender knows the best encoding and format for the recipient 💜.

To deal with performance and bandwidth issues, IVM MAY support streaming of IVM audio to the desktop 🌊. IVM MAY explicitly support formats other than raw audio to make streaming easier 💫.

Because most email readers are text/html based, and lots of devices can't record audio content, IVM MUST allow 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 🌸.

For devices that have apps dedicated to specific media types, or that can't handle certain content, IVM SHOULD define a way to describe the content of the message and show how that content can be accessed 🔍.

Desktop implementation of IVM MUST support attachments of any media type 🫶.

📣 heads up: this doc is long, so this is only part 1. The rest of the requirements (3.1.2 onward, plus references) are coming in part 2 🦋

3.1.2. Interoperability with IVM-capable Voice Messaging Systems 📞

Voice messaging systems are usually special-purpose machines that hook up to a telephone switch and provide call answering and voice messaging services ☎️. VPIM version 2 was designed for interoperating between those systems, and it's still the best messaging profile for that job 👑.

To support interoperability between IVM voice messaging systems and other compliant systems, IVM SHOULD have a minimum set of required features that guarantee interoperability 💖. It should also make room for extra functionality that more complex systems might support 🌈. IVM MUST define a mechanism for identifying essential content, and for status codes [CODES] that show a message couldn't be delivered because of capability differences 😤.

NOTE: IVM SHOULD provide some level of interoperability with VPIM version 2 voice messaging systems 🫶. For 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 they MUST gracefully handle the case where a legacy receiving system doesn't support the IVM codecs 🫖.

3.1.3. Interoperability with IVM-capable Unified Messaging Systems 📬

Unified messaging solutions usually use common store, directory, and transport layers to give better interoperability and access to a bunch of media content 🧚. They let you create and access voicemail, email, and fax messages from one single user interface 💅.

To fit the common functionality of unified messaging systems, IVM MUST support including body parts with 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 work with systems that can't handle a particular content type, IVM MUST provide a mechanism for identifying critical content 🔥. IVM MAY also define media specific status codes and strings to handle non-delivery of those body parts 🦋.

3.1.4. Interoperability with Traditional Email Servers 📧

Traditional email servers are the ones that only support textual media as inline content 🍓. IVM MUST interoperate consistently with the current Internet mail environment 💖. If an IVM message lands in users' mailboxes, IVM MUST provide a mechanism to work with common mail practices 🫶: storing messages in databases, retransmission, forwarding, creating mail digests, and replying to messages from non-audio equipment 💅✨

3.2. Conformance to Existing Standards ✨

okay so the big goal here is for IVM to match existing standards as closely as it possibly can 🦋 while still hitting all the other goals. no cap, it's a balancing act 💅

  • 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 🌸

bestie, this one is about VPIM version 2 🎀 The profile SHOULD stay backward compatible with it, but only as far as that doesn't wreck the functionality needed to hit the goals of this profile. 😭

If backward compatibility just isn't possible, IVM SHOULD provide and define a minimal set of rules and status codes for handling non-delivery of IVM messages. That covers interoperability with VPIM version 2 systems and other legacy systems. ✨

3.4. Robustness 💜

IVM MUST be usable in an environment that still has legacy gateways which don't understand MIME. 🫶 Core features and critical data MUST not be lost when messages pass through AMIS gateways [AMIS-A and AMIS-D]. That's a big deal, periodt 🔥

IVM SHOULD also allow interoperability with recipient devices and gateways that have limited buffering capabilities and cannot buffer all header information. 🧚

3.5. Security Considerations 🔐

Security is NOT a side quest here 💀 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. The ones called out especially are SMTP [DRUMSMTP], Internet Message Format [DRUMSIMF], and MIME [MIME1]. Read those carefully, iykyk 🙈

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.

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 🫶

okay this part is sweet 🥹 This document is the final result of an evolving requirements document. It started with VPIM v3 and grew into an alternative specification for a different application, one that is end-to-end instead of server-to-server. The basis for this document was written by Laile Di Silvestro and Rod Miles [VPIM3].

The author gratefully acknowledges the authors of [VPIM3], along with 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

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. It also doesn't 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. ✨

📦 where this page comes from