【WebRTC】NAT機制和傳輸機制
1.NAT機制
WebRTC對內網上的主機建立連線需要NAT，即網路地址轉換。
WebRTC直接採用了Libjingle中關於傳輸部分的元件。
Libjingle是Google公司開發的實現P2P傳輸的C++開源庫，Google Talk就是基於這個庫開發的。通過Libjingle可以建立一個直通的網路連線，可以無需關心中間的NAT，防火牆，中繼伺服器和代理, 會話建立的細節，直接進行資料的交換。
Libjingle中採用的是ICE這種綜合性的NAT穿越框架。ICE綜合運用基於UDP的STUN和基於TCP的TURN協議來實現。使用ICE的應用程式需要一個ICE代理來負責ICE，STUN，TURN以及其他模組的互動，發現本地裝置的網路的拓撲結構的資訊，找到一條路徑或者通過該路徑通訊。每個代理都有一些可以用於與遠端主機代理通訊的候選傳輸地址(candidate)。在網路中，每個代理可有自己的STUN伺服器，也可公用一個。本地計算機收集到所有的候選傳輸地址，將它們按優先順序高低進行排序，然後通過信令通道傳送給遠端計算機。這些候選傳輸地址作為SDP請求的屬性被傳輸。當遠端計算機收到請求後進行相同的收集過程，並且把自己的候選傳輸地址作為響應訊息傳送給請求者。這樣，每個代理都有一個完整的包含了雙方候選傳輸地址的列表，即可進行後續資料傳輸。
WebRTC中這一過程由瀏覽器底層實現，每個PeerConnection API生成一個ICE代理，當一個新的ICE候選連線可用時，ICE代理將通過一個回撥函式通知應用程式。當所有的候選地址蒐集齊之後，回撥函式也會通過觸發來通知應用程式已經完成蒐集工作。
STUN需要一個公網IP的STUN伺服器，使防火牆後的客戶端找出自己的公網地址，這可以完成92%的穿越。大約8%的概率無法通過上述方式成功建立連線時就需要採用中繼伺服器，即採用TURN協議。
2.傳輸機制
WebRTC的傳輸模組重用了LibJingle的部分元件，WebRTC技術在瀏覽器內部集成了一系列的網路傳輸及會話控制相關協議。傳輸及會話控制的實現重用了Libjingle專案的部分程式碼。RTP棧是RTP實時傳輸協議，該協議為實時媒體應用提供了一個傳輸音訊和視訊資料的方案。