深度解析工業(yè)級WebRTC應用實踐

網易在音視頻領域有10多年豐富經驗的積累，在公司內部我們把自己的這一套工業(yè)級的功能完整的音視頻技術方案稱為NRTC，NRTC的意思就是NetEase RTC。近幾年，WebRTC非?；馃?，尤其是2017年，蘋果宣布在Safari 11里面支持WebRTC，所以說Web本身也變成了一個非常重要的入口，是音視頻很重要的一個終端，對于我們來說，要在我們的NRTC里面實現(xiàn)對WebRTC的支持，也就是要能夠支持Web這樣一個終端和入口。

1、NRTC技術解決方案

NRTC全稱為NetEase RTC,是網易公司實現(xiàn)的一套工業(yè)級的功能完整的音視頻技術解決方案。

1.1 NRTC技術架構圖：

從架構圖中，大家可以看到，我們有NRTC SDK，這是實時音視頻通話的客戶端SDK，有PC端、移動端的SDK，另外有我們的NRTC MCU，這是一個媒體服務器。在客戶端上NRTC SDK會負責推拉流到NRTC MCU，NRTC MCU負責把媒體流中轉給其它的客戶端，同時它也會中轉給 NRTC BMS，BMS其實就是互動直播服務器，在BMS上會做混音混屏，將音視頻混成一路流后再推給NRTC LVS，LVS就是直播源站，最后再推給我們的NCDN網絡，通過NCDN的海量分發(fā)，使用我們的NRTC Player就可以支持海量的用戶拉流。在這里面大家可以看到左半邊是UDP的方案，右半邊是一個TCP的方案，同時我們在Server端有很多像錄制、混屏、混音、轉碼，包括存儲，后續(xù)還有基于存儲的點播。

1.2 NRTC支持的功能：

實時音視頻通話

直播

互動直播

點播

互動白板

短視頻

1.3 音視頻技術棧

信令： SDP、JSEP、SIP、Jingle、ROAP

傳輸： RTP、RTCP、DTLS、RTMP、FLV、HLS

P2P： ICE、STUN、TURN、NAT

網絡： UDP、TCP

音頻： Opus、G711、AAC、Speex、3A

視頻： H264、VP8

QoS： FEC、NACK、BWE

Server： SFU、MCU

端： Capture、Render、各種適配

2、怎樣理解WebRTC？

WebRTC是由W3C和IETF定義的規(guī)范，簡單來講，就是一個在瀏覽器里面去實現(xiàn)音視頻會話的框架（JavaScript API），它不需要安裝，可以滿足P2P傳輸。只要通過信令的協(xié)商，也可以和傳統(tǒng)的音視頻應用去做互聯(lián)互通。另外，WebRTC也是一個開源項目，是由谷歌公司提供的基于C++的可以跨平臺的開源的音視頻框架，是功能完整的一個音視頻SDK，一般用libwebrtc來表示這個開源項目。

2.1 WebRTC的體系結構

在這個簡單的架構里面，主要包括了網絡傳輸、音頻引擎、視頻引擎，，它主要的功能和內容其實是C++實現(xiàn)的，然后封裝了一層JavaScript的API，讓你用JavaScript能夠調用到這些功能。

2.2 WebRTC的特點和局限

通過JavaScript的API在瀏覽器上調用

沒有定義信令

基于客戶端，沒有SFU/MCU

完全基于標準

依賴瀏覽器來實現(xiàn)

2.3 如何使用WebRTC

1）方法一：基于JavaScript的API進行音視頻的應用

完全基于JavaScrip去做，沒有媒體相關的Server，可靠性或者功能會很受限，但可以控制很低的成本。

2）方法二：基于libwebrtc來實現(xiàn)

由于WebRTC本身這些C++的Code，沒有很好的工程化，所以在異常保護，錯誤恢復等方面做得不太夠。在真實的應用當中，可能要做很多的調整和改造。

3）方法三：兼容、支持WebRTC

對于一些有成熟的音視頻框架體系的公司，可以在自己的體系上來兼容、支持WebRTC。

2.4 NRTC和WebRTC的比較

NRTC早于WebRTC

NRTC是VoIP的完整解決方案，大概可以說NRTC SDK約等于WebRTC

NRTC的實現(xiàn)更靈活，WebRTC是基于標準的，有很多受限的方面

NRTC是工業(yè)級的實現(xiàn)，技術框架更加成熟

3、如何實現(xiàn)NRTC支持WebRTC

3.1 在NRTC中連接WebRTC的原理

