sip基于nat穿越

Vol .33 No.22 Computer Engineering · 网络与通信 ·

文章编号：1000—3428(2007)22—0148—03

文献标识码：A

2007年11月

November2007

中图分类号：TP393

基于代理的SIP穿越NAT和防火墙方案

蔡闻怡，陈一民

（上海大学计算机工程与科学学院，上海 200072）

摘 要：SIP协议作为NGN重要协议之一，广泛应用于VoIP等多媒体通信业务中。但由于SIP本身不支持SIP信令和媒体流穿越NAT和防火墙，了其在广域网上的应用和发展。该文分析了SIP穿越NAT的具体问题，提出了一种采用SIP和RTP代理服务器协同工作穿越NAT和防火墙解决方案，介绍了该方案的实现原理、拓扑结构，并叙述了具体实现过程及涉及的相关技术，最终实现了SIP信令流和媒体流的NAT和防火墙穿越。

关键词：会话初始化协议；NAT；SIP代理服务器；RTP代理服务器；媒体网关控制协议

Proxy-based Solution About SIP Traversing NAT and Firewall

CAI Wen-yi, CHEN Yi-min

(School of Computer Engineering and Science, Shanghai University, Shanghai 200072)

【Abstract】As one of the important protocol of NGN, SIP is widely used in multimedia communication transactions such as VoIP. But SIP can nottraverse NAT/Firewall, which blocks the development of it on WAN. With the analysis of problems about SIP/NAT traversal, a schemeis proposedto support SIP signal and media stream traversing NAT/FW with the cooperation of SIP proxy and RTP proxy. The principle and topologyof theschema is presented and the implementation how to traverse NAT/FW is described. 【Key words】SIP; NAT; SIP proxy; RTP proxy; media gateway control protocol(MGCP)

SIP [1]是一种应用层控制与信令协议，用于创建、修改和结束与一个或多个参与者的会话。SIP协议以其更加开放、易扩展、与Internet紧密结合等特性，逐渐成为VoIP主流协议。对于基于SIP控制协议的多媒体(音频和视频)应用，NAT/FW设备很难支持，其原因涉及IP地址私有化、防火墙包过滤策略等方面。目前，SIP穿越NAT问题已有客户端、服务器端、路由边界等多种解决方案。客户端解决方案无需改动现有NAT，但对SIP UA要求较高，需要支持相应协议；路由边界解决方案需要对现有NAT设备升级以支持相关协议；服务器端解决方案需要考虑传输时延和丢包率[2]。 在众多方案中，代理(proxy)技术无论从可扩展性、对现有设备的改造要求、安全性等方面，都显示出一定优势。代理方式通过对信令和媒体同时做Relay来实现NAT/FW穿越，使终端到终端的呼叫过程可视无需对现有NAT作任何改动，为两个分离的呼叫：从私网上的终端到代理以及从代理到公网上的终端，代理通过对呼叫进行中转解决NAT问题。然而，一般代理方式需要代理设备同时对信令和媒体进行中继转发，工作效率会受影响，还增加了数据包时延和丢包可能性。为此，本文提出在原有SIP代理服务器的基础上增加一个单独的RTP代理服务器，由SIP代理服务器完成信令部分的NAT处理，由运行的RTP媒体中继服务器完成媒体流中继，两者之间通过媒体网关控制协议(MGCP)进行协作，将信令和媒体流部分的NAT穿越分离开，由不同功能组件完成，使系统具有更好的可扩展性。 穿越NAT/FW主要的问题如图1所示[3]。INVITE sip:UA2@domain2.com SIP/2.0 Via:SIP/2.0/UDP 192.168.0.1:5060 From:UA1;tag=92 To:UA2 Call-Id: 12345678 CSeq: 9586afcs INVITE Contact:UA1 Content-Type: application/sdp Content-Length: 200 c=IN IP4 192.168.0.1 m=audio 49170 RTP/AVP 0 SIP不能穿越NAT/FW的问题如下： (1)当公网用户收到INVITE消息并发送对应的200OK响应消息时，响应消息将被发往由Via头字段指定的私有地址。由于私有地址在公网上不能路由，因此响应消息无法传送。 (2)contact头字段中指定的地址被用于对话中的后续请求，但是其包含的私有地址导致后续请求无法通过路由器在公网上正确路由。NAT只对IP层和TCP/UDP层的地址和端口进行转换，而SIP协议是应用层协议，通过应用层报文的交互来协商双方使用的IP地址和端口号，NAT/FW无法对应用层报文内部的信息进行处理，因而造成SIP信令寻址不成功或无法建立媒体通道。 (3)当公网用户向处于NAT之后的私网用户发送RTP数作者简介：蔡闻怡(1981－)，女，硕士，主研方向：多媒体网络通信；陈一民，教授、博士生导师

