課程地址：零聲學(xué)院 WebRTC入門與提高 ?https://ke.qq.com/course/435382?tuin=137bb271

技術(shù)支持QQ群：782508536

本門課程目的：幫助更多的學(xué)員入門WebRTC

本門課程分為以下章節(jié)：

（1）WebRTC入門

（2）WebRTC開(kāi)發(fā)環(huán)境搭建

（3）Coturn穿透和轉(zhuǎn)發(fā)服務(wù)器搭建

（4）音視頻采集和播放

（5）Nodejs實(shí)戰(zhàn)

（6）手把手實(shí)現(xiàn)音視頻一對(duì)一通話（包含信令協(xié)議設(shè)計(jì)挺峡、Web to Web、Android to Web度苔、 Android to Android）

（7）開(kāi)源方案介紹

（8）AppRTC開(kāi)源方案搭建

1 WebRTC入門

本章目的：

（1）了解什么WebRTC

（2）掌握WebRTC通話原理

（3）學(xué)完該課程的收獲

1.1 什么是WebRTC

WebRTC（Web Real-Time Communication）是 Google于2010以6829萬(wàn)美元從 Global IP Solutions 公司購(gòu)買，并于2011年將其開(kāi)源缀拭，旨在建立一個(gè)互聯(lián)網(wǎng)瀏覽器間的實(shí)時(shí)通信的平臺(tái)谆吴，讓 WebRTC技術(shù)成為 H5標(biāo)準(zhǔn)之一。我們看官網(wǎng)（https://webrtc.org）的介紹

從官網(wǎng)上的描述我們可以知道些侍，WebRTC是一個(gè)免費(fèi)的開(kāi)放項(xiàng)目，它通過(guò)簡(jiǎn)單的API為瀏覽器和移動(dòng)應(yīng)用程序提供實(shí)時(shí)通信（RTC）功能政模。

1.2 WebRTC框架

上圖的框架對(duì)于不同的開(kāi)發(fā)人員關(guān)注點(diǎn)不同：

（1）紫色部分是Web應(yīng)用開(kāi)發(fā)者API層

（2）藍(lán)色實(shí)線部分是面向?yàn)g覽器廠商的API層

（3）藍(lán)色虛線部分瀏覽器廠商可以自定義實(shí)現(xiàn)

特別是圖中的?PeerConnection?為 Web 開(kāi)發(fā)人員提供了一個(gè)抽象岗宣，從復(fù)雜的內(nèi)部結(jié)構(gòu)中抽象出來(lái)。我們只需要關(guān)注PeerConnection這個(gè)對(duì)象即可以開(kāi)發(fā)音視頻通話應(yīng)用內(nèi)淋样。

WebRTC架構(gòu)組件介紹

Your Web App

Web開(kāi)發(fā)者開(kāi)發(fā)的程序耗式，Web開(kāi)發(fā)者可以基于集成WebRTC的瀏覽器提供的web API開(kāi)發(fā)基于視頻、音頻的實(shí)時(shí)通信應(yīng)用趁猴。

Web API

面向第三方開(kāi)發(fā)者的WebRTC標(biāo)準(zhǔn)API（Javascript）刊咳，使開(kāi)發(fā)者能夠容易地開(kāi)發(fā)出類似于網(wǎng)絡(luò)視頻聊天的web應(yīng)用，最新的標(biāo)準(zhǔn)化進(jìn)程可以查看這里儡司。

WebRTC Native C++ API

本地C++ API層娱挨，使瀏覽器廠商容易實(shí)現(xiàn)WebRTC標(biāo)準(zhǔn)的Web API，抽象地對(duì)數(shù)字信號(hào)過(guò)程進(jìn)行處理捕犬。

Transport / Session

傳輸/會(huì)話層

會(huì)話層組件采用了libjingle庫(kù)的部分組件實(shí)現(xiàn)跷坝，無(wú)須使用xmpp/jingle協(xié)議

VoiceEngine

音頻引擎是包含一系列音頻多媒體處理的框架。

PS：VoiceEngine是WebRTC極具價(jià)值的技術(shù)之一碉碉，是Google收購(gòu)GIPS公司后開(kāi)源的柴钻。在VoIP上，技術(shù)業(yè)界領(lǐng)先垢粮。

