Network Working Group                                           S. McRae
Request for Comments: 4239                                           IBM
Category: Standards Track                                     G. Parsons
                                                         Nortel Networks
                                                           November 2005
Network Working Group                                           S. McRae
Request for Comments: 4239                                           IBM
Category: Standards Track                                     G. Parsons
                                                         Nortel Networks
                                                           November 2005

Internet Voice Messaging (IVM)


Status of This Memo


This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

本文件规定了互联网社区的互联网标准跟踪协议,并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态,请参考当前版本的“互联网官方协议标准”(STD 1)。本备忘录的分发不受限制。

Copyright Notice


Copyright (C) The Internet Society (2005).




This document describes 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 is not a successor format to VPIM v2 (Voice Profile for Internet Mail Version 2), but rather an alternative specification for a different application.

本文档中描述的互联网语音消息(IVM)概念不是VPIM v2(互联网邮件版本2的语音配置文件)的后续格式,而是不同应用程序的替代规范。

1. Introduction
1. 介绍

For some forms of communication, people prefer to communicate using their voices rather than typing. By permitting voicemail to be implemented in an interoperable way on top of Internet Mail, voice messaging and electronic mail no longer need to remain in separate, isolated worlds, and users will be able to choose the most appropriate form of communication. This will also enable new types of devices, 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 that 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 [VPIMV2] and revised in RFC 3801, Draft Standard [VPIMV2R2]) when forwarding messages to remote voicemail systems. 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. It is often not reasonable to expect a VPIM v2 message to be usable by an e-mail recipient. The result is messages that cannot be processed by the recipient (e.g., because of the encoding used), or look ugly to the user.

(RFC 2421[VPIMV2]中定义的VPIM v2和RFC 3801标准草案[VPIMV2R2]中修订的VPIM v2)转发消息到远程语音邮件系统时。VPIM v2旨在允许两个语音邮件系统交换消息,而不是允许语音邮件系统与桌面电子邮件客户端进行互操作。期望电子邮件收件人可以使用VPIM v2消息通常是不合理的。结果是收件人无法处理消息(例如,由于使用了编码),或者用户觉得消息很难看。

This document therefore proposes a 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 messages. In addition, this document describes features an e-mail client SHOULD implement to allow recipients to display voicemail messages 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, how a client MAY provide a level of interoperability with VPIM v2 is explained.

因此,本文档提出了一种标准机制,用于在SMTP/MIME中表示语音邮件消息,以及音频内容的标准编码,统一消息系统和邮件客户端必须实现该机制以确保互操作性。通过使用标准的SMTP/MIME表示和广泛实施的音频编码,这也将允许未具体实施该标准的电子邮件客户端的大多数用户仍然访问语音邮件消息。此外,本文档还介绍了电子邮件客户端应实现的功能,以允许收件人以更友好、上下文敏感的方式向用户显示语音邮件,并智能地提供语音邮件系统中常见的一些附加功能(例如,用语音邮件而不是电子邮件进行响应)。最后,解释了客户端如何提供与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 [VPIMV2R2], in addition to this specification, and uses it to construct messages to be sent to a voicemail server.

统一消息邮件客户端还需要能够与语音邮件服务器完全互操作。这在今天是可能的,前提是客户机除此规范外还实现了VPIM v2[VPIMV2R2],并使用它构造要发送到语音邮件服务器的消息。

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


Further information on VPIM and related activities can be found at or

有关VPIM和相关活动的更多信息,请访问 或

2. Conventions Used in This Document
2. 本文件中使用的公约

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


3. Message Format
3. 消息格式

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], and the MIME format [MIME1].


When creating a voice message from a client supporting IVM, the message header MUST indicate a message context of "voice-message" (see [HINT]). However, to support interoperability with clients not explicitly supporting IVM, a recipient MUST NOT require its presence in order to correctly process voice messages.


The receiving agent MUST be able to support multipart messages [MIME5]. If the receiving user agent identifies the message as a voice message (from the message context), it SHOULD 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 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 message).

消息中允许任何内容类型,但新的、转发的或回复语音消息的顶级内容类型应为多部分/混合。如果已知收件人符合VPIM v2,则可以使用多部分/语音消息(在这种情况下,在构建消息时必须执行[VPIMV2R2]的所有规定)。

