RFC3389 日本語訳

Network Working Group                                            R. Zopf
Request for Comments: 3389                           Lucent Technologies
Category: Standards Track                                 September 2002

Zopfがコメントのために要求するワーキンググループR.をネットワークでつないでください: 3389年のルーセントテクノロジーズカテゴリ: 標準化過程2002年9月

   Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)

安らぎ雑音のためのリアルタイムのトランスポート・プロトコル(RTP)有効搭載量(CN)

Status of this Memo

この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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

Abstract

要約

   This document describes a Real-time Transport Protocol (RTP) payload
   format for transporting comfort noise (CN).  The CN payload type is
   primarily for use with audio codecs that do not support comfort noise
   as part of the codec itself such as ITU-T Recommendations G.711,
   G.726, G.727, G.728, and G.722.

このドキュメントは、安らぎ雑音(CN)を輸送するためにレアル-時間Transportプロトコル(RTP)ペイロード形式について説明します。 CNペイロードタイプはコーデック自体のITU-TのRecommendations G.711や、G.726や、G.727や、G.728や、G.722などの一部として安らぎ雑音を支持しないオーディオコーデックをもって主として使用に賛成します。

1. Conventions Used in This Document

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 RFC-2119 [7].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC-2119[7]で説明されるように本書では解釈されることであるべきですか?

2. Introduction

2. 序論

   This document describes a RTP [1] payload format for transporting
   comfort noise.  The payload format is based on Appendix II of ITU-T
   Recommendation G.711 [8] which defines a comfort noise payload format
   (or bit-stream) for ITU-T G.711 [2] use in packet-based multimedia
   communication systems.  The payload format is generic and may also be
   used with other audio codecs without built-in Discontinuous
   Transmission (DTX) capability such as ITU-T Recommendations G.726
   [3], G.727 [4], G.728 [5], and G.722 [6].  The payload format
   provides a minimum interoperability specification for communication
   of comfort noise parameters.  The comfort noise analysis and
   synthesis as well as the Voice Activity Detection (VAD) and DTX
   algorithms are unspecified and left implementation-specific.

このドキュメントは、安らぎ雑音を輸送するためにRTP[1]ペイロード形式について説明します。 ペイロード形式はパケットベースのマルチメディア通信システムにおけるITU-T G.711[2]使用のために、安らぎ雑音ペイロード書式(または、ビットストリーム)を定義するITU-T Recommendation G.711[8]のAppendix IIに基づいています。ペイロード形式は、一般的であり、また、他のオーディオコーデックと共にITU-TのRecommendations G.726[3]や、G.727[4]や、G.728[5]や、G.722[6]などの内蔵のDiscontinuous Transmission(DTX)能力なしで使用されるかもしれません。 ペイロード形式は安らぎ雑音パラメタに関するコミュニケーションのための最小の相互運用性仕様を提供します。 Voice Activity Detection(VAD)とDTXアルゴリズムと同様に安らぎ雑音解析と統合は、不特定であり、実現特有の状態でおかれます。

Zopf                        Standards Track                     [Page 1]

RFC 3389             RTP Payload for Comfort Noise        September 2002

Zopf規格は雑音2002年9月に安らぎのためにRFC3389RTP有効搭載量を追跡します[1ページ]。

   However, an example solution for G.711 has been tested and is
   described in the Appendix [8].  It uses the VAD and DTX of G.729
   Annex B [9] and a comfort noise generation algorithm (CNG) which is
   provided in the Appendix for information.

しかしながら、G.711の解答例は、テストされて、Appendix[8]で説明されます。 それはG.729 Annex B[9]のVADとDTXと情報のためにAppendixに提供される安らぎ雑音世代アルゴリズム(CNG)を使用します。

   The comfort noise payload, which is also known as a Silence Insertion
   Descriptor (SID) frame, consists of a single octet description of the
   noise level and MAY contain spectral information in subsequent
   octets.  An earlier version of the CN payload format consisting only
   of the noise level byte was defined in draft revisions of the RFC
   1890.  The extended payload format defined in this document should be
   backward compatible with implementations of the earlier version
   assuming that only the first byte is interpreted and any additional
   spectral information bytes are ignored.

