LiveVideoStack整理而成。趙加雨闡述了網(wǎng)易在WebRTC上的探索和改進(jìn)，以及如何與WebRTC進(jìn)行互通。
概覽：
網(wǎng)易在音視頻領(lǐng)域有10多年豐富經(jīng)驗(yàn)的積累，在公司內(nèi)部我們把自己的這一套工業(yè)級(jí)的功能完整的音視頻技術(shù)方案稱為NRTC，NRTC的意思就是NetEase RTC。近幾年，WebRTC非�；馃�，尤其是2017年，蘋果宣布在Safari 11里面支持WebRTC，所以說(shuō)Web本身也變成了一個(gè)非常重要的入口，是音視頻很重要的一個(gè)終端，對(duì)于我們來(lái)說(shuō)，要在我們的NRTC里面實(shí)現(xiàn)對(duì)WebRTC的支持，也就是要能夠支持Web這樣一個(gè)終端和入口。
本次分享的主要內(nèi)容：
- 簡(jiǎn)要介紹NRTC的技術(shù)方案
- 怎樣理解WebRTC
- 如何實(shí)現(xiàn)NRTC支持WebRTC
1、NRTC技術(shù)解決方案
NRTC全稱為NetEase RTC,是網(wǎng)易公司實(shí)現(xiàn)的一套工業(yè)級(jí)的功能完整的音視頻技術(shù)解決方案。
1.1 NRTC技術(shù)架構(gòu)圖：
從架構(gòu)圖中，大家可以看到，我們有NRTC SDK，這是實(shí)時(shí)音視頻通話的客戶端SDK，有PC端、移動(dòng)端的SDK，另外有我們的NRTC MCU，這是一個(gè)媒體服務(wù)器。在客戶端上NRTC SDK會(huì)負(fù)責(zé)推拉流到NRTC MCU，NRTC MCU負(fù)責(zé)把媒體流中轉(zhuǎn)給其它的客戶端，同時(shí)它也會(huì)中轉(zhuǎn)給 NRTC BMS，BMS其實(shí)就是互動(dòng)直播服務(wù)器，在BMS上會(huì)做混音混屏，將音視頻混成一路流后再推給NRTC LVS，LVS就是直播源站，最后再推給我們的NCDN網(wǎng)絡(luò)，通過(guò)NCDN的海量分發(fā)，使用我們的NRTC Player就可以支持海量的用戶拉流。在這里面大家可以看到左半邊是UDP的方案，右半邊是一個(gè)TCP的方案，同時(shí)我們?cè)赟erver端有很多像錄制、混屏、混音、轉(zhuǎn)碼，包括存儲(chǔ)，后續(xù)還有基于存儲(chǔ)的點(diǎn)播。
1.2 NRTC支持的功能：
- 實(shí)時(shí)音視頻通話
- 直播
- 互動(dòng)直播
- 點(diǎn)播
- 互動(dòng)白板
- 短視頻
1.3 音視頻技術(shù)棧
信令： SDP、JSEP、SIP、Jingle、ROAP
傳輸： RTP、RTCP、DTLS、RTMP、FLV、HLS
P2P： ICE、STUN、TURN、NAT
網(wǎng)絡(luò)： UDP、TCP
音頻： Opus、G711、AAC、Speex、3A
視頻： H264、VP8
QoS： FEC、NACK、BWE
Server： SFU、MCU
端： Capture、Render、各種適配
2、怎樣理解WebRTC？
WebRTC是由W3C和IETF定義的規(guī)范，簡(jiǎn)單來(lái)講，就是一個(gè)在瀏覽器里面去實(shí)現(xiàn)音視頻會(huì)話的框架（JavaScript API），它不需要安裝，可以滿足P2P傳輸。只要通過(guò)信令的協(xié)商，也可以和傳統(tǒng)的音視頻應(yīng)用去做互聯(lián)互通。另外，WebRTC也是一個(gè)開源項(xiàng)目，是由谷歌公司提供的基于C++的可以跨平臺(tái)的開源的音視頻框架，是功能完整的一個(gè)音視頻SDK，一般用libwebrtc來(lái)表示這個(gè)開源項(xiàng)目。
2.1 WebRTC的體系結(jié)構(gòu)
在這個(gè)簡(jiǎn)單的架構(gòu)里面，主要包括了網(wǎng)絡(luò)傳輸、音頻引擎、視頻引擎，它主要的功能和內(nèi)容其實(shí)是C++實(shí)現(xiàn)的，然后封裝了一層JavaScript的API，讓你用JavaScript能夠調(diào)用到這些功能。
2.2 WebRTC的特點(diǎn)和局限
- 通過(guò)JavaScript的API在瀏覽器上調(diào)用
- 沒有定義信令
- 基于客戶端，沒有SFU/MCU
- 完全基于標(biāo)準(zhǔn)
- 依賴瀏覽器來(lái)實(shí)現(xiàn)
2.3 如何使用WebRTC
1）方法一：基于JavaScript的API進(jìn)行音視頻的應(yīng)用
完全基于JavaScrip去做，沒有媒體相關(guān)的Server，可靠性或者功能會(huì)很受限，但可以控制很低的成本。
2）方法二：基于libwebrtc來(lái)實(shí)現(xiàn)
由于WebRTC本身這些C++的Code，沒有很好的工程化，所以在異常保護(hù)，錯(cuò)誤恢復(fù)等方面做得不太夠。在真實(shí)的應(yīng)用當(dāng)中，可能要做很多的調(diào)整和改造。
3）方法三：兼容、支持WebRTC
對(duì)于一些有成熟的音視頻框架體系的公司，可以在自己的體系上來(lái)兼容、支持WebRTC。
2.4 NRTC和WebRTC的比較
- NRTC早于WebRTC
- NRTC是VoIP的完整解決方案，大概可以說(shuō)NRTC SDK約等于WebRTC
- NRTC的實(shí)現(xiàn)更靈活，WebRTC是基于標(biāo)準(zhǔn)的，有很多受限的方面
- NRTC是工業(yè)級(jí)的實(shí)現(xiàn)，技術(shù)框架更加成熟
3、 如何實(shí)現(xiàn)NRTC支持WebRTC
3.1 在NRTC中連接WebRTC的原理
從圖中的簡(jiǎn)要架構(gòu)設(shè)計(jì)可以看出，如果想要NRTC的技術(shù)方案和Web端建立連接，可以通過(guò)WebRTC Gateway這種方式，WebRTC GateWay跟NRTC MCU之間是通過(guò)UDP協(xié)議傳輸NPDU的流媒體，另一端通過(guò)SRTP連接Web。
下面給大家講解一下WebRTC GateWay：
在WebRTC GateWay里面主要包括兩部分：信令和媒體，在信令方面，我們主要提供了WebSocket，信令是為了幫助兩個(gè)端SDP和ICE去交互，由提供的WebSocket來(lái)進(jìn)行連接；在媒體方面，要實(shí)現(xiàn)ICE框架和SRTP協(xié)議棧來(lái)建立網(wǎng)絡(luò)通訊的連接，還要做一個(gè)包的轉(zhuǎn)封裝工作，把RTP的包和NPDU的包相互轉(zhuǎn)換。有了這個(gè)WebRTC GateWay，經(jīng)過(guò)我們的MCU就可以跟我們的其他的端實(shí)現(xiàn)互聯(lián)互通。
3.2 實(shí)現(xiàn)NRTC兼容WebRTC所做的工作
- 實(shí)現(xiàn)瀏覽器的兼容
- 建立ICE框架
- 搭建RCTP協(xié)議棧，得到反饋值
- 確保Web端的可靠連接
- 擁塞控制
3.3 瀏覽器的“坑點(diǎn)”
1）利用adapter.js來(lái)實(shí)現(xiàn)瀏覽器的兼容
各種不同版本的瀏覽器實(shí)現(xiàn)這個(gè)規(guī)范的時(shí)候可能會(huì)接口會(huì)有些不一樣，主要還是接口層的不一樣，通過(guò)adapter.js可以兼容這些接口。
2）視頻分辨率
有些瀏覽器支持視頻分辨率的裁切，有些不支持。
3）媒體流的生命周期
瀏覽器上的媒體流的生命周期有限，有時(shí)得到的媒體是沒有視頻或音頻。
4）請(qǐng)求得到用戶媒體成功，卻沒有媒體流發(fā)過(guò)來(lái)。
3.4 Lite ICE框架
在ICE框架中包括NAT,STUN-RFC5389,TURN-RFC5766,ICE-RFC5245,TCP。在一個(gè)高可靠的網(wǎng)絡(luò)連接中，還要能夠支持TCP連接。當(dāng)一方是Serve且有固定的公網(wǎng)IP，另外一方是客戶端的這種情況下，可以使用Lite ICE框架。在Lite ICE這種情況下面，你只要給一個(gè)Host candidates，即當(dāng)你的Server回來(lái)，給Server一個(gè)公網(wǎng)IP，不需要再去其他的探測(cè)，你只要給Server的Host candidates就可以了，在Lite ICE情況下面，是有Full peer這端會(huì)發(fā)起連通的檢查，也就是由瀏覽器這一端發(fā)起連通檢查，它只需要兩步就可以完成連通檢查。
3.5 網(wǎng)絡(luò)監(jiān)測(cè)
1）在信令中，WebSocket有斷網(wǎng)事件通知
2）RTCPeerConnection有斷網(wǎng)事件通知
3）在TCP連接上，有基于signaling channel的keepalive
3.6 斷開重連
1）Start over
Detach stream,銷毀現(xiàn)有連接等
信令連接、鑒權(quán)、媒體連接
2）ICE restart
3.7 Multiplexing and bundle
減少UDP的連接數(shù)
減少UDP的連接有兩個(gè)好處，第一，可以減少建立連接的時(shí)間，第二，在企業(yè)環(huán)境里面，很多UDP的一個(gè)端口連接需要找網(wǎng)管去配的，如果有多個(gè)連接，會(huì)加大配置和維護(hù)的難度。
3.8 丟包恢復(fù)和擁塞控制
1）GCC
GCC是在WebRTC本身現(xiàn)有的一套擁塞控制框架，它是有兩種模型，一種是基于丟包的模型，一種是基于時(shí)延的模型，從圖中可以看出，發(fā)送端有一個(gè)叫丟包的模型，在接收端有一個(gè)基于時(shí)延的模型（在最新的WebRTC里已調(diào)整為都在發(fā)送端了）；在發(fā)送端它會(huì)做帶寬評(píng)估，評(píng)估管理以后流媒體送到接收端，那接收端之它有個(gè)基于延時(shí)的一個(gè)帶寬評(píng)估，評(píng)估完以后，當(dāng)它發(fā)現(xiàn)這個(gè)帶寬受限，或者它需要調(diào)整碼率，它通過(guò)REMB將消息送給發(fā)送端，讓發(fā)送端重新調(diào)整碼率，從而來(lái)實(shí)現(xiàn)一個(gè)帶寬評(píng)估和自適應(yīng)碼率的過(guò)程。
2）如何在WebRTC GateWay中讓GCC工作起來(lái)
REMB
先在接收端進(jìn)行一個(gè)最大接收碼率估測(cè)，在WebRTC Gateway上通過(guò)REMB消息，告訴發(fā)送端如何調(diào)整碼率和帶寬。
GCC feedbacks
通過(guò)反饋給Delay-based controller正確的Transport cc來(lái)讓它計(jì)算正確的時(shí)延估計(jì)，以及帶寬評(píng)估；通過(guò)反饋Loss-based controller兩種RTCP的報(bào)文（SR/RR），來(lái)進(jìn)行丟包的計(jì)算。
3）丟包重傳（NACK）
實(shí)現(xiàn)一個(gè)雙向的丟包重傳，通過(guò)WebRTC GateWay和瀏覽器之間 發(fā)送NACK的RTCP feedback信息來(lái)進(jìn)行丟包重傳。
3.9 分享一個(gè)SDP的例子
