STUN
STUN協議爲終端提供一種方式能夠獲知自己經過NAT映射後的地址，從而替代位於應用層中的私網地址，達到NAT穿透的目的。STUN協議是典型的Client-Server協議，各種具體應用通過嵌入STUN客戶端與STUN Server端通訊來完成交互。
在典型的運用STUN進行NAT穿透的場景中，STUN客戶端首先向位於公網上的STUN服務器 發送Binding Request消息，STUN服務器接收到請求消息後識別出經過NAT轉換後的公網地址60.1.1.1:12345，將其附加在Binding Response消息中返回給客戶端。客戶端得到這個地址 後用它替換SDP中的私網地址與終端B完成媒體協商。使用STUN進行NAT穿透對應用的要 求是必須使用同樣的端口與STUN服務器交互和進行應用層通訊，比如當希望使用端口 37000進行RTP包的NAT穿透時，必須同樣使用37000端口與STUN服務器通訊，否則從STUN 服務器獲得的NAT映射後的地址一般與實際地址時不一樣的。另一個要求是STUN客戶端與 服務器端的通訊和應用使用獲得的NAT映射地址進行應用層通訊在時間上必須有連貫性， 這源於NAT設備建立的綁定有生存時間，當原綁定消亡後，NAT設備爲同一個私網地址建 立的新綁定往往不同，因此轉換後的公網地址是不同的。
STUN方案的特性如下表：
|
特性 |
說明 |
|
實現複雜度 |
實現簡單 |
|
TCP穿透支持 |
不支持 |
|
對現有設備的要求 |
要求客戶端支持，對現有NAT設備無改動要求，需增加STUN服務器 |
|
可擴展性 |
可擴展性好，與具體協議無關 |
|
安全性 |
一般 |
|
健壯性 |
差，不支持symmentric型NAT |
|
其他 |
支持自動檢測NAT類型，使用戶即使在使用STUN協議無法實現NAT 穿透時還可以根據NAT類型自主選擇其他可使用的NAT穿透方案 |
TURN
TURN解決NAT穿透的思路與STUN類似，都是通過修改應用層中的私網地址達到NAT穿透。 與STUN不同的是，TURN是通過兩方通訊的“中間人”的方式實現穿透，在這種方式下， 要進行通訊的兩方分別與位於公網上的TURN服務器建立各自的連接進行通訊，由服務器負 責在兩方之間進行數據轉發。要達到這個目的，實現TURN客戶端的終端必須在通訊開始前 與TURN服務器進行交互，得到服務器爲其臨時分配的位於TURN服務器上的公網地址，客戶端使用它替換位於應用層中的私網地址。
TURN方案的特性如下表：
|
特性 |
說明 |
|
實現複雜度 |
難於實現。TURN的安全性設計增加終端設置的複雜度 |
|
TCP穿透支持 |
支持 |
|
對現有設備的要求 |
對現有NAT設備無要求，要求客戶端支持，需增加TURN服務器s |
|
可擴展性 |
可擴展性好，與具體協議無關 |
|
安全性 |
一般 |
|
健壯性 |
好，支持所有類型的NAT |
|
其他 |
與P2P穿透方式相比，性能時relay穿透方式的弱點。另外TURN無法 實現負載分擔，解決的方式是把media relay服務器的分配工作放在 SIP proxy完成 |
ICE
與STUN和TURN相比，ICE並非是解決NAT穿透問題的協議，而是一個框架，在這個框架中， 可以整合其他現存的NAT穿透協議，如STUN、TURN、RSIP等。區別於其他的NAT穿透解 決方案，ICE是一種探索和更新式的解決方案，通過蒐集自身和對端儘可能多的網絡信息（各種網絡地址），嘗試在這些地址間建立數據通道，並在這一過程中不斷更新先前收集到的信息，從而找出和選擇能夠進行NAT穿透的數據通道。
ICE方案的特性如下表：
|
特性 |
說明 |
|
實現複雜度 |
一般 |
|
TCP穿透支持 |
支持 |
|
對現有設備的要求 |
對NAT設備無要求，支持所有類型的NAT設備。客戶端必須支持， 網路結構中需增加STUN/TURN服務器 |
|
可擴展性 |
可擴展性好，與具體協議無關 |
|
安全性 |
較好 |
|
健壯性 |
好，適用與所有NAT及NAT拓撲類型，且由於存在中繼服務器，NAT 穿透一般總是能成功 |
|
其他 |