SIP穿越NAT SIP穿越防火墙-SBC
FireWall&NAT
FireWall是一种被动网络安全防卫技术，位于网络的边界。在两个网络之间运行訪问控制策略。防止外部网络对内部信息资源的非法訪问，也能够阻止特定信息从内部网络被非法输出。一般来说，防火墙将过滤掉全部不请自到的网络通信（除指定开放的地址和port）。
NAT技术分为主要的网络地址转换技术(NAT)和网络地址与port转换技术(NAPT。Network Address and Port Translator)，其主要功能是为流出内网的分组分配一个全局的IP地址和port号作为其源地址和源port号，并将此映射关系增加一个地址/port映射表。
对于外来分组，NAT server将利用地址/port映射表将外来分组的目的IP地址和port号正确的变换回内部主机所使用的内部IP地址和port号，然后再转发给内网主机。
主要的NAT实现的功能非常easy，在子网内使用一个保留的IP子网段，这些IP对外是不可见的。子网内仅仅有少数一些IP地址能够相应到真正全球唯一的IP地址。假设这些节点须要訪问外部网络，那么基本NAT就负责将这个节点的子网内IP转化为一个全球唯一的IP然后发送出去。(主要的NAT会改变IP包中的原IP地址，可是不会改变IP包中的port)。
第二种NAT叫做NAPT。从名称上我们也能够看得出，NAPT不但会改变经过这个NAT设备的IP数据报的IP地址，还会改变IP数据报的TCP/UDPport。
基本NAT的设备可能我们见的不多。见下图
有一个私有网络10.0.0.0，Client A是当中的一台计算机，这个网络的网关（一个NAT设备）的外网IP是155.99.25.11(应该另一个内网的IP地址。比方10.0.0.10)。假设Client A中的某个进程（这个进程创建了一个UDP Socket,这个Socket绑定1234port）想訪问外网主机18.181.0.31的2234port。那么当数据包通过NAT时会发生什么事情呢？
首先NAT会改变这个数据包的源IP地址，改为155.99.25.11。
接着NAT会为这个传输创建一个Session（Session是一个抽象的概念，假设是TCP，或许Session是由一个SYN包開始。以一个FIN包结束。而UDP呢，以这个IP的这个port的第一个UDP開始，结束呢，或许是几分钟，或许是几小时），而且给这个Session分配一个port，比方62000，然后改变这个数据包的源port为62000。
所以本来是(10.0.0.1:1234->18.181.0.31:2234)的数据包到了互联网上变为了(155.99.25.11:62000->18.181.0.31:2234)。
一旦NAT创建了一个Session后，NAT会记住62000port相应的是10.0.0.1的1234port。以后从18.181.0.31发送到62000port的数据会被NAT自己主动的转发到10.0.0.1上。（注意：这里是说18.181.0.31发送到62000port的数据会被转发，其它的IP发送到这个port的数据将被NAT抛弃）这样Client A就与Server S1建立以了一个连接。前面我们所说的在NAT上建立的那个Session，就是我们常说的：”在内网的NAT上打上一个’洞’”。这个洞不能由外部来打，仅仅能由内网的主机来打。而且这个洞是有方向的。
如上例所说的是从内部某台主机（10.0.0.1）向外部的某个IP(18.181.0.31)发送一个UDP包。那么就在这个内网的NAT设备上打了一个方向为18.181.0.31的”洞”。
以后18.181.0.31就能够通过这个洞与内网的10.0.0.1联系了。（此处说明一点，在NAT上打的这个”洞”仅仅能由这两个IP使用。其它的IP不能利用这个洞进行通信。） 这就是称为UDP Hole Punching的技术。
在没有活动的时候，这个Hole会过期。NAT对于地址转换关系是有一定生命期的，某个地址转换后在一段时间内没有被使用将会被清除。当这个业务流再次出现时。将会建立一个新的地址转换关系。
NAT经常使用的分类例如以下：
Full Cone NAT(全然圆锥型)
Address Restricted Cone NAT(地址限制圆锥型 )
Port Restricted Cone NAT(port限制圆锥型)
Symmetric NAT(对称型)
Full Cone NAT(全然圆锥型NAT )
在全然圆锥型NAT（Full Cone NAT）中，NAT会将客户机地址{X:y}转换成公网地址{A:b}并绑定。不论什么包都能够通过地址{A:b}送到客户主机的{X:y}地址上。如图所看到的：
Address Restricted Cone NAT(地址限制圆锥型)
地址限制圆锥型NAT（Address Restricted Cone NAT）会将客户机地址{X:y}转换成公网地址{A:b}并绑定。仅仅有来自主机{P}的包才干和主机{X:y}通信。
例如以下图所看到的：
Port Restricted Cone NAT(port限制圆锥型)
port限制圆锥型NAT(Port Restricted Cone NAT)会将客户机地址{X:y}转换成公网地址{A:b}并绑定。仅仅有来自主机{P,q}的包才干和主机{X:y}通信。
例如以下图所看到的：
Symmetric NAT(对称型)
对称型NAT（Symmetric NAT）会将客户机地址{X:y}转换成公网地址{A:b}并绑定为{X:y}|{A:b}<->{P:q}。对称型NAT仅仅接受来自{P:q}的incoming packet，将它转给{X:y} ，每次客户机请求一个不同的公网地址和port，NAT会新分配一个port号{C,d} 。例如以下图所看到的：
部署SIP网络出现的问题
基于SIP协议的语音和视频会话採用主叫呼入方式（unsolicited incoming calls）。被叫方无法事先预知，所以终端必须随时监听外来的呼叫，这和前面介绍的防火墙工作原理是相悖的。即使打开防火墙上的一个port来专门接收呼叫信令。SIP语音和视频通信协议还会动态分配别的port来传送语音和视频等媒体数据。
怎样在不减少网络安全性的前提下为防火墙后面的用户提供安全的双向通信就是一个重要问题。
同一时候NAT对SIP语音和视频通信的传输有关键性的影响。首先，SIP会话信令(Layer 5)的SDP中包括了终端准备用来收发信令/媒体的地址和port信息。这些信息对NATserver是透明的，在经过NATserver之后保持不变。当位于内网的SIP终端作为主叫向外发起呼叫请求的时候，SIP信令经过NATserver之后仅仅有(Layer 3)的地址信息被改写，而layer 5的会话信令中包括的地址信息被原封不动的送到了被叫，中间可能经过多个SIP Proxy，利用SIP协议的这一机制，主叫和被叫能够完毕媒体协商过程。可是当被叫使用主叫的私有地址来发送媒体的时候，媒体流将发送失败。总之，针对NAT 的解决方式必须保证安全的双向通信，支持主叫呼入方式，同一时候要尽可能避免对NAT设备的改动或是依赖于特定类型的设备。
NAT的经常使用解决方式
解决NAT穿越有非常多中解决方式，经常使用的有：
1、ALG(Application Level Gateway)
能够识别SIP信令，能够适当地改动数据包。
ALG能够是单独的连接于外网和内网之间的设备。也能够是内置于防火墙内的插件。当FW/NAT发现外网呼叫信令为SIP时，将其转发到ALG(应用层网关)。通过ALG建立起内网伪地址终端与外网终端的通信连接。
经过NAT转换后。到外网SIP包中via，contact。ower/creator，connection information均须要改为NAT外网IP。
使用ALG须要对现有设备升级改造。比如思科的路由器都支持配置ALG。光口板用的正是ALG功能。
附件为光口板sip alg功能所遇到的一些关键问题。
2、MidCom(Middlebox Communications）
MIDCOM技术是为了解决ALG和代理技术所共同拥有的可扩展性不强而出现的一种NAT穿越解决方式。MIDCOM技术是採用可信的第三方（MIDCOM Agent）对Middlebox(NAT)进行控制，由MIDCOM Agent控制Middlebox打开和关闭媒体port。
总的来说，MIDCOM技术是一种理想的NAT穿越解决方式,它将IP语音和视频业务识别的智能从Middlebox转移到外部的MIDCOM Agent上，应用协议对Middlebox来说是透明的。
通常。MIDCOM Agent的功能能够集成在呼叫控制server（如SIPserver、GK或软交换设备）之中。而Middlebox功能集成在NAT之中，MIDCOM Agent和Middlebox之间接口採用MIDCOM协议完毕互通。
MIDCOM技术的优势在于可扩展性强，新增应用仅仅需对MIDCOM Agent进行扩展。而不会导致MIDBOX又一次升级。
然而。MIDCOM技术的实施须要对server和现有的NAT须要同一时候进行MIDCOM协议的升级扩展。因此该方案的实施不可避免带来了现有设备升级的困难。同一时候，MIDCOM协议尚处于不断完好的阶段。设备制造商提供的产品种类有限，因而现阶段MIDCOM方式的实际应用并不多见。但能够预见的是。随着MIDCOM协议的不断成熟和发展，该方式将获得越来越多的应用前景。
使用MidCom须要对现有设备升级改造。
3、STUN(Simple Traversalof UDP Through Network)
IETF RFC 3489定义了怎样确定由NAT分配的公网地址和port，不须要改造现有NAT。
主要特色：
- 能够让client发现NAT的存在以及类型；
- 能够让client发现NAT的绑定生命周期。
- 能够工作在多NAT串联环境下。
- 非常easy的协议，易于实现。负载低；
- STUNserver能够位于公网不论什么地方。
适用范围：
- 不适用于Symmetric NAT。
- 对于Non- Symmetric NAT都适用；
- 假设两方都位于同一个NAT之后。就不适用。
4、SBC(Session Border Controller)
SBC是VoIP接入层设备。它通过在网络的边界处对会话进行控制来实现NAT/防火墙穿透功能。同一时候还能够进行带宽限制、会话管理、流量统计等。
其次。SBC还能够被看作支持VoIP的代理server，能够识别第五层和第七层的消息，而且还能够处理第五层以上的众多会话信令协议。改动数据包头的地址，从而实现SBC内外网地址变换。
SBC的穿透过程遵循一定的通信模型，在模型中可将会话分解成若干信道。
在信道层面，通过对信道进行建立、维护和删除等操作保证信道的可用性，在会话层面，将不同信道进行连接和释放等操作，能够实现整个会话穿透过程。SBC位于两个网络的边界，其架构一般包括两个主要的功能模块：Signaling Proxy 和Media Proxy。当中Signaling Proxy 负责处理SIP会话信令，而Media Proxy负责对媒体流进行控制。Signaling Proxy和Media Proxy之间使用特定的协议和接口（比如Megaco 协议）来交换信息。例如以下图
–Signaling Proxy
Signaling Proxy是一个高性能的B2BUA（Back to Back User Agent）。负责对全部经过此节点的双向SIP会话信令进行必要的处理。在B2BUA中。当中一个作为UAS（User Agent Server）负责接收并处理主叫终端的会话请求，而另一个就作为UAC（User Agent Client）向下一跳发出会话请求。与代理server不同。B2BUA必须维护各个会话的状态。并參与到会话建立的信令交互过程中。
为了确保SIP会话信令通过SBC，能够改动域名server中相应于呼叫server（Call Server）的条目。将SBC的IP地址作为呼叫server的IP地址响应给进行DNS查询的终端，终端就会把发往呼叫server的信令都直接发到SBC。这些改动对终端用户是透明的，但SBC能够获得全部的呼叫信息，并能够參与到呼叫建立的过程中去详细实施控制。
其次，Signaling Proxy也必须对SIP会话信令中与信令和媒体有关的地址信息进行改动。
（1）SIP用户注冊消息处理。Signaling Proxy在截获SIP的用户注冊消息之后。将使用自己的IP地址和port号改写SIP头标中的Via和Contact域。然后再发往呼叫server（SIP注冊server），这样就能够把SIP用户的当前位置绑定在SBC上，当该SIP用户作为被叫的时候。信令都会首先发至SBC。
同一时候，由于NATserver会在比較短的间隔内清除地址/port映射表中的UDP无效表项，所以当终端使用UDP来传输SIP信令的时候。位于NATserver之后的终端必须周期性（大概几十秒）的向外部的呼叫server发送注冊消息。才干够使NATserver中相应于该终端的地址/port映射表项保持有效。
（2）SIP消息改写，为了确保Signaling Proxy始终位于信令通路上，Signaling Proxy必须使用本地的地址和port号来改写SIP消息中的Via和Contact域。
当使用内部地址的终端用户向呼叫server发送信令的时候。经过Firewall/NAT之后的IP分组将使用NATserver分配的源地址和源port。收到此信令的Signaling Proxy就会在本地建立一个映射关系，NATserver将为此终端分配的地址和port号。以及Signaling Proxy为此会话分配的地址和port号绑定在一起。这样。当反向信令到达Signaling Proxy的时候，Signaling Proxy将透过Firewall/NAT上正确的地址和port号将信令发送给终端。
（3）改动SDP，为了将Media Proxy增加到媒体通路中，SIP消息中的SDP部分也应当被改写。SDP中包括了终端准备用来收发媒体的地址和port信息。当终端位于Firewall/NAT之后的时候。这些信息假设原封不动的送达通信对端。就会导致通信对端发送媒体流失败。Signaling Proxy将通过Media Proxy分配本地的地址和port号。并使用本地的地址和port号改写这些信息，就能够保证双向媒体流的建立。
Signaling Proxy仅仅对特定SIP信令消息中的特定域进行改动，其它的消息和域都将维持不变。
–Media Proxy
Media Proxy接受Signaling Proxy的控制，是会话两方之间RTP/RTCP媒体流的转换点。由于全部的媒体流都要经过Media Proxy，所以应当具有控制媒体流的能力。对服务质量进行管理，获取计费信息及动态的网络地址/port转换等。
经过SBC信令和媒体流整个过程如图2所看到的。当主叫的用户代理（UA）发起呼叫的时候①，Signaling Proxy会在收到INVITE消息之后向Media Proxy申请分配本地的NAT地址和port（呼叫server側）②。并使用Media Proxy 返回的地址和port号③，改写信令消息中携带的SDP。然后再发往呼叫server④。终于由呼叫server送达被叫方⑤。
当反向信令到达Signaling Proxy的时候⑥⑦。Signaling Proxy会再次向Media Proxy申请分配本地的NAT地址和port（主叫用户側）⑧。并使用返回的地址和port号⑨改写反向信令中携带的SDP，然后再发往主叫的用户代理⑩。
经过这样的信令处理之后，主叫和被叫都会将媒体流发往Media Proxy上指定地址和port，此时Media Proxy就能够通过读取媒体流的源地址和源port来确定位于NAT之后的主叫/被叫在其Firewall/NAT上所使用的全局地址和port。进而把通信对端的媒体流发往该地址/port。由于Firewall/NAT上已经存在了相应此全局地址/port的映射关系，Firewall/NAT会将此媒体流转发给内部的终端，至此双向的媒体连接建立成功。因此，SBC在不减少网络安全性的前提下，为Firewall/NAT后的用户提供了安全的双向通信。
（1）动态的网络地址/port转换（NAPT），Media Proxy所具备的NAPT功能不仅能够解决运营商网络或用户网络的IPv4地址短缺问题，还隐藏了运营商网络和用户网络的拓扑信息，增强了对拒绝服务（Denial of Service）攻击的防御能力，也保证了运营商网络拓扑的机密性。
（2）产生计费信息。Media Proxy 是媒体流的必经之处，因此能够对会话的时长、会话的类型（语音、视频等）以及双向的数据流量进行监视和统计。是产生CDR（Charge Detail Records）的合适位置。
（3）网间的QoS映射。IP头标中的ToS域（Type Of Service）/DS域（Differentiated Service）指示了分组所应获得的QoS（Quality of Service）级别。为了保证端到端的服务质量，必须在两个网络的边缘完毕QoS映射。
当会话的IP分组在经过Media Proxy的时候，都携带了来源网络所做的ToS/DS标记。Media Proxy能够依据事先配置好的映射规则改变这些标记。再送入目的网络中，从而保证该会话的QoS 在不同运营商的网络内保持一致，也就是保证其端到端的QoS。
（4）IPv4到IPv6的协议转换，当处在两个异种网络（IPv4/IPv6）边缘的时候，Media Proxy还能够提供这两种IP协议的转换。
Media Proxy由于其所处的特殊位置成为部署IPv4/IPv6协议转换的理想设备。
5、rport机制
获得IP地址是在Via头中带上received參数。为了得到port信息，也參考了这样的方式。即在Via头中带上rport属性来指明port信息。
当在client和server之间是NAT的时候，请求可能会在NAT中创建（或刷新）一个绑定。为了让client收到响应信息。在事务处理的过程中这个绑定必须保持存在。大多数的NAT绑定有超过1分钟的超时时间。这超过了non-INVITE事务的持续时间。因而对non-INVITE事务的请求的响应仅仅能在绑定存在的时候存在。
INVITE事务倒是不存在这个问题。
为了保持这个绑定。client应该在每隔20s左右重发INVITE请求。这样的重发机制须要发生在收到一个暂时的响应后。
当然刚才所说的大概1分钟的超时时间也不是确定的，有时候会比这长，此时重发机制能够发慢一点，否则，能够发快一点。这些问题可參考RFC3489。
假设是支持rport机制的server，它须要在接收到的请求中检查Via头是否包括一个没有值的rport參数。
假设有，它须要在回应中带上rport的值。这与received的处理相似。
为了穿越对称性的NAT，响应须要发送到同样的IP地址和port。当server在多port或接口的请求上监听请求时，它必须记住请求是从何处发的。
对一个稳定的Proxy，在一个传输的持续时间中，记住这些东西是没有问题的。可是对于不稳定的Proxy。它不存储请求和响应中的状态信息。为了达到本规范的要求。它须要将地址和port信息加密到Via头字段中，在响应信息到达的时候。它能提取加密的信息并将它放到响应中。
rport机制须要终端支持该种机制，因此应用情况比較受限。
–实例
以下举一个发送REGISTER信息的实例。在请求信息的Via头中包括了没有值的rport參数，例如以下所看到的：
REGISTER sip:124.40.120.188:5060 SIP/2.0
Via:SIP/2.0/UDP 124.42.4.203:15500;branch=z9hG4bK-d8754z-1049ed261d2e643d-1---d8754z-;rport
Max-Forwards:70
Contact: <sip:19988888888@192.168.2.65:12344;rinstance=7cd1c532e92fdb0e>;expires=0
To: "19988888888"<sip:19988888888@124.40.120.188:5060>
From: "19988888888"<sip:19988888888@124.40.120.188:5060>;tag=203ba359
Call-ID: Yzc4N2IwMzY5OWU4MTdkMzY0NWY4OWU3NjMzNmJiM2U.
CSeq: 1 REGISTER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE,INFO
User-Agent: eyeBeam release 1105a stamp 56793
Content-Length: 0发送到的server支持rport机制，它看到请求中的rport后，将通过分析UDP包信息得到的NAT的公网地址（124.42.4.203）和port信息（15500）分别作为received和rport属性带给client：
SIP/2.0 200 OK
Via: SIP/2.0/UDP 124.42.4.203:15500;branch=z9hG4bK-d8754z-1049ed261d2e643d-1---d8754z-;rport=15500;
received=124.42.4.203
From: "19988888888"<sip:19988888888@124.40.120.188:5060>;tag=203ba359
To: "19988888888"<sip:19988888888@124.40.120.188:5060>;tag=0005-058-7d6dc90516ae2e21
Call-ID: Yzc4N2IwMzY5OWU4MTdkMzY0NWY4OWU3NjMzNmJiM2U.
CSeq: 4 REGISTER
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,UPDATE,PRACK,REFER,SUBSCRIBE,
NOTIFY,MESSAGE
Contact: <sip:124.40.120.188:5060>
Content-Length: 0client在得到响应信息后。知道了所使用的公网地址和port，在而后定期重发的REGISTER信息中，Contact变换成124.42.4.203: 15500。比如新发的REGISTER信息变为：
REGISTER sip:124.40.120.188:5060 SIP/2.0
Via: SIP/2.0/UDP 124.42.4.203:15500;branch=z9hG4bK-d8754z-1049ed261d2e643d-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:19988888888@124.42.4.203: 15500;rinstance=7cd1c532e92fdb0e>;expires=0
To: "19988888888"<sip:19988888888@124.40.120.188:5060>
From: "19988888888"<sip:19988888888@124.40.120.188:5060>;tag=203ba359
Call-ID: Yzc4N2IwMzY5OWU4MTdkMzY0NWY4OWU3NjMzNmJiM2U.
CSeq: 2 REGISTER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
User-Agent: eyeBeam release 1105a stamp 56793
Content-Length: 0
