几种方式解决SIP穿越NAT总结

SIP穿越NAT的几种方式多媒体会话信令协议是在准备建立媒体流传输的代理之间交换信息的协议，媒体流与信令流截然不同，它们所采用的网络通道也不一致。由于协议自身设计上的原因，使得媒体流无法直接穿透网络地址转换/防火墙(NAT/Firewall)。因为它们生存期的目标只是为了建立一个在信息中携带IP地址的分组流，这在遇到NAT/Firewall时会带来许多问题。而且这些协议的目标是通过建立P2P(PeertoPeer)媒体流以减小时延，而协议本身很多方面却与NAT存在兼容性问题，这也是穿透NAT/Firewall的困难所在。而NAT仍是解决当前公用IP地址紧缺和网络安全问题的最有力手段，所以解决NAT穿越成为首要问题。以SIP通信为例，呼叫建立和媒体通信的建立是依赖SIP消息首部和SDP消息所描述的地址和端口信息进行的，呼叫双方分别在内网和外网上，内网是通过NAT设备连接到外网，由于NAT设备工作在IP和TCP/UDP层，所以它不对SDP等应用层数据进行NAT变换，因此会造成寻址失败，从而导致呼叫无法正常建立。另外，VOIP设备的主要通信协议（如SIP和H.323）要求终端之间使用IP地址和端口号来建立端到端的数据侦听外来的呼叫，而防火墙却通常被配置阻止任何不请自到的数据分组通过。需要网络管理者打开防火墙上的一个端口来接收呼叫建立数据分组，例如5060端口（SIP的通信端口），但IP语音和视频通信协议还要求打开许多别的端口接收呼叫控制信息来建立语音和视频通信，这些端口号事先并不知道，是动态分配的，也就是说网络管理者为了允许语音和视频通信将不得不打开防火墙上所有的端口，防火墙就失去了存在的意义。所以当前的问题还有需要解决监听端口的问题。如下图SIP呼叫不成功示意图分析：1d:00:23766s:66:10102d:00:23766s:66:9993d:66:9993s:00:23766d:66:1010s:00:23766d:10:23788s:00:2020d:00:3399s:10:23788d:66:9993s:00:23766d:66:1010s:00:237669.d:00:3399s:10:2378810.d:66:9993s:00:2376611.d:66:1010s:00:2376612.d:10:23788s:66:1010d:10:23788s:66:999313.d:66s:10:23788A对Binvite时在SDP中带上了RTP协商的端口和私网IP，B回复200OK时告知RTP时的端口和私网地址，B收到A的RTP包后回复，因为RTP包记录是私网地址，所以RTP包被丢弃。目前主流的几种解决方式有ALG、STUN、TURN、ICE，我们分别来介绍它们的工作原理及工作流程。ALG1.1工作原理ALG是指能识别特定应用层协议（如SIP、H.323或MGCP协议）的防火墙。它不是简单地查看分组首部信息来解决数据分组是否可以通过，而是更深层地分析负载内容的数据，也就是应用层的数据。SIP和H.323协议都在负载中放了重要的控制信息。通过分析哪一个端口需要打开。防火墙动态的打开那些被应用的端口，而所有别的端口依然安全地保持关闭状态。ALG是支持VOIP应用最简单的一种方式，但该方案的缺点非常明显：每增加一种新的应用都将需要对NAT/Firewall进行升级。在安全要求上还需要作一些折衷，因为ALG不能识别加密后的报文内容，所以必须保证报文采用明文传送，这使得报文在公网中传送时有很大的安全隐患。SIP响应消息用于对请求消息进行响应，指示呼叫或注册的成功或失败状态。在请求与响应报文中需要进行ALG处理的地址字段类型主要有：Via、Record_Route、Contact、SDP。ALG处理流程为如下三个步骤：首先，ALG根据会话标识的协议类型对报文进行解码，若解码发现报文为不需要做ALG或解码发现为错误字段时退出，解码发现需进行字段转换时进一步处理；其次，ALG查找接口上的NAT配置，根据NAT配置转换报文中的IP地址、端口、call-id等信息并建立关联表，关联表记录了载荷地址的转换关系；最后，ALG调整报文载荷中的长度字段，如sipmessageheader的content-length字段标解决穿透NAT问题的另一思路是，私网中的VOIP终端通过某种机制预先得到出口NAT上的对外地址，然后在净载中所填写的地址信息直接填写出口NAT上的对外地址，而不是私网内终端的私有IP地址，这样净载中的内容在经过NAT时就无需被修改了，只需按普通NAT流程转换报文头的IP地址即可，净载中的IP地址信息和报文头地址信息是一致的。STUN协议就是基于此思路来解决应用层地址的转换问题。一旦客户端得知了Internet端的UDP端口，通信就可以开始了。如果NAT是完全圆锥型的，那么双方中的任何一方都可以发起通信。如果NAT是受限圆锥型或端口受限圆锥型，双方必须一起开始传输。需要注意的是，要使用STUNRFC中描述的技术并不一定需要使用STUN协议——还可以另外设计一个协议并把相同的功能集成到运行该协议的服务器上。SIP之类的协议是使用UDP分组在Internet上传输音频和／或视频数据的。不幸的是，由于通信的两个末端往往位于NAT之后，因此用传统的方法是无法建立连接的。这也就是STUN发挥作用的地方。STUN是一个客户机－服务器协议。一个VoIP电话或软件包可能会包括一个STUN客户端。这个客户端会向STUN服务器发送请求，之后，服务器就会向STUN客户端报告NAT路由器的公网IP地址以及NAT为允许传入流量传回内网而开通的端口。以上的响应同时还使得STUN客户端能够确定正在使用的NAT类型——因为不同的NAT类型处理传入的UDP分组的方式是不同的。四种主要类型中有三种是可以使用的：完全圆锥型NAT、受限圆锥型NAT和端口受限圆锥型NAT——但大型公司网络中经常采用的对称型NAT（又称为双向NAT）则不能使用。TURN3.1工作原理TURN的全称为TraversalUsingRelayNAT，即通过Relay方式穿越NAT，TURN应用模型通过分配TURNServer的地址和端口作为客户端对外的接受地址和端口，即私网用户发出的报文都要经过TURNServer进行Relay转发。这种方式又称SPAN(SimpleProtocolforAugmentingNATs)方式.TURN方式解决NAT问题的思路与STUN相似，也是基于私网接入用户通过某种机制预先得到其私有地址对应在公网的地址（STUN方式得到的地址为出口NAT上的地址，TURN方式得到地址为TURNServer上的地址），然后在报文负载中所描述的地址信息直接填写该公网地址的方式，实际应用原理也是一样的。这种方式除了具有STUN方式的优点外，还解决了STUN应用无法穿透对称NAT（SymmetricNAT）以及类似的Firewall设备的缺陷，即无论企业网/驻地网出口为哪种类型的NAT/FW，都可以实现NAT的穿透，同时TURN支持基于TCP的应用，如H323协议。此外TURNServer控制分配地址和端口，能分配RTP/RTCP地址对(RTCP端口号为RTP端口号加1)作为私网终端用户的接受地址，避免了STUN方式中出口NAT对RTP/RTCP地址端口号的任意分配，使得客户端无法收到对端发来的RTCP报文(对端发RTCP报文时，目的端口号缺省按RTP端口号加1发送)。TURN的局限性在于需要VOIP终端支持TURNClient，这一点同STUN一样对网络终端有要求。此外所有报文都必须经过TURNServer转发，增大了包的延迟和丢包的可能性。3.2网络拓扑图

