由 WebRTC 支持的实时通信应用必须经常应对不可预测的网络条件，这些条件可能导致数据包丢失、抖动和音频质量下降。为了缓解这些问题，WebRTC 实现可以利用一种称为冗余音频数据 (RED) 的技术。这种方法通过提供备份数据来增强音频可靠性，当主数据包在传输过程中丢失时，可以使用备份数据。在本文中，您将了解 RED 在 WebRTC 生态系统中的工作原理、实现方式、优缺点以及何时最适合使用该技术。
了解 RED（冗余音频数据）
RED 即 Redundant Audio Data（冗余音频数据）。RED 背后的理念是在RTP流中以多个有效载荷传输相同的音频信息。如果主音频数据有效载荷在传输过程中丢失或损坏，接收方可以使用质量较低的冗余信息来替换缺失或损坏的部分，从而提高音频流的整体质量和完整性。
RED 不是 RTP 的核心功能，而是一种可选的附加功能，用于提升音频质量，尤其是在不可靠的网络条件下。RED 最初是在 1997 年通过RFC 2198提出的，在 RTP 中默认不启用，因为它会消耗额外的带宽（对于 20ms/48 kHz 的 Opus，带有一个冗余副本，大约需要额外消耗 15-35 kbps 的带宽）。它通常用于对音频质量要求较高或网络状况难以预测的情况下。
RED 的工作原理
RED 机制遵循以下关键步骤。
1. 编码：
- 使用 Opus 等编解码器对原始音频数据包进行编码。
- 创建一个或多个冗余副本。在 Chrome 浏览器的实现中，RED 并没有进行完整的二次编码，而是将前一帧的 Opus-LBRR（前向纠错）封装在 RED 标头内，这比完全冗余编码更高效，带宽提升约 1.7 倍。
- Chrome 仅为 20 毫秒的 Opus 帧中插入 LBRR；如果强制使用 10 毫秒的
ptime，RED 将携带一个完整的辅助帧。
2. 打包：
- 原始数据包及其冗余数据使用 RED 格式捆绑到单个 RTP 数据包中；
- 数据包内的RED标头指示冗余数据的属性。
3. 传播：
- 带有 RED 有效载荷的 RTP 数据包通过网络发送
4. 接收：
- 接收端首先尝试解码原始数据包；
- 如果原始数据包丢失或损坏，接收端会尝试解码冗余数据；
- 接收端使用第一个成功解码的数据包，丢弃其他数据包。
RED 数据包结构
实施 RED 时，RTP 数据包结构会进行修改，以包含冗余数据：
根据 RFC 2198，RED 会为每个冗余块增加 4 个字节（隐含 1 字节主数据块标头）。因此，如果只有一个冗余副本，开销就是 4 个字节，而不是有时错误表述的 6 个字节。
由于 RTP 中默认没有定义 RED，因此需要有一种方法来传达 RTP 数据包中的动态有效载荷包含冗余数据。SDP（会话描述协议）包含使用 RED 的信息，并被添加为额外的有效载荷类型。
SDP 中的 rtpmap 属性可定义特定的编解码器、采样率和声道数。其使用示例如下：
m=audio 12345 RTP/AVP 121 0 5
a=rtpmap:121 red/8000/1RED 的优缺点及最佳实践
优点
- 提高音频质量：冗余有助于减轻数据包丢失的影响，从而产生更清晰、更一致的音频。
- 减少伪影：使用 RED 时，音频伪影（如咔嗒声、爆音和失真）不太明显。
- 增强的用户体验：即使在具有挑战性的网络条件下，听众也能体验到更流畅、更可靠的音频。
- 优雅降级：在网络压力下，音频质量会更加优雅地下降。
缺点
- 增加带宽消耗：发送音频数据的冗余副本会消耗额外的带宽。对于包含一个冗余副本的 20ms/48kHz Opus 数据包，通常每个数据包会额外增加 44 字节（4 字节 RED 报头 + 40 字节 Opus-LBRR），相当于约 17.6 kbps。考虑到报头压缩（包括 SRTP 报头 + 未压缩的 RTP/UDP/IP 报头），在每秒 50 个数据包的链路上，总开销会增加约 21-22 kbps。
- 潜在延迟影响：处理和传输额外的音频数据会增加整体处理负载，从而可能增加延迟。
- 实现复杂度：在混合转发场景下需要特殊处理。
- 编解码器兼容性：并非所有编解码器都同样支持 RED，因此在实施过程中需要仔细考虑。
使用 RED 的最佳实践
- 选择性应用：仅在网络条件允许的情况下使用 RED
- 自适应冗余：根据观察到的数据包丢失情况调整冗余级别
- 带宽意识：启用 RED 之前考虑可用带宽
- 后备策略：为不支持 RED 的客户准备替代方案
- 监控：跟踪 RED 使用情况对带宽和质量指标的影响
音频可靠性的替代方法
虽然 RED 显著提升了音频质量，但它并非提升 WebRTC 音频可靠性的唯一方法。其他补充或替代技术包括：
前向纠错（FEC）
许多现代音频编解码器（例如 Opus）都包含自己的纠错机制。例如，Opus 包含带内 FEC，无需完整的冗余数据包即可从丢包中恢复。这种方法比 RED 更节省带宽，但在严重丢包的情况下可能效果不佳。
丢包隐藏 (PLC)
先进的 PLC 算法可以合成音频来填补数据包丢失造成的间隙。这些技术非常适合短间隙，并且可以补充 RED，处理冗余数据丢失的情况。
抖动缓冲
抖动缓冲区有助于平滑数据包到达时间的变化，从而减少网络抖动对音频质量的影响。自适应抖动缓冲区可以根据网络状况动态调整其大小。
结论
本文介绍了 RED 相关概念、工作原理及优缺点等知识点。虽然 RED 会增加带宽使用量，但它能在主数据包丢失时提供后备数据，从而显著改善具有挑战性的网络环境中的音频质量。
对于开发音频质量至关重要的应用的 WebRTC 开发人员来说，了解何时以及如何实施 RED 是一项重要技能。通过仔细平衡带宽使用和提高可靠性之间的权衡，您可以创建即使在不理想的网络条件下也能保持稳健的实时通信体验。
当然，这对 WebRTC 开发者有较高的要求。您可以了解 ZEGO 的实时音视频RTC，80% 极端丢包情况下也可保持流畅音频通话，注册即可免费体验。可大大节省您的开发时间，为您的应用实现高质量的 RTC 体验。
