SIP之 穿越NAT

Agenda SIP穿越NAT NAT分类 问题之所在 各种解决方案

SIP穿越NAT – NAT分类 Full Cone NAT(完全圆锥型) Address Restricted Cone NAT(地址限制圆锥型 ) Port Restricted Cone NAT(端口限制圆锥型) Symmetric NAT(对称型) 私网 公网 M A,b P X,y NAT S

SIP穿越NAT – NAT分类 Full Cone NAT(完全圆锥型NAT ) M A,b P X,y S 私网 公网 M A,b P X,y Full Cone NAT S NAT会将客户机地址{X:y}转换成公网地址{A:b}并绑定 任何包都可以通过地址{A:b}送到客户主机的{X:y}地址上

SIP穿越NAT – NAT分类 Address Restricted Cone NAT(地址限制圆锥型 ) M P,q A,b P,r 私网 公网 M X P,q A,b P,r X,y X Restricted Cone NAT S NAT会将客户机地址{X:y}转换成公网地址{A:b}并绑定 只有来自主机{P}的包才能和主机{X:y}通信

SIP穿越NAT – NAT分类 Port Restricted Cone NAT(端口限制圆锥型 ) M,n P,q A,b P,r 私网 公网 M,n P,q A,b X P,r X,y X Port Restricted Cone NAT S NAT会将客户机地址{X:y}转换成公网地址{A:b}并绑定 只有来自主机{P,q}的包才能和主机{X:y}通信

SIP穿越NAT – NAT分类 Symmetric NAT(对称型) M,n C,d P,q A,b P,r X,y S X X 私网 公网 C,d M,n P,q A,b X P,r X,y X Port Restricted Cone NAT S NAT会将客户机地址{X:y}转换成公网地址{A:b}并绑定为{X:y}|{A:b}<->{P:q} NAT只接受来自{P:q}的incoming packet，将它转给{X:y} 每次客户机请求一个不同的公网地址和端口，NAT会新分配一个端口号{C,d}

SIP穿越NAT – 问题之所在 SIP Proxy无法穿过NAT回送SIP信令 X X 公网 私网 SIP Proxy 私网 Firewall /NAT X X SIP信令 Firewall /NAT 因为SIP信令中的From和Contact头域记录的是私网地址和端口,NAT无法识别和转换。

SIP穿越NAT – 问题之所在 如果是UDP Hole Punching呢？ 什么是UDP Hole? 私网 公网 UDP包 Firewall /NAT 这个内网的NAT上打了一个方向为211.136.91.58的“洞”，（这就是称为UDP Hole Punching的技术）以后211.136.91.58就可以通过这个洞与内网的192.168.1.223联系了，但是其他的IP不能利用这个洞。

SIP穿越NAT – 问题之所在 如果是UDP Hole Punching呢？ 在没有活动的时候，这个Hole会过期：

SIP穿越NAT – 解决问题 几种解决方案 ALG MidCom STUN TURN SBC

Application Level Gateway Solution SIP穿越NAT – ALG Application Level Gateway Solution ALG可以识别SIP信令，能够适当地修改数据包 ALG可以是单独的连接于外网和内网之间的设备，也可以是内置于防火墙内的插件 当FW/NAT发现外网呼叫信令为SIP时，将其转发到ALG(应用层网关)，通过ALG建立起内网伪地址终端与外网终端的通信连接 需要对现有设备升级改造

IETF MIDCOM(Middlebox Communications) Solution SIP穿越NAT – MidCom IETF MIDCOM(Middlebox Communications) Solution 允许第三方(MIDCOM Agent )成为受FW/NAT信任的实体，然后代表FW/NAT做出决定，强迫其开放端口传送媒体流或数据流。这些受信任的实体通过“MidCom”定义的新协议与FW/NAT进行通信。 协议的识别不由Middlebox完成，而是由外部的MIDCOM Agent完成 需要对现有设备升级改造

