WebRTC相關的基礎知識點

這裏主要用來記錄本身整理的和webRTC相關的一些基本的知識點，後續整理的一些基礎和零碎的知識點都會更新在這裏。內容大部分來自於webRTC官網、w3c以及一些前輩們的博客中的文章和相關書籍等。

2017年12月3日更新：

1.peer connection相關的協議

ICE

交互式鏈接創建Interactive Connectivity Establishment (ICE) 是一個容許你的瀏覽器和對端瀏覽器創建鏈接的協議框架。在實際的網絡當中，有不少緣由能致使簡單的從A端到B端直連不能如願完成。這須要繞過阻止創建鏈接的防火牆，給你的設備分配一個惟一可見的地址（一般狀況下咱們的大部分設備沒有一個固定的公網地址），若是路由器不容許主機直連，還得經過一臺服務器轉發數據。ICE經過使用如下幾種技術完成上述工做。

STUN

NAT的會話穿越功能Session Traversal Utilities for NAT (STUN) (縮略語的最後一個字母是NAT的首字母)是一個容許位於NAT後的客戶端找出本身的公網地址，判斷出路由器阻止直連的限制方法的協議。

客戶端經過給公網的STUN服務器發送請求得到本身的公網地址信息，以及是否可以被（穿過路由器）訪問。

 

NAT

網絡地址轉換協議Network Address Translation (NAT) 用來給你的（私網）設備映射一個公網的IP地址的協議。通常狀況下，路由器的WAN口有一個公網IP，全部鏈接這個路由器LAN口的設備會分配一個私有網段的IP地址（例如192.168.1.3）。私網設備的IP被映射成路由器的公網IP和惟一的端口，經過這種方式不須要爲每個私網設備分配不一樣的公網IP，可是依然能被外網設備發現。

一些路由器嚴格地限定了部分私網設備的對外鏈接。這種狀況下，即便STUN服務器識別了該私網設備的公網IP和端口的映射，依然沒法和這個私網設備創建鏈接。這種狀況下就須要轉向TURN協議。

TURN

一些路由器使用一種「對稱型NAT」的NAT模型。這意味着路由器只接受和對端先前創建的鏈接（就是下一次請求創建新的鏈接映射）。

NAT的中繼穿越方式Traversal Using Relays around NAT (TURN) 經過TURN服務器中繼全部數據的方式來繞過「對稱型NAT」。你須要在TURN服務器上建立一個鏈接，而後告訴全部對端設備發包到服務器上，TURN服務器再把包轉發給你。很顯然這種方式是開銷很大的，因此只有在沒得選擇的狀況下采用。

SDP

會話描述協議Session Description Protocol (SDP) 是一個描述多媒體鏈接內容的協議，例如分辨率，格式，編碼，加密算法等。因此在數據傳輸時兩端都可以理解彼此的數據。本質上，這些描述內容的元數據並非媒體流自己。

參考自：https://developer.mozilla.org/zh-CN/docs/Web/API/WebRTC_API/Protocols

 

2.Native層peer connection相關API

以目前對peer connection demo的瞭解，使用native層peer connection API開發的時候主要涉及到下面兩類API

 

• Stream APIs (mediastreaminterface.h)

• PeerConnection APIs (peerconnectioninterface.h)

下面是參考 https://webrtc.org/native-code/native-apis/的關於兩類API的框

 

 

同時他也給出使用peer connection 的調用流程

PeerConnectionFactory類提供了用來建立PeerConnection, MediaStream 和 MediaStreamTrack的工廠方法（The PeerConnectionFactory class provides factory methods to create PeerConnection, MediaStream and MediaStreamTrack objects.）

發起通話

1. 建立一個PeerConnectionFactoryInterface（Create a PeerConnectionFactoryInterface. Check constructors for more information about input parameters）
2. 建立一個PeerConnection對象，提供一個用來生成ICE candidates的指向STUN 以及 TURN服務器的配置結構體。而且提供一個實現了PeerConnectionObserver接口的對象，用來接收PeerConnection的回調。（Create a PeerConnection object. Provide a configuration struct which points to STUN and/or TURN servers used to generate ICE candidates, and provide an object that implements the PeerConnectionObserver interface, which is used to receive callbacks from the PeerConnection）
3. 使用PeerConnectionFactory建立本地MediaStreamTracks，經過調用AddTrack方法（或者遺留的AddStream方法）把他們添加到PeerConnection。（Create local MediaStreamTracks using the PeerConnectionFactory and add them to PeerConnection by calling AddTrack (or legacy method, AddStream)）
4. 建立一個offer，調用SetLocalDescription，把它序列化而且發送到遠端peer（Create an offer, call SetLocalDescription with it, serialize it, and send it to the remote peer）
5. 一旦一個ICE candidate被生成了PeerConnection會調用observer函數OnIceCandidate，這個candidates必須也被序列化而且發送到遠端peer。（Once an ICE candidate has been gathered, the PeerConnection will call the observer function OnIceCandidate. The candidates must also be serialized and sent to the remote peer）
6. 一旦接收到了遠端peer的應答，調用SetRemoteDescription處理遠端的應答（Once an answer is received from the remote peer, call SetRemoteDescription with the remote answer.）
7. 一旦從遠端peer接收到了遠端candidate，調用AddIceCandidate把它提供給PeerConnection（Once a remote candidate is received from the remote peer, provide it to the PeerConnection by calling AddIceCandidate）

