◆楊德炎 鄭少明 鄭漢軍 陳思德 李劍煜

基于WebRTC實(shí)現(xiàn)多人跨平臺(tái)同時(shí)在線視頻聊天

◆楊德炎 鄭少明 鄭漢軍 陳思德 李劍煜

（廈門安勝網(wǎng)絡(luò)科技有限公司 福建 321008）

手機(jī)、臺(tái)式機(jī)、筆記本、電視以及任何安裝智能操作平臺(tái)的移動(dòng)設(shè)備，都可以在通用平臺(tái)上，使地理上分散的用戶共聚一處，進(jìn)行視頻會(huì)議開(kāi)展協(xié)同工作，實(shí)現(xiàn)點(diǎn)對(duì)點(diǎn)實(shí)時(shí)信息交流和數(shù)據(jù)共享的世界，本文介紹的WebRTC技術(shù)就能實(shí)現(xiàn)這樣的協(xié)同工作。

WebRTC；WebSocket；跨平臺(tái)；實(shí)時(shí)通信；流媒體；視頻通話；NAT/防火墻穿透

0 前言

縱觀全球，將RTC（實(shí)時(shí)通訊）技術(shù)與現(xiàn)有內(nèi)容，音/視頻視頻數(shù)據(jù)和服務(wù)集成起來(lái)非常困難且耗時(shí)，還需要花費(fèi)昂貴的技術(shù)成本，尤其是建立在Web應(yīng)用上。

許多Web服務(wù)使用RTC，需要下載本機(jī)應(yīng)用程序或插件。其中包括早期的WebQQ、 微信網(wǎng)頁(yè)版、微軟的Skype、Facebook和Google Hangouts。下載，安裝和更新插件等復(fù)雜操作，容易出錯(cuò)并且很煩人。插件很難更新部署，調(diào)試，故障排除，測(cè)試和維護(hù)，兼容性差，需要為各種操作平臺(tái)定制開(kāi)發(fā)，并且可能需要昂貴的許可并與復(fù)雜的技術(shù)集成。通常很難說(shuō)服人們首先安裝插件，用戶體驗(yàn)極差，交互野蠻。

而現(xiàn)在這一切都變得很容易，網(wǎng)絡(luò)視頻新技術(shù)—基于WebRTC實(shí)現(xiàn)網(wǎng)頁(yè)化提供實(shí)時(shí)，無(wú)插件視頻、音頻和數(shù)據(jù)通信。

1 WebRTC概述

WebRTC，來(lái)自網(wǎng)頁(yè)即時(shí)通信（Web Real-Time Communication）的縮寫，通過(guò)簡(jiǎn)單友好的API為瀏覽器和移動(dòng)應(yīng)用程序提供實(shí)時(shí)，無(wú)插件的音/視頻和數(shù)據(jù)通信標(biāo)準(zhǔn)，涵蓋了視頻會(huì)議的核心技術(shù)，包括從視頻采集卡到網(wǎng)絡(luò)傳輸端視頻顯示等整個(gè)解決方案。其自適應(yīng)抖動(dòng)控制算法以及語(yǔ)音包丟失隱藏算法，能夠快速且高解析度地適應(yīng)不斷變化的網(wǎng)絡(luò)環(huán)境，確保音質(zhì)優(yōu)美且緩沖延遲最小。Video Jitter Buffer視頻抖動(dòng)緩沖器，能有效降低由于視頻抖動(dòng)和視頻信息包丟失帶來(lái)的不良影響。Image enhancements圖像質(zhì)量增強(qiáng)模塊對(duì)暗度檢測(cè)、顏色增強(qiáng)、色彩過(guò)渡、降噪處理等，表現(xiàn)出極為強(qiáng)悍的一面。

