在目前的网络环境中，由于IPv4地址资源的限制或出于网络安全的考虑，NAT设备广泛存在，如何使工作在应用层的SIP协议穿越NAT是SIP应用研究中的一个重要问题。
一、SIPNAT问题概述
NAT的英文全称是NetworkAddressTranslation，即网络地址转换，它是一个IETF 标准，允许一个机构以一个地址出现在Internet 上。NAT 将每个局域网节点的地址转换成一个IP 地址，反之亦然。它可以应用到防火墙技术里，把个别IP 地址隐藏起来不被外界发现，使外界无法直接访问内部网络设备，同时，它还帮助网络可以超越地址的限制，合理地安排网络中的公有Internet 地址和私有IP 地址的使用。
1．NAT类型
NAT设备在处理端口映射的方式以及与NAT外主机通信的方式上是不同的，按照这两种方式的不同可以分为四种类型：全通NAT（FullCone）；地址限制NAT（RestrictedCone）；
端口限制NAT（PortRestrictedCone）；对称性NAT（Symmetric）。
对于一个给定的私网源地址，前三种类型的NAT在一段时间内均为其维持一个公网地址映射，不管目的地址是否相同。而对称性NAT，为一个给定的私网源地址分配的地址映射依赖于包发送的目的地址，即为每一对不同的源和目的地址对分配一个不同的地址映射。
2.NAT与SIP
NAT技术目前主要应用于IP及UDP/TCP层，即对IP 包的地址及端口号进行转换，而SIP 协议是基于UDP/TCP 之上的应用层控制协议，SIP 包头中含有很多关于路由、接续SIP信令和建立呼叫连接的必不可少的地址信息，而且真正的媒体连接信息是放在SDP，即IP包的负载中传递的，这部分的私网地址在穿越NAT时不能被转换，因而造成SIP信令寻址不成功或媒体通道不能建立。
对于一个基于SIP的电话呼叫，可以分为两部分：第一部分是信令，也就是建立呼叫的协议消息；第二部分是实际传输的RTP媒体流，在两个终端设备或终端与网关之间。信令部分的NAT穿越相对简单，因为在典型的SIP系统中，终端离开NAT后的第一跳通常为默认的代理服务器，只要代理服务器将对方的消息发送到接收包的源地址，即可穿越上述的所有类型NAT。对于媒体流，由于是基于实时传输协议（RTP）和采用动态分配UDP端口方式，终端用户在实际传输媒体流之前是无法预知对方媒体流的对外端口的。当终端用户处在对称性NAT之后时，问题变得更加复杂。SIP/NAT问题就是SIP 消息及媒体流能否顺利穿越NAT 的问题。
随着语音和视频业务的蓬勃发展，SIP/NAT问题已成为基于SIP的VoIP技术在NAT设置的城域网和企业网中推广应用的最大障碍。
二、SIPNAT穿越技术进展
目前，业界对NAT穿透问题非常关注，也提出了多种解决方案。根据处理部分所在位置的不同，可以分为三种：客户端解决方案、路由边界解决方案以及服务器端解决方案。
1．客户端解决方案
客户端解决方案主要包括：STUN(simpletraversalof UDP through NAT)、TURN（Traversal Using Relay NAT）、ICE（Interactive Connectivity Establishment）。
STUN是一个轻量级的协议，允许应用程序探测当前在它们与公网之间是否存在NAT、防火墙以及它们的类型，并且具备能够探测到NAT所分配的公网地址和端口的能力。STUN协议中定义了两个实体：STUNClient和STUNServer。STUNClient嵌入在终端系统的应用程序中，比如SIP UA，它向STUN Server发送请求；STUN Server接收请求并产生STUN响应，它是无状态的。SIP终端在建立呼叫之前，通过向处在公网上的STUN服务器发送STUN请求，得到信令和媒体流在NAT上的映射地址，并且将这些地址填写到SIP消息中的Via、Contact字段以及SDP中的媒体流传输地址，替代原有的私有地址。但是，STUN只能工作在全通NAT、地址限制NAT以及端口限制NAT的网络环境下，在对称性NAT的情况下，SIP UA通过STUN请求得到的映射地址是无效的。
TURN协议在语法和操作上均与STUN相似，其优点是提供了对对称性NAT的穿越。处在公网的TURN服务器为客户端提供本身的一个外部IP地址和端口，并且负责中转通信双方的媒体流。TURN协议虽然支持所有类型的NAT穿越，但是它需要中转通信双方的媒体流，使得媒体流在传输过程中增加了一跳，不可避免地增加了包的延迟和丢包的可能性，而且完全使用TURN方式需要大量的TURN服务器，在有大量用户时，TURN服务器会成为系统瓶颈，因此我们应该尽量避免使用这种方法。目前，TURN的使用越来越少。
ICE目前已经被推认为在非对称性NAT环境下首选的客户端解决方案。ICE本身是一种方法，它利用STUN,TURN等任何符合UNSAF的协议来提供一个通用的解决方案。
2.路由边界解决方案
路由边界解决方案主要包括：应用层网关ALG、通用即插即用UPnP、中间盒通信MIDCOM。
应用层网关可以设计成能够识别指定IP协议（比如H.323和SIP协议）的防火墙，也被叫做ALGFirewall。它不是简单地察看包头信息来决定数据包是否可以通过，而是更深层的分析数据包负载内的数据，也就是应用层的数据。H.323和SIP协议都在负载中放了重要的控制信息，例如语音和视频终端使用哪一个数据端口来接收对方终端的语音和视频数据。通过分析哪一个端口需要打开，防火墙动态地打开那些被应用的端口，而所有别的端口依然安全地保持关闭状态。如果网络中有多层防火墙和NAT，则在呼叫路径上的每个防火墙都必须被升级以支持ALG功能。
UPnP是为了在电脑、智能设备和智能家电之间建立无所不在的网络连接而提出的协议体系。由微软公司发起，在1999年成立了一个开放的产业联盟UPnPForum，制订了一系列标准。其中的IGD(internetgatewaydevice)工作委员会提出了穿透NAT的解决方案，很多NAT设备制造商已经在新产品中支持这个协议。它以Internet 标准和技术(例如，TCP/IP、HTTP和XML)为基础，使这样的设备彼此可自动连接和协同工作，从而使网络(尤其是家庭网络)对更多的人成为可能。
MIDCOM是一种新出现的概念，其目的是使用第三方应用程序(包括硬件设备)来控制FireWall/NAT设备动态地决定安全策略，以适应VoIP业务。第三方的应用程序使用MIDCOM定义的协议(或私有协议)控制FireWall/NAT设备，根据“MultiMediaoverIP”的需要动态地打开呼叫信令、媒体流互通的IP地址和端口号，这样Firewall/NAT系统就无须嵌入过多的对“MultiMediaover IP”协议分析、解析的功能，而只需要维持已经存在的安全策略及转发机制，从而实现Firewall/NAT设备的穿透。
3．服务器端解决方案
服务器端解决方案主要包括：B2BUA（Back-to-BackUserAgent）、服务器端RTP中继。
B2BUA是一个接收请求并充当UAS处理请求的逻辑实体，主要是通过两个UA以Back-to-Back的工作模式控制经过它的呼叫。B2BUA与SIP代理服务器不同，B2BUA可以接收呼叫，并能对其进行修改，以其它形式代表发起呼叫的UA向终端目标发起呼叫，并能充当呼叫双方的媒体协商代表或对其进行监控管理。B2BUA可以对经过它的来自于私网的呼叫进行处理完成NAT的穿越。为适应所有类型NAT的环境，B2BUA也需要做媒体流的中介，因此，对于通信双方来说，呼叫控制信令和媒体流在传输过程中均增加了一跳，随着用户的增加，B2BUA将成为系统瓶颈。
服务器端RTP中继的方式相对B2BUA有所改进，它将B2BUA所完成的功能集成到了SIP代理服务器上，由SIP系统中的代理服务器完成信令部分的NAT处理修改，另外增设独立运行的媒体中继服务器来完成媒体流的中继。也就是说，将信令部分的NAT穿越和媒体流部分的NAT穿越分离开来，由不同的功能组件完成。服务器端RTP中继方式相对B2BUA来说，具有更好的可扩展性，目前已经被推认为在对称性NAT环境下的首选解决方案。
三、服务器端RTP中继的工作原理
通过中继RTP媒体流穿越NAT的方法，其工作原理可以简单描述为：SIP代理服务器对私网内用户呼叫的信令进行解析与处理，改写其中的某些头域，使得对应的响应消息以及随后的SIP信令可以顺利地在通信双方间传递；改写SDP中携带的RTP/RTCP地址信息，使得会话中随后的媒体流均经过指定的媒体中继服务器中继，从而完成信令和媒体流的NAT穿越。对于呼叫方和被叫方来说，媒体中继服务器均扮演着对方通信实体的角色。采用中继RTP媒体流穿越NAT方法建立会话的过程如图1所示。
SIP代理服务器需要修改的信息包括：
（1）最外层的Via头域：添加received和rport参数，记录下接收到消息的源地址，使得此消息对应的回应消息能顺利返回。
(2)Contact头域：修改成接收到消息的源地址，使得消息的接受者能将随后的消息发送到正确的地址。
(3)SDP中描述媒体的RTP/RTCP相应的IP地址和端口：对于需要NAT处理的会话邀请请求INVITE，SIP代理服务器请求媒体中继服务器分配地址和端口用以中继媒体流，并且将INVITE和200OK的SDP中的c=和m=参数修改成分配的地址，从而使双方媒体流通过媒体中继服务器中继。
媒体中继服务器的功能是中继转发会话双方的媒体流数据包。当一方的RTP数据包到达媒体中继服务器时，媒体中继服务器记录下发送数据包的源地址；当接收到另一方的数据包时，媒体中继服务器就知道了向何处转发。这是非常必要的，因为SIPUA媒体流只有真正穿过NAT 之后，NAT 地址映射关系才会建立，相应的映射地址才是可知的。
值得注意的是，媒体中继服务器只有在接收到通信两方发送的第一个RTP包之后，才能建立起中继路径，并转发会话双方的RTP媒体包。在对称性NAT的情况下，客户终端必须使用同一个IP地址/port端口来发送和接收RTP数据包，即为对称性RTP。
四、总结
综上所述，SIPNAT问题已有多种解决方案。客户端解决方案，虽然无需对现有NAT做任何改动，但对SIPUA的要求较高，需要支持相应的协议，而且到目前为止还无法解决通信双方均处在对称性NAT的情况；路由边界的各种解决方案，均需要对NAT设备升级，但目前网络实际已部署了大量的不支持相关特性的NAT设备，因而这种方式可行性较差；服务器端解决方案，通过中继RTP数据包来解决所有类型NAT的穿越，缺点就是增加了包的时延和丢包的可能性。具体采用哪种方式解决SIPNAT问题需要从以下角度进行综合考虑：（1）升级要求：哪些网络元素需要做升级；（2）网络业务量：应用这种解决方案后，是否会引入新的网络开销；（3）语音质量：此解决方案是否影响语音质量，增加时延或丢包率；（4）运营商的投资：运营商是否需要做大量投资；（5）企业投资：如果面向企业客户，企业是否需要做大量投资；（6）确定性：此解决方案是否只能在特定环境下生效，是否可以支持各种应用方案，是否可以穿越各种NAT；（7）扩展性：此方案是否支持大规模应用。
*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。
发布文章
