WebRTC SFU的职责之一是接收和发送RTCP数据包。RTCP数据包包括关于音频和视频流的不同类型的反馈，并且最重要的RTCP数据包是接收器报告(RR).
RR数据包从媒体流接收器发送到该媒体流的发送者。在SFU的情况下，RR由SFU产生，并发送到媒体流发送器，并且还从每个流接收器发送到SFU。(如图1)。
RR数据包内发送的反馈包括用于计算网络引入的往返时间延迟，抖动和信息丢失。
这些RR数据包中报告的数据包丢失很重要，因为发送的音频和视频将根据该参数进行调整：
- 在音频流的情况下，网络中的数据丢失修改了OPUS编解码器的强度级别。在存在很多数据丢失的情况下，发送器增加包括在音频分组中的前向纠错(FEC)的冗余级别。
- 在视频流的情况下，数据丢失修改编码和发送的视频比特率。在存在大量数据丢失的情况下，发送方降低发送比特率以减少网络中可能的拥塞。
基于该行为，问题是……SFU如何计算从SFU发送到发送方的RR报文中报告的丢包，以获得最佳用户体验？
在接下来的部分，您可以找到有关如何在三种不同类型流中处理此问题的建议:音频，带有联播的视频，和没有联播的视频。
音频
Opus FEC是带内发送的，因为FEC是端到端的(不能在SFU中添加/更新)，并且会议室中的每个人将获得相同等级的FEC。
如果我们希望音频FEC能够很好地为具有最弱链接的参与者工作，那么我们必须确保向发送方报告最糟糕的数据包丢失。
因此，从SFU向发送方报告的丢包应该是接收方的较差分组(max(PL1, PL2)).
例如，如果其中一个接收参与者在下行链路中遇到20%的数据丢失，则报告给发送方的数据丢失将会是20%,即使发送方和其余接收方处于完美的网络状态。
带有联播的视频
使用联播时，SFU能够向每个参与者发送不同的视频质量，因此不需要使发送流适应任何特定参与者。
因此，从SFU向发送方报告的丢包应该是该链路(发送方-SFU)的丢包，无论收到的丢包是什么，对于接收方1和2都是如此。
例如，如果发送方上行链路良好，即使接收方在下行链路中遇到大量丢包，报告给发送方的丢包也将为0.通过选择要转发给那些参与者的较低分辨率/层，可以通过在SFU中完成的重新传输和比特率自适应来纠正这一点。
无联播的视频
无联播时，SFU必须向每个参与者发送相同的视频质量。因此，发送者使用最弱的链接调整发送比特率并发送给参与者(和/或禁用某些参与者的视频)。
该比特率自适应主要由REMB RTCP数据控制，其中SFU包括在较差接收器中可用的带宽。但是丢包也会对REMB数据包中报告的比特率产生影响，因此我们需要确定要在RR数据包中包含哪些数据包丢失。
在这种情况下，我认为前面几节中描述的两种方法都可以很好的工作。或者a)SFU报告最差的接收器的丢包率，或者b)使用每个接收器的丢包估其带宽，并仅报告RR数据包中的发送方一侧丢包。
注意：如果您在房间中有2个参与者时使用P2P连接，并且当房间中有3个或更多参与者时，切换到具有联播的SFU，那么你应该从不在此视频中使用No-Simulcast和多个参与者案例。
原文标题：WebRTC SFU中发送数据包丢失反馈