安らぎ雑音ペイロード(また、Silence Insertion Descriptor(SID)フレームとして知られている)は、騒音レベルのただ一つの八重奏記述から成って、その後の八重奏にスペクトル情報を含むかもしれません。 騒音レベルバイトだけから成るCNペイロード形式の以前のバージョンはRFC1890の改正案で定義されました。 本書では定義された拡張ペイロード書式は最初のバイトだけが解釈されて、どんな追加スペクトル情報バイトも無視されると仮定する以前のバージョンの実現と互換性があった状態で後方であるべきです。

3. CN Payload Definition

3. CN有効搭載量定義

   The comfort noise payload consists of a description of the noise
   level and spectral information in the form of reflection coefficients
   for an all-pole model of the noise.  The inclusion of spectral
   information is OPTIONAL and the model order (number of coefficients)
   is left unspecified.  The encoder may choose an appropriate model
   order based on such considerations as quality, complexity, expected
   environmental noise, and signal bandwidth.  The model order is not
   explicitly transmitted since the number of coefficients can be
   derived from the length of the payload at the receiver.  The decoder
   may reduce the model order by setting higher order reflection
   coefficients to zero if desired to reduce complexity or for other
   reasons.

安らぎ雑音ペイロードは雑音のオールポールモデルのための反射率の形における、騒音レベルとスペクトル情報の記述から成ります。 スペクトル情報の包含はOPTIONALです、そして、モデル注文(係数の数)を不特定のままにします。 エンコーダは品質、複雑さが環境騒音を予想して、帯域幅を示すのでそのような問題に基づく適切なモデル注文を選ぶかもしれません。 受信機でペイロードの長さから係数の数を得ることができるので、明らかにモデル注文を伝えません。デコーダは、複雑さか他の理由で減少することが望まれているなら、より高いオーダー反射率をゼロに設定することによって、モデル注文を減らすかもしれません。

3.1 Noise Level

3.1 騒音レベル

   The magnitude of the noise level is packed into the least significant
   bits of the noise-level byte with the most significant bit unused and
   always set to 0 as shown below in Figure 1.  The least significant
   bit of the noise level magnitude is packed into the least significant
   bit of the byte.

騒音レベルの大きさは、最も重要なビットが未使用で騒音レベルバイトの最下位ビットに詰め込まれて、図1にいつも以下に示すように0に設定されます。 騒音レベルの大きさの最下位ビットはバイトの最下位ビットに詰め込まれます。

   The noise level is expressed in -dBov, with values from 0 to 127
   representing 0 to -127 dBov.  dBov is the level relative to the
   overload of the system.  (Note: Representation relative to the
   overload point of a system is particularly useful for digital
   implementations, since one does not need to know the relative
   calibration of the analog circuitry.)  For example, in the case of a
   u-law system, the reference would be a square wave with values +/-
   8031, and this square wave represents 0dBov.  This translates into
   6.18dBm0.

騒音レベルは-dBovで言い表されて、dBov. dBovはシステムのオーバーロードに比例した0〜127までの値が0〜-127を表している、レベルです。 (注意: システムのオーバーロード先に比例した表現は特にデジタル実現の役に立ちます、人がアナログ回路の相対的な較正を知る必要はないので。) 例えば、u-法のシステムの場合では、参照は値+/-8031がある矩形波でしょう、そして、この矩形波は0dBovを表します。 これは6.18dBm0に翻訳されます。

Zopf                        Standards Track                     [Page 2]

RFC 3389             RTP Payload for Comfort Noise        September 2002

