2017年，蘋果宣佈將在iOS 11中支援WebRTC，至此完成了主流PC瀏覽器、移動端的全覆蓋，而其提供了一整套完備的音視訊通訊方案，這給開發者帶來了巨大利好。英特爾協同通訊解決方案架構師段先德針對WebRTC的能力、優勢與不足、開發要點及未來發展幾方面進行分析。本文是『WebRTC-網際網路音視訊新標準？』系列的第一篇，如果您對WebRTC技術的未來有分析和洞見，歡迎聯絡 [email protected]。

文 / 段先德

策劃 / LiveVideoStack

2017年，隨著微軟和蘋果表態在其瀏覽器或系統產品中對WebRTC技術的支援，以及WebRTC 1.0標準的定案，WebRTC的話題越來越多地出現在廣大網際網路行業開發人員的視野中。很多同學對WebRTC的背景、目的、意義以及限制其實並不明白，加上媒體上各種吹捧和質疑的聲音互相摻雜，對WebRTC這項技術的應用前景和開發難度沒有切實的判斷。本文希望通過對WebRTC技術的粗淺梳理，為大家提供參考。

WebRTC是什麼？能做什麼？

很多人期望WebRTC是一個“拿來即用”的“端到端解決方案”，只需要在web端寫幾行JavaScript呼叫甚至不需要程式設計就能實現瀏覽器之間的實時音視訊通訊。也有很多人把WebRTC等同於Google在其Chromium工程中的開源實現。其實這都是誤解。WebRTC並不是一個“解決方案”，也不囿於某一種實現的程式碼庫。WebRTC是終端的音視訊媒體訪問（輸入輸出）介面在類似web環境下的標準化抽象，以及用於實時通訊的會話的建立過程、終端音視訊媒體（或其他資料）編碼格式、傳輸方式和引數的描述和協商規範。既然是一種標準規範，那麼無論具體實現方式如何，只要該實現符合該標準規範就應該可以互聯互通、擁有實時通訊的能力，這也是WebRTC最本質的意義。

WebRTC雖然冠以“web”之名，但並不受限於傳統網際網路應用或瀏覽器的終端執行環境。實際上無論終端執行環境是瀏覽器、桌面應用、移動裝置（Android或iOS）還是IoT裝置，只要IP連線可到達且符合WebRTC規範就可以互通。這一點釋放了大量智慧終端（或執行在智慧終端上的app）的實時通訊能力，打開了許多對於實時互動性要求較高的應用場景的想象空間，譬如線上教育、視訊會議、視訊社交、遠端協助、遠端操控等等都是其合適的應用領域。

WebRTC有什麼優勢和不足？

很長時間以來，實時通訊能力一直是電信類專用裝置（如電話、手機）的專有屬性。隨著各種網際網路應用和移動網際網路應用的層出不窮，特別是隨著使用者接入頻寬條件的不斷改善，許多新的應用都對實時通訊服務有著切實的需求，希望能夠把實時通訊能力整合到應用程式中。其實很多終端裝置都具有實時通訊的潛力的，但是在WebRTC之前，沒有一個統一的工業標準來描述一個裝置的實時通訊能力和連線建立過程。在對實時通訊能力的需求特別迫切的應用（如微信、WhasApp、FaceTime、Messenger等等）中，大家各做一套，“七國八制”，完全不能互通。

WebRTC最大的優勢就是“標準化”，它解決的問題就是給所有需要進行實時通訊的終端提供一套統一的、開放的實時通訊能力描述和連線建立標準。只要符合WebRTC的規範，通訊終端的形態和執行環境就是透明的（看不見也不關心），大家都可以用同一種“語言”進行“交談”。WebRTC對音視訊的編碼格式（codec）、傳輸方式和協商過程做出了明確的規定，原則上所有支援WebRTC的終端，在互操作性上將不存在障礙。目前各大瀏覽器廠商都積極參與到WebRTC技術的生態中，從web應用開始，WebRTC將成為基於網頁的音視訊實時通訊技術規範將。之後，在web應用於移動終端應用的互動需求驅動下，越來越多的移動應用的音視訊服務也將採用WebRTC的技術規範。