If the message was created as a voice message, and so is not useful if the audio content is omitted, then the appropriate audio body part MUST 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) MAY also be indicated via a Criticality of CRITICAL. Contents that 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.


When forwarding IVM messages, clients MUST preserve the content type of all audio body parts in order to ensure that the new recipient is able to play the forwarded messages.


The top level content type, on origination of a delivery notification message, MUST be a 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.


4. Transport
4. 运输

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


Delivery Status Notifications MAY be requested [DSN] if delivery of the message is important to the originator and a mechanism exists to return status indications to them (which may not be possible for voicemail originators).


5. Addressing
5. 寻址

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


It is desirable to be able to use an onramp/offramp for delivery of a voicemail message to a user, which will result in specific addressing requirements, based on service selectors 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].

希望允许使用目录服务在收件人的E.164电话号码和SMTP邮箱地址之间进行映射。[VPIMENUM]中讨论了如何使用ENUM基础结构实现这一点。系统将使用的VPIM LDAP模式的定义可在[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].


6. Notifications
6. 通知

Delivery Status Notifications MUST be supported. All non-delivery of messages MUST result in an NDN, if requested [DSN, DSN2, DSN3, DSN4]. If the receiving system supports content criticality and 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]).


7. Voice Contents
7. 语音内容

Voice messages may be contained at any location within a message and MUST always be contained in an audio/basic content-type, unless the originator is aware that the recipient can handle other content. Specifically, Audio/32kadpcm MAY be used when the recipient is known to support VPIM v2 [VPIMV2R2].

语音消息可以包含在消息中的任何位置,并且必须始终包含在音频/基本内容类型中,除非发端人知道收件人可以处理其他内容。具体而言,当已知接收方支持VPIM v2[VPIMV2R2]时,可以使用音频/32kadpcm。

The VOICE parameter on Content-Disposition from VPIM v2 [VPIMV2R2] SHOULD be used to identify any spoken names or spoken subjects (as distinct from voice message contents). As well, the Content-Duration header [DUR] SHOULD be used to indicate the audio length.

VPIM v2[VPIMV2R2]中内容配置上的语音参数应用于识别任何语音名称或语音主题(与语音消息内容不同)。此外,应使用内容持续时间标题[DUR]来指示音频长度。

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

如果已知,发起者的口头姓名可以作为单独的音频内容包含在消息中,并且应该由VPIM v2[VPIMV2R2]中定义的内容配置语音参数指示。如果该邮件只有一个收件人,则还可能包括口头姓名(根据VPIM v2)。还可以提供口语主题(根据VPIM v2)。

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 raw G.711 mu-law, which is indicated with a MIME content type of "audio/basic" (and SHOULD use a filename parameter that ends ".au") [G711], [MIME2]. A sending implementation MAY support interoperability with VPIM v2 [VPIMV2R2], in which case, it MUST be able to record G.726 (indicated as audio/32kadpcm) [G726], [ADPCM].

发送实现可以在发送消息之前确定接收方能力,并相应地选择编解码器(例如,使用某种形式的内容协商)。在缺乏此类接收方知识的情况下,发送实现必须使用原始G.711 mu法则,该法则由MIME内容类型“audio/basic”表示(并且应使用以“.au”结尾的文件名参数“[G711],[MIME2]”。发送实现可能支持与VPIM v2[VPIMV2R2]的互操作性,在这种情况下,它必须能够录制G.726(表示为音频/32kadpcm)[G726],[ADPCM]。

Recipients MUST be able to play 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).

收件人必须能够播放原始G.711 mu-law消息,并且可能能够播放G.726(表示为音频/32kadpcm),以提供与VPIM v2的互操作性。接收实现还可以播放用其他编解码器编码的消息(本机或通过转码)。

These requirements may be summarized as follows:


   Codec           No VPIM v2 Support      With VPIM v2 Support
                   Record    Playback      Record      Playback
   -------------   ------    --------      ------      --------
   Codec           No VPIM v2 Support      With VPIM v2 Support
                   Record    Playback      Record      Playback
   -------------   ------    --------      ------      --------

G.711 mu-law MUST MUST MUST MUST G.726 * MAY MUST MUST Other * MAY * MAY

G.711 mu法律必须必须G.726*可能必须其他*可能*可能

* = MUST NOT, but MAY only if recipient capabilities known

