多媒体业务网络地址转换穿越的方法及其系统

摘要

本发明涉及下一代网络中的通信系统和方法，公开了一种多媒体业务网络地址转换穿越的方法及其系统，使得收、发端口不一致的信令和媒体流可以成功穿越NAT/FW。这种多媒体业务网络地址转换穿越的方法及其系统在NAT/FW的内外分别设置了代理客户端和代理服务器，代理客户端为私网中的不同分组用户终端分配不同的UDP或TCP端口，从而和代理服务器建立不同的隧道。通过这些对业务数据透明的隧道，分组用户终端可以和公网中的主机进行正常的信令和媒体流交互。

说明书

技术领域

本发明涉及下一代网络中的通信系统和方法，特别涉及下一代网络中多媒体业务穿越网络地址转换/防火墙的系统和方法。

背景技术

下一代网络(Next Generation Network，简称“NGN”)是电信史的一块里程碑，它标志着新一代电信网络时代的到来。从发展的角度来看，NGN是从传统的以电路交换为主的公用电话交换网(Public Switched TelephoneNetwork，简称“PSTN”)中逐渐迈出了向以分组交换为主的步伐，它承载了原有PSTN网络的所有业务，把大量的数据传输卸载到网间互联协议(Internet Protocol，简称“IP”)网络中以减轻PSTN网络的重荷，又以IP技术的新特性增加和增强了许多新老业务。从这个意义上讲，NGN是基于时分多路复用(Time Division Multiplexing，简称“TDM”)的PSTN语音网络和基于网间互联协议/异步传输模式(IP/ATM)的分组网络融合的产物，它使得在新一代网络上语音、视频、数据等综合业务成为了可能。目前，NGN成为了研究的热点。

NGN在功能上可分为四个层次：接入和传输层、媒体传送层、控制层、网络服务层。软交换(SoftSwitch)为NGN提供具有实时性要求的业务的呼叫控制和连接控制功能，是NGN呼叫与控制的核心。软交换构件(SoftX)为NGN的网络控制层的关键构件，是提供综合业务和呼叫控制的设备。其主要作用包括：呼叫控制、信令网关、网关控制、综合业务、增强业务等。

随着NGN网络逐步从实验走向商用，NGN用户的接入越来越成为一个严重的问题。由于NGN是一个基于分组网承载的网络，接入用户都是通过IP地址来寻址，而当前的网络由于IP地址紧缺以及安全等各原因，大量的企业网和驻地网基本上都采用了私有IP地址通过出口的网络地址转换(Network Address Translation，简称“NAT”)/防火墙(Firewall，简称“FW”)接入公网。

防火墙用于限制数据包无限制地进入网络内。一般是设定一些包过滤原则，防火墙通过检查数据包的源地址、目标地址、源端口、目标端口和协议来判断数据包是否符合过滤原则，符合的才可以通过防火墙。实际应用时通常将一些需要外界访问的服务器，如Web服务器等放在这个区域内，防火墙配置成让所有发往这些服务器的对应端口的数据可以通过。

NAT用于使多台私网内的主机通过较少的公网地址访问公网，同时能够隐藏私网IP、保护私网内主机不受外界攻击。它的原理是当私网内主机需要访问公网时，由NAT服务器动态分配一个空闲的公网地址给该主机，当该主机不再需要访问公网时(例如该主机长时间没有向公网发送或从公网接收报文时)，NAT服务器收回已分配的公网地址。

目前业界解决FW/NAT穿透的方案有多种，比如用户数据报协议对网络地址转换的简单穿越(Simple Traversal of UDP Through Network AddressTranslators，简称“STUN”)、通过中继方式穿越网络地址转换(Traversal UsingRelay Network Address Translators，简称“TURN”)、全代理(Full Proxy)等方案。以下对这些主要方案做简单介绍。

在STUN方式中，私网接入用户通过某种机制预先得到其地址对应在出口NAT上的对外地址，然后在报文负载中所描述的地址信息就直接填写出口NAT上的对外地址，而不是私网内用户的私有IP地址，这样报文负载中的内容在经过NAT时就无需被修改了，只需按普通NAT流程转换报文头的IP地址即可，负载中的IP地址信息和报文头地址信息又是一致的。STUN协议就是基于此思路来解决应用层地址的转换问题。