從圖中的簡要架構設計可以看出，如果想要NRTC的技術方案和Web端建立連接，可以通過WebRTC Gateway這種方式，WebRTC GateWay跟NRTC MCU之間是通過UDP協(xié)議傳輸NPDU的流媒體，另一端通過SRTP連接Web。

下面給大家講解一下WebRTC GateWay：

在WebRTC GateWay里面主要包括兩部分：信令和媒體，在信令方面，我們主要提供了WebSocket，信令是為了幫助兩個端SDP和ICE去交互，由提供的WebSocket來進行連接；在媒體方面，要實現(xiàn)ICE框架和SRTP協(xié)議棧來建立網絡通訊的連接，還要做一個包的轉封裝工作，把RTP的包和NPDU的包相互轉換。有了這個WebRTC GateWay，經過我們的MCU就可以跟我們的其他的端實現(xiàn)互聯(lián)互通。

3.2 實現(xiàn)NRTC兼容WebRTC所做的工作

實現(xiàn)瀏覽器的兼容

建立ICE框架

搭建RCTP協(xié)議棧，得到反饋值

確保Web端的可靠連接

擁塞控制

3.3 瀏覽器的“坑點”

1）利用adapter.js來實現(xiàn)瀏覽器的兼容

各種不同版本的瀏覽器實現(xiàn)這個規(guī)范的時候可能會接口會有些不一樣，主要還是接口層的不一樣，通過adapter.js可以兼容這些接口。

2）視頻分辨率

有些瀏覽器支持視頻分辨率的裁切，有些不支持。

3）媒體流的生命周期

瀏覽器上的媒體流的生命周期有限，有時得到的媒體是沒有視頻或音頻。

4）請求得到用戶媒體成功，卻沒有媒體流發(fā)過來。

3.4 Lite ICE框架

在ICE框架中包括NAT,STUN-RFC5389,TURN-RFC5766,ICE-RFC5245,TCP。在一個高可靠的網絡連接中，還要能夠支持TCP連接。當一方是Serve且有固定的公網IP，另外一方是客戶端的這種情況下，可以使用Lite ICE框架。在Lite ICE這種情況下面，你只要給一個Host candidates，即當你的Server回來，給Server一個公網IP，不需要再去其他的探測，你只要給Server的Host candidates就可以了，在Lite ICE情況下面，是有Full peer這端會發(fā)起連通的檢查，也就是由瀏覽器這一端發(fā)起連通檢查，它只需要兩步就可以完成連通檢查。

3.5 網絡監(jiān)測

1）在信令中，WebSocket有斷網事件通知

2）RTCPeerConnection有斷網事件通知

3）在TCP連接上，有基于signaling channel的keepalive

3.6 斷開重連

1）Start over

Detach stream,銷毀現(xiàn)有連接等

信令連接、鑒權、媒體連接

2）ICE restart

3.7 Multiplexing and bundle

減少UDP的連接數(shù)

減少UDP的連接有兩個好處，第一，可以減少建立連接的時間，第二，在企業(yè)環(huán)境里面，很多UDP的一個端口連接需要找網管去配的，如果有多個連接，會加大配置和維護的難度。

3.8 丟包恢復和擁塞控制

1）GCC

GCC是在WebRTC本身現(xiàn)有的一套擁塞控制框架，它是有兩種模型，一種是基于丟包的模型，一種是基于時延的模型，從圖中可以看出，發(fā)送端有一個叫丟包的模型，在接收端有一個基于時延的模型（在最新的WebRTC里已調整為都在發(fā)送端了）；在發(fā)送端它會做帶寬評估，評估管理以后流媒體送到接收端，那接收端之它有個基于延時的一個帶寬評估，評估完以后，當它發(fā)現(xiàn)這個帶寬受限，或者它需要調整碼率，它通過REMB將消息送給發(fā)送端，讓發(fā)送端重新調整碼率，從而來實現(xiàn)一個帶寬評估和自適應碼率的過程。

2）如何在WebRTC GateWay中讓GCC工作起來

REMB

先在接收端進行一個最大接收碼率估測，在WebRTC Gateway上通過REMB消息，告訴發(fā)送端如何調整碼率和帶寬。

GCC feedbacks

通過反饋給Delay-based controller正確的Transport cc來讓它計算正確的時延估計，以及帶寬評估；通過反饋Loss-based controller兩種RTCP的報文（SR/RR）,來進行丟包的計算。

3）丟包重傳（NACK）

實現(xiàn)一個雙向的丟包重傳，通過WebRTC GateWay和瀏覽器之間 發(fā)送NACK的RTCP feedback信息來進行丟包重傳。

3.9 分享一個SDP的例子