[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 4239

     VPIM Working Group                                         Stuart McRae
     Internet Draft                                        Lotus Development
     Document: <draft-ietf-vpim-ivm-02.txt>                    Glenn Parsons
     Category: Standards Track                               Nortel Networks
                                                               July 19, 2001

                                Internet Voice Messaging

     Status of this Memo

        This document is an Internet-Draft and is in full conformance with all
        provisions of Section 10 of RFC2026.

        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
        The list of Internet-Draft Shadow Directories can be accessed at

     1. Abstract

        This document provides for the carriage of voicemail messages over
        Internet mail as part of a unified messaging infrastructure.

        The Internet Voice Messaging (IVM) concept described in this document
        was originally called VPIM v3. This term has been dropped to reflect
        the fact that it is not a successor format to VPIM v2, but rather an
        alternative specification for a different application.

     2. Conventions used in this document

        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 RFC-2119 [KEYWORDS].

McRae & Parsons           Expires:  19/02/02                         1
     Internet Voice Messaging                                July 2001

     3. Introduction

        People naturally communicate using their voices, and this is preferable
        to typing for some forms of communication. By permitting voicemail to
        be implemented in an interoperable way on top of Internet Mail, voice
        messaging and electronic mail need no longer remain separate, isolated
        worlds and users will be able to choose the most appropriate form of
        communication. This will also enable new types of device, without
        keyboards, to be used to participate in electronic messaging when
        mobile, in a hostile environment, or in spite of disabilities.

        There exist unified messaging systems which will transmit voicemail
        messages over the Internet using SMTP/MIME, but these systems suffer
        from a lack of interoperability because various aspects of such a
        message have not hitherto been standardized. In addition, voicemail
        systems can now conform to the Voice Profile for Internet Messaging
        (VPIM v2 as defined in RFC 2421 [VPIM2] and being clarified for Draft
        Standard in [VPIMV2R2]) when forwarding messages to remote voicemail
        systems, but VPIM v2 was designed to allow two voicemail systems to
        exchange messages, not to allow a voicemail system to interoperate with
        a desktop e-mail client, and it is often not reasonable to expect a
        VPIM v2 message to be usable by an e-mail recipient. The result is
        messages which cannot be processed by the recipient (e.g., because of
        the encoding used), or look ugly to the user.

        This document therefore proposes a new standard mechanism for
        representing a voicemail message within SMTP/MIME, and a standard
        encoding for the audio content, which unified messaging systems and
        mail clients MUST implement to ensure interoperability. By using a
        standard SMTP/MIME representation, and a widely implemented audio
        encoding, this will also permit most users of e-mail clients not
        specifically implementing the standard to still access the voicemail
        message. In addition, this document describes features an e-mail client
        SHOULD implement to allow recipient's to display voicemail message in a
        more friendly, context sensitive way to the user, and intelligently
        provide some of the additional functionality typically found in
        voicemail systems (such as responding with a voice message instead of
        e-mail). Finally is explained how a client MAY provide a level of
        interoperability with VPIM v2.

        It is desirable that unified messaging mail clients also be able to
        fully interoperate with voicemail servers. This is possible today,
        providing the client implements VPIM v2 [VPIMV2] in addition to this
        specification, and uses it to construct messages to be sent to a
        voicemail server.

        The definition in this document is based on the IVM Requirements
        document [GOALS].  It references separate work on critical content
        [CRITICAL] and message context [HINT]. Addressing and directory issues
        are discussed in related documents [ADDRESS], [VPIMENUM], [SCHEMA].

          McRae & Parsons                 Expires:  19/02/01              2
     Internet Voice Messaging                                July 2001

        Further information on VPIM and related activities can be found at
        http://www.vpim.org or http://www.ema.org/vpim.

     4. Message Format

        Voice messages may be created explicitly by a user (e.g. recording a
        voicemail message in their mail client) or implicitly by a unified
        messaging system (when it records a telephone message).

        All messages MUST conform with the Internet Mail format, as updated by
        the DRUMS working group [DRUMSIMF].

        The message header SHOULD indicate a message context of "voice-message"
        (see [HINT]).

        If the receiving user agent identifies the message as a voice message
        (from the message context), it MAY present it to the user as a voice
        message rather than as an electronic mail message with a voice
        attachment (see [BEHAVIOUR]).

        Any content type is permitted in a message, but the top level content
        type on origination of a new, forwarded or reply voice message SHOULD
        be multipart/mixed. If the recipient is known to be VPIM v2 compliant
        then multipart/voice-message MAY be used instead (in which case all the
        provisions of [VPIMV2R2] MUST be implemented in constructing the

        If the message was created as a voice message, then the appropriate
        audio body part SHOULD be indicated as critical content, via a
        Criticality parameter of CRITICAL on the Content-Disposition (see
        [CRITICAL]). Additional important body parts (such as the original
        audio message if a voicemail is being forwarded) SHOULD also indicated
        via a Criticality of CRITICAL. Contents which are not essential to
        communicating the meaning of the message (e.g., an associated vCard for
        the originator) MAY be indicated via a Criticality of IGNORE.

        The top level content type on origination of a delivery notification
        message MUST be multipart/report. This will allow automatic processing
        of the delivery notification - for example, so that text-to-speech
        processing can render a non-delivery notification in the appropriate
        language for the recipient.

     5. Transport

        The message MUST be transmitted in accordance with the Simple Mail
        Transport Protocol, as updated by the DRUMS working group [DRUMSMTP].

          McRae & Parsons                 Expires:  19/02/01              3
     Internet Voice Messaging                                July 2001

        Delivery Status Notifications SHOULD be requested [DSN] if delivery of
        the message is important to the originator.

     6. Addressing

        Any valid Internet Mail address may be used for a voice message.

        It is desirable to be able to use and onramp/offramp for delivery of a
        voicemail message to a user, which will result in specific addressing
        requirements, based on service selectors as defined in [SELECTOR].
        Further discussion of addressing requirements for voice messages can be
        found in the VPIM Addressing document [ADDRESS].

        It is desirable to permit the use of a directory service to map between
        the E.164 phone number of the recipient and an SMTP mailbox address. A
        discussion on how this may be achieved using the ENUM infrastructure is
        in [VPIMENUM].  A definition of the VPIM LDAP schema that a system
        would use is found in [SCHEMA].

        If a message is created and stored as a result of call answering, the
        callerÆs name and number MAY be stored in the message headers in its
        original format per [CLID].

     7. Notifications

        Delivery Status Notifications MUST be supported.  All non-delivery of
        messages MUST result in a NDN, if requested [DSN]. If the receiving
        system is unable to process all of the critical media types within a
        voice message (indicated by the content criticality), then it MUST non-
        deliver the entire message per [CRITICAL].

        Message Disposition Notifications SHOULD be supported (but according to
        MDN rules the user MUST be given the option of deciding whether MDNs
        are returned) per [MDN].

        If the recipient is unable to display all of the indicated critical
        content components indicated, then it SHOULD give the user the option
        of returning an appropriate MDN (see [CRITICAL]).

     8. Voice Contents

        Voice messages may be contained at any location within a message and
        SHOULD always be contained in either an audio/wav or audio/basic
        content-type.  The only exception is when the originator is aware that

          McRae & Parsons                 Expires:  19/02/01              4
     Internet Voice Messaging                                July 2001

        the recipient can handle other content. Specifically, Audio/32kadpcm
        MAY be used when the recipient is known to support VPIM v2 [VPIMV2].

        The VOICE parameter on Content-Disposition from VPIM v2 [VPIMV2] SHOULD
        be used to identify the any spoken names or spoken subjects (as
        distinct from voice message contents).

        The originator's spoken name SHOULD be included with messages as
        separate audio contents, if known, and indicated by the Content-
        Disposition VOICE parameter as defined in VPIM v2 [VPIMV2]. If there is
        a single recipient for the message, their spoken name MAY also be
        included (per VPIM v2). A spoken subject MAY also be provided (per VPIM

        A sending implementation MAY determine the recipient capabilities
        before sending a message and choose a codec accordingly (e.g., using
        some form of content negotiation).  In the absence of such recipient
        knowledge, sending implementations MUST use either: MS-GSM with a WAV
        header - indicated via "audio/wav; codec=31" [MSGSM],[WAV]; or raw
        G.711 mu-law -                     - indicated via "audio/basic" [G711],[MIME2]. A sending
        implementation MAY support interoperability with VPIM v2 [VPIMV2], in
        which case it MUST be able to record G.726 (indicated as

        Recipients MUST be able to play both a WAV encapsulated MS-GSM and a
        raw G.711 mu-law message, and MAY be able to play G.726 (indicated as
        audio/32kadpcm) to provide interoperability with VPIM v2.  A receiving
        implementation MAY also be able to play messages encoded with other
        codecs (either natively or via transcoding).

        These requirements may be summarized as follows:

           Codec           No VPIM v2 Support      With VPIM V2 Support
                           Record    Playback      Record      Playback
           -------------   ------    --------      ------      --------
           MS-GSM in WAV    MAY*      MUST          MAY*        MUST
           G.711 mu-law     MAY*      MUST          MAY*        MUST
           G.726            MAY       MAY           MUST        MUST
           Other            MAY       MAY           MAY         MAY

                      *MUST record at least one

     9. Fax Contents

        Fax contents SHOULD be carried according to RFC 2532 [IFAX].

     10. Interoperability with VPIM v2

          McRae & Parsons                 Expires:  19/02/01              5
     Internet Voice Messaging                                July 2001

        The above text provides some guidelines as to how to ensure that a VPIM
        v2 message arriving on at a compliant mail system might be rendered
        useful to the recipient. However, a thorough investigation of how full
        interoperability might be provided between IVM and VPIM v2 systems is
        beyond the scope of this document.

     11. Security Considerations

        It is anticipated that there are no additional security issues beyond
        those identified in VPIM v2 [VPIMV2R2].

          McRae & Parsons                 Expires:  19/02/01              6
     Internet Voice Messaging                                July 2001

     12. References

        [ADDRESS] Parsons, G., "VPIM Addressing", <draft-ietf-vpim-address-
        01.txt>, April 2001, Work in Progress.

        [ADPCM] G. Vaudreuil and G. Parsons, "Toll Quality Voice - 32 kbit/s
        ADPCM:  MIME Sub-type Registration", RFC 2422, September 1998.  Revised
        by:  <draft-ietf-vpim-vpimv2r2-32k-01.txt>, June 2001.

        [BEHAVIOUR] Parsons, G., Maruszak, J., "Voice Messaging Client
        Behaviour", <draft-ema-vpim-cb-02.txt>, July 2001, Work in Progress.

        [CLID] Parsons, G., Maruszak, J., "Calling Line Identification for VPIM
        Messages", <draft-ema-vpim-clid-02.txt>, June 2001, Work in Progress.

        [CRITICAL] Burger, E., Candell, E., "Critical Content of Internet Mail"
        <draft-burger-vpim-cc-04.txt>, April 2001, Work in Progress.

        [DSN] Moore, K., "SMTP Service Extension for Delivery Status
        Notifications" RFC 1891, January 1996.

        [DRUMSMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821 ,
        April 2001.

        [DRUMSIMF] Resnick, P., "Internet Message Format", RFC 2822, April

        [GOALS] Candell, E., "Goals for Internet Voice Mail", <draft-ietf-vpim-
        ivm-goals-03.txt>, April 2001, Work in Progress.

        [G726] 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).

        [G711] ITU-T Recommendation G.711 (1993), General Aspects of Digital
        Transmission Systems, Terminal Equipment - Pulse Code Modulation (PCM)
        of Voice Frequencies.

        [HINT]  Burger, E., Candell, E., Eliot, C., Klyne, G. "Message Context
        Internet Mail" <draft-ietf-vpim-hint-07.txt>, June 2001, Work in

        [IFAX] Masinter, L., Wing, D. "Extended Facsimile Using Internet Mail",
        RFC 2532, March 1999.

        [KEYWORDS] Bradner, S., "Key Words for use in RFCs To Indicate
        Requirement Levels", RFC 2119, March 1997.

        [MIME1] Freed, N., Borenstein, N., "Multipurpose Internet Mail
        Extensions (MIME) Part One: Format of Internet Message Bodies", RFC
        2045, November 1996.

          McRae & Parsons                 Expires:  19/02/01              7
     Internet Voice Messaging                                July 2001

        [MIME2] N. Freed and N. Borenstein,  "Multipurpose Internet Mail
        Extensions (MIME) Part Two: Media Types ", RFC 2046, Innosoft, First
        Virtual, November 1996.

        [MSGSM]   Di Silvestro, L., Hedberg, E., Baribault, G., "Microsoft GSM
        MIME Sub-type Registration" <draft-ema-vpim-wav-00.txt>, April 1999,
        Work in Progress (expired).

        [SELECTOR] Allocchio, C., "Minimal PSTN address format in Internet
        Mail", RFC 2303, March 1998.

        [SCHEMA] Brown, A., Vaudreuil, G. "Voice Messaging Directory
        Service",<draft-ietf-vpim-vpimdir-01.txt> , July 2000, Work in Progress

        [VPIMENUM] Vaudreuil, G. "Voice Message Routing Service", <draft-ietf-
        vpim-routing-01.txt> , July 2000, Work in Progress (expired).

        [VPIMV2]   Vaudreuil, G., Parsons, G., "Voice Profile for Internet Mail
        -  version 2", RFC 2421, September 1998.

        [VPIMV2R2]   Vaudreuil, G., Parsons, G., "Voice Profile for Internet
        Mail - version 2", <draft-ietf-vpim-vpimv2r2-03.txt>, June 2001, Work
        in Progress.

        [WAV]   Di Silvestro, L., Baribault, G., "Waveform Audio File Format
        MIME Sub-type Registration" <draft-ema-vpim-wav-00.txt>, April 1999,
        Work in Progress (expired).

     13. Author's Addresses

        Stuart J. McRae
        Lotus Development
        43 Seymour Gardens
        Twickenham, United Kingdom
        TW1 3AR

        Phone: +44 208 891 1896
        Fax: +44 1784 499 112
        Email: stuart_mcrae@lotus.com

        Glenn W. Parsons
        Nortel Networks
        P.O. Box 3511, Station C
        Ottawa, ON K1Y 4H7

          McRae & Parsons                 Expires:  19/02/01              8
     Internet Voice Messaging                                July 2001

        Phone: +1-613-763-7582
        Fax: +1-416-597-7005
        Email: gparsons@nortelnetworks.com

          McRae & Parsons                 Expires:  19/02/01              9
     Internet Voice Messaging                                July 2001

     14.  Full Copyright Statement

        Copyright (C) The Internet Society (2001).  All Rights Reserved.

        This document and translations of it may be copied and furnished to
        others, and derivative works that comment on or otherwise explain it or
        assist in its implementation may be prepared, copied, published and
        distributed, in whole or in part, without restriction of any kind,
        provided that the above copyright notice and this paragraph are
        included on all such copies and derivative works.  However, this
        document itself may not be modified in any way, such as by removing the
        copyright notice or references to the Internet Society or other
        Internet organizations, except as needed for the purpose of developing
        Internet standards in which case the procedures for copyrights defined
        in the Internet Standards process must be followed, or as required to
        translate it into languages other than English.

        The limited permissions granted above are perpetual and will not be
        revoked by the Internet Society or its successors or assigns.

        This document and the information contained herein is provided on an

         McRae & Parsons                 Expires:  19/02/01              10

Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/