用户的应用程序，作为STUN客户端(STUN CLIENT)向NAT外的STUN服务器(STUN SERVER)通过用户数据报协议(User Datagram Protocol，简称“UDP”)发送请求STUN消息，STUN SERVER收到请求消息，产生响应消息，响应消息中携带请求消息的源端口，即STUN CLIENT在NAT上对应的外部端口。然后响应消息通过NAT发送给STUN CLIENT，STUNCLIENT通过响应消息体中的内容得知其在NAT上对应的外部地址，并且将其填入以后呼叫协议的UDP负载中，告知对端，本端的实时传输协议(Real Time Transfer Protocol，简称“RTP”)接收地址和端口号为NAT外的地址和端口号。由于通过STUN协议已在NAT上预先建立媒体流的NAT映射表项，故媒体流可顺利穿越NAT。

STUN协议最大的优点是无需现有NAT/FW设备做任何改动。由于实际的网络环境中，已有大量的NAT/FW，并且这些NAT/FW并不支持分组语音(Voice over IP，简称“VoIP”)的应用，如果用MIDCOM或NAT/ALG方式来解决此问题，需要替换现有的NAT/FW，这是不太容易的。而采用STUN方式无需改动NAT/FW，这是其最大优势，同时STUN方式可在多个NAT串联的网络环境中使用。

根据STUN原理，STUN SERVER必须放在公网中，可以内嵌在公网软交换设备(SoftX)中，由于通过STUN协议已在NAT上预先建立媒体流的NAT映射表项，故媒体流可顺利穿越NAT。

STUN的局限性在于需要应用程序支持STUN CLIENT的功能，即NGN的网络终端需具备STUN CLIENT功能。同时STUN并不适合支持TCP连接的穿越，因此不支持H323应用协议。另外STUN方式还不支持NGN业务对防火墙的穿越，同时STUN方式不支持对称NAT类型的穿越。

TURN方式的解决NAT问题的思路与STUN相似，也是基于私网接入用户通过某种机制预先得到其私有地址对应在公网的地址，然后在报文负载中所描述的地址信息就直接填写该公网地址的方式。不同的是，STUN方式得到的地址为出口NAT上的地址，TURN方式得到地址为TURN服务器(TURN SERVER)上的地址。

TURN应用模型如图1所示，系统由会话型业务用户10、11，NAT/FW20、21，SoftX40、41以及TURN SERVER60组成。它通过分配TURN Server的地址和端口作为TURN客户端(TURN CLIENT)对外的接受地址和端口，即私网用户发出的报文都要经过TURN SERVER进行Relay转发。值得指出，这正是STUN方式与TURN方式区别最大的地方。这种方式应用模型除了具有STUN方式的优点外，还解决了STUN应用无法穿透对称NAT(SymmetricNAT)以及防火墙设备的缺陷，即无论企业网/驻地网出口为哪种类型的NAT/FW，都可以实现NAT的穿透，同时TURN支持基于传输控制协议(Transfer Control Protocol，简称“TCP”)的应用，如H323协议。此外TURNSERVER控制分配地址和端口，能分配实时传输协议(RealTime TransferProtocol，简称“RTP”)/实时传输控制协议(RealTime Transfer ControlProtocol，简称“RTCP”)地址对作为本端客户的接受地址，其中RTCP端口号为RTP端口号加1，从而避免了STUN应用模型下出口NAT对RTP/RTCP地址端口号的任意分配，使得客户端无法收到对端发过来的RTCP报文。

TURN的局限性在于需要终端支持TURN CLIENT，这一点同STUN一样对网络终端有要求。此外，所有报文都必须经过TURN SERVER转发，增大了包的延迟和丢包的可能性。

全代理(Full Proxy)方案是在NAT外有一个Proxy Server，私网内终端用户把Proxy Server看作是软交换设备，Proxy Server经过信令处理后再转发给真正的软交换；Proxy Server对软交换又可看作是用户，私网内终端用户作为被叫时，软交换设备把对被叫用户的呼叫请求先发给Proxy Server，ProxyServer经过信令处理后再转发给真正的被叫用户。Proxy Server同时作为媒体流的代理，无论主叫还是被叫的媒体流都经过Proxy Server。

