Skip to main content

RFC 8854 - WebRTC 前向纠错要求

发布时间: 2021年1月
状态: 标准轨道
作者: Justin Uberti (Google)

摘要 (Abstract)​

本文档为 WebRTC 实现使用前向纠错 (Forward Error Correction, FEC) 提供了信息和要求。

本备忘录的状态 (Status of This Memo)​

这是一份互联网标准轨道文档。

本文档是互联网工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已经接受了公众审查，并由互联网工程指导小组 (IESG) 批准发布。有关互联网标准的更多信息，请参见 RFC 7841 第2节。

有关本文档的当前状态、勘误表以及如何提供反馈的信息，可访问 https://www.rfc-editor.org/info/rfc8854。

目录 (Table of Contents)​

1. 简介​

在丢包率较高或需要完美媒体质量的情况下，可以使用前向纠错 (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] 第 4.3 节所述，这种方法将 FEC 数据包作为独立的 RTP 流发送，具有自己的同步源 (SSRC) [RFC3550] 和载荷类型，与主编码进行多路复用。虽然这种方法可以用单个 FEC 数据包保护主编码的多个数据包，但每个 FEC 数据包都将有自己的 IP/UDP/RTP/FEC 头部，在某些情况下（例如，用 FEC 数据包保护每个主数据包时）这种开销可能过大。

这种方法允许恢复整个 RTP 数据包，包括完整的 RTP 头部。

3.2. 冗余编码​

如 [RFC2198] 所述，这种方法允许将冗余数据附加到现有的主编码上，全部放在单个数据包中。这些冗余数据可能是先前载荷的精确副本，或者对于支持可变比特率编码的编解码器，冗余数据可能是更小、更低质量的表示。在某些情况下，冗余数据可能包括多个先前音频帧的编码。

由于只有一组数据包头部，这种方法允许非常高效地表示主数据和冗余数据。但是，只有当所有数据都适合单个数据包（即大小小于 MTU）时，才能实现这种节省。因此，这种方法通常对视频内容不太有用。

如 [RFC2198] 第 4 节所述，这种方法无法恢复 RTP 头部的某些部分，包括标记位、贡献源 (CSRC) 信息和头部扩展。

3.3. 编解码器特定的带内 FEC​

一些音频编解码器，特别是 Opus [RFC6716] 和自适应多速率 (AMR) [RFC4867]，支持自己的带内 FEC 机制，其中冗余数据包含在编解码器载荷中。这类似于上述冗余编码机制，但由于它不添加任何额外的帧，因此可能稍微更高效。

对于 Opus，被认为重要的音频帧会以较低的比特率重新编码并附加到下一个载荷中，允许部分恢复丢失的数据包。这个方案相当高效；实验表明，当使用 Opus FEC 时，施加的开销仅约为 20-30%，具体取决于所需的保护量。请注意，这种机制只能携带紧接在前面的音频帧的冗余信息；因此解码器无法完全恢复多个连续丢失的数据包，这在无线网络上可能是个问题。有关更多详细信息，请参见 [RFC6716] 第 2.1.7 节和 Opus 邮件列表帖子 [OpusFEC]。

对于 AMR 和 AMR-Wideband (AMR-WB)，数据包可以包含多个先前音频帧的副本或低质量编码。有关此机制的详细信息，请参见 [RFC4867] 第 3.7.1 节。

带内 FEC 机制无法恢复 RTP 头部的任何部分。

4. 音频内容的 FEC​

以下部分提供了关于如何最佳使用 FEC 传输音频数据的指导。如下面第 8 节所述，只有在网络条件需要时，或应用程序明确请求时，才应激活 FEC。

4.1. 推荐机制​

当使用没有内部 FEC 的可变比特率编解码器时，建议 (RECOMMENDED) 使用冗余编码（如第 3.2 节所述），使用先前数据包的低保真版本。这提供了对载荷的合理保护，比特率增加适中，因为冗余编码可以明显小于主编码。

当使用 Opus 编解码器时，建议 (RECOMMENDED) 使用内置的 Opus FEC 机制。这提供了对音频流的合理保护，以防止单个丢失，开销最小。请注意，如上所述，内置 Opus FEC 仅提供单帧冗余；如果需要多数据包保护，应 (SHOULD) 使用上述采用降低比特率 Opus 编码的冗余编码。