面向開(kāi)發(fā)者的標(biāo)準(zhǔn)API可分成Network Stream API、 RTCPeerConnection、Peer-to-peer Data API三大類，允許用戶在兩個(gè)瀏覽器之間直接通訊，實(shí)現(xiàn)雙向的數(shù)據(jù)交換。內(nèi)置抽象會(huì)話層，采用了libjingle庫(kù)的組件實(shí)現(xiàn)，提供會(huì)話建立和管理功能，無(wú)須使用xmpp/jingle協(xié)議。本地C++接口層能抽象地對(duì)數(shù)字信號(hào)過(guò)程進(jìn)行處理，通過(guò)STUN和ICE Server即可建立不同類型網(wǎng)絡(luò)間的視頻呼叫連接。而且具有很強(qiáng)的擴(kuò)展性，容易跟其它現(xiàn)有的音/視頻通訊系統(tǒng)結(jié)合。并且支持所有的主流操作平臺(tái)Windows、linux、Mac、Android、IOS等。

2 視頻會(huì)議系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

WebRTC 基于P2P的網(wǎng)絡(luò)通信，提供了瀏覽器到瀏覽器之間的通信。但是網(wǎng)絡(luò)之間的應(yīng)用程序不能簡(jiǎn)單隨意地進(jìn)行任意設(shè)備相連接，現(xiàn)實(shí)生活中大多數(shù)設(shè)備都隱藏在一層或多層NAT，有些設(shè)備還具有阻止某些端口和協(xié)議的防病毒軟件，而且許多設(shè)備都支持網(wǎng)絡(luò)代理和企業(yè)防火墻。為此瀏覽器之間用于交換建立通信的元數(shù)據(jù)—信令和穿越NAT和防火墻必須依托服務(wù)器維護(hù)。

2.1 信令服務(wù)器 Signaling Server

在瀏覽器之間的會(huì)話建立之前，瀏覽器之間顯然沒(méi)有辦法傳遞數(shù)據(jù)進(jìn)行通信，需要一系列協(xié)調(diào)通信和發(fā)送控制消息的機(jī)制來(lái)建立瀏覽器之間的通信 。瀏覽器之間傳遞的這些信令元數(shù)據(jù)需要通過(guò)服務(wù)器的中轉(zhuǎn)回傳，然后建立瀏覽器之間的會(huì)話，一旦成功RTCPeerConnection就會(huì)嘗試點(diǎn)對(duì)點(diǎn)直接連接，處理對(duì)等體之間流數(shù)據(jù)的穩(wěn)定和有效通信。

其實(shí)信令就是協(xié)調(diào)溝通的過(guò)程，而用于信令的消息服務(wù)需要是雙向的：客戶端到服務(wù)器，服務(wù)器到客戶端。為了使WebRTC程序之間進(jìn)行通信，其客戶端需要交換以下信息：

（1）控制初始化或關(guān)閉會(huì)話的控制消息和錯(cuò)誤消息。

（2）媒體流元數(shù)據(jù)，比如像解碼器、編解碼器的配置、帶寬、分辨率等網(wǎng)絡(luò)配置數(shù)據(jù)。

（3）用來(lái)建立安全連接的關(guān)鍵秘鑰數(shù)據(jù)。

（4）外界所看到用戶在網(wǎng)絡(luò)上的數(shù)據(jù)，比如IP地址和端口等。

舉個(gè)例子，如圖1：假設(shè)客戶端A希望與客戶端B建立TCP連接，那么這兩個(gè)客戶端A和B首先需要連接至服務(wù)器S。服務(wù)器S注冊(cè)每個(gè)客戶端的IP和專用端口。客戶端A使用與服務(wù)器S活動(dòng)的TCP會(huì)話來(lái)請(qǐng)求服務(wù)器S幫助其連接客戶端B。

圖1 Signaling Server工作原理圖

服務(wù)S把設(shè)備B的IP和端口回復(fù)給設(shè)備A，并在同一時(shí)間發(fā)送A的IP和端口給B。

設(shè)備A和設(shè)備B獲取到對(duì)方的IP端口后嘗試直連，傳出連接嘗試成功，或者失敗。如果其中一個(gè)傳出連接嘗試因網(wǎng)絡(luò)錯(cuò)誤，例如連接重置、主機(jī)無(wú)法訪問(wèn)而失敗，則主機(jī)只需在短暫延遲后重新嘗試該連接，直至應(yīng)用程序，建立TCP連接后，主機(jī)會(huì)相互進(jìn)行身份驗(yàn)證，以驗(yàn)證它們是否已連接到目標(biāo)主機(jī)。如果身份驗(yàn)證失敗，客戶端將關(guān)閉該連接并繼續(xù)等待其他連接成功。