Zopf規格は雑音2002年9月に安らぎのためにRFC3389RTP有効搭載量を追跡します[2ページ]。

                        0 1 2 3 4 5 6 7
                       +-+-+-+-+-+-+-+-+
                       |0|   level     |
                       +-+-+-+-+-+-+-+-+

0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |0| レベル| +-+-+-+-+-+-+-+-+

                 Figure 1: Noise Level Packing

図1: 騒音レベルパッキング

3.2 Spectral Information

3.2 スペクトル情報

   The spectral information is transmitted using reflection coefficients
   [8].  Each reflection coefficient can have values between -1 and 1
   and is quantized uniformly using 8 bits.  The quantized value is
   represented by the 8 bit index N, where N=0..,254, and index N=255 is
   reserved for future use.  Each index N is packed into a separate byte
   with the MSB first.  The quantized value of each reflection
   coefficient, k_i, can be obtained from its corresponding index using:

スペクトル情報は、反射率[8]を使用することで伝えられます。 各反射率は、一様に8ビットを使用することで-1〜1を評価して、量子化されたはずです。 量子化された値は8ビットのインデックスN、どこN=0によって表されるか。254、およびインデックスN=255はそうです。未来の使用のために、予約されます。 各インデックスNは最初に、MSBと共に別々のバイトに詰め込まれます。 対応するインデックス使用からそれぞれの反射率の量子化された値(k_i)を得ることができます:

        k_i(N_i) = 258*(N_i-127)     for N_i = 0...254; -1 < k_i < 1
                   -------------
                       32768

N_i=0のためのk_i(N_i)=258*(N_i-127)…254; -1 <k_i<1------------- 32768

3.3 Payload Packing

3.3 有効搭載量パッキング

   The first byte of the payload MUST contain the noise level as shown
   in Figure 1.  Quantized reflection coefficients are packed in
   subsequent bytes in ascending order as in Figure 2 where M is the
   model order.  The total length of the payload is M+1 bytes.  Note
   that a 0th order model (i.e., no spectral envelope information)
   reduces to transmitting only the energy level.

ペイロードの最初のバイトは図1に示されるように騒音レベルを含まなければなりません。 量子化された反射率は昇順にMがモデル注文である図2のようにその後のバイトで梱包されます。 ペイロードの全長は+1バイトMです。 0番目のオーダーモデル(すなわち、スペクトル包絡線情報がない)がエネルギーレベルだけを伝えるのに減少することに注意してください。

              Byte        1      2    3    ...   M+1
                       +-----+-----+-----+-----+-----+
                       |level|  N1 |  N2 | ... |  NM |
                       +-----+-----+-----+-----+-----+

バイト1 2 3… M+1+-----+-----+-----+-----+-----+ |レベル| N1| N2| ... | ニューメキシコ| +-----+-----+-----+-----+-----+

                Figure 2: CN Payload Packing Format

図2: 形式を梱包するCN有効搭載量

4. Usage of RTP

4. RTPの使用法

   The RTP header for the comfort noise packet SHOULD be constructed as
   if the comfort noise were an independent codec.  Thus, the RTP
   timestamp designates the beginning of the comfort noise period.  When
   this payload format is used under the RTP profile specified in RFC
   1890 [10], a static payload type of 13 is assigned for RTP timestamp
   clock rate of 8,000 Hz; if other rates are needed, they MUST be
   defined through dynamic payload types.  The RTP packet SHOULD NOT
   have the marker bit set.

安らぎのためのRTPヘッダーはパケットSHOULDを言い触らします。まるで安らぎ雑音が独立しているコーデックであるかのように組み立てられてください。その結果、RTPタイムスタンプは安らぎ雑音の期間の初めを指定します。 このペイロード形式がRFC1890[10]で指定されたRTPプロフィールの下で使用されるとき、13の静的なペイロードタイプが8,000HzのRTPタイムスタンプクロックレートのために割り当てられます。 他のレートが必要であるなら、ダイナミックなペイロードタイプでそれらを定義しなければなりません。 RTPパケットSHOULD NOTはマーカービットを設定させます。