要說不足之處，一個就是目前WebRTC標準剛剛塵埃落定，在2018年以及今後的一段時間內，還存在各家瀏覽器廠商的現有WebRTC實現與規範不完全相符的情況，會多少存在某些應用場景下互聯互通的問題，亟待各家瀏覽器廠商將持續完善現有實現以向標準看齊。另一個很大的不足（遺憾）可能是Android和iOS系統原生支援WebRTC標準的願景目前還不明確，需要通過在app中整合客戶端SDK來實現。不過向來技術標準的發展和與工業界的應用普及是相互激勵的，我們也可以說這是WebRTC標準發展的一個巨大空間。

怎麼做基於WebRTC的應用開發？

首先當然要讓終端具備WebRTC能力。如果終端執行環境是瀏覽器，目前絕大部分瀏覽器都已經實現了對WebRTC的支援（其中Safari和Edge的支援還在持續完善中），雖然彼此有一些差異，但是可以藉助adapter.js等適配層遮蔽掉這些差異。如果終端執行環境不是瀏覽器，則可以採用其他的開源SDK或商業SDK，將其整合在終端應用程式中。當然也可以基於Google的開源WebRTC實現的Native程式碼進行裁剪或移植。值得一提的是Google的開源WebRTC程式碼庫中有大量的終端多媒體問題和傳輸問題的應對方案的實現，包括音視訊的編解碼、同步、頻寬預測、QoS，AEC等，都是做終端（特別是IoT裝置或桌面環境應用）開發時很好的參考。

終端實現了WebRTC只是表示它具備了實時通訊的能力，但各個終端任然是孤立的，需要將各個終端的SDP進行交換才能讓它們完成媒體和傳輸的協商才能讓各個終端之間真正通起來。WebRTC並未就各個實現之間交換SDP的傳輸方式以及終端的“定址”方式做出規定，這跟具體應用場景和其實現方式高度相關。因此要實現基於WebRTC的應用還需要一些“額外”的工作，通過一個各個終端都“認識”並能“找到”的“中間人”來進行SDP交換。譬如最簡單的“1對1”呼叫的場景，這個“中間人”就是信令伺服器，這種WebRTC的信令伺服器可以基於任何訊息系統構建，有很多開源實現可以利用或參考，自研開發也並不複雜。

如果要基於WebRTC做“1對多”或者“多對多”的實時通訊應用，則情況要複雜一些，具體的做法也會因實際應用場景而不同，根據通訊終端之間的媒體流拓撲結構，大體上可以分為Peer2Peer（終端點對點連線）模式、SFU（Selective Forwarding Unit，伺服器選擇性轉發）模式和MCU（MultipointControl Unit，伺服器混音混流）模式。

Peer2Peer模式（所有參與方均需與其他所有參與方通訊的情景又叫Mesh模式）的特徵是呼叫中每兩個需要進行通訊的參與者之間都建立起點對點的媒體連線（PeerConnection），所有的媒體連線都是終端之間的（有可能通過TURN伺服器進行NAT穿越，但不影響本質流拓撲），伺服器側不參與。Peer2Peer模式的優點是媒體拓撲去中心化，伺服器側實現簡單，只需要將各個終端之間的信令交換送達即可；缺點是終端需要受理多路媒體流的收發，隨著呼叫中參與方數的增加，媒體連線數會階乘函式式增長，無論對終端的編解碼計算力還是頻寬資源都會帶來巨大的壓力。如果一個呼叫中引數方數很少（譬如大多數時間2方偶爾3方），則可以考慮選用Peer2Peer模式的伺服器側實現方案。

SFU模式的特徵是呼叫中所有的參與者都與伺服器側的媒體伺服器建立媒體連線，把媒體流傳送到媒體伺服器，媒體伺服器把媒體流（根據需要）選擇性轉發給需要接收該媒體流的所有參與者。SFU模式的優點是終端編碼運算和上行網路頻寬消耗大大減少，並且媒體伺服器可以根據要求將媒體流（需支援SVC）的不同分層選擇性地傳送給接收者，適當減少接收者側下行網路頻寬的消耗並提供一定的“可定製性”使用者體驗。缺點（或“代價”）是媒體伺服器需要受理所有媒體連線請求，接收所有參與者釋出的流並轉發給所有訂閱者，產生伺服器側運營壓力。

MCU模式的特徵是呼叫中所有的參與者都與伺服器側的媒體伺服器建立媒體連線並把媒體流傳送到媒體伺服器，媒體伺服器把所有收到的媒體流進行混流混音後傳送給所有需要接收的參與者。MCU模式相對SFU模式的優點是終端解碼運算和下行網路頻寬消耗進一步減少，並且天然具有轉碼能力，可以放寬終端採用音視訊編解碼格式的限制，使終端可以選擇對自身最友好的編解碼格式，大大提高終端生存能力。並且由於將所有終端的媒體混合在一起，可以實現伺服器側所見即所得的錄製和向外部流媒體伺服器推流。MCU的缺點（或“代價”）是媒體伺服器需要實時將所有接收的媒體流解碼混合再編碼，會帶來更大的計算力開銷。

在基於WebRTC的應用的實際開發中，大多數時候服務整合商並不需要從頭自研一套SFU或MCU系統，而是在市面上可用的開源或商業方案中進行選擇。在進行方案選擇時需要考慮的是，如果：

1. 希望客戶端側擁有更多的顯示佈局的靈活性且下行頻寬夠大夠穩定；

2. 呼叫中釋出媒體流的參與方數較少（譬如不多於6方）；

3. 無異種終端接入需求也不需要轉碼，則可以選擇SFU模式。

否則，如果：

1. 客戶端對下行資料量有苛刻的要求而對聚合畫面佈局沒有差異化要求；

2. 所有參與方（或很多參與方）都有釋出媒體流的需求（視訊會議的情景）；

3. 有異種終端（譬如SIP終端、IPCamera）的接入需求或轉碼需求；

4. 有伺服器側（雲端）錄製和推流到CDN的需求，則或許MCU模式更適合。除去所述這些情況以外的應用場景，則需要在各種需求的矛盾中權衡輕重得失以做出選擇了。

不過其實SFU模式和MCU模式並不是絕對互斥的，有的解決方案（例如Intel CS for WebRTC及其商業化版本）是將這兩種模式整合在一起的，服務整合商可以根據具體的應用場景進行靈活配置。

WebRTC發展前景如何？

作為終端技術規範，雖然WebRTC只是實時通訊解決方案中的一部分，但是是最貼近使用者的一部分，也許也是最重要的一部分。終端技術規範的標準化，是一個很好的開始。連一向以封閉的技術生態聞名的Apple都擁抱WebRTC了，將促進WebRTC技術的發展和普及，會有越來越多的網際網路（和移動網際網路）應用基於WebRTC構建其實時通訊服務。

進入2018年，在網際網路快速發展的當下和將來，WebRTC將極大啟用人與人、人與物、物與物（IoT）之間的資訊紐帶，移除掉通訊終端之間的時間（實時）和空間（基於網際網路）的障礙，成為應用場景創新的一道強大的技術保障。同時，類似VR、AR、自動駕駛等新的應用場景的出現也會給WebRTC技術帶來新的需求和動力，應用場景的商業化成功也將給技術發展持續注入活力和物質資源。譬如近年來直播連麥、網上課堂、遠端控制（抓娃娃機）等基於網際網路的視訊應用的猛烈發展和火熱，一次次催動著基於網際網路的的實時音視訊通訊技術的發展，呼喚著WebRTC這樣的統一、開放、透明的標準規範成熟和落地。

想象一下，在基於WebRTC構建的世界裡，所有通訊終端的媒體描述和連線建立過程都是一致的，只要終端之間開放媒體協商的通道，就可以建立起實時通訊，“微信”與“WhatsApp”能建立視訊通話，就像你在中國用手機跟美國的朋友家中的座機打電話一樣。那多美好！推動這一天的早日到來難道不也是我們網際網路音視訊通訊工作者們的歷史責任嗎？