GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3773

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:
  1. Desktop Email client applications
  2. IVM-capable Voice Mail systems
  3. IVM-capable unified messaging systems
  4. 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:
  1. Availability on desktops: Codecs SHOULD be available on most

platforms.

Candell Informational [Page 3] RFC 3773 Requirements for Internet Voice Mail June 2004

  1. Source code availability: Source code SHOULD be readily

accessible.

  1. Decoding complexity: All codecs MUST be low complexity to

decode.

  1. Encoding complexity: Some of the codecs MUST be low complexity

to encode.

  1. Bit rate: IVM SHOULD specify a codec with low bit rate for

devices (i.e., wireless) that do not have much space/bandwidth.

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

/data/webs/external/dokuwiki/data/pages/rfc/rfc3773.txt · Last modified: 2004/06/07 23:54 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki