[要約] RFC 5459は、G.729.1 RTPペイロードフォーマットのアップデートであり、不連続送信(DTX)のサポートに関するものです。このRFCの目的は、G.729.1コーデックのDTX機能をRTPペイロードフォーマットに統合することです。

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

G.729.1 RTPペイロードフォーマットアップデート:不連続伝送(DTX)サポート

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.

Copyright(c)2009 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 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.

このドキュメントは、国際電気通信連合(ITU-T)推奨G.729.1オーディオコーデックに使用されるリアルタイムトランスポートプロトコル(RTP)ペイロード形式を更新します。後方互換性のある方法で、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
        
1. Introduction
1. はじめに

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].

International Telecommunication Union(ITU-T)推奨G.729.1 [ITU-G.729.1]は、推奨事項G.729 [ITU-G.729]オーディオコーデックのスケーラブルでワイドバンド拡張です。[RFC4749]は、G.729.1エンコードされたオーディオ信号をリアルタイムトランスポートプロトコル(RTP)[RFC3550]にパケット化するためのペイロード形式を指定します。

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]のAnnex 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].

「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。

2. Background
2. 背景

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-G.729-B]と同じです。最初の拡張レイヤーは、狭帯域快適なノイズのパラメーターを追加しますが、2番目の拡張層はワイドバンド情報を追加します。G.729.1 SIDは、長さ2、3、または6オクテットにすることができます。

3. RTP Header Usage
3. RTPヘッダーの使用

The fields of the RTP header must be used as described in [RFC4749], except for the Marker (M) bit.

マーカー(M)ビットを除き、[RFC4749]に記載されているように、RTPヘッダーのフィールドを使用する必要があります。

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を使用する場合、Talkspurtの最初のパケット - つまり、パケットが連続して送信されていない沈黙期間後の最初のパケットは、RTPデータヘッダーのMビットを1に設定することで区別する必要があります。他のすべてのパケットのMビットは0に設定する必要があります。Talkspurtの開始を使用して、ネットワーク遅延の変化を反映するためにプレイアウト遅延を調整することができます。

If DTX is not used, the M bit MUST be set to 0 in all packets.

DTXが使用されていない場合、すべてのパケットでMビットを0に設定する必要があります。

4. Payload Format
4. ペイロード形式

The payload format is the same as in [RFC4749], with the option to add a SID at the end.

ペイロード形式は[RFC4749]と同じであり、最後にSIDを追加するオプションがあります。

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(フレームタイプ)フィールド)のペイロードヘッダーで構成され、その後、同じビットレートでゼロ以上の連続したオーディオフレームが続き、その後ゼロまたは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を単独で輸送できるように、つまり実際のオーディオフレームなしでは、FT値14をSIDに割り当てます。FT = 14を使用する場合、ペイロードには1つの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値はオーディオフレームのエンコーディングレートを説明するもののままです。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の定義と使用に影響を与えません。

5. Payload Format Parameters
5. ペイロードフォーマットパラメーター

Parameters defined in [RFC4749] are not modified. We add a new optional parameter to configure DTX.

[RFC4749]で定義されたパラメーターは変更されていません。新しいオプションパラメーターを追加して、DTXを構成します。

5.1. Media Type Registration Update
5.1. メディアタイプの登録更新

We add a new optional parameter to the audio/G7291 media subtype:

Audio/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を使用してはなりません。

5.2. Mapping to SDP Parameters
5.2. SDPパラメーターへのマッピング

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.

メディアタイプの仕様に掲載されている情報には、セッション説明プロトコル(SDP)[RFC4566]のフィールドへの特定のマッピングがあります。これは、RTPセッションを記述するために一般的に使用されます。

The mapping described in [RFC4749] remains unchanged.

[RFC4749]で説明されているマッピングは変更されていません。

The "dtx" parameter goes in the SDP "a=fmtp" attribute.

「DTX」パラメーターは、SDP「A = 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 A = 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
        
5.2.1. DTX Offer-Answer Model Considerations
5.2.1. DTXオファーアンドワーモデルの考慮事項

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」パラメーターの使用を正当化します。

5.2.2. DTX Declarative SDP Considerations
5.2.2. DTX宣言SDPの考慮事項

The "dtx" parameter is declarative and provides the parameter that SHALL be used when receiving and/or sending the configured stream.

「DTX」パラメーターは宣言的であり、構成されたストリームを受信および/または送信するときに使用されるパラメーターを提供します。

6. Congestion Control
6. 混雑制御

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パケットの数とオーディオストリームの平均帯域幅を減らすことにより、混雑制御に役立ちます。

7. Security Considerations
7. セキュリティに関する考慮事項

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は新しい特定の問題を導入しません。

8. IANA Considerations
8. IANAの考慮事項

IANA has assigned a new optional parameter for media subtype (audio/ G7291); see Section 5.1.

IANAは、メディアサブタイプ(Audio/ G7291)の新しいオプションパラメーターを割り当てました。セクション5.1を参照してください。

9. References
9. 参考文献
9.1. Normative References
9.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] International Telecommunications Union、 "G.729ベースの埋め込み可変ビットレートコーダー:8-32 kbit/sスケーラブルなワイドワイドバンドコーダーは、G.729"と相互操作可能です。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] International Telecommunications Union、「G.729.1 DTX/CNGスキーム」、ITU-T推奨G.729.1 Annex C、2008年5月。

[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月。

[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月。

[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月。

[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月。

9.2. Informative References
9.2. 参考引用

[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]国際通信ユニオン、「コンジュゲート構造代数コード発現線形予測(cs-acelp)を使用した8 kbit/sでの発話のコーディング」、ITU-T推奨G.729、1996年3月。

[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-G.729-B] International Telecommunications Union、「推奨v.70に準拠した端子に最適化されたG.729の沈黙圧縮スキーム」、ITU-T推奨G.729 Annex B、1996年10月。

[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

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