其NAT穿越原理在于当私网终端呼叫信令到达Proxy时，Proxy Server将对呼叫信令协议进行解析，对协议中携带的RTP/RTCP信息进行解析与处理，在记录下呼叫信令地址和端口，用户私网媒体流RTP/RTCP地址和端口同时，修改呼叫信令私网地址信息和RTP/RTCP地址信息为Proxy Server本身对外的公网IP地址，同时修改呼叫信令端口和媒体流端口为Proxy Server上分配的外部端口，然后将呼叫信令发送到软交换或对端。这样呼叫信令以及媒体流就可以通过Proxy Server在主被叫之间进行中转。同时Proxy Server采用首包刷新方式来更新媒体流的会话表项，即在终端发出媒体后，经过企业出口的NAT进行转换到达Proxy Server，通过首包学习得到出口NAT上动态分配的地址和端口信息，从而更新媒体流会话表项，建立一个完整的媒体流会话表项，完成媒体转发功能。

在实际应用中，上述方案存在以下问题：当多媒体终端的信令收端口和发端口不一致时，可能造成信令无法穿越NAT或FW设备；当RTP或RTCP的收端口和发端口不一致时，可能造成媒体流无法穿越NAT或FW设备。尤其RTP收发端口不一致的情况在视频终端中非常普遍。

对于这个问题，以上提到的几种现有技术产生该问题的原因相似，以STUN为例，如果STUN CLIENT的RTP收发端口不一致，则通过STUN协议已在NAT上预先建立的是媒体流的RTP发端口的NAT映射表项(P1)，并没有RTP收端口的NAT映射表项(P2)，所以对端仍然把媒体流发送到NAT设备的P1，既而被NAT设备转到STUN CLIENT的RTP发端口上，但STUN CLIENT发端口并不处理接收的报文，将报文丢弃，造成STUN CLIENT无法听到对端的话音或图象。

另外，作为IP语音信令或NGN信令之一的H.323信令协议比较特殊，一个H.323呼叫过程涉及RAS、Q.931、H.245等三个呼叫信令协议和三种呼叫信令地址，并且Q931的呼叫信令地址依赖于RAS消息交互的结果，H.245的信令地址依赖于Q.931消息交互的结果，这种动态协商信令地址的方式在NAT穿越中也带来一些问题。

STUN并不适合支持TCP连接的穿越，因此不支持H.323应用协议(H.323协议体系中的Q.931等协议是基于TCP连接)。虽然TURN支持TCP连接的穿越，但由于呼叫过程中的Q.931和H.245地址通常并没有在TURN协议中交互，无法获得它们在NAT外的映射地址，所以TURN Client做被叫时，Server找不到被叫Q.931和H.245信令地址，无法建立起这些信令的TCP连接；如果在H.323的注册过程前也通过TURN协议把Q.931和H.245信令地址在NAT上进行映射，则必须是Client端首先发起TCP连接，并且为防止NAT老化保持这种连接，不管是否有真实的呼叫都如此，而H.245信令地址通常是在Q.931消息交互中才生成的，所以这是不合理的。

对于H.323应用协议，Full Proxy技术中的PROXY Server无法主动学习到NAT内的H.323终端的Q.931信令地址在NAT上的映射地址，所以也解决不了该终端做被叫时的接续问题。

发明内容

有鉴于此，本发明的主要目的在于提供一种多媒体业务网络地址转换穿越的方法及其系统，使得收、发端口不一致的信令和媒体流可以成功穿越NAT/FW。

为实现上述目的，本发明提供了一种多媒体业务网络地址转换穿越的方法，包含以下步骤：

A代理客户端收到来自分组用户终端的业务报文时，把所述业务报文封装在隧道报文的负载内容中，把该隧道报文通过网络地址转换服务器或防火墙的中转发送给代理服务器；

B所述代理服务器从收到的隧道报文的负载内容中解出所述业务报文，对所述业务报文的负载内容进行解析，修改负载内容中的地址和端口信息，将修改后的业务报文发送到软交换设备或对端分组用户终端；