Zopf                        Standards Track                     [Page 3]

RFC 3389             RTP Payload for Comfort Noise        September 2002

Zopf規格は雑音2002年9月に安らぎのためにRFC3389RTP有効搭載量を追跡します[3ページ]。

   Each RTP packet containing comfort noise MUST contain exactly one CN
   payload per channel.  This is required since the CN payload has a
   variable length.  If multiple audio channels are used, each channel
   MUST use the same spectral model order 'M'.

安らぎ雑音を含むそれぞれのRTPパケットはちょうど1チャンネルあたり1個のCNペイロードを含まなければなりません。 CNペイロードには可変長があるので、これが必要です。 複数の音声チャンネルが使用されているなら、各チャンネルは同じスペクトル・モデル注文'M'を使用しなければなりません。

5. Guidelines for Use

5. 使用のためのガイドライン

   An audio codec with DTX capabilities generally includes VAD, DTX, and
   CNG algorithms.  The job of the VAD is to discriminate between active
   and inactive voice segments in the input signal.  During inactive
   voice segments, the role of the CNG is to sufficiently describe the
   ambient noise while minimizing the transmission rate.  A CN payload
   (or SID frame) containing a description of the noise is sent to the
   receiver to drive the CNG.  The DTX algorithm determines when a CN
   payload is transmitted.  During active voice segments, packets of the
   voice codec are transmitted and indicated in the RTP header by the
   static or dynamic payload type for that codec.  At the beginning of
   an inactive voice segment (silence period), a CN packet is
   transmitted in the same RTP stream and indicated by the CN payload
   type.  The CN packet update rate is left implementation specific. For
   example, the CN packet may be sent periodically or only when there is
   a significant change in the background noise characteristics.  The
   CNG algorithm at the receiver uses the information in the CN payload
   to update its noise generation model and then produce an appropriate
   amount of comfort noise.

一般に、DTX能力があるオーディオコーデックはVAD、DTX、およびCNGアルゴリズムを含んでいます。VADの仕事は入力信号のアクティブで不活発な声のセグメントを区別することです。 不活発な声のセグメントのときに、CNGの役割は通信速度を最小にしている間、環境雑音について十分説明することです。 CNGを運転するために雑音の記述を含むCNペイロード(または、SIDフレーム)を受信機に送ります。 DTXアルゴリズムは、CNペイロードがいつ伝えられるかを決定します。 能動態セグメントの間、音声コーデックのパケットは、RTPヘッダーでそのコーデックのための静的であるかダイナミックなペイロードタイプによって伝えられて、示されます。CNパケットは、不活発な声のセグメント(沈黙の期間)の始めに、同じRTPの流れで伝えられて、CNペイロードタイプによって示されます。 CNパケットアップデート率は実現特有の状態でおかれます。 例えば、定期的かバックグラウンドノイズの特性における著しい変化があるときにだけ時CNパケットを送るかもしれません。 受信機のCNGアルゴリズムは、雑音世代モデルをアップデートして、次に、適切な量の安らぎ雑音を発生させるのにCNペイロードで情報を使用します。

   The CN payload format provides a minimum interoperability
   specification for communication of comfort noise parameters.  The
   comfort noise analysis and synthesis as well as the VAD and DTX
   algorithms are unspecified and left implementation-specific.
   However, an example solution for G.711 has been tested and is
   described in Appendix II of ITU-T Recommendation G.711 [8].  It uses
   the VAD and DTX of G.729 Annex B [9] and a comfort noise generation
   algorithm (CNG), which is provided in the Appendix for information.
   Additional guidelines for use such as the factors affecting system
   performance in the design of the VAD/DTX/CNG algorithms are described
   in the Appendix.

