WebRTC的RTCPeerConnection()原理探析

目錄

• 寫在前面
• WebRTC P2P的現實物理實現
• signaling的具體實現過程

• 從getUserMedia()到RTCPeerConnection()，自認爲難度陡增。我想一方面是以前在Linux平臺上學習ROS調用攝像頭時，對底層的外設接口調用、攝像頭參數都有學習理解；另外一方面是，咱們在大三下學期纔開始計算機網絡的課程學習，對網絡通訊的理解尚處於未能達到閉環的自閉狀態（自閉——"全程自學完成知識閉環"）
• 面對ICE、SDP、NAT gateways、STUN、TURN等詞彙異常懵逼（解釋能夠參考這篇introduction）因此寫文以下，增進本身的理解，也爲一樣對這部分困惑的人提供一份參考

寫在前面

• 目前，在看過一些WebRTC的資料以後，認爲RTCPeerConnection()是最難的但也是最關鍵的，一樣在RTCPeerConnection()中，signaling部分是最難的，但也是最重要的，我想弄清楚這個部分，對WebRTC的各類跨平臺搭建會很是有幫助（跨PC、Android、Raspberry Pi）

• 創建瞭解基本的計算機網絡知識，好比協議架構模型、設備之間的通訊所需的基本步驟

• OK，先忽略各類具體的API，從一個基於現實物理器械的現實角度看看WebRTC的P2P到底怎麼實現，參考Lifetime of a WebRTC session

WebRTC P2P的現實物理實現

• 想必你們都寄過快遞，給人寄快遞，就是一個很典型的P2P的過程，下面對應WebRTC來說解一下這個過程

1. getUserMedia() 把要寄的東西找出來，在WebRTC裏面對應的就是獲取audio | video，以及對對獲取設備的選擇、分辨率的設置之類

2. RTCPeerConnection() 的signaling，相似於選什麼快遞公司（communication protocols），要寄的東西要不要處理一下形式、要裝箱子寄仍是塑料袋就好、收到快遞打開使用有沒有注意事項（media codecs and formats），填好寄到的地址（IP adress and port information），而後快遞就能夠寄出了

   Signaling is the process of sending control information between two devices to determine the communication protocols, channels, media codecs and formats, and method of data transfer, as well as any required routing information.

   There are three basic types of information that need to be exchanged during signaling:

   • Control messages used to set up, open, and close the communication channel, and to handle errors.
   • Information needed in order to set up the connection: the IP addressing and port information needed for the peers to be able to talk to one another.
   • Media capability negotiation: what codecs and media data formats can the peers understand? These need to be agreed upon before the WebRTC session can begin.

3. 經過RTCPeerConnection() 裏的一系列API實現上述signaling 過程，這個過程在下一節裏面詳細分解

4. 固然寄快遞有時候也會出現錯誤或者碰到異常狀況（雖然現實中這種狀況我沒遇到過），假如是天天都要發一次貨物的那種，ICE restart，就是指去找新的發貨方式，在找到新的發貨渠道以前保持原來的方式，直到找到新的發貨方式

signaling的具體實現過程

• 先放一張示意圖（來源）

• 理論過程:

1. Each peer creates an RTCPeerConnection object representing their end of the WebRTC session.
2. Each peer establishes a handler for icecandidate events, which handles sending those candidates to the other peer over the signaling channel.
3. Each peer establishes a handler for track event, which is received when the remote peer adds a track to the stream. This code should connect the tracks to its consumer, such as a <video> element.
4. The caller creates and shares with the receiving peer a unique identifier or token of some kind so that the call between them can be identified by the code on the signaling server. The exact contents and form of this identifier is up to you.
5. Each peer connects to an agreed-upon signaling server, such as a WebSocket server they both know how to exchange messages with.
6. Each peer tells the signaling server that they want to join the same WebRTC session (identified by the token established in step 4).

• 用一個程序的時序圖總結一下，時序圖連接，這個鏈接的圖片太大，無法粘貼到文章中，可是其中內容準確說明了整個鏈接的過程