修复下行链路 FEC 速率计算因未恢复的上行链路包丢失而受到污染

背景

在 mediasoup 的 SFU 架构中，用于驱动 FEC 多余的下行链路丢失分数来自下行链路用户向服务器发送的 RTCP 接收器报告。该报告反映了 mediasoup 将数据包转发给用户后的数据包丢失情况。
然而，mediasoup 传输的数据包来自发布者发送的上行链路 RTP 流。如果上行链路上丢失了数据包且未恢复（例如，NACK 失败），mediasoup 根本没有数据包可传输 — 这些序列号从未发送到下行链路。

问题

下行链路 RR 的 fractionLost 和 totalLost 由用户根据接收到的序列号间隔计算。当 mediasoup 跳过一个序列号，因为上行链路的数据包从未收到时，用户会看到一个间隔并将其计为丢失 — 与真实的下行链路丢失无异。

这意味着，传递到 UpdateProtectionParameters() 在 RtpStreamSend 中的 fractionLost 会被上行链路丢失所扩大：

• packetsLost = report->GetTotalLost();
• fractionLost = report->GetFractionLost(); // ← 包含上行链路丢失污染

后果

• 对于上行链路丢失，FEC 多余会被增加，而 FEC 在下行链路上无法修复
• 下行链路 FEC 数据包消耗带宽，但对来自上行链路的间隔没有任何恢复效益