Internet Voice Messaging (IVM)
Extracted elements (28)
IVM mandates G.711 mu-law (audio/basic) as the default codec because it is widely implemented, allowing most email clients not specifically implementing IVM to still access voicemail messages without transcoding.
Recipients must not require the 'voice-message' context header to process voice messages, preserving interoperability with clients not explicitly implementing IVM.
The top-level content type for delivery notifications is required to be multipart/report (rather than a simpler type) to enable automatic processing, such as text-to-speech rendering of NDNs in the recipient's language.
An IVM client that can process multipart/voice-message as multipart/mixed and play G.726 audio achieves partial VPIM v2 interoperability, but must not reply to a VPIM v2 system with a non-VPIM v2 message.
Dual-mode systems implementing both IVM and VPIM v2 and selecting the appropriate format based on recipient capabilities achieve full interoperability. The mechanism for determining recipient capabilities is outside the scope of this document.
IVM is not a successor to VPIM v2 but an alternative for a different application (desktop/unified messaging vs. voicemail-to-voicemail). VPIM v2 was designed for voicemail system interchange, not voicemail-to-email-client interoperability.
A conformant IVM implementation MUST NOT send a non-VPIM v2 message to a system it knows to be VPIM v2, unless it also knows that destination can handle such a message.
All voice messages MUST conform with the Internet Mail format as updated by the DRUMS working group and the MIME format.
An IVM/VPIM gateway MUST fully implement both this specification and the VPIM v2 specification, unless it knows the specific originators/recipients support capabilities beyond those required.
Delivery Status Notifications MUST be supported; all non-delivery of messages MUST result in an NDN if requested. If critical media types cannot be processed, the entire message MUST be non-delivered.
If a voice message is not useful without audio content, the appropriate audio body part MUST be indicated as critical content via a Criticality parameter of CRITICAL on the Content-Disposition.
In the absence of recipient capability knowledge, sending implementations MUST use raw G.711 mu-law (MIME type audio/basic, SHOULD use filename ending in '.au'). A VPIM v2 interoperable implementation MUST also support G.726 (audio/32kadpcm).
Message Disposition Notifications SHOULD be supported, but per MDN rules the user MUST be given the option of deciding whether MDNs are returned.
Recipients MUST be able to play raw G.711 mu-law messages and MAY be able to play G.726 (audio/32kadpcm) for VPIM v2 interoperability.
The message MUST be transmitted in accordance with the Simple Mail Transport Protocol as updated by the DRUMS working group.
The receiving agent MUST be able to support multipart messages. If the message is identified as a voice message, it SHOULD be presented to the user as a voice message rather than as email with a voice attachment.
The top level content type on a new, forwarded, or reply voice message SHOULD be multipart/mixed. If the recipient is known to be VPIM v2 compliant, multipart/voice-message MAY be used instead.
The top level content type on origination of a delivery notification message MUST be multipart/report, to allow automatic processing such as text-to-speech rendering of non-delivery notifications.
Voice messages MUST always be contained in an audio/basic content-type unless the originator is aware the recipient can handle other content. Audio/32kadpcm MAY be used when the recipient is known to support VPIM v2.
When creating a voice message from an IVM client, the message header MUST indicate a message context of 'voice-message', but a recipient MUST NOT require its presence to correctly process voice messages.
When forwarding IVM messages, clients MUST preserve the content type of all audio body parts to ensure the new recipient can play the forwarded messages.
Fax contents SHOULD be carried according to RFC 2532 (Extended Facsimile Using Internet Mail).
The caller's name and number MAY be stored in message headers in original format per RFC 3939 (Calling Line Identification for Voice Mail Messages) when a message is created as a result of call answering.
The Criticality parameter on Content-Disposition is used to mark essential body parts: CRITICAL for required audio content, IGNORE for non-essential content such as an originator vCard.
The message context header value 'voice-message' (per RFC 3458) is used to identify IVM voice messages, enabling clients to present them appropriately to the user.
The VOICE parameter on Content-Disposition (from VPIM v2) SHOULD be used to identify spoken names or spoken subjects as distinct from voice message contents. Content-Duration SHOULD indicate audio length.
Gateways between IVM and VPIM v2 are inherently lossy and may handle feature translation inconsistently (e.g., Sensitivity fields, unsupported content types), leading to unexpected behavior and potential security policy violations.
Gateways present an additional attack surface; a compromised gateway can conduct man-in-the-middle attacks that may appear to be authorized transformations and are difficult to detect.