[要約] 要約： RFC 3802は、32 kbit/sのADPCM（Adaptive Differential Pulse Code Modulation）を使用したトールクオリティの音声通信に関するMIMEサブタイプの登録について説明しています。目的： このRFCの目的は、ADPCMを使用した音声通信の品質を向上させるために、適切なMIMEサブタイプを定義し、その使用方法を指定することです。
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）The Internet Society（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適応性微分パルスコードモジュレーションの登録について説明します。このオーディオエンコーディングは、推奨G.726のITU-Tによって定義されます。
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サブタイプのオーディオ/32KADPCMの登録について説明します。このオーディオエンコーディングは、推奨G.726のITU-Tによって定義されます。このドキュメントは、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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[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]は、64 kbit/s a-lawまたはm-law pulseコード変調（PCM）チャネルの40、32、24から8000サンプル/秒の変換に推奨される特性を定義します。または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-lawまたはu-law pcmチャネルの変換に推奨されるアルゴリズムを32 kbit/sチャネルとの間で説明しています（これは、非難された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で定義されているように、32 KBIT/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.
このドキュメントが明確に定義する追加の考慮事項は、4つのビットコードワードのリトルエンディアン注文の選択です。このデフォルトの順序付けは、同等のX.400ボディパーツのITU-T推奨x.420 [x420]で定義されていますが、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.
Audio/32KADPCMサブタイプは、VPIM仕様[VPIM]の主要なコンポーネントです。これに関連して、コンテンツデスプトリーとコンテンツディスポジションヘッダーを使用して、オーディオ本体のコンテンツを簡潔に説明します。同様に、リトルエンディアンビット注文のみが有効です。適切な使用については、VPIM仕様を参照してください。
To: ietf-types@iana.org Subject: Registration of MIME media type audio/32KADPCM
宛先：ietf-types@iana.org件名：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
一般的にバイナリまたはベース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.
バイト内の4ビットコードの語順は、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
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）は、最初のオクテットの4つの最も有意なビットに配置され、最小有意ビット（LSB）で配置されます。オクテットの最も重要なビットのコードワード（A0）の。2番目のコードワード（b）は、最初のオクテットの4つの最も重要なビットに配置され、オクテットの最も重要なビットにコードワード（B3）の最も重要なビット（MSB）があります。コードワードの後続のペアは、同じ方法で連続したオクテットに詰められ、各ペアの最初のコードワードは、オクテットの最も重要な4ビットに配置されます。エンコードされた値が偶数のコードワードを含むように、音声サンプルを沈黙とともに拡張することが望ましい。ただし、音声サンプルが奇数のコードワードを含む場合、最後のコードワードは破棄されます。
+--+--+--+--+--+--+--+--+
|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
Glenn W. Parsons gparsons@nortelnetworks.com
Gregory M. Vaudreuil GregV@ieee.org
Gregory M. Vaudreuil 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、「インターネットメールの音声プロファイル-Version 2（VPIMV2）」、RFC 3801、2004年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 Media Types」、RFC 3023、2001年1月。
[VPIM1] Vaudreuil, G., "Voice Profile for Internet Mail", RFC 1911, February 1996.
[VPIM1] Vaudreuil、G。、「インターネットメールの音声プロファイル」、RFC 1911、1996年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 2421、1998年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 Williamson Rd Dallas、TX 75214米国
EMail: gregv@ieee.org
Glenn W. Parsons Nortel Networks P.O. Box 3511, Station C Ottawa, ON K1Y 4H7 Canada
グレン・W・パーソンズ・ノルテル・ネットワークP.O.ボックス3511、ステーションCオタワ、K1Y 4H7カナダ
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）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。