当使用 AMR/AMR-WB 编解码器时，建议 (RECOMMENDED) 使用它们的内置 FEC 机制。这比冗余编码提供了稍微更高效的音频流保护。

当使用恒定比特率编解码器（例如 PCMU [RFC5391]）时，可以 (MAY) 使用冗余编码，但这将导致比特率可能大幅增加，并且突然增加比特率以应对拥塞造成的丢失实际上可能会使情况变得更糟。

由于音频编码的数据包速率较低（通常每帧一个数据包），使用独立 FEC 流的开销高于其他机制，因此不建议 (NOT RECOMMENDED)。

如上所述，推荐的机制不允许恢复 RTP 头部的某些部分，这些部分在某些音频应用中可能很重要，例如 CSRC 和 [RFC6464] 和 [RFC6465] 中规定的 RTP 头部扩展。实现应该 (SHOULD) 考虑到这一点，并尝试使用类似于 [RFC2198] 第 4 节和 [RFC6464] 第 5 节所述的方法来近似这些信息。

4.2. 协商支持​

对给定 RTP 流的冗余编码支持应该 (SHOULD) 通过在 SDP offer [RFC3264] 中相关 "m=" 部分包含 audio/red [RFC2198] 作为附加支持的媒体类型来指示。应答者可以通过在 SDP answer 中相应的 "m=" 部分不包含 audio/red 媒体类型来拒绝使用冗余编码。

对编解码器特定 FEC 机制的支持通常通过 "a=fmtp" 参数指示。

对于 Opus，接收方必须 (MUST) 使用 "useinbandfec=1" 参数指示它已准备好使用传入的 FEC 数据，如 [RFC7587] 中所规定的。此参数是声明性的，可以针对任一媒体方向单独协商。

对于 AMR/AMR-WB，对冗余编码的支持以及支持的最大深度由 "max-red" 参数控制，如 [RFC4867] 第 8.1 节所规定的。接收方必须 (MUST) 包含此参数，并将其设置为适当的值，如 [TS.26114] 表 6.3 中所规定的。

5. 视频内容的 FEC​

以下部分提供了关于如何最佳使用 FEC 传输视频数据的指导。如下面第 8 节所述，只有在网络条件需要时，或应用程序明确请求时，才应激活 FEC。

5.1. 推荐机制​

视频帧由于其大小，通常需要多个 RTP 数据包。如上所述，独立 FEC 流可以用单个 FEC 数据包保护多个数据包。此外，[RFC8627] 中描述的灵活 FEC 机制还能够通过单个 FEC 流保护多个 RTP 流，包括属于 BUNDLE 组 [RFC8843] 的所有流。因此，对于视频内容，建议 (RECOMMENDED) 使用采用灵活 FEC RTP 载荷格式的独立 FEC 流。

为了处理传入的 FEC 流，接收方可以通过 SSRC 对其进行解复用，然后通过灵活 FEC 修复数据包的 RTP 头部中存在的 CSRC，或灵活 FEC 重传数据包的 FEC 头部中存在的 SSRC 字段，将其与适当的主流相关联。

5.2. 协商支持​

对保护给定 RTP 流的 SSRC 多路复用灵活 FEC 流的支持应该 (SHOULD) 通过在 SDP offer [RFC3264] 中相关 "m=" 部分包含 video/flexfec（如 [RFC8627] 第 5.1.2 节所述）作为附加支持的媒体类型来指示。如上所述，当使用 BUNDLE 时，即使为每个主流协商了灵活 FEC，也只会为每个 BUNDLE 组创建一个灵活 FEC 修复流。

应答者可以通过在 SDP answer 中相应的 "m=" 部分不包含 video/flexfec 媒体类型来拒绝使用 SSRC 多路复用 FEC。

使用仅 FEC 的 "m=" 行，以及如 [RFC5956] 第 4.1 节所述使用 SDP 组机制进行分组，目前未为 WebRTC 定义，不应 (SHOULD NOT) 提供。

应答者应该 (SHOULD) 拒绝任何仅 FEC 的 "m=" 行，除非他们特别知道如何在 WebRTC 上下文中处理这种情况（可能由 WebRTC 规范的未来版本定义）。