C所述代理服务器收到来自所述软交换设备或对端分组用户终端的回应报文时，对该回应报文的负载内容进行解析，修改负载内容中的地址和端口信息，将修改后的回应报文封装在隧道报文的负载内容中，把该隧道报文通过所述网络地址转换服务器或防火墙的中转发送给所述代理客户端；

D所述代理客户端从收到的隧道报文的负载内容中解出所述回应报文，并将所述回应报文转发给所述代理客户端。

其中，所述步骤B中修改负载内容中的地址和端口信息的步骤包含以下子步骤：

记录所述负载内容中的呼叫信令地址和端口，以及媒体流实时传输协议和实时传输控制协议地址和端口，并且将所述负载内容中的呼叫信令地址修改成所述代理服务器为该呼叫分配的在公网中的呼叫信令地址和端口，将所述负载内容中的媒体流实时传输协议和实时传输控制协议地址和端口修改成所述代理服务器为该媒体流分配的在公网中的地址和端口；

所述步骤C中改负载内容中的地址和端口信息的步骤包含以下子步骤：

将所述负载内容中回应信令地址和端口修改成所述被记录的呼叫信令地址和端口，将所述负载内容所携带的媒体流实时传输协议和实时传输控制协议地址和端口，修改成所述被记录的媒体流实时传输协议和实时传输控制协议地址和端口。

还包含以下步骤：

所述代理服务器向所述代理客户端发送所述隧道报文前先对所述隧道报文的负载内容进行加密；

所述代理客户端收到来自所述代理服务器的所述隧道报文时，对所述隧道报文的负载内容进行解密；

所述代理客户端向所述代理服务器发送所述隧道报文前先对所述隧道报文的负载内容进行加密；

所述代理服务器收到来自所述代理客户端的所述隧道报文时，对所述隧道报文的负载内容进行解密。

还包含以下步骤：

所述代理服务器和所述代理客户端在建立隧道连接时相互认证。

本发明还提供了一种多媒体业务网络地址转换穿越的系统，包含分组用户终端、代理客户端、网络地址转换服务器或防火墙、代理服务器和软交换设备；

所述分组用户终端位于私网内，用于发起和接收业务；

所述代理客户端位于私网内，用于把来自所述分组用户终端的业务报文封装到隧道报文的负载内容中，将该隧道报文向所述代理服务器发送，并且从来自所述代理服务器的隧道报文的负载内容中解出回应报文，将该回应报文发送给所述分组用户终端；

所述网络地址转换服务器或防火墙用于为所述分组用户终端提供接入公网的服务，并为所述代理客户端和所述代理服务器相互转发隧道报文；

所述代理服务器位于公网内，用于从来自所述代理客户端的隧道报文中解出业务报文，对所述业务报文的负载内容进行解析，修改该负载内容中的地址和端口信息，将修改后的业务报文发送到软交换设备或对端分组用户终端，并且对来自所述软交换设备或对端分组用户终端的回应报文的负载内容进行解析，修改该负载内容中的地址和端口信息，将修改后的回应报文封装在隧道报文的负载内容中，把该隧道报文向所述代理客户端发送；

所述软交换设备用于提供综合业务和呼叫控制，在收到回应给所述分组用户终端的报文时转发给所述代理服务器。

其中，所述代理服务器和所述代理客户端之间是基于用户数据报协议或传输控制协议的隧道。

所述代理服务器和所述代理客户端之间的隧道采用通用路由封装协议或网际协议安全协议进行通信。

所述网络地址转换服务器或防火墙是多级串联的。

通过比较可以发现，本发明的技术方案与现有技术的区别在于，在NAT/FW的内外分别设置了代理客户端和代理服务器，代理客户端为私网中的不同分组用户终端分配不同的UDP或TCP端口，从而和代理服务器建立不同的隧道。对分组用户终端向公网发送的报文，首先在代理客户端被封装为隧道报文，然后通过NAT/FW发送到代理服务器，此后在代理服务器被解封装为原先的报文并转发。类似的，对从公网返回分组用户终端的报文，首先在代理服务器被封装为隧道报文，然后通过NAT/FW发送到代理客户端，此后在代理客户端被解封装为原先的报文并转发到相应的分组用户终端。

