RFC3802 日本語訳
3802 Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse CodeModulation (ADPCM) MIME Sub-type Registration. G. Vaudreuil, G.Parsons. June 2004. (Format: TXT=11686 bytes) (Obsoletes RFC2422) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Vaudreuil
Request for Comments: 3802 Lucent Technologies
Obsoletes: 2422 G. Parsons
Category: Standards Track Nortel Networks
June 2004
コメントを求めるワーキンググループG.ボードルイの要求をネットワークでつないでください: 3802 ルーセントテクノロジーズは以下を時代遅れにします。 2422年のG.教区牧師カテゴリ: 規格は2004年6月にノーテルネットワークを追跡します。
Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code
Modulation (ADPCM) MIME Sub-type Registration
料金Quality Voice--32kbit/s Adaptive Differentialパルスコードの変調(ADPCM)MIME Sub-タイプRegistration
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(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サブタイプオーディオ/32KADPCM Adaptive Differentialパルスコードの変調の登録について説明します。 このオーディオコード化はITU-TによってRecommendation G.726で定義されます。
1. Introduction
1. 序論
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.
このドキュメントは料金品質のためのMIMEサブタイプオーディオ/32KADPCMオーディオの登録について説明します。 このオーディオコード化はITU-TによってRecommendation G.726で定義されます。 このドキュメントはRFC1911に含まれた以前のサブタイプ登録を時代遅れにします。 また、このドキュメントはRFC2422を時代遅れにします。
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[REQ]で説明されるように本書では解釈されることであるべきですか?
Vaudreuil, et al. Standards Track [Page 1] RFC 3802 32 kbit/s ADPCM June 2004
ボードルイ、他 規格Track[1ページ]RFC3802 32s ADPCM2004年kbit/6月
2. ITU-T Definition
2. ITU-T定義
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]は64s A-法かm kbit/法のパルス符号変調(PCM)チャンネルの変換のために8000サンプル/秒でチャンネルと40、32、24または16kbit/sチャンネルから推薦される特性を定義します。 変換は、適応差分パルス符号変調方式(ADPCM)コード変換のテクニックを使用することでPCMビットストリームに適用されます。 このRecommendationは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)のTelecommunications Standardization SectorのStudy Group15によって準備されて、1990年の14年12月にITUのResolution No.2手順の下で承認されました。
3. MIME Definition
3. MIME定義
3.1. audio/32KADPCM
3.1. オーディオ/32KADPCM
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 Recommendation G.726[G726]は64kbit/s A-法かu-法のPCMチャンネルの変換のためにチャンネルと32kbit/sチャンネルから推薦されたアルゴリズムを説明します(これは推奨しないG.721で説明されるように同じアルゴリズムです)。 変換は、Adaptive Differentialパルスコードの変調(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サブタイプオーディオ/32KADPCMは、ちょうどITU-T Recommendation G.726によって定義されるように2進のオーディオデータが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.
このドキュメントが明快ために定義する追加的約因は4つのビット・コード単語のリトルエンディアン注文の選択です。 このデフォルト注文も、ITU-T Recommendation X.420[X420]で同等なX.400身体の部分と定義されますが、また、IANA Registrationで以下で詳細です。
3.2. VPIM Usage
3.2. VPIM用法
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]の第一の構成要素です。 このような関係においては、Content-記述とContent-気質ヘッダーは、簡潔にオーディオボディーのコンテンツについて説明するのに使用されます。 また、リトルエンディアンの噛み付いている注文だけが有効です。 適切な用法についてVPIM Specificationを参照してください。
Vaudreuil, et al. Standards Track [Page 2] RFC 3802 32 kbit/s ADPCM June 2004
ボードルイ、他 規格Track[2ページ]RFC3802 32s ADPCM2004年kbit/6月
4. IANA Registration
4. IANA登録
To: ietf-types@iana.org
Subject: Registration of MIME media type audio/32KADPCM
To: ietf-types@iana.org Subject: MIMEメディアタイプオーディオ/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.
発信があるセキュリティ危険が知られていないか、または生のオーディオデータAudioデータのプレーはオーディオコーデックだけによって通常解釈されます。データ・ストリームに取り入れられる故意でない情報は騒音上結果として生じるでしょう。
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.
1バイト以内で注文される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
マジックナンバー(s): ? ファイル拡張子(s): .726 マッキントッシュファイルタイプは(s)をコード化します: APCM
Vaudreuil, et al. Standards Track [Page 3] RFC 3802 32 kbit/s ADPCM June 2004
ボードルイ、他 規格Track[3ページ]RFC3802 32s ADPCM2004年kbit/6月
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つの最下位ビットに置かれます、八重奏の最下位ビットにおける婉曲的表現(A0)の最下位ビット(LSB)で。 2番目の婉曲的表現(B)は最初の八重奏の4つの最上位ビットに置かれます、婉曲的表現(B3)の八重奏の最も重要なビットで最も重要なビット(MSB)で。 同様に、婉曲的表現のその後の組は連続した八重奏に詰め込まれるものとします、それぞれの組の最初の婉曲的表現が八重奏の最も重要でない4ビットに置かれている状態で。 声のサンプルが沈黙で広げられるのが好ましいので、コード化された値は婉曲的表現の偶数を包括します。 しかしながら、声のサンプルが婉曲的表現の奇数を含むなら、最後の婉曲的表現は捨てられるものとします。
+--+--+--+--+--+--+--+--+
|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:
詳細のために連絡する人とEメールアドレス:
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.ボードルイ
5. Security Considerations
5. セキュリティ問題
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.
発信があるセキュリティ危険が知られていないか、または生のオーディオデータAudioデータのプレーはオーディオコーデックだけによって通常解釈されます。データ・ストリームに取り入れられる故意でない情報は騒音上結果として生じるでしょう。
Vaudreuil, et al. Standards Track [Page 4] RFC 3802 32 kbit/s ADPCM June 2004
ボードルイ、他 規格Track[4ページ]RFC3802 32s ADPCM2004年kbit/6月
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[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 Recommendation G.726(1990)、Digital Transmission Systems、Terminal EquipmentのAspects司令官--40、32、24、16kbit/s Adaptive Differentialパルスコードの変調(ADPCM)。
[VPIM2R2] Vaudreuil, G., and G. Parsons, "Voice Profile for Internet
Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
[VPIM2R2] ボードルイ、G.、およびG.パーソンズ、「インターネットメールのためにProfileを声に出してください--バージョン2(VPIMv2)」、RFC3801、6月2004日
[REQ] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[REQ] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
6.2. Informative References
6.2. 有益な参照
[RFC 3023] Murata, M., St. Laurent, S. and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC3023] ムラタとM.と聖ローランとS.とD.コーン、「XMLメディアタイプ」、RFC3023、2001年1月。
[VPIM1] Vaudreuil, G., "Voice Profile for Internet Mail", RFC
1911, February 1996.
[VPIM1] ボードルイ、G.、「インターネットメールのための声のプロフィール」、RFC1911、1996年2月。
[VPIM2] Vaudreuil, G., and G. Parsons, "Voice Profile for Internet
Mail - version 2", RFC 2421, September 1998.
[VPIM2] ボードルイ、G.、およびG.パーソンズは「バージョン2インチ、RFC2421、1998年インターネットメール--9月のためにProfileを声に出します」。
[X420] ITU-T Recommendation X.420 (1996) - ISO/IEC 10021-7:1996,
Message handling systems: Interpersonal messaging.
[X420]ITU-T Recommendation X.420(1996)--ISO/IEC10021-7:1996、Message取り扱いシステム: 個人間のメッセージング。
7. Changes from RFC 2422
7. RFC2422からの変化
Only editorial and boilerplate changes from RFC 2422 have been made to this document.
RFC2422からの社説と決まり文句の変更だけをこのドキュメントにしました。
Vaudreuil, et al. Standards Track [Page 5] RFC 3802 32 kbit/s ADPCM June 2004
ボードルイ、他 規格Track[5ページ]RFC3802 32s ADPCM2004年kbit/6月
8. Authors' Addresses
8. 作者のアドレス
Gregory M. Vaudreuil Lucent Technologies 7291 Williamson Rd Dallas, TX 75214 United States
グレゴリーM.ボードルイルーセントテクノロジーズ7291ウィリアムソン・テキサス75214第ダラス(合衆国)
EMail: gregv@ieee.org
メール: gregv@ieee.org
Glenn W. Parsons Nortel Networks P.O. Box 3511, Station C Ottawa, ON K1Y 4H7 Canada
グレンW.ノーテル教区牧師は私書箱3511、駅のCオタワをK1Y 4H7カナダにネットワークでつなぎます。
Phone: +1-613-763-7582 Fax: +1-613-763-2697 EMail: gparsons@nortelnetworks.com
以下に電話をしてください。 +1-613-763-7582 Fax: +1-613-763-2697 メールしてください: gparsons@nortelnetworks.com
Vaudreuil, et al. Standards Track [Page 6] RFC 3802 32 kbit/s ADPCM June 2004
ボードルイ、他 規格Track[6ページ]RFC3802 32s ADPCM2004年kbit/6月
9. Full Copyright Statement
9. 完全な著作権宣言文
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Vaudreuil, et al. Standards Track [Page 7]
ボードルイ、他 標準化過程[7ページ]
一覧
スポンサーリンク