Opus：支持從6 kbit/s到510 kbit/s的恒定和可變比特率編碼贴届，幀大小從2.5 ms到60 ms，各種采樣率從8 kHz（4 kHz帶寬）到48 kHz（20 kHz帶寬足丢，可復(fù)制人類聽(tīng)覺(jué)系統(tǒng)的整個(gè)聽(tīng)力范圍）粱腻。由IETF RFC 6176定義。

NetEQ模塊是Webrtc語(yǔ)音引擎中的核心模塊?斩跌，一種動(dòng)態(tài)抖動(dòng)緩沖和錯(cuò)誤隱藏算法，用于隱藏網(wǎng)絡(luò)抖動(dòng)和數(shù)據(jù)包丟失的負(fù)面影響捞慌。保持盡可能低的延遲耀鸦，同時(shí)保持最高的語(yǔ)音質(zhì)量。

VideoEngine

WebRTC視頻處理引擎

VideoEngine是包含一系列視頻處理的整體框架啸澡，從攝像頭采集視頻到視頻信息網(wǎng)絡(luò)傳輸再到視頻顯示整個(gè)完整過(guò)程的解決方案袖订。

VP8?視頻圖像編解碼器，是WebRTC視頻引擎的默認(rèn)的編解碼器

VP8適合實(shí)時(shí)通信應(yīng)用場(chǎng)景嗅虏，因?yàn)樗饕轻槍?duì)低延時(shí)而設(shè)計(jì)的編解碼器洛姑。

1.3 WebRTC發(fā)展前景

WebRTC雖然冠以“web”之名，但并不受限于傳統(tǒng)互聯(lián)網(wǎng)應(yīng)用或?yàn)g覽器的終端運(yùn)行環(huán)境皮服。實(shí)際上無(wú)論終端運(yùn)行環(huán)境是瀏覽器楞艾、桌面應(yīng)用参咙、移動(dòng)設(shè)備（Android或iOS）還是IoT設(shè)備，只要IP連接可到達(dá)且符合WebRTC規(guī)范就可以互通硫眯。這一點(diǎn)釋放了大量智能終端（或運(yùn)行在智能終端上的app）的實(shí)時(shí)通信能力蕴侧，打開(kāi)了許多對(duì)于實(shí)時(shí)交互性要求較高的應(yīng)用場(chǎng)景的想象空間，譬如在線教育两入、視頻會(huì)議净宵、視頻社交、遠(yuǎn)程協(xié)助裹纳、遠(yuǎn)程操控等等都是其合適的應(yīng)用領(lǐng)域择葡。

全球領(lǐng)先的技術(shù)研究和咨詢公司Technavio最近發(fā)布了題為“全球網(wǎng)絡(luò)實(shí)時(shí)通訊（WebRTC）市場(chǎng)，2017-2021”的報(bào)告剃氧。報(bào)告顯示敏储，2017-2021年期間，全球網(wǎng)絡(luò)實(shí)時(shí)通信（WebRTC）市場(chǎng)將以34.37％的年均復(fù)合增長(zhǎng)率增長(zhǎng)她我，增長(zhǎng)十分迅速虹曙。增長(zhǎng)主要來(lái)自北美、歐洲及亞太地區(qū)番舆。

1.4 國(guó)內(nèi)方案廠商

聲網(wǎng)酝碳、即構(gòu)科技、環(huán)信恨狈、融云等公司都在基于WebRTC二次開(kāi)發(fā)自己的音視頻通話方案疏哗。

聲網(wǎng)?https://www.agora.io/cn/

即構(gòu)科技?https://www.zego.im/

1.5 WebRTC通話原理

首先思考的問(wèn)題：兩個(gè)不同網(wǎng)絡(luò)環(huán)境的（具備攝像頭/麥克風(fēng)多媒體設(shè)備的）瀏覽器，要實(shí)現(xiàn)點(diǎn)對(duì)點(diǎn) 的實(shí)時(shí)音視頻對(duì)話禾怠，難點(diǎn)在哪里返奉？

1. 媒體協(xié)商 ?

彼此要了解對(duì)方支持的媒體格式

比如：Peer-A端可支持VP8、H264多種編碼格式吗氏，而Peer-B端支持VP9芽偏、H264，要保證二端都正確的編解碼弦讽，最簡(jiǎn)單的辦法就是取它們的交集H264

注：有一個(gè)專門的協(xié)議 污尉，稱為Session Description Protocol (SDP)，可用于描述上述這類信息往产，在WebRTC中被碗，參與視頻通訊的雙方必須先交換SDP信息，這樣雙方才能知根知底仿村，而交換SDP的過(guò)程锐朴，也稱為"媒體協(xié)商"。

