在NAT解决方案中，我们不仅仅需要解决SIP信令的问题，还要解决RTP的问题。为了让大家能够继续跟进我们的讲座，笔者多花一点时间回顾一下关于NAT对SIP和RTP的造成的影响（以前的讲座中有比较深入的探讨）。现在我们举两个简单的例子说明NAT防火墙对SIP相关业务的影响。在以下的RTP 示例中，SIP信令都没有问题，内网用户呼叫到外网也没有问题，但是对端外网用户可能不能听到内网用户的语音，出去的RTP语音可以成功到达目的地终端，但是外网终端则不能进入到内网中。虽然SIP的SDP中已经添加了对RTP语音的描述，但是如果防火墙会过滤这些端口，或者根本没有开启这些端口的话，那么从语音流则会被过滤掉。这就是我们通常所说的单通现象。
在下面的这个RTP示例中，如果是从防火墙外部用户发起呼叫的话，防火墙会直接过滤了SIP请求，SIP消息会被拒绝。
从以上简单的示例中，读者可以看到，很多时候我们面对的现实情况是：
RTP端口是动态变化的，这是一个难题。
防火墙不知道RTP端口变化。
让防火墙开启更多端口在很多场景中是非常不现实的。
针对以上的问题，为了解决这些问题，我们依次介绍几个常见的解决方案。
1、在网络中使用UPnP的设置方式。UPnP是一种非常简单的协议，它可以运行在SIP终端设备中，终端设备开启这个功能以后，它可以直接查询公网地址和端口，然后让SIP INVITE重新写入新的地址，在SDP中使用公网地址。UPnP的好处是目前大部分的厂家都支持此协议，终端用户或者一般家庭用户可以通过简单设置就可以实现简单的NAT穿透。
2、ALG全称是Application Layer Gateway。RFC2633对ALG有粗略的定义。ALG可以对SIP相关数据进行转译（包括呼入请求，响应；呼出请求响应），隐藏内网必要消息，它收集SIP消息中的信息，主要对SIP 头的Via，Contact，Route和Record-Route进行处理。它和Media Proxy不同。它具有以下几个方面的特点：
ALG可以在DMZ中进行设置，由防火墙实现对其控制。
和Media Proxy类似，所有SIP消息和RTP消息可以通过ALG转发到目的地地址。
如果需要，ALG可以配合NAT修改SIP消息的一些值域。
ALG可以以软件的形式嵌入到防火墙。
以下示例演示了一个简单的注册流程，通过ALG以后，ALG然后修改地址，继续对注册服务器进行注册。注册服务器返回地址以后，ALG再次修改为内网地址。
因为SIP的技术越来越普及，有一些防火墙增加了对SIP的部分支持功能。让我们首先看一个如果是外网的用户呼叫内网用户时的流程，外网用户呼叫内网时，在内网SIP终端返回给外网用户时，防火墙设置了一个策略，这里，内网接收到端口是1344，防火墙则重新映射了一个端口1624，并且修改了SDP信息，然后在SDP中携带了新的RTP接收端口1624，发送给外网用户，通知外网用户，内网终端的RTP接收端口是1624。
外网终端通过这个指定的端口发送RTP语音流。防火墙知道通过这个端口的映射，然后根据映射规则，映射到内网的1344端口。到这里，RTP语音流正式开通。双方通话结束后，防火墙自动删除这个端口映射策略。
如果是内网用户呼叫外网用户，防火墙的映射机制基本上是相同的。这里，不同的是，内网用户对外网用户发起呼叫时，内网终端通知防火墙此终端准备接收RTP的具体端口，防火墙然后根据这个端口映射一个新端口，并且修改SDP的RTP端口，最后发送给外网的终端。外网终端则根据这个端口发送RTP语音，防火墙接收到这个端口的RTP流返回到原来的终端端口。如果通话结束，最后，防火墙删除映射端口匹配设置。以下是一个完整的呼出的呼叫流程：
通过以上示例我们可以看到，事实上，ALG仅对Via, Conatct 这些值域进行了修改，实现一个转译，支持了SDP payload。但是ALG目前不支持对多IP地址广播，加密的SDP，SIP TLS和IP V6等其他功能。所以，严格意义来说，ALG仍然很难满足SIP多种业务的需求。
3、Symmetric RTP可以帮助解决RTP端口通信不一致的问题。我们首先了解一下它的处理流程。Symmetric RTP 的实现过程需要经过以下几个步骤：
首先，用户需要通过STUN 服务器， 注册服务器进行SIP注册流程，然后需要每30秒钟重新注册，这样做的目的是保持端口处于存活状态，避免端口不会被防火墙关闭。注意，这里的SDP端口是1776。
然后，UA 2 收到了防火墙返回的端口消息后，如果UA 2 支持Symmetric NAT，则会获悉通知UA2 从这个端口（13455）返回语音流，而不是从SDP消息中的端口（1776）。这样就避免了防火墙过滤RTP端口的问题。这里的SDP中的端口是不会被认为是真正的RTP端口。
4、Media Proxy的目的是通过一个Proxy的二次转发机制，重新让双方终端通过Media Proxy进行通信。UA 2就可以对UA1 发起呼叫请求。这时的状态和我们以前介绍的Far End NAT情况类似，这里，需要Media Proxy处理一些proxy所承担 的工作：
Media Proxy需要重写SDP中的RTP/AVP值域，重新把RTP语音流指向媒体服务器需要的端口地址。
当对发起呼叫方SIP终端发送消息时，Media Proxy同时需要发送重写的RTP/AVP值域，保证RTP端口能够发送到正确的RTP端口。
在防火墙的端口策略设置中，所使用的端口需要一直仅对Media proxy开放。 这样就可以限定部分端口开放给Media Proxy，无需完全开放所有RTP端口。
5、参考资料：
https://docs.citrix.com/en-us/netscaler/11/solutions/netscaler-support-for-telecom-service-providers/lsn-introduction/lsn-configuring-alg/sip-protocol-alg.html
总结，在本章节中我们讨论了几个主要的NAT解决方案，ALG，UPnP，Symmetric RTP和Media Proxy。通过我们的讨论，我们可以发现，事实上，这些解决方案都有非常强的针对性，同时也具有非常多的局限性。用户需要做更多的调研，找到适合自己需求的解决方案。在本章节的讨论中，我们仅讨论了SIP和RTP的互联互通，基本上都是实现了SIP对NAT的简单功能实现，这些技术解决方案事实上并没有真正解决SIP在公网的业务兼容性问题，安全管理问题，公司网络和运营商网络之间的问题。对于这些功能的要求就需要在网络环境中部署SBC。因为SBC的讨论话题非常广，我们在下一节的讲座中专门讨论SBC的部署。
关注我们的公众微信号：asterisk-cn 获得有价值的行业技术分享，访问论坛：www.issabel.cn/forum 下载开源免费融合通信平台。