这种技术方案上的区别，带来了较为明显的有益效果，即能彻底地解决由于分组用户终端的RTP收发端口不一致造成媒体流无法穿越NAT/FW的问题，并且可以穿越多级串联的NAT/FW，还能彻底解决类似H.323这种动态协商呼叫信令端口的协议的NAT/FW穿越问题。这是因为收、发端口不一致的信令和媒体流报文在代理客户端或代理服务器被封装为同一端口号的隧道报文，因此可以顺利通过NAT/FW。而在私网处，代理客户端可以用任意的端口与同一私网内的分组用户终端通信，同时在公网处，代理服务器可以用任意的端口发送或接收需要与私网内分组用户终端交互的报文。

本发明方案不需要修改分组用户终端或改造网络中的NAT/FW设备，可以保护原先的投资，对不拥有分组用户终端和NAT/FW设备所有权的电信运营商更为适合。

此外可以通过对隧道报文的加密提高信息传送的安全性。

附图说明

图1是TURN方式下的系统结构图；

图2是根据本发明的一个实施例的多媒体业务NAT穿越的系统结构图；

图3是根据本发明的一个实施例的呼叫信令NAT穿越的方法流程图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述。

现参照图2描述根据本发明的一个实施例的FULL PROXY方式的系统结构图。

为突出本发明，图中只标出与本发明有密切关系的部分。如图2所示，系统由分组用户终端10和11、NAT/FW20和21、代理服务器30、软交换设备(SoftX)40和41组成。其中，分组用户终端10、11分别通过NAT/FW20、21跟代理服务器30相连；代理服务器30与SoftX40、41相连。图中实线为媒体流，虚线为信令流。

分组用户终端10、11是指使用诸如H.323、会话初始化协议(SessionInitation Protocol，简称“SIP”)、媒体网关控制协议(Media Gateway ControlProtocol，简称“MGCP”)、H.248等音频/视频协议通信的终端用户。它们是业务的发起者和接收者，位于私网中。

NAT/FW20、21是实现NAT功能和防火墙功能的设备，通常配置在私网接入公网的位置。它一方面用于防止数据包无限制的进入网络内，保护私网内主机不受外界攻击；另一方面通过网络地址端口转换，隐藏私网IP，使私网内的多个终端能够共享较少数量的公网IP地址。如现有技术中所述，NAT/FW20、21一般无法让音频/视频流实现穿越。

代理服务器30处在公网中，用于同私网中的代理客户端50、51一起构架用于穿透NAT/FW20、21的隧道，并且对来自或发向分组用户终端的原始报文进行全代理转换。这里说的隧道是指UDP或TCP的通道。代理服务器30与代理客户端50、51之间的隧道对通过该隧道传输的业务报文来说是透明的。

SoftX40、41是软交换设备，作为NGN的网络控制层的关键构件，用于提供综合业务和呼叫控制。

代理客户端50、51处在私网中，为各自私网中的不同分组用户终端(如分组用户终端10、11)分配不同的UDP或TCP端口，从而和代理服务器30建立不同的隧道。

当代理客户端50、51收到需要传输到公网的报文时，将构造一个新的隧道报文，把要传输的报文作为隧道报文的负载内容，增加隧道的IP头信息、UDP/TCP信息，让后把该隧道报文转发给代理服务器30。代理服务器30收到该隧道报文以后，记录隧道信息(IP头信息，UDP/TCP信息)，然后从隧道报文的负载内容中解出原始报文，并对原始报文的负载内容进行解析，记录原始报文的负载内容中的呼叫信令收发地址/端口、媒体RTP/RTCP的收发地址/端口，然后将该呼叫信令收发地址/端口修改成代理服务器30为该呼叫分配的在公网中的呼叫信令地址/端口，将RTP/RTCP的收发地址/端口修改成代理服务器30为该媒体流分配的在公网中的地址/端口。然后将该报文发送给SoftX40、41或对端分组用户终端。

当代理服务器30收到来自SoftX40、41或对端分组用户终端的回应报文时，先对负载内容进行解析，将该负载内容中的呼叫信令收发地址/端口修改成记录的呼叫信令收发地址/端口，将该负载内容中的媒体RTP/RTCP的收发地址/端口修改成记录的RTP/RTCP的收发地址/端口，然后将修改后的报文填入一个新建隧道报文的负载中，增加以前记录的隧道的IP头信息、UDP/TCP信息，然后发送到代理客户端50、51。代理客户端50、51从收到的隧道报文的负载内容中解出回应报文，将该回应报文发送给相应的分组用户终端。

