WebRTC支持P2P，但是仍需要Server：
- 協調通訊過程中，Client之間需要交換Meta Data
- 需要處理NAT或FW
什么是信令
信令就是協調通訊的過程，為了建立一個WebRTC的通訊過程，客戶端需要交換如下信息：
- Session，用來開始和結束通話
- 處理錯誤的消息
- Meta Data，如各自的音視頻解碼方式、帶寬
- 網絡數據，如對方的公網IP、端口、內網IP及端口
信令處理過程需要Client能夠來回傳遞消息，這個過程WebRTC沒有實現，需要自己創建。
TURN和STUN
Meta Data是通過信令服務器中轉發給Client，但是對于流媒體數據，一旦會話建立，首先嘗試使用P2P連接。
WebRTC通過ICE框架來處理復雜的網絡環境
- ICE試著找最好的路徑來讓Client建立連接，嘗試所有可能的選項，選擇最優的方案
- ICE首先嘗試P2P連接，如果失敗就會通過TURN服務器進行轉發
換一個說法： - STUN服務器是用來取外網地址的
- TURN服務器是在P2P失敗時進行轉發的
STUN和TURN服務的主要作用是處理打洞和轉發，配合完成ICE協議
首先嘗試使用P2P，如果失敗將求助于TCP，使用TURN轉發兩個端點的音視頻數據，TURN轉發的是兩個端點之間的音視頻數據不是信令數據。因為TURN服務器是在公網上，所以他能被各個客戶端找到，另外TURN服務器轉發的是數據流，很占用帶寬和資源。
ICE技術
基于IP的語音、數據、視頻等業務在NGN（Next Generation Network）網絡中所面臨的一個實際困難就是如何有效地穿透各種NAT/FW的問題。對此，SIP（會話初始化協議）以往的解決方法由ALGs（(Application Layer Gateway Service)）、STUN、TURN等方式。
現在有一種新的媒體會話信令穿透NAT/FW的解決方案-交互式連通建立方式ICE。它通過綜合利用現有協議，以一種更有效的方式來組織會話建立過程，使之在不增加任何延遲同時比STUN等單一協議更具有健壯性、靈活性。多媒體會話信令協議是在準備建立媒體流傳輸的代理之間交互信息的協議，例如SIP、RTSP（real time streaming protocol）等。
媒體流與信令流截然不同，它們所采用的網絡通道也不一致。由于協議自身設計上的原因，使得媒體流無法直接穿透網絡地址轉換/防火墻(NAT/FW)。因為它們生存期的目標只是為了建立一個在信息中攜帶IP地址的分組流，這在遇到NAT/FW 時會帶來許多問題。而且這些協議的目標是通過建立P2P(Peer to Peer)媒體流以減小時延，而協議本身很多方面卻與NAT存在兼容性問題，
這也是穿透 NAT/FW的困難所在。
ICE簡介
交互式連通建立方式ICE(Interactive Connectivity Establishment)并非一種新的協議，它不需要對STUN、TURN或RSIP進行擴展就可適用于各種NAT。
ICE是通過綜合運用上面某幾種協議，使之在最適合的情況下工作，以彌補單獨使用其中任何一種所帶來的固有缺陷。對于SIP來說，ICE只需要定義一些SDP(Session Description Protocol)附加屬性即可，對于別的多媒體信令協議也需要制定一些相應的機制來實現。
流程
1. 收集傳輸地址
會話發起者需要收集的對象包括：
- 本地傳輸地址(Local Transport Address)
- 來源傳輸地址(Derived Transport Address)。
本地傳輸地址:
通常由主機上一個物理(或虛擬)接口綁定一個端口而獲得。
會話發起者還將訪問提供UNSAF(Unilateral self-address fixing)的服務器，例如STUN、TURN或TEREDO。
對于每一個本地傳輸地址，會話者都可以從服務器上獲得一組來源傳輸地址。
顯然，實現物理或虛擬連通方式越多，ICE將工作得越好。
但為了建立對等通信，ICE通常要求至少有一個來源地址由位于公網上的中繼服務器(如TURN)所提供的，而且需要知道具體是哪一個來源傳輸地址。
2. 啟動STUN
會話發起者獲得一組傳輸地址后，將在本地傳輸地址啟動STUN服務器，這意味著發送到來源地址的STUN服務將是可達的。
與傳統的STUN不同，客戶端不需要在任何其它IP或端口上提供STUN服務，也不必支持TLS， ICE用戶名和密碼已經通過信令協議進行交換。客戶端將在每個本地傳輸地址上同時接受STUN請求包和媒體包，所以發起者需要消除STUN消息與媒體流協議之間的歧義。
在RTP和RTCP中實現這個并不難，因為RTP與RTCP包總是以0b10(v=2)打頭，而STUN是0b00。對于每個運行STUN服務器的本地傳輸地址，客戶端都必須選擇相應的用戶名和密碼。用戶名要求必須是全局唯一的，用戶名和密碼將被包含在初始化消息里傳至響應者，由響應者對STUN請求進行鑒別。
3. 確定傳輸地址的優先級
STUN服務器啟動后，下一步就是確定傳輸地址的優先級。
優先級反映了UA在該地址上接收媒體流的優先級別，取值范圍在0到1之間，通常優先級按照被傳輸媒體流量來確定。
流量小者優先，而且對于相同流量者的Ipv6地址比Ipv4地址具有更高優先級。因此物理接口產生的本地Ipv6傳輸地址具有最高的優先級，然后是本地Ipv4傳輸地址，然后是STUN、RSIP、TEREDO來源地址，最后是通過VPN接口獲得的本地傳輸地址。
4. 構建Initiate Message
Initiate Message由一系列媒體流組成，每個媒體流都有一個缺省地址和候選地址列表。
缺省地址通常被Initiate Message映射到SIP信令消息傳遞地址上，而候選地址列表用于提供一些額外的地址。
對于每個媒體流來說，任意Peer之間實現最大連通可能性的傳輸地址是由公網上轉發服務器(如TURN)提供的地址，
通常這也是優先級最低的傳輸地址。
客戶端將可用的傳輸地址編成一個候選地址列表(包括一個缺省地址)，并且為每個候選元素分配一個會話中唯一的標識符。
該標識符以及上述的優先級都被編碼在候選元素的id屬性中。一旦初始化信息生成后即可被發送。
5. 響應處理：連通性檢查和地址收集
會話應答方接收到Initiate Message后，會同時做幾個事情：
首先執行收集傳輸地址中描述的地址收集過程。這些地址可以在呼叫到達前預收集，這樣可以避免增加呼叫建立的時間。
當獲得來源地址以后，應答方會發送STUN Bind請求，該請求要求必須包含Username屬性和Password屬性，屬性值為從 alt中得到的用戶名和密碼。
STUN Bind請求還應包括一個Message-Integrity屬性，它是由Initiate Message中候選元素的用戶名和密碼計算得來的。
此外，STUN Bind請求不應有Change-Request或Response-Address屬性。當一個客戶端收到Initiate Message時，它將通過其中的缺省地址和端口發送媒體流。如果STUN Bind請求消息引起錯誤應答，則需要檢查錯誤代碼。
如果是401，430，432或500，說明客戶端應該重新發送請求。如果錯誤代碼是400，431和600，那么客戶端不必重試，直接按超時處理即可。
6. 生成Accept Message
應答者可以決定是接受或拒絕該通信，若拒絕則ICE過程終止，若接受則發送Accept消息。
Accept消息的構造過程與Initiate Message類似。
7. Accept Message的處理
Accept過程有兩種可能。如果Initiate Message的接受者不支持ICE，則Accept Message將只包含缺省的地址信息，這樣發起方就知道它不用執行連通性檢查了。然而如果本地配置信息要求發起者通過TURN服務器發包來進行連通性檢查，這將意味著那些直接發給響應者的包會被對方防火墻丟棄。為解決這個問題，發起者需要重新分配一個TURN來源地址，然后使用Send命令。一旦Send命令被Accept，發起者將發送所有的媒體包到TURN服務器，由服務器轉發至響應者。如果Accept Message包含候選項，則發起方處理Accept Message的過程就與響應方處理Initiate Message很相似了。
8. 附加ICE過程
Initiate或Accept消息交換過程結束后，雙方可能仍將繼續收集傳輸地址，這通常是由于某些STUN事務過長而未結束引起，另一種可能是由于Initiate/Accept消息交換時提供了新的地址。
9. ICE到SIP的映射
使用ICE方式穿透NAT，必須映射ICE定義的參數到SIP消息格式中，同時對其SDP屬性進行簡單擴展——在SDP的Media塊中定義一個新的屬性alt來支持ICE。它包含一個候選IP地址和端口，SDP的接受端可以用該地址來替換m和c中的地址。
Media塊中可能會有多個alt屬性，這時每個alt應該包括不重復的IP地址和端口。
總結
ICE方式的優勢是顯而易見的，它消除了現有的UNSAF機制的許多脆弱性。例如，傳統的STUN有幾個脆弱點：
- 一個是發現過程需要客戶端自己去判斷所在NAT類型，這實際上不是一個可取的做法。而應用ICE之后，這個發現過程已經不需要了。
- 另一點脆弱性在于STUN、TURN等機制都完全依賴于一個附加的服務器， 而ICE利用服務器分配單邊地址的同時，還允許客戶端直接相連，因此即使STUN或TRUN服務器中有任何一個失敗了，ICE方式仍可讓呼叫過程繼續下去。
- 此外，傳統的STUN最大的缺陷在于它不能保證在所有網絡拓撲結構中都正常工作，最典型的問題就是Symmetric NAT。對于TURN或類似轉發方式工作的協議來說，由于服務器的負擔過重，很容易出現丟包或者延遲情況。 而ICE方式正好提供了一種負載均衡的解決方案，它將轉發服務作為優先級最低的服務，從而在最大程度上保證了服務的可靠性和靈活性。
- 此外，ICE的優勢還在于對
Ipv6的支持，目前Cisco等公司正在設計基于ICE方式的NAT/FW解決方案。
