iOS下WebRTC音視頻通話（一）

在iOS下作IM功能時，不免都會涉及到音頻通話和視頻通話。QQ中的QQ電話和視頻通話效果就很是好，可是若是你沒有很是深厚的技術，也沒有那麼大的團隊，很難作到QQ那麼快速和穩定的通話效果。

可是利用WebRTC技術，即便一我的也可以實現效果不錯的音視頻通話。本篇介紹WebRTC的基礎概念。

WebRTC介紹

WebRTC，名稱源自網頁實時通訊（Web Real-Time Communication）的縮寫，是一個支持網頁瀏覽器進行實時語音對話或視頻對話的技術，是谷歌2010年以6820萬美圓收購Global IP Solutions公司而得到的一項技術。

WebRTC（Web Real-Time Communication）項目的最終目的主要是讓Web開發者可以基於瀏覽器（Chrome\FireFox...）輕易快捷開發出豐富的實時多媒體應用，而無需下載安裝任何插件，Web開發者也無需關注多媒體的數字信號處理過程，只需編寫簡單的Javascript程序便可實現。可是通過多年的打磨，WebRTC如今已經能夠在windows，linux，mac，android，iOS等多個平臺中使用。

WebRTC除了能夠用來作音頻通話、視頻通話，還能夠用來作視頻會議。

其餘關於WebRTC的介紹能夠參考：百度百科-WebRTC 以及 WebRTC官網

WebRTC 過程

WebRTC 利用RTCPeerConnection能夠創建點對點高效、穩定的音頻、視頻流傳輸。可是在進行點對點的流傳輸以前，它依然還須要利用服務器來作一些準備工做。而準備工做須要用到的東西就比較多了，好比STUN服務器、TURN服務器、ICE（NAT和防火牆穿透）、信令傳輸，相互之間的信令交換完畢，就會發送實時音視頻留給對方。

進行音視頻通話的完整過程：

• 一、首先設置好STUN服務器、和TURN服務器，而後將STUN服務器和TURN服務器包裝成RTCICEServer對象，保存進數組備用。
• 二、利用上一步的數組建立RTCPeerConnection鏈接。
• 三、爲RTCPeerConnection添加RTCMediaStream，而RTCMediaStream內包含視頻和音頻軌跡，只是作一些配置，而後WebRTC內部按照你的配置作音頻、視頻的採集。若是你只爲RTCMediaStream添加音軌，就是作音頻通話；同時添加音軌和視頻軌跡，則是作視頻通話；只添加視頻軌跡，則只能看到視頻畫面，沒有聲音。（這些都是在採集端設置）
• 四、爲視頻軌跡設置渲染的容器，便於開始音視頻通話後，將實時視頻畫面渲染到視圖上。（若是是音頻通話則沒有視頻軌跡，就不須要渲染）
• 五、發起方建立Offer，建立完成後會返回一個本地SessisonDescription（簡稱sdp，其實就是一些媒體和網絡相關的元數據信息），而後爲RTCPeerConnection設置本地sdp（RTCPeerConnection須要設置遠程sdp和本地sdp完成後才能進行點對點的流傳輸）。
• 六、將本地sdp信息設置完成後，將本地sdp發送給對方（這個過程就是將本地offer信令發送給對方）。
• 七、接收方收到offer信令以後，重複上面的一、二、三、4，而後將接收到的offer sdp設置爲本身的遠程sdp，而後再建立一個Answer。一樣的建立完成後會返回一個SessisonDescription，將這個sdp設置爲RTCPeerConnection的本地sdp，設置完成後再將answer發送給發起方。
• 八、發起方收到answer後，將answer sdp設置爲RTCPeerConnection的遠程sdp。
• 九、而後雙方就開始互相發送多媒體流數據，整個音視頻通話就完成了。

說明 STUN服務器、TURN服務器地址其實就是個url而已：stun:stun.l.google.com:19302，turn:numb.viagenie.ca，其中STUN服務器和TURN服務器能夠在自家的服務上建立，STUN、TURN服務器能夠有多個，作備用。

ICE，本端會生成全部網絡接口對應不一樣協議的Candidate。 每個Candidate實際上描述了和本身的通訊方式。好比一個STUN類型的Candidate會包含本端在防火牆外的IP和端口類型。本端會經過信令協議（sip/xmpp/http）將本身的全部的Candidate發送給對端。對方接收到後，會嘗試鏈接， 並找到一個最好的鏈接方式創建和本端的鏈接，以後的流媒體數據將經過此鏈接傳輸。

關於Candidate，是對本端網絡通訊能力的一種描述。對於UDP/STUN協議，Candidate僅包含IP及端口信息，對於TURN，包含TURN server的IP，端口，以及用戶名密碼等。Candidate由本端代碼生成，生成後經過信令發送給對端。對端會在本端全部的candidate中選擇一個最好的創建與本端的鏈接。

除了上面那些服務器外，還須要一些額外的服務器用來發現用戶，好比XMPP服務，主要是爲了維護用戶的關係以及保持其在線、離線等狀態。

WebRTC框架內不提供信令服務，所以信令信息的發送和接收處理須要咱們本身去處理。處理的方式也有不少種，好比利用XMPP的的發送和接收消息的機制，將信令信息發送給對方；也能夠用Http網絡將信令消息發送給對方；還能夠利用WebSocket將信息發送給對方。

先大體瞭解WebRTC交互的過程，便於後面理解代碼。

下一篇我會編寫一個在同路由器 的局域網內進行視頻通話的Demo。

關於WebRTC概念性的理解下面有幾篇文章，文章內也有一些連接都是很好的資料：

使用WebRTC搭建前端視頻聊天室——入門篇

使用WebRTC搭建前端視頻聊天室——信令篇

WebRTC的RTCDataChannel

雖然以上三篇主要是講Web前端的WebRTC使用，可是過程和概念概括的很是好，能夠多讀幾遍。

WebRTC and the Early API

WebRTC代理中的各類枚舉狀態

P2P傳輸，其中Candidate的做用以及P2P鏈接的過程介紹的對理解很是有幫助。

WebRTC中文網 其實iOS 中WebRTC的處理過程與Web端的處理過程除了API命名不一樣，過程基本是一致的。

重要的是經過編寫代碼，而後對照代碼的每一步去思考它這樣作是爲了幹啥。

Have Fun!