使用级联SFU改善媒体质量和规模
在多用戶視頻會議媒體服務器的部署中采用級聯結構可有效降低端到端的媒體延遲，改善媒體質量。來自Jitsi團隊的Boris Grozev深入描述了級聯SFU問題，并展示了他們的方法以及他們遇到的一些挑戰。LiveVideoStack對文章進行了翻譯，感謝WebRTC專家劉連響的技術審校。
文 / Boris Grozev
譯 / 元寶
審校 / 劉連響
原文 https://webrtchacks.com/sfu-cascading/
部署WebRTC媒體服務器有兩個主要挑戰，一個是擴展到多個服務器，另一個是優化會議中所有用戶的媒體延遲。雖然像“將會議X中的所有用戶發送到服務器Y”這樣的簡單分片方法很容易橫向擴展，但就媒體延遲而言，它們遠不是最佳的，而媒體延遲是用戶體驗的關鍵因素。將會議分發到位于用戶附近并在可靠骨干網上相互連接的服務器，可以同時解決這兩個問題。來自Jitsi團隊的Boris Grozev深入描述了級聯SFU問題，并展示了他們的方法以及他們遇到的一些挑戰。
?“老鼠的神經元”，圖片來自NIHD（CC-BY-2.0）
實時通信應用程序對吞吐量、延遲和丟包等網絡條件非常敏感。較低的比特率會導致較低的視頻質量，更長的網絡延時會導致端到端的音視頻延遲, 數據丟包會引起音頻的不連貫以及視頻的卡頓。
因此，在會議中選擇端點之間的最佳路徑非常重要。當只有兩個參與者時，這就比較簡單了——WebRTC使用ICE協議在兩個端點之間建立連接以交換多媒體。如果可能，兩個端點直接連接，否則在不太典型的情況下使用TURN中繼服務器。WebRTC支持解析域名以獲取TURN服務器地址，這使得可以輕松地選擇基于DNS的本地TURN服務器，例如使用AWS Route53的路由選項。
但是，當一個會議有更多的參與者通過中央媒體服務器路由時，情況就復雜得多。許多WebRTC服務，如Hangouts，seem.in，Slack和我們自己的meet.jit.si，使用選擇性轉發單元（SFU）來更有效地在3個或更多參與者之間傳遞音頻和視頻。
星形拓撲問題
在這種情況下，所有端點都連接到一個中央服務器（采用星形拓撲結構），與之交換多媒體。很明顯，選擇服務器的位置會對用戶體驗產生巨大影響——如果會議中的所有參與者都位于美國，這時候使用一臺在悉尼的服務器就不是一個好的主意。
大多數服務使用一種在很多時候都能很好地運行的簡單方法——它們選擇靠近會議中第一個參與者的服務器。但是，在某些情況下，這并不是最優的。例如，假設我們有三個參與者，如上圖所示，其中兩個位于美國東海岸，第三個是在澳大利亞。如果澳大利亞參與者（來電者C）首先加入會議，則此算法選擇澳大利亞的服務器（服務器2），但美國的服務器1是更好的選擇，因為它更接近大多數參與者。
諸如此類的場景并不常見，但確實會發生。假設參與者加入的順序是隨機的，這種情況發生在有3名參與者的會議中,其中一個是在一個偏遠的位置。?
另一種更常發生的情況如下圖所示：我們在兩個地點有兩組參與者。在這種情況下，加入的順序無關緊要，我們將始終擁有一些彼此接近的用戶，但他們的媒體必須通過遠程位置的服務器。例如，在下圖中，有2名澳大利亞來電者（C＆D）和2名美國來電者（A＆B）。
切換到服務器1對于呼叫者C和D來說不是最佳的選擇。對于呼叫者A和B，服務器2不是最佳的選擇。無論我們使用服務器1還是服務器2，都會有一些參與者通過非最佳遠程服務器連接。
如果我們不限于使用一臺服務器呢？我們可以讓每個參與者都連接到本地服務器，我們只需要互連服務器。
解決方案：級聯
稍后再說我們如何實際互連服務器的問題，讓我們首先看看它對會議的影響。
從C到D的SFU連接沒有改變——仍然通過服務器2。對于A和B之間的連接，我們使用服務器1而不是服務器2，如上圖所示，這顯然更好。有趣的部分實際上是從A到C（或任何其他效果類似的連接）的連接。我們使用A <=>服務器1 <=>服務器2 <=> C而不是使用A <=>服務器2 <=> C.
非直連傳輸時間影響
像這樣連接SFU網橋既有優點也有缺點。一方面，我們的研究結果表明，在這種情況下當我們添加額外的跳數時，端到端往返時間會更高。另一方面，減少從客戶端到它連接的第一個服務器的往返時間本身就具有優勢，因為我們可以在逐跳基礎上以更低的延遲執行流修復。
這是如何運作的？WebRTC使用RTP（通常通過UDP）傳輸媒體。這意味著運輸不可靠。當UDP數據包在網絡中丟失時，由應用程序決定是忽略/隱藏丟失，還是使用RTCP NACK數據包請求重傳。例如，應用程序可能選擇忽略丟失的音頻數據包，并請求一些但不是全部視頻數據包的重傳（取決于它們是否需要解碼后續幀）。
使用單個服務器的RTP數據包重新傳輸
使用級聯橋接器，這些重傳可以限于本地服務器。例如，在A-S1-S2-C路徑中，如果包在A和S1之間丟失，則S1將通知并請求重傳。如果在S2和C之間丟失數據包，C將請求重傳，S2將從其高速緩存中響應。如果兩個服務器之間丟失數據包，則接收服務器可以請求重傳。
使用兩臺服務器進行RTP數據包重傳。請注意，服務器2不會重新傳輸數據包2，因為NACK在數據包發送后很快就會到達。
客戶端使用抖動緩沖器來延遲視頻的播放，以便允許延遲或重傳的數據包到達。此緩沖區的大小部分基于往返時間動態變化。當逐跳執行重傳時，延遲較低，因此抖動緩沖區可以更短，從而降低整體延遲。
簡而言之，盡管使用額外的服務器，端到端往返時間會更高，但可以使得端到端媒體延遲降低(但我們還沒有在實踐中探索這種影響)。
實現級聯SFU
那么我們如何在Jitsi Meet中實現它，以及如何在meet.jit.si上部署它？
信號與媒體
讓我們先看看信號。從一開始，Jitsi Meet就將信令服務器（現在是Jicofo）和媒體服務器/ SFU（jitsi-videobridge）的概念分開。這種分離允許我們相對容易地實現對級聯橋的支持。首先，我們可以將所有信號邏輯保持在一個中心位置——Jicofo。其次，我們已經擁有了Jicofo和Jitsi Videobridge（COLIBRI）之間的信令協議。我們只需要為它添加一個小擴展。我們已經支持連接到一個信令服務器的多個SFU（用于負載平衡）。現在我們必須為一個SFU添加選項以連接到多個信令服務器。
我們最終得到了兩個獨立的服務器池——一個jicofo實例池和一個jitsi-videobridge實例池。下圖說明了部分內容。
AWS上的Jitsi Meet Setup示例允許跨不同數據中心進行橋接級聯
我們系統的第二部分是橋到橋通信。我們希望保持這部分盡可能簡單，因此我們決定不在橋之間做任何明確的信號傳遞。所有信令都發生在jicofo和jitsi-videobridge之間，兩個網橋之間的連接僅用于來自客戶端的音頻/視頻和數據信道消息。
Octo協議
為了協調這種通信，我們提出了Octo協議，它將RTP數據包封裝在一個簡單的固定長度報頭中，并允許傳輸字符串消息。在當前的實現中，橋接器以全網狀連接到彼此，但是該設計也允許其他拓撲。例如，使用中央中繼服務器（橋的星形）或為每個橋使用樹結構。
腳注：請注意，不是預先添加Octo標頭，而是可以將其添加為RTP標頭擴展，使網橋之間的流成為純RTP。未來版本的Octo可能會使用這種方法
第二個腳注：Octo并不真正代表什么。我們最初計劃使用中央繼電器，出于某種原因，它讓我們想起了一只章魚，所以我們為這個項目保留了這個名字。
Octo標題格式
在Jitsi Videobridge術語中，當橋接器是多橋會議的一部分時，它有一個額外的Octo通道（實際上是一個音頻通道和一個視頻通道）。該通道負責將媒體轉發到所有其他網橋，以及接收來自所有其他網橋的媒體。每個網橋綁定到Octo的單個端口（默認為4096），這就是為什么我們需要會議ID字段能夠同時處理多個會議。
目前，該協議沒有自己的安全機制，我們將這個責任委托給更低的層。這是我們希望接下來要做的事情，但目前橋梁需要在一個安全的網絡中（我們使用單獨的AWS VPC）。
與Simulcast一起使用
Jitsi Meet的一個顯著特征是支持 simulcast ?，其中每個參與者發送多個不同比特率的流，并且橋幫助選擇所需的比特。我們希望確保它繼續穩健地工作，因此我們轉發橋之間的所有聯播流。這允許在流之間更快地切換（因為本地橋不必請求新流）。但是，它在橋到橋流量方面并不是最優的，因為有些流通常不會被使用，只是消耗額外的帶寬而沒有任何好處。
活躍發言人選擇
我們還希望繼續支持會議中的活躍發言人。事實證明這很簡單——我們只是讓每個橋接器獨立地進行主導說話人識別，并通知其本地客戶端（這也是其他人使用過的方法）。這意味著計算需要多次完成，但它并不昂貴，并且允許我們簡化事情（例如，我們不必決定哪個橋接DSI，并且擔心路由消息）。
橋的選擇
通過當前的實現，橋的選擇算法很簡單。當新參與者加入時，Jicofo需要決定分配給它的橋。它是基于客戶端的區域以及可用橋梁的區域和負載來實現的。如果在與客戶端相同的區域中存在可用的橋，則使用它。否則，使用現有的一個會議橋。
有關設置Octo的文檔，請參見此處（https://github.com/jitsi/jitsi-videobridge/blob/master/doc/octo.md）。
部署級聯SFU
我們現在已經在meet.jit.si上啟用了地理橋級聯，如上所述。
對于此部署，我們在Amazon AWS中運行所有計算機。我們在六個地區擁有服務器（信令和媒體）：
? us-east-1（弗吉尼亞北部），
? us-west-2（俄勒岡州），
? eu-west-1（愛爾蘭），
? eu-central-1（法蘭克福），
? ap-se-1（新加坡），
? ap-se-2（悉尼）。
我們使用一層 ?地理定位的HAProxy實例 ?來幫助確定客戶端來自哪個區域。meet.jit.si域由Route53管理并解析為HAProxy實例，該實例將其自己的區域添加到它轉發的請求的HTTP頭。然后這個頭用于設置變量 config.deploymentInfo.userRegion的值，這個值通過/config.js文件提供給客戶端 。
對于診斷和演示此功能，meet.jit.si上的用戶界面顯示了正在使用的橋數以及每個參與者連接的位置。本地縮略圖的左上角部分滾動顯示服務器數量以及所連接服務器的區域。滾動遠程縮略圖會顯示遠程參與者所連接的服務器區域，以及瀏覽器與他們之間的端到端往返時間（如E2E RTT）。
您可以通過檢查Jitsi Meet中每個人的連接位置來查看是否正在使用橋接級聯。
結論
我們最初是在8月份，在meet.jit.si上推出了Octo作為A / B測試。初步結果看起來不錯，現在每個人都可以使用。我們需要處理大量數據，我們計劃詳細了解Octo的執行情況并撰寫更多相關信息。我們還計劃將這項工作作為支持大型會議的第一步（單個SFU是不夠的）。所以在接下來的幾個月里，請繼續關注這方面的更多內容。
精品文章推薦
技術趨勢：
UDP成為低延時流媒體關鍵 選SRT還是QUIC？
BBR如何讓Spotify流媒體更流暢？
CMAF將在2019年得到快速發展
VMAF：未畢之旅
技術干貨：
基于HLS格式的低延時互動直播技術
FFmpeg在Intel GPU上的硬件加速與優化
編解碼器之戰：AV1、HEVC、VP9和VVC
下一代低延時直播CDN：HLS、RTMP 與UDP +WebRTC
《周四橄欖球之夜》流媒體視頻拆解：Twitch VS Amazon Prime
總結
以上是生活随笔為你收集整理的使用级联SFU改善媒体质量和规模的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： LiveVideoStackCon音视频
- 下一篇： 音视频技术开发周刊 76期