Network Working Group G. Vaudreuil
Request for Comments: 3802 Lucent Technologies
Obsoletes: 2422 G. Parsons
Category: Standards Track Nortel Networks
June 2004
Network Working Group G. Vaudreuil
Request for Comments: 3802 Lucent Technologies
Obsoletes: 2422 G. Parsons
Category: Standards Track Nortel Networks
June 2004
Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub-type Registration
长途质量语音-32 kbit/s自适应差分脉冲编码调制（ADPCM）MIME子类型注册
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 (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document describes the registration of the MIME sub-type audio/32KADPCM Adaptive Differential Pulse Code Modulation for toll quality audio. This audio encoding is defined by the ITU-T in Recommendation G.726.
本文档描述了MIME子类型audio/32KADPCM自适应差分脉冲编码调制在收费质量音频中的注册。该音频编码由ITU-T在建议G.726中定义。
This document describes the registration of the MIME sub-type audio/32KADPCM for toll quality audio. This audio encoding is defined by the ITU-T in Recommendation G.726. This document obsoletes an earlier sub-type registration contained in RFC 1911. This document also obsoletes RFC 2422.
本文档描述了为toll quality audio注册MIME子类型audio/32KADPCM。该音频编码由ITU-T在建议G.726中定义。本文件废除了RFC 1911中包含的早期子类型注册。本文件还废除了RFC 2422。
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 [REQ].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[REQ]中的说明进行解释。
Recommendation G.726 [G726] defines the characteristics that are recommended for the conversion of a 64 kbit/s A-law or m-law pulse code modulation (PCM) channel at 8000 samples/second to and from a 40, 32, 24 or 16 kbit/s channel. The conversion is applied to the PCM bit stream using an adaptive differential pulse code modulation (ADPCM) transcoding technique. This Recommendation obsoletes G.721 which only defined the 32 kbit/s characteristics.
建议G.726[G726]定义了建议以8000个采样/秒的速度将64 kbit/s a律或m律脉冲编码调制（PCM）信道转换为40、32、24或16 kbit/s信道的特性。该转换使用自适应差分脉冲编码调制（ADPCM）转码技术应用于PCM比特流。本建议废除了仅定义32 kbit/s特性的G.721。
Recommendation G.726 was prepared by Study Group 15 of the Telecommunications Standardization Sector of the International Telecommunication Union (ITU-T) and was approved under the ITU's Resolution No. 2 procedure on the 14 of December 1990.
建议G.726由国际电信联盟（ITU-T）电信标准化部门第15研究组编写，并于1990年12月14日根据ITU第2号决议程序获得批准。
CCITT Recommendation G.726 [G726] describes the algorithm recommended for conversion of a 64 kbit/s A-law or u-law PCM channel to and from a 32 kbit/s channel (this is the same algorithm as described in the deprecated G.721). The conversion is applied to the PCM stream using an Adaptive Differential Pulse Code Modulation (ADPCM) transcoding technique.
CCITT建议G.726[G726]描述了建议用于将64 kbit/s a律或u律PCM信道转换为32 kbit/s信道和从32 kbit/s信道转换为64 kbit/s a律或u律PCM信道的算法（这与不推荐使用的G.721中描述的算法相同）。该转换使用自适应差分脉冲编码调制（ADPCM）转码技术应用于PCM流。
The MIME sub-type audio/32KADPCM is defined to hold binary audio data encoded in 32 kbit/s ADPCM exactly as defined by ITU-T Recommendation G.726. No header information shall be included as part of the audio data. The content transfer encoding is typically either binary or base64.
MIME子类型audio/32KADPCM被定义为完全按照ITU-T建议G.726的定义保存以32kbit/s ADPCM编码的二进制音频数据。不得将标题信息作为音频数据的一部分。内容传输编码通常为二进制或base64。
An additional consideration that this document defines for clarity is the choice of little endian ordering of the four bit code words. This default ordering is defined in ITU-T Recommendation X.420 [X420] for the equivalent X.400 body part, but is also detailed below in the IANA Registration.
为清晰起见，本文档定义的另一个考虑事项是选择四位码字的小端排序。该默认顺序在ITU-T建议X.420[X420]中针对等效X.400车身部件进行了定义，但在IANA注册中也有详细说明。
The audio/32KADPCM sub-type is a primary component of the VPIM specification [VPIM]. In this context, the Content-Description and Content-Disposition headers are used to succinctly describe the contents of the audio body. As well, only the little endian bit ordering is valid. Refer to the VPIM Specification for proper usage.
音频/32KADPCM子类型是VPIM规范[VPIM]的主要组件。在此上下文中，内容描述和内容处置头用于简洁地描述音频主体的内容。同样，只有小端位排序是有效的。有关正确使用方法，请参阅VPIM规范。
To: ietf-types@iana.org
Subject: Registration of MIME media type audio/32KADPCM
To: ietf-types@iana.org
Subject: Registration of MIME media type audio/32KADPCM
MIME media type name: audio
MIME媒体类型名称：音频
MIME subtype name: 32KADPCM
MIME子类型名称：32KADPCM
Required parameters: none
所需参数：无
Optional parameters: none
可选参数：无
Encoding considerations:
编码注意事项：
Binary or Base-64 generally preferred
通常首选二进制或Base-64
Security considerations:
安全考虑：
There are no known security risks with the sending or playing of raw audio data Audio data is typically interpreted only by an audio codec. Unintended information introduced into the data stream will result in noise.
发送或播放原始音频数据不存在已知的安全风险。音频数据通常仅由音频编解码器解释。引入数据流的非预期信息将导致噪声。
Interoperability considerations:
互操作性注意事项：
The four bit code word ordering within a byte may differ between existing implementations of G.726 codecs. Since this content only permits the little endian ordering, codecs that support the opposite ordering must reorder the code words before storing to or retrieving from this content type.
一个字节内的四位码字顺序在G.726编解码器的现有实现之间可能有所不同。由于该内容仅允许小端排序，因此支持相反排序的编解码器必须在存储到该内容类型或从中检索之前对码字进行重新排序。
Published specification:
已发布的规范：
ITU-T G.726 with little endian ordering
具有小端序的ITU-T G.726
Applications which use this media type:
使用此媒体类型的应用程序：
Primarily voice messaging
主要是语音信息
Additional information:
其他信息：
Magic number(s): ? File extension(s): .726 Macintosh File Type
Code(s): APCM
Magic number(s): ? File extension(s): .726 Macintosh File Type
Code(s): APCM
Little Endian Ordering:
小端序：
The 4-bit code words of the G.726 encoding MUST be packed into octets/bytes as follows: the first code word (A) is placed in the four least significant bits of the first octet, with the least significant bit (LSB) of the code word (A0) in the least significant bit of the octet; the second code word (B) is placed in the four most significant bits of the first octet, with the most significant bit (MSB) of the code word (B3) in the most significant bit of the octet. Subsequent pairs of the code words shall be packed in the same way into successive octets, with the first code word of each pair placed in the least significant four bits of the octet. It is preferred that the voice sample be extended with silence such that the encoded value comprises an even number of code words. However, if the voice sample comprises an odd number of code words, then the last code word shall be discarded.
G.726编码的4位码字必须按如下方式打包成八位字节/字节：第一个码字（A）放在第一个八位字节的四个最低有效位，码字（A0）的最低有效位（LSB）放在八位字节的最低有效位；第二个码字（B）位于第一个八位字节的四个最高有效位，码字（B3）的最高有效位（MSB）位于八位字节的最高有效位。随后的码字对应以相同方式打包成连续的八位字节，每对码字的第一个码字放在八位字节的最低有效四位。优选地，语音样本以静默方式扩展，使得编码值包括偶数个码字。但是，如果语音样本包含奇数个码字，则应丢弃最后一个码字。
+--+--+--+--+--+--+--+--+
|B3|B2|B1|B0|A3|A2|A1|A0|
+--+--+--+--+--+--+--+--+
MSB -> | 7| 6| 5| 4| 3| 2| 1| 0| <- LSB
+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+
|B3|B2|B1|B0|A3|A2|A1|A0|
+--+--+--+--+--+--+--+--+
MSB -> | 7| 6| 5| 4| 3| 2| 1| 0| <- LSB
+--+--+--+--+--+--+--+--+
32K ADPCM / Octet Mapping
32K ADPCM/八位组映射
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Glenn W. Parsons gparsons@NortelNetworks.com
格伦·W·帕森斯gparsons@NortelNetworks.com
Gregory M. Vaudreuil GregV@ieee.org
格雷戈里·M·沃德鲁伊GregV@ieee.org
Intended usage: COMMON
预期用途：普通
Author/Change controller:
作者/变更控制员：
Glenn W. Parsons & Gregory M. Vaudreuil
格伦·W·帕森斯和格雷戈里·M·沃德鲁伊
There are no known security risks with the sending or playing of raw audio data Audio data is typically interpreted only by an audio codec. Unintended information introduced into the data stream will result in noise.
发送或播放原始音频数据不存在已知的安全风险。音频数据通常仅由音频编解码器解释。引入数据流的非预期信息将导致噪声。
[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）。
[VPIM2R2] Vaudreuil, G., and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
[VPIM2R2]Vaudreuil，G.和G.Parsons，“互联网邮件语音配置文件-第2版（VPIMv2）”，RFC 38012004年6月。
[REQ] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[REQ]Bradner，S.，“在RFC中用于指示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC 3023] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC 3023]Murata，M.，St.Laurent，S.和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[VPIM1] Vaudreuil, G., "Voice Profile for Internet Mail", RFC 1911, February 1996.
[VPIM1]Vaudreuil，G.，“互联网邮件的语音模式”，RFC 19111996年2月。
[VPIM2] Vaudreuil, G., and G. Parsons, "Voice Profile for Internet Mail - version 2", RFC 2421, September 1998.
[VPIM2]Vaudreuil，G.和G.Parsons，“互联网邮件语音配置文件-第2版”，RFC 24211998年9月。
[X420] ITU-T Recommendation X.420 (1996) - ISO/IEC 10021-7:1996, Message handling systems: Interpersonal messaging.
[X420]ITU-T建议X.420（1996）-ISO/IEC 10021-7:1996，信息处理系统：人际信息。
Only editorial and boilerplate changes from RFC 2422 have been made to this document.
本文件仅作了RFC 2422的编辑和样板更改。
Gregory M. Vaudreuil Lucent Technologies 7291 Williamson Rd Dallas, TX 75214 United States
Gregory M.Vaudreuil-Lucent Technologies美国德克萨斯州达拉斯威廉森路7291号，邮编75214
EMail: gregv@ieee.org
EMail: gregv@ieee.org
Glenn W. Parsons Nortel Networks P.O. Box 3511, Station C Ottawa, ON K1Y 4H7 Canada
加拿大K1Y 4H7渥太华C站Glenn W.Parsons Nortel Networks邮政信箱3511
Phone: +1-613-763-7582
Fax: +1-613-763-2697
EMail: gparsons@nortelnetworks.com
Phone: +1-613-763-7582
Fax: +1-613-763-2697
EMail: gparsons@nortelnetworks.com
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.
版权所有（C）互联网协会（2004年）。本文件受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编辑功能的资金目前由互联网协会提供。