[要約] RFC 7655は、G.711.0のRTPペイロード形式に関する仕様です。このRFCの目的は、G.711.0コーデックを使用したリアルタイム通信のための効率的なデータ転送を提供することです。
Internet Engineering Task Force (IETF) M. Ramalho, Ed.
Request for Comments: 7655 P. Jones
Category: Standards Track Cisco Systems
ISSN: 2070-1721 N. Harada
NTT
M. Perumal
Ericsson
L. Miao
Huawei Technologies
November 2015
RTP Payload Format for G.711.0
G.711.0のRTPペイロード形式
Abstract
概要
This document specifies the Real-time Transport Protocol (RTP) payload format for ITU-T Recommendation G.711.0. ITU-T Rec. G.711.0 defines a lossless and stateless compression for G.711 packet payloads typically used in IP networks. This document also defines a storage mode format for G.711.0 and a media type registration for the G.711.0 RTP payload format.
このドキュメントでは、ITU-T勧告G.711.0のReal-time Transport Protocol（RTP）ペイロード形式を指定しています。 ITU-T Rec。 G.711.0は、IPネットワークで通常使用されるG.711パケットペイロードのロスレスおよびステートレス圧縮を定義しています。このドキュメントでは、G.711.0のストレージモード形式と、G.711.0 RTPペイロード形式のメディアタイプ登録も定義しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7655.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7655で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. G.711.0 Codec Background . . . . . . . . . . . . . . . . . . 4
3.1. General Information and Use of the ITU-T G.711.0 Codec . 4
3.2. Key Properties of G.711.0 Design . . . . . . . . . . . . 6
3.3. G.711 Input Frames to G.711.0 Output Frames . . . . . . . 8
3.3.1. Multiple G.711.0 Output Frames per RTP Payload
Considerations . . . . . . . . . . . . . . . . . . . 9
4. RTP Header and Payload . . . . . . . . . . . . . . . . . . . 10
4.1. G.711.0 RTP Header . . . . . . . . . . . . . . . . . . . 10
4.2. G.711.0 RTP Payload . . . . . . . . . . . . . . . . . . . 12
4.2.1. Single G.711.0 Frame per RTP Payload Example . . . . 12
4.2.2. G.711.0 RTP Payload Definition . . . . . . . . . . . 13
4.2.2.1. G.711.0 RTP Payload Encoding Process . . . . . . 14
4.2.3. G.711.0 RTP Payload Decoding Process . . . . . . . . 15
4.2.4. G.711.0 RTP Payload for Multiple Channels . . . . . . 17
5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 19
5.1. Media Type Registration . . . . . . . . . . . . . . . . . 20
5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 22
5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 22
5.4. SDP Examples . . . . . . . . . . . . . . . . . . . . . . 23
5.4.1. SDP Example 1 . . . . . . . . . . . . . . . . . . . . 23
5.4.2. SDP Example 2 . . . . . . . . . . . . . . . . . . . . 23
6. G.711.0 Storage Mode Conventions and Definition . . . . . . . 24
6.1. G.711.0 PLC Frame . . . . . . . . . . . . . . . . . . . . 24
6.2. G.711.0 Erasure Frame . . . . . . . . . . . . . . . . . . 25
6.3. G.711.0 Storage Mode Definition . . . . . . . . . . . . . 26
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9. Congestion Control . . . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . 30
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 31
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
The International Telecommunication Union (ITU-T) Recommendation G.711.0 [G.711.0] specifies a stateless and lossless compression for G.711 packet payloads typically used in Voice over IP (VoIP) networks. This document specifies the Real-time Transport Protocol (RTP) RFC 3550 [RFC3550] payload format and storage modes for this compression.
国際電気通信連合（ITU-T）勧告G.711.0 [G.711.0]は、Voice over IP（VoIP）ネットワークで通常使用されるG.711パケットペイロードのステートレスおよびロスレス圧縮を指定しています。このドキュメントでは、この圧縮のリアルタイムトランスポートプロトコル（RTP）RFC 3550 [RFC3550]ペイロード形式とストレージモードを指定します。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
ITU-T Recommendation G.711.0 [G.711.0] is a lossless and stateless compression mechanism for ITU-T Recommendation G.711 [G.711] and thus is not a "codec" in the sense of "lossy" codecs typically carried by RTP. When negotiated end-to-end, ITU-T Rec. G.711.0 is negotiated as if it were a codec, with the understanding that ITU-T Rec. G.711.0 losslessly encoded the underlying (lossy) G.711 Pulse Code Modulation (PCM) sample representation of an audio signal. For this reason, ITU-T Rec. G.711.0 will be interchangeably referred to in this document as a "lossless data compression algorithm" or a "codec", depending on context. Within this document, individual G.711 PCM samples will be referred to as "G.711 symbols" or just "symbols" for brevity.
ITU-T勧告G.711.0 [G.711.0]は、ITU-T勧告G.711 [G.711]のロスレスおよびステートレスの圧縮メカニズムであり、通常運ばれる「損失のある」コーデックという意味で「コーデック」ではありませんRTPによって。エンドツーエンドでネゴシエートされる場合、ITU-T Rec。 G.711.0は、コーデックであるかのように交渉され、ITU-T Rec。 G.711.0は、オーディオ信号の基になる（損失のある）G.711パルスコード変調（PCM）サンプル表現をロスレスエンコードしました。このため、ITU-T Rec。 G.711.0は、コンテキストに応じて、このドキュメントでは「ロスレスデータ圧縮アルゴリズム」または「コーデック」と同じ意味で呼ばれます。このドキュメントでは、簡潔にするために、個々のG.711 PCMサンプルを「G.711シンボル」または単に「シンボル」と呼びます。
This section describes the ITU-T Recommendation G.711 [G.711] codec, its properties, typical uses cases, and its key design properties.
このセクションでは、ITU-T勧告G.711 [G.711]コーデック、そのプロパティ、一般的な使用例、および主要な設計プロパティについて説明します。
ITU-T Recommendation G.711 is the benchmark standard for narrowband telephony. It has been successful for many decades because of its proven voice quality, ubiquity, and utility. A new ITU-T recommendation, G.711.0, has been established for defining a stateless and lossless compression for G.711 packet payloads typically used in VoIP networks. ITU-T Rec. G.711.0 is also known as ITU-T Rec. G.711 Annex A [G.711-A1], as ITU-T Rec. G.711 Annex A is effectively a pointer ITU-T Rec. G.711.0. Henceforth in this document, ITU-T Rec. G.711.0 will simply be referred to as "G.711.0" and ITU-T Rec. G.711 simply as "G.711".
ITU-T勧告G.711は、ナローバンドテレフォニーのベンチマーク標準です。実証済みの音声品質、ユビキタス、および実用性により、何十年もの間成功してきました。 VoIPネットワークで通常使用されるG.711パケットペイロードのステートレスおよびロスレス圧縮を定義するために、新しいITU-T勧告G.711.0が確立されました。 ITU-T Rec。 G.711.0はITU-T Recとしても知られています。 G.711 Annex A [G.711-A1]、ITU-T Rec。 G.711 Annex Aは、実質的にはポインタITU-T Recです。 G.711.0。以降、このドキュメントでは、ITU-T Rec。 G.711.0は、単に「G.711.0」およびITU-T Rec。 G.711は単に「G.711」と呼ばれます。
G.711.0 may be employed end-to-end, in which case the RTP payload format specification and use is nearly identical to the G.711 RTP specification found in RFC 3551 [RFC3551]. The only significant difference for G.711.0 is the required use of a dynamic payload type (the static PT of 0 or 8 is presently almost always used with G.711 even though dynamic assignment of other payload types is allowed) and the recommendation not to use Voice Activity Detection (see Section 4.1).
G.711.0はエンドツーエンドで使用できます。この場合、RTPペイロード形式の仕様と使用は、RFC 3551 [RFC3551]にあるG.711 RTP仕様とほぼ同じです。 G.711.0の唯一の重要な違いは、動的ペイロードタイプの使用が必要なことです（0または8の静的PTは、他のペイロードタイプの動的割り当てが許可されている場合でも、現在ほとんどの場合G.711で使用されます）。音声アクティビティ検出を使用します（セクション4.1を参照）。
G.711.0, being both lossless and stateless, may also be employed as a lossless compression mechanism for G.711 payloads anywhere between end systems that have negotiated use of G.711. Because the only significant difference between the G.711 RTP payload format header and the G.711.0 payload format header defined in this document is the payload type, a G.711 RTP packet can be losslessly converted to a G.711.0 RTP packet simply by compressing the G.711 payload (thus creating a G.711.0 payload), changing the payload type to the dynamic value desired and copying all the remaining G.711 RTP header fields into the corresponding G.711.0 RTP header. In a similar manner, the corresponding decompression of the G.711.0 RTP packet thus created back to the original source G.711 RTP packet can be accomplished by losslessly decompressing the G.711.0 payload back to the original source G.711 payload, changing the payload type back to the payload type of the original G.711 RTP packet and copying all the remaining G.711.0 RTP header fields into the corresponding G.711 RTP header. As a packet produced by the compression and decompression as described above is indistinguishable in every detail to the source G.711 packet, such compression can be made invisible to the end systems. Specification of how systems on the path between the end systems discover each other and negotiate the use of G.711.0 compression as described in this paragraph is outside the scope of this document.
ロスレスとステートレスの両方であるG.711.0は、G.711の使用をネゴシエートしたエンドシステム間のどこでも、G.711ペイロードのロスレス圧縮メカニズムとして使用できます。このドキュメントで定義されているG.711 RTPペイロード形式ヘッダーとG.711.0ペイロード形式ヘッダーの唯一の重要な違いはペイロードタイプであるため、G.711 RTPパケットは、次の方法でロスレスでG.711.0 RTPパケットに変換できます。 G.711ペイロードを圧縮し（したがってG.711.0ペイロードを作成）、ペイロードタイプを目的の動的な値に変更し、残りのすべてのG.711 RTPヘッダーフィールドを対応するG.711.0 RTPヘッダーにコピーします。同様に、このようにして作成された元のソースG.711 RTPパケットに戻すG.711.0 RTPパケットの対応する解凍は、ロスレスでG.711.0ペイロードを元のソースG.711ペイロードに復元し、ペイロードタイプを元のG.711 RTPパケットのペイロードタイプに戻し、残りのすべてのG.711.0 RTPヘッダーフィールドを対応するG.711 RTPヘッダーにコピーします。上記のように圧縮と解凍によって生成されたパケットは、ソースのG.711パケットと細部にわたって区別できないため、このような圧縮はエンドシステムから見えないようにすることができます。この段落で説明されているように、エンドシステム間のパス上のシステムが互いを検出し、G.711.0圧縮の使用をネゴシエートする方法の仕様は、このドキュメントの範囲外です。
It is informative to note that G.711.0, being both lossless and stateless, can be employed multiple times (e.g., on multiple, individual hops or series of hops) of a given flow with no degradation of quality relative to end-to-end G.711. Stated another way, multiple "lossless transcodes" from/to G.711.0/G.711 do not affect voice quality as typically occurs with lossy transcodes to/ from dissimilar codecs.
ロスレスとステートレスの両方であるG.711.0は、エンドツーエンドと比較して品質を低下させることなく、所定のフローの複数回（たとえば、複数の個別のホップまたは一連のホップで）使用できることに注意してください。 G.711。別の言い方をすれば、G.711.0 / G.711との間の複数の「ロスレストランスコード」は、通常、異なるコーデックとの間のロッシートランスコードで発生する音声品質に影響を与えません。
Lastly, it is expected that G.711.0 will be used as an archival format for recorded G.711 streams. Therefore, a G.711.0 Storage Mode Format is also included in this document.
最後に、記録されたG.711ストリームのアーカイブ形式としてG.711.0が使用されることが予想されます。したがって、G.711.0ストレージモードフォーマットもこのドキュメントに含まれています。
The fundamental design of G.711.0 resulted from the desire to losslessly encode and compress frames of G.711 symbols independent of what types of signals those G.711 frames contained. The primary G.711.0 use case is for G.711 encoded, zero-mean, acoustic signals (such as speech and music).
G.711.0の基本的な設計は、G.711フレームに含まれる信号のタイプとは関係なく、G.711シンボルのフレームをロスレスでエンコードおよび圧縮したいという要望から生まれました。 G.711.0の主要な使用例は、G.711エンコードされたゼロ平均音響信号（スピーチや音楽など）です。
G.711.0 attributes are below:
G.711.0の属性は次のとおりです。
A1 Compression for zero-mean acoustic signals: G.711.0 was designed as its primary use case for the compression of G.711 payloads that contained "speech" or other zero-mean acoustic signals. G.711.0 obtains greater than 50% average compression in service provider environments [ICASSP].
A1ゼロ平均音響信号の圧縮：G.711.0は、「音声」またはその他のゼロ平均音響信号を含むG.711ペイロードの圧縮の主な使用例として設計されました。 G.711.0は、サービスプロバイダー環境で50％を超える平均圧縮を取得します[ICASSP]。
A2 Lossless for any G.711 payload: G.711.0 was designed to be lossless for any valid G.711 payload - even if the payload consisted of apparently random G.711 symbols (e.g., a modem or FAX payload). G.711.0 could be used for "aggregate 64 kbps G.711 channels" carried over IP without explicit concern if a subset of these channels happened to be carrying something other than voice or general audio. To the extent that a particular channel carried something other than voice or general audio, G.711.0 ensured that it was carried losslessly, if not significantly compressed.
A2 G.711ペイロードのロスレス：G.711.0は、ペイロードが明らかにランダムなG.711シンボル（モデムやFAXペイロードなど）で構成されていても、有効なG.711ペイロードでロスレスになるように設計されています。 G.711.0は、これらのチャネルのサブセットがたまたま音声または一般的なオーディオ以外のものを運んでいた場合、明示的な懸念なしにIPを介して運ばれる「集約64 kbps G.711チャネル」に使用できます。 G.711.0は、特定のチャネルが音声または一般的なオーディオ以外のものを伝送する範囲で、大幅に圧縮されていなくても、損失なしで伝送されることを保証しました。
A3 Stateless: Compression of a frame of G.711 symbols was only to be dependent on that frame and not on any prior frame. Although greater compression is usually available by observing a longer history of past G.711 symbols, it was decided that the compression design would be stateless to completely eliminate error propagation common in many lossy codec designs (e.g., ITU-T Rec. G.729 [G.729] and ITU-T Rec. G.722 [G.722]). That is, the decoding process need not be concerned about lost prior packets because the decompression of a given G.711.0 frame is not dependent on potentially lost prior G.711.0 frames. Owing to this stateless property, the frames input to the G.711.0 encoder may be changed "on-the-fly" (a 5 ms encoding could be followed by a 20 ms encoding).
A3ステートレス：G.711シンボルのフレームの圧縮は、そのフレームにのみ依存し、以前のフレームには依存しませんでした。通常、過去のG.711シンボルのより長い履歴を観察することで、より大きな圧縮を利用できますが、多くの非可逆コーデック設計（ITU-T勧告G.729など）に共通するエラー伝搬を完全に排除するために、圧縮設計はステートレスであることが決定されました。 [G.729]およびITU-T Rec。G.722 [G.722]）。つまり、所定のG.711.0フレームの解凍は、失われた可能性のある以前のG.711.0フレームに依存しないため、デコードプロセスは失われた以前のパケットを考慮する必要はありません。このステートレスプロパティにより、G.711.0エンコーダーへのフレーム入力は「オンザフライ」で変更される可能性があります（5 msエンコーディングの後に20 msエンコーディングが続く可能性があります）。
A4 Self-describing: This property is defined as the ability to determine how many source G.711 samples are contained within the G.711.0 frame solely by information contained within the G.711.0 frame. Generally, the number of source G.711 symbols can be determined by decoding the initial octets of the compressed G.711.0 frame (these octets are called "prefix codes" in the standard). A G.711.0 decoder need not know how many symbols are contained in the original G.711 frame (e.g., parameter ptime in the Session Description Protocol (SDP) [RFC4566]), as it is able to decompress the G.711.0 frame presented to it without signaling knowledge.
A4自己記述型：このプロパティは、G.711.0フレーム内に含まれる情報のみによって、G.711.0フレーム内に含まれるソースG.711サンプルの数を決定する機能として定義されます。一般に、ソースG.711シンボルの数は、圧縮されたG.711.0フレームの最初のオクテットをデコードすることで決定できます（これらのオクテットは、規格では「プレフィックスコード」と呼ばれています）。 G.711.0デコーダーは、提示されたG.711.0フレームを解凍できるため、元のG.711フレームに含まれるシンボルの数（たとえば、Session Description Protocol（SDP）[RFC4566]のパラメーターptime）を知る必要はありません。知識を伝えることなく
A5 Accommodate G.711 payload sizes typically used in IP: G.711 input frames of length typically found in VoIP applications represent SDP ptime values of 5 ms, 10 ms, 20 ms, 30 ms, or 40 ms. Because the dominant sampling frequency for G.711 is 8000 samples per second, G.711.0 was designed to compress G.711 input frames of 40, 80, 160, 240, or 320 samples.
A5 IPで一般的に使用されるG.711ペイロードサイズに対応：VoIPアプリケーションで一般的に見られるG.711入力フレームは、5ミリ秒、10ミリ秒、20ミリ秒、30ミリ秒、または40ミリ秒のSDP ptime値を表します。 G.711の主要なサンプリング周波数は8000サンプル/秒であるため、G.711.0は、40、80、160、240、または320サンプルのG.711入力フレームを圧縮するように設計されています。
A6 Bounded expansion: Since attribute A2 above requires G.711.0 to be lossless for any payload (which could consist of any combination of octets with each octet spanning the entire space of 2^8 values), by definition there exists at least one potential G.711 payload that must be "uncompressible". Since the quantum of compression is an octet, the minimum expansion of such an uncompressible payload was designed to be the minimum possible of one octet. Thus, G.711.0 "compressed" frames can be of length one octet to X+1 octets, where X is the size of the input G.711 frame in octets. G.711.0 can therefore be viewed as a Variable Bit Rate (VBR) encoding in which the size of the G.711.0 output frame is a function of the G.711 symbols input to it.
A6制限付き拡張：上記の属性A2では、ペイロード（各オクテットが2 ^ 8値のスペース全体に及ぶオクテットの任意の組み合わせで構成されている可能性があります）に対してG.711.0がロスレスである必要があるため、定義により、少なくとも1つの潜在的なGが存在します。 「非圧縮」でなければならない.711ペイロード。圧縮の量子はオクテットであるため、そのような非圧縮ペイロードの最小拡張は、1オクテットの可能な限り最小になるように設計されました。したがって、G.711.0の「圧縮」フレームの長さは1オクテットからX + 1オクテットにすることができます。ここで、Xはオクテット単位の入力G.711フレームのサイズです。したがって、G.711.0は可変ビットレート（VBR）エンコーディングと見なすことができ、G.711.0出力フレームのサイズは、それに入力されるG.711シンボルの関数です。
A7 Algorithmic delay: G.711.0 was designed to have the algorithmic delay equal to the time represented by the number of samples in the G.711 input frame (i.e., no "look-ahead").
A7アルゴリズム遅延：G.711.0は、アルゴリズム遅延がG.711入力フレームのサンプル数で表される時間と同じになるように設計されています（つまり、「先読み」はありません）。
A8 Low Complexity: Less than 1.0 Weighted Million Operations Per Second (WMOPS) average and low memory footprint (~5k octets RAM, ~5.7k octets ROM, and ~3.6 basic operations) [ICASSP] [G.711.0].
A8低複雑性：1.0加重ミリオン操作/秒（WMOPS）の平均と低メモリフットプリント（〜5kオクテットRAM、〜5.7kオクテットROM、および〜3.6基本操作）[ICASSP] [G.711.0]。
A9 Both A-law and mu-law supported: G.711 has two operating laws, A-law and mu-law. These two laws are also known as PCMA and PCMU in RTP applications [RFC3551].
A9 A-lawとmu-lawの両方がサポートされています。G.711には、A-lawとmu-lawの2つの運用法があります。これら2つの法則は、RTPアプリケーションではPCMAおよびPCMUとしても知られています[RFC3551]。
These attributes generally make it trivial to compress a G.711 input frame consisting of 40, 80, 160, 240, or 320 samples. After the input frame is presented to a G.711.0 encoder, a G.711.0 "self-describing" output frame is produced. The number of samples contained within this frame is easily determined at the G.711.0 decoder by virtue of attribute A4. The G.711.0 decoder can decode the G.711.0 frame back to a G.711 frame by using only data within the G.711.0 frame.
これらの属性により、通常、40、80、160、240、または320個のサンプルで構成されるG.711入力フレームを圧縮するのは簡単です。入力フレームがG.711.0エンコーダーに提示された後、G.711.0の「自己記述型」出力フレームが生成されます。このフレーム内に含まれるサンプルの数は、属性A4によってG.711.0デコーダーで簡単に決定されます。 G.711.0デコーダは、G.711.0フレーム内のデータのみを使用して、G.711.0フレームをデコードしてG.711フレームに戻すことができます。
Lastly we note that losing a G.711.0 encoded packet is identical in effect to losing a G.711 packet (when using RTP); this is because a G.711.0 payload, like the corresponding G.711 payload, is stateless. Thus, it is anticipated that existing G.711 Packet Loss Concealment (PLC) mechanisms will be employed when a G.711.0 packet is lost and an identical MOS degradation relative to G.711 loss will be achieved.
最後に、G.711.0でエンコードされたパケットを失うことは、実質的にG.711パケットを失うことと同じです（RTPを使用する場合）。これは、対応するG.711ペイロードと同様に、G.711.0ペイロードがステートレスであるためです。したがって、G.711.0パケットが失われたときに既存のG.711パケット損失隠蔽（PLC）メカニズムが採用され、G.711損失と同じMOS劣化が達成されることが予想されます。
G.711.0 is a lossless and stateless compression of G.711 frames. Figure 1 depicts this where "A" is the process of G.711.0 encoding and "B" is the process of G.711.0 decoding.
G.711.0は、G.711フレームのロスレスおよびステートレス圧縮です。図1はこれを示しています。「A」はG.711.0エンコーディングのプロセスであり、「B」はG.711.0デコードのプロセスです。
|--------------------------| A |------------------------------|
| G.711 Input Frame |----->| G.711.0 Output Frame |
| of X Octets | | containing 1 to X+1 Octets |
| (where X MUST be 40, 80, | | (precise value dependent on |
| 160, 240, or 320 octets) |<-----| G.711.0 ability to compress) |
|__________________________| B |______________________________|
Figure 1: 1:1 Mapping from G.711 Input Frame to G.711.0 Output Frame
図1：G.711入力フレームからG.711.0出力フレームへの1：1マッピング
Note that the mapping is 1:1 (lossless) in both directions, subject to two constraints. The first constraint is that the input frame provided to the G.711.0 encoder (process "A") has a specific number of input G.711 symbols consistent with attribute A5 (40, 80, 160, 240, or 320 octets). The second constraint is that the companding law used to create the G.711 input frame (A-law or mu-law) must be known, consistent with attribute A9.
マッピングは両方向で1：1（ロスレス）であり、2つの制約があることに注意してください。最初の制約は、G.711.0エンコーダー（プロセス "A"）に提供される入力フレームに、属性A5（40、80、160、240、または320オクテット）と一致する特定の数の入力G.711シンボルがあることです。 2番目の制約は、G.711入力フレーム（A-lawまたはmu-law）の作成に使用される圧伸則が既知であり、属性A9と一致している必要があることです。
Subject to these two constraints, the input G.711 frame is processed by the G.711.0 encoder ("process A") and produces a "self-describing" G.711.0 output frame, consistent with attribute A4. Depending on the source G.711 symbols, the G.711.0 output frame can contain anywhere from 1 to X+1 octets, where X is the number of input G.711 symbols. Compression results for virtually every zero-mean acoustic signal encoded by G.711.0.
これら2つの制約に従って、入力G.711フレームはG.711.0エンコーダー（「プロセスA」）によって処理され、属性A4と一致する「自己記述型」G.711.0出力フレームを生成します。ソースG.711シンボルに応じて、G.711.0出力フレームには1〜X + 1オクテットのいずれかを含めることができます。Xは入力G.711シンボルの数です。 G.711.0によってエンコードされたほぼすべてのゼロ平均音響信号の圧縮結果。
Since the G.711.0 output frame is "self-describing", a G.711.0 decoder (process "B") can losslessly reproduce the original G.711 input frame with only the knowledge of which companding law was used (A-law or mu-law). The first octet of a G.711.0 frame is called the "Prefix Code" octet; the information within this octet conveys how many G.711 symbols the decoder is to create from a given G.711.0 input frame (i.e., 0, 40, 80, 160, 240, or 320). The Prefix Code value of 0x00 is used to denote zero G.711 source symbols, which allows the use of 0x00 as a payload padding octet (described later in Section 3.3.1).
G.711.0出力フレームは「自己記述型」であるため、G.711.0デコーダー（プロセス「B」）は、どの圧伸則が使用されたか（A-lawまたはmu-law）。 G.711.0フレームの最初のオクテットは「プレフィックスコード」オクテットと呼ばれます。このオクテット内の情報は、デコーダーが特定のG.711.0入力フレーム（つまり、0、40、80、160、240、または320）から作成するG.711シンボルの数を伝えます。プレフィックスコード値0x00は、G.711ソースシンボルがゼロであることを示すために使用されます。これにより、ペイロードパディングオクテットとして0x00を使用できます（セクション3.3.1で後述）。
Since G.711.0 was designed with typical G.711 payload lengths as a design constraint (attribute A5), this lossless encoding can be performed only with knowledge of the companding law being used. This information is anticipated to be signaled in SDP and is described later in this document.
G.711.0は、典型的なG.711ペイロード長を設計制約として使用して設計されているため（属性A5）、このロスレスエンコーディングは、使用されている圧伸則の知識がなければ実行できません。この情報は、SDPで通知されることが予想され、このドキュメントで後述します。
If the original inputs were known to be from a zero-mean acoustic signal coded by G.711, an intelligent G.711.0 encoder could infer the G.711 companding law in use (via G.711 input signal amplitude histogram statistics). Likewise, an intelligent G.711.0 decoder producing G.711 from the G.711.0 frames could also infer which encoding law is in use. Thus, G.711.0 could be designed for use in applications that have limited stream signaling between the G.711 endpoints (i.e., they only know "G.711 at 8k sampling is being used", but nothing more). Such usage is not further described in this document. Additionally, if the original inputs were known to come from zero-mean acoustic signals, an intelligent G.711.0 encoder could tell if the G.711.0 payload had been encrypted -- as the symbols would not have the distribution expected in either companding law and would appear random. Such determination is also not further discussed in this document.
元の入力がG.711によってコード化されたゼロ平均音響信号からのものであることがわかっている場合、インテリジェントなG.711.0エンコーダーがG.711圧伸則を使用していると推測できます（G.711入力信号振幅ヒストグラム統計を介して）。同様に、G.711.0フレームからG.711を生成するインテリジェントなG.711.0デコーダーも、どのエンコーディング法が使用されているかを推測できます。したがって、G.711.0は、G.711エンドポイント間のストリームシグナリングが制限されているアプリケーションで使用するように設計できます（つまり、「8kサンプリングでG.711が使用されている」ことだけがわかります）。このような使用法については、このドキュメントでは詳しく説明しません。さらに、元の入力がゼロ平均音響信号からのものであることがわかっている場合、インテリジェントG.711.0エンコーダーは、G.711.0ペイロードが暗号化されているかどうかを通知できます。ランダムに表示されます。このような決定についても、このドキュメントでは詳しく説明しません。
It is easily seen that this process is 1:1 and that lossless compression based on G.711.0 can be employed multiple times, as the original G.711 input symbols are always reproduced with 100% fidelity.
このプロセスは1：1であり、元のG.711入力シンボルは常に100％の忠実度で再現されるため、G.711.0に基づくロスレス圧縮を複数回使用できることが簡単にわかります。
As a general rule, G.711.0 frames containing more source G.711 symbols (from a given channel) will typically result in higher compression, but there are exceptions to this rule. A G.711.0 encoder may choose to encode 20 ms of input G.711 symbols as: 1) a single 20 ms G.711.0 frame, or 2) as two 10 ms G.711.0 frames, or 3) any other combination of 5 ms or 10 ms G.711.0 frames -- depending on which encoding resulted in fewer bits. As an example, an intelligent encoder might encode 20 ms of G.711 symbols as two 10 ms G.711.0 frames if the first 10 ms was "silence" and two G.711.0 frames took fewer bits than any other possible encoding combination of G.711.0 frame sizes.
一般的な規則として、（特定のチャネルからの）より多くのソースG.711シンボルを含むG.711.0フレームは、通常、より高い圧縮率になりますが、この規則には例外があります。 G.711.0エンコーダーは、20 msの入力G.711シンボルを次のようにエンコードすることを選択できます：1）単一の20 ms G.711.0フレーム、または2）2つの10 ms G.711.0フレームとして、または3）5の他の組み合わせmsまたは10 ms G.711.0フレーム-エンコーディングによってビット数が少なくなります。例として、最初の10ミリ秒が「無音」で、2つのG.711.0フレームが他のGの可能なエンコードの組み合わせよりも少ないビットを使用した場合、インテリジェントエンコーダーは20ミリ秒のG.711シンボルを2つの10ミリ秒G.711.0フレームとしてエンコードする可能性があります。 .711.0フレームサイズ。
During the process of G.711.0 standardization, it was recognized that although it is sometimes advantageous to encode integer multiples of 40 G.711 symbols in whatever input symbol format resulted in the most compression (as per above), the simplest choice is to encode the entire ptime's worth of input G.711 symbols into one G.711.0 frame (if the ptime supported it). This is especially so since the larger number of source G.711 symbols typically resulted in the highest compression anyway and there is added complexity in searching for other possibilities (involving more G.711.0 frames) that were unlikely to produce a more bit efficient result.
G.711.0の標準化の過程で、40のG.711シンボルの整数倍数を（上記のように）圧縮率が最も高い任意の入力シンボル形式でエンコードすると有利な場合がありますが、最も簡単な選択はエンコードすることです。 1つのG.711.0フレームへのptime全体の入力G.711シンボル（ptimeがサポートしている場合）。これは特にそうです。これは、ソースG.711シンボルの数が多いため、通常、いずれにせよ最高の圧縮が行われ、ビット効率の高い結果を生成する可能性が低い（より多くのG.711.0フレームを含む）他の可能性の検索がさらに複雑になるためです。
The design of ITU-T Rec. G.711.0 [G.711.0] foresaw the possibility of multiple G.711.0 input frames in that the decoder was defined to decode what it refers to as an incoming "bit stream". For this specification, the bit stream is the G.711.0 RTP payload itself. Thus, the decoder will take the G.711.0 RTP payload and will produce an output frame containing the original G.711 symbols independent of how many G.711.0 frames were present in it. Additionally, any number of 0x00 padding octets placed between the G.711.0 frames will be silently (and safely) ignored by the G.711.0 decoding process Section 4.2.3).
ITU-T Rec。のデザイン。 G.711.0 [G.711.0]は、デコーダが着信「ビットストリーム」と呼ばれるものをデコードするように定義されているため、複数のG.711.0入力フレームの可能性を予見していました。この仕様では、ビットストリームはG.711.0 RTPペイロード自体です。したがって、デコーダーはG.711.0 RTPペイロードを受け取り、G.711.0フレームがいくつ存在するかに関係なく、元のG.711シンボルを含む出力フレームを生成します。さらに、G.711.0フレームの間に配置された0x00パディングオクテットは、G.711.0のデコードプロセス（セクション4.2.3）によって静かに（そして安全に）無視されます。
To recap, a G.711.0 encoder may choose to encode incoming G.711 symbols into one or more than one G.711.0 frames and put the resultant frame(s) into the G.711.0 RTP payload. Zero or more 0x00 padding octets may also be included in the G.711.0 RTP payload. The G.711.0 decoder, being insensitive to the number of G.711.0 encoded frames that are contained within it, will decode the G.711.0 RTP payload into the source G.711 symbols. Although examples of single or multiple G.711 frame cases are illustrated in Section 4.2, the multiple G.711.0 frame cases MUST be supported and there is no need for negotiation (SDP or otherwise) required for it.
要約すると、G.711.0エンコーダーは、着信G.711シンボルを1つ以上のG.711.0フレームにエンコードし、結果のフレームをG.711.0 RTPペイロードに入れることを選択できます。ゼロ以上の0x00パディングオクテットもG.711.0 RTPペイロードに含めることができます。 G.711.0デコーダーは、その中に含まれるG.711.0エンコードされたフレームの数に影響されないため、G.711.0 RTPペイロードをソースG.711シンボルにデコードします。単一または複数のG.711フレームケースの例がセクション4.2に示されていますが、複数のG.711.0フレームケースがサポートされている必要があり、そのために必要なネゴシエーション（SDPまたはその他）は必要ありません。
In this section, we describe the precise format for G.711.0 frames carried via RTP. We begin with an RTP header description relative to G.711, then provide two G.711.0 payload examples.
このセクションでは、RTPを介して伝送されるG.711.0フレームの正確なフォーマットについて説明します。 G.711に関連するRTPヘッダーの説明から始め、次に2つのG.711.0ペイロードの例を示します。
Relative to G.711 RTP headers, the utilization of G.711.0 does not create any special requirements with respect to the contents of the RTP packet header. The only significant difference is that the payload type (PT) RTP header field MUST have a value corresponding to the dynamic payload type assigned to the flow. This is in contrast to most current uses of G.711 that typically use the static payload assignment of PT = 0 (PCMU) or PT = 8 (PCMA) [RFC3551] even though the negotiation and use of dynamic payload types is allowed for G.711. With the exception of rare PT exhaustion cases, the existing G.711 PT values of 0 and 8 MUST NOT be used for G.711.0 (helping to avoid possible payload confusion with G.711 payloads).
G.711 RTPヘッダーと比較して、G.711.0の使用は、RTPパケットヘッダーの内容に関して特別な要件を作成しません。唯一の重要な違いは、ペイロードタイプ（PT）RTPヘッダーフィールドが、フローに割り当てられた動的ペイロードタイプに対応する値を持つ必要があることです。これは、ダイナミックペイロードタイプのネゴシエーションと使用がGで許可されていても、通常はPT = 0（PCMU）またはPT = 8（PCMA）[RFC3551]のスタティックペイロード割り当てを使用するG.711のほとんどの現在の使用とは対照的です.711。まれなPT枯渇のケースを除いて、既存のG.711 PT値0および8はG.711.0に使用してはなりません（G.711ペイロードとの起こり得るペイロードの混同を回避するのに役立ちます）。
Voice Activity Detection (VAD) SHOULD NOT be used when G.711.0 is negotiated because G.711.0 obtains high compression during "VAD silence intervals" and one of the advantages of G.711.0 over G.711 with VAD is the lack of any VAD-inducing artifacts in the received signal. However, if VAD is employed, the Marker bit (M) MUST be set in the first packet of a talkspurt (the first packet after a silence period in which packets have not been transmitted contiguously as per rules specified in [RFC3551] for G.711 payloads). This definition, being consistent with the G.711 RTP VAD use, further allows lossless transcoding between G.711 RTP packets and G.711.0 RTP packets as described in Section 3.1.
ボイスアクティビティ検出（VAD）は、G.711.0が「VAD無音インターバル」中に高圧縮を取得するため、G.711.0がネゴシエートされる場合は使用しないでください。 -受信信号にアーティファクトを誘発する。ただし、VADが採用されている場合、マーカービット（M）はトークスパートの最初のパケット（Gの[RFC3551]で指定されたルールに従って連続的に送信されていない無音期間後の最初のパケット）に設定する必要があります。 711ペイロード）。この定義は、G.711 RTP VADの使用と一貫性があり、セクション3.1で説明されているように、G.711 RTPパケットとG.711.0 RTPパケット間のロスレストランスコーディングをさらに可能にします。
With this introduction, the RTP packet header fields are defined as follows:
この概要では、RTPパケットヘッダーフィールドは次のように定義されています。
V - As per [RFC3550]
V-[RFC3550]による
P - As per [RFC3550]
P-[RFC3550]による
X - As per [RFC3550]
X-[RFC3550]による
CC - As per [RFC3550]
CC-[RFC3550]による
M - As per [RFC3550] and [RFC3551]
M-[RFC3550]および[RFC3551]による
PT - The assignment of an RTP payload type for the format defined in this memo is outside the scope of this document. The RTP profiles in use currently mandate binding the payload type dynamically for this payload format (e.g., see [RFC3550] and [RFC4585]).
PT-このメモで定義されたフォーマットへのRTPペイロードタイプの割り当ては、このドキュメントの範囲外です。現在使用されているRTPプロファイルは、このペイロード形式に対してペイロードタイプを動的にバインドすることを義務付けています（たとえば、[RFC3550]および[RFC4585]を参照）。
SN - As per [RFC3550]
SN-[RFC3550]による
timestamp - As per [RFC3550]
タイムスタンプ-[RFC3550]による
SSRC - As per [RFC3550]
SSRC-[RFC3550]による
CSRC - As per [RFC3550]
CSRC-[RFC3550]による
V (version bits), P (padding bit), X (extension bit), CC (CSRC count), M (marker bit), PT (payload type), SN (sequence number), timestamp, SSRC (synchronizing source) and CSRC (contributing sources) are as defined in [RFC3550] and are as typically used with G.711. PT (payload type) is as defined in [RFC3551].
V（バージョンビット）、P（パディングビット）、X（拡張ビット）、CC（CSRCカウント）、M（マーカービット）、PT（ペイロードタイプ）、SN（シーケンス番号）、タイムスタンプ、SSRC（同期ソース）およびCSRC（コントリビューティングソース）は[RFC3550]で定義されており、通常G.711で使用されています。 PT（ペイロードタイプ）は、[RFC3551]で定義されています。
This section defines the G.711.0 RTP payload and illustrates it by means of two examples.
このセクションでは、G.711.0 RTPペイロードを定義し、2つの例を使って説明します。
The first example, in Section 4.2.1, depicts the case in which carrying only one G.711.0 frame in the RTP payload is desired. This case is expected to be the dominant use case and is shown separately for the purposes of clarity.
セクション4.2.1の最初の例は、RTPペイロードで1つのG.711.0フレームのみを伝送する必要がある場合を示しています。このケースは主要なユースケースであると予想され、明確にするために個別に示されています。
The second example, in Section 4.2.2, depicts the general case in which carrying one or more G.711.0 frames in the RTP payload is desired. This is the actual definition of the G.711.0 RTP payload.
セクション4.2.2の2番目の例は、RTPペイロードで1つ以上のG.711.0フレームを伝送することが望まれる一般的なケースを示しています。これは、G.711.0 RTPペイロードの実際の定義です。
This example depicts a single G.711.0 frame in the RTP payload. This is expected to be the dominant RTP payload case for G.711.0, as the G.711.0 encoding process supports the SDP packet times (ptime and maxptime, see [RFC4566]) commonly used when G.711 is transported in RTP. Additionally, as mentioned previously, larger G.711.0 frames generally compress more effectively than a multiplicity of smaller G.711.0 frames.
この例は、RTPペイロード内の単一のG.711.0フレームを示しています。 G.711.0エンコードプロセスは、G.711がRTPで転送されるときに一般的に使用されるSDPパケット時間（ptimeとmaxptime、[RFC4566]を参照）をサポートするため、これはG.711.0の主要なRTPペイロードのケースであると予想されます。さらに、前述のように、大きなG.711.0フレームは通常、多数の小さなG.711.0フレームよりも効果的に圧縮されます。
The following figure illustrates the single G.711.0 frame per RTP payload case.
次の図は、RTPペイロードの場合の単一のG.711.0フレームを示しています。
|-------------------|-------------------|
| One G.711.0 Frame | Zero or more 0x00 |
| | Padding Octets |
|___________________|___________________|
Figure 2: Single G.711.0 Frame in RTP Payload Case
図2：RTPペイロードケースの単一G.711.0フレーム
Encoding Process: A single G.711.0 frame is inserted into the RTP payload. The amount of time represented by the G.711 symbols compressed in the G.711.0 frame MUST correspond to the ptime signaled for applications using SDP. Although generally not desired, padding desired in the RTP payload after the G.711.0 frame MAY be created by placing one or more 0x00 octets after the G.711.0 frame. Such padding may be desired based on the Security Considerations (see Section 8).
エンコーディングプロセス：RTPペイロードに単一のG.711.0フレームが挿入されます。 G.711.0フレームで圧縮されたG.711シンボルで表される時間は、SDPを使用するアプリケーションに通知されるptimeに対応している必要があります。一般的には望ましくありませんが、G.711.0フレームの後のRTPペイロードで必要なパディングは、G.711.0フレームの後に1つ以上の0x00オクテットを配置することによって作成できます。このようなパディングは、セキュリティ上の考慮事項に基づいて望ましい場合があります（セクション8を参照）。
Decoding Process: Passing the entire RTP payload to the G.711.0 decoder is sufficient for the G.711.0 decoder to create the source G.711 symbols. Any padding inserted after the G.711.0 frame (i.e., the 0x00 octets) present in the RTP payload is silently ignored by the G.711.0 decoding process. The decoding process is fully described in Section 4.2.3.
デコードプロセス：RTPペイロード全体をG.711.0デコーダに渡すだけで、G.711.0デコーダはソースG.711シンボルを作成できます。 RTPペイロードに存在するG.711.0フレームの後に挿入されたパディング（つまり、0x00オクテット）は、G.711.0デコードプロセスによって暗黙的に無視されます。デコードプロセスについては、セクション4.2.3で詳しく説明しています。
This section defines the G.711.0 RTP payload and illustrates the case in which one or more G.711.0 frames are to be placed in the payload. All G.711.0 RTP decoders MUST support the general case described in this section (rationale presented previously in Section 3.3.1).
このセクションでは、G.711.0 RTPペイロードを定義し、1つ以上のG.711.0フレームがペイロードに配置されるケースを示します。すべてのG.711.0 RTPデコーダは、このセクションで説明されている一般的なケースをサポートする必要があります（前述のセクション3.3.1で説明した根拠）。
Note that since each G.711.0 frame is self-describing (see Attribute A4 in Section 3.2), the individual G.711.0 frames in the RTP payload need not represent the same duration of time (i.e., a 5 ms G.711.0 frame could be followed by a 20 ms G.711.0 frame). Owing to this, the amount of time represented in the RTP payload MAY be any integer multiple of 5 ms (as 5 ms is the smallest interval of time that can be represented in a G.711.0 frame).
各G.711.0フレームは自己記述型であるため（セクション3.2の属性A4を参照）、RTPペイロードの個々のG.711.0フレームは同じ期間を表す必要はありません（つまり、5 ms G.711.0フレームはその後に20ミリ秒のG.711.0フレームが続きます）。このため、RTPペイロードで表される時間は、5 msの整数倍になる場合があります（5 msは、G.711.0フレームで表すことができる最小の時間間隔であるため）。
The following figure illustrates the one or more G.711.0 frames per RTP payload case where the number of G.711.0 frames placed in the RTP payload is N. We note that when N is equal to 1, this case is identical to the previous example.
次の図は、RTPペイロードに配置されたG.711.0フレームの数がNである場合の、RTPペイロードごとの1つ以上のG.711.0フレームを示しています。Nが1に等しい場合、このケースは前の例と同じです。 。
|----------|---------|----------|---------|----------------|
| First | Second | | Nth | Zero or more |
| G.711.0 | G.711.0 | ... | G.711.0 | 0x00 |
| Frame | Frame | | Frame | Padding Octets |
|__________|_________|__________|_________|________________|
Figure 3: One or More G.711.0 Frames in RTP Payload Case
図3：RTPペイロードケースの1つ以上のG.711.0フレーム
We note here that when we have multiple G.711.0 frames, the individual frames can be, and generally are, of different lengths. The decoding process described in Section 4.2.3 is used to determine the frame boundaries.
ここで、複数のG.711.0フレームがある場合、個々のフレームは異なる長さになる可能性があり、一般的には異なることに注意してください。セクション4.2.3で説明されているデコードプロセスを使用して、フレーム境界を決定します。
Encoding Process: One or more G.711.0 frames are placed in the RTP payload simply by concatenating the G.711.0 frames together. The amount of time represented by the G.711 symbols compressed in all the G.711.0 frames in the RTP payload MUST correspond to the ptime signaled for applications using SDP. Although not generally desired, padding in the RTP payload SHOULD be placed after the last G.711.0 frame in the payload and MAY be created by placing one or more 0x00 octets after the last G.711.0 frame. Such padding may be desired based on security considerations (see Section 8). Additional details about the encoding process and considerations are specified later in Section 4.2.2.1.
エンコーディングプロセス：G.711.0フレームを連結するだけで、1つ以上のG.711.0フレームがRTPペイロードに配置されます。 RTPペイロードのすべてのG.711.0フレームで圧縮されたG.711シンボルで表される時間は、SDPを使用するアプリケーションに通知されるptimeに対応している必要があります。一般的には望ましくありませんが、RTPペイロードのパディングはペイロードの最後のG.711.0フレームの後に配置する必要があり（SHOULD）、最後のG.711.0フレームの後に1つ以上の0x00オクテットを配置することによって作成できます（MAY）。このようなパディングは、セキュリティ上の考慮事項に基づいて望ましい場合があります（セクション8を参照）。エンコーディングプロセスと考慮事項の詳細については、4.2.2.1項で後述します。
Decoding Process: As G.711.0 frames can be of varying length, the payload decoding process described in Section 4.2.3 is used to determine where the individual G.711.0 frame boundaries are. Any padding octets inserted before or after any G.711.0 frame in the RTP payload is silently (and safely) ignored by the G.711.0 decoding process specified in Section 4.2.3.
デコードプロセス：G.711.0フレームはさまざまな長さになる可能性があるため、セクション4.2.3で説明されているペイロードデコードプロセスを使用して、個々のG.711.0フレーム境界がどこにあるかを判別します。 RTPペイロードのG.711.0フレームの前または後に挿入されたパディングオクテットは、4.2.3項で指定されたG.711.0デコードプロセスによってサイレントに（そして安全に）無視されます。
ITU-T G.711.0 supports five possible input frame lengths: 40, 80, 160, 240, and 320 samples per frame, and the rationale for choosing those lengths was given in the description of property A5 in Section 3.2. Assuming a frequency of 8000 samples per second, these lengths correspond to input frames representing 5 ms, 10 ms, 20 ms, 30 ms, or 40 ms. So while the standard assumed the input "bit stream" consisted of G.711 symbols of some integer multiple of 5 ms in length, it did not specify exactly what frame lengths to use as input to the G.711.0 encoder itself. The intent of this section is to provide some guidance for the selection.
ITU-T G.711.0は、フレームあたり40、80、160、240、および320サンプルの5つの可能な入力フレーム長をサポートします。これらの長さを選択する根拠は、セクション3.2のプロパティA5の説明に記載されています。周波数が毎秒8000サンプルであると仮定すると、これらの長さは、5 ms、10 ms、20 ms、30 ms、または40 msを表す入力フレームに対応します。したがって、標準では、入力「ビットストリーム」は長さが5ミリ秒の整数倍のG.711シンボルで構成されると想定していましたが、G.711.0エンコーダ自体への入力として使用するフレーム長を正確に指定していませんでした。このセクションの目的は、選択に関するいくつかのガイダンスを提供することです。
Consider a typical IETF use case of 20 ms (160 octets) of G.711 input samples represented in a G.711.0 payload and signaled by using the SDP parameter ptime. As described in Section 3.3.1, the simplest way to encode these 160 octets is to pass the entire 160 octets to the G.711.0 encoder, resulting in precisely one G.711.0 compressed frame, and put that singular frame into the G.711.0 RTP payload. However, neither the ITU-T G.711.0 standard nor this IETF payload format mandates this. In fact, 20 ms of input G.711 symbols can be encoded as 1, 2, 3, or 4 G.711.0 frames in any one of six combinations (i.e., {20ms}, {10ms:10ms}, {10ms:5ms:5ms}, {5ms:10ms:5ms}, {5ms:5ms:10ms}, {5ms:5ms:5ms:5ms}) and any of these combinations would decompress into the same source 160 G.711 octets. As an aside, we note that the first octet of any G.711.0 frame will be the prefix code octet and information in this octet determines how many G.711 symbols are represented in the G.711.0 frame.
G.711.0ペイロードで表され、SDPパラメータptimeを使用して通知される20 ms（160オクテット）のG.711入力サンプルの典型的なIETFユースケースを考えてみます。セクション3.3.1で説明されているように、これらの160オクテットをエンコードする最も簡単な方法は、160オクテット全体をG.711.0エンコーダーに渡し、結果として1つのG.711.0圧縮フレームを生成し、その特異フレームをG.711.0に入れることです。 RTPペイロード。ただし、ITU-T G.711.0標準もこのIETFペイロード形式もこれを義務付けていません。実際、20ミリ秒の入力G.711シンボルは、6つの組み合わせ（つまり、{20ms}、{10ms：10ms}、{10ms：5ms）のいずれかで1、2、3、または4 G.711.0フレームとしてエンコードできます。 ：5ms}、{5ms：10ms：5ms}、{5ms：5ms：10ms}、{5ms：5ms：5ms：5ms}）とこれらの組み合わせのいずれも、同じソースの160 G.711オクテットに解凍されます。余談ですが、G.711.0フレームの最初のオクテットはプレフィックスコードのオクテットであり、このオクテットの情報により、G.711.0フレームで表されるG.711シンボルの数が決まります。
Notwithstanding the above, we expect one of two encodings to be used by implementers: the simplest possible (one 160-byte input to the G.711.0 encoder that usually results in the highest compression) or the combination of possible input frames to a G.711.0 encoder that results in the highest compression for the payload. The explicit mention of this issue in this IETF document was deemed important because the ITU-T G.711.0 standard is silent on this issue and there is a desire for this issue to be documented in a formal Standards Developing Organization (SDO) document (i.e., here).
上記にかかわらず、実装者は2つのエンコーディングの1つを使用することを想定しています。可能な限り単純なもの（通常はG.711.0エンコーダーへの160バイトの入力で、最も圧縮率が高くなります）またはGへの可能な入力フレームの組み合わせです。ペイロードの圧縮率が最も高い711.0エンコーダー。 ITU-T G.711.0標準はこの問題について言及していないため、このIETFドキュメントでこの問題を明示的に言及することは重要であると見なされ、この問題を正式な標準策定組織（SDO）ドキュメント（つまり、 、 ここに）。
The G.711.0 decoding process is a standard part of G.711.0 bit stream decoding and is implemented in the ITU-T Rec. G.711.0 reference code. The decoding process algorithm described in this section is a slight enhancement of the ITU-T reference code to explicitly accommodate RTP padding (as described above).
G.711.0デコードプロセスは、G.711.0ビットストリームデコードの標準部分であり、ITU-T勧告に実装されています。 G.711.0参照コード。このセクションで説明するデコードプロセスアルゴリズムは、RTPパディングに明示的に対応するためにITU-T参照コードをわずかに拡張したものです（上記のとおり）。
Before describing the decoding, we note here that the largest possible G.711.0 frame is created whenever the largest number of G.711 symbols is encoded (320 from Section 3.2, property A5) and these 320 symbols are "uncompressible" by the G.711.0 encoder. In this case (via property A6 in Section 3.2), the G.711.0 output frame will be 321 octets long. We also note that the value 0x00 chosen for the optional padding cannot be the first octet of a valid ITU-T Rec. G.711.0 frame (see [G.711.0]). We also note that whenever more than one G.711.0 frame is contained in the RTP payload, decoding of the individual G.711.0 frames will occur multiple times.
デコードについて説明する前に、最大数のG.711シンボルがエンコードされると（セクション3.2の320、プロパティA5の320）、可能な限り最大のG.711.0フレームが作成され、これらの320シンボルはGによって「圧縮できない」ことに注意してください。 711.0エンコーダ。この場合（セクション3.2のプロパティA6を使用）、G.711.0出力フレームは321オクテットの長さになります。また、オプションのパディングに選択された値0x00は、有効なITU-T Recの最初のオクテットにはなれないことに注意してください。 G.711.0フレーム（[G.711.0]を参照）。また、RTPペイロードに複数のG.711.0フレームが含まれている場合は、個々のG.711.0フレームのデコードが複数回発生することにも注意してください。
For the decoding algorithm below, let N be the number of octets in the RTP payload (i.e., excluding any RTP padding, but including any RTP payload padding), let P equal the number of RTP payload octets processed by the G.711.0 decoding process, let K be the number of G.711 symbols presently in the output buffer, let Q be the number of octets contained in the G.711.0 frame being processed, and let "!=" represent not equal to. The keyword "STOP" is used below to indicate the end of the processing of G.711.0 frames in the RTP payload. The algorithm below assumes an output buffer for the decoded G.711 source symbols of length sufficient to accommodate the expected number of G.711 symbols and an input buffer of length 321 octets.
以下のデコードアルゴリズムの場合、NをRTPペイロードのオクテット数（つまり、RTPパディングを除くがRTPペイロードパディングを含む）とし、PをG.711.0デコードプロセスで処理されるRTPペイロードオクテットの数と等しくします。 、Kを現在出力バッファにあるG.711シンボルの数とし、Qを処理中のG.711.0フレームに含まれるオクテットの数とし、「！=」は等しくないことを表します。キーワード「STOP」は、RTPペイロードのG.711.0フレームの処理の終了を示すために、以下で使用されています。以下のアルゴリズムは、G.711シンボルの予想数に対応するのに十分な長さのデコードされたG.711ソースシンボルの出力バッファーと、長さ321オクテットの入力バッファーを想定しています。
G.711.0 RTP Payload Decoding Heuristic:
G.711.0 RTPペイロードデコードヒューリスティック：
H1 Initialization of counters: Initialize P, the number of processed octets counter, to zero. Initialize K, the counter for how many G.711 symbols are in the output buffer, to zero. Initialize N to the number of octets in the RTP payload (including any RTP payload padding). Go to H2.
H1カウンターの初期化：処理されたオクテットカウンターの数であるPをゼロに初期化します。出力バッファ内にあるG.711シンボルの数のカウンタであるKをゼロに初期化します。 NをRTPペイロード（RTPペイロードパディングを含む）のオクテット数に初期化します。 H2に移動します。
H2 Read internal buffer: Read min{320+1, (N-P)-1} octets into the internal buffer from the (P+1) octet of the RTP payload. We note at this point, N-P octets have yet to be processed and that 320+1 octets is the largest possible G.711.0 frame. Also note that in the common case of zero-based array indexing of a uint8 array of octets, that this operation will read octets from index P through index [min{320+1, (N-P)}] from the RTP payload. Go to H3.
H2内部バッファーの読み取り：RTPペイロードの（P + 1）オクテットから内部バッファーにmin {320 + 1、（N-P）-1}オクテットを読み取ります。この時点では、N-Pオクテットはまだ処理されておらず、320 + 1オクテットが最大のG.711.0フレームであることに注意してください。また、オクテットのuint8配列のゼロベースの配列インデックス付けの一般的なケースでは、この操作はRTPペイロードからインデックスPからインデックス[min {320 + 1、（N-P）}]までオクテットを読み取ることに注意してください。 H3に移動します。
H3 Analyze the first octet in the internal buffer: If this octet is 0x00 (a padding octet), go to H4; otherwise, go to H5 (process a G.711.0 frame).
H3内部バッファの最初のオクテットを分析します。このオクテットが0x00（パディングオクテット）の場合、H4に移動します。それ以外の場合は、H5に進みます（G.711.0フレームを処理します）。
H4 Process padding octet (no G.711 symbols generated): Increment the processed packets counter by one (set P = P + 1). If the result of this increment results in P >= N, then STOP (as all RTP Payload octets have been processed); otherwise, go to H2.
H4プロセスパディングオクテット（G.711シンボルは生成されません）：処理されたパケットカウンターを1つインクリメントします（P = P + 1に設定）。このインクリメントの結果がP> = Nになる場合は、停止します（すべてのRTPペイロードオクテットが処理されているため）。それ以外の場合は、H2に進みます。
H5 Process an individual G.711.0 frame (produce G.711 samples in the output frame): Pass the internal buffer to the G.711.0 decoder. The G.711.0 decoder will read the first octet (called the "prefix code" octet in ITU-T Rec. G.711.0 [G.711.0]) to determine the number of source G.711 samples M are contained in this G.711.0 frame. The G.711.0 decoder will produce exactly M G.711 source symbols (M can only have values of 0, 40, 80, 160, 240, or 320). If K = 0, these M symbols will be the first in the output buffer and are placed at the beginning of the output buffer. If K != 0, concatenate these M symbols with the prior symbols in the output buffer (there are K prior symbols in the buffer). Set K = K + M (as there are now this many G.711 source symbols in the output buffer). The G.711.0 decoder will have consumed some number of octets, Q, in the internal buffer to produce the M G.711 symbols. Increment the number of payload octets processed counter by this quantity (set P = P + Q). If the result of this increment results in P >= N, then STOP (as all RTP Payload octets have been processed); otherwise, go to H2.
H5個々のG.711.0フレームを処理します（出力フレームでG.711サンプルを生成します）：内部バッファーをG.711.0デコーダーに渡します。 G.711.0デコーダーは最初のオクテット（ITU-T勧告G.711.0 [G.711.0]では「プレフィックスコード」オクテットと呼ばれる）を読み取り、このGに含まれるソースG.711サンプルMの数を決定します。 711.0フレーム。 G.711.0デコーダは、正確にM個のG.711ソースシンボルを生成します（Mは0、40、80、160、240、または320の値のみを持つことができます）。 K = 0の場合、これらのMシンボルは出力バッファーの最初になり、出力バッファーの先頭に配置されます。 K！= 0の場合、これらのM個のシンボルを出力バッファーの前のシンボルと連結します（バッファーにはK個の前のシンボルがあります）。 K = K + Mに設定します（これで、出力バッファーにこれだけ多くのG.711ソースシンボルがあります）。 G.711.0デコーダは、M G.711シンボルを生成するために、内部バッファでいくつかのオクテットQを消費します。処理されたペイロードオクテットの数をこの数だけ増やします（P = P + Qを設定）。このインクリメントの結果がP> = Nになる場合は、停止します（すべてのRTPペイロードオクテットが処理されているため）。それ以外の場合は、H2に進みます。
At this point, the output buffer will contain precisely K G.711 source symbols that should correspond to the ptime signaled if SDP was used and the encoding process was without error. If ptime was signaled via SDP and the number of G.711 symbols in the output buffer is something other than what corresponds to ptime, the packet MUST be discarded unless other system design knowledge allows for otherwise (e.g., occasional 5 ms clock slips causing one more or one less G.711.0 frame than nominal to be in the payload). Lastly, due to the buffer reads in H2 being bounded (to 321 octets or less), N being bounded to the size of the G.711.0 RTP payload, and M being bounded to the number of source G.711 symbols, there is no buffer overrun risk.
この時点で、出力バッファーには正確にK G.711ソースシンボルが含まれます。これは、SDPが使用され、エンコードプロセスにエラーがなかった場合に通知されるptimeに対応する必要があります。 ptimeがSDPを介して通知され、出力バッファー内のG.711シンボルの数がptimeに対応するもの以外の場合、他のシステム設計の知識で許可されていない限り、パケットを破棄する必要があります（たとえば、5ミリ秒のクロックスリップにより、ペイロード内にあるG.711.0フレームが公称値よりも多いか、または少ない。最後に、H2のバッファ読み取りが（321オクテット以下に）バインドされているため、NはG.711.0 RTPペイロードのサイズにバインドされ、MはソースG.711シンボルの数にバインドされているため、バッファオーバーランリスク。
We also note, as an aside, that the algorithm above (and the ITU-T G.711.0 reference code) accommodates padding octets (0x00) placed anywhere between G.711.0 frames in the RTP payload as well as prior to or after any or all G.711.0 frames. The ITU-T G.711.0 reference code does not have Steps H3 and H4 as separate steps (i.e., Step H5 immediately follows H2) at the added computational cost of some additional buffer passing to/from the G.711.0 frame decoder functions. That is, the G.711.0 decoder in the reference code "silently ignores" 0x00 padding octets at the beginning of what it believes to be a frame boundary encoded by G.711.0. Thus, Steps H3 and H4 above are an optimization over the reference code shown for clarity.
余談ですが、上記のアルゴリズム（およびITU-T G.711.0参照コード）は、RTPペイロード内のG.711.0フレーム間のどこかに配置されているパディングオクテット（0x00）に対応していること、およびすべてのG.711.0フレーム。 ITU-T G.711.0参照コードには、G.711.0フレームデコーダー関数との間でやり取りされる追加のバッファーの追加の計算コストで、ステップH3とH4が個別のステップ（つまり、ステップH5がH2の直後に続く）としてありません。つまり、参照コードのG.711.0デコーダーは、G.711.0によってエンコードされたフレーム境界であると考えられるものの最初の0x00パディングオクテットを「黙って無視」します。したがって、上記のステップH3およびH4は、わかりやすくするために示されている参照コードに対する最適化です。
If the decoder is at a playout endpoint location, this G.711 buffer SHOULD be used in the same manner as a received G.711 RTP payload would have been used (passed to a playout buffer, to a PLC implementation, etc.).
デコーダーがプレイアウトエンドポイントの場所にある場合、このG.711バッファーは、受信したG.711 RTPペイロードが使用されたのと同じ方法で使用する必要があります（プレイアウトバッファー、PLC実装などに渡される）。
We explicitly note that a framing error condition will result whenever the buffer sent to a G.711.0 decoder does not begin with a valid first G.711.0 frame octet (i.e., a valid G.711.0 prefix code or a 0x00 padding octet). The expected result is that the decoder will not produce the desired/correct G.711 source symbols. However, as already noted, the output returned by the G.711.0 decoder will be bounded (to less than 321 octets per G.711.0 decode request) and if the number of the (presumed) G.711 symbols produced is known to be in error, the decoded output MUST be discarded.
G.711.0デコーダーに送信されたバッファーが有効な最初のG.711.0フレームオクテット（つまり、有効なG.711.0プレフィックスコードまたは0x00パディングオクテット）で始まっていない場合は常に、フレーミングエラー条件が発生することに注意してください。期待される結果は、デコーダーが望ましい/正しいG.711ソースシンボルを生成しないことです。ただし、すでに述べたように、G.711.0デコーダーによって返される出力は制限され（G.711.0デコード要求ごとに321オクテット未満に）、生成された（推定）G.711シンボルの数がエラー、デコードされた出力は破棄する必要があります。
In this section, we describe the use of multiple "channels" of G.711 data encoded by G.711.0 compression.
このセクションでは、G.711.0圧縮でエンコードされたG.711データの複数の「チャネル」の使用について説明します。
The dominant use of G.711 in RTP transport has been for single channel use cases. For this case, the above G.711.0 encoding and decoding process is used. However, the multiple channel case for G.711.0 (a frame-based compression) is different from G.711 (a sample-based encoding) and is described separately here.
RTPトランスポートでのG.711の主な用途は、単一チャネルの使用例です。この場合、上記のG.711.0エンコードおよびデコードプロセスが使用されます。ただし、G.711.0（フレームベースの圧縮）の複数チャネルのケースはG.711（サンプルベースのエンコーディング）とは異なり、ここで個別に説明します。
Section 4 of RFC 3551 [RFC3551] provides guidelines for encoding audio channels and Section 4.1 of RFC 3551 [RFC3551] for the ordering of the channels within the RTP payload. The ordering guidelines in Section 4.1 of RFC 3551 SHOULD be used unless an application-specific channel ordering is more appropriate.
RFC 3551 [RFC3551]のセクション4は、オーディオチャネルをエンコードするためのガイドラインを提供し、RTPペイロード内のチャネルの順序については、RFC 3551 [RFC3551]のセクション4.1を提供します。アプリケーション固有のチャネルの順序がより適切でない限り、RFC 3551のセクション4.1の順序付けガイドラインを使用する必要があります。
An implicit assumption in RFC 3551 is that all the channel data multiplexed into an RTP payload MUST represent the same physical time span. The case for G.711.0 is no different; the underlying G.711 data for all channels in a G.711.0 RTP payload MUST span the same interval in time (e.g., the same "ptime" for a SDP-specified codec negotiation).
RFC 3551の暗黙の前提は、RTPペイロードに多重化されたすべてのチャネルデータが同じ物理タイムスパンを表す必要があるということです。 G.711.0の場合も例外ではありません。 G.711.0 RTPペイロード内のすべてのチャネルの基礎となるG.711データは、同じ時間間隔（たとえば、SDP指定のコーデックネゴシエーションの同じ「ptime」）にまたがる必要があります。
Section 4.2 of RFC 3551 provides guidelines for sample-based encodings such as G.711. This guidance is tantamount to interleaving the individual samples in that they SHOULD be packed in consecutive octets.
RFC 3551のセクション4.2は、G.711などのサンプルベースのエンコーディングのガイドラインを提供します。このガイダンスは、連続するオクテットにパックする必要があるという点で、個々のサンプルをインターリーブすることと同じです。
RFC 3551 provides guidelines for frame-based encodings in which the frames are interleaved. However, this guidance stems from the stated assumption that "the frame size for the frame-oriented codecs is given". However, this assumption is not valid for G.711.0 in that individual consecutive G.711.0 frames (as per Section 4.2.2 of this document) can:
RFC 3551は、フレームがインターリーブされるフレームベースのエンコーディングのガイドラインを提供します。ただし、このガイダンスは、「フレーム指向のコーデックのフレームサイズが指定されている」という想定に基づいています。ただし、この仮定はG.711.0には有効ではありません（このドキュメントのセクション4.2.2に従って）個々の連続したG.711.0フレームは次のことが可能です。
1. represent different time spans (e.g., two 5 ms G.711.0 frames in lieu of one 10 ms G.711.0 frame), and
1. 異なる時間間隔を表す（たとえば、1つの10ミリ秒G.711.0フレームの代わりに2つの5ミリ秒G.711.0フレーム）、および
2. be of different lengths in octets (and typically are).
2. オクテット単位で長さが異なります（通常はそうです）。
Therefore, a different, but also simple, concatenation-based approach is specified in this RFC.
したがって、このRFCでは、異なるが単純な連結ベースのアプローチが指定されています。
For the multiple channel G.711.0 case, each G.711 channel is independently encoded into one or more G.711.0 frames defined here as a "G.711.0 channel superframe". Each one of these superframes is identical to the multiple G.711.0 frame case illustrated in Figure 3 of Section 4.2.2 in which each superframe can have one or more individual G.711.0 frames within it. Then each G.711.0 channel superframe is concatenated -- in channel order -- into a G.711.0 RTP payload. Then, if optional G.711.0 padding octets (0x00) are desired, it is RECOMMENDED that these octets are placed after the last G.711.0 channel superframe. As per above, such padding may be desired based on Security Considerations (see Section 8). This is depicted in Figure 4.
複数チャネルG.711.0の場合、各G.711チャネルは、ここで「G.711.0チャネルスーパーフレーム」として定義されている1つ以上のG.711.0フレームに独立してエンコードされます。これらのスーパーフレームのそれぞれは、セクション4.2.2の図3に示されている複数のG.711.0フレームの場合と同じです。各スーパーフレームには、1つ以上の個別のG.711.0フレームを含めることができます。次に、各G.711.0チャネルスーパーフレームが（チャネル順に）G.711.0 RTPペイロードに連結されます。次に、オプションのG.711.0パディングオクテット（0x00）が必要な場合は、これらのオクテットを最後のG.711.0チャネルスーパーフレームの後に配置することをお勧めします。上記のように、このようなパディングはセキュリティの考慮事項に基づいて望ましい場合があります（セクション8を参照）。これを図4に示します。
|----------|---------|----------|---------|---------|
| First | Second | | Nth | Zero |
| G.711.0 | G.711.0 | ... | G.711.0 | or more |
| Channel | Channel | | Channel | 0x00 |
| Super- | Super- | | Super | Padding |
| Frame | Frame | | Frame | Octets |
|__________|_________|__________|_________|_________|
Figure 4: Multiple G.711.0 Channel Superframes in RTP Payload
図4：RTPペイロード内の複数のG.711.0チャネルスーパーフレーム
We note that although the individual superframes can be of different lengths in octets (and usually are), the number of G.711 source symbols represented -- in compressed form -- in each channel superframe is identical (since all the channels represent the identically same time interval).
個々のスーパーフレームはオクテットで異なる長さになることができますが（通常はそうです）、各チャネルのスーパーフレームで表されるG.711ソースシンボルの数（圧縮形式）は同じです（すべてのチャネルが同じように表現されるため）同じ時間間隔）。
The G.711.0 decoder at the receiving end simply decodes the entire G.711.0 (multiple channel) payload into individual G.711 symbols. If M such G.711 symbols result and there were N channels, then the first M/N G.711 samples would be from the first channel, the second M/N G.711 samples would be from the second channel, and so on until the Nth set of G.711 samples are found. Similarly, if the number of channels was not known, but the payload "ptime" was known, one could infer (knowing the sampling rate) how many G.711 symbols each channel contained; then, with this knowledge, the number of channels of data contained in the payload could be determined. When SDP is used, the number of channels is known because the optional parameter is a MUST when there is more than one channel negotiated (see Section 5.1). Additionally, when SDP is used, the parameter ptime is a RECOMMENDED optional parameter. We note that if both parameters channels and ptime are known, one could provide a check for the other and the converse. Whichever algorithm is used to determine the number of channels, if the length of the source G.711 symbols in the payload (M) is not an integer multiple of the number of channels (N), then the packet SHOULD be discarded.
受信側のG.711.0デコーダは、G.711.0（マルチチャネル）ペイロード全体を個々のG.711シンボルにデコードするだけです。そのようなG.711シンボルがM個生成され、チャネルがN個ある場合、最初のM / N G.711サンプルは最初のチャネルから、2番目のM / N G.711サンプルは2番目のチャネルからというように続きます。 G.711サンプルのN番目のセットが見つかるまで。同様に、チャネル数は不明であるが、ペイロード「ptime」は既知である場合、各チャネルに含まれるG.711シンボルの数を（サンプリングレートを把握して）推測できます。次に、この知識があれば、ペイロードに含まれるデータのチャネル数を決定できます。 SDPが使用される場合、ネゴシエーションされた複数のチャネルがある場合はオプションのパラメーターが必須であるため、チャネルの数は既知です（セクション5.1を参照）。さらに、SDPを使用する場合、パラメーターptimeは推奨されるオプションのパラメーターです。チャネルとptimeの両方のパラメーターがわかっている場合、一方が他方のチェックとその逆を確認できることに注意してください。チャネル数を決定するためにどのアルゴリズムを使用しても、ペイロードのソースG.711シンボルの長さ（M）がチャネル数（N）の整数倍でない場合、パケットは破棄されるべきです（SHOULD）。
Lastly, we note that although any padding for the multiple channel G.711.0 payload is RECOMMENDED to be placed at the end of the payload, the G.711.0 decoding algorithm described in Section 4.2.3 will successfully decode the payload in Figure 4 if the 0x00 padding octet is placed anywhere before or after any individual G.711.0 frame in the RTP payload. The number of padding octets introduced at any G.711.0 frame boundary therefore does not affect the number M of the source G.711 symbols produced. Thus, the decision for padding MAY be made on a per-superframe basis.
最後に、複数チャネルG.711.0ペイロードのパディングはペイロードの最後に配置することが推奨されていますが、セクション4.2.3で説明されているG.711.0デコードアルゴリズムは、図4のペイロードを正常にデコードすることに注意してください。 0x00パディングオクテットは、RTPペイロードの個々のG.711.0フレームの前後のどこかに配置されます。したがって、G.711.0フレーム境界で導入されたパディングオクテットの数は、生成されるソースG.711シンボルの数Mには影響しません。したがって、パディングの決定は、スーパーフレームごとに行われる場合があります。
This section defines the parameters that may be used to configure optional features in the G.711.0 RTP transmission.
このセクションでは、G.711.0 RTP伝送のオプション機能を構成するために使用できるパラメーターを定義します。
The parameters defined here are a part of the media subtype registration for the G.711.0 codec. Mapping of the parameters into SDP RFC 4566 [RFC4566] is also provided for those applications that use SDP.
ここで定義されるパラメータは、G.711.0コーデックのメディアサブタイプ登録の一部です。 SDPを使用するアプリケーションには、SDP RFC 4566 [RFC4566]へのパラメーターのマッピングも用意されています。
Type name: audio
タイプ名：オーディオ
Subtype name: G711-0
サブタイプ名：G711-0
Required parameters:
必須パラメーター：
clock rate: The RTP timestamp clock rate, which is equal to the sampling rate. The typical rate used with G.711 encoding is 8000, but other rates may be specified. The default rate is 8000.
クロックレート：RTPタイムスタンプのクロックレート。サンプリングレートと同じです。 G.711エンコーディングで使用される一般的なレートは8000ですが、他のレートを指定することもできます。デフォルトのレートは8000です。
complaw: This format-specific parameter, specified on the "a=fmtp: line", indicates the companding law (A-law or mu-law) employed. This format-specific parameter, as per RFC 4566 [RFC4566], is given unchanged to the media tool using this format. The case-insensitive values are "complaw=al" or "complaw=mu" are used for A-law and mu-law, respectively.
complaw：「a = fmtp：行」で指定されているこのフォーマット固有のパラメーターは、採用されている圧伸則（A-lawまたはmu-law）を示します。この形式固有のパラメーターは、RFC 4566 [RFC4566]に従って、この形式を使用するメディアツールに変更なしで提供されます。大文字と小文字を区別しない値は「complaw = al」または「complaw = mu」で、それぞれA-lawおよびmu-lawに使用されます。
Optional parameters:
オプションのパラメーター：
channels: See RFC 4566 [RFC4566] for definition. Specifies how many audio streams are represented in the G.711.0 payload and MUST be present if the number of channels is greater than one. This parameter defaults to 1 if not present (as per RFC 4566) and is typically a non-zero, small-valued positive integer. It is expected that implementations that specify multiple channels will also define a mechanism to map the channels appropriately within their system design; otherwise, the channel order specified in Section 4.1 of RFC 3551 [RFC3551] will be assumed (e.g., left, right, center). Similar to the usual interpretation in RFC 3551 [RFC3551], the number of channels SHALL be a non-zero, positive integer.
チャネル：定義については、RFC 4566 [RFC4566]を参照してください。 G.711.0ペイロードで表されるオーディオストリームの数を指定します。チャネルの数が1より大きい場合は存在する必要があります。このパラメーターは、存在しない場合はデフォルトで1になり（RFC 4566に準拠）、通常はゼロ以外の小さい値の正の整数です。複数のチャネルを指定する実装は、システム設計内でチャネルを適切にマップするメカニズムも定義することが期待されます。それ以外の場合は、RFC 3551 [RFC3551]のセクション4.1で指定されたチャネル順序が想定されます（左、右、中央など）。 RFC 3551 [RFC3551]の通常の解釈と同様に、チャネル数はゼロ以外の正の整数である必要があります（SHALL）。
maxptime: See RFC 4566 [RFC4566] for definition.
maxptime：定義については、RFC 4566 [RFC4566]を参照してください。
ptime: See RFC 4566 [RFC4566] for definition. The inclusion of "ptime" is RECOMMENDED and SHOULD be in the SDP unless there is an application-specific reason not to include it (e.g., an application that has a variable ptime on a packet-by-packet basis). For constant ptime applications, it is considered good form to include "ptime" in the SDP for session diagnostic purposes. For the constant ptime multiple channel case described in Section 4.2.2, the inclusion of "ptime" can provide a desirable payload check.
ptime：定義については、RFC 4566 [RFC4566]を参照してください。 「ptime」を含めることをお勧めします。これを含めないアプリケーション固有の理由（たとえば、パケットごとに可変のptimeを持つアプリケーション）がない限り、SDPに含める必要があります。一定のptimeアプリケーションの場合、セッション診断の目的で「ptime」をSDPに含めることは適切な形式と見なされます。セクション4.2.2で説明されている一定のptime複数チャネルのケースでは、「ptime」を含めることで望ましいペイロードチェックを提供できます。
Encoding considerations:
エンコードに関する考慮事項：
This media type is framed binary data (see Section 4.8 in RFC 6838 [RFC6838]) compressed as per ITU-T Rec. G.711.0.
このメディアタイプは、ITU-T勧告に従って圧縮されたフレーム化されたバイナリデータ（RFC 6838 [RFC6838]のセクション4.8を参照）です。 G.711.0。
Security considerations:
セキュリティに関する考慮事項：
See Section 8.
セクション8を参照してください。
Interoperability considerations: none
相互運用性に関する考慮事項：なし
Published specification:
公開された仕様：
ITU-T Rec. G.711.0 and RFC 7655 (this document).
ITU-T Rec。 G.711.0およびRFC 7655（このドキュメント）。
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Although initially conceived for VoIP, the use of G.711.0, like G.711 before it, may find use within audio and video streaming and/or conferencing applications for the audio portion of those applications.
当初はVoIP向けに考案されましたが、それ以前のG.711と同様に、G.711.0の使用は、オーディオおよびビデオストリーミングや会議アプリケーションで、これらのアプリケーションのオーディオ部分に使用される可能性があります。
Additional information:
追加情報：
The following applies to stored-file transfer methods:
以下は、保管ファイル転送方式に適用されます。
Magic numbers: #!G7110A\n or #!G7110M\n (for A-law or MU-law encodings respectively, see Section 6).
マジックナンバー：＃！G7110A \ nまたは＃！G7110M \ n（A-lawまたはMU-lawエンコーディングについては、セクション6を参照）。
File Extensions: None
ファイル拡張子：なし
Macintosh file type code: None
Macintoshファイルタイプコード：なし
Object identifier or OIL: None
オブジェクト識別子またはOIL：なし
Person & email address to contact for further information:
詳細について連絡する人とメールアドレス：
Michael A. Ramalho <mramalho@cisco.com> or <mar42@cornell.edu>
Intended usage: COMMON
使用目的：COMMON
Restrictions on usage:
使用上の制限：
This media type depends on RTP framing, and hence is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time.
このメディアタイプはRTPフレーミングに依存するため、RTP [RFC3550]を介した転送に対してのみ定義されます。現在、他のフレーミングプロトコル内のトランスポートは定義されていません。
Author: Michael A. Ramalho Change controller:
著者：Michael A. Ramalho変更コントローラー：
IETF Payload working group delegated from the IESG.
IESGから委任されたIETFペイロードワーキンググループ。
The information carried in the media type specification has a specific mapping to fields in SDP, which is commonly used to describe an RTP session. When SDP is used to specify sessions employing G.711.0, the mapping is as follows:
メディアタイプ仕様で伝達される情報には、RTPセッションを説明するために一般的に使用されるSDPのフィールドへの特定のマッピングがあります。 SDPを使用してG.711.0を使用するセッションを指定する場合、マッピングは次のようになります。
o The media type ("audio") goes in SDP "m=" as the media name.
o メディアタイプ（「オーディオ」）は、メディア名としてSDP「m =」に入ります。
o The media subtype ("G711-0") goes in SDP "a=rtpmap" as the encoding name.
o メディアサブタイプ（ "G711-0"）は、エンコーディング名としてSDP "a = rtpmap"に入ります。
o The required parameter "rate" also goes in "a=rtpmap" as the clock rate.
o 必須パラメーター「rate」も、クロックレートとして「a = rtpmap」に入ります。
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
o パラメータ「ptime」と「maxptime」は、SDPの「a = ptime」属性と「a = maxptime」属性にそれぞれ入ります。
o Remaining parameters go in the SDP "a=fmtp" attribute by copying them directly from the media type string as a semicolon-separated list of parameter=value pairs.
o 残りのパラメーターは、パラメータータイプ=値のペアのセミコロン区切りのリストとしてメディアタイプ文字列から直接コピーすることにより、SDPの「a = fmtp」属性に入ります。
The following considerations apply when using the SDP offer/answer mechanism [RFC3264] to negotiate the "channels" attribute.
SDPオファー/アンサーメカニズム[RFC3264]を使用して「チャネル」属性をネゴシエートする場合、次の考慮事項が適用されます。
o If the offering endpoint specifies a value for the optional channels parameter that is greater than one, and the answering endpoint both understands the parameter and cannot support that value requested, the answer MUST contain the optional channels parameter with the highest value it can support.
o オファリングエンドポイントが1より大きいオプションチャネルパラメーターの値を指定し、応答エンドポイントの両方がパラメーターを理解し、要求されたその値をサポートできない場合、応答には、サポートできる最大値のオプションチャネルパラメーターを含める必要があります。
o If the offering endpoint specifies a value for the optional channels parameter, the answer MUST contain the optional channels parameter unless the only value the answering endpoint can support is one, in which case the answer MAY contain the optional channels parameter with a value of 1.
o オファリングエンドポイントがオプションチャネルパラメータの値を指定する場合、応答エンドポイントがサポートできる唯一の値が1でない限り、回答はオプションチャネルパラメータを含む必要があります。その場合、回答は値1のオプションチャネルパラメータを含むことができます（MAY）。
o If the offering endpoint specifies a value for the ptime parameter that the answering endpoint cannot support, the answer MUST contain the optional ptime parameter.
o オファリングエンドポイントが、応答側エンドポイントがサポートできないptimeパラメータの値を指定する場合、応答にはオプションのptimeパラメータが含まれている必要があります。
o If the offering endpoint specifies a value for the maxptime parameter that the answering endpoint cannot support, the answer MUST contain the optional maxptime parameter.
o オファリングエンドポイントが応答側エンドポイントがサポートできないmaxptimeパラメータの値を指定する場合、応答にはオプションのmaxptimeパラメータが含まれている必要があります。
The following examples illustrate how to signal G.711.0 via SDP.
次の例は、SDPを介してG.711.0をシグナリングする方法を示しています。
m=audio RTP/AVP 98
a=rtpmap:98 G711-0/8000
a=fmtp:98 complaw=mu
In the above example, the dynamic payload type 98 is mapped to G.711.0 via the "a=rtpmap" parameter. The mandatory "complaw" is on the "a=fmtp" parameter line. Note that neither optional parameters "ptime" nor "channels" is present; although, it is generally good form to include "ptime" in the SDP if the session is a constant ptime session for diagnostic purposes.
上記の例では、動的ペイロードタイプ98は、「a = rtpmap」パラメータを介してG.711.0にマッピングされます。必須の「complaw」は「a = fmtp」パラメーター行にあります。オプションのパラメーター「ptime」も「channels」も存在しないことに注意してください。ただし、セッションが診断目的の一定のptimeセッションである場合は、SDPに「ptime」を含めるのが一般的に適切な形式です。
The following example illustrates an offering endpoint requesting 2 channels, but the answering endpoint can only support (or render) one channel.
次の例は、2つのチャネルを要求するオファリングエンドポイントを示していますが、応答エンドポイントは1つのチャネルしかサポート（またはレンダリング）できません。
Offer:
提供：
m=audio RTP/AVP 98
a=rtpmap:98 G711-0/8000/2
a=ptime:20
a=fmtp:98 complaw=al
Answer:
回答：
m=audio RTP/AVP 98
a=rtpmap: 98 G711-0/8000/1
a=ptime: 20
a=fmtp:98 complaw=al
In this example, the offer had an optional channels parameter. The answer must have the optional channels parameter also unless the value in the answer is one. Shown here is when the answer explicitly contains the channels parameter (it need not have and it would be interpreted as one channel). As mentioned previously, it is considered good form to include "ptime" in the SDP for session diagnostic purposes if the session is a constant ptime session.
この例では、オファーにオプションのチャネルパラメータがありました。回答の値が1でない限り、回答にはオプションのchannelパラメータも必要です。ここに示されているのは、回答にChannelsパラメータが明示的に含まれている場合です（必須ではなく、1つのチャネルとして解釈されます）。前述のように、セッションが一定のptimeセッションである場合は、セッション診断の目的で「ptime」をSDPに含めることをお勧めします。
The G.711.0 storage mode definition in this section is similar to many other IETF codecs (e.g., iLBC RFC 3951 [RFC3951] and EVRC-NW RFC 6884 [RFC6884]), and is essentially a concatenation of individual G.711.0 frames.
このセクションのG.711.0ストレージモードの定義は、他の多くのIETFコーデック（たとえば、iLBC RFC 3951 [RFC3951]およびEVRC-NW RFC 6884 [RFC6884]）に類似しており、基本的に個々のG.711.0フレームの連結です。
We note that something must be stored for any G.711.0 frames that are not received at the receiving endpoint, no matter what the cause. In this section, we describe two mechanisms, a "G.711.0 PLC Frame" and a "G.711.0 Erasure Frame". These G.711.0 PLC and G.711.0 Erasure Frames are described prior to the G.711.0 storage mode definition for clarity.
原因に関係なく、受信エンドポイントで受信されないG.711.0フレームについては何かを保存する必要があることに注意してください。このセクションでは、「G.711.0 PLCフレーム」と「G.711.0消去フレーム」の2つのメカニズムについて説明します。これらのG.711.0 PLCおよびG.711.0消去フレームは、明確にするためにG.711.0ストレージモード定義の前に説明されています。
When G.711 RTP payloads are not received by a rendering endpoint, a PLC mechanism is typically employed to "fill in" the missing G.711 symbols with something that is auditorially pleasing; thus, the loss may be not noticed by a listener. Such a PLC mechanism for G.711 is specified in ITU-T Rec. G.711 - Appendix 1 [G.711-AP1].
G.711 RTPペイロードがレンダリングエンドポイントによって受信されない場合、通常、PLCメカニズムを使用して、欠落しているG.711シンボルを聴覚的に楽しいもので「埋めます」。したがって、損失はリスナーに気付かれない場合があります。 G.711のそのようなPLCメカニズムは、ITU-T Rec。 G.711-付録1 [G.711-AP1]。
A natural extension when creating G.711.0 frames for storage environments is to employ such a PLC mechanism to create G.711 symbols for the span of time in which G.711.0 payloads were not received -- and then to compress the resulting "G.711 PLC symbols" via G.711.0 compression. The G.711.0 frame(s) created by such a process are called "G.711.0 PLC Frames".
ストレージ環境用にG.711.0フレームを作成するときの自然な拡張は、このようなPLCメカニズムを使用して、G.711.0ペイロードが受信されなかった期間のG.711シンボルを作成し、結果の "G. G.711.0圧縮による711 PLCシンボル」。このようなプロセスで作成されたG.711.0フレームは、「G.711.0 PLCフレーム」と呼ばれます。
Since PLC mechanisms are designed to render missing audio data with the best fidelity and intelligibility, G.711.0 frames created via such processing is likely best for most recording situations (such as voicemail storage) unless there is a requirement not to fabricate (audio) data not actually received.
PLCメカニズムは欠落したオーディオデータを最高の忠実度と明瞭度でレンダリングするように設計されているため、このような処理で作成されたG.711.0フレームは、（オーディオ）データを作成しないという要件がない限り、ほとんどの録音状況（ボイスメールストレージなど）に最適です。実際には受け取っていません。
After such PLC G.711 symbols have been generated and then encoded by a G.711.0 encoder, the resulting frames may be stored in G.711.0 frame format. As a result, there is nothing to specify here -- the G.711.0 PLC frames are stored as if they were received by the receiving endpoint. In other words, PLC-generated G.711.0 frames appear as "normal" or "ordinary" G.711.0 frames in the storage mode file.
このようなPLC G.711シンボルが生成され、G.711.0エンコーダーによってエンコードされた後、結果のフレームはG.711.0フレーム形式で保存されます。その結果、ここでは何も指定する必要はありません。G.711.0PLCフレームは、受信側エンドポイントによって受信されたかのように格納されます。つまり、PLCで生成されたG.711.0フレームは、ストレージモードファイルで「通常」または「通常」のG.711.0フレームとして表示されます。
"Erasure Frames", or equivalently "Null Frames", have been designed for many frame-based codecs since G.711 was standardized. These null/erasure frames explicitly represent data from incoming audio that were either not received by the receiving system or represent data that a transmitting system decided not to send. Transmitting systems may choose not to send data for a variety of reasons (e.g., not enough wireless link capacity in radio-based systems) and can choose to send a "null frame" in lieu of the actual audio. It is also envisioned that erasure frames would be used in storage mode applications for specific archival purposes where there is a requirement not to fabricate audio data that was not actually received.
「消去フレーム」または同等の「ヌルフレーム」は、G.711が標準化されて以来、多くのフレームベースのコーデック用に設計されています。これらのヌル/消去フレームは、受信システムによって受信されなかった、または送信システムが送信しないことを決定したデータを表す着信オーディオからのデータを明示的に表します。送信システムは、さまざまな理由（たとえば、無線ベースのシステムでは無線リンク容量が不十分）でデータを送信しないことを選択する場合があり、実際のオーディオの代わりに「nullフレーム」を送信することを選択できます。消去フレームは、実際に受信されなかったオーディオデータを作成しないという要件がある特定のアーカイブ目的のストレージモードアプリケーションで使用されることも想定されています。
Thus, a G.711.0 erasure frame is a representation of the amount of time in G.711.0 frames that were not received or not encoded by the transmitting system.
したがって、G.711.0消去フレームは、送信システムによって受信されなかった、またはエンコードされなかったG.711.0フレーム内の時間量の表現です。
Prior to defining a G.711.0 erasure frame, it is beneficial to note what many G.711 RTP systems send when the endpoint is "muted". When muted, many of these systems will send an entire G.711 payload of either 0+ or 0- (i.e., one of the two levels closest to "analog zero" in either G.711 companding law). Next we note that a desirable property for a G.711.0 erasure frame is for "non-G.711.0 Erasure Frame-aware" endpoints to be able to playback a G.711.0 erasure frame with the existing G.711.0 ITU-T reference code.
G.711.0消去フレームを定義する前に、エンドポイントが「ミュート」されているときに多くのG.711 RTPシステムが送信するものを記録しておくと役立ちます。ミュートすると、これらのシステムの多くは0+または0-のG.711ペイロード全体を送信します（つまり、いずれかのG.711圧縮法の「アナログゼロ」に最も近い2つのレベルの1つ）。次に、G.711.0消去フレームの望ましいプロパティは、「非G.711.0消去フレーム対応」エンドポイントが既存のG.711.0 ITU-T参照コードでG.711.0消去フレームを再生できるようにすることです。 。
A G.711.0 Erasure Frame is defined as any G.711.0 frame for which the corresponding G.711 sample values are either the value 0++ or the value 0-- for the entirety of the G.711.0 frame. The levels of 0++ and 0-- are defined to be the two levels above or below analog zero, respectively. An entire frame of value 0++ or 0-- is expected to be extraordinarily rare when the frame was in fact generated by a natural signal, as analog inputs such as speech and music are zero-mean and are typically acoustically coupled to digital sampling systems. Note that the playback of a G.711.0 frame characterized as an erasure frame is auditorially equivalent to a muted signal (a very low value constant).
G.711.0消去フレームは、G.711.0フレーム全体で、対応するG.711サンプル値が値0 ++または値0--のいずれかであるG.711.0フレームとして定義されます。 0 ++および0--のレベルは、それぞれアナログゼロより上または下の2つのレベルと定義されています。音声や音楽などのアナログ入力はゼロ平均であり、通常はデジタルサンプリングに音響的に結合されるため、フレームが実際に自然信号によって生成された場合、値0 ++または0--のフレーム全体が非常にまれであると予想されます。システム。消去フレームとして特徴付けられるG.711.0フレームの再生は、ミュートされた信号（非常に低い値の定数）と聴覚的に同等であることに注意してください。
These G.711.0 erasure frames can be reasonably characterized as null or erasure frames while meeting the desired playback goal of being decoded by the G.711.0 ITU-T reference code. Thus, similarly to G.711 PLC frames, the G.711.0 erasure frames appear as "normal" or "ordinary" G.711.0 frames in the storage mode format.
これらのG.711.0消去フレームは、G.711.0 ITU-T参照コードによってデコードされるという望ましい再生目標を満たしながら、ヌルまたは消去フレームとして合理的に特徴付けることができます。したがって、G.711 PLCフレームと同様に、G.711.0消去フレームは、ストレージモード形式で「通常」または「通常」のG.711.0フレームとして表示されます。
The storage format is used for storing G.711.0 encoded frames. The format for the G.711.0 storage mode file defined by this RFC is shown below.
格納形式は、G.711.0エンコードフレームの格納に使用されます。このRFCで定義されているG.711.0ストレージモードファイルの形式を以下に示します。
|---------------------------|----------|--------------|
| Magic Number | | |
| | Version | Concatenated |
| "#!G7110A\n" (for A-law) | Octet | G.711.0 |
| or | | Frames |
| "#!G7110M\n" (for mu-law) | "0x00" | |
|___________________________|__________|______________|
Figure 5: G.711.0 Storage Mode Format
図5：G.711.0ストレージモードの形式
The storage mode file consists of a magic number and a version octet followed by the individual G.711.0 frames concatenated together.
ストレージモードファイルは、マジックナンバーとバージョンオクテットで構成され、その後に個別のG.711.0フレームが連結されます。
The magic number for G.711.0 A-law corresponds to the ASCII character string "#!G7110A\n", i.e., "0x23 0x21 0x47 0x37 0x31 0x31 0x30 0x41 0x0A". Likewise, the magic number for G.711.0 MU-law corresponds to the ASCII character string "#!G7110M\n", i.e., "0x23 0x21 0x47 0x37 0x31 0x31 0x4E 0x4D 0x0A".
G.711.0 A-lawのマジックナンバーは、ASCII文字列「＃！G7110A \ n」に対応しています。つまり、「0x23 0x21 0x47 0x37 0x31 0x31 0x30 0x41 0x0A」です。同様に、G.711.0 MU-lawのマジックナンバーは、ASCII文字列「＃！G7110M \ n」に対応しています。つまり、「0x23 0x21 0x47 0x37 0x31 0x31 0x4E 0x4D 0x0A」です。
The version number octet allows for the future specification of other G.711.0 storage mode formats. The specification of other storage mode formats may be desirable as G.711.0 frames are of variable length and a future format may include an indexing methodology that would enable playout far into a long G.711.0 recording without the necessity of decoding all the G.711.0 frames since the beginning of the recording. Other future format specification may include support for multiple channels, metadata, and the like. For these reasons, it was determined that a versioning strategy was desirable for the G.711.0 storage mode definition specified by this RFC. This RFC only specifies Version 0 and thus the value of "0x00" MUST be used for the storage mode defined by this RFC.
バージョン番号オクテットは、他のG.711.0ストレージモードフォーマットの将来の仕様に対応しています。 G.711.0フレームは可変長であり、将来のフォーマットには、すべてのG.711.0をデコードする必要なしに長いG.711.0レコーディングへの再生を可能にするインデックス付け方法が含まれる可能性があるため、他のストレージモードフォーマットの仕様が望ましい場合があります。記録の開始以降のフレーム。その他の将来のフォーマット仕様には、複数のチャネル、メタデータなどのサポートが含まれる可能性があります。これらの理由により、このRFCで指定されているG.711.0ストレージモード定義にはバージョン管理戦略が望ましいと判断されました。このRFCはバージョン0のみを指定しているため、このRFCで定義されているストレージモードには「0x00」の値を使用する必要があります。
The G.711.0 codec data frames, including any necessary erasure or PLC frames, are stored in consecutive order concatenated together as shown in Section 4.2.2. As the Version 0 storage mode only supports a single channel, the RTP payload format supporting multiple channels defined in Section 4.2.4 is not supported in this storage mode definition.
セクション4.2.2に示すように、G.711.0コーデックデータフレームは、必要な消去フレームまたはPLCフレームを含め、連結された連続した順序で格納されます。バージョン0ストレージモードは単一のチャネルのみをサポートするため、セクション4.2.4で定義された複数のチャネルをサポートするRTPペイロード形式は、このストレージモード定義ではサポートされません。
To decode the individual G.711.0 frames, the algorithm presented in Section 4.2.2 may be used to decode the individual G.711.0 frames. If the version octet is determined not to be zero, the remainder of the payload MUST NOT be passed to the G.711.0 decoder, as the ITU-T G.711.0 reference decoder can only decode concatenated G.711.0 frames and has not been designed to decode elements in yet to be specified future storage mode formats.
個々のG.711.0フレームをデコードするには、セクション4.2.2に示すアルゴリズムを使用して、個々のG.711.0フレームをデコードできます。バージョンオクテットがゼロでないと判断された場合、ITU-T G.711.0リファレンスデコーダーは連結されたG.711.0フレームのみをデコードでき、設計されていないため、ペイロードの残りをG.711.0デコーダーに渡してはなりません（MUST NOT）。まだ指定されていない将来のストレージモード形式で要素をデコードします。
One media type (audio/G711-0) has been defined and registered in IANA's "Media Types" registry. See Section 5.1 for details.
1つのメディアタイプ（audio / G711-0）が定義され、IANAの「Media Types」レジストリに登録されています。詳細については、セクション5.1を参照してください。
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550], and in any applicable RTP profile (such as RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711], or RTP/ SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] discusses, it is not a responsibility of the RTP payload format to discuss or mandate what solutions are used to meet the basic security goals like confidentiality, integrity, and source authenticity for RTP in general. This responsibility lays on anyone using RTP in an application. They can find guidance on available security mechanisms and important considerations in "Options for Securing RTP Sessions" [RFC7201]. Applications SHOULD use one or more appropriate strong security mechanisms. The rest of this Security Considerations section discusses the security impacting properties of the playload format itself.
この仕様で定義されているペイロード形式を使用するRTPパケットは、RTP仕様[RFC3550]および適用可能なすべてのRTPプロファイル（RTP / AVP [RFC3551]、RTP / AVPF [RFC4585]、RTP / SAVP [RFC3711]、またはRTP / SAVPF [RFC5124]。ただし、「RTPプロトコルフレームワークの保護：RTPが単一のメディアセキュリティソリューションを義務付けない理由」[RFC7202]が説明しているように、RTPペイロード形式の責任はありません。一般的にRTPの機密性、整合性、ソースの信頼性などの基本的なセキュリティ目標を達成するために使用されるソリューションについて話し合いまたは義務付けます。この責任は、アプリケーションでRTPを使用するすべての人にあります。利用可能なセキュリティメカニズムと重要な考慮事項に関するガイダンスは、「 RTPセッションを保護するためのオプション」[RFC7201]。アプリケーションは、1つ以上の適切な強力なセキュリティメカニズムを使用する必要があります。この「セキュリティに関する考慮事項」セクションの残りの部分では、plaのセキュリティに影響を与えるプロパティについて説明しますyloadフォーマット自体。
Because the data compression used with this payload format is applied end-to-end, any encryption needs to be performed after compression.
このペイロード形式で使用されるデータ圧縮はエンドツーエンドで適用されるため、暗号化は圧縮後に実行する必要があります。
Note that end-to-end security with either authentication, integrity, or confidentiality protection will prevent a network element not within the security context from performing media-aware operations other than discarding complete packets. To allow any (media-aware) intermediate network element to perform its operations, it is required to be a trusted entity that is included in the security context establishment.
認証、整合性、または機密保護のいずれかを備えたエンドツーエンドのセキュリティでは、セキュリティコンテキスト内にないネットワーク要素が、完全なパケットを破棄する以外のメディア対応操作を実行できないことに注意してください。 （メディア対応）中間ネットワーク要素がその操作を実行できるようにするには、セキュリティコンテキストの確立に含まれる信頼されたエンティティである必要があります。
G.711.0 has no known denial-of-service (DoS) attacks due to decoding, as data posing as a desired G711.0 payload will be decoded into something (as per the decoding algorithm) with a finite amount of computation. This is due to the decompression algorithm having a finite worst-case processing path (no infinite computational loops are possible). We also note that the data read by the G.711.0 decoder is controlled by the length of the individual encoded G.711.0 frame(s) contained in the RTP payload. The decoding algorithm specified previously in Section 4.2.3 ensures that the G.711.0 decoder will not read beyond the length of the internal buffer specified (which is in turn specified to be no greater than the largest possible G.711.0 frame of 321 octets). Therefore, a G.711.0 payload does not carry "active content" that could impose malicious side-effects upon the receiver.
G.711.0には、解読による既知のサービス拒否（DoS）攻撃がありません。目的のG711.0ペイロードを装ったデータは、（解読アルゴリズムに従って）有限の計算量で解読されるためです。これは、有限の最悪の場合の処理パスを持つ解凍アルゴリズムによるものです（無限の計算ループは不可能です）。また、G.711.0デコーダーによって読み取られるデータは、RTPペイロードに含まれる個々のエンコードされたG.711.0フレームの長さによって制御されることにも注意してください。セクション4.2.3で以前に指定されたデコードアルゴリズムは、G.711.0デコーダーが指定された内部バッファー（321オクテットの可能な最大のG.711.0フレーム以下になるように指定されている）の長さを超えて読み取らないことを保証します。したがって、G.711.0ペイロードには、受信者に悪意のある副作用をもたらす可能性のある「アクティブコンテンツ」は含まれていません。
G.711.0 is a VBR audio codec. There have been recent concerns with VBR speech codecs where a passive observer can identify phrases from a standard speech corpus by means of the lengths produced by the encoder even when the payload is encrypted [IEEE]. In this paper, it was determined that some Code-Excited Linear Prediction (CELP) codecs would produce discrete packet lengths for some phonemes. Furthermore, with the use of appropriately designed Hidden Markov Models (HMMs), such a system could predict phrases with unexpected accuracy. One CELP codec studied, SPEEX, had the property that produced 21 different packet lengths in its wideband mode, and these packet lengths probabilistically mapped to phonemes that an HMM system could be trained on. In this paper, it was determined that a mitigation technique would be to pad the output of the encoder with random padding lengths to the effect: 1) that more discrete payload sizes would result, and 2) that the probabilistic mapping to phonemes would become less clear. As G.711 is not a speech-model-based codec, neither is G.711.0. A G.711.0 encoding, during talking periods, produces frames of varying frame lengths that are not likely to have a strong mapping to phonemes. Thus, G.711.0 is not expected to have this same vulnerability. It should be noted that "silence" (only one value of G.711 in the entire G.711 input frame) or "near silence" (only a few G.711 values) is easily detectable as G.711.0 frame lengths or one or a few octets. If one desires to mitigate for silence/non-silence detection, statistically variable padding should be added to G.711.0 frames that resulted in very small G.711.0 frames (less than about 20% of the symbols of the corresponding G.711 input frame). Methods of introducing padding in the G.711.0 payloads have been provided in the G.711.0 RTP payload definition in Section 4.2.2.
G.711.0はVBRオーディオコーデックです。ペイロードが暗号化されている場合でも、パッシブオブザーバーがエンコーダーによって生成された長さによって標準のスピーチコーパスからフレーズを識別できるVBRスピーチコーデックに最近の懸念があります[IEEE]。このホワイトペーパーでは、一部のCode-Excited Linear Prediction（CELP）コーデックが一部の音素に対して個別のパケット長を生成することが判明しました。さらに、適切に設計された隠しマルコフモデル（HMM）を使用すると、このようなシステムは予期しない精度でフレーズを予測できます。調査した1つのCELPコーデックであるSPEEXには、ワイドバンドモードで21の異なるパケット長を生成するプロパティがあり、これらのパケット長は、HMMシステムをトレーニングできる音素に確率論的にマッピングされていました。このホワイトペーパーでは、軽減策として、エンコーダの出力にランダムなパディング長でパディングを行うことで、1）より多くの離散的なペイロードサイズが得られ、2）音素への確率的マッピングが少なくなると判断しました。晴れ。 G.711は音声モデルベースのコーデックではないため、G.711.0も同様です。 G.711.0エンコーディングは、通話期間中に、音素への強力なマッピングがありそうにないさまざまなフレーム長のフレームを生成します。したがって、G.711.0にはこれと同じ脆弱性があるとは予想されていません。 「無音」（G.711入力フレーム全体でG.711の1つの値のみ）または「ほぼ無音」（少数のG.711値のみ）は、G.711.0フレーム長または1つとして簡単に検出できることに注意してください。または数オクテット。無音/無音検出を軽減したい場合は、統計的に可変のパディングをG.711.0フレームに追加して、G.711.0フレームを非常に小さくする必要があります（対応するG.711入力フレームのシンボルの約20％未満） ）。 G.711.0ペイロードにパディングを導入する方法は、セクション4.2.2のG.711.0 RTPペイロード定義で提供されています。
The G.711 codec is a Constant Bit Rate (CBR) codec that does not have a means to regulate the bitrate. The G.711.0 lossless compression algorithm typically compresses the G.711 CBR stream into a lower-bandwidth VBR stream. However, being lossless, it does not possess means of further reducing the bitrate beyond the compression result based on G.711.0. The G.711.0 RTP payloads can be made arbitrarily large by means of adding optional padding bytes (subject only to MTU limitations).
G.711コーデックは、ビットレートを調整する手段を持たない固定ビットレート（CBR）コーデックです。 G.711.0ロスレス圧縮アルゴリズムは、通常、G.711 CBRストリームを低帯域幅VBRストリームに圧縮します。ただし、ロスレスであるため、G.711.0に基づく圧縮結果を超えてビットレートをさらに削減する手段はありません。 G.711.0 RTPペイロードは、オプションのパディングバイトを追加することにより、任意に大きくすることができます（MTUの制限のみに従う）。
Therefore, there are no explicit ways to regulate the bit rate of the transmissions outlined in this RTP payload format except by means of modulating the number of optional padding bytes in the RTP payload.
したがって、RTPペイロードのオプションのパディングバイト数を変調する以外に、このRTPペイロード形式で概説されている送信のビットレートを規制する明示的な方法はありません。
[G.711] ITU-T, "Pulse Code Modulation (PCM) of Voice Frequencies", ITU-T Recommendation G.711 PCM, 1988.
[G.711] ITU-T、「音声周波数のパルス符号変調（PCM）」、ITU-T勧告G.711 PCM、1988。
[G.711-A1] ITU-T, "New Annex A on Lossless Encoding of PCM Frames", ITU-T Recommendation G.711 Amendment 1, 2009.
[G.711-A1] ITU-T、「PCMフレームのロスレスエンコーディングに関する新しい付録A」、ITU-T勧告G.711修正1、2009。
[G.711-AP1] ITU-T, "A high quality low-complexity algorithm for packet loss concealment with G.711", ITU-T Recommendation G.711 AP1, 1999.
[G.711-AP1] ITU-T、「G.711によるパケット損失隠蔽のための高品質低複雑性アルゴリズム」、ITU-T勧告G.711 AP1、1999。
[G.711.0] ITU-T, "Lossless Compression of G.711 Pulse Code Modulation", ITU-T Recommendation G.711 LC PCM, 2009.
[G.711.0] ITU-T、「G.711パルスコード変調のロスレス圧縮」、ITU-T勧告G.711 LC PCM、2009。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <http://www.rfc-editor.org/info/rfc3264>.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション記述プロトコル（SDP）を備えたオファー/アンサーモデル」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<http://www.rfc-editor.org / info / rfc3264>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、 <http://www.rfc-editor.org/info/rfc3550>。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, <http://www.rfc-editor.org/info/rfc3551>.
[RFC3551] Schulzrinne、H。およびS. Casner、「Minimal Controlを使用したオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、DOI 10.17487 / RFC3551、2003年7月、<http：//www.rfc-editor。 org / info / rfc3551>。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <http://www.rfc-editor.org/info/rfc3711>.
[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「Secure Real-time Transport Protocol（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、3月2004、<http://www.rfc-editor.org/info/rfc3711>。
[RFC3951] Andersen, S., Duric, A., Astrom, H., Hagen, R., Kleijn, W., and J. Linden, "Internet Low Bit Rate Codec (iLBC)", RFC 3951, DOI 10.17487/RFC3951, December 2004, <http://www.rfc-editor.org/info/rfc3951>.
[RFC3951]アンデルセン、S。、デュリック、A。、アストロム、H。、ハーゲン、R。、クライイン、W、およびJ.リンデン、「インターネット低ビットレートコーデック（iLBC）」、RFC 3951、DOI 10.17487 / RFC3951、2004年12月、<http://www.rfc-editor.org/info/rfc3951>。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<http://www.rfc-editor.org/ info / rfc4566>。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <http://www.rfc-editor.org/info/rfc4585>.
[RFC4585] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイムトランスポートコントロールプロトコル（RTCP）ベースのフィードバック用の拡張RTPプロファイル（RTP / AVPF） "、RFC 4585、DOI 10.17487 / RFC4585、2006年7月、<http://www.rfc-editor.org/info/rfc4585>。
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, <http://www.rfc-editor.org/info/rfc5124>.
[RFC5124] Ott、J。およびE. Carrara、「リアルタイム転送制御プロトコル（RTCP）ベースのフィードバック用の拡張セキュアRTPプロファイル（RTP / SAVPF）」、RFC 5124、DOI 10.17487 / RFC5124、2008年2月、<http ：//www.rfc-editor.org/info/rfc5124>。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc-editor.org/info/rfc6838>.
[RFC6838] Freed、N.、Klensin、J。、およびT. Hansen、「Media Type Specifications and Registration Procedures」、BCP 13、RFC 6838、DOI 10.17487 / RFC6838、2013年1月、<http：//www.rfc- editor.org/info/rfc6838>。
[RFC6884] Fang, Z., "RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW)", RFC 6884, DOI 10.17487/RFC6884, March 2013, <http://www.rfc-editor.org/info/rfc6884>.
[RFC6884] Fang、Z。、「Enhanced Variable Rate Narrowband-Wideband Codec（EVRC-NW）のRTPペイロードフォーマット」、RFC 6884、DOI 10.17487 / RFC6884、2013年3月、<http：//www.rfc-editor。 org / info / rfc6884>。
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <http://www.rfc-editor.org/info/rfc7201>.
[RFC7201] Westerlund、M。およびC. Perkins、「RTPセッションを保護するためのオプション」、RFC 7201、DOI 10.17487 / RFC7201、2014年4月、<http://www.rfc-editor.org/info/rfc7201>。
[RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 2014, <http://www.rfc-editor.org/info/rfc7202>.
[RFC7202] Perkins、C。およびM. Westerlund、「RTPフレームワークの保護：RTPが単一のメディアセキュリティソリューションを義務付けない理由」、RFC 7202、DOI 10.17487 / RFC7202、2014年4月、<http：//www.rfc- editor.org/info/rfc7202>。
[G.722] ITU-T, "7 kHz audio-coding within 64 kbit/s", ITU-T Recommendation G.722, 1988.
[G.722] ITU-T、「64 kHz以内の7 kHzオーディオコーディング」、ITU-T勧告G.722、1988。
[G.729] ITU-T, "Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear prediction (CS-ACELP)", ITU-T Recommendation G.729, 2007.
[G.729] ITU-T、「共役構造代数的コード励起線形予測を使用した8 kbit / sでの音声のコーディング（CS-ACELP）」、ITU-T勧告G.729、2007年。
[ICASSP] Harada, N., Yamamoto, Y., Moriya, T., Hiwasaki, Y., Ramalho, M., Netsch, L., Stachurski, J., Miao, L., Taddei, H., and F. Qi, "Emerging ITU-T Standard G.711.0 - Lossless Compression of G.711 Pulse Code Modulation, International Conference on Acoustics Speech and Signal Processing (ICASSP), 2010, ISBN 978-1-4244-4244-4295-9", March 2010.
[ICASSP]原田直人、山本由紀子、守谷敏夫、日和崎由紀夫、ラマーリョM.、ネットシュL.、スタチュルスキーJ.、ミャオL.、タデイH.、F 。Qi、 "Emerging ITU-T Standard G.711.0-Lossless Compression of G.711 Pulse Code Modulation、International Conference on Acoustics Speech and Signal Processing（ICASSP）、2010、ISBN 978-1-4244-4244-4295-9" 、2010年3月。
[IEEE] Wright, C., Ballard, L., Coull, S., Monrose, F., and G. Masson, "Spot Me if You Can: Uncovering Spoken Phrases in Encrypted VoIP Conversations, IEEE Symposium on Security and Privacy, 2008, ISBN: 978-0-7695-3168-7", May 2008.
[IEEE] Wright、C.、Ballard、L.、Coull、S.、Monrose、F。、およびG. Masson、「できれば私にスポットを当てる：暗号化されたVoIP会話での音声フレーズの発見、セキュリティとプライバシーに関するIEEEシンポジウム、 2008、ISBN：978-0-7695-3168-7 "、2008年5月。
Acknowledgements
謝辞
There have been many people contributing to G.711.0 in the course of its development. The people listed here deserve special mention: Takehiro Moriya, Claude Lamblin, Herve Taddei, Simao Campos, Yusuke Hiwasaki, Jacek Stachurski, Lorin Netsch, Paul Coverdale, Patrick Luthi, Paul Barrett, Jari Hagqvist, Pengjun (Jeff) Huang, John Gibbs, Yutaka Kamamoto, and Csaba Kos. The review and oversight by the IETF Payload working group chairs Ali Begen and Roni Even during the development of this RFC is appreciated. Additionally, the careful review by Richard Barnes, the extensive review by David Black, and the reviews provided by the IESG are likewise very much appreciated.
G.711.0の開発には多くの人が貢献しています。ここにリストされている人々は特別な言及に値します：森谷武弘、クロードラムブリン、エルベタデイ、シマオカンポス、ヒワサキユウスケ、ヤチェクシュタルスキー、ロリンネッチ、ポールカバーデール、パトリックルティ、ポールバレット、ヤリハグクビスト、ペンジュン（ジェフ）フアン、ジョンギブス、鎌本豊、Csaba Kos。 IERF Payloadワーキンググループの議長であるAli BegenとRoniによるレビューと監視は、このRFCの開発中も高く評価されています。さらに、Richard Barnesによる慎重なレビュー、David Blackによる広範なレビュー、およびIESGによるレビューも同様に非常に高く評価されています。
Contributors
貢献者
The authors thank everyone who have contributed to this document. The people listed here deserve special mention: Ali Begen, Roni Even, and Hadriel Kaplan.
著者は、このドキュメントに貢献してくれたすべての人に感謝します。ここにリストされている人々は、特別な言及に値します：Ali Begen、Roni Even、およびHadriel Kaplan。
Authors' Addresses
著者のアドレス
Michael A. Ramalho (editor) Cisco Systems, Inc. 6310 Watercrest Way Unit 203 Lakewood Ranch, FL 34202 United States Phone: +1 919 476 2038 Email: mramalho@cisco.com Paul E. Jones Cisco Systems, Inc. 7025 Kit Creek Road Research Triangle Park, NC 27709 United States
Michael A. Ramalho（編集者）Cisco Systems、Inc. 6310 Watercrest Way Unit 203 Lakewood Ranch、FL 34202 United States電話：+1 919 476 2038メール：mramalho@cisco.com Paul E. Jones Cisco Systems、Inc. 7025 Kit Creek Road Research Triangle Park、NC 27709アメリカ合衆国
Phone: +1 919 476 2048
Email: paulej@packetizer.com
Noboru Harada NTT Communications Science Labs 3-1 Morinosato-Wakamiya Atsugi, Kanagawa 243-0198 Japan
のぼる はらだ んっｔ こっむにかちおんｓ Ｓしえんせ ぁｂｓ ３ー１ もりのさとーわかみや あつぎ、 かながわ ２４３ー０１９８ じゃぱん
Phone: +81 46 240 3676
Email: harada.noboru@lab.ntt.co.jp
Muthu Arul Mozhi Perumal Ericsson Ferns Icon Doddanekundi, Mahadevapura Bangalore, Karnataka 560037 India
Mutu Arul Mozhi Perumal Reichsvn Ferns Icon Palliyankundi、Mahadevapur Bangalore、Karnataka ೫೬೦೦೩೭インド
Phone: +91 9449288768
Email: muthu.arul@gmail.com
Lei Miao Huawei Technologies Co. Ltd Q22-2-A15R, Environment Protection Park No. 156 Beiqing Road HaiDian District Beijing 100095 China
l EI Mia oh UA is Technologies co。Ltd Q22-2-A15R、環境保護公園番号156 be i青道路ha ID Ian地区北京100095中国
Phone: +86 1059728300
Email: lei.miao@huawei.com