* =不得,但仅当收件人能力已知时才可以

8. Fax Contents
8. 传真内容

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

传真内容应按照RFC 2532[IFAX]的规定进行。

9. Interoperability with VPIM v2
9. 与VPIM v2的互操作性

Interoperability between VPIM v2 systems and IVM systems can take a number of different forms. While a thorough investigation of how full interoperability might be provided between IVM and VPIM v2 systems is beyond the scope of this document; three key alternatives are discussed below.

VPIM v2系统和IVM系统之间的互操作性可以采取多种不同的形式。然而,对如何在IVM和VPIM v2系统之间提供完全互操作性的彻底调查超出了本文件的范围;下文讨论了三个关键备选方案。

9.1. Handling VPIM v2 Messages in an IVM Client
9.1. 在IVM客户端中处理VPIM v2消息

If an IVM-conformant client is able to process a content type of multipart/voice-message (by treating it as multipart/mixed) and play a G.726 encoded audio message within it (indicated by a content type of audio/32kadpcm), then a VPIM v2 message that gets routed to that desktop will be at least usable by the recipient.

如果符合IVM的客户端能够处理多部分/语音消息的内容类型(通过将其视为多部分/混合),并在其中播放G.726编码的音频消息(由音频/32kadpcm的内容类型指示),则路由到该桌面的VPIM v2消息将至少可供接收者使用。

This delivers a level of partial interoperability that would ease the life of end users. However, care should be taken to ensure that any attempt to reply to such a message does not result in an invalid VPIM v2 message being sent to a VPIM v2 system. Note that replying to an e-mail user who has forwarded a VPIM v2 message to you is, however, acceptable.

这提供了一定程度的部分互操作性,可以简化最终用户的生活。但是,应注意确保回复此类消息的任何尝试不会导致向VPIM v2系统发送无效的VPIM v2消息。请注意,回复已向您转发VPIM v2消息的电子邮件用户是可以接受的。

A conformant IVM implementation MUST NOT send a non-VPIM v2 message to something it knows to be a VPIM v2 system, unless it also knows that the destination system can handle such a message (even though VPIM v2 systems are encouraged to handle non-VPIM v2 messages in a graceful manner). In general, it must be assumed that if a system sends you a conformant VPIM v2 message, then it is a VPIM v2 system, and so you may only reply with a VPIM v2 compliant message (unless you know by some other means that the system supports IVM).

一致性IVM实现不得将非VPIM v2消息发送到其已知的VPIM v2系统,除非其也知道目标系统可以处理此类消息(即使鼓励VPIM v2系统以优雅的方式处理非VPIM v2消息)。通常,必须假设如果系统向您发送符合VPIM v2的消息,那么它就是VPIM v2系统,因此您只能使用符合VPIM v2的消息进行回复(除非您通过其他方式知道系统支持IVM)。

In addition, it should be noted that an IVM client may not fully conform to VPIM v2, even if it supports playing a G.726 message (e.g., it may not respect the handling of the Sensitivity field required by VPIM v2). This is one reason why VPIM v2 systems may choose not to route messages to any system they do not know to be VPIM v2 compliant.

此外,应注意,IVM客户端可能不完全符合VPIM v2,即使它支持播放G.726消息(例如,它可能不遵守VPIM v2要求的敏感度字段处理)。这就是为什么VPIM v2系统可能选择不将消息路由到他们不知道符合VPIM v2的任何系统的原因之一。

9.2. Dual Mode Systems and Clients
9.2. 双模式系统和客户端

A VPIM v2 system could be extended to also be able to support IVM compliant messages, and an IVM conformant client could be extended to implement VPIM v2 in full when corresponding with a VPIM v2 compliant

VPIM v2系统可以扩展到也能够支持符合IVM的消息,并且符合IVM的客户端可以扩展到在与符合VPIM v2的系统相对应时完全实现VPIM v2

system. This is simply a matter of implementing both specifications and selecting the appropriate one, depending on the received message content or the recipient's capabilities. This delivers full interoperability for the relevant systems, providing the capabilities of the target users can be determined.


Note that the mechanism for determining if a given recipient is using a VPIM v2 system or client is outside of the scope of this specification. Various mechanisms for capabilities discovery exist that could be applied to this problem, but no standard solution has yet been defined.

