文｜網易智慧企業流媒體服務器天團

?

導讀：疫情期間，視頻會議等遠程辦公產品備受青睞，眾多互聯網玩家切入視頻會議市場，加劇市場競爭。但是，產品雖多，能夠帶來穩定可靠體驗的產品卻鳳毛麟角，它的難點在哪里？視頻會議的門檻到底有多高，又能夠做到怎樣的極致體驗？網易智慧企業流媒體服務器天團將會從0到1，和大家分享如何基于WebRTC來搭建一個視頻會議。

?

入門篇

先請出我們今天的主角 - WebRTC，它是由谷歌推廣的實時音視頻技術棧，是音視頻領域搜索熱度最高的技術。它有多重身份，既是W3C的標準，也是一個開源項目，還有一個對應的IETF工作組(RTCWEB)。在WebRTC出現之前，音視頻通信是高不可攀的領域，需要大量的專業積累才能入門，而現在，越來越多的開發者通過WebRTC來深入了解RTC技術。

WebRTC技術的本質是構建點對點的實時通信，目前主流的瀏覽器，包括Chrome, Firefox, Edge等，天然就支持WebRTC協議。對入門開發者來說，選用這幾款瀏覽器，連開發客戶端的時間都省了。最簡單的Web視頻會議，只需要架設一個Web服務器，服務器兼具信令交換的能力(信令服務也可以獨立部署)，兩個瀏覽器通過Web Server交換會話信息，就能建立P2P通道來傳輸媒體流，進行1v1的視頻會議。如下圖所示。

?

兩個瀏覽器向Web服務器請求頁面，并進行SDP交換，然后在瀏覽器之間直接建立P2P Transport，進行媒體流傳輸。這是最簡單的WebRTC應用形式。

