- 從
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來講解一下這個過程
getUserMedia()把要寄的東西找出來，在WebRTC里面對應的就是獲取audio | video，以及對對獲取設備的選擇、分辨率的設置之類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.
- 通過
RTCPeerConnection()里的一系列API實現上述signaling過程，這個過程在下一節里面詳細分解 - 當然寄快遞有時候也會出現錯誤或者碰到異常情況（雖然現實中這種情況我沒遇到過），假如是每天都要發一次貨物的那種，
ICE restart，就是指去找新的發貨方式，在找到新的發貨渠道之前保持原來的方式，直到找到新的發貨方式
signaling的具體實現過程
- 先放一張示意圖（來源）
- 理論過程:
- Each peer creates an RTCPeerConnection object representing their end of the WebRTC session.
- Each peer establishes a handler for icecandidate events, which handles sending those candidates to the other peer over the signaling channel.
- 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. - 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.
- Each peer connects to an agreed-upon signaling server, such as a WebSocket server they both know how to exchange messages with.
- Each peer tells the signaling server that they want to join the same WebRTC session (identified by the token established in step 4).
- 用一個程序的時序圖總結一下，時序圖鏈接，這個連接的圖片太大，沒法粘貼到文章中，但是其中內容准確說明了整個連接的過程