请注意,确定给定收件人是否使用VPIM v2系统或客户端的机制不在本规范的范围内。存在可应用于此问题的各种能力发现机制,但尚未定义标准解决方案。

9.3. Gateways
9.3. 通道

It would be possible to build a gateway linking a set of VPIM v2 users with a set of IVM users. This gateway would implement the semantics of the two worlds, and translate between them according to defined policies.

可以构建一个网关,将一组VPIM v2用户与一组IVM用户连接起来。这个网关将实现这两个世界的语义,并根据定义的策略在它们之间进行转换。

For example, VPIM v2 messages with a Sensitivity of Private might be rejected instead of forwarded to an IVM recipient, because it might not implement the semantics of a Private message, while an IVM message containing content not supported in VPIM v2 (e.g., a PNG image), with a Criticality of CRITICAL, would be rejected in the gateway.

例如,敏感度为Private的VPIM v2消息可能会被拒绝,而不是转发给IVM收件人,因为它可能无法实现私有消息的语义,而包含VPIM v2中不支持的内容(例如PNG图像)的关键性为CRITICAL的IVM消息将在网关中被拒绝。

Such a gateway MUST fully implement this specification and the VPIM v2 specification [VPIMV2R2], unless it knows somehow that the specific originators/recipients support capabilities beyond those required by these standards.

此类网关必须完全实施本规范和VPIM v2规范[VPIMV2R2],除非它不知何故知道特定的发起人/接收人支持超出这些标准要求的能力。

10. Security Considerations
10. 安全考虑

This document presents an optional gateway between IVM and VPIM systems. Gateways are inherently lossy systems and not all information can be accurately translated. This applies to both the transcoding of the voice and the translation of features. Two examples of feature translation are given in 9.3, but the risk remains that different gateways will handle the translation differently since it is undefined in this document. This may lead to unexpected behavior through gateways.


In addition, gateways present an additional point of attack for those interested in compromising a messaging system. If a gateway is compromised, "monkey in the middle" attacks, conducted from the compromised gateway, may be difficult to detect or appear to be authorized transformations.


Aside from the gateway issue, it is anticipated that there are no new additional security issues beyond those identified in VPIM v2 [VPIMV2R2] and in the other RFCs referenced by this document -- especially SMTP [DRUMSMTP], Internet Message Format [DRUMSIMF], MIME [MIME2], Critical Content [CRITICAL], and Message Context [HINT].

除网关问题外,预计除VPIM v2[VPIMV2R2]和本文件引用的其他RFC中确定的安全问题外,不会有新的其他安全问题——特别是SMTP[DRUMSMTP]、互联网消息格式[DrumsMF]、MIME[MIME2]、关键内容[Critical]和消息上下文[HINT]。

11. References
11. 工具书类
11.1. Normative References
11.1. 规范性引用文件

[ADDRESS] Parsons, G., "Voice Profile for Internet Mail (VPIM) Addressing", RFC 3804, June 2004.

[地址]Parsons,G.,“互联网邮件(VPIM)寻址的语音配置文件”,RFC 3804,2004年6月。

[ADPCM] Vaudreuil, G. and G. Parsons, "Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub-type Registration", RFC 3802, June 2004.

[ADPCM]Vaudreuil,G.和G.Parsons,“收费质量语音-32 kbit/s自适应差分脉冲编码调制(ADPCM)MIME子类型注册”,RFC 3802,2004年6月。

[BEHAVIOUR] Parsons, G. and J. Maruszak, "Voice Messaging Client Behaviour", RFC 4024, July 2005.

[Behavior]Parsons,G.和J.Maruszak,“语音信息客户端行为”,RFC 40242005年7月。

[CLID] Parsons, G. and J. Maruszak, "Calling Line Identification for Voice Mail Messages", RFC 3939, December 2004.

[CLID]Parsons,G.和J.Maruszak,“语音邮件的呼叫线路识别”,RFC 39392004年12月。

[CRITICAL] Burger, E., "Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter", RFC 3459, January 2003.

[关键]Burger,E.,“关键内容多用途互联网邮件扩展(MIME)参数”,RFC 3459,2003年1月。

[DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.

[DSN]Moore,K.,“用于传递状态通知(DSN)的简单邮件传输协议(SMTP)服务扩展”,RFC 34612003年1月。

[DSN2] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.

[DSN2]Vaudreuil,G.“邮件系统管理消息报告的多部分/报告内容类型”,RFC 3462,2003年1月。

[DSN3] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.

[DSN3]Vaudreuil,G.“增强邮件系统状态代码”,RFC 3463,2003年1月。

[DSN4] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.

[DSN4]Moore,K.和G.Vaudreuil,“交付状态通知的可扩展消息格式”,RFC 3464,2003年1月。

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

[Drusmtp]Klensin,J.,“简单邮件传输协议”,RFC 28212001年4月。

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

[DRUMSIMF]Resnick,P.,“互联网信息格式”,RFC 2822,2001年4月。

[DUR] Vaudreuil, G. and G. Parsons, "Content Duration MIME Header Definition", RFC 3803, June 2004.

[DUR]Vaudreuil,G.和G.Parsons,“内容持续时间MIME头定义”,RFC 3803,2004年6月。

[HINT] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message Context for Internet Mail", RFC 3458, January 2003.

[提示]Burger,E.,Candell,E.,Eliot,C.,和G.Klyne,“互联网邮件的消息上下文”,RFC 3458,2003年1月。

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

[IFAX]Masinter,L.和D.Wing,“使用互联网邮件的扩展传真”,RFC 25321999年3月。

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[关键词]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

[MDN] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.

[MDN]Hansen,T.和G.Vaudreuil,“消息处置通知”,RFC 3798,2004年5月。

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

[MIME1]Freed,N.和N.Borenstein,“多用途Internet邮件扩展(MIME)第一部分:Internet邮件正文格式”,RFC 20451996年11月。

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

[MIME2]Freed,N.和N.Borenstein,“多用途Internet邮件扩展(MIME)第二部分:媒体类型”,RFC 20461996年11月。

[MIME5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.

[MIME5]Freed,N.和N.Borenstein,“多用途Internet邮件扩展(MIME)第五部分:一致性标准和示例”,RFC 2049,1996年11月。

[SELECTOR] Allocchio, C., "Minimal GSTN address format in Internet Mail", RFC 3191, October 2001.


[SCHEMA] Vaudreuil, G., "Voice Messaging Directory Service", RFC 4237, October 2005.

[SCHEMA]Vaudreuil,G.“语音信息目录服务”,RFC 4237,2005年10月。

[VPIMENUM] Vaudreuil, G., "Voice Message Routing Service", RFC 4238, October 2005.

[VPIMENUM]Vaudreuil,G.,“语音消息路由服务”,RFC 4238,2005年10月。

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

[VPIMV2]Vaudreuil,G.和G.Parsons,“互联网邮件语音配置文件-第2版”,RFC 24211998年9月。

[VPIMV2R2] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.

[VPIMV2R2]Vaudreuil,G.和G.Parsons,“互联网邮件语音配置文件-第2版(VPIMv2)”,RFC 38012004年6月。

11.2. Informative References
11.2. 资料性引用

[GOALS] Candell, E., "High-Level Requirements for Internet Voice Mail", RFC 3773, June 2004.

[目标]Candell,E.“互联网语音邮件的高层次要求”,RFC 37732004年6月。

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

[G726]CCITT建议G.726(1990),数字传输系统的一般方面,终端设备-40,32,24,16 kbit/s自适应差分脉冲编码调制(ADPCM)。

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


Authors' Addresses


Stuart J. McRae IBM Lotus Park, The Causeway< Staines, TW18 3AG United Kingdom

Stuart J.McRae IBM莲花公园,堤道<Staines,TW18 3AG英国

   Phone: +44 1784 445 112
   Fax: +44 1784 499 112
   Phone: +44 1784 445 112
   Fax: +44 1784 499 112

Glenn W. Parsons Nortel Networks 3500 Carling Avenue Ottawa, ON K2H 8E9 Canada

加拿大K2H 8E9渥太华卡林大道3500号格伦·W·帕森斯北电网络公司

   Phone: +1-613-763-7582
   Fax: +1-613-967-5060
   Phone: +1-613-763-7582
   Fax: +1-613-967-5060

Full Copyright Statement


Copyright (C) The Internet Society (2005).


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.

本文件受BCP 78中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。



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.

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息,请参见BCP 78和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


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




Funding for the RFC Editor function is currently provided by the Internet Society.