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)
互联网语音信息（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).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document describes the carriage of voicemail messages over Internet mail as part of a unified messaging infrastructure.
本文档描述了作为统一消息基础架构的一部分，通过Internet邮件传输语音邮件的过程。
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的语音配置文件）的后续格式，而是不同应用程序的替代规范。
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.
对于某些形式的交流，人们更喜欢用自己的声音交流，而不是打字。通过允许语音邮件以可互操作的方式在Internet邮件之上实现，语音消息和电子邮件不再需要保持在单独、孤立的世界中，用户将能够选择最合适的通信形式。这也将使不带键盘的新型设备能够在移动、敌对环境或残疾情况下参与电子信息传递。
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
存在使用SMTP/MIME通过Internet传输语音邮件的统一消息系统，但这些系统缺乏互操作性，因为此类消息的各个方面迄今尚未标准化。此外，语音邮件系统现在可以符合Internet消息的语音配置文件
(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].
本文件中的定义基于IVM需求文件[目标]。它引用了关于关键内容[critical]和消息上下文[HINT]的单独工作。寻址和目录问题在相关文档[ADDRESS]、[VPIMENUM]、[SCHEMA]中讨论。
Further information on VPIM and related activities can be found at http://www.vpim.org or http://www.ema.org/vpim.
有关VPIM和相关活动的更多信息，请访问http://www.vpim.org 或http://www.ema.org/vpim.
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC-2119[关键词]中所述进行解释。
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].
所有邮件必须符合由DRUMSMF工作组更新的Internet邮件格式和MIME格式[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.
从支持IVM的客户端创建语音消息时，消息头必须指示“语音消息”的消息上下文（请参阅[提示]）。但是，为了支持与不明确支持IVM的客户端的互操作性，收件人必须不要求其在场才能正确处理语音消息。
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]).
接收代理必须能够支持多部分消息[MIME5]。如果接收用户代理将消息标识为语音消息（来自消息上下文），则应将其作为语音消息而不是带有语音附件的电子邮件消息呈现给用户（请参见[行为]）。
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.
如果消息是作为语音消息创建的，因此如果省略了音频内容则没有用处，则必须通过内容配置上的临界参数critical（临界）将适当的音频主体部分指示为临界内容（参见[临界]）。其他重要的身体部位（如语音邮件转发时的原始音频信息）也可以通过关键信息的关键程度来指示。对于传达信息的含义而言不重要的内容（例如，发端人的相关vCard）可通过忽略的关键性来指示。
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.
转发IVM消息时，客户端必须保留所有音频正文部分的内容类型，以确保新收件人能够播放转发的消息。
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.
发送通知邮件时的顶级内容类型必须是多部分/报告。例如，这将允许自动处理传递通知，以便文本到语音处理可以为收件人以适当的语言呈现未传递通知。
The message MUST be transmitted in accordance with the Simple Mail Transport Protocol, as updated by the DRUMS working group [DRUMSMTP].
消息必须按照简单邮件传输协议传输，该协议由DRUMSTP工作组更新。
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).
如果消息的传递对发端人很重要，并且存在向其返回状态指示的机制（这对于语音邮件发端人来说可能是不可能的），则可以请求发送状态通知[DSN]。
Any valid Internet Mail address may be used for a voice message.
任何有效的Internet邮件地址都可以用于语音消息。
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].
根据[SELECTOR]中定义的服务选择器，希望能够使用入站/出站向用户发送语音邮件消息，这将导致特定的寻址要求。语音消息寻址要求的进一步讨论可在VPIM寻址文档[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].
如果由于电话应答而创建和存储了一条消息，则呼叫者的姓名和号码可能会按照[CLID]以其原始格式存储在消息头中。
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].
必须支持传递状态通知。如果请求，所有未送达的邮件都必须生成NDN[DSN、DSN2、DSN3、DSN4]。如果接收系统支持内容关键性，并且无法处理语音消息中的所有关键媒体类型（由内容关键性指示），则必须根据[关键性]不交付整个消息。
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].
根据[MDN]，应该支持消息处置通知（但根据MDN规则，必须为用户提供决定是否返回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]).
如果收件人无法显示所有指定的关键内容组件，则应向用户提供返回适当MDN的选项（请参见[关键]）。
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
* =不得，但仅当收件人能力已知时才可以
Fax contents SHOULD be carried according to RFC 2532 [IFAX].
传真内容应按照RFC 2532[IFAX]的规定进行。
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系统之间提供完全互操作性的彻底调查超出了本文件的范围；下文讨论了三个关键备选方案。
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的任何系统的原因之一。
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系统或客户端的机制不在本规范的范围内。存在可应用于此问题的各种能力发现机制，但尚未定义标准解决方案。
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]，除非它不知何故知道特定的发起人/接收人支持超出这些标准要求的能力。
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.
本文档介绍了IVM和VPIM系统之间的可选网关。网关本质上是有损系统，并非所有信息都能准确转换。这适用于语音转码和特征翻译。9.3中给出了两个功能翻译示例，但风险仍然存在，不同的网关将以不同的方式处理翻译，因为本文档中未定义。这可能会通过网关导致意外行为。
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]。
[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.
[SELECTOR]Allocchio，C.，“互联网邮件中的最小GSTN地址格式”，RFC3191，2001年10月。
[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月。
[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.
[G711]ITU-T建议G.711（1993），数字传输系统的一般方面，终端设备-语音频率的脉冲编码调制（PCM）。
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
EMail: stuart.mcrae@uk.ibm.com
Phone: +44 1784 445 112
Fax: +44 1784 499 112
EMail: stuart.mcrae@uk.ibm.com
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
EMail: gparsons@nortel.com
Phone: +1-613-763-7582
Fax: +1-613-967-5060
EMail: gparsons@nortel.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（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中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
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 http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。