官網永遠是最重要，但同時也是最容易忽略的學習途徑。So you should look official websites firtsly.。

先看一看基礎概念的解釋
WebRTC 相關縮寫名詞簡介

推薦一種方式，打開官方給的例子，然后通過瀏覽器調試，定位到控制到就能夠看到這個流程了。WebRTC samples
如下：

• Offer/Answer 與 Signal Channel 是什麼？

WebRTC 必須透過某種中介伺服器才能建立連線，而我們稱這種媒介為「訊號通道 (Signal Channel)」。也就是說，在建立連線之前，會先透過訊號通道交換建立連線所需的資訊。

我們所要交換的資訊就是「Offer」與「Answer」，而其內容就是上述的 SDP。

當 Peer A 設立連線時，就會建立 Offer。接著會透過選定的訊號通道將此 Offer 傳送給 Peer B。在 Peer B 收到訊號通道傳來的 Offer 之後，就會建立 Answer，並透過同樣的訊號通道將 Answer 回傳給 Peer A。

• ICE Candidate 是什麼？

如上所述，Offer/Answer 與 SDP 用以交換多媒體的格式內容；ICE candidate 則用以交換網路連線的建立方式，並可說明端點溝通的方法 (直接通訊，或透過 TURN 伺服器通訊)。

概述

一、WebRTC 直播時代

二、A Closer Look Into WebRTCwebkit添加新內容

相關

一、音視頻云聲網Agora：從demo到實用，中間還差1萬個WebRTC

WebRtc協議棧

在這個例子中，我們將使用SIP-over-WebSocket（SIPoWS）作為信令棧。HTTP協議用于瀏覽器下載HTML5/JavaScript程序內容；NAT棧解決P2P連接問題；媒體棧用于發送和接收RTC的音頻和視頻。

二、為什么要有打洞服務

• IPv4用完
• 私有地址一致，用了同一網段，不能用內網地址，需要用外網地址。
• 在有防火墻和地址轉換時P2P需要UDP打洞：NAT后不能直接向廣域網那樣IP直接連接
• 不是所有 NAT 網絡都能打洞成功，連接就會建立失敗，只能服務器中轉。

環境搭建

一、Webrtc服務器搭建

• 通話的房間服務器(Room Server)
• 通話的信令服務器(Signaling Server)
• 防火墻打洞服務器(STUN/TURN/ICE Server)

二、iOS下音視頻通信-基于WebRTC非常全面的介紹，并且有Demo。大愛，跟著demo走一遍就熟了

嚴格來說它僅僅是不需要服務端來進行數據中轉而已。

WebRTC至少有兩件事必須要用到服務器：

• 瀏覽器之間交換建立通信的元數據（信令）必須通過服務器。

  • 我們在A和B需要建立P2P連接的時候，至少要服務器來協調，來控制連接開始建立。而連接斷開的時候，也需要服務器來告知另一端P2P連接已斷開。這些我們用來控制連接的狀態的數據稱之為信令，而這個與服務端連接的通道，對于WebRTC而言就是信令通道。
  • 在建立連接之前，客戶端之間顯然沒有辦法傳遞數據。所以我們需要通過服務器的中轉，在客戶端之間傳遞這些數據，然后建立客戶端之間的點對點連接。但是WebRTC API中并沒有實現這些，這些就需要我們來實現了。

• 為了穿越NAT和防火墻。

• WebRTC主要實現了三個API

1. MediaStream：通過MediaStream的API能夠通過設備的攝像頭及話筒獲得視頻、音頻的同步流
2. RTCPeerConnection：RTCPeerConnection是WebRTC用于構建點對點之間穩定、高效的流傳輸的組件
3. RTCDataChannel：RTCDataChannel使得瀏覽器之間（點對點）建立一個高吞吐量、低延時的信道，用于傳輸任意數據。
   其中RTCPeerConnection是我們WebRTC的核心組件。

• P2P連接的過程

1. A和B連接上服務端，建立一個TCP長連接（任意協議都可以，WebSocket/MQTT/Socket原生/XMPP），我們這里為了省事，直接采用WebSocket，這樣一個信令通道就有了。
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的這些信息。

三、WebRTC(iOS)下載編譯(下載指定版本)

點對點連接下，會導致這樣一個問題：

如果客戶端A想給客戶端B發送數據，則數據來到客戶端B所在的路由器下，會被NAT阻攔，這樣B就無法收到A的數據了。
但是A的NAT此時已經知道了B這個地址，所以當B給A發送數據的時候，NAT不會阻攔，這樣A就可以收到B的數據了。這就是我們進行NAT穿越的核心思路。

思路：
我們借助一個公網IP服務器。a、b都往公網IP/PORT發包,公網服務器就可以獲知a,b的IP/PORT，又由于a,b主動給公網IP服務器發包，所以公網服務器可以穿透NAT A,NAT B送包給a,b。
所以只要公網IP將b的IP/PORT發給a,a的IP/PORT發給b。這樣下次a和b互相消息，就不會被NAT阻攔了。

基礎概念

一、WebRTC入門教程.md

• STUN (Session Traversal Utilities for NAT) 只能UDP，告訴我暴露在廣域網的地址IP port ，我通過映射的廣域網地址進行P2P數據通信。
• TURN( Traversal Using Relays around for NAT)UDP或TCP， 打洞失敗后，提供服務器中轉數據，通話雙方數據都通過服務器，占服務器帶寬較大 - 為了確保通話在絕大多數環境下可以正常工作。跨網只能用服務器中轉（測試發現的） ，使用TURN這種情況在視頻通話中占10%
• ICE 網絡連接服務

二、WebRtc建立P2P鏈接的總體流程UML類圖非常不錯。

