WebRTC支持P2P，但是仍需要Server：

• 協(xié)調(diào)通訊過程中甲捏，Client之間需要交換Meta Data
• 需要處理NAT或FW

什么是信令

信令就是協(xié)調(diào)通訊的過程演熟，為了建立一個WebRTC的通訊過程，客戶端需要交換如下信息：

• Session司顿，用來開始和結(jié)束通話
• 處理錯誤的消息
• Meta Data芒粹，如各自的音視頻解碼方式、帶寬
• 網(wǎng)絡(luò)數(shù)據(jù)大溜，如對方的公網(wǎng)IP化漆、端口、內(nèi)網(wǎng)IP及端口
  信令處理過程需要Client能夠來回傳遞消息钦奋，這個過程WebRTC沒有實現(xiàn)获三，需要自己創(chuàng)建。

TURN和STUN

Meta Data是通過信令服務(wù)器中轉(zhuǎn)發(fā)給Client锨苏，但是對于流媒體數(shù)據(jù)疙教，一旦會話建立，首先嘗試使用P2P連接伞租。
WebRTC通過ICE框架來處理復(fù)雜的網(wǎng)絡(luò)環(huán)境

• ICE試著找最好的路徑來讓Client建立連接贞谓，嘗試所有可能的選項，選擇最優(yōu)的方案
• ICE首先嘗試P2P連接葵诈，如果失敗就會通過TURN服務(wù)器進行轉(zhuǎn)發(fā)
  換一個說法：
• STUN服務(wù)器是用來取外網(wǎng)地址的
• TURN服務(wù)器是在P2P失敗時進行轉(zhuǎn)發(fā)的
  STUN和TURN服務(wù)的主要作用是處理打洞和轉(zhuǎn)發(fā)裸弦，配合完成ICE協(xié)議

首先嘗試使用P2P，如果失敗將求助于TCP作喘，使用TURN轉(zhuǎn)發(fā)兩個端點的音視頻數(shù)據(jù)理疙，TURN轉(zhuǎn)發(fā)的是兩個端點之間的音視頻數(shù)據(jù)不是信令數(shù)據(jù)。因為TURN服務(wù)器是在公網(wǎng)上泞坦，所以他能被各個客戶端找到窖贤，另外TURN服務(wù)器轉(zhuǎn)發(fā)的是數(shù)據(jù)流，很占用帶寬和資源贰锁。

ICE技術(shù)

基于IP的語音赃梧、數(shù)據(jù)、視頻等業(yè)務(wù)在NGN（Next Generation Network）網(wǎng)絡(luò)中所面臨的一個實際困難就是如何有效地穿透各種NAT/FW的問題豌熄。對此授嘀，SIP（會話初始化協(xié)議）以往的解決方法由ALGs（(Application Layer Gateway Service)）、STUN锣险、TURN等方式蹄皱。
現(xiàn)在有一種新的媒體會話信令穿透NAT/FW的解決方案-交互式連通建立方式ICE览闰。它通過綜合利用現(xiàn)有協(xié)議，以一種更有效的方式來組織會話建立過程巷折，使之在不增加任何延遲同時比STUN等單一協(xié)議更具有健壯性焕济、靈活性。多媒體會話信令協(xié)議是在準(zhǔn)備建立媒體流傳輸?shù)拇碇g交互信息的協(xié)議盔几，例如SIP晴弃、RTSP（real time streaming protocol）等。
媒體流與信令流截然不同逊拍，它們所采用的網(wǎng)絡(luò)通道也不一致上鞠。由于協(xié)議自身設(shè)計上的原因，使得媒體流無法直接穿透網(wǎng)絡(luò)地址轉(zhuǎn)換/防火墻(NAT/FW)芯丧。因為它們生存期的目標(biāo)只是為了建立一個在信息中攜帶IP地址的分組流芍阎，這在遇到NAT/FW 時會帶來許多問題。而且這些協(xié)議的目標(biāo)是通過建立P2P(Peer to Peer)媒體流以減小時延缨恒，而協(xié)議本身很多方面卻與NAT存在兼容性問題谴咸，
這也是穿透 NAT/FW的困難所在。

ICE簡介

交互式連通建立方式ICE(Interactive Connectivity Establishment)并非一種新的協(xié)議骗露，它不需要對STUN岭佳、TURN或RSIP進行擴展就可適用于各種NAT。
ICE是通過綜合運用上面某幾種協(xié)議萧锉，使之在最適合的情況下工作珊随，以彌補單獨使用其中任何一種所帶來的固有缺陷。對于SIP來說柿隙，ICE只需要定義一些SDP(Session Description Protocol)附加屬性即可叶洞，對于別的多媒體信令協(xié)議也需要制定一些相應(yīng)的機制來實現(xiàn)。

流程

1. 收集傳輸?shù)刂?/h6>

會話發(fā)起者需要收集的對象包括：

• 本地傳輸?shù)刂?Local Transport Address)
• 來源傳輸?shù)刂?Derived Transport Address)禀崖。

本地傳輸?shù)刂?
通常由主機上一個物理(或虛擬)接口綁定一個端口而獲得衩辟。
會話發(fā)起者還將訪問提供UNSAF(Unilateral self-address fixing)的服務(wù)器，例如STUN波附、TURN或TEREDO艺晴。
對于每一個本地傳輸?shù)刂罚瑫捳叨伎梢詮姆?wù)器上獲得一組來源傳輸?shù)刂贰?br> 顯然叶雹，實現(xiàn)物理或虛擬連通方式越多财饥，ICE將工作得越好换吧。
但為了建立對等通信折晦，ICE通常要求至少有一個來源地址由位于公網(wǎng)上的中繼服務(wù)器(如TURN)所提供的，而且需要知道具體是哪一個來源傳輸?shù)刂贰?/p>

2. 啟動STUN

會話發(fā)起者獲得一組傳輸?shù)刂泛笳赐撸瑢⒃诒镜貍鬏數(shù)刂穯覵TUN服務(wù)器满着，這意味著發(fā)送到來源地址的STUN服務(wù)將是可達的谦炒。
與傳統(tǒng)的STUN不同，客戶端不需要在任何其它IP或端口上提供STUN服務(wù)风喇，也不必支持TLS宁改， ICE用戶名和密碼已經(jīng)通過信令協(xié)議進行交換』昴客戶端將在每個本地傳輸?shù)刂飞贤瑫r接受STUN請求包和媒體包还蹲，所以發(fā)起者需要消除STUN消息與媒體流協(xié)議之間的歧義。
在RTP和RTCP中實現(xiàn)這個并不難耙考，因為RTP與RTCP包總是以0b10(v=2)打頭谜喊，而STUN是0b00。對于每個運行STUN服務(wù)器的本地傳輸?shù)刂肪胧迹蛻舳硕急仨氝x擇相應(yīng)的用戶名和密碼斗遏。用戶名要求必須是全局唯一的，用戶名和密碼將被包含在初始化消息里傳至響應(yīng)者鞋邑，由響應(yīng)者對STUN請求進行鑒別诵次。

3. 確定傳輸?shù)刂返膬?yōu)先級

STUN服務(wù)器啟動后，下一步就是確定傳輸?shù)刂?/strong>的優(yōu)先級枚碗。
優(yōu)先級反映了UA在該地址上接收媒體流的優(yōu)先級別逾一，取值范圍在0到1之間，通常優(yōu)先級按照被傳輸媒體流量來確定肮雨。
流量小者優(yōu)先嬉荆，而且對于相同流量者的Ipv6地址比Ipv4地址具有更高優(yōu)先級。因此物理接口產(chǎn)生的本地Ipv6傳輸?shù)刂?/code>具有最高的優(yōu)先級酷含，然后是本地Ipv4傳輸?shù)刂?/code>鄙早，然后是STUN、RSIP椅亚、TEREDO來源地址限番，最后是通過VPN接口獲得的本地傳輸?shù)刂贰?/p>

4. 構(gòu)建Initiate Message