[发明专利]基于虚拟中继实现承载互通的方法及系统

说明书

技术领域

本发明涉及通信领域，尤其是涉及一种基于虚拟中继实现承载互通的方法及系统。

背景技术

在分离架构下，呼叫控制面和承载控制面的主体分别是MGC(媒体网关控制器)和MGW(媒体网关)。MGW接受MGC的控制，接口协议称作媒体网关控制协议，在Itu-t定义为H.248系列规范。

MGW为呼叫/会话提供具体的承载资源。在H.248协议模型中，Context(上下文)和Termination(端点)是最重要的两个概念。其中，Termination是对MGW上承载资源的抽象，由网关自行分配Id来标识，MGC通过这个Id来引用MGW上的承载资源并对其进行操作。一个Termination可以用来标识一个TDM时隙，可以用来标识AAL2的连接，也可以用来表示一个RTP流，如此等等。而Context则用来将多个Termination关联起来，以体现其对呼叫/会话的参与关系，通常对于普通呼叫/会话，一个Context中只包含两个Termination，而对于特殊业务，如多媒体呼叫、多方通话/会议和监听等，则可以允许有2个以上的Termination。具体请参见H.248协议。

MGW和MGW之间通过承载联通起来。一个物理的MGW可以虚拟成多个逻辑的MGW，这些逻辑的MGW被称为VMGW(Virtual MGW，虚拟媒体网关)，每个VMGW对其MGC来说都作为一个单独的物理MGW来看待。MGC负责呼叫控制，可以管理多个MGW(对于每个这样的MGW，既可能是物理的，也可能是虚拟的)，需要为呼叫在所管理的MGW之间路由并建立承载路径。一个呼叫/会话可能只在一个MGC控制的区域内就可以完成，也可能需要跨越多个MGC，此时MGC需要处理相互之间的路由和承载路径的建立问题。示意如图1。

在图1中，USER 1到USER 2之间的呼叫经过了两个MGC的控制域，分别为MGC 1和MGC 2，MGC为其建立的承载路径经过了MGW 1、MGW 2和MGW 3三个MGW，其中MGW 1本身就是一个物理MGW，而MGW 2和MGW 3则是同一个物理MGW上的两个VMGW。很明显，从物理MGW角度看，上述MGW 2和MGW 3涉及网关内承载互通的问题。

通常情况下，一个承载路径在一个MGW(从MGC角度看到的MGW，即要么是一个未划分VMGW的物理MGW，要么就是一个VMGW)内只涉及一个Context，比如对于普通呼叫这种做法是适用的。对应上图的承载路径，示意如图2。

通常采用一个Context并不表明就不可以采用多个Context。实际上会发现，将原来一个MGW对应单个Context的方式改变成一个MGW对应2个甚至多个Context是有好处的——特别是从MGC的角度。比如可能获得以下的好处:

1>MGC的处理模型可以统一到跨MGW呼叫模型中，即只涉及单个MGW的呼叫也可以当作跨两个MGW的呼叫来处理——本来MGC就要管理跨MGW的呼叫模型，而单Context方式下MGC还要多管理一种MGW内呼叫的模型；

2>MGC呼叫信令功能的Incoming-Half和Outgoing-Half可以获得一个更松耦合的设计——单Context形式下，这个Context是Incoming-Half和Outgoing-Half要共同维护的东西，这就是一种耦合性，而一旦Incoming-Half和Outgoing-Half可以各自拥有一个Context，则这种耦合性就消失了(注:对于Incoming-Half和Outgoing-Half的概念，参考BICC协议可以获得良好的概念)；

3>对于某些特殊业务模型，比如MPTY、监听、移动放音时切换，多Context设计可以带来灵活性和方便性——以MPTY为例，如果多方通话采用单一Context设计，则会议桥上下文的放音和监听需要进行复杂的拓扑管理，实现代价非常大，而采用多Context设计之后，会议桥可以放在一个单独的上下文内，放音和监听在每个Call Leg上下文中进行，则这种复杂的拓扑管理就避免了(请参考3GPP TS23.205规范，对MPTY的单Context设计和多Context设计有良好清晰的阐述)。很显然，一旦这么有好处的东西被付诸实施，则带来了单个MGW内(这个MGW可以是一个未划分VMGW的物理MGW，也可以是一个VMGW)承载互通的问题。

总结上面的描述，获得问题如下: