RFC 8854 - WebRTC Forward Error Correction Requirements 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc8854.html
タイトル : RFC 8854 - WebRTC前方誤り訂正（FEC）要件
翻訳編集 : 自動生成

[要約] RFC 8854は、WebRTC通信におけるエンドツーエンドのパケット損失からの保護（Forward Error Correction: FEC）に関する要件を規定しています。リアルタイム通信の品質を維持するために、どのようにFECを適用し、輻輳制御と組み合わせるべきかのガイドラインを提供しています。ネットワークのパケットロスが発生した場合でも、音声やビデオの途切れを最小限に抑えるための技術的指針となります。

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前方誤り訂正（FEC）要件

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で入手できます。

著作権表示

著作権（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

1. Introduction

1. はじめに

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メカニズム、およびそれらの使用方法に関するガイダンスを提供します。

2. Terminology

2. 用語

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.

このドキュメントのキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY"、および "OPTIONAL" は、BCP 14 [RFC2119] [RFC8174] で説明されているように、すべて大文字で表示される場合にのみ解釈されるものとします。

3. Types of FEC

3. FECの種類

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];このセクションでは、利用可能なさまざまなメカニズムを列挙し、それらのトレードオフを説明します。

3.1. Separate FEC Stream

3.1. 別々のFECストリーム

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パケット全体の回復を可能にします。

3.2. Redundant Encoding

3.2. 冗長エンコーディング

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ヘッダーの特定の部分を回復することはできません。

3.3. Codec-Specific In-Band FEC

3.3. コーデック固有のバンドFEC

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ヘッダーのいずれかを回復できません。

4. FEC for Audio Content

4. オーディオコンテンツのFEC

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はアクティブにする必要があります。

4.1. Recommended Mechanism

4.1. 推奨機構

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] などの固定ビットレートコーデックを使用する場合、冗長符号化を使用してもよい (MAY) が、これにより潜在的に大幅なビットレート増加が生じる可能性があり、輻輳による損失に対処するために突然ビットレートを増加させることは、実際には事態を悪化させる可能性があります。

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ストリームの使用は他のメカニズムよりも高いオーバーヘッドを伴い、したがって推奨されません (NOT RECOMMENDED)。

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で説明されているものと同様の方法で、この情報を説明すべきです (SHOULD)。

4.2. Negotiating Support

4.2. 交渉支援

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データを使用するように準備されていることを認識していなければなりません (MUST)。このパラメータは宣言的であり、どちらのメディアの方向も個別に交渉することができます。

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に指定されているように、適切な値に設定しなければなりません (MUST)。

5. FEC for Video Content

5. ビデオコンテンツ用FEC

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はアクティブにする必要があります。

5.1. Recommended Mechanism

5.1. 推奨機構

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メカニズムは、BUNDLEグループの一部であるすべてのストリームを含む、単一の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ヘッダー。

5.2. Negotiating Support

5.2. 交渉支援

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 =」の追加のサポートされているメディアタイプとして、video/flexfec（[RFC8627]、セクション5.1.2）を含めることで示すべきです (SHOULD)。SDPオファー[RFC3264]。上述のように、BUNDLEが使用されるとき、たとえ柔軟なFECが各一次ストリームに対してネゴシエートされていても、各BUNDLEグループに対して単一の柔軟な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 =」セクションにvideo/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グループメカニズムを使用したFEC専用「m=」行の使用およびグループ化は、現在WebRTCでは定義されておらず、提供すべきではありません (SHOULD NOT)。

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 =」行を拒否すべきです (SHOULD)。

6. FEC for Application Content

6. アプリケーションコンテンツのFEC

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に関して推奨されません。

7. Implementation Requirements

7. 実装要件

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メカニズムもサポートされるべきです (SHOULD)。

Implementations MAY support additional FEC mechanisms if desired, e.g., [RFC5109].

実装は、必要に応じて追加のFECメカニズムをサポートしていてもよい (MAY)。

8. Adaptive Use of FEC

8. 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データを使用すべきである (SHOULD) ことに注意してください。いずれにせよ余分なデータを送信するのであれば、そのデータに主ペイロードを保護させるのが理にかなっています。さらに、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を適用すべきです (SHOULD)。

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.

最後に、冗長性を適用することは、パケット損失に対してストリームを保護するのに役立ちますが、損失がネットワークの輻輳によって引き起こされる場合、冗長データによって使用される追加の帯域幅は実際には状況を悪化させ、大きくなる可能性があることに注意してください。ネットワークの劣化

9. Security Considerations

9. セキュリティに関する考慮事項

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メカニズムについての追加のセキュリティ上の考慮事項は、それぞれの文書に列挙されます。

10. IANA Considerations

10. IANAの考慮事項

This document requires no actions from IANA.

この文書ではIANAからの処置は必要ありません。

11. References

11. 参考文献

11.1. Normative References

11.1. 引用文献

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

[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. and H. Schulzrinne、「セッション記述プロトコル（SDP）」、RFC 3264、DOI 10.17487/RFC3264、2002年6月、<https://www.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>.

[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., and 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>.

11.2. Informative References

11.2. 参考引用

[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-January/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., and 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., and 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., and 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., and 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>.

[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., and 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., and 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., and 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., and 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>.

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