由于代理客户端50、51的收发端口可以完全一致，因此可以有效地解决收、发端口不一致导致的信令和媒体流无法穿越NAT/FW的问题。由于隧道对要传输的报文来说是透明的，因此对于H.323信令协议也可以很好地支持。

此外，为了防止NAT/FW20、21上隧道映射地址的老化，需要在代理服务器30和代理客户端50、51之间增加一种简单的心搏消息，例如可以定时从代理客户端50、51向代理服务器30发送一个没有内容的空报文。

下面再结合图3具体说明根据本发明的一个实施例的呼叫信令NAT穿越的方法。

在步骤110中，分组用户终端10向代理客户端50发送呼叫信令报文，该报文的IP头源地址是分组用户终端10的IP/端口，该报文的目的地址是代理服务器30的IP/知名端口。所谓知名端口是指在业界已经形成行业标准或约定俗成的与某一种应用对应的端口，例如端口21是文件传输协议(FileTransfer Protocol，简称“FTP”)的知名端口。该报文的UDP/TCP头信息是原始呼叫信令报文的UDP/TCP头。该报文的UDP/TCP报文负载是原始的呼叫信令报文内容。

此后进入步骤120，代理客户端50收到来自分组用户终端10的呼叫信令报文时，构造一个新的隧道报文，把要传输的报文作为隧道报文的负载内容，增加隧道的IP头信息、UDP/TCP信息，让后把隧道报文转发给NAT/FW20。该报文的IP头源地址是代理客户端50的IP/端口，该报文的目的地址是代理服务器30的IP/知名端口。该报文的UDP/TCP头信息是隧道UDP/TCP头。该报文的UDP/TCP报文负载是呼叫信令报文或者呼叫信令报文的某种变换形式，例如在呼叫信令报文的开头增加一些私有协议字段或对报文进行加密。

此后进入步骤130，NAT/FW20对收到的隧道报文作常规的NAT地址转换，为该隧道报文分配一个公网地址/端口，替换该隧道报文的私网源地址/端口，然后记录下被分配的公网地址/端口和被替换的私网地址/端口之间的对应关系，最后将该隧道报文发送给代理服务器30。该报文的IP头源地址是NAT/FW20对代理客户端50隧道地址所做的映射IP/端口，该报文的目的地址是代理服务器30的IP/知名端口。该报文的UDP/TCP头信息是隧道UDP/TCP头。该报文的UDP/TCP报文负载是呼叫信令报文或者呼叫信令报文的某种变换形式。熟悉本发明领域的技术人员会理解，在NAT/FW20中的地址对应关系失效以前，一旦NAT/FW20收到来自公网的发向上述被分配的公网地址/端口的报文，则NAT/FW20会将该报文的公网地址/端口转换成记录的私网地址/端口，并转发给私网中的相应分组用户终端。

此后进入步骤140，代理服务器30收到该隧道报文以后，记录隧道信息(IP头信息，UDP/TCP信息)，然后从隧道报文的负载中解出原始呼叫信令报文，并对原始呼叫信令报文的负载内容进行解析，记录原始呼叫信令报文的负载内容中的呼叫信令收发地址/端口、媒体RTP/RTCP的收发地址/端口，然后将该呼叫信令收发地址/端口修改成为该呼叫分配的在公网中的呼叫信令地址/端口。然后将该报文发送给SoftX40。该报文的IP头源地址是代理服务器30为该呼叫分配的在公网中的呼叫信令地址/端口，该报文的目的地址是SoftX40的IP/知名端口。该报文的UDP/TCP头信息是代理服务器和软交换设备通信协议的UDP/TCP头。该报文的UDP/TCP报文负载是对原始呼叫信令报文内容进行相关地址变换后的呼叫信令报文内容。