接收通話

1. 若是PeerConnectionFactoryInterface不存在的話就建立一個（Create PeerConnectionFactoryInterface if it doesn't exist.）
2. 建立一個新的PeerConnection（Create a new PeerConnection.）
3. 經過調用SetRemoteDescription提供一個遠端offer給新的PeerConnection對象（Provide the remote offer to the new PeerConnection object by calling SetRemoteDescription）
4. 經過調用CreateAnswer，給遠端offer生成一個answer而且把它發送給遠端peer（Generate an answer to the remote offer by calling CreateAnswer and send it back to the remote peer）
5. 經過調用SetLocalDescription來給新的PeerConnection提供一個本地應答（Provide the local answer to the new PeerConnection by calling SetLocalDescription with the answer）
6. 調用AddIceCandidate提供一個遠端ICE candidates（Provide the remote ICE candidates by calling AddIceCandidate.）
7. 一旦candidate生成了，PeerConnection會調用observer函數OnIceCandidate，把這些candidates發送給遠端peer（Once a candidate has been gathered, the PeerConnection will call the observer function OnIceCandidate. Send these candidates to the remote peer）

3. p2p創建流程

在不瞭解webRTC中p2p的創建流程的狀況下去分析peerconnection demo時，感受無從下手，因此應當先了解一下兩個peer是怎樣創建鏈接的。

WebRTC用 ICE協議來保證NAT穿越，因此它有這麼一個流程：咱們須要從 STUN Server中獲得一個 ice candidate，這個東西實際上就是公網地址

 

1. A和B鏈接上服務端，創建一個TCP長鏈接（任意協議均可以，WebSocket/MQTT/原生Socket/XMPP），這樣一個信令通道就有了。
2. A從ice server（STUN Server）獲取ice candidate併發送給Socket服務端，並生成包含session description（SDP）的offer，發送給Socket服務端。
3. Socket服務端把A的offer和ice candidate轉發給B，B會保存下A這些信息。
4. 而後B發送包含本身session description的answer(由於它收到的是offer，因此返回的是answer，可是內容都是SDP)和ice candidate給Socket服務端。
5. Socket服務端把B的answer和ice candidate給A，A保存下B的這些信息。

 

 

1. ClientA首先建立PeerConnection對象，而後打開本地音視頻設備，將音視頻數據封裝成MediaStream添加到PeerConnection中。
2. ClientA調用PeerConnection的CreateOffer方法建立一個用於offer的SDP對象，SDP對象中保存當前音視頻的相關參數。ClientA經過PeerConnection的SetLocalDescription方法將該SDP對象保存起來，並經過Signal服務器發送給ClientB。
3. ClientB接收到ClientA發送過的offer SDP對象，經過PeerConnection的SetRemoteDescription方法將其保存起來，並調用PeerConnection的CreateAnswer方法建立一個應答的SDP對象，經過PeerConnection的SetLocalDescription的方法保存該應答SDP對象並將它經過Signal服務器發送給ClientA。
4. ClientA接收到ClientB發送過來的應答SDP對象，將其經過PeerConnection的SetRemoteDescription方法保存起來。
5. 在SDP信息的offer/answer流程中，ClientA和ClientB已經根據SDP信息建立好相應的音頻Channel和視頻Channel並開啓Candidate數據的收集，Candidate數據能夠簡單地理解成Client端的IP地址信息（本地IP地址、公網IP地址、Relay服務端分配的地址）。
6. 當ClientA收集到Candidate信息後，PeerConnection會經過OnIceCandidate接口給ClientA發送通知，ClientA將收到的Candidate信息經過Signal服務器發送給ClientB，ClientB經過PeerConnection的AddIceCandidate方法保存起來。一樣的操做ClientB對ClientA再來一次。
7. 這樣ClientA和ClientB就已經創建了音視頻傳輸的P2P通道，ClientB接收到ClientA傳送過來的音視頻流，會經過PeerConnection的OnAddStream回調接口返回一個標識ClientA端音視頻流的MediaStream對象，在ClientB端渲染出來便可。一樣操做也適應ClientB到ClientA的音視頻流的傳輸。

 

至此A與B創建起了一個P2P鏈接。

參考自：

http://www.cnblogs.com/fangkm/p/4364553.html  

http://www.jianshu.com/p/c49da1d93df4