具體的連接建立方式基于信令控制協(xié)議JSEP（JavaScript Session Establishment Protocol），在JSEP中，需要交換的關(guān)鍵信息是多媒體會(huì)話描述，由于開(kāi)發(fā)者所使用的協(xié)議不盡相同，例如SIP或XMPP，WebRTC建立呼叫的思想建立在媒體流控制層面上，從而與上層信令傳輸相分離，防止相互之間的信令污染。只要上層信令為其提供了多媒體會(huì)話描述符這樣的關(guān)鍵信息就可以建立連接，不管開(kāi)發(fā)者用何種方式來(lái)傳遞。

2.2 NAT穿透服務(wù)器 ICE Server

網(wǎng)絡(luò)地址轉(zhuǎn)換NAT（Network Address Translation）就是為解決IPV4下的IP地址匱乏而出現(xiàn)的一種技術(shù)。NAT設(shè)備允許在具有面向Internet的單個(gè)公共IP地址的路由器后面的專用網(wǎng)絡(luò)上，使用私有IP地址。內(nèi)部網(wǎng)絡(luò)設(shè)備通過(guò)將傳出請(qǐng)求的源地址更改為NAT設(shè)備的源地址，并將回復(fù)中繼回原始設(shè)備來(lái)與外部網(wǎng)絡(luò)上的主機(jī)通信。

每個(gè)WebRTC終端都有一個(gè)唯一的地址，可以與其他對(duì)等端交換，以便直接通信和數(shù)據(jù)交換。但是NAT提供具有IP地址的設(shè)備在專用本地網(wǎng)絡(luò)內(nèi)使用，但是該地址不能在外部使用。沒(méi)有公共地址，WebRTC對(duì)等體就無(wú)法進(jìn)行通信。

為了解決這問(wèn)題，我們需要ICE服務(wù)器來(lái)克服現(xiàn)實(shí)網(wǎng)絡(luò)的復(fù)雜性，借助NAT網(wǎng)關(guān)跟蹤來(lái)自專用網(wǎng)絡(luò)的出站請(qǐng)求，并維持每個(gè)已建立連接的狀態(tài)，以便將來(lái)自公共網(wǎng)絡(luò)上的對(duì)等體的響應(yīng)直接響應(yīng)到專用網(wǎng)絡(luò)中的對(duì)等體。保證了RTCPeerConnection能實(shí)現(xiàn)NAT穿越。

簡(jiǎn)單地說(shuō)就是將ICE服務(wù)器URL傳遞給RTCPeerConnection， ICE試圖找到連接對(duì)等體的最佳路徑。它并行嘗試所有可能性，并選擇最有效的選項(xiàng)。ICE首先嘗試使用從設(shè)備的操作系統(tǒng)和網(wǎng)卡獲得的主機(jī)地址建立連接。如果失敗它將用于NAT后面的設(shè)備，ICE使用STUN服務(wù)器獲取外部地址，如果失敗，則通過(guò)TURN中繼服務(wù)器路由其流量。

每個(gè)TURN服務(wù)器都支持STUN,TURN服務(wù)器也是STUN服務(wù)器，內(nèi)置了增加的中繼功能,ICE還應(yīng)對(duì)NAT設(shè)置的復(fù)雜性。

我們借助兩個(gè)客戶端的設(shè)備A和B，一開(kāi)始通過(guò)TCP或UDP連接到具有全球公網(wǎng)IP的服務(wù)器S,如圖2：A,B兩個(gè)客戶端駐留在單獨(dú)的專用網(wǎng)絡(luò)里，和它們各自的NAT阻止客戶端直接與另一個(gè)客戶端連接。兩個(gè)客戶端可以簡(jiǎn)單地使用服務(wù)器S在它們之間中繼消息，而不是嘗試直接連接。例如，向客戶端B發(fā)送消息，A只需將消息沿其已建立的客戶端/服務(wù)器連接發(fā)送到服務(wù)器S，服務(wù)器S使用其現(xiàn)有的客戶端/服務(wù)器連接S將消息轉(zhuǎn)發(fā)到客戶端B。

