基于Full Proxy的H.323协议穿透NAT解决方案
摘要：由于IP地址的短缺，以及出于安全的考虑，在因特网中广泛采用NAT技术。在VoIP应用中，如何穿透NAT，就成了必须要解决的问题。本文提出了一种H.323协议穿透NAT的解决方案，并详细分析了方案的实现过程，该方案基于Full Proxy方式，无需改动现有NAT设备。
关键词：H.323；穿透；VOIP；NAT；Full Proxy
中图分类号：TP393文献标识码：A文章编号：1009-3044(2007)16-30973-01
A Solution Of NAT Traversal For H.323:Based On Full Proxy
ZHANG Wei
(Xuzhou Institute of Technology,Xuzhou,China)
Abstract:Because IP address become scarce, a technique known as Network Address Translation, or NAT, was developed to allow the use of a single IP address for a whole network of computers. How to traversal NAT, became the problem for VoIP. In this paper, a solution of traversing NAT with H.323 is proposed. This solution is based on Full Proxy, and no special configuration is required for NAT.
Key words:H.323;traversal;VoIP;NAT;Full Proxy
1 引言
由于IPv4地址的短缺，以及出于安全的考虑等问题，在因特网中广泛采用NAT技术，如何穿透NAT是所有网络应用必须解决的问题。H.323是广泛应用的VoIP协议，但由于其本身的复杂性，使得在设计NAT穿透方案时面临很多挑战。目前，业界已经提出很多NAT穿透技术，主要有：NAT/ALG、UDP-TUNNELING、STUN、TURN、Full Proxy等方式。本文提出一种基于
Full Proxy的穿透方案，并介绍其实现。
2 H.323协议穿透NAT存在的问题
根据H.323协议的呼叫流程，当处于内网中的网关如果通过GK呼叫外网中的通信实体，H.225和 H.245信令通道是可以正常建立的，只是在打开逻辑通道时，由于双方的逻辑通道是通过封装在IP包之内完成协商的，因此NAT不会建立两个通道之间的数据转发，这样音频信息就不能正常穿透NAT。
而当外网中的通信实体呼叫该网关时，由于H.323协议的监听端口是1720，如果网关与网守之间没有做任何事先的处理，那么网守直接向网关的1720发送连接请求时，该请求只发到了NAT的1720端口，但是NAT并不会将该端口上的请求发送到内网网关的监听端口，这样H.225信令通道建立失败，该呼叫不能正常建立。
除此之外还存在H.245通道正确建立的问题和音频信息不能穿透NAT的问题。主叫写入OLC消息中的RTP Media Control数据是私网的地址。 Media数据只有私到公的（即：公网可以看到/听到NAT后的终端，但NAT后的没有接到数据），因为被叫（公网）发送的Media数据的目的地地址是私网地址，该地址NAT不支持转送。根据以上分析的问题，提出以下的解决方案。
3 NAT穿透方案
我们把问题分解为以下三部分：
3.1建立H225通道
H225通道是基于TCP连接的，因此应该知道目的地址和端口。并且只有在NAT之后才建立该通道，并使通道保持连接等待呼叫，流程如下：
(1)终端发送RRQ注册的时候，Gatekeeper比较RRQ包的来源地址和RRQ消息中callSignalAddress的地址，从而知道该终端是否在NAT后。
(2)Gatekeeper对位于NAT后的终端GW1发送RCF包时，增加nonStandardData域。
(3)GW1收到RCF后，得知自己在NAT后，就创建一个TCP， 并连接到RCF包中指定的callSignalAddress地址上（1721端口），这样就建立了TCP通道。
3.2建立H.245通道
H.225通道建立以后，我们只要使H.245通道从内网向外发起连接，就可以建立H.245通道。具体实现是利用Q.931里的Facility消息，改变呼叫流程，流程如下：
(1)GW1发出Connect消息，其中H.245Address域中包含的地址是建立H.245控制信令的TCP地址。Gatekeeper收到后，创建一个TCP连接，准备用于H.245的传输。Gatekeeper用这个新创建的TCP连接改写GW1发出的Connect包的H.245Address域，并发给GW2。
(2)同时，Gatekeeper发出Q.931 Facility startH.245消息给GW1，该消息中包含了上一步中创建的TCP连接。
(3)GW1收到该消息，改成从内部向外创建H.245通道。
3.3建立媒体端口映射
在H.245的信令交互过程中，主从确定和能力集协商与普通情况下相同，只是在协商逻辑通道时作了处理，使媒体信息可以穿透NAT。主要是解析信令包，更改其中的媒体端口为外部的映射端口，双方的媒体流通过第三方中转。当内外网的通信双方协商好逻辑通道后，先由内网向外网的逻辑通道发送RTP包，公网终端收到私网发送的Media包后，将该UDP的来源地址（NAT转换后的地址）保留下来,比较其和前面协商的地址，如果不同，就使用该地址来替换发送RTP包所用的地址。NAT收到这个UDP包，因为已经有从该地址出去的UDP包，因此NAT能正确将该包送往内网。这样就解决了音频信息不能穿透NAT的问题。
4 结束语
本方案充分利用了H.323协议本身的特性，经过测试，该NAT穿透方案稳定性很好，并且具有很大的灵活性和可扩展性，无需现有NAT做任何改动即可开展VoIP业务。由于要对报文进行解析，因此支持报文加密，同时可以对报文流量进行分析控制，可以提供更好的QoS服务。在下一代网络中，该方案具有很强的适应性。
关键词：H.323；穿透；VOIP；NAT；Full Proxy
中图分类号：TP393文献标识码：A文章编号：1009-3044(2007)16-30973-01
A Solution Of NAT Traversal For H.323:Based On Full Proxy
ZHANG Wei
(Xuzhou Institute of Technology,Xuzhou,China)
Abstract:Because IP address become scarce, a technique known as Network Address Translation, or NAT, was developed to allow the use of a single IP address for a whole network of computers. How to traversal NAT, became the problem for VoIP. In this paper, a solution of traversing NAT with H.323 is proposed. This solution is based on Full Proxy, and no special configuration is required for NAT.
Key words:H.323;traversal;VoIP;NAT;Full Proxy
1 引言
由于IPv4地址的短缺，以及出于安全的考虑等问题，在因特网中广泛采用NAT技术，如何穿透NAT是所有网络应用必须解决的问题。H.323是广泛应用的VoIP协议，但由于其本身的复杂性，使得在设计NAT穿透方案时面临很多挑战。目前，业界已经提出很多NAT穿透技术，主要有：NAT/ALG、UDP-TUNNELING、STUN、TURN、Full Proxy等方式。本文提出一种基于
Full Proxy的穿透方案，并介绍其实现。
2 H.323协议穿透NAT存在的问题
根据H.323协议的呼叫流程，当处于内网中的网关如果通过GK呼叫外网中的通信实体，H.225和 H.245信令通道是可以正常建立的，只是在打开逻辑通道时，由于双方的逻辑通道是通过封装在IP包之内完成协商的，因此NAT不会建立两个通道之间的数据转发，这样音频信息就不能正常穿透NAT。
而当外网中的通信实体呼叫该网关时，由于H.323协议的监听端口是1720，如果网关与网守之间没有做任何事先的处理，那么网守直接向网关的1720发送连接请求时，该请求只发到了NAT的1720端口，但是NAT并不会将该端口上的请求发送到内网网关的监听端口，这样H.225信令通道建立失败，该呼叫不能正常建立。
除此之外还存在H.245通道正确建立的问题和音频信息不能穿透NAT的问题。主叫写入OLC消息中的RTP Media Control数据是私网的地址。 Media数据只有私到公的（即：公网可以看到/听到NAT后的终端，但NAT后的没有接到数据），因为被叫（公网）发送的Media数据的目的地地址是私网地址，该地址NAT不支持转送。根据以上分析的问题，提出以下的解决方案。
3 NAT穿透方案
我们把问题分解为以下三部分：
3.1建立H225通道
H225通道是基于TCP连接的，因此应该知道目的地址和端口。并且只有在NAT之后才建立该通道，并使通道保持连接等待呼叫，流程如下：
(1)终端发送RRQ注册的时候，Gatekeeper比较RRQ包的来源地址和RRQ消息中callSignalAddress的地址，从而知道该终端是否在NAT后。
(2)Gatekeeper对位于NAT后的终端GW1发送RCF包时，增加nonStandardData域。
(3)GW1收到RCF后，得知自己在NAT后，就创建一个TCP， 并连接到RCF包中指定的callSignalAddress地址上（1721端口），这样就建立了TCP通道。
3.2建立H.245通道
H.225通道建立以后，我们只要使H.245通道从内网向外发起连接，就可以建立H.245通道。具体实现是利用Q.931里的Facility消息，改变呼叫流程，流程如下：
(1)GW1发出Connect消息，其中H.245Address域中包含的地址是建立H.245控制信令的TCP地址。Gatekeeper收到后，创建一个TCP连接，准备用于H.245的传输。Gatekeeper用这个新创建的TCP连接改写GW1发出的Connect包的H.245Address域，并发给GW2。
(2)同时，Gatekeeper发出Q.931 Facility startH.245消息给GW1，该消息中包含了上一步中创建的TCP连接。
(3)GW1收到该消息，改成从内部向外创建H.245通道。
3.3建立媒体端口映射
在H.245的信令交互过程中，主从确定和能力集协商与普通情况下相同，只是在协商逻辑通道时作了处理，使媒体信息可以穿透NAT。主要是解析信令包，更改其中的媒体端口为外部的映射端口，双方的媒体流通过第三方中转。当内外网的通信双方协商好逻辑通道后，先由内网向外网的逻辑通道发送RTP包，公网终端收到私网发送的Media包后，将该UDP的来源地址（NAT转换后的地址）保留下来,比较其和前面协商的地址，如果不同，就使用该地址来替换发送RTP包所用的地址。NAT收到这个UDP包，因为已经有从该地址出去的UDP包，因此NAT能正确将该包送往内网。这样就解决了音频信息不能穿透NAT的问题。
4 结束语
本方案充分利用了H.323协议本身的特性，经过测试，该NAT穿透方案稳定性很好，并且具有很大的灵活性和可扩展性，无需现有NAT做任何改动即可开展VoIP业务。由于要对报文进行解析，因此支持报文加密，同时可以对报文流量进行分析控制，可以提供更好的QoS服务。在下一代网络中，该方案具有很强的适应性。