2. 網(wǎng)絡(luò)協(xié)商

彼此要了解對(duì)方的網(wǎng)絡(luò)情況蔼囊，這樣才有可能找到一條相互通訊的鏈路

先說(shuō)結(jié)論：(1)獲取外網(wǎng)IP地址映射焚志；（2）通過(guò)信令服務(wù)器（signal server）交換"網(wǎng)絡(luò)信息"

理想的網(wǎng)絡(luò)情況是每個(gè)瀏覽器的電腦都是私有公網(wǎng)IP衣迷，可以直接進(jìn)行點(diǎn)對(duì)點(diǎn)連接。

實(shí)際情況是：我們的電腦和電腦之前或大或小都是在某個(gè)局域網(wǎng)中娩嚼，需要NAT（Network Address Translation蘑险，網(wǎng)絡(luò)地址轉(zhuǎn)換），顯示情況如下圖：

在解決WebRTC使用過(guò)程中的上述問(wèn)題的時(shí)候岳悟，我們需要用到STUN和TURN佃迄。

STUN

STUN（Session Traversal Utilities for NAT，NAT會(huì)話穿越應(yīng)用程序）是一種網(wǎng)絡(luò)協(xié)議贵少，它允許位于NAT（或多重NAT）后的客戶端找出自己的公網(wǎng)地址呵俏，查出自己位于哪種類型的NAT之后以及NAT為某一個(gè)本地端口所綁定的Internet端端口。這些信息被用來(lái)在兩個(gè)同時(shí)處于NAT路由器之后的主機(jī)之間創(chuàng)建UDP通信滔灶。該協(xié)議由RFC 5389定義普碎。

在遇到上述情況的時(shí)候，我們可以建立一個(gè)STUN服務(wù)器录平，這個(gè)服務(wù)器做什么用的呢麻车？主要是給無(wú)法在公網(wǎng)環(huán)境下的視頻通話設(shè)備分配公網(wǎng)IP用的。這樣兩臺(tái)電腦就可以在公網(wǎng)IP中進(jìn)行通話斗这。

使用一句話說(shuō)明STUN做的事情就是：告訴我你的公網(wǎng)IP地址+端口是什么动猬。搭建STUN服務(wù)器很簡(jiǎn)單，媒體流傳輸是按照P2P的方式表箭。

那么問(wèn)題來(lái)了赁咙，STUN并不是每次都能成功的為需要NAT的通話設(shè)備分配IP地址的，P2P在傳輸媒體流時(shí)免钻，使用的本地帶寬彼水，在多人視頻通話的過(guò)程中，通話質(zhì)量的好壞往往需要根據(jù)使用者本地的帶寬確定极舔。那么怎么辦凤覆？TURN可以很好的解決這個(gè)問(wèn)題。

TURN

TURN的全稱為Traversal Using Relays around NAT拆魏，是STUN/RFC5389的一個(gè)拓展叛赚，主要添加了Relay功能。如果終端在NAT之后稽揭， 那么在特定的情景下，有可能使得終端無(wú)法和其對(duì)等端（peer）進(jìn)行直接的通信肥卡，這時(shí)就需要公網(wǎng)的服務(wù)器作為一個(gè)中繼溪掀， 對(duì)來(lái)往的數(shù)據(jù)進(jìn)行轉(zhuǎn)發(fā)。這個(gè)轉(zhuǎn)發(fā)的協(xié)議就被定義為TURN步鉴。

在上圖的基礎(chǔ)上揪胃，再架設(shè)幾臺(tái)TURN服務(wù)器：

在STUN分配公網(wǎng)IP失敗后璃哟，可以通過(guò)TURN服務(wù)器請(qǐng)求公網(wǎng)IP地址作為中繼地址。這種方式的帶寬由服務(wù)器端承擔(dān)喊递，在多人視頻聊天的時(shí)候随闪，本地帶寬壓力較小，并且骚勘，根據(jù)Google的說(shuō)明铐伴，TURN協(xié)議可以使用在所有的環(huán)境中。（單向數(shù)據(jù)200kbps 一對(duì)一通話）

以上是WebRTC中經(jīng)常用到的2個(gè)協(xié)議俏讹，STUN和TURN服務(wù)器我們使用coturn開(kāi)源項(xiàng)目來(lái)搭建当宴。

補(bǔ)充：ICE跟STUN和TURN不一樣，ICE不是一種協(xié)議泽疆，而是一個(gè)框架（Framework）户矢，它整合了STUN和TURN。coturn開(kāi)源項(xiàng)目集成了STUN和TURN的功能殉疼。

