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和多個參與者案例。

本文首發於由聲網 Agora 贊助運營的 WebRTC 中文網