收稿日期：2007-01-04 E-mail：caiwenyi_1007@163.com

1 SIP穿越NAT/FW的问题 下面是一个INVITE消息的例子，从私网通过NAT发送至公网。其中包含的不可路由地址的头字段用粗体显示。SIP ——148

据包时，将采用INVITE消息中SDP部分c参数指定的地址。可是其指定的私有地址导致RTP包在公网上无法路由。此外，在控制信息中动态地协商分配的媒体流端口也为在NAT/FW上配置固定的包过滤策略带来了困难。 Private NetworkPublic Network

INVITE 数据包INVITE 数据包INVITE 数据包Via: 192.168.0.1Via: 192.168.0.1Via: 192.168.0.1Contact:192.168.0.1Contact:192.168.0.1Contact:192.168.0.1Appc=IN IP4 192.168.0.1Appc=IN IP4 192.168.0.1Appc=IN IP4 192.168.0.1Layerm=8000Layerm=8000Layerm=8000IP192.168.0.1: 5060IPIPLayerLayer220.110.1.2: 9020Layer220.110.1.2: 9020RouterSignallingSignallingSignallingUA 1NAT/FW200 OK 数据包

UA 2192.168.0.1

202.120.1.2220.110.1.2: 9020

Via: 192.168.0.1AppContact:192.168.0.1c=IN IP4 192.168.0.1Layerm=8000响应消息的目标地址是Via头字段IP中指定的私有地址，不可路由

Layer202.120.1.2:5060RouterSignallingRe-INVITE 数据包Via: 192.168.0.1Contact:192.168.0.1Appc=IN IP4 192.168.0.1Layerm=8000对话中后续请求的目标地址是IPContact头字段中指定的私有地Layer202.120.1.2:5060址，不可路由

RouterSignallingRTP 数据包Via: 192.168.0.1Contact:192.168.0.1Appc=IN IP4 192.168.0.1Layerm=8000RTP数据包的目标地址是SDP部分中参数c指定的私有地IPLayer202.120.1.2:5060址，不可路由

RouterMedia图1 SIP穿越NAT的问题2 方案的具体实现技术 2.1 实现原理 通过RTP代理媒体流穿越NAT/FW的方法，其工作原理如下：SIP Proxy解析与处理私网内用户呼叫的信令，并对其中某些头字段进行改写，使对应的响应消息以及随后的SIP信令可以顺利地在通信双方间传递。另外，改写SDP中携带的RTP/RTCP地址信息，使得会话中随后的媒体流均经过指定的RTP Proxy中继，从而完成信令和媒体流的NAT穿越。只有以SIP Proxy和RTP Proxy地址为源地址或目标地址的SIP信令包和媒体数据包才被允许通过防火墙。RTP代理服务器需要一个公网IP地址，SIP代理服务器通过媒体网关控制协议对RTP代理服务器进行控制。 2.2 拓扑结构 穿越NAT/FW方案的拓扑结构如图2所示。NAT/FW设备面向3个接口。面向内部的接口与私网中的SIP UA连接，面向外部的接口与公网连接，DMZ(DeMilitarized zone)接口用于连接SIP proxy和RTP proxy。 SIP proxy与RTP proxy之间通过多媒体网关控制协议[4]进行协商。SIP proxy中需要集成MGCP协议的客户端——呼叫代理，RTP proxy中需要实现MGCP协议的服务器端——呼叫代理服务器。MGCP与SIP一样，也使用SDP对多媒体会话进行描述。因此，在本方案中，SIP proxy可以复制SIP消息中