6. 应用内容的 FEC​

WebRTC 还支持发送通用应用数据的能力，并提供传输级重传机制以支持完全和部分（例如，定时）可靠性。有关详细信息，请参见 [RFC8831]。

由于应用程序可以精确控制要发送的数据，它能够监控数据包统计信息并在必要时执行自己的应用级 FEC。

因此，本文档不对底层数据传输的 FEC 提出建议。

7. 实现要求​

为了支持上述推荐的功能，实现必须 (MUST) 能够接收并使用其支持的音频编解码器的相关 FEC 格式，并且必须 (MUST) 如第 4 节所述指示此支持。如上所述，建议 (RECOMMENDED) 在发送时使用这些格式。

如第 5 节所述，也应该 (SHOULD) 支持 [RFC8627] 中描述的通用 FEC 机制。

如果需要，实现可以 (MAY) 支持其他 FEC 机制，例如 [RFC5109]。

8. FEC 的自适应使用​

由于使用 FEC 总是会导致传输冗余数据，并且数据总量必须保持在拥塞控制和接收方指示的任何带宽限制内，这将导致主编码可用的带宽减少，即使冗余数据未被使用。这与 RTX [RFC4588] 或灵活 FEC 的重传模式（[RFC8627] 第 1.1.7 节）等方法形成对比，后者仅在必要时传输冗余数据，代价是额外的往返行程，从而增加了媒体延迟。

鉴于此，当连接 RTT 在应用程序的延迟预算内时，WebRTC 实现应该 (SHOULD) 优先使用 RTX 或灵活 FEC 重传而不是 FEC，否则应该 (SHOULD) 只传输保护观察到的丢包所需的 FEC 量（可以通过监控来自 RTP 控制协议 (RTCP) 接收方报告 [RFC3550] 的传输丢包数据来确定），除非应用程序表示它愿意付出质量代价来主动避免丢失。

请注意，在探测带宽时，即投机性地发送额外数据以确定是否存在额外的链路容量，应该 (SHOULD) 使用 FEC 数据作为额外数据。鉴于无论如何都要发送额外数据，让这些数据保护主载荷是有意义的；此外，FEC 通常可以以仅适度增加带宽的方式应用，这在探测时是必要的。

当使用带有分层编解码器的 FEC 时，例如 [RFC6386]，其中只有基础层帧对于未来帧的解码至关重要，实现应该 (SHOULD) 只将 FEC 应用于这些基础层帧。

最后，应该注意的是，尽管应用冗余通常有助于保护流免受丢包的影响，但如果丢失是由网络拥塞引起的，冗余数据使用的额外带宽实际上可能会使情况变得更糟，并可能导致网络显著退化。

9. 安全考虑​

在 WebRTC 上下文中，FEC 专门关注从丢失的数据包中恢复数据；任何损坏的数据包都将在安全实时传输协议 (SRTP) [RFC3711] 解密过程中被丢弃。因此，如 [RFC3711] 第 10 节所述，使用 FEC 与 SRTP 时的默认处理是在发送方先执行 FEC 再执行 SRTP，在接收方先执行 SRTP 再执行 FEC。此顺序用于 DTLS-SRTP [RFC5763] 中使用的所有 SRTP 保护配置文件，这些配置文件在 [RFC5764] 第 4.1.2 节中列举。

每个单独 FEC 机制的其他安全考虑在其各自的文档中列举。

10. IANA 考虑​

本文档不需要 IANA 采取任何行动。

11. 参考文献​

11.1. 规范性参考文献​

[RFC2119] [RFC2198] [RFC3264] [RFC4867] [RFC5956] [RFC7587] [RFC8174] [RFC8627] [TS.26114]

11.2. 信息性参考文献​

[OpusFEC] [RFC3550] [RFC3711] [RFC4588] [RFC5109] [RFC5391] [RFC5763] [RFC5764] [RFC6386] [RFC6464] [RFC6465] [RFC6716] [RFC8831] [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]

Copyright (c) 2021 IETF Trust 及文档作者。保留所有权利。

本文档受 BCP 78 以及 IETF Trust 关于 IETF 文档的法律规定（在本文档发布之日生效）的约束。请仔细阅读这些文档，因为它们描述了您对本文档的权利和限制。