CNペイロード形式は安らぎ雑音パラメタに関するコミュニケーションのための最小の相互運用性仕様を提供します。 VADとDTXアルゴリズムと同様に安らぎ雑音解析と統合は、不特定であり、実現特有の状態でおかれます。 しかしながら、G.711の解答例は、テストされて、ITU-T Recommendation G.711[8]のAppendix IIで説明されます。 それはG.729 Annex B[9]のVADとDTXと安らぎ雑音世代アルゴリズム(CNG)を使用します。(それは、情報のためにAppendixに提供されます)。 使用のためのVAD/DTX/CNGアルゴリズムのデザインにおけるシステム性能に影響する要素などの別途ガイドラインはAppendixで説明されます。

5.1 Usage of SDP

5.1 SDPの使用法

   When using the Session Description Protocol (SDP) [11] to specify RTP
   payload information, the use of comfort noise is indicated by the
   inclusion of a payload type for CN on the media description line.
   When using CN with the RTP/AVP profile [10] and a codec whose RTP
   timestamp clock rate is 8000 Hz, such as G.711 (PCMU, static payload
   type 0), the static payload type 13 for CN can be used:

RTPペイロード情報を指定するのにSession記述プロトコル(SDP)[11]を使用するとき、安らぎ雑音の使用はメディア記述線の上のCNのためにペイロードタイプの包含で示されます。 RTP/AVPプロフィール[10]があるCNとRTPタイムスタンプクロックレートが8000HzであるG.711などのコーデック(PCMU、静的なペイロードタイプ0)を使用するとき、CNのための静的なペイロードタイプ13を使用できます:

         m=audio 49230 RTP/AVP 0 13

オーディオの49230RTP/AVP0m=13

Zopf                        Standards Track                     [Page 4]

RFC 3389             RTP Payload for Comfort Noise        September 2002

Zopf規格は雑音2002年9月に安らぎのためにRFC3389RTP有効搭載量を追跡します[4ページ]。

   When using CN with a codec that has a different RTP timestamp clock
   rate, a dynamic payload type mapping (rtpmap attribute) is required.

異なったRTPタイムスタンプクロックレートを持っているコーデックがあるCNを使用するとき、(rtpmap属性)を写像するダイナミックなペイロードタイプが必要です。

   This example shows CN used with the G.722.1 codec (see RFC 3047
   [12]):

この例はG.722.1コーデックと共に使用されるCNを示しています。(RFC3047[12])を見てください:

         m=audio 49230 RTP/AVP 101 102
         a=rtpmap:101 G7221/16000
         a=fmtp:121 bitrate=24000
         a=rtpmap:102 CN/16000

オーディオの49230RTP/AVP101 102m=a=rtpmap: 101G7221/16000 a=fmtp: 121bitrate=24000 a=rtpmap: 102CN/16000

   Omission of a payload type for CN on the media description line
   implies that this comfort noise payload format will not be used, but
   it does not imply that silence will not be suppressed.  RTP allows
   discontinuous transmission (silence suppression) on any audio payload
   format.  The receiver can detect silence suppression on the first
   packet received after the silence by observing that the RTP timestamp
   is not contiguous with the end of the interval covered by the
   previous packet even though the RTP sequence number has incremented
   only by one.  The RTP marker bit is also normally set on such a
   packet.

メディア記述線の上のCNのためのペイロードタイプの省略は、この安らぎ雑音ペイロード形式が使用されないのを含意しますが、それは、沈黙が抑圧されないのを含意しません。 RTPはどんなオーディオペイロード形式にも不連続なトランスミッション(沈黙抑圧)を許容します。 受信機はRTP一連番号が受け取りましたが、間隔の終わりが前のパケットでカバーされている状態でRTPタイムスタンプが隣接でないことを観測することによって沈黙の後に受け取った単に1つ増加された最初のパケットの上に沈黙抑圧を検出できます。 また、通常、RTPマーカービットはそのようなパケットの上に設定されます。

6. IANA Considerations