3.3工作流程示意图A：0ANAT：00STUNSERVER：10B：1BNAT：20分析：d:10:1111s:0:10102d:10:1111s:00:20203d:00:2020s:00:20204d:0:1010s:00:20205d:20:2222s:1:30306d:20:2222s:10:40407d:10:4040s:20:22228d:1:3030s:20:2222A与B接收到TURN的响应消息就得到信令和媒体流在NAT上的映射地址，并将这些地址写到SIP消息中的Via,Contact字段以及SDP中的媒体流传送地址，代替原有的私网地址。如A的SDP带的端口为10000，B的SDP带的端口为20000，A、B相互告知对端它的端口，所以端口10000BNAT是打开的，端口20000ANAT是打开的，所以RTP包可路由。9d:10:1111s:00:555610d:20:2222s:10:1111d:1:3030s:20:222211d:10:4040s:20:655512d:00:5556s:10:4040d:0:1010s:00:2020ICE4.1工作原理交互式连通建立方式ICE(InteractiveConnectivityEstablishment)并非一种新的协议，它不需要对STUN、TURN或RSIP进行扩展就可适用于各种NAT。ICE是通过综合运用上面某几种协议，使之在最适合的情况下工作，以弥补单独使用其中任何一种所带来的固有缺陷。ICE跟STUN和TURN不一样，ICE不是一种协议，而是一个framework，它整合了STUN和TURN。使用ICE方式穿透NAT，必须映射ICE定义的参数到SIP消息格式中，同时对其SDP属性进行简单扩展—在SDP的Media块中定义一个新的属性“alt”来支持ICE。它包含一个候选IP地址和端口，SDP的接受端可以用该地址来替换m和c中的地址。Media块中可能会有多个alt属性，这时每个alt应该包括不重复的IP地址和端口。

对于SIP来说，ICE只需要定义一些SDP(SessionDescriptionProtocol)附加属性即可，对于别的多媒体信令协议也需要制定一些相应的机制来实现。其思想是：建立媒体流信道时，发出很多种选择，有本地端口，STUN端口，TURN端口，并给出这些端口的优先级，由被叫方自主选择端口，根据一定的算法和联通性测试，选出最好的端口来通信。ICE算法流程分为以F几个过程：

(1)收集本地传输地址

会话者从服务器上获得主机上一个物理(或虚拟)接口绑定一个端口的本地传输地址。

(2)启动STUN

与传统的STUN不同，ICE用户名和密码可以通过信令协议进行交换。

(3)确定传输地址的优先级

优先级反映了UA在该地址上接收媒体流的优先级别，取值范围0到1之间，按照被传输媒体流量来确定。

(4)构建初始化信息(InitiateMessage)

初始化消息由一系列媒体流组成，每个媒体流的任意Peer之间实现最人连通可能性的传输地址是由公网L转发服务器(如TURN)提供的地址。

(5)响应处理

连通性检查和执行ICE算法中描述的地址收集过程。

(6)生成接受信息(AcceptMessage)

若接受则发送Accept消息，其构造过程与InitiateMessage类似。

(7)接受信息处理

接受过程需要发起者使用Send命令，由服务器转发至响应者。(8)附加ICE过程

Initiate或Accept消息交换过程结束后，双方可能仍将继续收集传输地址。(9)ICE到SIP的映射4.2网络拓扑图4.3工作流程示意图举例：通信双方同时处于对称式NAT/FW内部，现在SIP终端A要与B进行VoIP通信。A所在的内部地址是，外部地址是0；B的内部地址是，外部地址是30；STUN/TURN服务器的地址是10。首先A发起请求，进行地址收集，如下图，收集了STUN服务映射的地址M：211.36.2930：9988，第二次收集了TURN服务映射的地址M：10：8076，第二次的IP和端口都改变了是因为NAT是对称型，重新映射一条路径。B进行地址收集，和A的过程是一致的。如下图，收集了STUN服务映射的地址M：30:10892，第二次收集了