在WebRTC中用來(lái)描述 網(wǎng)絡(luò)信息的術(shù)語(yǔ)叫candidate梯浪。

媒體協(xié)商 sdp

網(wǎng)絡(luò)協(xié)商 candidate

3. 媒體協(xié)商+網(wǎng)絡(luò)協(xié)商數(shù)據(jù)的交換通道

從上面1/2點(diǎn)我們知道了2個(gè)客戶端協(xié)商媒體信息和網(wǎng)絡(luò)信息，那怎么去交換瓢娜？是不是需要一個(gè)中間商去做交換挂洛？所以我們需要一個(gè)信令服務(wù)器（Signal server）轉(zhuǎn)發(fā)彼此的媒體信息和網(wǎng)絡(luò)信息。

如上圖恋腕，我們?cè)诨赪ebRTC API開(kāi)發(fā)應(yīng)用（APP）時(shí)抹锄，可以將彼此的APP連接到信令服務(wù)器（Signal Server，一般搭建在公網(wǎng)荠藤，或者兩端都可以訪問(wèn)到的局域網(wǎng)）伙单，借助信令服務(wù)器，就可以實(shí)現(xiàn)上面提到的SDP媒體信息及Candidate網(wǎng)絡(luò)信息交換哈肖。

信令服務(wù)器不只是交互 媒體信息sdp和網(wǎng)絡(luò)信息candidate吻育，比如：

（1）房間管理

（2）人員進(jìn)出房間

WebRTC APIs

MediaStream?—? MediaStream用來(lái)表示一個(gè)媒體數(shù)據(jù)流（通過(guò)getUserMedia接口獲取）淤井，允許你訪問(wèn)輸入設(shè)備布疼，如麥克風(fēng)和 Web攝像機(jī),該 API 允許從其中任意一個(gè)獲取媒體流。

RTCPeerConnection?— RTCPeerConnection 對(duì)象允許用戶在兩個(gè)瀏覽器之間直接通訊 币狠，你可以通過(guò)網(wǎng)絡(luò)將捕獲的音頻和視頻流實(shí)時(shí)發(fā)送到另一個(gè) WebRTC 端點(diǎn)游两。使用這些 Api，你可以在本地機(jī)器和遠(yuǎn)程對(duì)等點(diǎn)之間創(chuàng)建連接漩绵。它提供了連接到遠(yuǎn)程對(duì)等點(diǎn)贱案、維護(hù)和監(jiān)視連接以及在不再需要連接時(shí)關(guān)閉連接的方法。

4. 一對(duì)一通話

在一對(duì)一通話場(chǎng)景中止吐，每個(gè) Peer均創(chuàng)建有一個(gè) PeerConnection 對(duì)象宝踪，由一方主動(dòng)發(fā) Offer SDP侨糟，另一方則應(yīng)答 AnswerSDP，最后雙方交換 ICE Candidate 從而完成通話鏈路的建立瘩燥。但是在中國(guó)的網(wǎng)絡(luò)環(huán)境中秕重，據(jù)一些統(tǒng)計(jì)數(shù)據(jù)顯示，至少1半的網(wǎng)絡(luò)是無(wú)法直接穿透打通厉膀，這種情況下只能借助TURN服務(wù)器中轉(zhuǎn)溶耘。

5. NAT知識(shí)補(bǔ)充

具體NAT打洞的知識(shí)在本課程不做進(jìn)一步的講解，這里提供些鏈接給大家做參考：

P2P技術(shù)詳解(一)：NAT詳解——詳細(xì)原理站蝠、P2P簡(jiǎn)介?https://www.cnblogs.com/mlgjb/p/8243646.htm

P2P技術(shù)詳解(二)：P2P中的NAT穿越(打洞)方案詳解?http://www.reibang.com/p/9bfbcbee0abb

P2P技術(shù)詳解(三)：P2P技術(shù)之STUN汰具、TURN、ICE詳解?http://www.reibang.com/p/258e7d8be2ba

詳解P2P技術(shù)中的NAT穿透原理?http://www.reibang.com/p/f71707892eb2

1.6 課程收獲

WebRTC工作原理

WebRTC API的使用

WebRTC 一對(duì)一視頻通話開(kāi)發(fā)

AppRTC開(kāi)源項(xiàng)目搭建方法

常用的WebRTC開(kāi)源方案