此后进入步骤150，SoftX40向代理服务器30发送回应的信令报文。该报文的IP头源地址是SoftX40的IP/端口，该报文的目的地址是代理服务器30为该呼叫分配的在公网中的呼叫信令地址/端口。该报文的UDP/TCP头信息是软交换设备和代理服务器通信协议的UDP/TCP头。该报文的UDP/TCP报文负载是SoftX40回应的信令报文内容。熟悉本发明领域的技术人员会理解，代理服务器30也可以直接将呼叫信令报文直接发送给对端分组用户终端，然后从对端分组用户终端获得回应的信令报文，这并不影响本发明的实质和范围。

此后进入步骤160，当代理服务器30收到SoftX40回应的信令报文时，先对该报文的负载内容进行解析，将该报文中呼叫信令收发地址/端口修改成记录的呼叫信令收发地址/端口，将媒体RTP/RTCP的收发地址/端口修改成记录的RTP/RTCP的收发地址/端口，然后将修改后的报文填入一个新建隧道报文的负载中，增加以前记录的隧道的IP头信息、UDP/TCP信息，然后发送到NAT/FW20。该报文的IP头源地址是代理服务器30的IP/知名端口，该报文的目的地址是NAT/FW20对代理客户端50隧道地址所做的映射IP/端口。该报文的UDP/TCP头信息是隧道UDP/TCP头。该报文的UDP/TCP报文负载是对SoftX40回应的信令报文内容进行了相关地址变换后的回应信令报文，或者是回应信令报文的某种变换形式，例如在该报文的开头增加一些私有协议字段或对该报文进行加密。

此后进入步骤170，NAT/FW20对收到的对收到的隧道报文作常规的NAT地址转换，根据NAT/FW20的地址映射表中的内容，将该隧道报文的目的地址从公网地址/端口转换成记录的代理客户端50的私网地址/端口，并转发给私网中的代理客户端50。该报文的IP头源地址是代理服务器30的IP/知名端口，该报文的目的地址是代理客户端50的IP/隧道端口。该报文的UDP/TCP头信息是隧道UDP/TCP头。该报文的UDP/TCP报文负载是对SoftX40回应的信令报文内容进行了相关地址变换后的回应信令报文，或者是回应信令报文的某种变换形式。

此后进入步骤180，代理客户端50从收到的隧道报文的负载中解出回应信令报文，将该回应报文发送给分组用户终端10。该报文的IP头源地址是代理服务器30的IP/知名端口，该报文的目的地址是分组用户终端10的IP/端口。该报文的UDP/TCP头信息是代理客户端50到分组用户终端10转发报文的UDP/TCP头。该报文的UDP/TCP报文负载是SoftX40回应的信令报文内容进行了相关地址变换后的回应信令报文内容。

熟悉本发明领域的技术人员会理解，媒体流RTP/RTCP报文的处理流程以及H.323呼叫过程的实现与上述呼叫信令的处理类似。

同时代理服务器30和代理客户端50之间隧道的协议既可以采用上述简单的方式或自定义一套私有协议，也可以采用一些标准的协议，如通用路由封装(Generic Route Encapsulation，简称“GRE”)协议、网际协议安全(InternetProtocol Security，简称“IPSec”)协议等。为保证信息安全，还可以采用信息加密的方式，比如数据加密标准(Data EncryptionStandard，简称“DES”)、三倍数据加密标准(3DES)加密等，而且不论控制信令还是媒体流都可以加密。为了防止非法的代理客户端接入，代理客户端和代理服务器在建立隧道连接时可以互相认证和数据加密，认证方法可以采用MD5或者SHA-1等。

另外，如果企业的的路由器/NAT/FW/BAS设备都支持GRE协议或IPSec协议或其他隧道协议，则可以不增加代理客户端，而直接通过这些设备和代理服务器上的GRE隧道或IPSec隧道实现类似上述隧道方案，解决上述收发端口不一致造成的问题。但路由器/NAT/FW/BAS设备不一定支持GRE或IPSec等隧道协议，而且网络规划会相对麻烦，所以这只是一种备选的技术解决方案，不推荐使用。

虽然通过参照本发明的某些优选实施例，已经对本发明进行了图示和描述，但本领域的普通技术人员应该明白，可以在形式上和细节上对其作各种各样的改变，而不偏离所附权利要求书所限定的本发明的精神和范围。