[要約] RFC 8854は、WebRTCにおける転送エラー訂正の要件を定義しています。このRFCの目的は、リアルタイム通信におけるパケット損失を軽減し、通信の品質を向上させることです。
Internet Engineering Task Force (IETF) J. Uberti
Request for Comments: 8854 Google
Category: Standards Track January 2021
ISSN: 2070-1721
WebRTC Forward Error Correction Requirements
WEBRTC前方誤り訂正要件
Abstract
概要
This document provides information and requirements for the use of Forward Error Correction (FEC) by WebRTC implementations.
この文書は、WebRTC実装によって順方向誤り訂正（FEC）を使用するための情報と要件を提供します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
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 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8854.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8854で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。
Table of Contents
目次
1. Introduction
2. Terminology
3. Types of FEC
3.1. Separate FEC Stream
3.2. Redundant Encoding
3.3. Codec-Specific In-Band FEC
4. FEC for Audio Content
4.1. Recommended Mechanism
4.2. Negotiating Support
5. FEC for Video Content
5.1. Recommended Mechanism
5.2. Negotiating Support
6. FEC for Application Content
7. Implementation Requirements
8. Adaptive Use of FEC
9. Security Considerations
10. IANA Considerations
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Author's Address
In situations where packet loss is high, or perfect media quality is essential, Forward Error Correction (FEC) can be used to proactively recover from packet losses. This specification provides guidance on which FEC mechanisms to use, and how to use them, for WebRTC implementations.
パケット損失が高く、または完全なメディア品質が不可欠な状況では、順方向誤り訂正（FEC）を使用してパケット損失から積極的に回復することができます。この仕様は、WebRTC実装のために使用するFECメカニズム、およびそれらの使用方法に関するガイダンスを提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
「必須」、「必須」、「必須」、「SHALL」、「必ず」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「5月」「この文書では、BCP 14 [RFC2119] [RFC8174]に記載されている場合に解釈されるべきであり、ここに示すように、すべての首都に表示されます。
FEC describes the sending of redundant information in an outgoing packet stream so that information can still be recovered even in the event of packet loss. There are multiple ways this can be accomplished for RTP media streams [RFC3550]; this section enumerates the various mechanisms available and describes their trade-offs.
FECは、パケット損失が発生した場合でも情報が依然として回復することができるように、発信パケットストリーム内の冗長情報の送信を説明しています。これがRTPメディアストリームで実行できる方法は複数あります[RFC3550];このセクションでは、利用可能なさまざまなメカニズムを列挙し、それらのトレードオフを説明します。
This approach, as described in [RFC5956], Section 4.3, sends FEC packets as an independent RTP stream with its own synchronization source (SSRC) [RFC3550] and payload type, multiplexed with the primary encoding. While this approach can protect multiple packets of the primary encoding with a single FEC packet, each FEC packet will have its own IP/UDP/RTP/FEC header, and this overhead can be excessive in some cases, e.g., when protecting each primary packet with a FEC packet.
このアプローチは、[RFC5956]、セクション4.3で説明されているように、FECパケットを独立したRTPストリームとして独自の同期ソース（SSRC）[RFC3550]とペイロードタイプをプライマリエンコーディングで多重化します。このアプローチは、単一のFECパケットを使用してプライマリエンコードの複数のパケットを保護することができますが、各FECパケットには独自のIP / UDP / RTP / FECヘッダーがあります。FECパケットで。
This approach allows for recovery of entire RTP packets, including the full RTP header.
このアプローチでは、フルRTPヘッダーを含むRTPパケット全体の回復を可能にします。
This approach, as described in [RFC2198], allows for redundant data to be piggybacked on an existing primary encoding, all in a single packet. This redundant data may be an exact copy of a previous payload, or for codecs that support variable-bitrate encodings, the redundant data may possibly be a smaller, lower-quality representation. In certain cases, the redundant data could include encodings of multiple prior audio frames.
[RFC2198]に記載されているように、このアプローチでは、既存の一次エンコーディングで冗長データをピギーバックすることができます。この冗長データは、以前のペイロードの正確なコピー、または可変ビットレートエンコーディングをサポートするコーデックの場合、冗長データはおそらくより小さく、低品質の表現である可能性があります。場合によっては、冗長データには、複数の前のオーディオフレームのエンコードが含まれている可能性があります。
Since there is only a single set of packet headers, this approach allows for a very efficient representation of primary and redundant data. However, this savings is only realized when the data all fits into a single packet (i.e. the size is less than a MTU). As a result, this approach is generally not useful for video content.
パケットヘッダーの一組のセットしかないので、このアプローチは、一次データと冗長データの非常に効率的な表現を可能にします。しかしながら、この節約は、データが全て単一のパケットに収まるときにのみ実現される（すなわち、サイズはMTUより小さい）。結果として、このアプローチは一般にビデオコンテンツには有用ではない。
As described in [RFC2198], Section 4, this approach cannot recover certain parts of the RTP header, including the marker bit, contributing source (CSRC) information, and header extensions.
[RFC2198]、セクション4で説明されているように、このアプローチは、マーカービット、貢献ソース（CSRC）情報、およびヘッダー拡張子を含む、RTPヘッダーの特定の部分を回復することはできません。
Some audio codecs, notably Opus [RFC6716] and Adaptive Multi-Rate (AMR) [RFC4867], support their own in-band FEC mechanism, where redundant data is included in the codec payload. This is similar to the redundant encoding mechanism described above, but as it adds no additional framing, it can be slightly more efficient.
いくつかのオーディオコーデック、特にOPUS [RFC6716]および適応マルチレート（AMR）[RFC4867]は、冗長データがコーデックペイロードに含まれているそれら自身のインバンドFECメカニズムをサポートします。これは上記の冗長符号化メカニズムと似ていますが、追加のフレーミングを追加するため、わずかに効率的です。
For Opus, audio frames deemed important are re-encoded at a lower bitrate and appended to the next payload, allowing partial recovery of a lost packet. This scheme is fairly efficient; experiments performed indicate that when Opus FEC is used, the overhead imposed is only about 20-30%, depending on the amount of protection needed. Note that this mechanism can only carry redundancy information for the immediately preceding audio frame; thus the decoder cannot fully recover multiple consecutive lost packets, which can be a problem on wireless networks. See [RFC6716], Section 2.1.7, and this Opus mailing list post [OpusFEC] for more details.
For AMR and AMR-Wideband (AMR-WB), packets can contain copies or lower-quality encodings of multiple prior audio frames. See [RFC4867], Section 3.7.1, for details on this mechanism.
AMRおよびAMR-WideBand（AMR-WB）の場合、パケットには、複数の前のオーディオフレームのコピーまたは低品質のエンコーディングを含めることができます。このメカニズムの詳細については、セクション3.7.1の[RFC4867]を参照してください。
In-band FEC mechanisms cannot recover any of the RTP header.
インバンドFECメカニズムは、RTPヘッダーのいずれかを回復できません。
The following section provides guidance on how to best use FEC for transmitting audio data. As indicated in Section 8 below, FEC should only be activated if network conditions warrant it, or upon explicit application request.
次のセクションでは、オーディオデータの送信にFECを最大限に使用する方法に関するガイダンスについて説明します。以下のセクション8に示されるように、ネットワーク状態がそれを正しく保証する場合、または明示的なアプリケーション要求の場合にのみ、FECはアクティブにする必要があります。
When using variable-bitrate codecs without an internal FEC, redundant encoding (as described in Section 3.2) with lower-fidelity version(s) of the previous packet(s) is RECOMMENDED. This provides reasonable protection of the payload with only moderate bitrate increase, as the redundant encodings can be significantly smaller than the primary encoding.
内部FECのない可変BITRATEコーデックを使用する場合、前のパケットのより低い忠実度のバージョン（S）を備えた冗長エンコードが推奨されます。これは、冗長符号化が主要な符号化よりもかなり小さくなる可能性があるため、これにより、中程度のビットレートの増加のみでペイロードを合理的に保護することができます。
When using the Opus codec, use of the built-in Opus FEC mechanism is RECOMMENDED. This provides reasonable protection of the audio stream against individual losses, with minimal overhead. Note that, as indicated above, the built-in Opus FEC only provides single-frame redundancy; if multi-packet protection is needed, the aforementioned redundant encoding with reduced-bitrate Opus encodings SHOULD be used instead.
OPUSコーデックを使用する場合は、内蔵のOpus FECメカニズムを使用することをお勧めします。これにより、オーバーヘッドが最小限のオーバーヘッドで、個々の損失に対する音声ストリームを合理的な保護を提供します。上記のように、内蔵OPUS FECはシングルフレームの冗長性のみを提供することに注意してください。マルチパケット保護が必要な場合は、縮小ビットレートOPUエンコーディングを備えた前述の冗長符号化を代わりに使用する必要があります。
When using the AMR/AMR-WB codecs, use of their built-in FEC mechanism is RECOMMENDED. This provides slightly more efficient protection of the audio stream than redundant encoding does.
AMR / AMR-WBコーデックを使用する場合は、内蔵FECメカニズムを使用することをお勧めします。これにより、冗長エンコードよりも音声ストリームをわずかに効率的に保護します。
When using constant-bitrate codecs, e.g., PCMU [RFC5391], redundant encoding MAY be used, but this will result in a potentially significant bitrate increase, and suddenly increasing bitrate to deal with losses from congestion may actually make things worse.
定数ビットレートコーデックを使用する場合、例えばPCMU [RFC5391]、冗長符号化を使用することができるが、これは潜在的に有意なビットレートの増加をもたらし、突然輻輳からの損失に対処するためにビットレートを増加させることは実際に物事を悪化させる可能性がある。
Because of the lower packet rate of audio encodings, usually a single packet per frame, use of a separate FEC stream comes with a higher overhead than other mechanisms, and therefore is NOT RECOMMENDED.
オーディオエンコードのパケットレートが低いため、通常はフレームごとに単一のパケットがあるため、別のFECストリームの使用には他のメカニズムよりも高いオーバーヘッドが付いているため、お勧めできません。
As mentioned above, the recommended mechanisms do not allow recovery of parts of the RTP header that may be important in certain audio applications, e.g., CSRCs and RTP header extensions like those specified in [RFC6464] and [RFC6465]. Implementations SHOULD account for this and attempt to approximate this information, using an approach similar to those described in [RFC2198], Section 4, and [RFC6464], Section 5.
上述のように、推奨されるメカニズムは、[RFC6464]および[RFC6465]で指定された特定のオーディオアプリケーション、例えばCSRCSおよびRTPヘッダー拡張機能では重要である可能性があるRTPヘッダーの一部の回復を可能にしません。実装は、[RFC2198]、セクション4、および[RFC6464]、セクション5で説明されているものと同様の方法で、この情報を説明する必要があります。
Support for redundant encoding of a given RTP stream SHOULD be indicated by including audio/red [RFC2198] as an additional supported media type for the associated "m=" section in the SDP offer [RFC3264]. Answerers can reject the use of redundant encoding by not including the audio/red media type in the corresponding "m=" section in the SDP answer.
特定のRTPストリームの冗長エンコーディングのサポートは、SDPオファー[RFC3264]の関連付けの「M =」セクションのサポートされている追加のメディアタイプとして、AUDIO / RED [RFC2198]を追加してください。回答者は、SDP回答の対応する「M =」セクションにオーディオ/赤いメディアタイプを含まないことによって、冗長エンコードの使用を拒否できます。
Support for codec-specific FEC mechanisms are typically indicated via "a=fmtp" parameters.
コーデック固有のFECメカニズムのサポートは通常、 "A = FMTP"パラメータを介して示されます。
For Opus, a receiver MUST indicate that it is prepared to use incoming FEC data with the "useinbandfec=1" parameter, as specified in [RFC7587]. This parameter is declarative and can be negotiated separately for either media direction.
OPUの場合、[RFC7587]で指定されているように、「useinbandfec = 1」パラメータを使用して入ってくるFECデータを使用するように準備されていることを認識している必要があります。このパラメータは宣言的であり、どちらのメディアの方向も個別に交渉することができます。
For AMR/AMR-WB, support for redundant encoding, and the maximum supported depth, are controlled by the "max-red" parameter, as specified in [RFC4867], Section 8.1. Receivers MUST include this parameter, and set it to an appropriate value, as specified in [TS.26114], Table 6.3.
AMR / AMR-WBの場合、冗長エンコーディングのサポート、およびサポートされている最大深度は、[RFC4867]、セクション8.1で指定されているように、「MAX-RED」パラメータによって制御されます。受信者はこのパラメータを含め、[TS.26114]の[TS.26114]、表6.3に指定されているように、適切な値に設定する必要があります。
The following section provides guidance on how to best use FEC for transmitting video data. As indicated in Section 8 below, FEC should only be activated if network conditions warrant it, or upon explicit application request.
次のセクションでは、ビデオデータを送信するためにFECを最もよく使用する方法に関するガイダンスを説明します。以下のセクション8に示されるように、ネットワーク状態がそれを正しく保証する場合、または明示的なアプリケーション要求の場合にのみ、FECはアクティブにする必要があります。
Video frames, due to their size, often require multiple RTP packets. As discussed above, a separate FEC stream can protect multiple packets with a single FEC packet. In addition, the Flexible FEC mechanism described in [RFC8627] is also capable of protecting multiple RTP streams via a single FEC stream, including all the streams that are part of a BUNDLE group [RFC8843]. As a result, for video content, use of a separate FEC stream with the Flexible FEC RTP payload format is RECOMMENDED.
ビデオフレームは、それらのサイズのために、複数のRTPパケットを必要とします。上述のように、別個のFECストリームは、単一のFECパケットを持つ複数のパケットを保護することができる。さらに、[RFC8627]に記載されているフレキシブルFECメカニズムは、バンドルグループの一部であるすべてのストリームを含む、単一のFECストリームを介して複数のRTPストリームを保護することもできます。その結果、ビデオコンテンツの場合、柔軟なFEC RTPペイロードフォーマットを使用して別々のFECストリームを使用することをお勧めします。
To process the incoming FEC stream, the receiver can demultiplex it by SSRC, and then correlate it with the appropriate primary stream(s) via the CSRC(s) present in the RTP header of Flexible FEC repair packets, or the SSRC field present in the FEC header of Flexible FEC retransmission packets.
着信FECストリームを処理するために、受信機はSSRCによってそれを分離することができ、次に柔軟なFEC修復パケットのRTPヘッダーに存在するCSRC（S）を介して適切な一次ストリーム、またはに存在するSSRCフィールドと相関させることができます。フレキシブルFEC再送パケットのFECヘッダー。
Support for an SSRC-multiplexed Flexible FEC stream to protect a given RTP stream SHOULD be indicated by including video/flexfec (described in [RFC8627], Section 5.1.2) as an additional supported media type for the associated "m=" section in the SDP offer [RFC3264]. As mentioned above, when BUNDLE is used, only a single Flexible FEC repair stream will be created for each BUNDLE group, even if Flexible FEC is negotiated for each primary stream.
特定のRTPストリームを保護するためのSSRC多重化された柔軟なFECストリームのサポートは、関連する「M =」の「M =」の追加のサポートされているメディアタイプとして、ビデオ/ FLEXFEC（[RFC8627]、セクション5.1.2）を含めることで示す必要があります。SDPオファー[RFC3264]。上述のように、バンドルが使用されるとき、たとえ柔軟なFECが各一次ストリームに対してネゴシエートされていても、各バンドルグループに対して単一の柔軟なFEC修復ストリームのみが作成される。
Answerers can reject the use of SSRC-multiplexed FEC by not including the video/flexfec media type in the corresponding "m=" section in the SDP answer.
回答者は、SDP回答の対応する「M =」セクションにビデオ/ FLEXFECメディアタイプを含まないことによってSSRC多重化FECの使用を拒否できます。
Use of FEC-only "m=" lines, and grouping using the SDP group mechanism as described in [RFC5956], Section 4.1, is not currently defined for WebRTC, and SHOULD NOT be offered.
[RFC5956]、セクション4.1で説明されているSDPグループメカニズムを使用したGROUNINGの使用、SDPグループメカニズムを使用したグループ化は、現在WebRTCに対して定義されており、提供されるはずです。
Answerers SHOULD reject any FEC-only "m=" lines, unless they specifically know how to handle such a thing in a WebRTC context (perhaps defined by a future version of the WebRTC specifications).
回答者は、WebRTCコンテキスト（おそらく将来のバージョンのWebRTC仕様によって定義されている）を扱う方法を特に知らない限り、FECのみの「M =」行を拒否する必要があります。
WebRTC also supports the ability to send generic application data, and provides transport-level retransmission mechanisms to support full and partial (e.g., timed) reliability. See [RFC8831] for details.
WebRTCはまた、一般的なアプリケーションデータを送信する能力をサポートし、完全かつ部分的な（例えば、時限）信頼性をサポートするためのトランスポートレベルの再送信メカニズムを提供します。詳細については[RFC8831]を参照してください。
Because the application can control exactly what data to send, it has the ability to monitor packet statistics and perform its own application-level FEC if necessary.
アプリケーションは送信するデータを正確に制御できるため、パケット統計を監視し、必要に応じて独自のアプリケーションレベルのFECを実行することができます。
As a result, this document makes no recommendations regarding FEC for the underlying data transport.
その結果、この文書は基礎となるデータ転送のためのFECに関して推奨されません。
To support the functionality recommended above, implementations MUST be able to receive and make use of the relevant FEC formats for their supported audio codecs, and MUST indicate this support, as described in Section 4. Use of these formats when sending, as mentioned above, is RECOMMENDED.
上記の機能をサポートするためには、実装はサポートされているオーディオコーデックの関連するFECフォーマットを受信して使用することができ、セクション4で説明されているように、このサポートを示している必要があります。がおすすめ。
The general FEC mechanism described in [RFC8627] SHOULD also be supported, as mentioned in Section 5.
セクション5で述べたように、[RFC8627]に記載されている一般的なFECメカニズムもサポートされるべきです。
Implementations MAY support additional FEC mechanisms if desired, e.g., [RFC5109].
実装は、必要に応じて追加のFECメカニズムをサポートしていてもよい。
Because use of FEC always causes redundant data to be transmitted, and the total amount of data must remain within any bandwidth limits indicated by congestion control and the receiver, this will lead to less bandwidth available for the primary encoding, even when the redundant data is not being used. This is in contrast to methods like RTX [RFC4588] or Flexible FEC's retransmission mode ([RFC8627], Section 1.1.7), which only transmit redundant data when necessary, at the cost of an extra round trip and thereby increased media latency.
FECの使用は常に冗長データを送信するため、データの合計量が輻輳制御と受信側で示されている帯域幅の制限内に留まる必要がありますが、これにより、冗長データが次の場合でもプライマリエンコーディングで使用可能な帯域幅が少なくなります。使われていません。これは、RTX [RFC4588]またはフレキシブルFECの再送信モード（[RFC8627]、セクション1.1.7）のような方法とは対照的に、必要に応じて冗長データを送信し、それによってメディアの待ち時間を増やします。
Given this, WebRTC implementations SHOULD prefer using RTX or Flexible FEC retransmissions instead of FEC when the connection RTT is within the application's latency budget, and otherwise SHOULD only transmit the amount of FEC needed to protect against the observed packet loss (which can be determined, e.g., by monitoring transmit packet loss data from RTP Control Protocol (RTCP) receiver reports [RFC3550]), unless the application indicates it is willing to pay a quality penalty to proactively avoid losses.
これを考えると、接続RTTがアプリケーションの待ち時間予算内にある場合は、FECの代わりにRTXまたは柔軟なFECの再送信を使用する必要があります。そうでなければ、観測されたパケット損失から保護するのに必要なFECの量だけを送信する必要があります（これを決定できます。たとえば、アプリケーションが損失を避けるために品質のペナルティを支払うことを望んでいることを示していない限り、RTCP制御プロトコル（RTCP）レシーバーレポート[RFC3550]から送信パケット損失データを監視することによって、[RFC3550]）。
Note that when probing bandwidth, i.e., speculatively sending extra data to determine if additional link capacity exists, FEC data SHOULD be used as the additional data. Given that extra data is going to be sent regardless, it makes sense to have that data protect the primary payload; in addition, FEC can typically be applied in a way that increases bandwidth only modestly, which is necessary when probing.
追加のリンク容量が存在するかどうかを判断するために帯域幅を探している場合、追加のデータを決定するために追加データを追加データとして使用する必要があります。余分なデータが関係なく送信されることを考えると、そのデータがプライマリペイロードを保護することは理にかなっています。さらに、FECは通常、帯域幅を緩やかに増加させる方法で適用でき、これはプロービング時に必要です。
When using FEC with layered codecs, e.g., [RFC6386], where only base layer frames are critical to the decoding of future frames, implementations SHOULD only apply FEC to these base layer frames.
ベースレイヤフレームのみが将来のフレームの復号にとって重要である階層化コーデックでFECを使用する場合、実装はこれらの基本レイヤフレームにFECを適用する必要があります。
Finally, it should be noted that, although applying redundancy is often useful in protecting a stream against packet loss, if the loss is caused by network congestion, the additional bandwidth used by the redundant data may actually make the situation worse and can lead to significant degradation of the network.
最後に、冗長性を適用することは、パケット損失に対してストリームを保護するのに役立ちますが、損失がネットワークの輻輳によって引き起こされる場合、冗長データによって使用される追加の帯域幅は実際には状況を悪化させ、大きくなる可能性があることに注意してください。ネットワークの劣化
In the WebRTC context, FEC is specifically concerned with recovering data from lost packets; any corrupted packets will be discarded by the Secure Real-Time Transport Protocol (SRTP) [RFC3711] decryption process. Therefore, as described in [RFC3711], Section 10, the default processing when using FEC with SRTP is to perform FEC followed by SRTP at the sender, and SRTP followed by FEC at the receiver. This ordering is used for all the SRTP protection profiles used in DTLS-SRTP [RFC5763], which are enumerated in [RFC5764], Section 4.1.2.
WebRTCコンテキストでは、FECは紛失したパケットからのデータの回復に特に関係しています。破損したパケットは、セキュアリアルタイムトランスポートプロトコル（SRTP）[RFC3711]復号化プロセスによって破棄されます。したがって、[RFC3711]、SECTION 10で説明されているように、SRTPを使用してFECを使用する場合のデフォルト処理は、送信側でSRTPとそれに続くSRTPとそれに続く受信機でFECを実行することです。この注文は、[RFC5764]、4.1.2で列挙されているDTLS-SRTP [RFC5763]で使用されるすべてのSRTP保護プロファイルに使用されます。
Additional security considerations for each individual FEC mechanism are enumerated in their respective documents.
個々のFECメカニズムについての追加のセキュリティ上の考慮事項は、それぞれの文書に列挙されます。
This document requires no actions from IANA.
この文書ではIANAからの処置は必要ありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J.C., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, DOI 10.17487/RFC2198, September 1997, <https://www.rfc-editor.org/info/rfc2198>.
[RFC2198] Perkins、C、Kouvelas、I。、Hodson、O.、Hardman、V.、Handley、M.、Bolot、JC、Vega-Garcia、A.、およびS.FOSSE-PARISIS、「RTPペイロード」冗長オーディオデータ "、RFC 2198、DOI 10.17487 / RFC2198、1997年9月、<https://www.rfc-editor.org/info/rfc2198>。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.
[RFC3264] Rosenberg、J.およびH.Schulzrinne、「セッション記述プロトコル（SDP）」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<https：//ww.rfc-editor.org/ info / rfc3264>。
[RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 4867, DOI 10.17487/RFC4867, April 2007, <https://www.rfc-editor.org/info/rfc4867>.
[RFC4867] Sjoberg、J.、Westerlund、M.、Lakaniemi、A.、およびQ. XIE、「適応型マルチレート（AMR）および適応マルチレートワイドバンドのRTPペイロードフォーマットおよびファイル格納形式（AMR-WB））オーディオコーデック "、RFC 4867、DOI 10.17487 / RFC4867、2007年4月、<https://www.rfc-editor.org/info/rfc4867>。
[RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in the Session Description Protocol", RFC 5956, DOI 10.17487/RFC5956, September 2010, <https://www.rfc-editor.org/info/rfc5956>.
[RFC5956] BEGEN、A。、「セッション記述プロトコル」、RFC 5956、DOI 10.17487 / RFC5956、2010年9月、<https://www.rfc-editor.org/info/rfc5956>。
[RFC7587] Spittka, J., Vos, K., and JM. Valin, "RTP Payload Format for the Opus Speech and Audio Codec", RFC 7587, DOI 10.17487/RFC7587, June 2015, <https://www.rfc-editor.org/info/rfc7587>.
[RFC7587] Spittka、J.、Vos、K.、JM。バリ、「Opus Speech and Audio CodecのRTPペイロードフォーマット」、RFC 7587、DOI 10.17487 / RFC7587、2015年6月、<https：//www.rfc-editor.org/info/rfc7587>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8627] Zanaty, M., Singh, V., Begen, A., and G. Mandyam, "RTP Payload Format for Flexible Forward Error Correction (FEC)", RFC 8627, DOI 10.17487/RFC8627, July 2019, <https://www.rfc-editor.org/info/rfc8627>.
[RFC8627] Zanaty、M.、Singh、V.、Begen、A.、およびG. Mandyam、「柔軟な順方向誤り訂正のためのRTPペイロード形式（FEC）」、RFC 8627、DOI 10.17487 / RFC8627、2019年7月、<HTTPS：//www.rfc-editor.org/info/rfc8627>。
[TS.26114] 3GPP, "IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction", 3GPP TS 26.114 15.0.0, 22 September 2017, <http://www.3gpp.org/ftp/Specs/html-info/26114.htm>.
[TS.26114] 3GPP、「IPマルチメディアサブシステム（IMS）;マルチメディアテレフォニー;メディア処理とインタラクション」、3GPP TS 26.114 15.0.0,22,22,22、<http://www.3gpp.org/ftp/specs/HTML-Info / 26114.htm>。
[OpusFEC] Terriberry, T., "Subject: Opus FEC", message to the opus mailing list, 28 January 2013, <http://lists.xiph.org/pipermail/ opus/2013-January/001904.html>.
[Opusfec] Terriberry、T.、 "Subject：Opus FEC"、Opusメーリングリストへのメッセージ、<http://lists.xiph.org/pipermail/ opus / 2013-1月/ 001904.html>。
[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, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R.、およびV. Jacobson、「RTP：リアルタイムアプリケーション用輸送プロトコル」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、<https://www.rfc-editor.org/info/rfc3550>。
[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, <https://www.rfc-editor.org/info/rfc3711>.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E.、K.Norrman、「安全なリアルタイムトランスポートプロトコル（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、3月2004年、<https：//www.rfc-editor.org/info/rfc3711>。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, <https://www.rfc-editor.org/info/rfc4588>.
[RFC4588] Rey、J.、Leon、D.、Miyazaki、A.、Varsa、V.およびR.Hakenberg、「RTP再送ペイロードフォーマット」、RFC 4588、DOI 10.17487 / RFC4588、2006年7月、<https：//www.rfc-editor.org/info/rfc4588>。
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, <https://www.rfc-editor.org/info/rfc5109>.
[RFC5109] Li、A.、ED。、「汎用フォワードエラー訂正のためのRTPペイロード形式」、RFC 5109、DOI 10.17487 / RFC5109、2007年12月、<https：//www.rfc-editor.org/info/rfc5109>。
[RFC5391] Sollaud, A., "RTP Payload Format for ITU-T Recommendation G.711.1", RFC 5391, DOI 10.17487/RFC5391, November 2008, <https://www.rfc-editor.org/info/rfc5391>.
[RFC5391] SOLLAUD、A。、「ITU-T勧告のRTPペイロード形式G.711.1」、RFC 5391、DOI 10.17487 / RFC5391、2008年11月、<https://www.rfc-editor.org/info/rfc5391>。
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, <https://www.rfc-editor.org/info/rfc5763>.
[RFC5763] FISCHL、J.、TSCHOFENIG、H.、およびE.RESCORLA、「データグラムトランスポート層セキュリティ（DTLS）」、RFC 5763、DOI 10.17487 /を使用したセキュリティコンテキスト（SRTP）セキュリティコンテキストを確立するためのフレームワーク。2010年5月、<https://www.rfc-editor.org/info/rfc5763>。
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, <https://www.rfc-editor.org/info/rfc5764>.
[RFC5764] MCGREW、D.およびE. RESCORLA、セキュアリアルタイムトランスポートプロトコル（SRTP） "、RFC 5764、DOI 10.17487 / RFC5764、2010年5月、<HTTPS）：//www.rfc-editor.org/info/rfc5764>。
[RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding Guide", RFC 6386, DOI 10.17487/RFC6386, November 2011, <https://www.rfc-editor.org/info/rfc6386>.
[RFC6386] Bankoski、J.、Koleszar、J.、Quillio、L.、Salonen、J.、Wilkins、P.、およびY。XU、「VP8データフォーマットおよびデコードガイド」、RFC 6386、DOI 10.17487 / RFC6386、2011年11月、<https：//www.rfc-editor.org/info/rfc6386>。
[RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication", RFC 6464, DOI 10.17487/RFC6464, December 2011, <https://www.rfc-editor.org/info/rfc6464>.
[RFC6464] Lennox、J.、Ed。、Ivov、E.、およびE.Marocco、「クライアントからミキサーのオーディオレベル表示のためのリアルタイムトランスポートプロトコル（RTP）ヘッダ拡張」、RFC 6464、DOI 10.17487 /RFC6464、2011年12月、<https://www.rfc-editor.org/info/rfc6464>。
[RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication", RFC 6465, DOI 10.17487/RFC6465, December 2011, <https://www.rfc-editor.org/info/rfc6465>.
[RFC6465] IVOV、E.、ED。、Marocco、E.、ED。、およびJ.Lennox、「ミキサー間のオーディオレベル表示のためのリアルタイムトランスポートプロトコル（RTP）ヘッダ拡張」、RFC 6465、DOI 10.17487 / RFC6465、2011年12月、<https://www.rfc-editor.org/info/rfc6465>。
[RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, September 2012, <https://www.rfc-editor.org/info/rfc6716>.
[RFC6716] Valin、JM、VOS、K.、およびT.Treiberry、「Opus Audio Codecの定義」、RFC 6716、DOI 10.17487 / RFC6716、2012年9月、<https：//www.rfc-editor.org/ info / rfc6716>。
[RFC8831] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021, <https://www.rfc-editor.org/info/rfc8831>.
[RFC8831] Jesup、R.、Loreto、S.、M.Tüxen、「Webrtcデータチャンネル」、RFC 8831、DOI 10.17487 / RFC8831、2021年1月、<https：//www.rfc-editor.org/info/RFC8831>。
[RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", RFC 8843, DOI 10.17487/RFC8843, January 2021, <https://www.rfc-editor.org/info/rfc8843>.
[RFC8843] Holmberg、C、Alvestrand、H.、およびC.ジェンニング、「セッション記述プロトコル（SDP）」、RFC 8843、DOI 10.17487 / RFC8843、<https：// www。rfc-editor.org/info/rfc8843>。
Acknowledgements
謝辞
Several people provided significant input into this document, including Bernard Aboba, Jonathan Lennox, Giri Mandyam, Varun Singh, Tim Terriberry, Magnus Westerlund, and Mo Zanaty.
Bernard Aboba、Jonathan Lennox、Giri Mandyam、Varun Singh、Tim Treiberry、Magnus Westerlund、Mo Zanatyなど、この文書に重要な入力を提供しました。
Author's Address
著者の住所
Justin Uberti Google 747 6th St S Kirkland, WA 98033 United States of America
Justin Uberti Google 747 6th St S Kirkland、WA 98033アメリカ合衆国
Email: justin@uberti.name