メインコンテンツまでスキップ

RFC 8854 - WebRTC 前方誤り訂正要件

  • ステータス: Proposed Standard
  • 発行日: January 2021
  • ストリーム: IETF
  • エラッタ: エラッタなし

概要​

この文書は, WebRTC 実装による前方誤り訂正 (Forward Error Correction, FEC) の使用に関する情報と要件を提供します.

このメモの位置付け​

これは Internet Standards Track 文書です.

この文書は Internet Engineering Task Force (IETF) の成果物です. IETF コミュニティのコンセンサスを表します. 公開レビューを受け, Internet Engineering Steering Group (IESG) により公開が承認されています. Internet 標準に関する詳細は RFC 7841 の Section 2 を参照してください.

この文書の現在の状態, エラッタ, およびフィードバックの方法については https://www.rfc-editor.org/info/rfc8854 を参照してください.

著作権表示​

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.

この文書は BCP 78 および IETF Trust の IETF Documents に関する法的規定 (https://trustee.ietf.org/license-info) (この文書の発行日に有効なもの) の対象です. これらの文書を注意深く確認してください. これらは本文書に関する権利と制限を記述しています. 本文書から抽出されたコードコンポーネントには, Trust Legal Provisions の Section 4.e に記載された Simplified BSD License テキストを含める必要があり, Simplified BSD License に記載された保証なしで提供されます.

目次​

1. はじめに​

パケット損失が高い状況, または完璧なメディア品質が不可欠な場合, 前方誤り訂正 (Forward Error Correction, FEC) を使用してパケット損失から積極的に回復できます. この仕様は, WebRTC 実装がどの FEC メカニズムを使用し, どのように使用するかについての指針を提供します.

2. 用語​

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", および "OPTIONAL" は, BCP 14 [RFC2119] [RFC8174] に記載のとおりに解釈されます. ただし, ここに示すようにすべて大文字で現れる場合に限ります.

3. FEC の種類​

FEC は, パケット損失が発生した場合でも情報を回復できるように, 送信パケットストリームに冗長情報を送ることを指します. RTP メディアストリーム [RFC3550] については複数の方法があり, 本節では利用可能な各種メカニズムを列挙し, そのトレードオフを説明します.

3.1. 独立 FEC ストリーム​

[RFC5956] Section 4.3 で説明されているこの方式は, FEC パケットを独自の synchronization source (SSRC) [RFC3550] と payload type を持つ独立した RTP ストリームとして送信し, 主符号化と多重化します. この方式では単一の FEC パケットで主符号化の複数パケットを保護できますが, 各 FEC パケットには独自の IP/UDP/RTP/FEC ヘッダーが付き, 例えば各主パケットを FEC パケットで保護する場合など, オーバーヘッドが大きくなりすぎることがあります.

この方式では, 完全な RTP ヘッダーを含む RTP パケット全体の回復が可能です.

3.2. 冗長符号化​

[RFC2198] で説明されているこの方式では, 既存の主符号化に冗長データを載せて, すべてを単一パケットにまとめます. この冗長データは以前の payload の正確なコピーである場合もあれば, 可変ビットレート符号化をサポートするコーデックでは, より小さく低品質な表現である場合もあります. 場合によっては, 冗長データに複数の先行音声フレームの符号化が含まれることもあります.

パケットヘッダーが 1 組だけなので, この方式は主データと冗長データを非常に効率的に表現できます. ただし, この節約はデータがすべて単一パケットに収まる (すなわちサイズが MTU 未満である) 場合にのみ実現されます. そのため, この方式は一般に映像コンテンツにはあまり有用ではありません.

[RFC2198] Section 4 で説明されているように, この方式では RTP ヘッダーの一部 (marker ビット, contributing source (CSRC) 情報, ヘッダー拡張を含む) を回復できません.

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

一部の音声コーデック, 特に Opus [RFC6716] および Adaptive Multi-Rate (AMR) [RFC4867] は, 冗長データをコーデック payload に含める独自のインバンド FEC メカニズムをサポートしています. これは上述の冗長符号化メカニズムに似ていますが, 追加のフレーミングを加えないため, やや効率的になり得ます.

Opus では, 重要と見なされた音声フレームがより低いビットレートで再符号化され, 次の payload に付加され, 損失パケットの部分的な回復を可能にします. この方式はかなり効率的です; 実験によると, Opus FEC を使用した場合のオーバーヘッドは, 必要な保護量に応じて約 20-30% にすぎません. このメカニズムは直前の音声フレームの冗長情報のみを運べることに注意してください; したがってデコーダは連続して失われた複数パケットを完全に回復できず, これは無線ネットワークで問題になり得ます. 詳細は [RFC6716] Section 2.1.7 および Opus メーリングリスト投稿 [OpusFEC] を参照してください.

AMR および AMR-Wideband (AMR-WB) では, パケットに複数の先行音声フレームのコピーまたは低品質符号化を含めることができます. このメカニズムの詳細は [RFC4867] Section 3.7.1 を参照してください.

インバンド FEC メカニズムでは RTP ヘッダーのいずれの部分も回復できません.

4. 音声コンテンツ向け FEC​

以下の節では, 音声データを送信するために FEC を最適に使用する方法についての指針を示します. 下記 Section 8 に示すように, FEC はネットワーク条件がそれを正当化する場合, またはアプリケーションが明示的に要求する場合にのみ有効にすべきです.

4.1. 推奨メカニズム​

内部 FEC のない可変ビットレートコーデックを使用する場合, 以前のパケットの低忠実度版を用いた冗長符号化 (Section 3.2 で説明) が RECOMMENDED です. 冗長符号化は主符号化よりかなり小さくできるため, 適度なビットレート増加で payload を合理的に保護できます.

Opus コーデックを使用する場合, 組み込み Opus FEC メカニズムの使用が RECOMMENDED です. これにより, 最小限のオーバーヘッドで個々の損失に対する音声ストリームの合理的な保護が得られます. 上記のとおり, 組み込み Opus FEC は単一フレームの冗長性のみを提供します; 複数パケット保護が必要な場合は, 代わりにビットレートを下げた Opus 符号化による上述の冗長符号化を SHOULD 使用します.

AMR/AMR-WB コーデックを使用する場合, それらの組み込み FEC メカニズムの使用が RECOMMENDED です. これは冗長符号化よりやや効率的に音声ストリームを保護します.

定ビットレートコーデック (例: PCMU [RFC5391]) を使用する場合, 冗長符号化を MAY 使用できますが, ビットレートが大幅に増加する可能性があり, 輻輳による損失に対処するために突然ビットレートを上げると, かえって状況を悪化させることがあります.

音声符号化のパケットレートは通常フレームあたり 1 パケットと低いため, 独立 FEC ストリームの使用は他のメカニズムよりオーバーヘッドが高く, したがって NOT RECOMMENDED です.

上述のとおり, 推奨メカニズムでは, 一部の音声アプリケーションで重要になり得る RTP ヘッダーの一部 (例えば CSRC や [RFC6464] および [RFC6465] で規定される RTP ヘッダー拡張) を回復できません. 実装はこれを考慮し, [RFC2198] Section 4 および [RFC6464] Section 5 で説明されるものと同様の手法でこの情報を近似するよう SHOULD 試みます.

4.2. サポートの交渉​

所与の RTP ストリームに対する冗長符号化のサポートは, SDP offer [RFC3264] の関連 "m=" セクションに audio/red [RFC2198] を追加のサポートメディアタイプとして含めることで SHOULD 示します. 応答側は, SDP answer の対応する "m=" セクションに audio/red メディアタイプを含めないことで冗長符号化の使用を拒否できます.

コーデック固有 FEC メカニズムのサポートは, 通常 "a=fmtp" パラメータで示されます.

Opus では, 受信側は [RFC7587] で規定されている "useinbandfec=1" パラメータを用いて, 着信 FEC データを使用する準備ができていることを MUST 示します. このパラメータは宣言的であり, いずれかのメディア方向について個別に交渉できます.

AMR/AMR-WB では, 冗長符号化のサポートおよびサポートする最大深さは, [RFC4867] Section 8.1 で規定される "max-red" パラメータで制御されます. 受信側はこのパラメータを MUST 含め, [TS.26114] Table 6.3 で規定される適切な値に設定しなければなりません.

5. 映像コンテンツ向け FEC​

以下の節では, 映像データを送信するために FEC を最適に使用する方法についての指針を示します. 下記 Section 8 に示すように, FEC はネットワーク条件がそれを正当化する場合, またはアプリケーションが明示的に要求する場合にのみ有効にすべきです.

5.1. 推奨メカニズム​

映像フレームはそのサイズのため, しばしば複数の RTP パケットを必要とします. 上述のとおり, 独立 FEC ストリームは単一の FEC パケットで複数パケットを保護できます. さらに, [RFC8627] で説明される Flexible FEC メカニズムは, BUNDLE グループ [RFC8843] に属するすべてのストリームを含む, 複数の RTP ストリームを単一の FEC ストリームで保護することもできます. その結果, 映像コンテンツについては, Flexible FEC RTP payload 形式を用いた独立 FEC ストリームの使用が RECOMMENDED です.

着信 FEC ストリームを処理するため, 受信側は SSRC でデマルチプレックスし, Flexible FEC repair パケットの RTP ヘッダーに存在する CSRC, または Flexible FEC retransmission パケットの FEC ヘッダーに存在する SSRC フィールドにより, 適切な主ストリームと関連付けることができます.

5.2. サポートの交渉​

所与の RTP ストリームを保護する SSRC 多重 Flexible FEC ストリームのサポートは, SDP offer [RFC3264] の関連 "m=" セクションに video/flexfec ([RFC8627] Section 5.1.2 で説明) を追加のサポートメディアタイプとして含めることで SHOULD 示します. 上述のとおり, BUNDLE を使用する場合, 各主ストリームについて Flexible FEC が交渉されていても, 各 BUNDLE グループにつき単一の Flexible FEC repair ストリームのみが作成されます.

応答側は, SDP answer の対応する "m=" セクションに video/flexfec メディアタイプを含めないことで SSRC 多重 FEC の使用を拒否できます.

FEC のみの "m=" 行の使用, および [RFC5956] Section 4.1 で説明される SDP group メカニズムによるグループ化は, 現在 WebRTC 向けに定義されておらず, SHOULD NOT オファーします.

応答側は, WebRTC コンテキストでそのようなものを扱う方法を特に知っていない限り (おそらく将来の WebRTC 仕様で定義される), あらゆる FEC のみの "m=" 行を SHOULD 拒否します.

6. アプリケーションコンテンツ向け FEC​

WebRTC は汎用アプリケーションデータの送信もサポートし, 完全および部分的 (例: 時間制限付き) 信頼性を支援するトランスポートレベルの再送メカニズムを提供します. 詳細は [RFC8831] を参照してください.

アプリケーションは送信するデータを正確に制御できるため, パケット統計を監視し, 必要に応じて独自のアプリケーションレベル FEC を実行できます.

その結果, この文書は下位データトランスポート向けの FEC について推奨を行いません.

7. 実装要件​

上記で推奨される機能をサポートするため, 実装はサポートする音声コーデックに関連する FEC 形式を受信して利用できなければならず (MUST), Section 4 で説明するとおりこのサポートを示さなければなりません (MUST). 上述のとおり, 送信時にこれらの形式を使用することは RECOMMENDED です.

[RFC8627] で説明される一般的な FEC メカニズムも, Section 5 で述べたとおり SHOULD サポートします.

必要に応じて, 実装は [RFC5109] などの追加の FEC メカニズムを MAY サポートできます.

8. FEC の適応的使用​

FEC の使用は常に冗長データの送信を伴い, データ総量は輻輳制御と受信側が示す帯域幅制限内に保たれなければならないため, 冗長データが使われない場合でも主符号化に使える帯域が減少します. これは RTX [RFC4588] や Flexible FEC の再送モード ([RFC8627] Section 1.1.7) のような方法と対照的で, 後者は必要なときのみ冗長データを送信しますが, 余分なラウンドトリップのコストでメディア遅延が増加します.

このため, 接続 RTT がアプリケーションの遅延予算内にある場合, WebRTC 実装は FEC の代わりに RTX または Flexible FEC 再送を優先して SHOULD 使用し, そうでない場合は観測されたパケット損失 (例えば RTP Control Protocol (RTCP) 受信者報告 [RFC3550] からの送信パケット損失データを監視して判定できる) に対する保護に必要な FEC 量のみを SHOULD 送信します. ただし, アプリケーションが損失を積極的に避けるために品質ペナルティを支払う意思を示す場合を除きます.

帯域幅をプローブするとき, すなわち追加のリンク容量があるかを判定するために投機的に余分なデータを送るとき, 余分なデータとして FEC データを SHOULD 使用します. いずれにせよ余分なデータを送る以上, そのデータで主 payload を保護するのは妥当です; さらに, FEC は通常帯域を適度に増やす形で適用でき, これはプローブ時に必要です.

例えば [RFC6386] のようなレイヤドコーデックで FEC を使う場合, 将来のフレームの復号に重要なのはベースレイヤフレームのみであるため, 実装はこれらのベースレイヤフレームにのみ FEC を SHOULD 適用します.

最後に, 冗長の適用はストリームをパケット損失から保護するのにしばしば有用ですが, 損失がネットワーク輻輳によるものである場合, 冗長データが使う追加帯域がかえって状況を悪化させ, ネットワークの著しい劣化につながり得ることに留意すべきです.

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

WebRTC コンテキストでは, FEC は失われたパケットからデータを回復することに特に関係します; 破損したパケットは Secure Real-Time Transport Protocol (SRTP) [RFC3711] の復号プロセスで破棄されます. したがって, [RFC3711] Section 10 で説明されているように, FEC と SRTP を併用する場合のデフォルト処理は, 送信側では FEC の後に SRTP, 受信側では SRTP の後に FEC を実行することです. この順序は, DTLS-SRTP [RFC5763] で使用され [RFC5764] Section 4.1.2 に列挙されるすべての SRTP 保護プロファイルで用いられます.

個々の FEC メカニズムに関する追加のセキュリティ考慮事項は, それぞれの文書に列挙されています.

10. IANA に関する考慮事項​

この文書は IANA からのアクションを必要としません.

11. 参考文献​

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.

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

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

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

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

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

[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. 参考情報​

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

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

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

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

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

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

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

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

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

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

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

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

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

謝辞​

Bernard Aboba, Jonathan Lennox, Giri Mandyam, Varun Singh, Tim Terriberry, Magnus Westerlund, Mo Zanaty を含む複数の方々が, この文書に重要な意見を提供しました.

著者の連絡先​

Justin Uberti
Google
747 6th St S
Kirkland, WA 98033
United States of America
Email: [email protected]