前言：
WebRTC，名稱源自網頁實時通信（Web Real-Time Communication）的縮寫，簡而言之它是一個支持網頁瀏覽器進行實時語音對話或視頻對話的技術。
它爲我們提供了視頻會議的核心技術，包括音視頻的採集、編解碼、網絡傳輸、顯示等功能，並且還支持跨平臺：windows，linux，mac，android，iOS。
它在2011年5月開放了工程的源代碼，在行業內得到了廣泛的支持和應用，成爲下一代視頻通話的標準。
本文將站在巨人的肩膀上，基於WebRTC去實現不同客戶端之間的音視頻通話。這個不同的客戶端，不侷限於移動端和移動端，還包括移動端和Web瀏覽器之間。
目錄：
一.WebRTC的實現原理。
二.iOS下WebRTC環境的搭建。
三.介紹下WebRTC的API，以及實現點對點連接的流程。
四.iOS客戶端的詳細實現，以及服務端信令通道的搭建。
正文：
一.WebRTC的實現原理。
WebRTC的音視頻通信是基於P2P，那麼什麼是P2P呢？
它是點對點連接的英文縮寫。
1.我們從P2P連接模式來講起：
一般我們傳統的連接方式，都是以服務器爲中介的模式：
類似http協議：客戶端?服務端（當然這裏服務端返回的箭頭僅僅代表返回請求數據）。
我們在進行即時通訊時，進行文字、圖片、錄音等傳輸的時候：客戶端A?服務器?客戶端B。
而點對點的連接恰恰數據通道一旦形成，中間是不經過服務端的，數據直接從一個客戶端流向另一個客戶端：
客戶端A?客戶端B ... 客戶端A?客戶端C ...（可以無數個客戶端之間互聯）
這裏可以想想音視頻通話的應用場景，我們服務端確實是沒必要去獲取兩者通信的數據，而且這樣做有一個最大的一個優點就是，大大的減輕了服務端的壓力。
而WebRTC就是這樣一個基於P2P的音視頻通信技術。
2.WebRTC的服務器與信令。
講到這裏，可能大家覺得WebRTC就不需要服務端了麼？這是顯然是錯誤的認識，嚴格來說它僅僅是不需要服務端來進行數據中轉而已。
WebRTC提供了瀏覽器到瀏覽器（點對點）之間的通信，但並不意味着WebRTC不需要服務器。暫且不說基於服務器的一些擴展業務，WebRTC至少有兩件事必須要用到服務器：
瀏覽器之間交換建立通信的元數據（信令）必須通過服務器。
爲了穿越NAT和防火牆。
第1條很好理解，我們在A和B需要建立P2P連接的時候，至少要服務器來協調，來控制連接開始建立。而連接斷開的時候，也需要服務器來告知另一端P2P連接已斷開。這些我們用來控制連接的狀態的數據稱之爲信令，而這個與服務端連接的通道，對於WebRTC而言就是信令通道。
圖中signalling就是往服務端發送信令，然後底層調用WebRTC，WebRTC通過服務端得到的信令，得知通信對方的基本信息，從而實現虛線部分Media通信連接。
當然信令能做的事還有很多，這裏大概列了一下：
用來控制通信開啓或者關閉的連接控制消息
發生錯誤時用來彼此告知的消息
媒體流元數據，比如像解碼器、解碼器的配置、帶寬、媒體類型等等
用來建立安全連接的關鍵數據
外界所看到的的網絡上的數據，比如IP地址、端口等
在建立連接之前，客戶端之間顯然沒有辦法傳遞數據。所以我們需要通過服務器的中轉，在客戶端之間傳遞這些數據，然後建立客戶端之間的點對點連接。但是WebRTC API中並沒有實現這些，這些就需要我們來實現了。
而第2條中的NAT這個概念，我們之前在iOS即時通訊，從入門到“放棄”？ ，中也提到過，不過那個時候我們是爲了應對NAT超時，所造成的TCP連接中斷。在這裏我們就不展開去講了，感興趣的可以看看：NAT百科
這裏我簡要說明一下，NAT技術的出現，其實就是爲了解決IPV4下的IP地址匱乏。舉例來說，就是通常我們處在一個路由器之下，而路由器分配給我們的地址通常爲192.168.0.1 、192.168.0.2如果有n個設備，可能分配到192.168.0.n，而這個IP地址顯然只是一個內網的IP地址，這樣一個路由器的公網地址對應了n個內網的地址，通過這種使用少量的公有IP 地址代表較多的私有IP 地址的方式，將有助於減緩可用的IP地址空間的枯竭。
但是這也帶來了一系列的問題，例如這裏點對點連接下，會導致這樣一個問題：
如果客戶端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的NAT/防火牆穿越技術，就是基於上述的一個思路來實現的：
建立點對點信道的一個常見問題，就是NAT穿越技術。在處於使用了NAT設備的私有TCP/IP網絡中的主機之間需要建立連接時需要使用NAT穿越技術。以往在VoIP領域經常會遇到這個問題。目前已經有很多NAT穿越技術，但沒有一項是完美的，因爲NAT的行爲是非標準化的。這些技術中大多使用了一個公共服務器，這個服務使用了一個從全球任何地方都能訪問得到的IP地址。在RTCPeeConnection中，使用ICE框架來保證RTCPeerConnection能實現NAT穿越
這裏提到了ICE協議框架，它大約是由以下幾個技術和協議組成的：STUN、NAT、TURN、SDP，這些協議技術，幫助ICE共同實現了NAT/防火牆穿越。
小夥伴們可能又一臉懵逼了，一下子又出來這麼多名詞，沒關係，這裏我們暫且不去管它們，等我們後面實現的時候，還會提到他們，這裏提前感興趣的可以看看這篇文章：WebRTC protocols
http://www.cocoachina.com/ios/20170306/18837.html