6. IANA問題

   This section defines a new RTP payload name and associated MIME type,
   CN (audio/CN).  The payload format specified in this document is also
   assigned payload type 13 in the RTP Payload Types table of the RTP
   Parameters registry maintained by the Internet Assigned Numbers
   Authority (IANA).

CN、このセクションは新しいRTPペイロード名と関連MIMEの種類を定義します(オーディオ/CN)。 また、本書では指定されたペイロード形式はインターネットAssigned民数記Authority(IANA)によって維持されたRTP Parameters登録のRTP有効搭載量Typesテーブルのペイロードタイプ13に割り当てられます。

6.1 Registration of MIME media type audio/CN

6.1 MIMEメディアタイプオーディオ/CNの登録

   MIME media type name: audio

MIMEメディア型名: オーディオ

   MIME subtype name: CN

MIME「副-タイプ」は以下を命名します。 CN

   Required parameters: None

必要なパラメタ: なし

   Optional parameters:
   rate: specifies the RTP timestamp clock rate, which is usually (but
   not always) equal to the sampling rate.  This parameter should have
   the same value as the codec used in conjunction with comfort noise.
   The default value is 8000.

任意のパラメタ: 以下を評価してください。 標本抽出率と等しい状態でRTPタイムスタンプクロックレートを指定します。 このパラメタには、安らぎ雑音に関連して使用されるコーデックと同じ値があるべきです。 デフォルト値は8000です。

Zopf                        Standards Track                     [Page 5]

RFC 3389             RTP Payload for Comfort Noise        September 2002

Zopf規格は雑音2002年9月に安らぎのためにRFC3389RTP有効搭載量を追跡します[5ページ]。

   Encoding considerations:
   This type is only defined for transfer via RTP [RFC 1889].

問題をコード化します: このタイプは転送のためにRTP[RFC1889]を通して定義されるだけです。

   Security considerations: see Section 7 "Security Considerations".

セキュリティ問題: 「セキュリティ問題」というセクション7を見てください。

   Interoperability considerations: none

相互運用性問題: なし

   Published specification:
   This document and Appendix II of ITU-T Recommendation G.711

広められた仕様: ITU-T Recommendation G.711のこのドキュメントとAppendix II

   Applications which use this media type:
   Audio and video streaming and conferencing tools.

このメディアタイプを使用するアプリケーション: オーディオ、ビデオ・ストリーミング、および会議ツール。

   Additional information: none

追加情報: なし

   Person & email address to contact for further information:
   Robert Zopf
   zopf@lucent.com

詳細のために連絡する人とEメールアドレス: ロバートZopf zopf@lucent.com

   Intended usage: COMMON

意図している用法: 一般的

   Author/Change controller:
   Author: Robert Zopf
   Change controller: IETF AVT Working Group

コントローラを書くか、または変えてください: 以下を書いてください。 ロバートZopf Changeコントローラ: IETF AVT作業部会

7. Security Considerations

7. セキュリティ問題

   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification [1].  This implies that confidentiality of the media
   streams is achieved by encryption.  Because the payload format is
   arranged end-to-end, encryption MAY be performed after encapsulation
   so there is no conflict between the two operations.

この仕様に基づき定義されたペイロード書式を使用するRTPパケットはRTP仕様[1]で議論したセキュリティ問題を受けることがあります。 これは、メディアの流れの秘密性が暗号化で達成されるのを含意します。 ペイロード形式が整っている終わりから終わりであるので、暗号化がカプセル化の後に実行されるかもしれないので、2つの操作の間には、闘争が全くありません。

   As this format transports background noise, there are no significant
   security, confidentiality, or authentication concerns.

この形式がバックグラウンドノイズを輸送するとき、どんな重要なセキュリティ、秘密性も、または認証関心もありません。

8. References

8. 参照

   [1]  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
        "RTP: A Transport Protocol for Real-Time Applications", RFC
        1889, January 1996.

[1]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。

   [2]  ITU Recommendation G.711 (11/88) - Pulse code modulation (PCM)
        of voice frequencies.