又由于A,B主動(dòng)給公網(wǎng)IP的服務(wù)器S發(fā)消息，所以公網(wǎng)服務(wù)器可以穿透NAT A, NAT B送包給A,B。只要公網(wǎng)IP將B的IP/PORT發(fā)給A,A的IP/PORT發(fā)給B。這樣下次A和B互相消息，就不會(huì)被NAT阻攔了。

TURN用于在對(duì)等體之間中繼音頻、視頻數(shù)據(jù)流，而不是信令數(shù)據(jù)，服務(wù)器具有公共地址，因此即使對(duì)等體位于防火墻或代理之后，也可以與對(duì)等方聯(lián)系。

服務(wù)器具有公共地址，因此即使對(duì)等體位于防火墻或代理之后，也可以與對(duì)等方聯(lián)系。

圖2 NAT穿越原理圖

3 總結(jié)

基于WebRTC技術(shù)的網(wǎng)頁(yè)版網(wǎng)絡(luò)視頻會(huì)議技術(shù)，使用支持HTML5瀏覽器的設(shè)備即可，它與幾乎所有的瀏覽器兼容，無(wú)需額外下載安裝任何插件，極大地提高了安全性，且支持市面上所有主流的操作平臺(tái)。使開(kāi)發(fā)者能夠容易地開(kāi)發(fā)出網(wǎng)絡(luò)視頻聊天的web應(yīng)用，同時(shí)也極大地減少開(kāi)發(fā)成本，一次編寫到處運(yùn)行，維護(hù)成本低。

應(yīng)用中使用的編解碼器和協(xié)議可以進(jìn)行大量工作，即使在不可靠的網(wǎng)絡(luò)上也可以進(jìn)行強(qiáng)大而靈活的點(diǎn)對(duì)點(diǎn)實(shí)時(shí)通信，內(nèi)置安全性（DTLS）和擁塞控制，內(nèi)含多種容錯(cuò)機(jī)制丟包隱藏、回聲消除、帶寬適應(yīng)性、動(dòng)態(tài)抖動(dòng)緩沖、自動(dòng)增益控制、降噪和抑制、圖像清潔等。以及多個(gè)對(duì)等端各自直接相互通信，或通過(guò)多點(diǎn)控制單元（MCU），進(jìn)行選擇性流轉(zhuǎn)發(fā)，混合或錄制音頻和視頻。

而這一切都可以通過(guò)低廉的開(kāi)發(fā)成本得到一個(gè)高性能的產(chǎn)品。

[1]趙宇.WebRTC技術(shù)在語(yǔ)音平臺(tái)中的應(yīng)用研究[J].通信技術(shù),2018.

[2]李鋒.WebRTC標(biāo)準(zhǔn)的現(xiàn)狀研究及展望[J].中國(guó)新通信,2018.

[3]孫衛(wèi)喜,席少龍.P2P中NAT穿越問(wèn)題的研究[J].計(jì)算機(jī)技術(shù)與發(fā)展,2014.

[4]韓可玉,王振濤,蘇繼斌.NAT和防火墻穿越技術(shù)研究[J].軟件導(dǎo)刊,2014.

[5]陳亮. 基于改進(jìn)ICE協(xié)議的流媒體穿透NAT的研究[D].華南理工大學(xué),2012.

[6]Cihan Topal,Cuneyt Akinlar. Secure seamless peer-to-peer (P2P) UDP communication using IPv4 LSRR option and IPv4+4 addresses[J]. Computers and Electrical Engineering,2008.

[7]Julian Jang-Jaccard,Surya Nepal,Branko Celler,Bo Yan. WebRTC-based video conferencing service for telehealth[J]. Computing,2016.

[8]Vogt,C.,Werner,M.J.,Schmidt,T.C.Leveraging WebRTC for P2P content distribution in web browsers[P]. ,2013.