一种跨越私网实现多媒体呼叫的系统和方法 【技术领域】
本发明涉及一种支持跨越私网实现多媒体呼叫的系统及其方法，它主要涉及在Internet网上进行语音、视频、数据及其混合的呼叫的领域，可以支持不同私网内的多媒体终端或媒体网关、私网内的多媒体终端或媒体网关与公网内的多媒体终端或媒体网关进行语音、视频、数据等多媒体互通的技术。
背景技术
在当前向NGN(Next Generation Network，下一代网络)的技术演进中，已经可以通过多种手段、如Softswitch(软交换)、H.323等方式，实现语音、视频等多媒体信息在IP等分组网、PSTN等传统电话交换网上的交互。
特别是在IP等分组网中，由于存在多种组网方式，如广域网、局域网等；这样在实现多媒体信息互通中，就会遇到公网与私网、私网与私网内的MediaGateway(媒体网关)和IP电话等设备互通的情况。
由于私网地址不能在公网中使用，因此如何将私网地址转换为公网地址、如何寻找目的地的公网地址与对应地私网地址，是解决这一问题的关键。
在现有的IP技术中，使用NAT(网络地址转换)协议是一种常见的方法。NAT协议可以事先将每个私网内的设备的私网地址与一个对应的公网地址相关联，当这个设备需要与非本网的媒体网关或IP电话等设备进行通讯时，所有发出的含有信令流和媒体流消息的IP包均将在一个专门设备中使用NAT协议替代为相应的公网地址，然后再转发出去。由于主被叫两侧都通过NAT协议将地址转换为了公网地址，因此使用当前所有现成的成熟的路由协议都可以找到被叫侧，进行实现语音、视频通讯。这种方式的最大优点是简单，但缺点也特别明显：
√使用私网地址的一大原因是由于公网地址资源缺乏；而对于实现基于分组(如IP)的语音、视频等呼叫业务的特性而言，采用NAT方式，将耗费大量的地址资源。这是因为，首先，对于每个设备都将预先分配一个公网地址，以便关联一个私网地址；如果这个设备根本不在线时，但这个关联仍将存在，而不会被动态分配。其次，媒体网关或IP电话等设备在呼叫建立期间需要一个端口用于呼叫信令的交互，同时一旦进入通话状态，则需要其它端口用于语音、视频等多媒体流的传输；使用NAT协议，只能预先建立这些私网端口与公网相应的地址和端口的关联。这样，即使这个媒体网关或IP电话等设备不在使用，这些用于媒体流的端口也必须保持关联，从而造成地址资源浪费。
√在媒体网关或IP电话等设备与其呼叫控制器(如软交换、H.323中的GateKeeper(网守)等)的消息交互中，广泛使用了多种信令协议，如H.248、MGCP、SIP、H.323等，其中在能力协商时携带了主被叫媒体流的地址信息。而NAT协议只能进行IP包头中的地址转换，对于IP包中的协议净荷内容是不干预的，因此这些媒体流地址(仍是私网地址)不可能进行转换；从而使得媒体流无法送达而失败。这是使用NAT方案最本质的弱点。
针对以上NAT方案的缺点，目前也出现了其它改进的解决方案，如协议分析网关：
√私网内的媒体网关或IP电话等设备不直接向呼叫控制器(如软交换、网守等)发送信令消息，而是将这些消息先发到协议分析网关处，协议分析网关可以根据其私网地址静态地或动态地关联到公网地址上，然后协议分析网关再转发到呼叫控制器(软交换、网守等)。同样的，媒体流也是动态的关联了公网地址，从而实现媒体流的互传。
√这个方案最大的优点在于协议分析网关不只进行公网、私网地址的转换，而且它还针对每个协议，将其中涉及媒体流的私网地址也转换为公网地址，如对于H.248、MGCP、SIP协议中，可以对其中的SDP进行分析，提取和替换其中的私网地址。
但是，这个方案也有自己的缺点：
√私网内的媒体网关或IP电话等设备由于不直接向呼叫控制器发送命令，会影响某些功能的实现(如切换、接入认证以及移动等功能)；同时对于这些呼叫控制器而言，管理到的是协议分析网关所对应的公网地址，管理不到真正的私网内的媒体网关或IP电话等设备，这也会影响某些功能实现(如网络拓扑、定位等功能)。
√私网内的媒体网关或IP电话等设备由于不直接向呼叫控制器发送命令，因此移动到其它私网时与新的协议分析网关配合时有困难。
√这个方案由于参与分析和改变信令内容，影响了IP包净荷的完整性。特别是，如果这些IP包使用了安全特性，如加密，可能根本无法实现地址替换。
√这个方案要求对于每个协议都需要自己的协议分析网关，并且随私网内的媒体网关或IP电话等设备使用协议的增加而增加。
√这个方案的结果即使是同一私网的设备的呼叫，也将通过协议分析网关转发，这样，一方面媒体流的转发增加了协议分析网关的处理量；另一方面，由此也会影响设备的语音质量。
在所查询的已有专利中，在中华人民共和国国家知识产权局网页中，(http：//www.sipo.gov.cn/sipo/zljs/default.htm)使用关键词：IP查询，没有找到相关的专利文献。(截止2003/3/24)
在摘要中使用“私网”为关键词检索摘要，有一份相关的专利：
◆中国专利申请号01135610.3(公开号CN1411220A)，名称为私有网络的IP语音业务实现方法及系统的发明专利申请
该专利申请是由华为提出的，它描述的是，在私网中的终端向VoIP服务器注册时，利用NAT协议将呼叫所需要的所有信令通道、媒体通道的私网地址转换为对应的公网地址，并始终维持这些通道的占用的方法。
它与本发明实现思想上有本质的不同：
1)属于NAT实现方式，其优缺点请参见上文“背景技术”中的介绍，使用该专利申请技术时，存在即使不呼叫也会占用大量的NAT公网地址而造成资源浪费的缺陷。因此，这种方法在具有相同地址转换能力情况下，接入的用户远比本发明少。换言之，效率不高。
2)该专利申请技术为了弥补NAT协议中只能修改IP地址不能修改信令内容的缺点，对标准的VoIP协议(申请专利中指的是MGCP协议)进行了扩充，使得“由VoIP服务器将对应逻辑通道的公网地址和端口号在响应私网用户PC客户端登录请求的应答消息中发送给该PC客户端”。这属于对标准协议的修改，与本发明的出发点截然不同。
3)从该专利申请看，即使是同一私网内的用户的通话，都必须经过公网绕一圈，这样会造成语音延时增加，从而导致语音质量下降，而且内部通话的安全性也下降。
4)从该专利申请看，对于私网套私网的情形没有说明，就其篇幅所涉及而言，实现私网套私网是可以的，但有许多重要环节需要明确予以说明公开，如地址代理服务器与VoIP的连接，网关如何工作等等。
而查询http：//www.uspto.gov，使用关键词(((″PRIVATE NETWORK″ORNAT)AND″IP ADDRESS″)AND TELECOMMUNICATION)可以查到约93个专利(截止2003/3/24)，绝大部分与本专利无关，相关的有以下一些：
◆美国专利6,526,056号Virtual private network employingtag-implemented egress-channel selection(使用打TAG标答的方式选择外出通道的虚拟专用网)
该专利是由CISCO提出的，它通过TAG标识不同的VPN(虚拟专用网)；
它在不同VPN的边缘路由器中根据目的地VPN封装TAG(这个TAG是两个VPN边缘路由器协商好的)，然后通过在发端发数据时加上该TAG，而在接收端去除该TAG，从而实现跨越私网的目的。它与本发明相关，但没有冲突。它由于是通过边缘路由器协商确定TAG值，没有一个呼叫控制器来协调管理全域中的TAG值，因此不构成一个跨越私网进行多媒体呼叫的系统，特别对于多媒体呼叫实现复杂组网方式时(如私网套私网的情形)是有困难的。该美国专利所介绍的相当于本发明中边界网关(BGW)所实现的一种方式。
◆美国专利6,523,068号Method for encapsulating and transmitting amessage includes private and forwarding network addresses with payloadto an end of a tunneling association(封装和传输将含有私有的前一跳网络地址作为隧道连接一端的负荷类型的消息的方法)
该专利是3Com提出的，用于在从私网发包前加以封装，然后通过隧道发送；以及在公网接收该包后予以识别。该专利的思想与本发明所介绍的系统的一种实现方式相关，同上文专利一样，它具体介绍了如何将私网中的包发送到公网上的方法，而非整个系统。这是与本发明的不同之处，本发明所描述的系统除此之外，还有其它有关如何建立私网间的连接从而进行多媒体呼叫的内容。
◆美国专利6,496,867号System and method to negotiate private networkaddresses for initiating tunneling associations through private and/orpublic networks(在通过公用/私用网络时当发起初始隧道连接时协商私网地址的系统和方法)
它也是由3Com提出的，类似于美国专利6523068号，介绍了有关如何在公网与私网间建立隧道的系统和方法-它通过第三方设备、边缘设备协商源与目的私网设备的公网地址。它与本发明所述的系统最接近，都是通过隧道方式穿越私网，但其中实现的核心思想却是有很大的不同。
1)在该专利中，第三方设备的作用仅是得到目的地的公网地址，并且它只是协商同一网络中的源和目的边缘设备的IP地址，即是段到段的；而本发明则目标是端到端的，从设备使用和技术复杂度上要简单的多。在多媒体呼叫中，这种段到段的协商公网地址的方法，会导致呼叫控制方式繁琐分散，而且很难完成一些业务逻辑的实现。
2)在该专利中，通篇讲述的是在一个公网中的两个不同子网间的跨私网通讯，源端边缘设备(相当于本发明中的边界网关)保存有源端设备的私网地址、目的端边缘设备的公网地址和目的端设备的私网地址的地址表，由此来确定路由。如果是私网套私网的情形，从其论述推断，由于源端边缘设备不能直接得到目标端设备的私网地址(因为中间隔了多个私网，有多个边缘设备)，因此按该专利方法查找路由会失效，除非它增加更多的标识来标识这个隧道。本发明由于采用了别的方法，不存在此类问题，可以实现私网套私网的组网情况。
3)在该专利中，其方法的核心是希望源端设备和目的端设备的通讯，如同在同一网络一样。因此它将源端和目的端设备的IP地址分配动态化，然后在发起通讯时，通过传递私网地址或从多个私网地址中选择的方式，将源端和目的端的私网地址选择为同一网络的IP地址，同时保证这些地址在各自的网络中不重复。这样，任一端的数据流发向对端时，将首先被转到相应的边缘设备(由于目的地址不是本私网中)，然后通过边缘设备内部相应的地址表找到对端的边缘设备，进而找到对端设备，完成数据交互。好处显而易见，但最大的问题是由于私网地址的传递影响了目的地私网中设备的IP地址分配规划，会影响目的地私网设备有些与源端设备通讯无关的业务工作不正常；因为该IP地址被分配为与源端同一网络内的地址，则假如同时需要上网浏览，则由于该业务是与源端无关的业务，而可能由于IP地址的缘故而失败。其次，由于要传递私网地址，这就要求源和目的的私网地址即使在不通讯时，也要按同一网络规划，这对于某些应用(如公司总部与各地区分部间的通讯)可以做到，但对于不同公司，甚至不同运营商间的通讯，此要求过于苛刻。第三，由于要传递私网地址，可能会给目的端设备带来安全性上的隐患。而在本发明中，对于IP地址的规划没有要求，也不会破坏目的端的IP地址规划；因此适用范围比该专利要广泛得多。
◆美国专利6,006,272号Method for network address translation(网络地址转换的方法)
它介绍的内容为：每个私网中的设备需要配置私网地址、对应的公网地址和MAC地址；路由器根据目的地址判断是公网还是地网，从而进行地址转换。该专利仅涉及到NAT，与上述所介绍的NAT转换类似，优缺点已经在上文介绍过。
以上，已详细说明了现有技术各解决方案的技术特点及其缺陷，显然现有技术尚有需要改进之处。
【发明内容】
本发明的目的在于提供一种跨越私网实现多媒体呼叫的系统和方法，通过设置硬件系统中的至少一跨越边界的边界网关，一用于全局控制的呼叫控制器，以及至少一媒体网关，连接多个不同类别的媒体终端和所述边界网关，通过该边界网关接受所述呼叫控制器的控制，并在该呼叫控制器的控制之下，通过所述边界网关之间建立不同私网或者私网与公网之间的信令消息隧道和媒体通道，以解决上述方案的缺点，既要支持私网穿越，又要能够不改变信令内容，从而保证私网内发出的IP包净荷的完整性。
进一步地，本发明的目的还在于提供一种跨越私网实现多媒体呼叫的系统和方法，由于有所述呼叫控制器的统一控制，同一子网内的媒体网关之间的媒体流直接在两个媒体网关之间的可达路由传递，不需要经过边界网关等设备转发。
更进一步地，本发明的目的还在于提供一种跨越私网实现多媒体呼叫的系统和方法，由于在私网套私网的环境中可在所述呼叫控制器的控制下，通过多个边界网关，其中包括中间边界网关，建立外网，如其他私网或公网，到内部私网的信令消息隧道或媒体通道，实现更复杂网络结构下的数据传递。
本发明的技术方案如下：
一种跨越私网实现多媒体呼叫的系统，其包括一公网及至少一私网，以及以下硬件部分：
至少一边界网关，即协议分析网关，位于所述私网与所述公网的边界处，用于完成私网地址与公网地址的相互映射，以及对这些映射关系的建立和维护，并且该边界网关不对信令内容进行修改；
一呼叫控制器，与所述边界网关通讯连接，用于负责呼叫的建立和业务逻辑的控制和实现，负责指导建立跨越私网的路径的建立；
至少一媒体网关，用于连接所述呼叫控制器或所述边界网关，以及各类协议的多媒体终端，为各类多媒体业务的接入点；
以及以下软件代码部分：
在所述边界网关上安装相应路由寻址、子网判断、隧道管理功能的程序，该程序存储于相应存储空间及内存中；
在所述呼叫控制器上安装支持子网管理、指导边界网关维护隧道的程序，该程序存储于相应存储空间及内存中；
在所述媒体网关上安装支持边界网关管理的程序，该程序存储于相应存储空间及内存中。
所述的系统，其中，所述系统还可以包括一第二边界网关，其位于私网套私网环境中的内部私网的边界，用于连接所述边界网关和各类协议的多媒体终端，为各类多媒体业务的接入点。
一种跨越私网实现多媒体呼叫的方法，其系统包括一公网及至少一私网，以及至少设置以下硬件部分：
至少一边界网关，即协议分析网关，位于所述私网与所述公网的边界处，用于完成私网地址与公网地址的相互映射，以及对这些映射关系的建立和维护，并且该边界网关不对信令内容进行修改；
一呼叫控制器，与所述边界网关通讯连接，用于负责呼叫的建立和业务逻辑的控制和实现，负责指导建立跨越私网的路径的建立；
至少一媒体网关，用于连接所述呼叫控制器或所述边界网关，以及各类协议的多媒体终端，为各类多媒体业务的接入点；该方法至少包括以下步骤：
a)将所述呼叫控制器所能控制的域中的所有媒体网关所作的子网予以编号，并分配一个全域唯一的子网标识号；
b)在配置所述边界网关时，配置其所在的子网标识号，该子网标识号与所述呼叫控制器的对应子网标识号一致，同时，该边界网关将所述呼叫控制器作为信令的接收者；
c)当所述媒体网关向所述呼叫控制器发送信令消息时，所述媒体网关按照各自协议的要求，组装为正常的信令消息，并发向与该媒体网关相连接的边界网关；
d)所述边界网关收到该信令消息后，即主动发起一个从本边界网关到所述呼叫控制器的路径并时刻予以维护，根据所述子网标识号予以判断，如果所述边界网关与所述呼叫控制器在同一子网内，所述信令信息直接合成一个隧道包的净荷后发送到该呼叫控制器；否则，所述边界网关和所述呼叫控制器建立一条经过中间边界网关的隧道，将本信令消息合成一个隧道包的净荷后经所述隧道发送给所述呼叫控制器；
e)所述呼叫控制器返回的应答，通过所述隧道发回原先发出信令的媒体网关。
所述的方法，其中，所述方法还包括以下步骤
f)所述呼叫控制器向呼叫的另一方发出信令请求时，所述呼叫控制器根据所述子网标识号判断被叫侧媒体网关所在的子网是否与本身所在的子网属于同一个网络，如果属于同一个网络，则直接发送信令消息，否则所述呼叫控制器向媒体网关所在的对应边界网关发出建立隧道的请求，所述边界网关建立一条经过中间边界网关(如果媒体网关与边界网关之间还有多个私网时需要中间边界网关)的隧道。
所述的方法，其中，所述方法传送媒体流时还包括以下步骤
g)所述呼叫控制器向所述边界网关发出建立媒体通道的命令请求，并指示该边界网关被叫处于被叫边界网关内，该边界网关根据这些指示，自动发出建立从本边界网关经中间边界网关到被叫边界网关的媒体通道；
h)该媒体通道在呼叫开始时动态建立，呼叫结束后自动删除，以节约资源；
i)同一私网内的两个或多个媒体网关之间的呼叫和通话，其媒体流不通过边界网关进行转发，而是在两个媒体网关之间的可达路由上直接传递。
本发明提供的一种跨越私网实现多媒体呼叫的系统和方法，由于采用了上述跨越边界的边界网关，用于全局控制的呼叫控制器，以及至少一个媒体网关，该媒体网关通过对应边界网关，在所述呼叫控制器的控制之下，实现跨越不同私网或者私网与公网之间的信令消息和媒体流交互，即实现了穿越私网，同时对信令内容无改变，从而保证了从私网发出的IP包净荷的完整性，适用于不同协议方式信令信息及媒体流在不同私网之间或私网与公网之间的交互，简单方便，节省地址资源，使用范围更广，并减少了数据传输的冗余路径。
而且，本发明提供的一种跨越私网实现多媒体呼叫的系统和方法，由于其设置有所述呼叫控制器的统一控制，同一子网内的信令消息直接合成一个隧道包的净荷发送给所述呼叫控制器，而无需经外网传递，从而减少了网内数据交互的路径，并且增加了数据传输的安全性。
以及，本发明提供的一种跨越私网实现多媒体呼叫的系统和方法，还由于其在私网套私网的环境中可在所述呼叫控制器的控制下，通过多个边界网关，其中包括中间边界网关，建立外网，如其他私网或公网，到内部私网的信令消息隧道或媒体通道，实现了更复杂网络结构下的数据传递，并且相同地址转换能力情况下，本发明的效率更高。
总体来讲，采用本发明，与现有技术相比，其优势在于：
1)通过所述呼叫控制器的动态管理信令信息隧道和媒体通道，可以节省边界网关的资源；
2)边界网关不修改媒体网关发送和接收的信令消息的内容，不影响信令数据的完整性，从而扩展了边界网关的使用范围。
3)边界网关由于不需要修改信令消息的内容，可以不再关心媒体网采取何种协议，因此大大减少已有方案中针对每种协议的边界网关的数量，降低了边界网关实现的难度，提高了其处理效率和处理能力。
4)边界网关由于不再是媒体网关信令的接收和处理者，不关心信令内容，因此媒体网关的安全性和移动性与没有私网情况下时是一样的，媒体网关可以通过DHCP(动态主机地址分配协议)技术在所述呼叫控制器所管理的全域内移动。
5)所述呼叫控制器不负责寻址，而是通过告诉边界网关目的地位置所在以后由边界网关自行寻址到目的地的路径，因此所述呼叫控制器可以将自己定位于业务的实现和提供上，而非路径的建立和维护，这对于实现一些复杂的有分支的业务(如会议电视、统一消息(UnifiedMessage)等业务)可以降低实现的复杂度。
6)所述呼叫控制器可以直接管理到所有媒体网关，掌握媒体网关的网络拓扑，因此对于原有网络中的同一私网内的呼叫，媒体流完全可以直接在相应的媒体网关中交互，而不必通过边界网关转发，因此提高了服务质量。
7)本系统支持对于私网套私网等复杂的网络情形。
8)本系统支持对于同一个私网中有多个边界网关的情形。
【附图说明】
图1为本发明的一种跨越私网实现多媒体呼叫的系统和方法的原理框架图；
图2为本发明的系统和方法的另一较佳实施例的原理框架及其方法流程示意图；
图3为本发明的系统和方法的第三较佳实施例的原理框架及其方法流程示意图；
图4为本发明的系统和方法的第四较佳实施例的原理框架及其方法流程示意图。
【具体实施方式】
下面结合附图对本系统的几种典型的实现方式进行详细描述。
本发明所述的可跨越私网进行多媒体呼叫的系统，如图1所示的，是至少包括以下几个必备硬件部分和相应的软件代码：
A)多个边界网关100、101、102(BGW)，即上文中提到的协议分析网关，其位于私网与公网的边界处，它的主要作用是完成私网地址和公网地址的相互映射，以及这些映射关系的建立和维护。与现有技术有所不同，该边界网关不对信令内容进行修改，从而保证了信令内容的完整性。
B)一呼叫控制器200，如上文中提到的软交换Softswitch，它的功能是负责呼叫的建立和业务逻辑的控制和实现，负责指导建立跨越私网的路径的建立。
C)多个媒体网关300、301、302、303，可能为或连接有使用各类协议如H.248、MGCP、SIP、H.323的媒体网关或多媒体终端等，是各类多媒体业务的接入点。
这些部件均可位于同一网络中，可以是基于IP/ATM传输网络，也可以位于不同网络，如私网和公网，甚至可以位于私网套私网的环境中。图1所示是本发明系统典型的组网结构图。其中子网1相当于公网，子网2和子网3则相当于私网，而子网4又是子网3中的一个私网，即私网套私网的情况。各个子网中的媒体网关300、301、302、303、304、305可以在所述呼叫控制器200的控制下进行多媒体呼叫，传递语音和视频、数据等媒体流信息，其分别连接有本网内的多媒体终端，如IP电话或个人计算机PC，如图示标号为400～405的各装置。当跨越私网时，如子网2内的多媒体终端通过其媒体网关300或301要与外网如公网(即子网1)、或子网3或子网4交互时，由所述边界网关100在所述呼叫控制器200的指导下，自行建立交互的边界网关的路径并时刻予以维护。
与此同时，对于所述边界网关100、101、102等均需要安装具体相应路由寻址、子网判断、隧道管理功能的软件，存贮在相应硬件设备的存储空间和内存中。对于所述呼叫控制器200需要安装支持子网管理、指导边界网关维护隧道的软件，存贮在相应硬件设备的存储空间和内存中。对于媒体网关300、301、......305需要安装支持边界网关管理的软件，存贮在相应硬件设备的存储空间和内存中。
本系统所述的跨越私网进行多媒体呼叫的核心方法为：
第一步，将所述呼叫控制器200所能控制的域中的所有媒体网关所在的子网予以编号，并分配一个全域唯一的标识号，如图1中所示的子网1、子网2、子网3、子网4等。
第二步，在配置所述边界网关100、101、102时，必须配置其所在的子网标识号，这些标识号应与所述呼叫控制器200中所编号的对应子网标识号相一致；同时，所述边界网关需要将该呼叫控制器200作为信令的接收者。
第三步，当所述媒体网关300～305向所述呼叫控制器200发送信令消息时，所述媒体网关按照各自协议如H.248、MGCP、SIP等的要求，组装为正常的信令消息，发向对应边界网关100、101、102。
第四步，对应边界网关100、101、102收到此信令消息后，发现这是一个发向所述呼叫控制器200的信令消息时，则主动发起一个从本边界网关到所述呼叫控制器的路径；根据所述子网标识号，如果判断出所述呼叫控制器200与本边界网关在同一子网中，如图1所示的边界网关100、101与所述呼叫控制器200，则可以直接将本信令消息合成一个隧道包的净荷，直接发向该呼叫控制器200；如果判断出不在同一子网中，如所述边界网关102和所述呼叫控制器200，则通过相应方法，自行建立一条从所述边界网关102，经边界网关101到所述呼叫控制器200的隧道，此时，所述边界网关101为该隧道的中间边界隧道，并将待发本信令信息合成一个隧道包的净荷，发向所述呼叫控制器200。这样，所述呼叫控制器200就可以通过隧道收到不同私网中的信令消息了，而且媒体网关发出的原始信令消息内容没有被修改。在此期间，所述边界网关对于所述媒体网关使用何种协议(如H.248、MGCP、SIP等)向呼叫控制器200发送信令消息并不关心。这条隧道将一直予以保持，除非遇到出于维护、安全、断电的原因予以重建时为止。
第五步，所述呼叫控制器200返回的应答，则可以通过已经建立好的隧道发回到原先发出信令信息的媒体网关。
第六步，所述呼叫控制器200如果向呼叫的另一方发出信令请求时，如果隧道没有建立，则所述呼叫控制器200判断被叫侧媒体网关所在的子网是否和本身所在的子网是否属于同一个网络中，即该被叫侧媒体网关所在的子网的边界网关是否和该呼叫控制器位于同一子网内；如果是属于同一个网络，则可以直接发出信令消息；如果不属于同一个网络，如所述呼叫控制器200向如图1中所示的媒体网关302发送命令请求，则该呼叫控制器200向边界网关101发出建立隧道的请求，该边界网关101通过相应方法，建立一条经所述边界网关102到达媒体网关302的隧道，并将本信令合成一个隧道包的净荷，发向所述媒体网关302。这样，主被叫之间的信令消息可以进行互通，并在所述呼叫控制器200的指导下建立呼叫。此时，所述边界网关102处于私网套私网环境下的内外私网之间的边界上，即为第二边界网关。
第七步，对于媒体流的传递，它与信令消息保持一个相对固定的隧道是不同的，必须在呼叫开始时动态建立，在呼叫结束后自动删除，以节约资源。因此，当需要建立媒体隧道时，如建立从媒体网关300到媒体网关302的媒体通道，则所述呼叫控制器200向所述边界网关100发出建立媒体通道的命令请求，并指示该边界网关100被叫处于所述被叫边界网关102内。所述边界网关100根据这些指示，自动发出建立从所述边界网关100到所述被叫边界网关102的隧道请求，通过相应的方法，可以建立一条从该边界网关100、经中间边界网关101、再到被叫边界网关102的隧道，由此传递媒体流。该隧道即媒体通道在呼叫结束后会自动删除，以节约资源。
如图2所示的是本发明的一种跨越私网实现多媒体呼叫的系统和方法的另一较佳实施例，其描述了一个私网内的媒体网关用户与公网内的媒体网关用户进行多媒体呼叫的情形，主被叫所在的媒体网关不在同一子网内，而其中一个与呼叫控制器、边界网关在同一子网，这是最常见的一种组网方式，如私网用户与公网用户的互通。在IP/ATM网上，硬件部分至少由相应的呼叫控制器200、边界网关100、媒体网关300、301、302等组成，当然还可以包括其它硬件设备如DHCP服务器、AAA服务器等。
所述媒体网关使用的协议可以有不同，为叙述方便假定以H.248协议为例，使用其它协议如MGCP、SIP等不影响本组网方式的实现。
当私网内的所述媒体网关300用户，如电话400或个人计算机PC401发起一个呼叫，被叫用户是公网的媒体网关301的用户时，软件部分与本系统相关的处理步骤如下：
第一步(step：1)，所述媒体网关300中用户向所述呼叫控制器200发送一个消息，如SERVICECHANGE注册或NOTIFY上报摘机消息，该媒体网关300组装该消息，并发向对应边界网关100。所述信令消息中如使用本端地址作本端标识时，则使用的是私网中的地址；也可以使用域名等方式来作为本端标识。
第二步(step：2)，所述边界网关100收到此消息后，发现所述呼叫控制器200与所述边界网关100同处一个子网内，因此直接确定信令隧道，然后将接收到的消息直接封装入隧道中，并加上本身的附加标识信息，发给所述呼叫控制器200。
第三步(step：3)，所述呼叫控制器200收到此消息后，从中取出原始的信令消息，进行处理。所述呼叫控制器200处理后，将根据H.248协议，返回应答消息，如SERVICECHANGE或NOTIFY的REPLY，也封装入相应的隧道包中，发向所述边界网关100。
第四步(step：4)，所述边界网关100收到此消息后，内部查找到相应的已建立的隧道，从中取出原始信令内容，发给对应媒体网关300。这样，该媒体网关300可以通过信令隧道与所述呼叫控制器200完成了一次信令交互。
这样，当呼叫发起时，重复上述第一步到第四步，所述媒体网关300可以向所述呼叫控制器200上报摘机消息，接收放拨号音和等待收号消息、上报已收到的号码、创建媒体端口中等。
第五步(step：5)，当所述呼叫控制器200进行号码分析，发现被叫用户在与本身同一个子网的所述媒体网关301中时，需要建立媒体通道，因此向所述边界网关100发出建立媒体通道的命令，其中携带了目的地子网标识。
第六步(step：6)，所述边界网关100收到此消息后，如判断出被叫媒体网关301与本身同处一个子网时，在本身分配一个媒体端口，返回给所述呼叫控制器200。
第七步(step：7)，所述呼叫控制器200将所述边界网关100返回的媒体端口作为H.248协议中的远端端口，发向被叫侧媒体网关301，要求振铃和建立媒体端口。
第八步(step：8)，所述被叫侧媒体网关301收到本消息后，由于是标准信令，因此根据协议进行相应的处理，进行振铃，并向所述呼叫控制器200返回创建了的媒体端口。
第九步(step：9)，所述呼叫控制器200接收到被叫侧的媒体能力，向所述边界网关100发出确认路径的命令。
第十步(step：10)，所述边界网关100收到命令后，由于知道了被叫侧的媒体端口，因此可以建立一条从本身到被叫侧媒体端口的连接并予以保持，作为媒体流的转发。
第十一步(step：11)，所述呼叫控制器200根据H.248协议，向主叫侧媒体网关300发送被叫侧的能力，其中的被叫能力已被替换为所述边界网关100分配的媒体端口。这样，经过该边界网关100的转发，所述媒体网关300与所述媒体网关301的媒体流可以进行相互传递。
第十二步(step：12)，当呼叫结束时，由被叫用户向所述媒体网关301上报挂机消息。
第十三步(step：13)，所述呼叫控制器200收到挂机消息后，根据H.248协议要求返回所述媒体网关301应答消息。
第十四步(step：14)，与此同时，所述呼叫控制器200向所述边界网关100发出释放媒体连接的命令。
第十五步(step：15)，所述边界网关100接受此命令，并释放已建立的媒体连接；但所述媒体网关300的信令隧道仍保持。
第十六步(step：16)，所述边界网关100可以向所述呼叫控制器200返回相应的统计值。
第十七步(step：17)，所述呼叫控制器200根据协议，通过信令隧道，向主叫侧送忙音，并等待挂机，完成呼叫的释放工作。其中的信令交互可重复第一步到第四步的操作。
如图3所示的是本发明的一种跨越私网实现多媒体呼叫的系统和方法的第三较佳实施例，其描述了同一个私网内的两个媒体网关用户多媒体呼叫的情形，这一般应用于同一个私网(如同一个公司)内的呼叫。硬件组成同前两实施例，不再赘述。
所述媒体网关使用的协议可以有不同，为方便说明假定以H.248协议为例，使用其它协议如MGCP、SIP等并不影响本组网方式的实现。 当私网内的媒体网关300用户，如IP电话400或多媒体终端PC401，发起一个呼叫，被叫用户是同一子网的另一媒体网关301的用户如IP电话402或多媒体终端PC403时，软件部分与本系统相关的处理步骤如下：
第一步(step：1)，所述媒体网关300中的用户向所述呼叫控制器200发送一个消息，如SERVICECHANGE注册或NOTIFY上报摘机消息，所述媒体网关300组装该消息，发向对应边界网关100。信令消息中如使用本端地址作本端标识时，则使用的是私网中的地址；也可以使用域名等方式来作为本端标识。
第二步(step：2)，所述边界网关100收到此消息后，发现所述呼叫控制器与所述边界网关100同处一个子网内，因此直接确定信令隧道，然后将接收到的消息直接封装入隧道中，并加上本身的附加标识信息，发给所述呼叫控制器200。
第三步(step：3)，所述呼叫控制器200收到此消息后，从中取出原始的信令消息，进行处理；所述呼叫控制器100处理后，将根据H.248协议，返回应答消息，如SERVICECHANGE或NOTIFY的REPLY，也封装入相应的隧道包中，发向所述边界网关100。
第四步(step：4)，所述边界网关100收到此消息后，内部查找到相应的已建立的隧道，从中取出原始信令内容，发给对应媒体网关300。这样，该媒体网关300可以通过信令隧道与所述呼叫控制器200完成了一次信令交互。
这样，当呼叫发起时，重复上述第一步到第四步，媒体网关(300)可以向呼叫控制器(200)上报摘机消息，接收放拨号音和等待收号消息、上报已收到的号码、创建媒体端口中等。
第五步(step：5)，当所述呼叫控制器200进行号码分析，发现被叫用户在与本身同一个子网的媒体网关301中时，因此不需要建立媒体通道，但是需要建立信令隧道。于是直接将所述边界网关100返回的媒体端口作为H.248协议中的远端端口，要求振铃和建立媒体端口，该消息将封装在隧道包的净荷中，发向该边界网关100。
第六步(step：6)，该边界网关100收到此消息后，查找内部记录，找到被叫侧媒体网关注册时所建立的信令隧道，并从消息中取出原始的信令，发向被叫侧媒体网关301。
第七步(step：7)，所述被叫侧媒体网关301收到本消息后，由于是标准信令，因此根据协议进行相应的处理，进行振铃，并返回创建了的媒体端口。
第八步(step：8)，所述边界网关100收到该被叫侧媒体网关301返回的应答，在内部查找出信令隧道，并封装入隧道包，发给所述呼叫控制器200。
第九步(step：9)，所述呼叫控制器200收到应答后，根据H.248协议，重复第五步到第八步向所述主叫侧媒体网关300发送被叫侧的能力，其中的被叫能力仍为被叫侧网关301分配的媒体端口。这样，所述媒体网关300与媒体网关301的媒体流可以直接进行相互传递，而没有通过所述边界网关100转发。
第十步(step：10)，当呼叫结束时，由被叫用户向所述媒体网关301上报挂机消息，重复第一步到第四步，所述呼叫控制器200可以收到挂机消息。
第十一步(step：11)，所述呼叫控制器200收到挂机后，根据H.248协议要求返回所述媒体网关301应答消息。
第十二步(step：12)，与此同时，所述呼叫控制器200重复第五步到第八步向所述媒体网关301发出释放呼叫的命令。
第十三步(step：13)，所述被叫侧媒体网关301可以向所述呼叫控制器200返回相应的统计值。
第十四步(step：14)，所述呼叫控制器200根据协议，通过信令隧道，向主叫侧送忙音，并等待挂机，完成呼叫的释放工作。其中的信令交互可重复第一步到第八步。
如图4所示的是本发明的一种跨越私网实现多媒体呼叫的系统和方法的第四较佳实施例，其描述了两个私网之间的媒体网关用户进行多媒体呼叫的情形。硬件组成同前述实施例，不再赘述。
所述媒体网关使用的协议可以是多种，为方便叙述假定以H.248协议为例，使用其它协议如MGCP、SIP等不影响本组网方式的实现。
当一个私网内的媒体网关300的用户发起一个呼叫，被叫用户是另一个私网的媒体网关301的用户时，软件部分与本系统相关的处理步骤如下：
第一步(step：1)，所述媒体网关300中用户向所述呼叫控制器200发送一个消息，如SERVICECHANGE注册或NOTIFY上报摘机消息，所述媒体网关300组装该消息，发向对应边界网关100。信令消息中如使用本端地址作本端标识时，则使用的是私网中的地址；也可以使用域名等方式来作为本端标识。
第二步(step：2)，所述边界网关100收到此消息后，发现所述呼叫控制器与该边界网关100同处一个子网内，因此直接确定信令隧道，然后将接收到的消息直接封装入隧道中，并加上本身的附加标识信息，发给所述呼叫控制器200。
第三步(step：3)，所述呼叫控制器200收到此消息后，从中取出原始的信令消息，进行处理。该呼叫控制器100处理后，将根据H.248协议，返回应答消息，如SERVICECHANGE或NOTIFY的REPLY，也封装入相应的隧道包中，发向所述边界网关100。
第四步(step：4)，所述边界网关100收到此消息后，内部查找到相应的已建立的隧道，从中取出原始信令内容，发给所述媒体网关300。这样，该媒体网关300可以通过信令隧道与所述呼叫控制器200完成了一次信令交互。
对于所述媒体网关301，也会向所述呼叫控制器200发送相应的消息，重复第一步到第四步，从而在其对应边界网关101中建立了从所述呼叫控制器200到所述媒体网关302的信令隧道。
第五步(step：5)，当所述呼叫控制器200根据H.248协议向所述媒体网关300发送消息时，如放拨号音，则组装相应的命令内容，如ADD或MODIFY等，封装入相应的隧道包中，发向所述边界网关100。
第六步(step：6)，所述边界网关100收到此消息后，内部查找到相应的已建立的隧道，从中取出原始信令内容，发给媒体网关300。
第七步(step：7)，所述媒体网关300根据命令内容，执行动作，并根据协议返回执行结果。
第八步(step：8)，所述边界网关100得到返回结果后，通过隧道返回给呼叫控制器200。这样，所述媒体网关300与所述呼叫控制器200之间的信令可以通过所述边界网关100进行交互。同样方法，所述媒体网关301与呼叫控制器200之间的信令也可以通过所述边界网关101进行交互。
这样，当呼叫发起时，重复上述第一步到第八步，所述媒体网关300可以向呼叫控制器200上报摘机消息，接收放拨号音和等待收号消息、上报已收到的号码、创建媒体端口中等。
第九步(step：9)，当所述呼叫控制器200进行号码分析，发现被叫用户在与主叫用户不同的另一个子网中时，搜索出其所在的边界网关101。因此，所述呼叫控制器200向边界网关100发出建立媒体连接的命令。
第十步(step：10)，所述边界网关100收到此消息后，判断出被叫媒体网关301与本身不在同一子网，就向被叫侧边界网关101发出建立媒体通道的申请。
第十一步(step：11)，所述边界网关101可以建立该隧道，则向主叫侧边界网关100返回已建立的隧道参数。
第十二步(step：12)，所述边界网关100将本身的媒体端口和从被叫边界网关101得到的媒体端口返回给所述呼叫控制器200。
第十三步(step：13)，所述呼叫控制器200将所述边界网关100返回的参数中被叫边界网关101的媒体端口作为H.248协议中的远端端口，重复第五步到第八步，发向被叫媒体网关301，要求振铃和建立媒体端口。
第十四步(step：14)，被叫侧媒体网关301收到本消息后，由于是标准信令，因此根据协议进行相应的处理，进行振铃，并重复第七步到第八步向所述呼叫控制器200返回创建了的媒体端口。
第十五步(step：15)，所述呼叫控制器200接收到被叫侧的媒体能力，向主叫边界网关100发出确认路径的命令。
第十六步(step：16)，所述边界网关100收到命令后，由于知道了被叫侧的媒体端口，因此可以建立一条从本身到被叫侧媒体端口的隧道并予以保持，作为媒体流的转发。
第十七步(step：17)，所述呼叫控制器200根据H.248协议，向主叫侧媒体网关300发送被叫侧的能力，其中的被叫能力已被替换为主叫侧边界网关100分配的媒体端口。这样，经过该边界网关100和被叫侧边界网关101的转发，主叫侧媒体网关300与被叫侧媒体网关301的媒体流可以进行相互传递。
第十八步(step：18)，当呼叫结束时，由被叫用户向被叫侧媒体网关301上报挂机消息，所述媒体网关301如第一步到第四步向所述呼叫控制器上报此消息。
第十九步(step：19)，所述呼叫控制器200收到挂机消息后，该呼叫控制器200向被叫侧边界网关101发出释放媒体隧道的命令。
第二十步(step：20)，该被叫侧边界网关101接受此命令，并释放已建立的媒体隧道。但媒体网关301的信令隧道仍保持。
第二十一步(step：21)，该被叫侧边界网关101可以向所述呼叫控制器200返回相应的统计值。
第二十二步(step：22)，所述呼叫控制器200同时也根据协议，重复第五步到第八步，向被叫侧媒体网关301发出释放呼叫的命令。
第二十三步(step：23)，所述呼叫控制器200向主叫侧边界网关100也发出释放媒体隧道的命令。操作类同第十九步到第二十一步。
第二十四步(step：24)，所述呼叫控制器200根据协议，通过信令隧道，向主叫侧送忙音，并等待挂机，完成呼叫的释放工作。其中的信令交互可重复第一步到第八步。
综上所述，采用本发明，与现有技术相比，其优势在于：
1.通过所述呼叫控制器的动态管理信令信息隧道和媒体通道，可以节省边界网关的资源；
2.边界网关不修改媒体网关发送和接收的信令消息的内容，不影响信令数据的完整性，从而扩展了边界网关的使用范围。
3.边界网关由于不需要修改信令消息的内容，可以不再关心媒体网采取何种协议，因此大大减少已有方案中针对每种协议的边界网关的数量，降低了边界网关实现的难度，提高了其处理效率和处理能力。
4.边界网关由于不再是媒体网关信令的接收和处理者，不关心信令内容，因此媒体网关的安全性和移动性与没有私网情况下时是一样的，媒体网关可以通过DHCP协议等技术在所述呼叫控制器所管理的全域内移动。
5.所述呼叫控制器不负责寻址，而是通过告诉边界网关目的地位置所在以后由边界网关自行寻址到目的地的路径，因此所述呼叫控制器可以将自己定位于业务的实现和提供上，而非路径的建立和维护，这对于实现一些复杂的有分支的业务(如会议电视、统一消息(UnifiedMessage)等业务)可以降低实现的复杂度。
6.所述呼叫控制器可以直接管理到所有媒体网关，掌握媒体网关的网络拓扑，因此对于原有网络中的同一私网内的呼叫，媒体流完全可以直接在相应的媒体网关中交互，而不必通过边界网关转发，因此提高了服务质量。
7.本系统支持对于私网套私网等复杂的网络情形。
8.本系统支持对于同一个私网中有多个边界网关的情形。
应当指出的是，对本领域普通技术人员来说，根据本发明的技术方案及其较佳实施例的描述，可以做出各种可能的等同改变或替换，而所有这些改变或替换都应属于本发明所附权利要求的保护范围。