這種簡單的媒體流直聯的方式，線上有很多教程，也可以參考WebRTC的demo (https://webrtc.github.io/samples/)，這里不展開。

如果拓展到多方的視頻會議，架構是這樣的：

?

可以看到，這種”簡單”的視頻會議，有兩個風險點：

P2P在兩個客戶端之間建立，不可避免的涉及到NAT穿透的問題，打洞的成功率直接影響P2P的可用性，在會議場景是不能接受的。

在多人場景下，本地的媒體流以拷貝的形式發送給每個對端，對網絡帶寬是個極大的浪費，上行網絡的帶寬瓶頸決定了會議的方數上限，影響體驗，也不利于擴展。

要解決這兩個問題，就要引入媒體服務器。看下面的架構圖：

?

加入媒體服務器后，每個瀏覽器只和服務器建立媒體傳輸通道。

• 媒體服務器架設在公網，P2P的可用性有保障。
• 每個瀏覽器只向服務器發送一路本地媒體流，由服務器負責轉發給遠端，避免了帶寬浪費。

對于視頻會議來說，這是更優的架構選擇。

常用的媒體服務器主要分為SFU(Selected Forward Unit)和MCU(Multipoint Control Unit)，SFU只負責媒體流轉發，不做太多復雜的媒體處理，并發能力會強一些。MCU除了媒體流的接收/發送，還會進行轉碼和混流，對服務器的性能要求比較高，在實時傳輸系統中，轉碼會帶來額外的延時，在選型時也必須考慮。多人視頻會議場景下的SFU/MCU架構示意如圖：

SFU對接入的媒體流進行全網轉發，MCU對接收到的媒體流做轉碼后，只轉發一路合成后的媒體流。它們的優勢和劣勢總結如下表：

WebRTC的生態中，有許多優秀的開源媒體服務器，下面列出部分關注度高的項目。

?

Project	SFU	MCU	LIcense
Janus	??	??	GPL v3
Licode	??	??	MIT
MediaSoup	??	??	ISC
Kurento	??	??	Apache2
Jitsi	??	??	Apache2

?

?	優勢	劣勢
SFU	靈活分發，并發高	下行轉發路數多，帶寬占用高，多方通話影響體驗
MCU	轉發流數少，下行帶寬占用少	服務器性能要求高，部署成本高，實時性稍差

大家可以根據自己的需求，選擇合適的項目來搭建媒體服務器。對于實時性和高并發有強要求的會議場景，筆者還是推薦采用SFU架構，下面的進階篇中也會基于SFU展開介紹。

另外，如果不滿足于瀏覽器入會，有擴展客戶端覆蓋的需求，上述的開源項目中，也有相應的native的客戶端庫，比如mediaSoup，有提供一個libmediasoupclient的C++ library，這個庫本身是基于libwebrtc的，大家可以基于這個庫來搭建iOS/Andriod/PC的客戶端，需要一定的時間摸索編譯環境，但不會太復雜。

這還不是WebRTC生態的全部，在客戶端擴展方面，WebRTC是一直走在路上的，各種前沿的混合開發框架項目中，都能看到它的身影，比如RN/Flutter/Cordova等等，在Github上都有WebRTC開發庫，愿意實踐的開發者可以嘗試，不過，要用這些開發框架做到產品化，還是需要一定積累的，需要踩一些坑。

到這里，我們完成了基礎的視頻會議搭建，或許在通話時會面對這樣那樣的質量問題，但至少實現了聽得見、看得到，淺嘗則止的目標已達成。下面的進階篇，就留給打算深入學習RTC的小伙伴(需要一些音視頻基礎)。

?

進階篇

視頻會議的基礎是實時音視頻通信(RTC)技術，在上一篇解決了聽得見、看得到的問題之后，在接下來的進階篇中，我們重點關注下如何能讓音視頻通信穩定、流暢、可靠，也就是關乎視頻會議的質量體驗問題。

大家可能都會有這樣的體會，視頻會議總是很難保持穩定，偶爾會視頻卡住，或者聲音斷續，或是今天可以正常完會，改天就不好。其實實時音視頻通信的原理就是信號的采集，處理和傳輸，而其中傳輸部分是最難把控的，為了做到實時性，我們要摒棄長時延、可靠的TCP，選擇不可靠，但有可能做到實時的UDP。在公共互聯網上用UDP搭建傳輸網絡，它的不可靠的因子會被放大，比如時延，抖動，丟包等，都有可能影響視頻會議的體驗。

下面的章節中，我們重點介紹實時音視頻通信中的Quality of Service(QoS)。QoS可以狹義地理解為鏈路分組數據傳輸的質量指標，相對的另一個指標是Quality of Experience(QoE)，它是用戶對設備，網絡和系統總體的端到端主觀體驗。

?

QoS那些事

WebRTC中已經具備了一些保障QoS的策略，比如ARQ，FEC，Jitter Buffer，Congestion Control等，讓我們結合前面的SFU架構來展開探討。

QoS策略的主要任務是對抗影響數據傳輸的網絡變量，比如時延，抖動，丟包，帶寬等。我們簡單介紹下QoS的常規武器。

ARQ：自動重傳請求，是數據鏈路層的錯誤糾正協議之一，WebRTC中用到是協議中的NACK機制，即接收端監測到數據包SeqN丟失后，發送對該數據包的重傳請求，由發送端執行重傳。

FEC：前向糾錯，是增加數據通訊可靠度的方法，利用原始數據編碼進行冗余信息的傳輸，當傳輸中出現丟包，允許接收端根據冗余信息重建。WebRTC利用UlpFEC進行數據保護，冗余系數由鏈路上的丟包率決定。

Jitter Buffer：抖動緩沖，通過在接收端維護一個數據緩沖區，可以對抗一定程度的網絡抖動，丟包和亂序，需要考慮的是接收延時和卡頓之間的平衡。

Congestion Control：擁塞控制， WebRTC利用GCC算法來控制傳輸，通過兼顧丟包和時延的算法來估計網絡可用帶寬，并以此估算值來控制源端發送碼率，避免網絡擁堵。

在典型的SFU傳輸鏈路中，媒體流(RTP數據包)由Sender發送到Receiver，媒體控制流(RTCP包)由Receiver反饋給Sender。控制流中包括了NACK, PLI, REMB, Receiver Report等反饋信息。這些反饋信息是配合QoS策略的輔助手段。

有了這些QoS策略的加持，WebRTC的視頻通話能夠對抗一定程度的網絡狀況，正常情況下的通話質量可以保障。但是，這種默認的策略也存在明顯的改進空間，比如：

QoS的策略是在端到端之間生效的，接收端發現丟包后，才會向發送端發送NACK請求重傳，全鏈路的路徑(rtt)過長，影響數據重傳和恢復的效率。

接收端在發現無法恢復視頻幀后，才會發送PLI(Picture Lost Indicator)向源端請求關鍵幀，直到下一個關鍵幀到達前，所有鏈路上的視頻幀都無法正常解碼，影響接收端的視頻幀率，較大概率造成卡頓。

針對這兩個典型的問題，我們可以分別嘗試改進。

如上圖所示，在改進的SFU傳輸架構中，重傳請求不再是全鏈路反饋，而是在客戶端和服務器之間進行。一方面，服務器具備了NACK請求的能力，及時發現上行鏈路的丟包，及時向發送到請求重傳。另一方面，服務器能夠及時響應接收端的NACK請求。丟包重傳的效率提升，有助于減少端到端延時，改善音視頻體驗。

對于弱網下視頻幀率較低的問題，除了優化傳輸過程中的FEC+NACK策略之外，還可以從源端編碼器入手調整。

常規的RTC系統中的編碼GOP是IPPP…P，每一個P幀都作為參考幀，一旦某一幀有數據包缺失，其后的所有P幀都無法正常解碼，抗誤碼擾動的能力比較差。

一種改進的思路是，改變編碼器的參考幀選擇，采用長參考幀Long-Term Reference (LTR) frames機制，比如：

?

可以看到，引入LTR后，P幀不再是單一的前向參考，而是會有選擇性的參考一些固定的幀，只要這部分固定的參考幀能夠完整被接收，就能確保其他的完整幀能夠正常解碼，提高接收端的視頻幀率，保障流暢。這種編碼方式是比較適合于RTC系統的，能夠對抗更大的網絡抖動。

應用在視頻會議中，需要接收端實時反饋的配合。接收端借助于RTCP，實時反饋能夠正常解碼的幀信息，發送端可以利用收集到的這些信息，選擇合適的參考幀序列(需要兼顧編碼效率)，這樣端到端的配合，能夠最大程度的提升實時傳輸系統的體驗。

這種反饋與編碼協同的機制，同樣適用于多人的會議場景。只不過，在多人場景中，我們要面對更加棘手的多端擁塞控制問題。

前面介紹過WebRTC自帶的端到端擁塞控制，在會議場景下，擁塞控制需要綜合考慮各個客戶端的情況，如下圖所示：

在多人會議情況下，各個接收端的帶寬能力是不相同的，每條鏈路的帶寬估計值都會反饋到發送端，由發送端來統一決策，控制編碼和發送碼率。這會帶來兩個潛在的問題：

多條鏈路的帶寬反饋導致發送端的決策困難，編碼/發送碼率容易抖動。

某一個接收端的網絡帶寬不足(如圖中的300k下行)，發送端就會降低碼率以適配當前帶寬，導致每個接收端的體驗都會下降，這顯然是不合理的。

?

解決這些問題，我們就要來改進擁塞控制模型。大致的思路是，在SFU上實現帶寬估計反饋，以及下行的擁塞控制。將端到端的擁塞策略，演進為分段的擁塞控制策略。

理想情況下，發送端會根據上行的帶寬估計值控制源端編碼和發送碼率，SFU則會利用下行的帶寬估計值，來控制下發給各接收端的最高碼率。

然而，現實問題是，當SFU只有一路視頻可以轉發時，如何根據各鏈路的帶寬情況進行下發控制，有點巧婦難為無米之炊的感覺。

這里要借助于兩種源端編碼策略 - Simulcast和SVC。

Simulcast：同步廣播，指的是同時編碼/發送多路視頻流，比如常規發送一路720p，外加一路180p的流，這樣在SFU下發給接收端的時候，可以根據下行帶寬的限制，選擇下發不同分辨率的流，照顧到每個端的體驗。

應用Simulcast的系統示意：

SVC：可伸縮編碼，使用基于層次的方法，提供時間或空間可伸縮編碼組合。在RTC的應用中，通常會選用時域SVC，通過改變幀率來實現伸縮性。SFU可以根據下行的實際帶寬，從同一路SVC視頻流中解析出不同的時域分層，分別傳輸給各個接收端，同樣可以實現差異化的視頻流轉發。

?

?	優勢	劣勢
Simulcast	每路流都能保障幀率	上行帶寬占用高；分辨率跨度大
SVC	同一路視頻流，上行帶寬合理	時域分層影響接收幀率

?

Simulcast和SVC在實際應用中各有優劣，Simulcast多路流的分辨率跨度大，主觀體驗不佳；SVC的時域分層會影響幀率，容易出現卡頓。

?

實時傳輸網絡

前一節重點介紹了WebRTC QoS的基本配置，以及進階的實踐方向。有了這些武器，可以在上下行網絡質量有波動時，還能保障較好的音視頻體驗。

在視頻會議的搭建過程中，QoS策略的保障是一方面，傳輸鏈路的選擇也同樣重要。

到目前為止，我們介紹的視頻會議架構還是中心服務器轉發，擺在我們面前有幾個顯而易見的問題：

用戶遠距離接入，尤其是跨國、跨地區時，傳輸鏈路質量沒有保障。

國內的跨運營商之間接入，網絡抖動大，影響會議質量。

單點服務器的容量和負載受限制。

如果希望我們的視頻會議是穩定、可靠的，解決上面的所有問題，必須構建一個具備智能調度的實時傳輸網絡。

整體網絡傳輸的調度見上圖，幾點簡要的說明：

分區域/分運營商部署SFU服務器，用戶通過接入服務實現就近接入，保障了最后一公里的質量。

靈活/按需部署路由節點，通過路由分配服務，能夠根據實時網絡質量選擇最優的傳輸路徑。

分布式的SFU更有利于會議方數的擴展和服務擴容

需要保障傳輸s網絡內部的數據傳輸質量，可以嘗試QUIC。

結合上述兩點，有了可靠的傳輸網絡，加上QoS保障的上下行質量，才能實現讓人放心的視頻會議體驗。

?

其他

除了網絡傳輸和QoS之外，視頻會議的質量體驗也和客戶端的表現相關，一些端側的疑難雜癥，比如設備可用性，回聲消除，雙講抑制等等，一定程度上決定了會議產品的成敗。這一部分的技術細節，將會在今后的公號文章中分享。

?

?

To Be Continued

?

自建一個視頻會議產品絕非一朝一夕之事。視頻會議系統龐大，文中介紹的也只是一小部分。未來我們會針對技術細節，結合網易實踐，進行持續的分享，甚至推出免費的系列課程。

?

另外，如果你對本篇文章有任何疑問，或想針對某一細節繼續探討，歡迎大家關注“網易智慧企業技術+”公眾號，留下你的問題，對話網易智慧企業流媒體服務器天團。我們也會定期匯總大家的問題，整理成專題文章發布，希望給大家帶來更多收獲。

?

?

福利時間

初次見面，

“網易智慧企業技術+”為各位朋友準備了一些禮物：

網易云音樂黑膠VIP年卡? ?3張?

網易嚴選旅行頸枕眼罩套裝? ?10份

?

玩法如下：

Step1：關注“網易智慧企業技術+”公眾號

Step2：轉發本篇文章至朋友圈并截圖

Step3：將截圖上傳至抽獎表單

（若無自動回復，可回復關鍵詞“抽獎”獲取鏈接）

?

4月15日晚上9:30統一開獎

?

總結

以上是生活随笔為你收集整理的从入门到进阶｜如何基于WebRTC搭建一个视频会议的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。