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 穿透一般总是能成功
其他