STUN(Simple Traversalof UDP Through Network) Solution SIP穿越NAT – STUN STUN(Simple Traversalof UDP Through Network) Solution STUN回包告诉客户端 公网IP和12345端口 私网 公网 [A,b] What’s my ip? A,b S,t X,y NAT 希望在5060端口接收数据 从5060端口发送请求STUN服务器 NAT映射端口为12345

SIP穿越NAT – STUN IETF RFC 3489定义了如何确定由NAT分配的公网地址和端口 不需要改造现有NAT 主要特色： 非常简单的协议，易于实现，负载低 STUN服务器可以位于公网任何地方 适用范围： 不适用于Symmetric NAT 对于Non- Symmetric NAT都适用 如果双方都位于同一个NAT之后，就不适用

SIP穿越NAT – STUN STUN的优点： 无需现有NAT设备做任何改动 可在多个NAT串联的网络环境中使用 STUN的局限性： 需要终端支持STUN CLIENT的功能 不适合支持TCP连接的穿越，所以不支持H.323 不支持Symmetric NAT 不支持对防火墙的穿越

SIP穿越NAT – STUN

SIP穿越NAT – STUN

SIP穿越NAT – STUN 成熟的STUN Server/Client方案: http://sourceforge.net/projects/stun/ 下载stund_0.94_Oct29.gz 运行其中的WinStun.exe测试程序,即可获知NAT类型以及分配的公网地址：

TURN(Traveral Using Relay NAT) Solution SIP穿越NAT –TURN TURN(Traveral Using Relay NAT) Solution 通过Relay方式穿越NAT的方式： 私网终端发出的报文都要经过TURN Server进行Relay转发 私网 公网 O,p M,n [O,p] A,b O,p Give my ip S,t M,n X,y NAT 分配一个IP和端口：[O,p]

SIP穿越NAT –TURN IETF draft “draft-rosenberg-midcom-turn-06” TURN Server控制分配地址和端口，能分配RTP/RTCP地址对(RTCP端口号为RTP端口号加1)作为私网终端用户的接收地址，避免了STUN方式中出口NAT对RTP/RTCP地址端口号的任意分配，使得客户端无法收到对端发来的RTCP报文(对端发RTCP报文时，目的端口号缺省按RTP端口号加 1发送)。

SIP穿越NAT –TURN 与STUN的类似之处： 私网中的终端通过某种机制预先得到公网上的服务地址，然后在报文净载中所要求的地址信息就直接填写该公网地址。 与STUN的区别： STUN得到的地址为出口NAT上外部地址；TURN得到的地址为TURN Server上的公网地址 TURN支持Symmetric NAT TURN支持基于TCP的应用，如H.323

SIP穿越NAT –TURN TURN的优点： 无需现有NAT设备做任何改动 可在多个NAT串联的网络环境中使用 支持Symmetric NAT 支持TCP连接的穿越 TURN的局限性： 需要终端支持TURN CLIENT的功能 所有报文都必须经过TURN Server转发，增大了包的延迟和丢包的可能性

ICE(Interactive Connectivity Establishment) Solution SIP穿越NAT –ICE ICE(Interactive Connectivity Establishment) Solution IETF draft “draft-ietf-mmusic-ice-03” 综合运用 STUN、TURN或RSIP(Realm Specific IP)协议，使之在最适合的情况下工作，以弥补单独使用其中任何一种所带来的固有缺陷 在 SIP client开发上显著地增加了复杂性 适用于各种类型的NAT 需要每一个终端支持 traversal 方法 资源： 可以参考论文《基于ICE方式SIP信令穿透Symmetric NAT技术研究 》

SBC(Session Border Controller) Solution SIP穿越NAT –SBC SBC(Session Border Controller) Solution SIP Proxy SIP Signaling Firewall Firewall RTP/RTCP Media

SIP穿越NAT –SBC Signaling Solution SBC可以帮助SIP信令穿越已经存在的FW/NAT，而不需要对现有的FW/NAT设备做任何改变 对于SIP终端，SIP终端设备会周期性发送注册消息到SBC Media Traversal Solution SBC可以把相应的媒体流发送到防火墙上的相关IP地址和端口，然后正确地使媒体流到达防火墙后的用户侧

谢谢！