著名的開源視頻會議服務器開發(fā)商Jitsi的核心開發(fā)人員Boris Grozev和他的團隊利用了更加智能的方式Cascading SFUs的方式處理語音時時延問題，通過對比測試，測試結果取得了比較好的效果。Cascadiing（串聯？） SFU的實現來自于基本的網絡資源查詢的原理，就是通過算法路由到距離客戶最近的媒體服務器。以下內容是官方開發(fā)人員的具體介紹，更多完整文檔參考文章鏈接。

　　現在的很多語音業(yè)務和會議服務器都部署在云端，用戶則可能部署在世界各地，網絡的穩(wěn)定性會嚴重影響語音質量，時延，抖動，丟包，或者視頻影像不清晰等問題。因此，在用戶用戶之間選擇一個最佳的媒體路徑是非常至關重要的。在WebRTC的環(huán)境中，有時是用戶之間通過ICE 或者TRUN 來實現，這種場景事實上是非常簡單的場景，可以支持少量用戶的視頻會議。但是，如果視頻會議人數很多的時候，一個單點服務器很難處理大量用戶的會議場景。因此，使用一種智能的方法，例如SFU是非常有必要的。下面介紹兩種方式的處理機制和其策略，以及測試結果的優(yōu)化。

　　首先，讓我們看看使用Star的 處理方式，如果三個用戶在不同的地方，他們需要實現視頻會議的話，可能需要經過兩個服務器的處理流程，同時每個呼叫方都需要和另外兩個互相連接，而且會議中的成員加入的順序不同，可能導致連接錯誤或者無效的連接，這樣就會浪費很多服務器和網絡資源，如下圖例所示，可能用戶A和用戶B都連接了服務器 2 而不是服務器1。

　　讓我們看看如何使用串聯的方式來解決智能選擇路由和服務器的方式。通過串聯的方式來處理的話，用戶A 就會通過服務器1，然后對接服務器2，呼叫服務器2的用戶C。這樣的話，兩臺服務器就會被充分利用，減少了資源浪費。

　　連接SFU的橋接有其優(yōu)勢也有其劣勢。其劣勢是增加了多個跳轉，但是如果進行了優(yōu)化以后，大大減少了語音數據的往返時延。關于此策略的實現，參考鏈接論文有詳細介紹。對于WebRTC來說，通常情況下使用RTP來傳輸數據，其本身具有不可靠性。如何實現視頻的重新傳輸也是一個很大的挑戰(zhàn)。使用單機服務器的往返時延如下，需要多次不同對象的處理。

　　使用SFU橋接的往返時間的話，重新傳輸僅限于本地服務器傳輸。例如，如果丟包發(fā)生在用戶A和服務器1之間，服務器1要求用戶A重傳。如果丟包發(fā)生在用戶C和服務器2之間，服務器2則要求用戶C之間重傳；如果兩個服務器之間發(fā)生丟包，則要求兩個服務器之間重傳數據包。用戶終端可以通過設置jitter buffer來緩存視頻播放。根據作者結論，理論上來說，雖然，端對端的整個往返時間長于外部服務器部署方案的時間，但是端對端的時延降低。

　　剛才我們討論了串聯SFU的好處和對說延的正面影響。現在討論一下如何部署基于Jitsi的視頻會議解決方案。具體解決方案查閱Jitsi 官方網站。

　　在部署串聯SFU的環(huán)境中，除了技術架構的調整以外，Jitisi還使用了其他的協議和優(yōu)化手段來進一步實現SFU的性能優(yōu)化。具體的方法包括：

　　為了能夠網站客觀地測試SFU的橋接方式，用戶使用亞馬遜云平臺，對接機構地區(qū)的云服務器進行傳輸測試，測試結果比較滿意。

　　總結，通過SFU 橋接方式可以提高SFU 視頻會議服務器的媒體質量，同時可以增加SFU 視頻會議服務器的拓展性�？朔�人員準備在最近的版本發(fā)布中做進一步的測試。

　　注：以上文檔是筆者翻閱以便作為技術學校的資料，用戶可以參考官方原文做進一步研究。

　　https://webrtchacks.com/sfu-cascading/

　　https://jitsi.org/wp-content/uploads/2018/11/ccwc2018-geo.pdf