Network Working Group A. Sollaud
Request for Comments: 5459 France Telecom
Updates: 4749 January 2009
Category: Standards Track
G.729.1 RTP Payload Format Update:
Discontinuous Transmission (DTX) Support
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 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 updates the Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union (ITU-T) Recommendation G.729.1 audio codec. It adds Discontinuous Transmission (DTX) support to the RFC 4749 specification, in a backward-compatible way. An updated media type registration is included for this payload format.
この文書では、トランスポートプロトコル（RTP）ペイロード形式は、国際電気通信連合（ITU-T）勧告G.729.1オーディオコーデックを使用するリアルタイムに更新されます。これは、下位互換性のある方法で、RFC 4749の仕様に不連続送信（DTX）のサポートを追加します。更新されたメディアタイプの登録は、このペイロード形式のために含まれています。
Table of Contents
目次
1. Introduction ....................................................2
2. Background ......................................................2
3. RTP Header Usage ................................................3
4. Payload Format ..................................................3
5. Payload Format Parameters .......................................4
5.1. Media Type Registration Update .............................4
5.2. Mapping to SDP Parameters ..................................5
5.2.1. DTX Offer-Answer Model Considerations ...............5
5.2.2. DTX Declarative SDP Considerations ..................6
6. Congestion Control ..............................................6
7. Security Considerations .........................................6
8. IANA Considerations .............................................6
9. References ......................................................6
9.1. Normative References .......................................6
9.2. Informative References .....................................7
The International Telecommunication Union (ITU-T) Recommendation G.729.1 [ITU-G.729.1] is a scalable and wideband extension of the Recommendation G.729 [ITU-G.729] audio codec. [RFC4749] specifies the payload format for packetization of G.729.1-encoded audio signals into the Real-time Transport Protocol (RTP) [RFC3550].
国際電気通信連合（ITU-T）勧告G.729.1 [ITU-G.729.1]は勧告G.729 [ITU-G.729】オーディオコーデックの拡張性と広帯域拡張です。 [RFC4749]はリアルタイムトランスポートプロトコル（RTP）[RFC3550]にG.729.1符号化されたオーディオ信号のパケットのためのペイロードのフォーマットを指定します。
Annex C of G.729.1 [ITU-G.729.1-C] adds Discontinuous Transmission (DTX) support to G.729.1. This document updates the RTP payload format to allow usage of this Annex.
G.729.1 [ITU-G.729.1-C]の附属書CはG.729.1に不連続送信（DTX）のサポートを追加します。この文書では、この附属書の使用を可能にするためのRTPペイロードフォーマットを更新します。
Only changes or additions to [RFC4749] will be described in the following sections.
[RFC4749]にのみ変更または追加は、以下のセクションで説明します。
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.729.1 supports Discontinuous Transmission (DTX), a.k.a. "silence suppression". It means that the coder includes a Voice Activity Detection (VAD) algorithm to determine if an audio frame contains silence or actual audio. During silence periods, the coder may significantly decrease the transmitted bit rate by sending a small frame called a Silence Insertion Descriptor (SID) and then stop transmission. The receiver's decoder will generate comfort noise (CNG) according to the parameters contained in the SID. This DTX/CNG scheme is specified in [ITU-G.729.1-C].
G.729.1は、不連続送信（DTX）、別称「無音圧縮」をサポートしています。これは、符号化器は、音声フレームが無音または実際の音声が含まれているかどうかを決定するために音声アクティビティ検出（VAD）アルゴリズムを含むことを意味します。沈黙期間中、コーダは大幅無音挿入記述子（SID）と呼ばれる小さなフレームを送信することにより送信ビットレートを減少させ、その後、送信を停止してもよいです。受信機のデコーダは、SIDに含まれるパラメータに従って快適ノイズ（CNG）を生成します。このDTX / CNG方式は[ITU-G.729.1-C]で指定されています。
The G.729.1 SID has an embedded structure. The core SID is the same as the legacy G.729 SID [ITU-G.729-B]. The first enhancement layer adds some parameters for narrowband comfort noise, while a second enhancement layer adds wideband information. The G.729.1 SID can be 2, 3, or 6 octets long.
G.729.1 SIDは、埋め込まれた構造を有しています。コアSIDは、レガシーG.729 SID [ITU-729-B]と同様です。第2拡張層は広帯域情報を追加しながら、第1拡張レイヤは、狭帯域快適雑音のためにいくつかのパラメータを追加します。 G.729.1 SIDは、2、3、または6オクテット長くすることができます。
The fields of the RTP header must be used as described in [RFC4749], except for the Marker (M) bit.
[RFC4749]で説明されるようにRTPヘッダのフィールドは、マーカ（M）ビットを除いて、使用しなければなりません。
If DTX is used, the first packet of a talkspurt -- that is, the first packet after a silence period during which packets have not been transmitted contiguously -- MUST be distinguished by setting the M bit in the RTP data header to 1. The M bit in all other packets MUST be set to 0. The beginning of a talkspurt MAY be used to adjust the playout delay to reflect changing network delays.
有音部のDTXが使用される場合、最初のパケット - すなわち、パケットが連続的に送信されていない時に無音期間の後の最初のパケットは、 - 1にRTPデータヘッダ内のMビットを設定することによって区別されなければなりません他のすべてのパケットにMビットが0に設定されなければならない有音部の開始は、ネットワーク遅延を変更反映するプレイアウト遅延を調整するために使用され得ます。
If DTX is not used, the M bit MUST be set to 0 in all packets.
DTXを使用しない場合、Mビットは、すべてのパケットでは0に設定しなければなりません。
The payload format is the same as in [RFC4749], with the option to add a SID at the end.
ペイロード形式は末尾にSIDを追加するオプションと、[RFC4749]と同じです。
So the complete payload consists of a payload header of 1 octet (MBS (maximum bit rate supported) and FT (frame type) fields), followed by zero or more consecutive audio frames at the same bit rate, followed by zero or one SID.
そう完全なペイロードは1つのオクテットのペイロードヘッダで構成され（MBS（最大ビットレートは、サポートされている）とFT（フレーム・タイプ）フィールド）は、0または1 SID続く同じビットレートでゼロまたはそれ以上の連続したオーディオフレーム、続きます。
Note that this is consistent with the payload format of G.729 described in section 4.5.6 of [RFC3551].
これは[RFC3551]のセクション4.5.6に記載のG.729のペイロードフォーマットと一致していることに留意されたいです。
To be able to transport a SID alone -- that is, without actual audio frames -- we assign the FT value 14 to the SID. When using FT=14, only a single SID frame SHALL be included in the payload. The actual SID size (2, 3, or 6 octets) is inferred from the payload size: it is the size of what is left after the payload header.
つまり、実際のオーディオフレームなし - - だけではSIDを輸送できるようにするために、我々は、SIDにFT値14を割り当てます。 FT = 14を使用する場合、単一のSIDフレームは、ペイロードに含めなければなりません。実際のSIDのサイズは（2、3、または6つのオクテット）ペイロードサイズから推測される：それはペイロードヘッダの後に残っているもののサイズです。
When a SID is appended to actual audio frames, the FT value remains the one describing the encoding rate of the audio frames. Since the SID is much smaller than any other frame, it can be easily detected at the receiver side, and it will not hinder the calculation of the number of frames. The actual SID size is inferred from the payload size: it is the size of what is left after the audio frames.
SIDは、実際のオーディオフレームに付加されたときに、FTの値は、音声フレームの符号化レートを記述する1つのままです。 SIDが他のフレームよりもはるかに小さいので、それは容易に受信側で検出することができ、それはフレームの数の計算を妨げないであろう。実際のSIDのサイズは、ペイロードサイズから推測される：それは、オーディオフレームの後に残っているもののサイズです。
Section 5.4 of [RFC4749] mandates to ignore the remaining bytes after complete frames. This document overrides that statement: the receiver of the payload must consider these remaining bytes as a SID frame. If the size of this remainder is not a valid SID frame size (2, 3, or 6 octets), the receiver MUST ignore these bytes.
[RFC4749]義務のセクション5.4は、完全なフレームの後に残りのバイトを無視します。この文書は、そのステートメントを上書きします：ペイロードの受信機は、SIDフレームとしてこれらの残りのバイトを考慮する必要があります。この余りの大きさは、有効なSIDフレームサイズ（2、3、または6オクテット）でない場合、受信機は、これらのバイトを無視しなければなりません。
The full FT table is given for convenience:
フルFTテーブルは便宜的に与えられます：
+-------+---------------+-------------------+
| FT | encoding rate | frame size |
+-------+---------------+-------------------+
| 0 | 8 kbps | 20 octets |
| 1 | 12 kbps | 30 octets |
| 2 | 14 kbps | 35 octets |
| 3 | 16 kbps | 40 octets |
| 4 | 18 kbps | 45 octets |
| 5 | 20 kbps | 50 octets |
| 6 | 22 kbps | 55 octets |
| 7 | 24 kbps | 60 octets |
| 8 | 26 kbps | 65 octets |
| 9 | 28 kbps | 70 octets |
| 10 | 30 kbps | 75 octets |
| 11 | 32 kbps | 80 octets |
| 12-13 | (reserved) | - |
| 14 | SID | 2, 3, or 6 octets |
| 15 | NO_DATA | 0 |
+-------+---------------+-------------------+
DTX has no impact on the MBS definition and use.
DTXは、MBSの定義と使用には影響しません。
Parameters defined in [RFC4749] are not modified. We add a new optional parameter to configure DTX.
[RFC4749]で定義されたパラメータが変更されません。私たちは、DTXを設定するための新しいオプションのパラメータを追加します。
We add a new optional parameter to the audio/G7291 media subtype:
私たちは、オーディオ/ G7291メディアサブタイプに新しいオプションのパラメータを追加します。
dtx: indicates that Discontinuous Transmission (DTX) is used or preferred. Permissible values are 0 and 1. 0 means no DTX. 1 means DTX support, as described in Annex C of ITU-T Recommendation G.729.1. 0 is implied if this parameter is omitted.
DTXは：不連続送信（DTX）が使用されるか、または好ましいことを示しています。許容値は0と1 0はDTXがないことを意味しています。図1は、ITU-T勧告G.729.1の附属書Cに記載されているように、DTXサポートを意味します。このパラメータが省略された場合は0が暗示されます。
When DTX is turned off, the RTP payload MUST NOT contain a SID, and the FT value 14 MUST NOT be used.
DTXをオフにすると、RTPペイロードはSIDを含んではならない、とFT値14を使用してはいけません。
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.
メディアタイプ仕様で搬送される情報は、一般的にRTPセッションを記述するために使用されるセッション記述プロトコル（SDP）[RFC4566]のフィールドに特定のマッピングを有します。
The mapping described in [RFC4749] remains unchanged.
[RFC4749]に記載されたマッピングは変わりません。
The "dtx" parameter goes in the SDP "a=fmtp" attribute.
「DTX」パラメータはSDP「=のfmtp」属性になります。
Some example partial SDP session descriptions utilizing G.729.1 encodings follow.
G.729.1エンコーディングを利用するいくつかの例部分SDPセッション記述が続きます。
Example 1: default parameters (DTX off)
例1：デフォルトパラメータ（DTXオフ）
m=audio 57586 RTP/AVP 96 a=rtpmap:96 G7291/16000
M =オーディオ57586 RTP / AVP 96 = rtpmap：96 G7291 / 16000
Example 2: recommended packet duration of 40 ms (=2 frames), maximum bit rate is 20 kbps, DTX supported and preferred.
実施例2：40ミリ秒（= 2つのフレーム）の推奨パケット持続時間、最大ビットレートは20 kbpsの、DTXがサポートと好ましいです。
m=audio 49987 RTP/AVP 97 a=rtpmap:97 G7291/16000 a=fmtp:97 maxbitrate=20000; dtx=1 a=ptime:40
M =オーディオ49987 RTP / AVP 97 = rtpmap：97 G7291 / 16000 =のfmtp：97のmaxBitrate = 20000。 DTX = 1、A = PTIME：40
The offer-answer model considerations of [RFC4749] fully apply. In this section, we only define the management of the "dtx" parameter.
[RFC4749]のオファーアンサーモデルの考慮事項が完全に適用されます。このセクションでは、我々は唯一の「DTX」パラメータの管理を定義します。
The "dtx" parameter concerns both sending and receiving, so both sides of a bi-directional session MUST have the same DTX setting. If one party indicates that it does not support DTX, DTX must be deactivated both ways. In other words, DTX is actually activated if, and only if, "dtx=1" in the offer and in the answer.
送信側と受信側の両方の「DTX」パラメータの懸念ので、双方向セッションの両側が同じDTXの設定を持たなければなりません。一方の当事者が、それはDTXをサポートしていないことを示している場合、DTXは両方の方法を無効にする必要があります。言い換えれば、DTXは実際に場合に限り、「DTX = 1」を提供中との回答で活性化されます。
A special rule applies for multicast: the "dtx" parameter becomes declarative and MUST NOT be negotiated. This parameter is fixed, and a participant MUST use the configuration that is provided for the session.
特別なルールは、マルチキャストのために適用されます：「DTX」パラメータは、宣言になり、交渉してはいけません。このパラメータは固定されており、参加者はセッションのために提供された構成を使用しなければなりません。
An RTP receiver compliant with only RFC 4749 and not this specification will ignore the "dtx" parameter and will not include it in its answer, so DTX will not be activated in this case. As a remark, if that happened, this kind of receiver would not be confused by an RTP stream with DTX because RFC 4749 requires that the bytes that are now used for SID frames be ignored. But during the silence period, the receiver would then react using packet loss concealment instead of comfort noise generation, leading to bad audio quality. This justifies the use of the "dtx" parameter, even if the payload format is backward-compatible at the binary level.
唯一のRFC 4749およびないこの仕様に準拠したRTP受信機は、「DTX」パラメータを無視し、DTXは、この場合には作動しませんので、その答えの中に含まれません。それが起こった場合は、RFC 4749は、現在のSIDフレームのために使用されているバイトが無視されている必要がありますので、発言のように、受信機のこの種は、DTXとRTPストリームに惑わされないであろう。しかし、沈黙期間中に、受信機は、悪いオーディオ品質につながる、パケット損失隠蔽の代わりに、快適ノイズ生成を使用して反応するであろう。これは、ペイロードフォーマットはバイナリレベルで下位互換性がある場合でも、「DTX」パラメータの使用を正当化します。
The "dtx" parameter is declarative and provides the parameter that SHALL be used when receiving and/or sending the configured stream.
「DTX」パラメータが宣言され、受信及び/又は構成されたストリームを送信するときに使用しなければならないパラメータを提供します。
The congestion control considerations of [RFC4749] apply.
[RFC4749]の輻輳制御の考慮事項が適用されます。
The use of DTX can help congestion control by reducing the number of transmitted RTP packets and the average bandwidth of audio streams.
DTXの使用は、送信されたRTPパケットの数とオーディオストリームの平均帯域幅を減少させることによって輻輳制御を助けることができます。
The security considerations of [RFC4749] apply.
[RFC4749]のセキュリティ上の考慮事項が適用されます。
By observing the RTP flow with DTX, an attacker could see when and for how long people are speaking. This is a general fact for DTX, and G.729.1 DTX introduces no new specific issue.
DTXとRTPの流れを観察することによって、攻撃者は、いつ、どのくらいの人が話しているのために見ることができました。これは、DTXのための一般的な事実であり、およびG.729.1 DTXには、新たな特定の問題を紹介しません。
IANA has assigned a new optional parameter for media subtype (audio/ G7291); see Section 5.1.
IANAは、メディアサブタイプ（オーディオ/ G7291）のための新しいオプションのパラメータが割り当てられています。セクション5.1を参照してください。
[ITU-G.729.1] International Telecommunications Union, "G.729 based Embedded Variable bit-rate coder: An 8-32 kbit/s scalable wideband coder bitstream interoperable with G.729", ITU-T Recommendation G.729.1, May 2006.
[ITU-G.729.1]国際電気通信連合、「G.729埋込み変数のビットレートコーダをもと：8-32キロビット/秒スケーラブル広帯域符号化ビットストリームG.729との相互運用性」、ITU-T勧告G.729.1、月2006。
[ITU-G.729.1-C] International Telecommunications Union, "G.729.1 DTX/CNG scheme", ITU-T Recommendation G.729.1 Annex C, May 2008.
[ITU-G.729.1-C]国際電気通信連合、 "G.729.1 DTX / CNGスキーム"、ITU-T勧告G.729.1附属書C、2008年5月。
[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月。
[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月。
[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月。
[RFC4749] Sollaud, A., "RTP Payload Format for the G.729.1 Audio Codec", RFC 4749, October 2006.
[RFC4749] Sollaud、A.、 "G.729.1オーディオコーデックのためのRTPペイロードフォーマット"、RFC 4749、2006年10月。
[ITU-G.729] International Telecommunications Union, "Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear-prediction (CS-ACELP)", ITU-T Recommendation G.729, March 1996.
[ITU-G.729]国際電気通信連合、ITU-T勧告G.729、1996年3月 "8キロビットでのスピーチのコーディングは/共役構造代数コード励振線形予測（CS-ACELP）を使用してS"。
[ITU-G.729-B] International Telecommunications Union, "A silence compression scheme for G.729 optimized for terminals conforming to Recommendation V.70", ITU-T Recommendation G.729 Annex B, October 1996.
[ITU-729-B]国際電気通信連合、ITU-T勧告G.729の付属書B、1996年10月 "勧告V.70に準拠した端末向けに最適化G.729のための無音圧縮方式"。
[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月。
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