[要約] RFC 5391は、ITU-T勧告G.711.1のためのRTPペイロード形式を定義しています。このRFCの目的は、G.711.1コーデックを使用して音声をRTPパケットにエンコードするための標準化を提供することです。
Network Working Group A. Sollaud
Request for Comments: 5391 France Telecom
Category: Standards Track November 2008
RTP Payload Format for ITU-T Recommendation G.711.1
ITU-T推奨のRTPペイロード形式G.711.1
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2008 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.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the ITU Telecommunication Standardization Sector (ITU-T) G.711.1 audio codec. Two media type registrations are also included.
このドキュメントは、ITU Telecommunication Standardizationセクター（ITU-T）G.711.1オーディオコーデックに使用するリアルタイムトランスポートプロトコル（RTP）ペイロード形式を指定します。2つのメディアタイプの登録も含まれています。
Table of Contents
目次
1. Introduction ....................................................2
2. Background ......................................................2
3. RTP Header Usage ................................................3
4. Payload Format ..................................................4
4.1. Payload Header .............................................4
4.2. Audio Data .................................................5
5. Payload Format Parameters .......................................6
5.1. PCMA-WB Media Type Registration ............................7
5.2. PCMU-WB Media Type Registration ............................8
5.3. Mapping to SDP Parameters ..................................9
5.3.1. Offer-Answer Model Considerations ...................9
5.3.2. Declarative SDP Considerations .....................11
6. G.711 Interoperability .........................................11
7. Congestion Control .............................................12
8. Security Considerations ........................................12
9. IANA Considerations ............................................12
10. References ....................................................13
10.1. Normative References .....................................13
10.2. Informative References ...................................13
The ITU Telecommunication Standardization Sector (ITU-T) Recommendation G.711.1 [ITU-G.711.1] is an embedded wideband extension of the Recommendation G.711 [ITU-G.711] audio codec. This document specifies a payload format for packetization of G.711.1 encoded audio signals into the Real-time Transport Protocol (RTP).
ITU Telecommunication Standardizationセクター（ITU-T）推奨G.711.1 [ITU-G.711.1]は、推奨G.711 [ITU-G.711]オーディオコーデックの埋め込み広帯域拡張です。このドキュメントは、G.711.1エンコードされたオーディオ信号をリアルタイムトランスポートプロトコル（RTP）にパケット化するためのペイロード形式を指定します。
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 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
G.711.1 is a G.711 embedded wideband speech and audio coding algorithm operating at 64, 80, and 96 kbps. At 64 kbps, G.711.1 is fully interoperable with G.711. Hence, an efficient deployment in existing G.711-based Voice over IP (VoIP) infrastructures is foreseen.
G.711.1は、64、80、および96 kbpsで動作するG.711埋め込みワイドバンド音声およびオーディオコーディングアルゴリズムです。64 kbpsでは、G.711.1はG.711と完全に相互運用可能です。したがって、既存のG.711ベースの音声オーバーIP（VOIP）インフラストラクチャに効率的な展開が予見されています。
The codec operates on 5-ms frames, and the default sampling rate is 16 kHz. Input and output at 8 kHz are also supported for narrowband modes.
コーデックは5 msフレームで動作し、デフォルトのサンプリングレートは16 kHzです。8 kHzでの入力と出力も、狭帯域モードでサポートされています。
The encoder produces an embedded bitstream structured in three layers corresponding to three available bit rates: 64, 80, and 96 kbps. The bitstream can be truncated at the decoder side or by any component of the communication system to adjust, "on the fly", the bit rate to the desired value.
エンコーダは、3つの利用可能なビットレートに対応する3つの層で構成された埋め込みビットストリームを生成します：64、80、および96 kbps。ビットストリームは、デコーダー側で、または通信システムの任意のコンポーネントによって切り捨てられ、「オンザフライ」で、ビットレートを目的の値に合わせて調整できます。
The following table gives more details on these layers.
次の表は、これらのレイヤーの詳細を示しています。
+-------+------------------------+----------+
| Layer | Description | Bit rate |
+-------+------------------------+----------+
| L0 | G.711 compatible | 64 kbps |
| L1 | narrowband enhancement | 16 kbps |
| L2 | wideband enhancement | 16 kbps |
+-------+------------------------+----------+
Table 1: Layers description
表1：レイヤーの説明
The combinations of these three layers results in the definition of four modes, as per the following table.
これら3つの層の組み合わせにより、次の表に従って、4つのモードの定義が生じます。
+------+----+----+----+------------+----------+
| Mode | L0 | L1 | L2 | Audio band | Bit rate |
+------+----+----+----+------------+----------+
| R1 | x | | | narrowband | 64 kbps |
| R2a | x | x | | narrowband | 80 kbps |
| R2b | x | | x | wideband | 80 kbps |
| R3 | x | x | x | wideband | 96 kbps |
+------+----+----+----+------------+----------+
Table 2: Modes description
表2：モードの説明
The format of the RTP header is specified in [RFC3550]. The payload format defined in this document uses the fields of the header in a manner consistent with that specification.
RTPヘッダーの形式は[RFC3550]で指定されています。このドキュメントで定義されているペイロード形式は、その仕様と一致する方法でヘッダーのフィールドを使用します。
marker (M): G.711.1 does not define anything specific regarding Discontinuous Transmission (DTX), a.k.a. silence suppression. Codec-independent mechanisms may be used, like the generic comfort-noise payload format defined in [RFC3389].
マーカー（M）：G.711.1は、不連続感染（DTX）、別名沈黙抑制に関して特定のものを定義しません。[RFC3389]で定義されている一般的なコンフォートノイズペイロード形式のように、コーデックに依存しないメカニズムが使用される場合があります。
For applications that send either no packets or occasional comfort-noise packets during silence, the first packet of a talkspurt -- that is, the first packet after a silence period during which packets have not been transmitted contiguously -- SHOULD be distinguished by setting the marker bit in the RTP data header to one. The marker bit in all other packets is zero. The beginning of a talkspurt MAY be used to adjust the playout delay to reflect changing network delays. Applications without silence suppression MUST set the marker bit to zero.
沈黙中にパケットや時折の快適なノイズパケットを送信しないアプリケーションの場合、Talkspurtの最初のパケット - つまり、パケットが連続的に送信されていない沈黙期間後の最初のパケットは、設定することによって区別されるべきです。RTPデータヘッダーのマーカービットは1つです。他のすべてのパケットのマーカービットはゼロです。Talkspurtの開始を使用して、プレイアウトの遅延を調整して、ネットワーク遅延の変化を反映することができます。沈黙の抑制なしのアプリケーションは、マーカービットをゼロに設定する必要があります。
payload type (PT): The assignment of an RTP payload type for this packet format is outside the scope of this document, and will not be specified here. It is expected that the RTP profile under which this payload format is being used will assign a payload type for this codec or specify that the payload type is to be bound dynamically (see Section 5.3).
ペイロードタイプ（PT）：このパケット形式のRTPペイロードタイプの割り当ては、このドキュメントの範囲外であり、ここでは指定されません。このペイロード形式が使用されているRTPプロファイルは、このコーデックにペイロードタイプを割り当てるか、ペイロードタイプを動的にバインドすることを指定することが期待されます（セクション5.3を参照）。
timestamp: The RTP timestamp clock frequency is the same as the default sampling frequency: 16 kHz.
タイムスタンプ：RTPタイムスタンプクロック周波数は、デフォルトのサンプリング周波数：16 kHzと同じです。
G.711.1 has also the capability to operate with 8-kHz sampled input/output signals. It does not affect the bitstream, and the decoder does not require a priori knowledge about the sampling rate of the original signal at the input of the encoder. Therefore, depending on the implementation and the audio acoustic capabilities of the devices, the input of the encoder and/or the output of the decoder can be configured at 8 kHz; however, a 16-kHz RTP clock rate MUST always be used.
G.711.1には、8 kHzのサンプリングされた入力/出力信号で動作する機能もあります。ビットストリームには影響しません。デコーダーは、エンコーダの入力での元の信号のサンプリングレートに関する先験的な知識を必要としません。したがって、デバイスの実装とオーディオアコースティック機能に応じて、エンコーダーの入力および/またはデコーダーの出力は8 kHzで構成できます。ただし、16 kHzのRTPクロックレートを常に使用する必要があります。
The duration of one frame is 5 ms, corresponding to 80 samples at 16 kHz. Thus, the timestamp is increased by 80 for each consecutive frame.
1つのフレームの持続時間は5ミリ秒で、16 kHzの80のサンプルに対応しています。したがって、タイムスタンプは、連続したフレームごとに80増加します。
The complete payload consists of a payload header of 1 octet, followed by one or more consecutive G.711.1 audio frames of the same mode.
完全なペイロードは、1オクテットのペイロードヘッダーで構成され、その後、同じモードの1つ以上の連続したG.711.1オーディオフレームが続きます。
The mode may change between packets, but not within a packet.
モードはパケット間で変更される場合がありますが、パケット内では変更されません。
The payload header is illustrated below.
ペイロードヘッダーを以下に示します。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0 0 0 0 0| MI |
+-+-+-+-+-+-+-+-+
The five most significant bits are reserved for further extension and MUST be set to zero and MUST be ignored by receivers.
5つの最も重要なビットはさらなる拡張のために予約されており、ゼロに設定する必要があり、受信機は無視する必要があります。
The Mode Index (MI) field (3 bits) gives the mode of the following frame(s) as per the table:
モードインデックス（MI）フィールド（3ビット）は、テーブルに従って、次のフレームのモードを示します。
+------------+--------------+------------+
| Mode Index | G.711.1 mode | Frame size |
+------------+--------------+------------+
| 1 | R1 | 40 octets |
| 2 | R2a | 50 octets |
| 3 | R2b | 50 octets |
| 4 | R3 | 60 octets |
+------------+--------------+------------+
Table 3: Modes in payload header
表3：ペイロードヘッダーのモード
All other values of MI are reserved for future use and MUST NOT be used.
MIの他のすべての値は将来の使用のために予約されており、使用してはなりません。
Payloads received with an undefined MI value MUST be discarded.
未定義のMI値で受信したペイロードを破棄する必要があります。
If a restricted mode-set has been set up by the signaling (see Section 5), payloads received with an MI value not in this set MUST be discarded.
制限付きモードセットがシグナリングによって設定されている場合（セクション5を参照）、このセットにないMI値で受信したペイロードを破棄する必要があります。
After this payload header, the consecutive audio frames are packed in order of time, that is, oldest first. All frames MUST be of the same mode, indicated by the MI field of the payload header.
このペイロードヘッダーの後、連続したオーディオフレームは時間の順に詰め込まれています。つまり、最初は最古です。すべてのフレームは、ペイロードヘッダーのMIフィールドで示される同じモードでなければなりません。
Within a frame, layers are always packed in the same order: L0 then L1 for mode R2a, L0 then L2 for mode R2b, L0 then L1 then L2 for mode R3. This is illustrated below.
フレーム内では、レイヤーは常に同じ順序で詰め込まれます。L0、モードR2aの場合はL1、L0、モードR2BのL2、L0、L1、Mode R3でL2。これを以下に示します。
+-------------------------------+
R1 | L0 |
+-------------------------------+
+-------------------------------+--------+
R2a | L0 | L1 |
+-------------------------------+--------+
+-------------------------------+--------+
R2b | L0 | L2 |
+-------------------------------+--------+
+-------------------------------+--------+--------+
R3 | L0 | L1 | L2 |
+-------------------------------+--------+--------+
The size of one frame is given by the mode, as per Table 3, and the actual number of frames is easy to infer from the size of the audio data part:
1つのフレームのサイズは、表3に従ってモードで与えられ、実際のフレーム数はオーディオデータパーツのサイズから簡単に推測できます。
nb_frames = (size_of_audio_data) / (size_of_one_frame).
Only full frames must be considered. So if there is a remainder to the division above, the corresponding remaining bytes in the received payload MUST be ignored.
完全なフレームのみを考慮する必要があります。したがって、上記の部門に残りがある場合、受信したペイロード内の対応する残りのバイトは無視する必要があります。
This section defines the parameters that may be used to configure optional features in the G.711.1 RTP transmission.
このセクションでは、G.711.1 RTP伝送でオプションの機能を構成するために使用できるパラメーターを定義します。
Both A-law and mu-law G.711 are supported in the core layer L0, but there is no interoperability between A-law and mu-law. So two media types with the same parameters will be defined: audio/PCMA-WB for A-law core, and audio/PCMU-WB for mu-law core. This is consistent with the audio/PCMA and audio/PCMU media types separation for G.711 audio.
A-LawとMu-Law G.711の両方がコア層L0でサポートされていますが、A-LawとMu-Lawの間に相互運用性はありません。したがって、同じパラメーターを持つ2つのメディアタイプが定義されます：A-Law CoreのAudio/PCMA-WB、およびMU-LAWコアのオーディオ/PCMU-WB。これは、G.711オーディオのオーディオ/PCMAおよびオーディオ/PCMUメディアタイプの分離と一致しています。
The parameters are defined here as part of the media subtype registrations for the G.711.1 codec. A mapping of the parameters into the Session Description Protocol (SDP) [RFC4566] is also provided for those applications that use SDP. In control protocols that do not use MIME or SDP, the media type parameters must be mapped to the appropriate format used with that control protocol.
パラメーターは、G.711.1コーデックのメディアサブタイプ登録の一部としてここで定義されています。セッション説明プロトコル（SDP）[RFC4566]へのパラメーターのマッピングは、SDPを使用するアプリケーションにも提供されています。MIMEまたはSDPを使用しないコントロールプロトコルでは、メディアタイプのパラメーターを、そのコントロールプロトコルで使用する適切な形式にマッピングする必要があります。
This registration is done using the template defined in [RFC4288] and following [RFC4855].
この登録は、[RFC4288]および[RFC4855]で定義されたテンプレートを使用して行われます。
Type name: audio
タイプ名：オーディオ
Subtype name: PCMA-WB
サブタイプ名：PCMA-WB
Required parameters: none
必要なパラメーター：なし
Optional parameters:
オプションのパラメーター：
mode-set: restricts the active codec mode set to a subset of all modes. Possible values are a comma-separated list of modes from the set: 1, 2, 3, 4 (see Mode Index in Table 3 of RFC 5391). The modes are listed in order of preference; first is preferred. If mode-set is specified, frames encoded with modes outside of the subset MUST NOT be sent in any RTP payload. If not present, all codec modes are allowed.
モードセット：すべてのモードのサブセットに設定されたアクティブコーデックモードを制限します。考えられる値は、セットからのモードのコンマ分離されたリストです：1、2、3、4（RFC 5391の表3のモードインデックスを参照）。モードは好みの順にリストされています。最初は好まれます。モードセットが指定されている場合、サブセットの外側のモードでエンコードされたフレームをRTPペイロードで送信してはなりません。存在しない場合、すべてのコーデックモードが許可されます。
ptime: the recommended length of time (in milliseconds) represented by the media in a packet. It should be an integer multiple of 5 ms (the frame size). See Section 6 of RFC 4566.
PTIME：パケット内のメディアが表す推奨期間（ミリ秒単位）。5ミリ秒（フレームサイズ）の整数倍でなければなりません。RFC 4566のセクション6を参照してください。
maxptime: the maximum length of time (in milliseconds) that can be encapsulated in a packet. It should be an integer multiple of 5 ms (the frame size). See Section 6 of RFC 4566.
Maxptime：パケットにカプセル化できる最大時間（ミリ秒単位）。5ミリ秒（フレームサイズ）の整数倍でなければなりません。RFC 4566のセクション6を参照してください。
Encoding considerations: This media type is framed and contains binary data. See Section 4.8 of RFC 4288.
考慮事項のエンコーディング：このメディアタイプはフレーム化されており、バイナリデータが含まれています。RFC 4288のセクション4.8を参照してください。
Security considerations: See Section 8 of RFC 5391.
セキュリティ上の考慮事項：RFC 5391のセクション8を参照してください。
Interoperability considerations: none
相互運用性の考慮事項：なし
Published specification: RFC 5391
公開された仕様：RFC 5391
Applications that use this media type: Audio and video conferencing tools.
このメディアタイプを使用するアプリケーション：オーディオおよびビデオ会議ツール。
Additional information: none
追加情報：なし
Person & email address to contact for further information: Aurelien Sollaud, aurelien.sollaud@orange-ftgroup.com
詳細については、人とメールアドレスをお問い合わせ：Aurelien Sollaud、Aurelien.sollaud@orange-ftgroup.com
Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP.
意図された使用法：使用に関する一般的な制限：このメディアタイプはRTPフレーミングに依存するため、RTPを介した転送のみが定義されます。
Author: Aurelien Sollaud
著者：Aurelien Sollaud
Change controller: IETF Audio/Video Transport working group delegated from the IESG
Change Controller：IETFオーディオ/ビデオトランスポートワーキンググループは、IESGから委任されました
This registration is done using the template defined in [RFC4288] and following [RFC4855].
この登録は、[RFC4288]および[RFC4855]で定義されたテンプレートを使用して行われます。
Type name: audio
タイプ名：オーディオ
Subtype name: PCMU-WB
サブタイプ名：PCMU-WB
Required parameters: none
必要なパラメーター：なし
Optional parameters:
オプションのパラメーター：
mode-set: restricts the active codec mode-set to a subset of all modes. Possible values are a comma-separated list of modes from the set: 1, 2, 3, 4 (see Mode Index in Table 3 of RFC 5391). The modes are listed in order of preference; first is preferred. If mode-set is specified, frames encoded with modes outside of the subset MUST NOT be sent in any RTP payload. If not present, all codec modes are allowed.
モードセット：アクティブなコーデックモードセットをすべてのモードのサブセットに制限します。考えられる値は、セットからのモードのコンマ分離されたリストです：1、2、3、4（RFC 5391の表3のモードインデックスを参照）。モードは好みの順にリストされています。最初は好まれます。モードセットが指定されている場合、サブセットの外側のモードでエンコードされたフレームをRTPペイロードで送信してはなりません。存在しない場合、すべてのコーデックモードが許可されます。
ptime: the recommended length of time (in milliseconds) represented by the media in a packet. It should be an integer multiple of 5 ms (the frame size). See Section 6 of RFC 4566.
PTIME：パケット内のメディアが表す推奨期間（ミリ秒単位）。5ミリ秒（フレームサイズ）の整数倍でなければなりません。RFC 4566のセクション6を参照してください。
maxptime: the maximum length of time (in milliseconds) that can be encapsulated in a packet. It should be an integer multiple of 5 ms (the frame size). See Section 6 of RFC 4566.
Maxptime：パケットにカプセル化できる最大時間（ミリ秒単位）。5ミリ秒（フレームサイズ）の整数倍でなければなりません。RFC 4566のセクション6を参照してください。
Encoding considerations: This media type is framed and contains binary data. See Section 4.8 of RFC 4288.
考慮事項のエンコーディング：このメディアタイプはフレーム化されており、バイナリデータが含まれています。RFC 4288のセクション4.8を参照してください。
Security considerations: See Section 8 of RFC 5391.
セキュリティ上の考慮事項：RFC 5391のセクション8を参照してください。
Interoperability considerations: none
相互運用性の考慮事項：なし
Published specification: RFC 5391
公開された仕様：RFC 5391
Applications that use this media type: Audio and video conferencing tools.
このメディアタイプを使用するアプリケーション：オーディオおよびビデオ会議ツール。
Additional information: none
追加情報：なし
Person & email address to contact for further information: Aurelien Sollaud, aurelien.sollaud@orange-ftgroup.com
詳細については、人とメールアドレスをお問い合わせ：Aurelien Sollaud、Aurelien.sollaud@orange-ftgroup.com
Intended usage: COMMON
意図された使用法：共通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP.
使用に関する制限：このメディアタイプはRTPフレーミングに依存するため、RTPを介した転送に対してのみ定義されます。
Author: Aurelien Sollaud
著者：Aurelien Sollaud
Change controller: IETF Audio/Video Transport working group delegated from the IESG
Change Controller：IETFオーディオ/ビデオトランスポートワーキンググループは、IESGから委任されました
The information carried in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [RFC4566], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the G.711.1 codec, the mapping is as follows:
メディアタイプの仕様に掲載されている情報には、セッション説明プロトコル（SDP）[RFC4566]のフィールドへの特定のマッピングがあります。これは、RTPセッションを記述するために一般的に使用されます。SDPがG.711.1コーデックを使用するセッションを指定するために使用される場合、マッピングは次のとおりです。
o The media type ("audio") goes in SDP "m=" as the media name.
o メディアタイプ（ "Audio"）は、メディア名としてSDP "m ="になります。
o The media subtype ("PCMA-WB" or "PCMU-WB") goes in SDP "a=rtpmap" as the encoding name. The RTP clock rate in "a=rtpmap" MUST be 16000 for G.711.1.
o メディアサブタイプ（「PCMA-WB」または「PCMU-WB」）は、sdp "a = rtpmap"でエンコード名として掲載されます。「a = rtpmap」のRTPクロックレートは、G.711.1で16000でなければなりません。
o The parameter "mode-set" goes in the SDP "a=fmtp" attribute by copying it as a "mode-set=<value>" string.
o パラメーター「モードセット」は、 "Mode-set = <value>"文字列としてコピーすることにより、SDP "a = fmtp"属性になります。
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」属性に移動します。
The following considerations apply when using SDP offer-answer procedures [RFC3264] to negotiate the use of G.711.1 payload in RTP:
rtpでのG.711.1ペイロードの使用を交渉するために、SDPオファーアンドワープロシージャ[RFC3264]を使用する場合、以下の考慮事項が適用されます。
o Since G.711.1 is an extension of G.711, the offerer SHOULD announce G.711 support in its "m=audio" line, with G.711.1 preferred. This will allow interoperability with both G.711.1 and G.711-only capable parties. This is done by offering the PCMA media subtype in addition to PCMA-WB, and/or PCMU in addition to PCMU-WB.
o G.711.1はG.711の拡張であるため、オファーはG.711.1が優先される「M = Audio」ラインでG.711サポートを発表する必要があります。これにより、G.711.1とG.711のみの有能なパーティーの両方で相互運用性が可能になります。これは、PCMA-WBに加えてPCMAメディアサブタイプを提供し、PCMU-WBに加えてPCMUを提供することによって行われます。
Below is an example part of such an offer, for A-law:
以下は、A-Lawのためのそのような申し出の例です。
m=audio 54874 RTP/AVP 96 8
a=rtpmap:96 PCMA-WB/16000
a=rtpmap:8 PCMA/8000
As a reminder, the payload format for G.711 is defined in Section 4.5.14 of [RFC3551].
リマインダーとして、G.711のペイロード形式は[RFC3551]のセクション4.5.14で定義されています。
o The "mode-set" parameter is bi-directional; i.e., the restricted mode-set applies to media both to be received and sent by the declaring entity. If a mode-set was supplied in the offer, the answerer MUST return either the same mode-set or a subset of this mode-set. The answerer MAY change the preference order. If no mode-set was supplied in the offer, the anwerer MAY return a mode-set to restrict the possible modes. In any case, the mode-set in the answer then applies for both offerer and answerer. The offerer MUST NOT send frames of a mode that has been removed by the answerer.
o 「モードセット」パラメーターは双方向です。つまり、制限付きモードセットは、メディアに適用され、宣言されたエンティティによって受信および送信されます。オファーにモードセットが提供された場合、回答者は同じモードセットまたはこのモードセットのサブセットを返す必要があります。応答者は、優先順序を変更する場合があります。オファーにモードセットが提供されていない場合、Anwererはモードセットを返して可能なモードを制限する場合があります。いずれにせよ、回答のモードセットは、提供者と回答者の両方に適用されます。オファーは、応答者によって削除されたモードのフレームを送信してはなりません。
For multicast sessions, if "mode-set" is supplied in the offer, the answerer SHALL only participate in the session if it supports the offered mode-set.
マルチキャストセッションの場合、オファーで「モードセット」が提供されている場合、応答者は、提供されたモードセットをサポートしている場合にのみセッションに参加するものとします。
o The parameters "ptime" and "maxptime" will in most cases not affect interoperability. The SDP offer-answer handling of the "ptime" parameter is described in [RFC3264]. The "maxptime" parameter MUST be handled in the same way.
o ほとんどの場合、「PTIME」と「MaxPtime」のパラメーターは相互運用性に影響しません。「PTIME」パラメーターのSDPオファーアンドワー処理は、[RFC3264]で説明されています。「MaxPtime」パラメーターも同じ方法で処理する必要があります。
o Any unknown parameter in an offer MUST be ignored by the receiver and MUST NOT be included in the answer.
o オファー内の未知のパラメーターは、受信機によって無視され、答えに含めてはなりません。
Below are some example parts of SDP offer-answer exchanges.
以下は、SDPオファーアンスワーエの交換の一部の例です。
o Example 1
o 例1
Offer: G.711.1 all modes, with G.711 fallback, prefers mu-law
m=audio 54874 RTP/AVP 96 97 0 8
a=rtpmap:96 PCMU-WB/16000
a=rtpmap:97 PCMA-WB/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
Answer: all modes accepted, both mu- and A-law.
m=audio 59452 RTP/AVP 96 97
a=rtpmap:96 PCMU-WB/16000
a=rtpmap:97 PCMA-WB/16000
o Example 2
o 例2
Offer: G.711.1 all modes, with G.711 fallback, prefers A-law
m=audio 54874 RTP/AVP 96 97 8 0
a=rtpmap:96 PCMA-WB/16000
a=rtpmap:97 PCMU-WB/16000
Answer: wants only A-law mode R3
m=audio 59452 RTP/AVP 96
a=rtpmap:96 PCMA-WB/16000
a=fmtp:96 mode-set=4
o Example 3
o 例3
Offer: G.711.1 A-law with two modes, R2b and R3, with R3 preferred
m=audio 54874 RTP/AVP 96
a=rtpmap:96 PCMA-WB/16000
a=fmtp:96 mode-set=4,3
Answer: accepted
m=audio 59452 RTP/AVP 96
a=rtpmap:96 PCMA-WB/16000
a=fmtp:96 mode-set=4,3
If the answerer had wanted to restrict to one mode, it would have answered with only one value in the mode-set, for example mode-set=3 for mode R2b.
回答者が1つのモードに制限したい場合、モードセットにはモードセット= 3のモードR2Bの値が1つだけで回答していました。
For declarative use of SDP, nothing specific is defined for this payload format. The configuration given by the SDP MUST be used when sending and/or receiving media in the session.
SDPの宣言的な使用のために、このペイロード形式に対して特定の定義はありません。SDPによって指定された構成は、セッションでメディアを送信および/または受信するときに使用する必要があります。
The L0 layer of G.711.1 is fully interoperable with G.711, and is embedded in all modes of G.711.1. This provides an easy G.711.1 - G.711 transcoding process.
G.711.1のL0層は、G.711と完全に相互運用可能であり、G.711.1のすべてのモードに埋め込まれています。これにより、簡単なG.711.1 -G.711トランスコーディングプロセスが提供されます。
A gateway or any other network device receiving a G.711.1 packet can easily extract a G.711-compatible payload, without the need to decode and re-encode the audio signal. It simply has to take the audio data of the payload, and strip the upper layers (L1 and/or L2), if any.
G.711.1パケットを受信するゲートウェイまたはその他のネットワークデバイスは、オーディオ信号をデコードして再エンコードすることなく、G.711互換のペイロードを簡単に抽出できます。ペイロードのオーディオデータを取得し、上部層（L1および/またはL2）を削除するだけです。
If a G.711.1 packet contains several frames, the concatenation of the L0 layers of each frame will form a G.711-compatible payload.
G.711.1パケットにいくつかのフレームが含まれている場合、各フレームのL0レイヤーの連結はG.711互換のペイロードを形成します。
Congestion control for RTP SHALL be used in accordance with [RFC3550] and any appropriate profile (for example, [RFC3551]).
RTPの混雑制御は、[RFC3550]および適切なプロファイル（たとえば[RFC3551]）に従って使用するものとします。
The embedded nature of G.711.1 audio data can be helpful for congestion control, since a coding mode with a lower bit rate can be selected when needed. This property is usable only when multiple modes have been negotiated (either no "mode-set" parameter in the SDP or a "mode-set" with at least two modes).
G.711.1オーディオデータの埋め込み性は、必要に応じてビットレートが低いコーディングモードを選択できるため、輻輳制御に役立ちます。このプロパティは、複数のモードがネゴシエートされた場合にのみ使用可能です（SDPには「モードセット」パラメーターがないか、少なくとも2つのモードを備えた「モードセット」のいずれか）。
The number of frames encapsulated in each RTP payload influences the overall bandwidth of the RTP stream, due to the header overhead. Packing more frames in each RTP payload can reduce the number of packets sent and hence the header overhead, at the expense of increased delay and reduced error robustness.
各RTPペイロードにカプセル化されたフレームの数は、ヘッダーのオーバーヘッドにより、RTPストリームの全体的な帯域幅に影響します。各RTPペイロードでより多くのフレームを梱包すると、遅延の増加とエラーの堅牢性の低下を犠牲にして、送信されるパケットの数、したがってヘッダーのオーバーヘッドを減らすことができます。
RTP packets using the payload format defined in this specification are subject to the general security considerations discussed in the RTP specification [RFC3550] and any appropriate profile (for example, [RFC3551]).
この仕様で定義されたペイロード形式を使用したRTPパケットは、RTP仕様[RFC3550]および適切なプロファイル（たとえば[RFC3551]）で説明されている一般的なセキュリティ上の考慮事項の対象となります。
As this format transports encoded speech/audio, the main security issues include confidentiality, integrity protection, and authentication of the speech/audio itself. The payload format itself does not have any built-in security mechanisms. Any suitable external mechanisms, such as the Secure Real-time Transport Protocol (SRTP) [RFC3711], MAY be used.
この形式はエンコードされた音声/オーディオを輸送するため、主なセキュリティの問題には、機密性、整合性保護、および音声/オーディオ自体の認証が含まれます。ペイロード形式自体には、組み込みのセキュリティメカニズムがありません。安全なリアルタイム輸送プロトコル（SRTP）[RFC3711]などの適切な外部メカニズムを使用することができます。
This payload format and the G.711.1 encoding do not exhibit any significant non-uniformity in the receiver-end computational load, and thus they are unlikely to pose a denial-of-service threat due to the receipt of pathological datagrams. In addition, they do not contain any type of active content such as scripts.
このペイロード形式とG.711.1エンコーディングは、受信者エンドの計算負荷に有意な不均一性を示さないため、病理学的データグラムの受領によりサービス拒否の脅威をもたらす可能性は低いです。さらに、スクリプトなどのアクティブなコンテンツは含まれていません。
Two new media subtypes (audio/PCMA-WB and audio/PCMU-WB) have been registered by IANA. See Sections 5.1 and 5.2.
2つの新しいメディアサブタイプ（Audio/PCMA-WBとAudio/PCMU-WB）がIANAによって登録されています。セクション5.1および5.2を参照してください。
[ITU-G.711.1] International Telecommunications Union, "Wideband embedded extension for G.711 pulse code modulation", ITU-T Recommendation G.711.1, March 2008.
[ITU-G.711.1] International Telecommunications Union、「G.711パルスコード変調の広帯域埋め込み拡張」、ITU-T推奨G.711.1、2008年3月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551] Schulzrinne、H。およびS. Casner、「最小限のコントロールを備えたオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[RFC4855] Casner、S。、「RTPペイロードフォーマットのメディアタイプ登録」、RFC 4855、2007年2月。
[ITU-G.711] International Telecommunications Union, "Pulse code modulation (PCM) of voice frequencies", ITU-T Recommendation G.711, November 1988.
[ITU-G.711] International Telecommunications Union、「音声周波数のパルスコード変調（PCM）」、ITU-T推奨G.711、1988年11月。
[RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)", RFC 3389, September 2002.
[RFC3389] ZOPF、R。、「リアルタイム輸送プロトコル（RTP）コンフォートノイズのペイロード（CN）」、RFC 3389、2002年9月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「安全なリアルタイム輸送プロトコル（SRTP）」、RFC 3711、2004年3月。
Author's Address
著者の連絡先
Aurelien Sollaud France Telecom 2 avenue Pierre Marzin Lannion Cedex 22307 France
Aurelien Sollaud France Telecom 2 Avenue Pierre Marzin Lannion Cedex 22307 France
Phone: +33 2 96 05 15 06
EMail: aurelien.sollaud@orange-ftgroup.com