[2]、ITU Recommendation G.711(11/88)--音声周波数のパルス符号変調(PCM)。

Zopf                        Standards Track                     [Page 6]

RFC 3389             RTP Payload for Comfort Noise        September 2002

Zopf規格は雑音2002年9月に安らぎのためにRFC3389RTP有効搭載量を追跡します[6ページ]。

   [3]  ITU Recommendation G.726 (12/90) - 40, 32, 24, 16 kbit/s
        Adaptive Differential Pulse Code Modulation (ADPCM).

[3]、ITU Recommendation G.726(12/90)--40、32、24、16kbit/s Adaptive Differentialパルスコードの変調(ADPCM)。

   [4]  ITU Recommendation G.727 (12/90) - 5-, 4-, 3- and 2-bits sample
        embedded adaptive differential pulse code modulation (ADPCM).

[4]、ITU Recommendation G.727(12/90)--5、4 3と2ビットのサンプルは適応差分パルス符号変調方式(ADPCM)を埋め込みました。

   [5]  ITU Recommendation G.728 (09/92) - Coding of speech at 16
        kbits/s using low-delay code excited linear prediction.

[5] ITU Recommendation G.728(09/92)--スピーチがコード化されて、16kbits/s使用では、コードを安値で遅らせてください。直線的な予測を起こさせました。

   [6]  ITU Recommendation G.722 (11/88) - 7 kHz audio-coding within 64
        kbit/s.

[6]、ITU Recommendation G.722(11/88)--64kbit/sの中の7kHzのオーディオ符号化。

   [7]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[7] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [8]  Appendix II to Recommendation G.711 (02/2000) - A comfort noise
        payload definition for ITU-T G.711 use in packet-based
        multimedia communication systems.

Recommendation G.711(02/2000)への[8]付録II--パケットベースのマルチメディア通信システムにおけるITU-T G.711使用のための安らぎ雑音ペイロード定義。

   [9]  Annex B (08/97) to Recommendation G.729 - C source code and test
        vectors for implementation verification of the algorithm of the
        G.729 silence compression scheme.

[9] B(08/97)をRecommendation G.729に付加してください--G.729沈黙圧縮技術のアルゴリズムの実現検証のためのCソースコードとテストベクトル。

   [10] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
        with Minimal Control", RFC 1890, January 1996.

[10]Schulzrinne、H.、「最小量のコントロールがあるオーディオとテレビ会議システムのためのRTPプロフィール」、RFC1890、1996年1月。

   [11] Handley, M. and V. Jacobson, "SDP: Session Description
        Protocol", RFC 2327, April 1998.

[11] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。

   [12] Luthi, P., "RTP Payload Format for ITU-T Recommendation
        G.722.1", RFC 3047, January 2001.

[12] リューティ、P.、「ITU-T推薦G.722.1のためのRTP有効搭載量形式」、RFC3047、2001年1月。

9. Author's Address

9. 作者のアドレス

   Robert Zopf
   Lucent Technologies
   INS Access VoIP Networks
   2G-234A
   101 Crawfords Corner Rd
   Holmdel, NJ  07733-3030  US

ロバートZopfルーセントテクノロジーズINSアクセスVoIPネットワーク2G-234A101Crawfordsコーナー第Holmdel、ニュージャージー07733-3030米国

   Phone:   1-732-949-1667
   Fax:   1-732-949-7016
   EMail: zopf@lucent.com

以下に電話をしてください。 1-732-949-1667 Fax: 1-732-949-7016 メールしてください: zopf@lucent.com

Zopf                        Standards Track                     [Page 7]

RFC 3389             RTP Payload for Comfort Noise        September 2002

Zopf規格は雑音2002年9月に安らぎのためにRFC3389RTP有効搭載量を追跡します[7ページ]。

10. Full Copyright Statement

10. 完全な著作権宣言文

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Zopf                        Standards Track                     [Page 8]

Zopf標準化過程[8ページ]