[要約] RFC 7587は、Opus音声およびオーディオコーデックのためのRTPペイロード形式に関する仕様です。このRFCの目的は、Opusコーデックを使用して音声およびオーディオデータをRTPパケットにエンコードする方法を定義することです。
Internet Engineering Task Force (IETF) J. Spittka
Request for Comments: 7587
Category: Standards Track K. Vos
ISSN: 2070-1721 vocTone
JM. Valin
Mozilla
June 2015
RTP Payload Format for the Opus Speech and Audio Codec
Opus音声およびオーディオコーデックのRTPペイロード形式
Abstract
概要
This document defines the Real-time Transport Protocol (RTP) payload format for packetization of Opus-encoded speech and audio data necessary to integrate the codec in the most compatible way. It also provides an applicability statement for the use of Opus over RTP. Further, it describes media type registrations for the RTP payload format.
このドキュメントでは、コーデックを最も互換性のある方法で統合するために必要な、オーパスエンコードされた音声およびオーディオデータのパケット化のためのリアルタイムトランスポートプロトコル（RTP）ペイロード形式を定義します。また、RTPを介したOpusの使用に関する適用可能性に関する声明も提供します。さらに、RTPペイロード形式のメディアタイプ登録についても説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc7587.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7587で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions, Definitions, and Acronyms Used in This Document 3
3. Opus Codec . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Network Bandwidth . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Recommended Bitrate . . . . . . . . . . . . . . . . . 4
3.1.2. Variable versus Constant Bitrate . . . . . . . . . . 4
3.1.3. Discontinuous Transmission (DTX) . . . . . . . . . . 5
3.2. Complexity . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Forward Error Correction (FEC) . . . . . . . . . . . . . 6
3.4. Stereo Operation . . . . . . . . . . . . . . . . . . . . 6
4. Opus RTP Payload Format . . . . . . . . . . . . . . . . . . . 7
4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . 7
4.2. Payload Structure . . . . . . . . . . . . . . . . . . . . 7
5. Congestion Control . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. Opus Media Type Registration . . . . . . . . . . . . . . 9
7. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 12
7.1. SDP Offer/Answer Considerations . . . . . . . . . . . . . 13
7.2. Declarative SDP Considerations for Opus . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Opus [RFC6716] is a speech and audio codec developed within the IETF Internet Wideband Audio Codec working group. The codec has a very low algorithmic delay, and it is highly scalable in terms of audio bandwidth, bitrate, and complexity. Further, it provides different modes to efficiently encode speech signals as well as music signals, thus making it the codec of choice for various applications using the Internet or similar networks.
Opus [RFC6716]は、IETFインターネットワイドバンドオーディオコーデックワーキンググループ内で開発された音声およびオーディオコーデックです。コーデックのアルゴリズム遅延は非常に低く、オーディオ帯域幅、ビットレート、複雑さの点で非常にスケーラブルです。さらに、音声信号や音楽信号を効率的にエンコードするためのさまざまなモードを提供し、インターネットや類似のネットワークを使用するさまざまなアプリケーションに最適なコーデックにします。
This document defines the Real-time Transport Protocol (RTP) [RFC3550] payload format for packetization of Opus-encoded speech and audio data necessary to integrate Opus in the most compatible way. It also provides an applicability statement for the use of Opus over RTP. Further, it describes media type registrations for the RTP payload format.
このドキュメントでは、Opusを最も互換性のある方法で統合するために必要な、Opusでエンコードされた音声およびオーディオデータのパケット化のためのリアルタイムトランスポートプロトコル（RTP）[RFC3550]ペイロード形式を定義します。また、RTPを介したOpusの使用に関する適用可能性に関する声明も提供します。さらに、RTPペイロード形式のメディアタイプ登録についても説明します。
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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
audio bandwidth: The range of audio frequencies being coded
オーディオ帯域幅：コーディングされるオーディオ周波数の範囲
CBR: Constant bitrate
CBR：固定ビットレート
CPU: Central Processing Unit
CPU：中央処理装置
DTX: Discontinuous Transmission
DTX：不連続送信
FEC: Forward Error Correction
FEC：前方誤り訂正
IP: Internet Protocol
IP：インターネットプロトコル
samples: Speech or audio samples (per channel)
サンプル：音声またはオーディオのサンプル（チャネルごと）
SDP: Session Description Protocol
SDP：セッション記述プロトコル
SSRC: Synchronization source
SSRC：同期ソース
VBR: Variable bitrate
VBR：可変ビットレート
Throughout this document, we refer to the following definitions:
このドキュメント全体を通して、次の定義を参照しています。
+--------------+----------------+-----------------+-----------------+
| Abbreviation | Name | Audio Bandwidth | Sampling Rate |
| | | (Hz) | (Hz) |
+--------------+----------------+-----------------+-----------------+
| NB | Narrowband | 0 - 4000 | 8000 |
| | | | |
| MB | Mediumband | 0 - 6000 | 12000 |
| | | | |
| WB | Wideband | 0 - 8000 | 16000 |
| | | | |
| SWB | Super-wideband | 0 - 12000 | 24000 |
| | | | |
| FB | Fullband | 0 - 20000 | 48000 |
+--------------+----------------+-----------------+-----------------+
Table 1: Audio Bandwidth Naming
表1：オーディオ帯域幅の命名
Opus encodes speech signals as well as general audio signals. Two different modes can be chosen, a voice mode or an audio mode, to allow the most efficient coding depending on the type of the input signal, the sampling frequency of the input signal, and the intended application.
Opusは、音声信号と一般的なオーディオ信号をエンコードします。音声モードと音声モードの2つの異なるモードを選択して、入力信号のタイプ、入力信号のサンプリング周波数、および目的のアプリケーションに応じて、最も効率的なコーディングを行うことができます。
The voice mode allows efficient encoding of voice signals at lower bitrates while the audio mode is optimized for general audio signals at medium and higher bitrates.
音声モードでは、低ビットレートの音声信号を効率的にエンコードできます。一方、音声モードは、中程度以上のビットレートの一般的な音声信号用に最適化されています。
Opus is highly scalable in terms of audio bandwidth, bitrate, and complexity. Further, Opus allows transmitting stereo signals with in-band signaling in the bitstream.
Opusは、オーディオ帯域幅、ビットレート、複雑さの点で非常にスケーラブルです。さらに、Opusでは、ビットストリームでインバンドシグナリングを使用してステレオ信号を送信できます。
Opus supports bitrates from 6 kbit/s to 510 kbit/s. The bitrate can be changed dynamically within that range. All other parameters being equal, higher bitrates result in higher audio quality.
Opusは6 kbit / sから510 kbit / sまでのビットレートをサポートしています。ビットレートはその範囲内で動的に変更できます。他のすべてのパラメータが等しい場合、ビットレートが高いほど、オーディオ品質が高くなります。
For a frame size of 20 ms, these are the bitrate "sweet spots" for Opus in various configurations:
フレームサイズが20ミリ秒の場合、これらはさまざまな構成でのOpusのビットレート「スイートスポット」です。
o 8-12 kbit/s for NB speech,
o NBスピーチの場合は8〜12 kbit / s、
o 16-20 kbit/s for WB speech,
o WBスピーチでは16〜20 kbit / s、
o 28-40 kbit/s for FB speech,
o FBスピーチの場合28-40 kbit / s、
o 48-64 kbit/s for FB mono music, and
o FBモノラル音楽では48〜64 kbit / s、および
o 64-128 kbit/s for FB stereo music.
o FBステレオミュージックでは64〜128 kbit / s。
For the same average bitrate, variable bitrate (VBR) can achieve higher audio quality than constant bitrate (CBR). For the majority of voice transmission applications, VBR is the best choice. One reason for choosing CBR is the potential information leak that _might_ occur when encrypting the compressed stream. See [RFC6562] for guidelines on when VBR is appropriate for encrypted audio communications. In the case where an existing VBR stream needs to be converted to CBR for security reasons, the Opus padding mechanism described in [RFC6716] is the RECOMMENDED way to achieve padding because the RTP padding bit is unencrypted.
同じ平均ビットレートの場合、可変ビットレート（VBR）は固定ビットレート（CBR）よりも高い音質を実現できます。ほとんどの音声伝送アプリケーションでは、VBRが最適です。 CBRを選択する理由の1つは、圧縮ストリームを暗号化するときに発生する可能性がある潜在的な情報漏洩です。暗号化された音声通信にVBRが適している場合のガイドラインについては、[RFC6562]を参照してください。セキュリティ上の理由で既存のVBRストリームをCBRに変換する必要がある場合、[RFC6716]で説明されているOpusパディングメカニズムは、RTPパディングビットが暗号化されていないため、パディングを実現するための推奨方法です。
The bitrate can be adjusted at any point in time. To avoid congestion, the average bitrate SHOULD NOT exceed the available network bandwidth. If no target bitrate is specified, the bitrates specified in Section 3.1.1 are RECOMMENDED.
ビットレートはいつでも調整できます。混雑を避けるために、平均ビットレートは利用可能なネットワーク帯域幅を超えてはいけません。ターゲットビットレートが指定されていない場合、セクション3.1.1で指定されたビットレートが推奨されます。
Opus can, as described in Section 3.1.2, be operated with a variable bitrate. In that case, the encoder will automatically reduce the bitrate for certain input signals, like periods of silence. When using continuous transmission, it will reduce the bitrate when the characteristics of the input signal permit, but it will never interrupt the transmission to the receiver. Therefore, the received signal will maintain the same high level of audio quality over the full duration of a transmission while minimizing the average bitrate over time.
Opusは、セクション3.1.2で説明されているように、可変ビットレートで操作できます。その場合、エンコーダーは無音の期間など、特定の入力信号のビットレートを自動的に減らします。連続送信を使用すると、入力信号の特性が許す場合はビットレートが低下しますが、受信機への送信が中断されることはありません。したがって、受信信号は、平均ビットレートを最小限に抑えながら、送信の全期間にわたって同じ高レベルのオーディオ品質を維持します。
In cases where the bitrate of Opus needs to be reduced even further or in cases where only constant bitrate is available, the Opus encoder can use Discontinuous Transmission (DTX), where parts of the encoded signal that correspond to periods of silence in the input speech or audio signal are not transmitted to the receiver. A receiver can distinguish between DTX and packet loss by looking for gaps in the sequence number, as described by Section 4.1 of [RFC3551].
Opusのビットレートをさらに下げる必要がある場合、または一定のビットレートのみが利用可能な場合、Opusエンコーダーは不連続伝送（DTX）を使用できます。DTXは、入力音声の無音の期間に対応するエンコードされた信号の部分です。またはオーディオ信号が受信機に送信されません。 [RFC3551]のセクション4.1で説明されているように、受信者はシーケンス番号のギャップを探すことにより、DTXとパケット損失を区別できます。
On the receiving side, the non-transmitted parts will be handled by a frame loss concealment unit in the Opus decoder, which generates a comfort noise signal to replace the non-transmitted parts of the speech or audio signal. Using Comfort Noise as defined in [RFC3389] with Opus is discouraged. The transmitter MUST drop whole frames only, based on the size of the last transmitted frame, to ensure successive RTP timestamps differ by a multiple of 120 and to allow the receiver to use whole frames for concealment.
受信側では、送信されなかった部分はOpusデコーダーのフレーム損失隠蔽ユニットによって処理され、音声またはオーディオ信号の送信されなかった部分を置き換えるコンフォートノイズ信号を生成します。 [RFC3389]で定義されているコンフォートノイズをOpusで使用することはお勧めしません。連続したRTPタイムスタンプが120の倍数だけ異なることを保証し、レシーバーがフレーム全体を隠蔽に使用できるようにするには、トランスミッターが最後に送信されたフレームのサイズに基づいて、フレーム全体のみをドロップする必要があります。
DTX can be used with both variable and constant bitrate. It will have a slightly lower speech or audio quality than continuous transmission. Therefore, using continuous transmission is RECOMMENDED unless constraints on available network bandwidth are severe.
DTXは、可変ビットレートと固定ビットレートの両方で使用できます。連続送信よりも音声または音声の品質がわずかに低くなります。したがって、利用可能なネットワーク帯域幅の制約が厳しくない限り、連続送信の使用をお勧めします。
Complexity of the encoder can be scaled to optimize for CPU resources in real time, mostly as a trade-off between audio quality and bitrate. Also, different modes of Opus have different complexity.
エンコーダの複雑さをスケーリングして、CPUリソースをリアルタイムで最適化できます。これは、主にオーディオ品質とビットレートのトレードオフとして行われます。また、Opusのモードが異なれば、複雑さも異なります。
The voice mode of Opus allows for embedding in-band Forward Error Correction (FEC) data into the Opus bitstream. This FEC scheme adds redundant information about the previous packet (N-1) to the current output packet N. For each frame, the encoder decides whether to use FEC based on (1) an externally provided estimate of the channel's packet loss rate; (2) an externally provided estimate of the channel's capacity; (3) the sensitivity of the audio or speech signal to packet loss; and (4) whether the receiving decoder has indicated it can take advantage of in-band FEC information. The decision to send in-band FEC information is entirely controlled by the encoder; therefore, no special precautions for the payload have to be taken.
Opusの音声モードでは、帯域内転送エラー訂正（FEC）データをOpusビットストリームに埋め込むことができます。このFECスキームは、前のパケット（N-1）に関する冗長情報を現在の出力パケットNに追加します。エンコーダーは、フレームごとに、（1）外部から提供されたチャネルのパケット損失率の推定に基づいてFECを使用するかどうかを決定します。 （2）外部から提供されたチャネル容量の見積もり。 （3）パケット損失に対する音声または音声信号の感度。 （４）受信デコーダが帯域内ＦＥＣ情報を利用できることを示しているかどうか。インバンドFEC情報を送信するかどうかの決定は、エンコーダーによって完全に制御されます。したがって、ペイロードに対して特別な注意を払う必要はありません。
On the receiving side, the decoder can take advantage of this additional information when it loses a packet and the next packet is available. In order to use the FEC data, the jitter buffer needs to provide access to payloads with the FEC data. Instead of performing loss concealment for a missing packet, the receiver can then configure its decoder to decode the FEC data from the next packet.
受信側では、デコーダーはパケットを失い、次のパケットが利用可能になったときに、この追加情報を利用できます。 FECデータを使用するには、ジッタバッファがFECデータを含むペイロードへのアクセスを提供する必要があります。欠落したパケットの損失隠蔽を実行する代わりに、受信機は次のパケットからFECデータをデコードするようにデコーダーを構成できます。
Any compliant Opus decoder is capable of ignoring FEC information when it is not needed, so encoding with FEC cannot cause interoperability problems. However, if FEC cannot be used on the receiving side, then FEC SHOULD NOT be used, as it leads to an inefficient usage of network resources. Decoder support for FEC SHOULD be indicated at the time a session is set up.
準拠するOpusデコーダーは、不要なFEC情報を無視できるため、FECを使用したエンコードで相互運用性の問題が発生することはありません。ただし、受信側でFECを使用できない場合は、FECを使用しないでください。これは、ネットワークリソースの非効率的な使用につながるためです。 FECのデコーダーサポートは、セッションのセットアップ時に示す必要があります（SHOULD）。
Opus allows for transmission of stereo audio signals. This operation is signaled in-band in the Opus bitstream and no special arrangement is needed in the payload format. An Opus decoder is capable of handling a stereo encoding, but an application might only be capable of consuming a single audio channel.
Opusでは、ステレオオーディオ信号の伝送が可能です。この操作は、Opusビットストリームでインバンドで通知され、ペイロード形式で特別な配置は必要ありません。 Opusデコーダーはステレオエンコーディングを処理できますが、アプリケーションは単一のオーディオチャネルしか使用できない場合があります。
If a decoder cannot take advantage of the benefits of a stereo signal, this SHOULD be indicated at the time a session is set up. In that case, the sending side SHOULD NOT send stereo signals as it leads to an inefficient usage of network resources.
デコーダーがステレオ信号の利点を利用できない場合、これはセッションのセットアップ時に示される必要があります。その場合、送信側はステレオ信号を送信すべきではありません。ネットワーク信号の非効率的な使用につながるからです。
The payload format for Opus consists of the RTP header and Opus payload data.
Opusのペイロード形式は、RTPヘッダーとOpusペイロードデータで構成されます。
The format of the RTP header is specified in [RFC3550]. The use of the fields of the RTP header by the Opus payload format is consistent with that specification.
RTPヘッダーのフォーマットは[RFC3550]で指定されています。 Opusペイロード形式によるRTPヘッダーのフィールドの使用は、その仕様と一致しています。
The payload length of Opus is an integer number of octets; therefore, no padding is necessary. The payload MAY be padded by an integer number of octets according to [RFC3550], although the Opus internal padding is preferred.
Opusのペイロード長はオクテットの整数です。したがって、パディングは必要ありません。ペイロードは、[RFC3550]に従って整数のオクテットでパディングされる場合がありますが、Opus内部パディングが推奨されます。
The timestamp, sequence number, and marker bit (M) of the RTP header are used in accordance with Section 4.1 of [RFC3551].
[RFC3551]のセクション4.1に従って、RTPヘッダーのタイムスタンプ、シーケンス番号、マーカービット（M）が使用されます。
The RTP payload type for Opus is to be assigned dynamically.
OpusのRTPペイロードタイプは動的に割り当てられます。
The receiving side MUST be prepared to receive duplicate RTP packets. The receiver MUST provide at most one of those payloads to the Opus decoder for decoding, and it MUST discard the others.
受信側は、重複するRTPパケットを受信できるように準備する必要があります。レシーバーは、これらのペイロードの多くても1つをOpusデコーダーにデコードのために提供する必要があり、その他は破棄する必要があります。
Opus supports 5 different audio bandwidths, which can be adjusted during a stream. The RTP timestamp is incremented with a 48000 Hz clock rate for all modes of Opus and all sampling rates. The unit for the timestamp is samples per single (mono) channel. The RTP timestamp corresponds to the sample time of the first encoded sample in the encoded frame. For data encoded with sampling rates other than 48000 Hz, the sampling rate has to be adjusted to 48000 Hz.
Opusは5つの異なるオーディオ帯域幅をサポートしており、ストリーム中に調整できます。 RTPタイムスタンプは、Opusのすべてのモードとすべてのサンプリングレートで48000 Hzのクロックレートで増加します。タイムスタンプの単位は、単一（モノ）チャネルあたりのサンプルです。 RTPタイムスタンプは、エンコードされたフレームの最初のエンコードされたサンプルのサンプル時間に対応します。 48000 Hz以外のサンプリングレートでエンコードされたデータの場合、サンプリングレートを48000 Hzに調整する必要があります。
The Opus encoder can output encoded frames representing 2.5, 5, 10, 20, 40, or 60 ms of speech or audio data. Further, an arbitrary number of frames can be combined into a packet, up to a maximum packet duration representing 120 ms of speech or audio data. The grouping of one or more Opus frames into a single Opus packet is defined in Section 3 of [RFC6716]. An RTP payload MUST contain exactly one Opus packet as defined by that document.
Opusエンコーダーは、2.5、5、10、20、40、または60 msの音声またはオーディオデータを表すエンコードされたフレームを出力できます。さらに、最大120ミリ秒の音声またはオーディオデータを表す最大パケット持続時間まで、任意の数のフレームを1つのパケットに結合できます。 1つ以上のOpusフレームを単一のOpusパケットにグループ化することは、[RFC6716]のセクション3で定義されています。 RTPペイロードには、そのドキュメントで定義されているとおりのOpusパケットが1つだけ含まれている必要があります。
Figure 1 shows the structure combined with the RTP header.
図1に、RTPヘッダーと組み合わせた構造を示します。
+----------+--------------+
|RTP Header| Opus Payload |
+----------+--------------+
Figure 1: Packet Structure with RTP Header
図1：RTPヘッダーを含むパケット構造
Table 2 shows supported frame sizes in milliseconds of encoded speech or audio data for the speech and audio modes (Mode) and sampling rates (fs) of Opus, and it shows how the timestamp is incremented for packetization (ts incr). If the Opus encoder outputs multiple encoded frames into a single packet, the timestamp increment is the sum of the increments for the individual frames.
表2は、Opusの音声および音声モード（モード）とサンプリングレート（fs）でエンコードされた音声または音声データのミリ秒単位でサポートされているフレームサイズを示し、パケット化（ts incr）のタイムスタンプがどのように増加するかを示しています。 Opusエンコーダーが複数のエンコードされたフレームを単一のパケットに出力する場合、タイムスタンプの増分は、個々のフレームの増分の合計です。
+---------+-----------------+-----+-----+-----+-----+------+------+
| Mode | fs | 2.5 | 5 | 10 | 20 | 40 | 60 |
+---------+-----------------+-----+-----+-----+-----+------+------+
| ts incr | all | 120 | 240 | 480 | 960 | 1920 | 2880 |
| | | | | | | | |
| voice | NB/MB/WB/SWB/FB | x | x | o | o | o | o |
| | | | | | | | |
| audio | NB/WB/SWB/FB | o | o | o | o | x | x |
+---------+-----------------+-----+-----+-----+-----+------+------+
Table 2: Supported Opus frame sizes and timestamp increments are marked with an o. Unsupported ones are marked with an x.
表2：サポートされているOpusフレームサイズとタイムスタンプの増分には、oが付いています。サポートされていないものは、xでマークされています。
The target bitrate of Opus can be adjusted at any point in time, thus allowing efficient congestion control. Furthermore, the amount of encoded speech or audio data encoded in a single packet can be used for congestion control, since the transmission rate is inversely proportional to the packet duration. A lower packet transmission rate reduces the amount of header overhead, but at the same time increases latency and loss sensitivity, so it ought to be used with care.
Opusのターゲットビットレートはいつでも調整できるため、効率的な輻輳制御が可能です。さらに、送信レートはパケットの持続時間に反比例するため、単一のパケットにエンコードされた音声またはオーディオデータのエンコード量を輻輳制御に使用できます。パケット転送速度が低いと、ヘッダーのオーバーヘッドの量が減少しますが、同時に待ち時間と損失感度が増加するため、注意して使用する必要があります。
Since UDP does not provide congestion control, applications that use RTP over UDP SHOULD implement their own congestion control above the UDP layer [RFC5405]. Work in the RMCAT working group [rmcat] describes the interactions and conceptual interfaces necessary between the application components that relate to congestion control, including the RTP layer, the higher-level media codec control layer, and the lower-level transport interface, as well as components dedicated to congestion control functions.
UDPは輻輳制御を提供しないため、RTP over UDPを使用するアプリケーションは、UDPレイヤー[RFC5405]の上に独自の輻輳制御を実装する必要があります（SHOULD）。 RMCATワーキンググループ[rmcat]での作業では、RTPレイヤー、上位レベルのメディアコーデックコントロールレイヤー、下位レベルのトランスポートインターフェイスなど、輻輳制御に関連するアプリケーションコンポーネント間に必要な相互作用と概念的なインターフェイスについて説明します輻輳制御機能専用のコンポーネントとして。
One media subtype (audio/opus) has been defined and registered as described in the following section.
次のセクションで説明するように、1つのメディアサブタイプ（オーディオ/オーパス）が定義および登録されています。
Media type registration is done according to [RFC6838] and [RFC4855].
メディアタイプの登録は[RFC6838]と[RFC4855]に従って行われます。
Type name: audio
タイプ名：オーディオ
Subtype name: opus
サブタイプ名：opus
Required parameters:
必須パラメーター：
rate: the RTP timestamp is incremented with a 48000 Hz clock rate for all modes of Opus and all sampling rates. For data encoded with sampling rates other than 48000 Hz, the sampling rate has to be adjusted to 48000 Hz.
レート：RTPタイムスタンプは、Opusのすべてのモードとすべてのサンプリングレートで48000 Hzのクロックレートで増加します。 48000 Hz以外のサンプリングレートでエンコードされたデータの場合、サンプリングレートを48000 Hzに調整する必要があります。
Optional parameters:
オプションのパラメーター：
maxplaybackrate: a hint about the maximum output sampling rate that the receiver is capable of rendering in Hz. The decoder MUST be capable of decoding any audio bandwidth, but, due to hardware limitations, only signals up to the specified sampling rate can be played back. Sending signals with higher audio bandwidth results in higher than necessary network usage and encoding complexity, so an encoder SHOULD NOT encode frequencies above the audio bandwidth specified by maxplaybackrate. This parameter can take any value between 8000 and 48000, although commonly the value will match one of the Opus bandwidths (Table 1). By default, the receiver is assumed to have no limitations, i.e., 48000.
maxplaybackrate：レシーバーがHz単位でレンダリングできる最大出力サンプリングレートに関するヒント。デコーダーは任意のオーディオ帯域幅をデコードできる必要がありますが、ハードウェアの制限により、指定されたサンプリングレートまでの信号のみを再生できます。より高いオーディオ帯域幅で信号を送信すると、必要なネットワーク使用量とエンコードの複雑さが高くなるため、エンコーダーは、maxplaybackrateで指定されたオーディオ帯域幅を超える周波数をエンコードしないでください。このパラメーターは8000から48000までの任意の値を取ることができますが、通常、この値はOpus帯域幅の1つと一致します（表1）。デフォルトでは、レシーバーには制限がないと見なされます（48000など）。
sprop-maxcapturerate: a hint about the maximum input sampling rate that the sender is likely to produce. This is not a guarantee that the sender will never send any higher bandwidth (e.g., it could send a prerecorded prompt that uses a higher bandwidth), but it indicates to the receiver that frequencies above this maximum can safely be discarded. This parameter is useful to avoid wasting receiver resources by operating the audio processing pipeline (e.g., echo cancellation) at a higher rate than necessary. This parameter can take any value between 8000 and 48000, although commonly the value will match one of the Opus bandwidths (Table 1). By default, the sender is assumed to have no limitations, i.e., 48000.
sprop-maxcapturerate：送信者が生成する可能性が高い最大入力サンプリングレートに関するヒント。これは、送信者がより高い帯域幅を送信しないことを保証するものではありません（たとえば、より高い帯域幅を使用する録音済みのプロンプトを送信する可能性があります）。ただし、この最大値を超える周波数は安全に破棄できることを受信者に示します。このパラメーターは、オーディオ処理パイプライン（エコーキャンセレーションなど）を必要以上に高いレートで操作することにより、レシーバーリソースの浪費を回避するのに役立ちます。このパラメーターは8000から48000までの任意の値を取ることができますが、通常、この値はOpus帯域幅の1つと一致します（表1）。デフォルトでは、送信者は48000などの制限がないと見なされます。
maxptime: the maximum duration of media represented by a packet (according to Section 6 of [RFC4566]) that a decoder wants to receive, in milliseconds rounded up to the next full integer value. Possible values are 3, 5, 10, 20, 40, 60, or an arbitrary multiple of an Opus frame size rounded up to the next full integer value, up to a maximum value of 120, as defined in Section 4. If no value is specified, the default is 120.
maxptime：デコーダーが受信するパケット（[RFC4566]のセクション6による）で表されるメディアの最大持続時間（ミリ秒単位）。次の完全な整数値に切り上げられます。可能な値は、3、5、10、20、40、60、またはOpusフレームサイズの任意の倍数で、セクション4で定義されているように、最大値120まで次の完全な整数値に切り上げられます。値がない場合が指定されている場合、デフォルトは120です。
ptime: the preferred duration of media represented by a packet (according to Section 6 of [RFC4566]) that a decoder wants to receive, in milliseconds rounded up to the next full integer value. Possible values are 3, 5, 10, 20, 40, 60, or an arbitrary multiple of an Opus frame size rounded up to the next full integer value, up to a maximum value of 120, as defined in Section 4. If no value is specified, the default is 20.
ptime：デコーダが受信するパケット（[RFC4566]のセクション6による）で表されるメディアの推奨継続時間（ミリ秒単位）。次の完全な整数値に切り上げられます。可能な値は、3、5、10、20、40、60、またはOpusフレームサイズの任意の倍数で、セクション4で定義されているように、最大値120まで次の整数値に切り上げられます。値がない場合が指定されている場合、デフォルトは20です。
maxaveragebitrate: specifies the maximum average receive bitrate of a session in bits per second (bit/s). The actual value of the bitrate can vary, as it is dependent on the characteristics of the media in a packet. Note that the maximum average bitrate MAY be modified dynamically during a session. Any positive integer is allowed, but values outside the range 6000 to 510000 SHOULD be ignored. If no value is specified, the maximum value specified in Section 3.1.1 for the corresponding mode of Opus and corresponding maxplaybackrate is the default.
maxaveragebitrate：セッションの最大平均受信ビットレートをビット/秒（bit / s）で指定します。パケット内のメディアの特性に依存するため、ビットレートの実際の値は異なる場合があります。最大平均ビットレートは、セッション中に動的に変更される場合があります。正の整数は許可されますが、6000〜510000の範囲外の値は無視してください。値を指定しない場合、セクション3.1.1で指定されているOpusの対応するモードと対応するmaxplaybackrateの最大値がデフォルトです。
stereo: specifies whether the decoder prefers receiving stereo or mono signals. Possible values are 1 and 0, where 1 specifies that stereo signals are preferred, and 0 specifies that only mono signals are preferred. Independent of the stereo parameter, every receiver MUST be able to receive and decode stereo signals, but sending stereo signals to a receiver that signaled a preference for mono signals may result in higher than necessary network utilization and encoding complexity. If no value is specified, the default is 0 (mono).
ステレオ：デコーダがステレオまたはモノラル信号のどちらを受信するかを指定します。可能な値は1および0です。1はステレオ信号が優先されることを指定し、0はモノラル信号のみが優先されることを指定します。ステレオパラメータとは関係なく、すべての受信機はステレオ信号を受信してデコードできる必要がありますが、モノラル信号を優先することを通知した受信機にステレオ信号を送信すると、必要以上にネットワークの利用率とエンコーディングの複雑さが生じる可能性があります。値を指定しない場合、デフォルトは0（モノ）です。
sprop-stereo: specifies whether the sender is likely to produce stereo audio. Possible values are 1 and 0, where 1 specifies that stereo signals are likely to be sent, and 0 specifies that the sender will likely only send mono. This is not a guarantee that the sender will never send stereo audio (e.g., it could send a prerecorded prompt that uses stereo), but it indicates to the receiver that the received signal can be safely downmixed to mono. This parameter is useful to avoid wasting receiver resources by operating the audio processing pipeline (e.g., echo cancellation) in stereo when not necessary. If no value is specified, the default is 0 (mono).
sprop-stereo：送信者がステレオオーディオを生成する可能性が高いかどうかを指定します。可能な値は1および0です。1はステレオ信号が送信される可能性が高いことを示し、0は送信側がモノラルのみを送信する可能性が高いことを示します。これは、送信者がステレオオーディオを送信しないことを保証するものではありません（たとえば、ステレオを使用する録音済みのプロンプトを送信する可能性があります）が、受信した信号を安全にモノラルにダウンミックスできることを受信者に示します。このパラメーターは、必要のないときにステレオでオーディオ処理パイプライン（エコーキャンセルなど）を操作することにより、レシーバーリソースの浪費を回避するのに役立ちます。値を指定しない場合、デフォルトは0（モノ）です。
cbr: specifies if the decoder prefers the use of a constant bitrate versus a variable bitrate. Possible values are 1 and 0, where 1 specifies constant bitrate, and 0 specifies variable bitrate. If no value is specified, the default is 0 (vbr). When cbr is 1, the maximum average bitrate can still change, e.g., to adapt to changing network conditions.
cbr：デコーダーが可変ビットレートではなく固定ビットレートの使用を好むかどうかを指定します。可能な値は1と0です。1は固定ビットレートを指定し、0は可変ビットレートを指定します。値を指定しない場合、デフォルトは0（vbr）です。 cbrが1の場合でも、最大の平均ビットレートは変化する可能性があります（たとえば、変化するネットワーク状態に適応するためなど）。
useinbandfec: specifies that the decoder has the capability to take advantage of the Opus in-band FEC. Possible values are 1 and 0. Providing 0 when FEC cannot be used on the receiving side is RECOMMENDED. If no value is specified, useinbandfec is assumed to be 0. This parameter is only a preference, and the receiver MUST be able to process packets that include FEC information, even if it means the FEC part is discarded.
useinbandfec：デコーダーにOpusインバンドFECを利用する機能があることを指定します。可能な値は1と0です。受信側でFECを使用できない場合に0を指定することをお勧めします。値が指定されていない場合、useinbandfecは0と見なされます。このパラメーターは単なる設定であり、FEC部分が破棄されることを意味する場合でも、受信者はFEC情報を含むパケットを処理できる必要があります。
usedtx: specifies if the decoder prefers the use of DTX. Possible values are 1 and 0. If no value is specified, the default is 0.
usedtx：デコーダーがDTXの使用を優先するかどうかを指定します。可能な値は1と0です。値を指定しない場合、デフォルトは0です。
Encoding considerations:
エンコードに関する考慮事項：
The Opus media type is framed and consists of binary data according to Section 4.8 of [RFC6838].
Opusメディアタイプはフレーム付きで、[RFC6838]のセクション4.8に基づくバイナリデータで構成されています。
Security considerations:
セキュリティに関する考慮事項：
See Section 8 of this document.
このドキュメントのセクション8を参照してください。
Interoperability considerations: none
相互運用性に関する考慮事項：なし
Published specification: RFC 7587
公開された仕様：RFC 7587
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Any application that requires the transport of speech or audio data can use this media type. Some examples are, but not limited to, audio and video conferencing, Voice over IP, and media streaming.
音声またはオーディオデータの転送を必要とするアプリケーションは、このメディアタイプを使用できます。例としては、音声およびビデオ会議、Voice over IP、メディアストリーミングなどがあります。
Fragment identifier considerations: N/A
フラグメント識別子の考慮事項：なし
Person & email address to contact for further information:
詳細について連絡する人とメールアドレス：
SILK Support, silksupport@skype.net
SILKサポート、silksupport @ skype.net
Jean-Marc Valin, jmvalin@jmvalin.ca
Jean-Marc Valin、jmvalin @ jmvalin.ca
Intended usage: COMMON Restrictions on usage:
使用目的：一般的な使用制限：
For transfer over RTP, the RTP payload format (Section 4 of this document) SHALL be used.
RTPを介した転送では、RTPペイロード形式（このドキュメントのセクション4）を使用する必要があります（SHALL）。
Authors:
著者：
Julian Spittka, jspittka@gmail.com
Julian Spittka、jspittka @ gmail.com
Koen Vos, koenvos74@gmail.com
Koen Vos、koenvos74 @ gmail.com
Jean-Marc Valin, jmvalin@jmvalin.ca
Jean-Marc Valin、jmvalin @ jmvalin.ca
Change controller: IETF Payload working group delegated from the IESG
変更コントローラー：IESGから委任されたIETFペイロードワーキンググループ
The information described in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [RFC4566], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing Opus, the mapping is as follows:
メディアタイプの仕様で説明されている情報には、セッション記述プロトコル（SDP）[RFC4566]のフィールドへの特定のマッピングがあります。これは、RTPセッションを説明するために一般的に使用されます。 SDPを使用してOpusを使用するセッションを指定する場合、マッピングは次のようになります。
o The media type ("audio") goes in SDP "m=" as the media name.
o メディアタイプ（「オーディオ」）は、メディア名としてSDP「m =」に入ります。
o The media subtype ("opus") goes in SDP "a=rtpmap" as the encoding name. The RTP clock rate in "a=rtpmap" MUST be 48000, and the number of channels MUST be 2.
o メディアサブタイプ（ "opus"）は、エンコーディング名としてSDP "a = rtpmap"に入ります。 「a = rtpmap」のRTPクロックレートは48000でなければならず、チャネル数は2でなければなりません。
o The OPTIONAL media type parameters "ptime" and "maxptime" are mapped to "a=ptime" and "a=maxptime" attributes, respectively, in the SDP.
o オプションのメディアタイプパラメータ「ptime」と「maxptime」は、SDPの「a = ptime」属性と「a = maxptime」属性にそれぞれマップされます。
o The OPTIONAL media type parameters "maxaveragebitrate", "maxplaybackrate", "stereo", "cbr", "useinbandfec", and "usedtx", when present, MUST be included in the "a=fmtp" attribute in the SDP, expressed as a media type string in the form of a semicolon-separated list of parameter=value pairs (e.g., maxplaybackrate=48000). They MUST NOT be specified in an SSRC-specific "fmtp" source-level attribute (as defined in Section 6.3 of [RFC5576]).
o オプションのメディアタイプパラメータ「maxaveragebitrate」、「maxplaybackrate」、「stereo」、「cbr」、「useinbandfec」、および「usedtx」は、存在する場合、SDPの「a = fmtp」属性に含める必要があります。パラメーター=値のペアをセミコロンで区切ったリスト形式のメディアタイプ文字列（例：maxplaybackrate = 48000）。 SSRC固有の「fmtp」ソースレベル属性（[RFC5576]のセクション6.3で定義されている）で指定しないでください。
o The OPTIONAL media type parameters "sprop-maxcapturerate" and "sprop-stereo" MAY be mapped to the "a=fmtp" SDP attribute by copying them directly from the media type parameter string as part of the semicolon-separated list of parameter=value pairs (e.g., sprop-stereo=1). These same OPTIONAL media type parameters MAY also be specified using an SSRC-specific "fmtp" source-level attribute as described in Section 6.3 of [RFC5576]. They MAY be specified in both places, in which case the parameter in the source-level attribute overrides the one found on the "a=fmtp" line. The value of any parameter that is not specified in a source-level source attribute MUST be taken from the "a=fmtp" line, if it is present there.
oオプションのメディアタイプパラメータ「sprop-maxcapturerate」と「sprop-stereo」は、セミコロンで区切られたパラメータリストの一部としてメディアタイプパラメータ文字列から直接コピーすることにより、「a = fmtp」SDP属性にマッピングできます。値のペア（例：sprop-stereo = 1）。 [RFC5576]のセクション6.3で説明されているように、これらの同じオプションのメディアタイプパラメータは、SSRC固有の「fmtp」ソースレベル属性を使用して指定することもできます（MAY）。それらは両方の場所で指定できます。その場合、source-level属性のパラメーターが「a = fmtp」行にあるパラメーターをオーバーライドします。ソースレベルのソース属性で指定されていないパラメーターの値は、「a = fmtp」行に存在する場合は、そこから取得する必要があります。
Below are some examples of SDP session descriptions for Opus:
以下は、OpusのSDPセッションの説明の例です。
Example 1: Standard mono session with 48000 Hz clock rate
例1：48000 Hzクロックレートの標準モノセッション
m=audio 54312 RTP/AVP 101
a=rtpmap:101 opus/48000/2
Example 2: 16000 Hz clock rate, maximum packet size of 40 ms, recommended packet size of 40 ms, maximum average bitrate of 20000 bit/s, prefers to receive stereo but only plans to send mono, FEC is desired, DTX is not desired
例2：16000 Hzのクロックレート、40 msの最大パケットサイズ、40 msの推奨パケットサイズ、20000ビット/秒の最大平均ビットレート、ステレオの受信を優先しますが、モノを送信する計画のみ、FECが望ましい、DTXは望ましくない
m=audio 54312 RTP/AVP 101
a=rtpmap:101 opus/48000/2
a=fmtp:101 maxplaybackrate=16000; sprop-maxcapturerate=16000;
maxaveragebitrate=20000; stereo=1; useinbandfec=1; usedtx=0
a=ptime:40
a=maxptime:40
Example 3: Two-way full-band stereo preferred
例3：双方向フルバンドステレオを推奨
m=audio 54312 RTP/AVP 101
a=rtpmap:101 opus/48000/2
a=fmtp:101 stereo=1; sprop-stereo=1
When using the offer/answer procedure described in [RFC3264] to negotiate the use of Opus, the following considerations apply:
[RFC3264]で説明されているオファー/アンサー手順を使用してOpusの使用を交渉する場合、次の考慮事項が適用されます。
o Opus supports several clock rates. For signaling purposes, only the highest, i.e., 48000, is used. The actual clock rate of the corresponding media is signaled inside the payload and is not restricted by this payload format description. The decoder MUST be capable of decoding every received clock rate. An example is shown below:
o Opusはいくつかのクロックレートをサポートしています。シグナリングの目的で、最も高い、つまり48000のみが使用されます。対応するメディアの実際のクロックレートはペイロード内で通知され、このペイロード形式の説明によって制限されません。デコーダーは受信したすべてのクロックレートをデコードできる必要があります。以下に例を示します。
m=audio 54312 RTP/AVP 100
a=rtpmap:100 opus/48000/2
o The "ptime" and "maxptime" parameters are unidirectional receive-only parameters and typically will not compromise interoperability; however, some values might cause application performance to suffer. [RFC3264] defines the SDP offer/answer handling of the "ptime" parameter. The "maxptime" parameter MUST be handled in the same way.
o 「ptime」および「maxptime」パラメーターは単方向の受信専用パラメーターであり、通常は相互運用性を損なうことはありません。ただし、値によっては、アプリケーションのパフォーマンスが低下する可能性があります。 [RFC3264]は、「ptime」パラメータのSDPオファー/アンサー処理を定義します。 「maxptime」パラメータは同じ方法で処理する必要があります。
o The "maxplaybackrate" parameter is a unidirectional receive-only parameter that reflects limitations of the local receiver. When sending to a single destination, a sender MUST NOT use an audio bandwidth higher than necessary to make full use of audio sampled at a sampling rate of "maxplaybackrate". Gateways or senders that are sending the same encoded audio to multiple destinations SHOULD NOT use an audio bandwidth higher than necessary to represent audio sampled at "maxplaybackrate", as this would lead to inefficient use of network resources. The "maxplaybackrate" parameter does not affect interoperability. Also, this parameter SHOULD NOT be used to adjust the audio bandwidth as a function of the bitrate, as this is the responsibility of the Opus encoder implementation.
o 「maxplaybackrate」パラメーターは、ローカルレシーバーの制限を反映する単一方向の受信専用パラメーターです。単一の宛先に送信する場合、送信者は、「maxplaybackrate」のサンプリングレートでサンプリングされたオーディオを最大限に活用するために、必要以上に高いオーディオ帯域幅を使用してはなりません。同じエンコードされたオーディオを複数の宛先に送信するゲートウェイまたは送信者は、「maxplaybackrate」でサンプリングされたオーディオを表すために必要以上のオーディオ帯域幅を使用しないでください。これは、ネットワークリソースの非効率的な使用につながるためです。 「maxplaybackrate」パラメータは相互運用性には影響しません。また、このパラメーターは、オーパスエンコーダーの実装の責任であるため、ビットレートの関数としてオーディオ帯域幅を調整するために使用してはなりません（SHOULD NOT）。
o The "maxaveragebitrate" parameter is a unidirectional receive-only parameter that reflects limitations of the local receiver. The sender of the other side MUST NOT send with an average bitrate higher than "maxaveragebitrate" as it might overload the network and/or receiver. The "maxaveragebitrate" parameter typically will not compromise interoperability; however, some values might cause application performance to suffer and ought to be set with care.
o 「maxaveragebitrate」パラメーターは、ローカルレシーバーの制限を反映する単一方向の受信専用パラメーターです。反対側の送信側は、「maxaveragebitrate」よりも高い平均ビットレートで送信してはいけません。ネットワークや受信側に過負荷をかける可能性があるためです。 「maxaveragebitrate」パラメータは通常、相互運用性を損なうことはありません。ただし、値によっては、アプリケーションのパフォーマンスが低下する可能性があるため、注意して設定する必要があります。
o The "sprop-maxcapturerate" and "sprop-stereo" parameters are unidirectional sender-only parameters that reflect limitations of the sender side. They allow the receiver to set up a reduced-complexity audio processing pipeline if the sender is not planning to use the full range of Opus's capabilities. Neither "sprop-maxcapturerate" nor "sprop-stereo" affect interoperability, and the receiver MUST be capable of receiving any signal.
o 「sprop-maxcapturerate」および「sprop-stereo」パラメーターは、送信側の制限を反映する単一方向の送信専用パラメーターです。これにより、送信者がOpusの全機能を使用する予定がない場合でも、受信者は複雑さの少ないオーディオ処理パイプラインをセットアップできます。 「sprop-maxcapturerate」も「sprop-stereo」も相互運用性には影響せず、レシーバーは任意の信号を受信できる必要があります。
o The "stereo" parameter is a unidirectional receive-only parameter. When sending to a single destination, a sender MUST NOT use stereo when "stereo" is 0. Gateways or senders that are sending the same encoded audio to multiple destinations SHOULD NOT use stereo when "stereo" is 0, as this would lead to inefficient use of network resources. The "stereo" parameter does not affect interoperability.
o 「ステレオ」パラメーターは、単一方向の受信専用パラメーターです。単一の宛先に送信する場合、「ステレオ」が0の場合、送信者はステレオを使用してはなりません。「ステレオ」が0の場合、同じエンコードされたオーディオを複数の宛先に送信するゲートウェイまたは送信者はステレオを使用しないでください。これは非効率になるためです。ネットワークリソースの使用。 「ステレオ」パラメータは相互運用性には影響しません。
o The "cbr" parameter is a unidirectional receive-only parameter.
o 「cbr」パラメーターは、単一方向の受信専用パラメーターです。
o The "useinbandfec" parameter is a unidirectional receive-only parameter.
o 「useinbandfec」パラメーターは、単一方向の受信専用パラメーターです。
o The "usedtx" parameter is a unidirectional receive-only parameter.
o 「usedtx」パラメーターは、単一方向の受信専用パラメーターです。
o Any unknown parameter in an offer MUST be ignored by the receiver and MUST be removed from the answer.
o オファー内の不明なパラメーターは、受信者によって無視されなければならず、応答から削除されなければなりません（MUST）。
The Opus parameters in an SDP offer/answer exchange are completely orthogonal, and there is no relationship between the SDP offer and the answer.
SDPオファー/アンサー交換のOpusパラメーターは完全に直交しており、SDPオファーとアンサーの間に関係はありません。
For declarative use of SDP such as in the Session Announcement Protocol (SAP) [RFC2974] and the Real Time Streaming Protocol (RTSP) [RFC2326] for Opus, the following needs to be considered:
Opus用のSession Announcement Protocol（SAP）[RFC2974]やReal Time Streaming Protocol（RTSP）[RFC2326]などのSDPの宣言的な使用については、以下を考慮する必要があります。
o The values for "maxptime", "ptime", "maxplaybackrate", and "maxaveragebitrate" ought to be selected carefully to ensure that a reasonable performance can be achieved for the participants of a session.
o "maxptime"、 "ptime"、 "maxplaybackrate"、および "maxaveragebitrate"の値は、セッションの参加者が適切なパフォーマンスを達成できるように注意深く選択する必要があります。
o The values for "maxptime", "ptime", and of the payload format configuration are recommendations by the decoding side to ensure the best performance for the decoder.
o 「maxptime」、「ptime」、およびペイロード形式の構成の値は、デコーダーの最高のパフォーマンスを保証するためにデコード側で推奨されます。
o All other parameters of the payload format configuration are declarative and a participant MUST use the configurations that are provided for the session. More than one configuration can be provided if necessary by declaring multiple RTP payload types; however, the number of types ought to be kept small.
o ペイロード形式設定の他のすべてのパラメータは宣言的であり、参加者はセッションに提供される設定を使用する必要があります。必要に応じて、複数のRTPペイロードタイプを宣言することにより、複数の構成を提供できます。ただし、タイプの数は少なくする必要があります。
Use of VBR is subject to the security considerations in [RFC6562].
VBRの使用は、[RFC6562]のセキュリティに関する考慮事項に従います。
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and in any applicable RTP profile such as RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711], or RTP/ SAVPF [RFC5124]. However, as "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] discusses, it is not an RTP payload format's responsibility to discuss or mandate what solutions are used to meet the basic security goals like confidentiality, integrity, and source authenticity for RTP in general. This responsibility lies on anyone using RTP in an application. They can find guidance on available security mechanisms and important considerations in "Options for Securing RTP Sessions" [RFC7201]. Applications SHOULD use one or more appropriate strong security mechanisms.
この仕様で定義されたペイロード形式を使用するRTPパケットは、RTP仕様[RFC3550]およびRTP / AVP [RFC3551]、RTP / AVPF [RFC4585]、RTP / SAVP [ RFC3711]、またはRTP / SAVPF [RFC5124]。ただし、「RTPフレームワークのセキュリティ保護：RTPが単一のメディアセキュリティソリューションを義務付けない理由」[RFC7202]が説明しているように、機密性などの基本的なセキュリティ目標を達成するためにどのソリューションが使用されるかを話し合う、または義務付けるのは、RTPペイロード形式の責任ではありません。完全性、および一般的なRTPのソースの信頼性。この責任は、アプリケーションでRTPを使用するすべての人にあります。利用可能なセキュリティメカニズムと重要な考慮事項に関するガイダンスは、「RTPセッションを保護するためのオプション」[RFC7201]にあります。アプリケーションは、1つ以上の適切な強力なセキュリティメカニズムを使用する必要があります。
This payload format and the Opus encoding do not exhibit any significant non-uniformity in the receiver-end computational load and thus are unlikely to pose a denial-of-service threat due to the receipt of pathological datagrams.
このペイロード形式とOpusエンコーディングは、受信側の計算負荷に大きな不均一性を示さないため、病理学的データグラムの受信によるサービス拒否の脅威をもたらす可能性は低いです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, DOI 10.17487/RFC2326, April 1998, <http://www.rfc-editor.org/info/rfc2326>.
[RFC2326] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「Real Time Streaming Protocol（RTSP）」、RFC 2326、DOI 10.17487 / RFC2326、1998年4月、<http：//www.rfc-editor。 org / info / rfc2326>。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <http://www.rfc-editor.org/info/rfc3264>.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション記述プロトコル（SDP）を備えたオファー/アンサーモデル」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<http://www.rfc-editor.org / info / rfc3264>。
[RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)", RFC 3389, DOI 10.17487/RFC3389, September 2002, <http://www.rfc-editor.org/info/rfc3389>.
[RFC3389] Zopf、R。、「Real-time Transport Protocol（RTP）Payload for Comfort Noise（CN）」、RFC 3389、DOI 10.17487 / RFC3389、2002年9月、<http://www.rfc-editor.org/ info / rfc3389>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、 <http://www.rfc-editor.org/info/rfc3550>。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, <http://www.rfc-editor.org/info/rfc3551>.
[RFC3551] Schulzrinne、H。およびS. Casner、「Minimal Controlを使用したオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、DOI 10.17487 / RFC3551、2003年7月、<http：//www.rfc-editor。 org / info / rfc3551>。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <http://www.rfc-editor.org/info/rfc3711>.
[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「Secure Real-time Transport Protocol（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、3月2004、<http://www.rfc-editor.org/info/rfc3711>。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<http://www.rfc-editor.org/ info / rfc4566>。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, <http://www.rfc-editor.org/info/rfc4855>.
[RFC4855] Casner、S。、「RTPペイロード形式のメディアタイプ登録」、RFC 4855、DOI 10.17487 / RFC4855、2007年2月、<http://www.rfc-editor.org/info/rfc4855>。
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, <http://www.rfc-editor.org/info/rfc5576>.
[RFC5576] Lennox、J.、Ott、J。、およびT. Schierl、「Session Description Protocol（SDP）のソース固有のメディア属性」、RFC 5576、DOI 10.17487 / RFC5576、2009年6月、<http：// www.rfc-editor.org/info/rfc5576>。
[RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP", RFC 6562, DOI 10.17487/RFC6562, March 2012, <http://www.rfc-editor.org/info/rfc6562>.
[RFC6562]パーキンス、C。およびJM。 Valin、「Secure RTPでの可変ビットレートオーディオの使用に関するガイドライン」、RFC 6562、DOI 10.17487 / RFC6562、2012年3月、<http://www.rfc-editor.org/info/rfc6562>。
[RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, September 2012, <http://www.rfc-editor.org/info/rfc6716>.
[RFC6716] Valin、JM。、Vos、K。、およびT. Terriberry、「Definition of the Opus Audio Codec」、RFC 6716、DOI 10.17487 / RFC6716、2012年9月、<http://www.rfc-editor.org / info / rfc6716>。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc-editor.org/info/rfc6838>.
[RFC6838] Freed、N.、Klensin、J。、およびT. Hansen、「Media Type Specifications and Registration Procedures」、BCP 13、RFC 6838、DOI 10.17487 / RFC6838、2013年1月、<http：//www.rfc- editor.org/info/rfc6838>。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, October 2000, <http://www.rfc-editor.org/info/rfc2974>.
[RFC2974] Handley、M.、Perkins、C。、およびE. Whelan、「Session Announcement Protocol」、RFC 2974、DOI 10.17487 / RFC2974、2000年10月、<http://www.rfc-editor.org/info/ rfc2974>。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <http://www.rfc-editor.org/info/rfc4585>.
[RFC4585] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイムトランスポートコントロールプロトコル（RTCP）ベースのフィードバック用の拡張RTPプロファイル（RTP / AVPF） "、RFC 4585、DOI 10.17487 / RFC4585、2006年7月、<http://www.rfc-editor.org/info/rfc4585>。
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, <http://www.rfc-editor.org/info/rfc5124>.
[RFC5124] Ott、J。およびE. Carrara、「リアルタイム転送制御プロトコル（RTCP）ベースのフィードバック用の拡張セキュアRTPプロファイル（RTP / SAVPF）」、RFC 5124、DOI 10.17487 / RFC5124、2008年2月、<http ：//www.rfc-editor.org/info/rfc5124>。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, DOI 10.17487/RFC5405, November 2008, <http://www.rfc-editor.org/info/rfc5405>.
[RFC5405] Eggert、L。およびG. Fairhurst、「アプリケーション設計者のためのユニキャストUDP使用ガイドライン」、BCP 145、RFC 5405、DOI 10.17487 / RFC5405、2008年11月、<http://www.rfc-editor.org/info / rfc5405>。
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <http://www.rfc-editor.org/info/rfc7201>.
[RFC7201] Westerlund、M。およびC. Perkins、「RTPセッションを保護するためのオプション」、RFC 7201、DOI 10.17487 / RFC7201、2014年4月、<http://www.rfc-editor.org/info/rfc7201>。
[RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 2014, <http://www.rfc-editor.org/info/rfc7202>.
[RFC7202] Perkins、C。およびM. Westerlund、「RTPフレームワークの保護：RTPが単一のメディアセキュリティソリューションを義務付けない理由」、RFC 7202、DOI 10.17487 / RFC7202、2014年4月、<http：//www.rfc- editor.org/info/rfc7202>。
[rmcat] "RTP Media Congestion Avoidance Techniques (rmcat) Documents", <https://datatracker.ietf.org/wg/rmcat/ documents/>.
[rmcat]「RTPメディア輻輳回避テクニック（rmcat）ドキュメント」、<https://datatracker.ietf.org/wg/rmcat/documents/>。
Acknowledgements
謝辞
Many people have made useful comments and suggestions contributing to this document. In particular, we would like to thank Tina le Grand, Cullen Jennings, Jonathan Lennox, Gregory Maxwell, Colin Perkins, Jan Skoglund, Timothy B. Terriberry, Martin Thompson, Justin Uberti, Magnus Westerlund, and Mo Zanaty.
多くの人々がこのドキュメントに貢献する有用なコメントや提案をしました。特に、Tina le Grand、Cullen Jennings、Jonathan Lennox、Gregory Maxwell、Colin Perkins、Jan Skoglund、Timothy B. Terriberry、Martin Thompson、Justin Uberti、Magnus Westerlund、Mo Zanatyに特に感謝します。
Authors' Addresses
著者のアドレス
Julian Spittka
ジュリアン・スピットカ
Email: jspittka@gmail.com
Koen Vos vocTone
Koen Vos vocTone
Email: koenvos74@gmail.com
Jean-Marc Valin Mozilla 331 E. Evelyn Avenue Mountain View, CA 94041 United States
Jean-Marc Valin Mozilla 331 E. Evelyn Avenue Mountain View、CA 94041アメリカ合衆国
Email: jmvalin@jmvalin.ca