的SDP部分至MGCP命令中，并传递给RTP proxy，另外，由于只用到MGCP的某些命令，因此只需要实现MGCP协议的一个子集，如建立连接、修改连接、拆除连接的命令分别是CRCX、MDCX和DLCX。 SIP UAPrivate NetworkSIP UAPublic NetworkRouterSIP UANAT/FWUA 1Domain 1192.168.0.1DMZSIP RegisterUA 2Domain 2SIP Domain202.120.1.2SIP RTP ProxyProxyfwp.com220.110.5.6220.110.3.4SIP SignalRTP StreamMGCP Signal图2 穿越NAT/FW方案的拓扑结构 2.3 具体实现 2.3.1 SIP信令穿越NAT UA与SIP Proxy之间进行信令传递的消息流图如图3 所示。 UA 1SIP ProxyUA 2IP: 192.168.0.1IP: 220.110.5.6IP: 202.120.1.2Port: 5060

Port: 9020

Port: 5060

F1 RequestF2 RequestF3 ResponseF4 Response 图3 UA与SIP Proxy之间消息流图 前面指出的SIP穿越NAT/FW遇到的问题(1)和问题(2)可以通过扩展SIP协议来解决。UA1邀请UA2加入一个会话，首先发送SIP INVITE请求至SIP代理服务器。SIP Proxy对收到的请求消息进行修改：如果最顶端的Via头字段中的地址与本数据包的源地址不一致，则添加received参数[5]，记录下接收到消息的源地址；对于NAPT类型，还需要添加rport参数，记录下SIP Proxy在公网上对于SIP信令开放的端口号；用SIP proxy的公网地址220.110.5.6替换Contact头字段中的主机私网地址。SIP Proxy对请求消息的修改如图4所示。 与此同时，在SIP Proxy中用一张呼叫状态表记录整个呼叫过程中的状态[6]，表中记录收到的INVITE请求消息中的Call-ID, Via, Contact共3个头字段的值。在状态表中必须记录下每个头字段中相关参数改变后的数值以及增加的头字段值，如：添加Via头字段，其中，sent-by参数的值记录为SIP proxy的公网地址及端口220.110.5.6:5060；Contact头字段值记录为SIP proxy的公网地址。其他对于请求消息的操作按照一般SIP proxy规则处理。SIP Proxy中对应状态表的修改过程如图5所示。通过以上修改，就可解决SIP穿越NAT/FW中遇到的问题(1)和问题(2)。 —149—

