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
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.
著作権（C）2008 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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/ライセンス情報）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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電気通信標準化部門（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電気通信標準化部門（ITU-T）勧告G.711.1 [ITU-G.711.1]は勧告G.711 [ITU-G.711】オーディオコーデックの埋め込み広帯域拡張です。この文書では、リアルタイムトランスポートプロトコル（RTP）にG.711.1エンコードされたオーディオ信号のパケットのペイロード形式を指定します。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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はG.711埋め込み広帯域音声および64で動作する音声符号化アルゴリズム、80、96 kbpsです。 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ミリ秒フレームで動作し、既定のサンプリングレートは16kHzです。 8kHzで入力と出力が狭帯域モードでサポートされています。
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.
64、80、および96 kbpsの：エンコーダは、3つの利用可能なビットレートに対応した3層構造に埋め込まれたビットストリームを生成します。ビットストリームは、所望の値にビットレート「オンザフライ」、デコーダ側で、または調整するための通信システムの任意のコンポーネントによって切り捨てられることができます。
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.
一つにRTPデータヘッダ内のマーカビットを設定することによって区別されるべきです。他のすべてのパケットでマーカービットはゼロです。有音部の先頭には、変化するネットワークの遅延を反映するために、プレイアウト遅延を調整するために使用されるかもしれません。無音抑止のないアプリケーションはゼロにマーカービットを設定しなければなりません。
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.
タイムスタンプ：16キロヘルツ：RTPタイムスタンプのクロック周波数は、既定のサンプリング周波数と同じです。
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はまた、8kHzのサンプリングされた入力/出力信号で動作する能力を有します。これは、ビットストリームに影響を与えない、及びデコーダは、エンコーダの入力における元の信号のサンプリングレートについての先験的な知識を必要としません。したがって、実装およびデバイスのオーディオ音響機能に応じて、エンコーダおよび/またはデコーダの出力の入力は8kHzで構成することができます。しかし、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ミリ秒である16kHzで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.
完全なペイロードは、同じモードの一の以上の連続したG.711.1オーディオフレームに続く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次いでL1モードR2aをするため、L0次いでL2モードR2bのため、L0次いでL1次いでL2モードR3ため。これは、以下に例示されています。
+-------------------------------+
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).
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-法G.711の両方がコア層L0でサポートされていますが、-lawおよびmu-lawの間には相互運用性がありません。義理のコア用オーディオ/ PCMA-WBを、およびμ-lawのコア用オーディオ/ PCMU-WB：だから、同じパラメータを持つ2つのメディアタイプが定義されます。これは、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
人と詳細のために連絡する電子メールアドレス：オーレリアンSollaud、aurelien.sollaud@orange-ftgroup.com
Intended usage: COMMON
意図している用法：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
著者：オーレリアンSollaud
Change controller: IETF Audio/Video Transport working group delegated from the IESG
変更コントローラ：IESGから委任IETFオーディオ/ビデオ輸送ワーキンググループ
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
人と詳細のために連絡する電子メールアドレス：オーレリアンSollaud、aurelien.sollaud@orange-ftgroup.com
Intended usage: COMMON
意図している用法：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
著者：オーレリアンSollaud
Change controller: IETF Audio/Video Transport working group delegated from the IESG
変更コントローラ：IESGから委任IETFオーディオ/ビデオ輸送ワーキンググループ
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:
メディアタイプ仕様で搬送される情報は、一般的にRTPセッションを記述するために使用されるセッション記述プロトコル（SDP）[RFC4566]のフィールドに特定のマッピングを有します。 SDPがG.711.1コーデックを使用するセッションを指定するために使用される場合、以下のように、マッピングは次のとおりです。
o The media type ("audio") goes in SDP "m=" as the media name.
Oメディアタイプ（「オーディオ」）は、メディア名として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「モードに設定= <値>」の文字列としてそれをコピーして、SDPの「a =のfmtp」属性になります。
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
Oパラメータの "PTIME" と "maxptime" は、それぞれ、 "A = PTIME" と "A = maxptimeは" 属性SDPに行きます。
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.
G.711.1はG.711の拡張であるため、O、申出が好ましいG.711.1と、その「M =オーディオ」ラインにG.711サポートを発表するべきです。これは、G.711.1とG.711のみの対応の当事者の双方との相互運用が可能になります。これは、PCMU-WBに加えてPCMA-WBに加えてPCMAメディアサブタイプを提供し、および/またはPCMUによって行われます。
Below is an example part of such an offer, for A-law:
以下は、義理のために、そのようなオファーの例の一部です：
m=audio 54874 RTP/AVP 96 8 a=rtpmap:96 PCMA-WB/16000 a=rtpmap:8 PCMA/8000
M =オーディオ54874 RTP / AVP 96 8 A = rtpmap：96 PCMA-WB / 16000 = 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
実施例1 O
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
オファー：G.711.1すべてのモード、G.711フォールバックとは、好むミュー法則M =オーディオ54874 RTP / AVP 96 97 0 8 A = rtpmap：96 PCMU-WB / 16000 = rtpmap：97 PCMA-WB / 16000 = rtpmap：0 PCMU / 8000 = 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
回答：すべてのモードに受け入れ、ミューと義理の両方。 M =オーディオ59452 RTP / AVP 96 97 = rtpmap：96 PCMU-WB / 16000 = rtpmap：97 PCMA-WB / 16000
o Example 2
実施例2 O
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
オファー：G.711.1すべてのモード、G.711フォールバックとは、好む法則M =オーディオ54874 RTP / AVP 96 97 8 0 A = rtpmap：96 PCMA-WB / 16000 = 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
答え：たいだけ則モードR3のM =オーディオ59452 RTP / AVP 96 = rtpmap：96 PCMA-WB / 16000 =のfmtp：96モード設定= 4
o Example 3
実施例3 O
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
オファー：96 PCMA-WB / 16000 =のfmtp：96モード設定= 4,3 R3をm =オーディオ54874 RTP / AVP 96 = rtpmap好ましい2つのモード、R2bのとR3とG.711.1 A則、
Answer: accepted m=audio 59452 RTP/AVP 96 a=rtpmap:96 PCMA-WB/16000 a=fmtp:96 mode-set=4,3
答え：受け付けM =オーディオ59452 RTP / AVP 96 = rtpmap：96 PCMA-WB / 16000 =のfmtp：96モード設定= 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モードに制限したかったならば、それは例えば、モードR2bのためのモードセット= 3のために、モードセットで一つの値だけで答えていました。
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のトランスコード処理 - これは簡単G.711.1を提供します。
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または少なくとも二つのモードを有する「モードセット」のいずれかでNO「モード設定」パラメータ）ネゴシエートされた場合にのみ使用可能です。
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.
二つの新しいメディアサブタイプ（オーディオ/ PCMA-WBおよびオーディオ/ 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]国際電気通信連合、 "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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[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.、フレデリック、R.、およびV.ヤコブソン、 "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]解放され、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]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[RFC4855] Casner、S.、RFC 4855、2007年2月 "RTPペイロード形式のメディアタイプ登録"。
[ITU-G.711] International Telecommunications Union, "Pulse code modulation (PCM) of voice frequencies", ITU-T Recommendation G.711, November 1988.
[ITU-G.711]国際電気通信連合、 "パルス符号変調（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.、RFC 3389、2002年9月 "コンフォートノイズ（CN）のためのリアルタイムトランスポートプロトコル（RTP）ペイロード"。
[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.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
Author's Address
著者のアドレス
Aurelien Sollaud France Telecom 2 avenue Pierre Marzin Lannion Cedex 22307 France
オーレリアンSollaudフランステレコム2大通りピエールMarzin 22307ラニオンセデックスフランス
Phone: +33 2 96 05 15 06 EMail: aurelien.sollaud@orange-ftgroup.com
電話：+33 2 96 05 15 06 Eメール：aurelien.sollaud@orange-ftgroup.com