[要約] RFC 6366は、インターネットオーディオコーデックの要件を定義するものであり、高品質な音声通信を実現することを目的としています。
Internet Engineering Task Force (IETF) J. Valin
Request for Comments: 6366 Mozilla
Category: Informational K. Vos
ISSN: 2070-1721 Skype Technologies, S.A.
August 2011
Requirements for an Internet Audio Codec
インターネットオーディオコーデックの要件
Abstract
概要
This document provides specific requirements for an Internet audio codec. These requirements address quality, sampling rate, bit-rate, and packet-loss robustness, as well as other desirable properties.
このドキュメントは、インターネットオーディオコーデックの特定の要件を提供します。これらの要件は、品質、サンプリングレート、ビットレート、およびパケット損失の堅牢性、およびその他の望ましいプロパティに対応しています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6366.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6366で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
2. Definitions .....................................................3
3. Applications ....................................................3
3.1. Point-to-Point Calls .......................................3
3.2. Conferencing ...............................................4
3.3. Telepresence ...............................................5
3.4. Teleoperation and Remote Software Services .................5
3.5. In-Game Voice Chat .........................................5
3.6. Live Distributed Music Performances / Internet
Music Lessons ..............................................6
3.7. Delay-Tolerant Networking or Push-to-Talk Services .........6
3.8. Other Applications .........................................7
4. Constraints Imposed by the Internet on the Codec ................7
5. Detailed Basic Requirements .....................................8
5.1. Operating Space ............................................9
5.2. Quality and Bit-Rate .......................................9
5.3. Packet-Loss Robustness ....................................10
5.4. Computational Resources ...................................10
6. Additional Considerations ......................................12
6.1. Low-Complexity Audio Mixing ...............................12
6.2. Encoder Side Potential for Improvement ....................12
6.3. Layered Bit-Stream ........................................13
6.4. Partial Redundancy ........................................13
6.5. Stereo Support ............................................13
6.6. Bit Error Robustness ......................................13
6.7. Time Stretching and Shortening ............................14
6.8. Input Robustness ..........................................14
6.9. Support of Audio Forensics ................................14
6.10. Legacy Compatibility .....................................14
7. Security Considerations ........................................14
8. Acknowledgments ................................................15
9. Informative References .........................................15
This document provides requirements for an audio codec designed specifically for use over the Internet. The requirements attempt to address the needs of the most common Internet interactive audio transmission applications and ensure good quality when operating in conditions that are typical for the Internet. These requirements also address the quality, sampling rate, delay, bit-rate, and packet-loss robustness. Other desirable codec properties are considered as well.
このドキュメントは、インターネット経由で使用するために特別に設計されたオーディオコーデックの要件を提供します。この要件は、最も一般的なインターネットインタラクティブなオーディオ伝送アプリケーションのニーズに対応し、インターネットに典型的な条件で動作するときに良質の品質を確保しようとします。これらの要件は、品質、サンプリングレート、遅延、ビットレート、およびパケット損失の堅牢性にも対応しています。他の望ましいコーデックプロパティも考慮されます。
Throughout this document, the following conventions refer to the sampling rate of a signal:
このドキュメント全体で、次の規則は、信号のサンプリングレートを指します。
Narrowband: 8 kilohertz (kHz)
ナローバンド：8キロハツ（KHZ）
Wideband: 16 kHz
ワイドバンド：16 kHz
Super-wideband: 24/32 kHz
スーパーワイドバンド：24/32 kHz
Full-band: 44.1/48 kHz
フルバンド：44.1/48 kHz
Codec bit-rates in bits per second (bit/s) will be considered without counting any overhead ((IP/UDP/RTP) headers, padding, etc.). The codec delay is the total algorithmic delay when one adds the codec frame size to the "look-ahead". Thus, it is the minimum theoretically achievable end-to-end delay of a transmission system that uses the codec.
1秒あたりのビット（ビット/s）のコーデックビットレートは、オーバーヘッド（（IP/UDP/RTP）ヘッダー、パディングなど）をカウントせずに考慮されます。コーデックの遅延は、コーデックフレームサイズを「見た目」に追加すると、アルゴリズムの総遅延です。したがって、コーデックを使用するのは、伝送システムの理論的に達成可能なエンドツーエンド遅延です。
The following applications should be considered for Internet audio codecs, along with their requirements:
次のアプリケーションは、インターネットオーディオコーデックの要件とともに考慮する必要があります。
o Point-to-point calls
o ポイントツーポイントコール
o Conferencing
o 会議
o Telepresence
o テレプレゼンス
o Teleoperation
o 遠隔操作
o In-game voice chat
o ゲーム内の音声チャット
o Live distributed music performances / Internet music lessons
o ライブ分配された音楽パフォーマンス /インターネット音楽のレッスン
o Delay-tolerant networking or push-to-talk services
o 遅延耐性ネットワーキングまたはプッシュツートークサービス
o Other applications
o その他のアプリケーション
Point-to-point calls are voice over IP (VoIP) calls from two "standard" (fixed or mobile) phones, and implemented in hardware or software. For these applications, a wideband codec is required, along with narrowband support for compatibility with a public switched telephone network (PSTN). It is expected for the range of
ポイントツーポイント呼び出しは、2つの「標準」（固定またはモバイル）の電話からのVoice over IP（VoIP）呼び出しであり、ハードウェアまたはソフトウェアに実装されています。これらのアプリケーションには、広帯域コーデックが必要であり、公開された電話ネットワーク（PSTN）との互換性に対する狭帯域のサポートが必要です。の範囲に期待されています
useful bit-rates to be 12 - 32 kilobits per second (kbit/s) for wideband speech and 8 - 16 kbit/s for narrowband speech. The codec delay must be less than 40 milliseconds (ms), but no more than 25 ms is desirable. Support for encoding music is not required, but it is desirable for the codec not to make background (on-hold) music excessively unpleasant to hear. Also, the codec should be robust to noise (produce intelligible speech and no annoying artifacts) even at lower bit-rates.
ワイドバンド音声では12〜32キロビット/秒（kbit/s）、狭帯域発話では8〜16 kbit/sの有用なビットレート。コーデックの遅延は40ミリ秒（MS）未満でなければなりませんが、25ミリ秒以下では望ましいです。音楽のエンコーディングのサポートは必要ありませんが、コーデックが背景（オンホールド）音楽を過度に不快にすることを聞かないことが望ましいです。また、コーデックは、ビットレートが低い場合でも、ノイズに対して堅牢である必要があります（わかりやすい音声を生成し、迷惑なアーティファクトはありません）。
Conferencing applications (that support multi-party calls) have additional requirements on top of the requirements for point-to-point calls. Conferencing systems often have higher-fidelity audio equipment and have greater network bandwidth available -- especially when video transmission is involved. Therefore, support for super-wideband audio becomes important, with useful bit-rates in the 32 - 64 kbit/s range. The ability to vary the bit-rate, according to the "difficulty" of the audio signal, is a desirable feature for the codec. This not only saves bandwidth "on average", but it can also help conference servers make more efficient use of the available bandwidth, by using more bandwidth for important audio streams and less bandwidth for less important ones (e.g., background noise).
会議アプリケーション（マルチパーティコールをサポートする）は、ポイントツーポイントコールの要件に加えて追加の要件があります。会議システムには、多くの場合、忠実度の高いオーディオ機器があり、特にビデオ伝送が関係する場合は、より大きなネットワーク帯域幅を利用できます。したがって、スーパーワイドバンドオーディオのサポートが重要になり、32〜64 Kbit/sの範囲で有用なビットレートがあります。オーディオ信号の「難易度」によると、ビットレートを変更する機能は、コーデックにとって望ましい機能です。これにより、帯域幅は「平均して」節約されるだけでなく、重要なオーディオストリームに帯域幅をより多く使用し、重要性の低いものでは帯域幅（バックグラウンドノイズなど）を使用することにより、会議サーバーが利用可能な帯域幅をより効率的に使用できるようにすることもできます。
Conferencing end-points often operate in hands-free conditions, which creates acoustic echo problems. Therefore, lower delay is important, as it reduces the quality degradation due to any residual echo after acoustic echo cancellation (AEC). Consequently, the codec delay must be less than 30 ms for this application. An optional low-delay mode with less than 10 ms delay is desirable, but not required.
会議のエンドポイントは、多くの場合、ハンズフリーの条件で動作し、音響エコーの問題を引き起こします。したがって、音響エコーキャンセル（AEC）後の残留エコーのために品質分解を減らすため、より低い遅延が重要です。したがって、このアプリケーションでは、コーデックの遅延は30ミリ秒未満でなければなりません。10ミリ秒未満の遅延を備えたオプションの低遅延モードが望ましいが、必須ではない。
Most conferencing systems operate with a bridge that mixes some (or all) of the audio streams and sends them back to all the participants. In that case, it is important that the codec not produce annoying artifacts when two voices are present at the same time. Also, this mixing operation should be as easy as possible to perform. To make it easier to determine which streams have to be mixed (and which are noise/silence), it must be possible to measure (or estimate) the voice activity in a packet without having to fully decode the packet (saving most of the complexity when the packet need not be decoded). Also, the ability to save on the computational complexity when mixing is also desirable, but not required. For example, a transform codec may make it possible to mix the streams in the transform domain, without having to go back to time-domain. Low-complexity up-sampling and down-sampling within the codec is also a desirable feature when mixing streams with different sampling rates.
ほとんどの会議システムは、オーディオストリームの一部（またはすべて）を混ぜて、すべての参加者に送り返すブリッジで動作します。その場合、2つの声が同時に存在する場合、コーデックが迷惑なアーティファクトを生成しないことが重要です。また、このミキシング操作は、できるだけ簡単に実行できるはずです。どのストリームを混合する必要があるか（どのノイズ/サイレンスであるか）を簡単に判断できるようにするには、パケットを完全にデコードすることなく、パケット内の音声アクティビティを測定（または推定）することが可能である必要があります（ほとんどの複雑さを保存しますパケットをデコードする必要がない場合）。また、混合が望ましいが必要ありませんが、混合が望ましいときに計算の複雑さを保存する機能もあります。たとえば、変換コーデックにより、Time Domainに戻ることなく、変換ドメインのストリームを混合できる可能性があります。コーデック内での低複雑度のアップサンプリングとダウンサンプリングは、ストリームを異なるサンプリングレートと混合する場合にも望ましい機能です。
Most telepresence applications can be considered to be essentially very high-quality video-conferencing environments, so all of the conferencing requirements also apply to telepresence. In addition, telepresence applications require super-wideband and full-band audio capability with useful bit-rates in the 32 - 80 kbit/s range. While voice is still the most important signal to be encoded, it must be possible to obtain good quality (even if not transparent) music.
ほとんどのテレプレゼンスアプリケーションは、本質的に非常に高品質のビデオ会議環境であると考えることができるため、すべての会議要件もテレプレゼンスにも適用されます。さらに、テレプレゼンスアプリケーションには、32〜80 kbit/sの範囲で有用なビットレートを備えたスーパーワイドバンドおよびフルバンドオーディオ機能が必要です。音声は依然としてエンコードされる最も重要なシグナルですが、高品質（透明ではない場合でも）を取得することが可能である必要があります。
Most telepresence applications require more than one audio channel, so support for stereo and multi-channel is important. While this can always be accomplished by encoding multiple single-channel streams, it is preferable to take advantage of the redundancy that exists between channels.
ほとんどのテレプレゼンスアプリケーションには複数のオーディオチャネルが必要なため、ステレオとマルチチャネルのサポートが重要です。これは常に複数のシングルチャネルストリームをエンコードすることで実現できますが、チャネル間に存在する冗長性を活用することが望ましいです。
Teleoperation applications are similar to telepresence, with the exception that they involve remote physical interactions. For example, the user may be controlling a robot while receiving real-time audio feedback from that robot. For these applications, the delay has to be less than 10 ms. The other requirements of telepresence (quality, bit-rate, multi-channel) apply to teleoperation as well. The only exception is that mixing is not an important issue for teleoperation.
遠隔操作アプリケーションは、遠隔の物理的相互作用が含まれることを除いて、テレプレゼンスに似ています。たとえば、ユーザーは、そのロボットからリアルタイムのオーディオフィードバックを受信しながらロボットを制御している場合があります。これらのアプリケーションでは、遅延は10ミリ秒未満でなければなりません。テレプレゼンスの他の要件（品質、ビットレート、マルチチャネル）もテレオ操作に適用されます。唯一の例外は、ミキシングが遠隔操作にとって重要な問題ではないということです。
The requirements for remote software services are similar to those of teleoperation. These applications include remote desktop applications, remote virtualization, and interactive media application being rendered remotely (e.g., video games rendered on central servers). For all these applications, full-band audio with an algorithmic delay below 10 ms are important.
リモートソフトウェアサービスの要件は、テレオ操作の要件に似ています。これらのアプリケーションには、リモートデスクトップアプリケーション、リモート仮想化、インタラクティブメディアアプリケーションがリモートでレンダリングされています（たとえば、セントラルサーバーでレンダリングされたビデオゲームなど）。これらすべてのアプリケーションでは、10ミリ秒未満のアルゴリズム遅延を伴うフルバンドオーディオが重要です。
An increasing number of computer/console games make use of VoIP to allow players to communicate in real time. The requirements for gaming are similar to those of conferencing, with the main difference being that narrowband compatibility is not necessary. While for most applications a codec delay up to 30 ms is acceptable, a low-delay (< 10 ms) option is highly desirable, especially for games with rapid interactions. The ability to use variable bit-rate (VBR) (with a maximum allowed bit-rate) is also highly desirable because it can significantly reduce the bandwidth requirement for a game server.
コンピューター/コンソールゲームの数が増えているため、VoIPを使用して、プレイヤーがリアルタイムで通信できるようにします。ゲームの要件は会議の要件に似ており、主な違いは狭帯域の互換性が必要ないということです。ほとんどのアプリケーションでは、最大30ミリ秒までのコーデック遅延は許容されますが、特に迅速な相互作用のあるゲームでは、低遅延（<10ミリ秒）オプションが非常に望ましいです。可変ビットレート（VBR）（最大許可ビットレートを使用）を使用する機能も、ゲームサーバーの帯域幅要件を大幅に削減できるため、非常に望ましいものです。
Live music over the Internet requires extremely low end-to-end delay and is one of the most demanding applications for interactive audio transmission. It has been observed that for most scenarios, total end-to-end delays up to 25 ms could be tolerated by musicians, with the absolute limit (where none of the scenarios are possible) being around 50 ms [carot09]. In order to achieve this low delay on the Internet -- either in the same city or in a nearby city -- the network propagation time must be taken into account. When also subtracting the delay of the audio buffer, jitter buffer, and acoustic path, that leaves around 2 ms to 10 ms for the total delay of the codec. Considering the speed of light in fiber, every 1 ms reduction in the codec delay increases the range over which synchronization is possible by approximately 200 km.
インターネット上のライブミュージックには、非常に低いエンドツーエンドの遅延が必要であり、インタラクティブなオーディオ伝送に最も要求の厳しいアプリケーションの1つです。ほとんどのシナリオでは、ミュージシャンが最大25ミリ秒までの総エンドツーエンド遅延を許容できることが観察されています。同じ都市または近くの都市のいずれかで、インターネットでこの低遅延を達成するには、ネットワークの伝播時間を考慮する必要があります。また、オーディオバッファー、ジッターバッファー、アコースティックパスの遅延を差し引くと、コーデックの合計遅延のために約2ミリ秒から10ミリ秒が残ります。繊維の光の速度を考慮すると、コーデック遅延の1ミリ秒の減少ごとに、同期が約200 kmの範囲が増加します。
Acoustic echo is expected to be an even more important issue for network music than it is in conferencing, especially considering that the music quality requirements essentially forbid the use of a "non-linear processor" (NLP) with AEC. This is another reason why very low delay is essential.
アコースティックエコーは、特に音楽の品質要件がAECとの「非線形プロセッサ」（NLP）の使用を本質的に禁止することを考慮すると、会議よりもネットワーク音楽にとってさらに重要な問題になると予想されます。これが、非常に低い遅延が不可欠であるもう1つの理由です。
Considering that the application is music, the full audio bandwidth (44.1 or 48 kHz sampling rate) must be transmitted with a bit-rate that is sufficient to provide near-transparent to transparent quality. With the current audio coding technology, this corresponds to approximately 64 kbit/s to 128 kbit/s per channel. As for telepresence, support for two or more channels is often desired, so it would be useful for a codec to be able to take advantage of the redundancy that is often present between audio channels.
アプリケーションが音楽であることを考慮すると、完全なオーディオ帯域幅（44.1または48 kHzのサンプリングレート）は、透明な品質に対してほぼ透明性を提供するのに十分なビットレートで送信する必要があります。現在のオーディオコーディングテクノロジーでは、これはチャネルあたり約64 kbit/sから128 kbit/sに相当します。テレプレゼンスに関しては、2つ以上のチャネルのサポートが望まれることが多いため、コーデックがオーディオチャネル間に存在することが多い冗長性を利用できるようにすることが役立ちます。
Internet transmissions are subjected to interruptions of connectivity that severely disturb a phone call. This may happen in cases of route changes, handovers, slow fading, or device failures. To overcome this distortion, the phone call can be halted and resumed after the connectivity has been reestablished again.
インターネット送信は、電話を激しく妨害する接続性の中断にさらされます。これは、ルートの変更、携帯電話、ゆっくりしたフェード、またはデバイスの障害の場合に発生する可能性があります。この歪みを克服するために、接続が再び再確立された後、電話を停止して再開することができます。
Also, if transmission capacity is lower than the minimal coding rate, switching to a push-to-talk mode still allows for effective communication. In this situation, voice is transmitted at slower-than-real-time bit-rate and conversations are interrupted until the speech has been transmitted.
また、送信容量が最小コードレートよりも低い場合、プッシュツートークモードに切り替えると、効果的な通信が可能になります。この状況では、音声はリアルよりも遅いビットレートで送信され、スピーチが伝わるまで会話が中断されます。
These modes require interrupting the audio playout and continuing after a pause of arbitrary duration.
これらのモードでは、オーディオプレイアウトを中断し、任意の期間が一時停止した後も継続する必要があります。
The above list is by no means a complete list of all applications involving interactive audio transmission on the Internet. However, it is believed that meeting the needs of all these different applications should be sufficient to ensure that the needs of other applications not listed will also be met.
上記のリストは、インターネット上のインタラクティブなオーディオ伝送を含むすべてのアプリケーションの完全なリストではありません。ただし、これらすべての異なるアプリケーションのニーズを満たすことは、リストされていない他のアプリケーションのニーズも満たされることを保証するのに十分であるべきであると考えられています。
Packet losses are inevitable on the Internet, and dealing with them is one of the most fundamental requirements for an Internet audio codec. While any audio codec can be combined with a good packet-loss concealment (PLC) algorithm, the important aspect is what happens on the first packets received _after_ the loss. More specifically, this means that:
インターネットではパケットの損失は避けられず、それらを扱うことは、インターネットオーディオコーデックの最も基本的な要件の1つです。オーディオコーデックは、優れたパケットロスの隠蔽（PLC）アルゴリズムと組み合わせることができますが、重要な側面は、最初のパケットで発生する_after_損失です。より具体的には、これは次のことを意味します。
o it should be possible to interpret the contents of any received packet, irrespective of previous losses as specified in BCP 36 [PAYLOADS]; and
o BCP 36 [ペイロード]で指定された以前の損失に関係なく、受け取ったパケットの内容を解釈することが可能です。と
o the decoder should re-synchronize as quickly as possible (i.e., the output should quickly converge to the output that would have been obtained if no loss had occurred).
o デコーダーはできるだけ早く再同期する必要があります（つまり、出力は、損失が発生しなかった場合に得られた出力に迅速に収束する必要があります）。
The constraint of being able to decode any packet implies the following considerations for an audio codec:
パケットをデコードできるという制約は、オーディオコーデックの次の考慮事項を意味します。
o The size of a compressed frame must be kept smaller than the MTU to avoid fragmentation;
o 断片化を避けるために、圧縮フレームのサイズはMTUよりも小さく保つ必要があります。
o The interpretation of any parameter encoded in the bit-stream must not depend on information contained in other packets. For example, it is not acceptable for a codec to allow signaling a mode change in one packet and assume that subsequent frames will be decoded according to that mode.
o ビットストリームでエンコードされたパラメーターの解釈は、他のパケットに含まれる情報に依存してはなりません。たとえば、コーデックが1つのパケットのモード変更を信号することを許可し、その後のフレームがそのモードに従ってデコードされると仮定することは許容できません。
Although the interpretation of parameters cannot depend on other packets, it is still reasonable to use some amount of prediction across frames, provided that the predictors can resynchronize quickly in case of a lost packet. In this case, it is important to use the best compromise between the gain in coding efficiency and the loss in packet loss robustness due to the use of inter-frame prediction. It is a desirable property for the codec to allow some real-time control of that trade-off, so that it can take advantage of more prediction when the loss rate is small, while being more robust to losses when the loss rate is high.
パラメーターの解釈は他のパケットに依存することはできませんが、予測因子がパケットの紛失の場合に迅速に再同期することができれば、フレーム全体である程度の予測を使用することは依然として合理的です。この場合、コーディング効率のゲインとパケット損失の堅牢性の損失との間の最良の妥協点を使用することが重要です。コーデックがそのトレードオフをリアルタイムで制御できるようにすることは望ましいプロパティであり、損失率が小さいときにより多くの予測を利用できるようにしますが、損失率が高い場合は損失に対してより堅牢です。
To improve the robustness to packet loss, it would be desirable for the codec to allow an adaptive (data- and network-dependent) amount of side information to help improve audio quality when losses occur. For example, side information may include the retransmission of certain parameters encoded in the previous frame(s).
パケット損失に対する堅牢性を向上させるには、コーデックが適応型（データ依存およびネットワーク依存の）量のサイド情報を許可して、損失が発生したときにオーディオの品質を改善することが望ましいでしょう。たとえば、サイド情報には、前のフレームにエンコードされた特定のパラメーターの再送信が含まれる場合があります。
To ensure freedom of implementation, decoder-side-only error concealment does not need to be specified, although a functional PLC algorithm is desirable as part of the codec reference implementation. Obviously, any information signaled in the bit-stream intended to aid PLC needs to be specified.
実装の自由を確保するには、Decoder-Sideのみのエラーの隠蔽を指定する必要はありませんが、Codec参照実装の一部として機能的なPLCアルゴリズムが望ましいものです。明らかに、PLCを支援することを目的としたビットストリームで合図された情報を指定する必要があります。
Another important property of the Internet is that it is mostly a best-effort network, with no guaranteed bandwidth. This means that the codec has to be able to vary its output bit-rate dynamically (in real time), without requiring an out-of-band signaling mechanism, and without causing audible artifacts at the bit-rate change boundaries. Additional desirable features are:
インターネットのもう1つの重要な特性は、それがほとんどがベストエフォルトネットワークであり、保証された帯域幅がないことです。つまり、コーデックは、帯域外のシグナル伝達メカニズムを必要とせずに、ビットレートの変更境界で可聴アーティファクトを引き起こすことなく、その出力ビットレートを動的に（リアルタイムで）変化させることができなければならないことを意味します。追加の望ましい機能は次のとおりです。
o Having the possibility to use smooth bit-rate changes with one byte/frame resolution;
o 1つのバイト/フレーム解像度でスムーズなビットレートの変更を使用する可能性があります。
o Making it possible for a codec to adapt its bit-rate based on the source signal being encoded (source-controlled VBR) to maximize the quality for a certain _average_ bit-rate.
o エンコードされているソース信号（ソース制御VBR）に基づいて、コーデックが特定の_Average_ビットレートの品質を最大化することを可能にします。
Because the Internet transmits data in bytes, a codec should produce compressed data in integer numbers of bytes. In general, the codec design should take into consideration explicit congestion notification (ECN) and may include features that would improve the quality of an ECN implementation.
インターネットはデータをバイトで送信するため、コーデックは整数数のバイトで圧縮データを生成するはずです。一般に、コーデック設計では、明示的な輻輳通知（ECN）を考慮し、ECN実装の品質を改善する機能を含めることができます。
The IETF has defined a set of application-layer protocols to be used for transmitting real-time transport of multimedia data, including voice. Thus, it is important for the resulting codec to be easy to use with these protocols. For example, it must be possible to create an [RTP] payload format that conforms to BCP 36 [PAYLOADS]. If any codec parameters need to be negotiated between end-points, the negotiation should be as easy as possible to carry over session initiation protocol (SIP) [RFC3261]/ session description protocol (SDP) [RFC4566] or alternatively over extensible messaging and presence protocol (XMPP) [RFC6120] / Jingle [XEP-0167].
IETFは、音声を含むマルチメディアデータのリアルタイム輸送を送信するために使用されるアプリケーション層プロトコルのセットを定義しました。したがって、結果のコーデックがこれらのプロトコルで使いやすいことが重要です。たとえば、BCP 36 [ペイロード]に適合する[RTP]ペイロード形式を作成することが可能である必要があります。エンドポイント間でコーデックパラメーターを交渉する必要がある場合、セッション開始プロトコル（SIP）[RFC3261]/セッション説明プロトコル（SDP）[RFC4566]または拡張可能なメッセージングと存在よりも交渉が可能な限り簡単になるはずです。プロトコル（XMPP）[RFC6120] / Jingle [XEP-0167]。
This section summarizes all the constraints imposed by the target applications and by the Internet into a set of actual requirements for codec development.
このセクションでは、ターゲットアプリケーションとインターネットによって課されるすべての制約を、コーデック開発の実際の要件にまとめます。
The operating space for the target applications can be divided in terms of delay: most applications require a "medium delay" (20-30 ms), while a few require a "very low delay" (< 10 ms). It makes sense to divide the space based on delay because lowering the delay has a cost in terms of quality versus bit-rate.
ターゲットアプリケーションの動作スペースは、遅延の観点から分割できます。ほとんどのアプリケーションには「中程度の遅延」（20〜30ミリ秒）が必要ですが、「非常に低い遅延」（<10ミリ秒）が必要です。遅延を下げると品質とビットレートの点でコストがかかるため、遅延に基づいてスペースを分割することは理にかなっています。
For medium delay, the resulting codec must be able to efficiently operate within the following range of bit-rates (per channel):
中程度の遅延のために、結果のコーデックは、次のビットレート（チャネルごと）の範囲内で効率的に動作できる必要があります。
o Narrowband: 8 kbit/s to 16 kbit/s
o ナローバンド：8 kbit/sから16 kbit/s
o Wideband: 12 to 32 kbit/s
o ワイドバンド：12〜32 kbit/s
o Super-wideband: 24 to 64 kbit/s
o スーパーワイドバンド：24〜64 kbit/s
o Full-band: 32 to 80 kbit/s
o フルバンド：32〜80 kbit/s
Obviously, a lower-delay codec that can operate in the above range is also acceptable.
明らかに、上記の範囲で動作できる低遅延コーデックも許容されます。
For very low delay, the resulting codec will need to operate within the following range of bit-rates (per channel):
非常に低い遅延のために、結果のコーデックは次のビットレートの範囲内で動作する必要があります（チャネルごと）。
o Super-wideband: 32 to 80 kbit/s
o スーパーワイドバンド：32〜80 kbit/s
o Full-band: 48 to 128 kbit/s
o フルバンド：48〜128 kbit/s
o (Narrowband and wideband not required)
o （ナローバンドとワイドバンドは不要）
The quality of a codec is directly linked to the bit-rate, so these two must be considered jointly. When comparing the bit-rate of codecs, the overhead of IP/UDP/RTP headers should not be considered, but any additional bits required in the RTP payload format, after the header (e.g., required signaling), should be considered. In terms of quality versus bit-rate, the codec to be developed must be better than the following codecs, that are generally considered royalty-free:
コーデックの品質はビットレートに直接リンクされているため、これら2つは共同で考慮する必要があります。コーデックのビットレートを比較する場合、IP/UDP/RTPヘッダーのオーバーヘッドを考慮すべきではありませんが、ヘッダー（たとえば、必要なシグナル伝達）の後にRTPペイロード形式に必要な追加ビットを考慮する必要があります。品質対ビット率の観点から、開発されるコーデックは、一般的にロイヤリティフリーと見なされる次のコーデックよりも優れている必要があります。
o For narrowband: Speex (NB) [Speex], and internet low bit-rate codec (iLBC)(*) [RFC3951]
o ナローバンドの場合：SPEEX（NB）[SPEEX]、およびインターネット低ビットレートコーデック（ILBC）（*）[RFC3951]
o For wideband: Speex (WB) [Speex], G.722.1(*) [ITU.G722.1]
o ワイドバンドの場合：SPEEX（WB）[SPEEX]、G.722.1（*）[ITU.G722.1]
o For super-wideband/fullband: G.722.1C(*) [ITU.G722.1]
o スーパーワイドバンド/フルバンドの場合：g.722.1c（*）[itu.g722.1]
The codecs marked with (*) have additional licensing restrictions, but the codec to be developed should still not perform significantly worse. In addition to the quality targets listed above, a desirable objective is for the codec quality to be no worse than Adaptive Multi-Rate (AMR-NB) and Adaptive Multi-Rate Wideband (AMR-WB). Quality should be measured for multiple languages, including tonal languages. The case of multiple simultaneous voices (as sometimes happens in conferencing) should be evaluated as well.
（*）でマークされたコーデックには追加のライセンス制限がありますが、開発されるコーデックはまだ大幅に悪化してはなりません。上記の品質目標に加えて、望ましい目的は、コーデックの品質が適応的なマルチレート（AMR-NB）および適応型マルチレート広帯域（AMR-WB）よりも悪いことではないことです。品質は、音色言語を含む複数の言語で測定する必要があります。複数の同時の声の場合（会議で時々起こるように）同様に評価する必要があります。
The comparison with the above codecs assumes that the codecs being compared have similar delay characteristics. The bit-rate required, for a certain level of quality, may be higher than the referenced codecs in cases where a much lower delay is required. In that case, the increase in bit-rate must be less than the ratio between the delays.
上記のコーデックとの比較は、比較されているコーデックには同様の遅延特性があることを前提としています。一定レベルの品質のために必要なビットレートは、はるかに低い遅延が必要な場合に参照されるコーデックよりも高い場合があります。その場合、ビット率の増加は、遅延間の比率よりも少ない必要があります。
It is desirable for the codecs to support source-controlled variable bit-rate (VBR) to take advantage of different inputs, that require a different bit-rate, to achieve the same quality. However, it should still be possible to use the codec at a truly constant bit-rate to ensure that no information leak is possible when using an encrypted channel.
コーデックがソース制御された可変ビットレート（VBR）をサポートして、同じ品質を達成するために異なるビットレートを必要とするさまざまな入力を利用することが望ましいです。ただし、暗号化されたチャネルを使用するときに情報漏れが不可能であることを確認して、真に一定のビットレートでコーデックを使用することはまだ可能です。
Robustness to packet loss is a very important aspect of any codec to be used on the Internet. Codecs must maintain acceptable quality at loss rates up to 5% and maintain good intelligibility up to 15% loss rate. At any sampling rate, bit-rate, and packet-loss rate, the quality must be no less than the quality obtained with the Speex codec or the Global System for Mobile Communications - Full Rate (GSM-FR) codec in the same conditions. The actual packet-loss "patterns" to be used in testing must be obtained from real packet-loss traces collected on the Internet, rather than from loss models. These traces should be representative of the typical environments in which the applications of Section 3 operate. For example, traces related to VoIP calls should consider the loss patterns observed for typical home broadband and corporate connections.
パケット損失に対する堅牢性は、インターネットで使用されるコーデックの非常に重要な側面です。コーデックは、最大5％までの損失率で許容品質を維持し、最大15％の損失率を維持する必要があります。サンプリングレート、ビットレート、およびパケット損失率では、品質は、同じ条件でのMobile通信のためのSPEEXコーデックまたはモバイル通信のためのグローバルシステム - フルレート（GSM-FR）コーデックで得られる品質にほかなりません。テストで使用される実際のパケットロス「パターン」は、損失モデルからではなく、インターネット上で収集された実際のパケットロストレースから取得する必要があります。これらのトレースは、セクション3のアプリケーションが動作する典型的な環境を表す必要があります。たとえば、VoIPコールに関連するトレースは、典型的なホームブロードバンドと企業の接続で観察される損失パターンを考慮する必要があります。
The resulting codec should be implementable on a wide range of devices, so there should be a fixed-point implementation or at least assurance that a reasonable fixed-point is possible. The computational resources figures listed below are meant to be upper bounds. Even below these bounds, resources should still be minimized. Any proposed increase in computational resources consumption (e.g., to increase quality) should be carefully evaluated
結果のコーデックは、幅広いデバイスで実装可能である必要があるため、固定点の実装または少なくとも合理的な固定点が可能であることを保証する必要があります。以下にリストされている計算リソースの数値は、上限であることを意図しています。これらの境界以下であっても、リソースを最小限に抑える必要があります。計算リソースの消費の提案（品質を向上させるなど）を慎重に評価する必要があります
even if the resulting resource consumption is below the upper bound. Having variable complexity would be useful (but not required) in achieving that goal as it would allow trading quality/bit-rate for lower complexity.
結果のリソース消費が上限を下回っている場合でも。複雑な目標を達成するのに、さまざまな複雑さを持つことは有用です（ただし、必要ありません）。
The computational requirements for real-time encoding and decoding of a mono signal on one core of a recent x86 CPU (as measured with the Unix "time" utility or equivalent) are as follows:
最近のX86 CPUの1つのコア（UNIXの「時間」のユーティリティまたは同等物で測定）のモノ信号のリアルタイムエンコードとデコードの計算要件は次のとおりです。
o Narrowband: 40 megahertz (MHz) (2% of a 2 gigahertz (GHz) CPU core)
o ナローバンド：40メガヘルツ（MHz）（2ギガヘルツ（GHz）CPUコアの2％）
o Wideband: 80 MHz (4% of a 2 GHz CPU core)
o ワイドバンド：80 MHz（2 GHz CPUコアの4％）
o Super-wideband/fullband: 200 MHz (10% of a 2 GHz CPU core)
o スーパーワイドバンド/フルバンド：200 MHz（2 GHz CPUコアの10％）
It is desirable that the MHz values listed above also be achievable on fixed-point digital signal processors that are capable of single-cycle multiply-accumulate operations (16x16 multiplication accumulated into 32 bits).
上記のMHZ値は、単一サイクルの増殖型操作（32ビットに蓄積された16x16乗算）が可能な固定点デジタル信号プロセッサでも達成可能であることが望ましいです。
For applications that require mixing (e.g., conferencing), it should be possible to estimate the energy and/or the voice activity status of the decoded signal with less than 10% of the complexity figures listed above.
混合（会議など）を必要とするアプリケーションの場合、上記の複雑さの数値の10％未満で、デコードされた信号のエネルギーおよび/または音声活動ステータスを推定できるはずです。
It is the intent to maximize the range of devices on which a codec can be implemented. Therefore, the reference implementation must not depend on special hardware features or instructions to be present in order to meet the complexity requirement. However, it may be desirable to take advantage of such hardware when available, (e.g., hardware accelerators for operations like Fast Fourier Transforms (FFT) and convolutions). A codec should also minimize the use of saturating arithmetic so as to be implementable on architectures that do not provide hardware saturation (e.g., ARMv4).
コーデックを実装できるデバイスの範囲を最大化する意図です。したがって、参照実装は、複雑さの要件を満たすために存在する特別なハードウェア機能や指示に依存してはなりません。ただし、利用可能な場合は、このようなハードウェアを利用することが望ましい場合があります（たとえば、高速フーリエ変換（FFT）や畳み込みなどの操作のためのハードウェアアクセラレータ）。コーデックは、ハードウェアの飽和を提供しないアーキテクチャで実装できるように、飽和算術の使用を最小限に抑える必要があります（例：ARMV4）。
The combined codec size and data read-only memory (ROM) should be small enough not to cause significant implementation problems on typical embedded devices. The codec context/state size required should be no more than 2*R*C bytes in floating-point, where R is the sampling rate and C is the number of channels. For fixed-point, that size should be less than R*C. The scratch space required should also be less than 2*R*C bytes for floating point or less than R*C bytes for fixed-point.
コーデックのサイズとデータの読み取り専用メモリ（ROM）の組み合わせは、典型的な組み込みデバイスに重大な実装の問題を引き起こさないほど小さい必要があります。必要なコーデックのコンテキスト/状態サイズは、浮動小数点で2*r*cを超えるバイトでなければなりません。ここで、rはサンプリングレート、Cはチャネルの数です。固定点の場合、そのサイズはr*c未満でなければなりません。必要なスクラッチスペースも、浮動小数点の場合は2*r*cバイト未満であるか、固定点のr*cバイト未満でなければなりません。
There are additional features or characteristics that may be desirable under some circumstances, but should not be part of the strict requirements. The benefit of meeting these considerations should be weighted against the associated cost.
状況によっては望ましい可能性のある追加機能または特性がありますが、厳格な要件の一部であるべきではありません。これらの考慮事項を満たすことの利点は、関連するコストに対して重み付けされるべきです。
In many applications that require a mixing server (e.g., conferencing, games), it is important to minimize the computational cost of the mixing. As much as possible, it should be possible to perform the mixing with fewer computations than it would take to decode all the streams, mix them, and re-encode the result. Properties that reduce the complexity of the mixing process include:
ミキシングサーバー（会議、ゲームなど）を必要とする多くのアプリケーションでは、ミキシングの計算コストを最小限に抑えることが重要です。可能な限り、すべてのストリームをデコードし、それらを混合し、結果を再エンコードするのにかかるよりも少ない計算で混合を実行することが可能であるはずです。混合プロセスの複雑さを減らす特性は次のとおりです。
o The ability to derive sufficient parameters, such as loudness and/or spectral envelope, for estimating voice activity of a compressed frame without fully decoding that frame;
o そのフレームを完全にデコードせずに圧縮フレームの音声アクティビティを推定するために、ラウドネスやスペクトルエンベロープなどの十分なパラメーターを導き出す機能。
o The ability to mix the streams in an intermediate representation (e.g., transform domain), rather than having to fully decode the signals before the mixing;
o ミキシングの前に信号を完全にデコードする必要があるのではなく、中間表現（たとえば、変換ドメイン）でストリームを混合する機能。
o The use of bit-stream layers (Section 6.3) by aggregating a small number of active streams at lower quality.
o 少数のアクティブストリームを低品質で集約することにより、ビットストリーム層（セクション6.3）の使用。
For conferencing applications, the total complexity of the decoding, voice activity detection (VAD), and mixing should be considered when evaluating proposals.
アプリケーションを会議するには、提案を評価する際に、デコード、音声アクティビティ検出（VAD）、および混合の完全な複雑さを考慮する必要があります。
In many codecs, it is possible to improve the quality by improving the encoder without breaking compatibility (i.e., without changing the decoder). Potential for improvement varies from one codec to another. It is generally low for pulse code modulation (PCM) or adaptive differential pulse code modulation (ADPCM) codecs and higher for perceptual transform codecs. All things being equal, being able to improve a codec after the bit-stream is a desirable property. However, this should not be done at the expense of quality in the reference encoder. Other potential improvements include signal-adaptive frame size selection and improved discontinuous transmission (DTX) algorithms that take advantage of predicting the decoder sides packet loss concealment (PLC) algorithms.
多くのコーデックでは、互換性を破ることなく（つまり、デコーダーを変更せずに）エンコーダーを改善することにより、品質を改善することができます。改善の可能性は、コーデックによって異なります。一般に、パルスコード変調（PCM）または適応型差動パルスコード変調（ADPCM）コーデックの場合は低く、知覚変換コーデックでは高くなります。すべてのものが平等であり、ビットストリームの後にコーデックを改善できることが望ましいプロパティです。ただし、これは、参照エンコーダーの品質を犠牲にして行うべきではありません。その他の潜在的な改善には、信号に適合したフレームサイズの選択と、デコーダー側のパケット損失隠蔽（PLC）アルゴリズムの予測を活用する不連続伝送（DTX）アルゴリズムの改善が含まれます。
A layered codec makes it possible to transmit only a certain subset of the bits and still obtain a valid bit-stream with a quality that is equivalent to the quality that would be obtained from encoding at the corresponding rate. While this is not a necessary feature for most applications, it can be desirable for cases where a "mixing server" needs to handle a large number of streams with limited computational resources.
階層化されたコーデックにより、ビットの特定のサブセットのみを送信し、対応する速度でエンコードから得られる品質に相当する品質を持つ有効なビットストリームを取得できます。これはほとんどのアプリケーションに必要な機能ではありませんが、「ミキシングサーバー」が限られた計算リソースを備えた多数のストリームを処理する必要がある場合に望ましい場合があります。
One possible way of increasing robustness to packet loss is to include partial redundancy within packets. This can be achieved either by including the base layer of the previous frame (for a layered codec) or by transmitting other parameters from the previous frame(s) to assist the PLC algorithm in case of loss. The ability to include partial redundancy for high-loss scenarios is desirable, provided that the feature can be dynamically turned on or off (so that no bandwidth is wasted in case of loss-free transmission).
パケット損失に対する堅牢性を高める可能性のある方法の1つは、パケットに部分的な冗長性を含めることです。これは、前のフレームの基本層（層状コーデック用）を含めるか、前のフレームから他のパラメーターを送信して、損失の場合にPLCアルゴリズムを支援することによって達成できます。機能を動的にオンまたはオフにできる限り、低損失シナリオに部分的な冗長性を含める機能が望ましい（損失のない送信の場合、帯域幅が無駄にされないように）。
It is highly desirable for the codec to have stereo support. At a minimum, the codec should be able to encode two channels independently without causing significant stereo image artifacts. It is also desirable for the codec to take advantage of the inter-channel redundancy in stereo audio to reduce the bit-rate (for an equivalent quality) of stereo audio compared to coding channels independently.
コーデックがステレオサポートをすることは非常に望ましいです。少なくとも、コーデックは、重要なステレオ画像アーティファクトを引き起こすことなく、2つのチャネルを個別にエンコードできるはずです。また、コーデックがステレオオーディオのチャネル間冗長性を活用して、独立してコーディングチャネルと比較してステレオオーディオのビットレート（同等品質）を減らすことも望ましいです。
The vast majority of Internet-based applications do not need to be robust to bit errors because packets either arrive unaltered or do not arrive at all. Therefore, the emphasis should be on packet-loss robustness and packet-loss concealment. That being said, often, the extra robustness to bit errors can be achieved at no cost at all (i.e., no increase in size, complexity, or bit-rate; no decrease in quality, or packet-loss robustness, etc.). In those cases, it is useful to make a change that increases the robustness to bit errors. This can be useful for applications that use UDP Lite transmission (e.g., over a wireless LAN). Robustness to packet loss should *never* be sacrificed to achieve higher bit error robustness.
インターネットベースのアプリケーションの大部分は、パケットが変更されていないか、まったく到着しないため、ビットエラーに対して堅牢である必要はありません。したがって、パケットロスの堅牢性とパケット損失の隠蔽に重点が置かれるべきです。そうは言っても、多くの場合、ビットエラーに対する余分な堅牢性は、まったく無料で達成できます（つまり、サイズ、複雑さ、またはビットレートの増加はありません。品質の低下、またはパケットロスの堅牢性など）。そのような場合、ビットエラーに対する堅牢性を高める変更を加えると便利です。これは、UDP Liteトランスミッション（ワイヤレスLANなど）を使用するアプリケーションに役立ちます。パケット損失への堅牢性は、より高いビットエラーの堅牢性を達成するために犠牲にされるべきではありません。
When adaptive jitter buffers are used, it is often necessary to stretch or shorten the audio signal to allow changes in buffering. While this operation can be performed directly on the decoder's output, it is often more computationally efficient to stretch or shorten the signal directly within the decoder. It is desirable for the reference implementation to provide a time stretching/shortening implementation, although it should not be normative.
適応性のあるジッターバッファーを使用する場合、バッファリングの変更を可能にするために、オーディオ信号を伸ばしたり短くしたりする必要があることがよくあります。この操作はデコーダーの出力で直接実行できますが、多くの場合、デコーダー内で信号を直接伸ばすか短くする方が計算効率が良くなります。参照実装が時間の伸長/短縮の実装を提供することが望ましいですが、それは規範的であってはなりません。
The systems providing input to the encoder and receiving output from the decoder may be far from ideal in actual use. Input and output audio streams may be corrupted by compounding non-linear artifacts from analog hardware and digital processing. The codecs to be developed should be tested to ensure that they degrade gracefully under adverse audio input conditions. Types of digital corruption that may be tested include tandeming, transcoding, low-quality resampling, and digital clipping. Types of analog corruption that may be tested include microphones with substantial background noise, analog clipping, and loudspeaker distortion. No specific end-to-end quality requirements are mandated for use with the proposed codec. It is advisable, however, that several typical in situ environments/ processing chains be specified for the purpose of benchmarking end-to-end quality with the proposed codec.
エンコーダーへの入力を提供し、デコーダーからの出力を受信するシステムは、実際の使用において理想とはほど遠い場合があります。入力および出力オーディオストリームは、アナログハードウェアとデジタル処理から非線形アーティファクトを調合することにより破損する場合があります。開発されるコーデックは、有害なオーディオ入力条件下で優雅に劣化することを確認するためにテストする必要があります。テストされる可能性のあるデジタル破損の種類には、タンデミング、トランスコーディング、低品質の再サンプリング、デジタルクリッピングが含まれます。テストされる可能性のあるアナログの破損の種類には、かなりのバックグラウンドノイズ、アナログクリッピング、スピーカーの歪みがあるマイクが含まれます。提案されたコーデックで使用するための特定のエンドツーエンドの品質要件は義務付けられていません。ただし、提案されたコーデックでエンドツーエンドの品質をベンチマークする目的で、いくつかの典型的なin situ環境/処理チェーンを指定することをお勧めします。
Emergency calls can be analyzed using audio forensics if the context and situation of the caller has to be identified. Thus, it is important to transmit not only the voice of the callers well, but also to transmit background noise at high quality. In these situations, sounds or noises of low volume should also not be compressed or dropped. Therefore, the encoder must allow DTX to be disabled when required (e.g., for emergency calls).
発信者のコンテキストと状況を特定する必要がある場合、オーディオフォレンジックを使用して緊急通話を分析できます。したがって、発信者の声だけでなく、バックグラウンドノイズを高品質で送信することも重要です。これらの状況では、低ボリュームの音や音も圧縮およびドロップしないでください。したがって、エンコーダは、必要に応じてDTXを無効にする必要があります（緊急通話など）。
In order to create the best possible codec for the Internet, there is no requirement for compatibility with legacy Internet codecs.
インターネットに最適なコーデックを作成するために、レガシーインターネットコーデックとの互換性の要件はありません。
Although this document itself does not have security considerations, this section describes the security requirements for the codec.
このドキュメント自体にはセキュリティ上の考慮事項はありませんが、このセクションではコーデックのセキュリティ要件について説明します。
As for any protocol to be used over the Internet, security is a very important aspect to consider. This goes beyond the obvious considerations of preventing buffer overflows and similar attacks that can lead to denial-of-service (DoS) or remote code execution. One very important security aspect is to make sure that the decoders have a bounded and reasonable worst-case complexity. This prevents an attacker from causing a DoS by sending packets that are specially crafted to take a very long (or infinite) time to decode.
インターネットで使用されるプロトコルについては、セキュリティは考慮すべき非常に重要な側面です。これは、緩衝液のオーバーフローと同様の攻撃を防止するという明らかな考慮事項を超えて、サービス拒否（DOS）またはリモートコードの実行につながる可能性があります。非常に重要なセキュリティの側面の1つは、デコーダーが境界で合理的な最悪の複雑さを持っていることを確認することです。これにより、攻撃者が非常に長い（または無限の）時間をかけるために特別に作成されたパケットを送信することにより、攻撃者がDOSを引き起こすのを防ぎます。
A more subtle aspect is the information leak that can occur when the codec is used over an encrypted channel (e.g., [SRTP]). For example, it was suggested [wright08] [white11] that use of source-controlled VBR may reveal some information about a conversation through the size of the compressed packets. Therefore, it should be possible to use the codec at a truly constant bit-rate, if needed.
より微妙な側面は、暗号化されたチャネル（[SRTP]など）でコーデックが使用されるときに発生する可能性のある情報リークです。たとえば、[Wright08] [White11]ソース制御VBRの使用は、圧縮パケットのサイズを通じて会話に関する情報を明らかにする可能性があることが示唆されました。したがって、必要に応じて、コーデックを本当に一定のビットレートで使用することが可能です。
We would like to thank all the people who contributed directly or indirectly to this document, including Slava Borilin, Christopher Montgomery, Raymond (Juin-Hwey) Chen, Jason Fischl, Gregory Maxwell, Alan Duric, Jonathan Christensen, Julian Spittka, Michael Knappe, Christian Hoene, and Henry Sinnreich. We would also like to thank Cullen Jennings, Jonathan Rosenberg, and Gregory Lebovitz for their advice.
Slava Borilin、Christopher Montgomery、Raymond（Juin-Hwey）Chen、Jason Fischl、Gregory Maxwell、Alan Duric、Jonathan Christensen、Julian Spittka、Michael Knappe、Michael Knappe、Michael Knappeなど、この文書に直接または間接的に貢献したすべての人々に感謝します。クリスチャン・ホーン、ヘンリー・シン・ライヒ。また、Cullen Jennings、Jonathan Rosenberg、Gregory Lebovitzのアドバイスにも感謝します。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[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月。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6120] Saint-Andre、P。、「拡張可能なメッセージと存在プロトコル（XMPP）：Core」、RFC 6120、2011年3月。
[XEP-0167] Ludwig, S., Saint-Andre, P., Egan, S., McQueen, R., and D. Cionoiu, "Jingle RTP Sessions", XSF XEP 0167, December 2009.
[Xep-0167] Ludwig、S.、Saint-Andre、P.、Egan、S.、McQueen、R。、およびD. Cionoiu、「Jingle RTP Sessions」、XSF XEP 0167、2009年12月。
[RFC3951] Andersen, S., Duric, A., Astrom, H., Hagen, R., Kleijn, W., and J. Linden, "Internet Low Bit Rate Codec (iLBC)", RFC 3951, December 2004.
[RFC3951] Andersen、S.、Duric、A.、Astom、H.、Hagen、R.、Kleijn、W。、およびJ. Linden、「Internet Low Bit Rate Codec（ILBC）」、RFC 3951、2004年12月。
[ITU.G722.1] International Telecommunications Union, "Low-complexity coding at 24 and 32 kbit/s for hands-free operation in systems with low frame loss", ITU-T Recommendation G.722.1, May 2005.
[ITU.G722.1] International Telecommunications Union、「低いフレーム損失を伴うシステムでのハンズフリー操作のための24および32 KBIT/sでの低複雑度コーディング」、ITU-T推奨G.722.1、2005年5月。
[Speex] Xiph.Org Foundation, "Speex: http://www.speex.org/", 2003.
[Speex] Xiph.org Foundation、 "Speex：http：//www.spex.org/"、2003。
[carot09] Carot, A., Werner, C., and T. Fischinger, "Towards a Comprehensive Cognitive Analysis of Delay-Influenced Rhythmical Interaction: http://www.carot.de/icmc2009.pdf", 2009.
[Carot09] Carot、A.、Werner、C。、およびT. Fischinger、「遅延の影響を受けたリズミカルな相互作用の包括的な認知分析に向けて：http：//www.carot.de/icmc2009.pdf "、2009。
[PAYLOADS] Handley, M. and C. Perkins, "Guidelines for Writers of RTP Payload Format Specifications", BCP 36, RFC 2736, December 1999.
[ペイロード] Handley、M。およびC. Perkins、「RTPペイロード形式の仕様の作家のためのガイドライン」、BCP 36、RFC 2736、1999年12月。
[RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RTP] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[SRTP] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「The Secure Real-Time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[wright08] Wright, C., Ballard, L., Coull, S., Monrose, F., and G. Masson, "Spot me if you can: Uncovering spoken phrases in encrypted VoIP conversations: http://www.cs.jhu.edu/~cwright/oakland08.pdf", 2008.
[Wright08] Wright、C.、Ballard、L.、Coull、S.、Monrose、F。、およびG. Masson、「可能であれば：暗号化されたVoIP会話で話し言葉のフレーズを明らかにする：http：//www.cs.jhu.edu/〜cwright/oakland08.pdf "、2008。
[white11] White, A., Matthews, A., Snow, K., and F. Monrose, "Phonotactic Reconstruction of Encrypted VoIP Conversations: Hookt on fon-iks http://www.cs.unc.edu/~fabian/papers/foniks-oak11.pdf", 2011.
[White11] White、A.、Matthews、A.、Snow、K。、およびF. Monrose、「暗号化されたVoIP会話の音韻的再構築：Fon-Iks http://www.cs.unc.edu/~fabian/papers/foniks-oak11.pdf "、2011。
Authors' Addresses
著者のアドレス
Jean-Marc Valin Mozilla 650 Castro Street Mountain View, CA 94041 USA
Jean-Marc Valin Mozilla 650 Castro Street Mountain View、CA 94041 USA
EMail: jmvalin@jmvalin.ca
Koen Vos Skype Technologies, S.A. Stadsgarden 6 Stockholm, 11645 Sweden
Koen Vos Skype Technologies、S.A。Stadsgarden6 Stockholm、11645 Sweden
EMail: koen.vos@skype.net