F1 RequestINVITE sip:User2@domain2.com SIP/2.0Via: SIP/2.0/UDP 192.168.0.1:5060…Call-ID: 12345Contact: User1…F2 RequestINVITE sip:User2@domain2.com SIP/2.0Via: SIP/2.0/UDP 192.168.0.1:5060;received=220.110.5.6;rport=9020…Call-ID:12345Contact: Proxy… 图4 SIP Proxy修改请求消息 收到 F1 Request后：MessageCall-IDVia (sent-by)ContactINVITE12345192.168.0.1:5060192.168.0.1SIP Proxy修改后：MessageCall-IDVia (sent-by)ContactINVITE12345192.168.0.1:5060192.168.0.1INVITE12345220.110.5.6:9020220.110.5.6 图5 SIP Proxy收到请求后修改状态表 当收到响应消息时，本文设计的SIP proxy会对其进行修改：删除最顶端的Via头字段(本例中代表公网上UA 2的地址)，并删除由SIP Proxy本身添加的received和rport参数值。同时，SIP Proxy在呼叫状态表中查找与响应一致的Call-ID，添加Via头字段，其中，sent-by参数的值记录为SIP proxy的公网地址及端口220.110.5.6:5060；其他对于响应消息的操作按照一般SIP proxy规则处理。 对于公网中UA2发起的请求，由于在SIP Proxy的注册表中已经记录了私网中所有终端的ID和内网IP地址，因此SIP Proxy很容易确定被叫终端的地址。SIP Proxy对请求和响应消息做类似修改后，SIP信令便能顺利穿越NAT/FW了。 2.3.2 媒体流穿越NAT 媒体流穿越NAT/FW问题是难点之一，因此，解决音频、视频等媒体流在通信中穿越NAT/FW问题也是本方案的重点部分。媒体流通信包括建立初始连接、修改连接和开始通信3部分。 当UA1呼叫UA2时，SIP proxy事先通过MGCP协议与RTP Proxy联系，建立其与UA1及UA2之间的初始连接，在SIP Proxy中的呼叫状态表中需要记录SDP消息体中c行和m行的值。SIP消息中的SDP部分被复制后加入MGCP命令中，RTP proxy中集成的CAS对其进行分析。同时指定一个连接模式为“非活动”(inactive)状态，因为此时不需要RTP proxy传输任何媒体流。图6为此时RTP Proxy中的配置情况，其中描述了本地与远端的IP地址与端口以及连接模式。 建立初始连接后，SIP Proxy发送修改后的INVITE请求至的UA2，其中，SDP消息体中c行的主机地址用RTP Proxy的地址替换；m行中的端口也用RTP Proxy中开放的媒体流端口替换。通过对参数c和m的修改，能够解决SIP穿越NAT/FW中遇到的问题(3)和问题(2)。 —150 —RTP ProxySendOnlyRecvOnlyLocalRemoteUA 220.110.3.4Audio: 10126UA 1Video: 101282RemoteLocal192.168.0.1220.110.3.4Audio: 49170Audio: 10130RTPVideo: 53000Video: 10132RTP 图6 建立初始连接后RTP Proxy配置情况 在UA2发送的响应消息中，UA2将在IP地址202.120.1.2及端口3456处接收音频流，但是拒绝进行视频流通信，并将端口设置成0。SIP Proxy利用收到的响应消息中的SDP部分构造MGCP命令发送至RTP proxy，要求修改与UA1及UA2之间的连接。RTP proxy将关闭分配给视频流的端口。图7为此时RTP Proxy中的配置情况，其中加入了与UA2连接的远端部分，并对视频流端口进行修改。 RTP ProxySendOnlyRecvOnlyLocalRemoteUA 220.110.3.4202.120.1.2Audio: 10126UA 1Audio: 3456Video: 0Video: 02RemoteLocal192.168.0.1220.110.3.4Audio: 49170Audio: 10130RTPVideo: 0Video: 0RTP 图7 修改连接后RTP Proxy配置情况 在UA1发送ACK后，SIP proxy要求RTP proxy开放媒体流连接，即MGCP命令中的连接模式从inactive变成SendRecv。此时，UA1与UA2之间可以通过RTP proxy进行音频流的通信。图8为此时RTP Proxy中的配置情况。 RTP ProxySendRecvSendRecvLocalRemoteUA 220.110.3.4202.120.1.21RTPAudio: 10126Audio: 3456UA RTP2RemoteLocal192.168.0.1220.110.3.4RTPAudio: 49170Audio: 10130RTP 图8 开始通信后RTP Proxy配置情况 3 结论 本文根据现有的SIP穿越技术，结合对SIP协议本身的研究，采取SIP代理与RTP代理相结合的方法，提出了一种支持SIP穿越NAT/FW的解决方案。本方案可以透明地支持带防火墙的基本NAT、NAPT的多种穿越，并且对于现有多样的SIP用户终端和NAT设备无需做任何改动。实验结果表明，基于代理架构的SIP穿越NAT/FW解决方案具有很强的可行性，SIP信令和媒体流分别通过SIP Proxy和RTP Proxy代理进行中继传输，代理服务器之间通过MGCP协同工作，系统可靠性及工作效率较高。 (下转第180页)