• 鏈接總體流程

  
  

• 時序圖

  
  

• 類圖

  
  

協議

一、NAT

NAT（Network Address Translation，網絡地址轉換）是1994年提出的。當在專用網內部的一些主機本來已經分配到了本地IP地址（即僅在本專用網內使用的專用地址），但現在又想和因特網上的主機通信（并不需要加密）時，可使用NAT方法。這種通過使用少量的公有IP 地址代表較多的私有IP 地址的方式，將有助于減緩可用的IP地址空間的枯竭。

• NAT實現方式：即靜態轉換Static Nat、動態轉換Dynamic Nat和端口多路復用OverLoad
• NAT穿透方法：目前常用的針對UDP的NAT 穿透（NAT Traversal）方法主要有：STUN、TURN、ICE、uPnP等。其中ICE方式由于其結合了STUN和TURN的特點，所以使用最為廣泛。針對TCP的NAT穿透技術目前仍為難點。實用的技術仍然不多。
• NAT工作原理：NAT將自動修改IP報文的源IP地址和目的IP地址，Ip地址校驗則在NAT處理過程中自動完成。有些應用程序將源IP地址嵌入到IP報文的數據部分中，所以還需要同時對報文的數據部分進行修改，以匹配IP頭中已經修改過的源IP地址。否則，在報文數據部分嵌入IP地址的應用程序就不能正常工作。簡單來講就是通過一個轉換頭，將內網地址變為公網地址，接收的時候根據記錄將公網地址變成內網，完成傳輸。

二、STUN

是一種網絡協議，它一種網絡協議，它允許位于NAT（或多重NAT）后的客戶端找出自己的公網地址，查出自己位于哪種類型的NAT之后以及NAT為某一 個本地端口所綁定的Internet端端口。這些信息被用來在兩個同時處于NAT 路由器之后的主機之間建立UDP通信。。目的就是找到外界連接內部地址的所需信息。

STUN是一個客戶機－服務器協議。一個VoIP電話或軟件包可能會包括一個STUN客戶端。這個客戶端會向STUN服務器發送請求，之后，服務器就會向STUN客戶端報告NAT路由器的公網IP地址以及NAT為允許傳入流量傳回內網而開 通的端口。

以上的響應同時還使得STUN客戶端能夠確定正在使用的NAT類型——因為不同的NAT類型處理傳入的UDP分組的方式是不同的。四種主要類型中有三種是可以使用的：完全圓錐型NAT、受限圓錐型NAT和端口受限圓錐型NAT——但大型公司網絡中經常采用的對稱型 NAT（又稱為雙向NAT）則不能使用。

三、STUN和TURN技術淺析 比較全面的分析

STUN（Simple Traversal of User Datagram Protocol Through Network Address Translators），即簡單的用UDP穿透NAT，是個輕量級的協議，是基于UDP的完整的穿透NAT的解決方案。它允許應用程序發現它們與公共互聯網之間存在的NAT和防火墻及其他類型。它也可以讓應用程序確定NAT分配給它們的公網IP地址和端口號。STUN是一種Client/Server的協議，也是一種Request/Response的協議，默認端口號是3478。

在現實Internet網絡環境中，大多數計算機主機都位于防火墻或NAT之后，只有少部分主機能夠直接接入Internet。很多時候，我們希望網絡中的兩臺主機能夠直接進行通信，即所謂的P2P通信，而不需要其他公共服務器的中轉。由于主機可能位于防火墻或NAT之后，在進行P2P通信之前，我們需要進行檢測以確認它們之間能否進行P2P通信以及如何通信。這種技術通常稱為NAT穿透（NAT Traversal）。最常見的NAT穿透是基于UDP的技術，如RFC3489中定義的STUN協議。

NAT對待UDP的實現方式有4種方式、簡單可以理解為：

1. 隨便搞，沒搞過的也可以搞
2. 只有搞過的才能搞
3. 之前帶過套的才能搞
4. 只有搞得爽的才能搞

TURN，首先在RFC5766中定義，英文全稱是Traversal Using Relays around NAT:Relay Extensions to Session Traversal Utilities for NAT，即使用中繼穿透NAT:STUN的擴展。簡單的說，TURN與STURN的共同點都是通過修改應用層中的私網地址達到NAT穿透的效果，異同點是TURN是通過兩方通訊的“中間人”方式實現穿透。

如果一個主機位于NAT的后面，在某些情況下它不能夠與其他主機點對點直接連接。在這些情況下，它需要使用中間網點提供的中繼連接服務。TURN協議就是用來允許主機控制中繼的操作并且使用中繼與對端交換數據。TURN與其他中繼控制協議不同的是它能夠允許一個客戶端使用一個中繼地址與多個對端連接。

四、WebRTC protocols

五、SDP 協議分析

SDP 完全是一種會話描述格式 ― 它不屬于傳輸協議 ― 它只使用不同的適當的傳輸協議，包括會話通知協議（SAP）、會話初始協議（SIP）、實時流協議（RTSP）、MIME 擴展協議的電子郵件以及超文本傳輸協議（HTTP）。SDP協議是也是基于文本的協議，這樣就能保證協議的可擴展性比較強，這樣就使其具有廣泛的應用范圍。SDP 不支持會話內容或媒體編碼的協商，所以在流媒體中只用來描述媒體信息。

六、試驗UDP打洞穿透NAT

比較全面的介紹了。備有例子

七、tun turn ice等穿越NAT方法大部分理論介紹

代碼分析

一、WebRtc重要概念

二、WebRtc 之P2C的建立

三、WebRtc語音整體框架

四、 webrtc android ios系列教程，五十多節，內容有點多。可以慢慢看