CN101031006B - 基于ip的汇接局多业务传输方法 - Google Patents

Abstract

本发明涉及移动通信系统中汇接局基于IP的通信业务传输方法，公开了一种基于IP的汇接局多业务传输方法，使得TMSC的IP承载组网满足并实现语音、传真、数据等多种业务的传输。本发明中，通过利用BICC带外协商首先让MGC之间协商所能切换的编解码方案，然后MGC下发命令使得MGW开始检测与传真数据业务相关的信号、事件等，在呼叫通信过程中，MGW上报所检测到的事件或信号，MGC判断并引发对话两侧的编解码方案的切换，并通过IPBCP协商建立承载面，从而在MSC IP承载上实现传真、数据业务，解决汇接局情况下语音传真的切换。

Description

基于IP的汇接局多业务传输方法

技术领域

本发明涉及移动通信系统中汇接局基于IP的通信业务传输方法，特别涉及移动通信系统中汇接局基于IP的语音、传真、数据等通信业务传输方法。

背景技术

随着通信技术的突飞猛进，人们对于个人通信的期望和要求也越来越高，因此移动运营商需要特别关注用户界面、业务质量等直接影响用户使用移动业务的体验的方面。第三代(3rd Generation，简称“3G”)移动通信系统的高带宽、多业务、高质量等特点极大的吸引着移动消费市场，但3G技术中尚且存在的一些问题如果没有解决将会在一定程度上限制市场扩大，影响移动运营事务的发展。    

在将来的3G网络架构中，移动网不再局限于电路交换的方式，逐渐向分组网际协议(Internet Protocol，简称“IP”)网络演变。另外，随着传统通信网络、互联网以及移动通信网络的发展，各个网络相互融合是必然趋势，下一代网络(Next Generation Nerwork，简称“NGN”)就是以网际协议(InternetProtocol，简称“IP”)分组交换网络为核心网，控制与承载分离，各种接入技术并存，融合现有各种网络的新一代网络，能够满足未来宽带多媒体通信的需求。

NGN是在传统的以电路交换为主的公用电话交换网(Public SwitchedTelephone Network，简称“PSTN”)中逐渐迈出了向以分组交换为主的步伐，它承载了原有PSTN网络的所有业务，同时把大量的数据传输卸载到IP网络中以减轻PSTN网络的重荷，又以IP技术的新特性增加和增强了许多新老业务。NGN是基于时分复用的PSTN语音网络、综合业务数字网络(IntegratedServices Digital Network，简称“ISDN”)、基于IP的分组网络、以及移动通信网等多种网络融合的产物，它使得在新一代网络上语音、视频、数据等综合业务成为了可能。

国际电信联盟电信标准部(International Telecommunication UnionTelecommunication Standardization Sector，简称“ITU-T”)所定义的NGN是一种基于分组的网络，能够提供电信业务、能够利用多种宽带和服务质量(Quality of Service，简称“QoS”)使能的传输技术，其业务相关功能独立于底层的传输相关技术，为用户提供自由接入到不同的业务供应商，支持通用移动性使业务的一致性和普遍性供应给用户成为可能。

在移动域，传统的汇接移动交换中心(Transit Mobile Switching Center，简称“TMSC”)主要是以时分复用(Time Division Multiplex，简称“TDM”)承载为主，TDM固定带宽为64Kbit/s，可以用于传递话音、数据及传真业务。随着NGN发展演变，传统的TDM承载方向逐渐演进到IP承载。其中MSC也因承载与控制分离机制而被分为媒体网关(Media Gateway，简称“MGW”)和媒体网关控制器(Media Gateway Controller，简称“MGC”)。

基于IP承载的业务传输可以使用多种编码方式，如ITU-T的G.729、G.711协议等。其中，G.729数据速率为8Kbit/s，可以传送语音业务(Voiceon IP，简称“VoIP”)，但不能传递数据及传真业务。G.711数据速率为64Kbit/s，理论上可以传递数据及传真业务，但是由于IP传输的不可靠性，如果发生丢包，则不能正常实现数据传递及传真数据。

另外用于传输话音、传真、数据业务的G.711冗余(G.711 Redundant，简称“G.711Red”)编解码方案不仅在IP网络适用，而且因引入了冗余机制而具有较高的可靠性。还有专门用于传真业务的互联网实时传真协议T.38，它比G.711Red还具有更高的效率。因此，一般在传输传真业务的时候，都会采用T.38编解码。

基于IP传输的业务种类越来越多，必须准确的判断业务类型并选择合适的编解码方案来传输。如果无法准确判断业务类型，则选择的编解码方案不能很好满足业务传输的需求，甚至无法正常传输。因此如何根据呼叫信令来判断业务类型，并及时选择合适编解码方案是一个技术难题。

另外，由于汇接局MGC之间采用承载无关的呼叫控制协议(Bearerindependent call control protocol，简称“BICC”)进行带外协商可选的编解码器(Coder & Decoder，简称“Codec”)。而BICC信令不具备选择IP承载的地址的功能，MGW的承载话路地址是通过基于IP的承载控制协议(IPBearer Control Protocol，简称“IPBCP”)进行协商的。汇接局组网的原理如图1所示。在MGC和MGW之间存在Mc接口，供MGC下发命令或MGW上报事件。两个MGW之间的数据承载面是基于IP实现的。在信令层MGC之间通过BICC协商，协商不涉及具体的承载地址信息等，因此在实现承载面时，MGW通过MGC进行IPBCP协商，确定通信的IP地址和用户数据协议(User Data Protocol，简称“UDP”)端口号等信息。

因此，这就涉及到另外一个问题，在多业务传输时，在解决了业务编解码方案的切换之后，如何解决基于IPBCP协商的承载面信息更新。比如在语音和传真阶段，因为无法在呼叫建立阶段进行很好的区分，所以在IPBCP协商时，都使用目前的协商方式，协商出虚拟IuFP Codec或者使用实际语音使用的Codec以及UDP端口号，而实际语音编解码是MGC通过BICC协商的G.729。在切换到传真阶段时，还使用该虚拟Codec，但是语音编解码却在经过BICC协商后被MGC修改为G.711或者G.711Red，承载地址可以发生变化也可以不发生变化。

综上所述，如何简单高效地实现汇接局基于IP多业务传输中的编解码方案的切换以及IP承载面信息的更新是当前急需解决的技术难题。

由于在呼叫建立阶段往往无法区分语音和非语言的其他传真或数据业务，因此一种解决方法是，在呼叫建立前就采用能够同时支持语音、数据、传真的承载方式或编码。如在IP承载时使用G.711/G.711Red编码，则能够同时支持各种业务，保证业务的畅通。但是该方法的问题在于，若IP承载不分业务类型直接采用G.711/G.711Red编码将严重浪费IP带宽，因为TMSC的主要业务还是语音，普通的话音采用G.729编码可以完全满足要求。而G.711/G.711Red所需要的带宽更大，如果一直采用该编码方式而不顾及带宽的浪费，显然不能解决本质问题。

另一种解决方法是，在呼叫建立前通过信令判断出传真、数据业务，然后采用G.711/G.711Red编码传送传真、数据业务，实现各种业务的传送。该方法的弊端在于，呼叫建立前通过信令判断传真、数据业务并不准确，需要特定的环境才能判断，现有的网络条件并不具备。如，固网传真机接入时发起的呼叫在信令上与普通的公共交换电信网(Public SwitchTelecommunication Network，简称“PSTN”)的呼叫信令一样，这样的情况下，通过呼叫前的信令就无法检测，因此从信令上判断并不准确。

还有种解决方法是在呼叫建立时先建立为语音通道，通过检测传真、调制解调器(Modulation&Demodulation，简称“Modem”)音修改通道为G.711透传或者T.38来传送传真或调制解调数据业务。但是通过IPBCP协商的承载地址(IP地址和UDP端口号)在整个通话过程中不再需要修改。该方案中，整个过程承载地址不改变，在语音和传真阶段使用相同的IP地址和UDP端口号，如果处理不好会引起杂音以及承载处理比较麻烦，需要进行报文识别，丢弃非法报文等保护操作。因此对于通信过程中不同性质业务的切换，最好对IP承载分配不同的端口号及地址。

发明内容

有鉴于此，本发明的主要目的在于提供一种基于IP的汇接局多业务传输方法，使得TMSC的IP承载组网满足并实现语音、传真、数据等多种业务的传输。

为实现上述目的，本发明提供了一种基于IP的汇接局多业务传输方法，包含以下步骤：

A在呼叫建立前，通信双方协商并配置用于传输业务的编解码方案；

B在呼叫过程中，媒体网关检测业务相关信号或事件并分别上报给媒体网关控制器；

C在呼叫过程中，所述媒体网关控制器根据上报的所述业务相关信号或事件判断业务类型，通知并控制切换相应的编解码方案，切换所述编解码方案时忽略承载资源相关信息；

D所述编解码方案的切换触发所述媒体网关之间的承载资源重协商和更新。

其中，所述步骤D包含以下子步骤：

所述媒体网关控制器下发的新的编解码方案触发承载资源重协商；

所述媒体网关根据配置的对应业务类型的承载资源信息向对端发起协商；

协商成功后，双方使用新的承载资源进行业务传输，并释放原承载资源。

此外在所述方法中，所述通信双方的媒体网关控制器通过承载无关呼叫控制带外协商用于传输业务的编解码方案。

此外在所述方法中，所述步骤D中所述媒体网关之间通过基于IP的承载控制协议协商或重协商所述承载资源。

此外在所述方法中，所述基于IP的承载控制协议协商过程中，

在呼叫建立阶段，所述媒体网关控制器下发H.248信令支持所述基于IP的承载控制协议协商，配置承载资源和虚拟编解码方案；

在呼叫过程中，当所述编解码方案发生切换时，所述媒体网关控制器下发H.248信令，忽略所述承载资源信息，并通知所切换的编解码方案，同时触发所述基于IP的承载控制协议重协商。

此外在所述方法中，所述承载资源是指IP地址或端口号。

此外在所述方法中，所述步骤A还包含子步骤：

主叫汇接局的所述媒体网关控制器发送初始地址消息，在其中携带本局支持的编解码方案；

被叫汇接局的所述媒体网关控制器发回应用传送消息，在其中携带协商后的编解码方案；

所述被叫端发回振铃及应答消息；

主被叫汇接局的所述媒体网关控制器向对应媒体网关下发检测所述业务相关信号或事件的请求。

此外在所述方法中，当所述步骤B中所述媒体网关检测到所述业务相关信号或事件并上报给对应媒体网关控制器时，所述步骤C包含子步骤：

该媒体网关控制器下发请求指示该媒体网关切换到对应业务类型的编解码方案；

该媒体网关控制器通过所述承载无关呼叫控制指示对端媒体网关控制器对应业务类型的编解码方案；

对端媒体网关控制器下发请求指示对应媒体网关切换到对应业务类型的编解码方案。

此外在所述方法中，所述业务包含：语音业务、传真业务、数据业务。

此外在所述方法中，所述编解码方案包含：G.729编解码方案、G.711冗余编解码方案、T.38编解码方案。应该还有G.711透传编解码。

通过比较可以发现，本发明的技术方案与现有技术的主要区别在于，通过利用BICC带外协商首先让MGC之间协商所能切换的编解码方案，然后MGC下发命令使得MGW开始检测与传真数据业务相关的信号、事件等，在呼叫通信过程中，MGW上报所检测到的事件或信号，MGC判断并引发对话两侧的编解码方案的切换，比如切换到G.711或T.38，并通过IPBCP协商建立承载面，从而在MSC IP承载上实现传真、数据业务，解决汇接局情况下语音传真的切换，其中在切换时MGC忽略实际地址信息，完成编解码方案切换后再通过MGC下发的Modify Codec的消息触发IPBCP重协商端口号及IP地址等，然后更新IP地址和端口号信息，通过Modify消息触发IPBCP的Modify消息进行端口号的修改，开始传送传真业务，并关闭原先的语音流，避免使用相同的端口号或IP地址。

这种技术方案上的区别，带来了较为明显的有益效果，即通过BICC带外协商实现汇接局通信对端的编解码方案的统一切换，通过信号或事件的检测判断传真数据业务的发生，以及通过编解码方案的切换实现传真数据业务的传送，从而在IP组网的TMSC承载传真、数据业务，并且提高网络带宽的利用率，提高网络灵活性，提高通信效率，同时传真数据业务的实现也拓宽了移动通信及未来网络的应用范围，改善了用户体验，促进通信网络发展；

通过采用MGC和MGW间的IPBCP协商，实现通信对端IP地址和UDP端口号等的重协商，在语音、传真、数据业务同时传送的情况下，实现了语音和传真的端口号不同的问题，有效防止语音流和传真流之间在切换时的互相干扰问题；

在TMSC IP承载上实现传真、数据业务，解决汇接局情况下语音传真的切换，同时减少处理的复杂度，防止语音流、传真流互相干扰，提高业务质量。

附图说明

图1是TMSC的IP承载组网结构示意图；

图2是根据本发明的第一实施方式的基于IP的汇接局多业务传输方法流程图；

图3是根据本发明的第三实施方式的编解码方案协商信令交互流程图；

图4是根据本发明的第四实施方式的语音业务切换到传真业务的信令交互流程图。

具体实施方式

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

本发明提出基于IP的多业务传输方案，采用多种编解码方案(G.729、G.711、G.711Red、T.38等)来传输语音(VoIP)、传真(Fax)、数据(Data)、调制解调(Modem)等业务。先用语音通道建立通话之后根据带内呼叫信令判断业务类型，对于传真、数据等业务，需要切换至更大带宽的编解码方案；对于高速传真业务则要采用更高效率的编解码方案。由于对带内呼叫信令的检测，能够准确判断业务类型。最终可以实现用更灵活组网的IP承载来高效传输各种业务。

在MGC之间通过BICC实现带外协商编解码方案，在MGW之间通过IPBCP实现承载资源如IP地址或UDP端口号等的协商分配，BICC在建立呼叫和编解码方案切换时忽略实际承载资源信息，而在编解码方案切换完成后，由IPBCP协商再重新配置。

在基于IP的业务传输中，主叫MGW和被叫MGW之间的传输由IP承载，业务传输大致分为协商、检测、切换、更新几个步骤，即先由主被叫双方协商对应业务类型的备用编解码方案，然后由MGW从带内信令中检测与业务相关的特征信令，检测结果上报给MGC，由MGC来判断业务类型，并最终做出切换配置相应编解码方案的控制操作，切换之后发出IPBCP重新协商承载资源，采用新资源通信的同时释放旧资源。

本发明的第一实施方式，整个多业务传送过程的基本步骤包括带外协商、检测信号、编解码切换、承载重协商等，这个过程的流程图如图2所示。

在步骤201中，在呼叫建立前，通信双方协商并配置用于传输业务的编解码方案。通过BICC信令交互，发起端先发送本局所支持的所有可行的编解码方案，这些方案包括支持各种业务的编解码Codec，比如支持语音业务的G.729、支持语音和传真业务的G.711/G.711Red等，对端收到协商请求后，将本局支持的编解码方案发回，这样双方就协商得到共同支持的编解码方案。

数据业务、传真功能的提供需要MGC和MGW共同完成，由于IP承载的普通语音编码(如G.729)不能支持传真业务，需要在检测到传真事件时切换为支持传真的编码类型，如切换为G.711Red、T.38编码。

在呼叫建立前进行编解码带外协商，呼叫应答成功后，如果协商后支持G.711Red或T.38编码，则MGC在TDM端点向网关下发传真/数据信号、传真事件带内检测请求，MGW检测到后向MGC上报，MGC通过编解码修改流程将IP端点的语音编码修改为可传递传真/数据的编码(G.711Red、T.38)，从而实现传真/数据功能。

在步骤202中，在呼叫过程中，媒体网关检测业务相关信号或事件并分别上报给媒体网关控制器。在BICC带外协商结束后，通信双方就要下发MGW，请求其检测相关业务的各种信号或事件，比如传真业务的话，检测CNG信号或CED和V21信号，MGW在呼叫过程中检测这些信号，并上报给MGC，注意到在整个呼叫过程中都在进行检测，而不是根据呼叫建立阶段的判断，这样能够精确判断业务的切换。

在步骤203中，在呼叫过程中，媒体网关控制器根据上报的业务相关信号或事件判断业务类型，通知并控制切换相应的编解码方案。在这个步骤中，切换编解码方案时忽略承载资源相关信息。MGC收到上报的业务相关信号和事件，就可以判断是否启动对应的业务，比如CNG信号的发生就指示传真(FAX)业务的启动，此时MGC下发请求通知MGW切换对应的Codec。本局MGC还要通过BICC信令通知对端MGC，对端MGC再下发请求通知其MGW切换对应的Codec。

在步骤204中，编解码方案的切换触发承载资源重协商和更新，MGC下发的新的编解码方案触发承载资源重协商。MGC与MGW之间的Mc接口上，MGC通过H.248信令，在Local描述符中指示引发IPBCP重协商。

在步骤205中，MGW根据配置的对应业务类型的承载资源信息向对端发起协商。MGW发送预先配置的承载资源信息，比如对于传真业务，则发送预设的传真业务专用UDP端口号，区别于之前的语音通道，可以避免混乱。对端确认该UDP端口号，协商完成，即分配成功新的承载资源。

在步骤206中，协商成功后，双方使用新的承载资源进行业务传输，并释放原承载资源。即关闭原来的UDP端口的语音通信，并采用新的端口进行传真业务。

上面叙述中，通信双方的信令层采用BICC，MGC通过BICC带外协商用于传输业务的编解码方案，在其他实施方式中也可以采用其他可行的信令，不限于BICC。同样在MGW协商承载面资源分配时，可以采用但也不限于IPBCP实现。另外，承载资源一般是指IP地址和UDP端口号，当然在其他的基于IP的高层协议下，也是其他的端口号或其他类型的承载资源。

本发明的关键在于BICC及IPBCP协商的具体操作以及MGC等网元的处理方法。在本发明的第二实施方式中，IPBCP主要在两个阶段需要协商承载资源：在呼叫建立阶段，MGC下发H.248信令支持IPBCP协商，配置承载资源和虚拟编解码方案；在呼叫过程中，当编解码方案发生切换时，MGC下发H.248信令，忽略承载资源信息，并通知所切换的编解码方案，同时触发所述IPBCP重协商。

具体承载面的实现方法描述如下，呼叫建立阶段，在MC接口上，MGC通过在H.248的Local描述符里面携带相应信息，来支持IPBCP的协商，IPBCP协商出本端和对端UDP端口号，以及虚拟Codec：IuFP。BICC不关心实际物理承载地址，在相关命令中，使用不关注实际承载地址的方式(下文中的用“-”表示)，将后续Codec等信息在Local描述符里面下发给MGW，这样就完成了编解码的切换过程。

表1为支持IPBCP重协商的H.248信令，用于切换传真业务的编解码方案。其中关键部分Local描述符中：“m＝image-udptl t38”表示MGC用“-”表示使用原有地址，并触发UMG的T38传送，即切换Codec并忽略了承载资源；“a＝T38FaxRateManagement：transferredTCF”表示采用端到端训练；“a＝T38FaxUdpEC：T38UDPRedundancy”表示采用冗余包冗余；“a＝T38MaxBitRate：14400”表示FAX最高速率为14400bps。

可见，MGC下发的新的编解码触发IPBCP的重新协商，MGW根据配置的传真业务类型的端口号向对方发起协商。协商成功后，使用新的端口进行传真业务流，以前的语音流关闭。

表1支持IPBCP重协商的H.248信令

在本发明的第三实施方式中给出了BICC带外协商的具体实现步骤。图3示出了呼叫建立前的Codec协商及事件检测请求流程，以局间为BICC信令为例：

首先进行编解码(Code & Decode，简称“Codec”)带外协商，MGc1向MGC2发送初始地址消息(Initial Address Message，简称“IAM”)，其中携带了主叫端即MGC1侧支持的编解码方案，如G.729、G.711Red、T.38等；MGC2收到该消息后判断哪些Codec在本地支持，并将这些Codec发回，这样双方便协商确认了Codec方案，MGC2向MGC1返回应用传输消息(Application Transport Message，简称“APM”)消息，携带协商后确定的编解码方案。

接着，MGC2向MGC1返回被叫振铃消息(Address Complete Message，简称“ACM”)和应答消息(Answer Message，简称“ANM”)。

然后，主被叫MSC在TDM端点发起数据传真信号、传真事件检测请求。MGC1向MGW1发送修改(Modify)消息，发起检测业务相关信令的请求；MGW1返回Modify响应消息。另一侧，MGC2向MGW2发送Modify消息，发起检测业务相关信令的请求；MGW2返回Modify响应消息。这里检测请求通知MGW对带内的业务相关信令，比如Fax业务的V21信令、CM(Fax)等，进行监测，将检测事件通知MGC。

在本发明的第四实施方式中，给出了业务切换过程及承载资源重协商过程的实现方案。当MGW检测到业务相关信号或事件并上报给对应的MGC时，该MGC下发请求指示该MGW切换到对应业务类型的编解码方案；该MGC通过所述BICC指示对端MGC对应业务类型的编解码方案；对端MGC下发请求指示对应MGW切换到对应业务类型的编解码方案。

在MGC向MGW发起带内检测后，MGC根据MGW上报的信号，按上报信号不同分业务进行处理，可以支持普通FAX、高速FAX、MODEM数据业务。如图4所示，以普通传真业务为例，需要检测的信号是CNG或者CED和V21，图中假设协商结果两端网关都支持G.711Red。

语音通道建立后，对普通Fax，MGW1上报CNG或者CED、V21信号，MGC1根据V21信号通知MGW切换到Fax通道(CED不能作为MGC切换的依据)；

MGC1下发modify，修改IP端点为Codec为G.711Red。

通过BICC携带G.711Red编码到对端，要求MGC2修改Codec为G.711Red。

MGC2下发modify，修改被叫IP端点Codec为G.711Red。

完成Codec修改，之后引发的IPBCP的协商即如前所述把UDP端口号改为Fax业务专用端口号，而关闭语音业务的端口。

上述实施方式的描述中，业务类型有语音业务VoIP、传真业务Fax、数据业务Data、调制解调器业务Modem等。而编解码方案有G.729编解码方案、G.711冗余编解码方案、T.38编解码方案等。当然以后技术发展出现新的业务类型及相应的编解码方案，仍然适用于本发明中，能够实现多业务的传输，具有很好的兼容性。

熟悉本领域的技术人员可以理解，上述实施方式中技术细节的描述中以一些常用应用场景为例，给出具体的参数设置等，在实际应用中根据实际情况可以灵活设置，更好地实现发明目的，并不影响本发明的实质和范围。

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

Claims (10)

1.一种基于IP的汇接局多业务传输方法，其特征在于，包含以下步骤：

A在呼叫建立前，通信双方协商并配置用于传输业务的编解码方案；

B在呼叫过程中，媒体网关检测业务相关信号或事件并分别上报给媒体网关控制器；

C在呼叫过程中，所述媒体网关控制器根据上报的所述业务相关信号或事件判断业务类型，通知并控制切换相应的编解码方案，切换所述编解码方案时忽略承载资源相关信息；

D所述编解码方案的切换触发所述媒体网关之间的承载资源重协商和更新。

2.根据权利要求1所述的基于IP的汇接局多业务传输方法，其特征在于，

所述步骤D包含以下子步骤：

所述媒体网关控制器下发的新的编解码方案触发承载资源重协商；

所述媒体网关根据配置的对应业务类型的承载资源信息向对端发起协商；

协商成功后，双方使用新的承载资源进行业务传输，并释放原承载资源。

3.根据权利要求2所述的基于IP的汇接局多业务传输方法，其特征在于，所述通信双方的媒体网关控制器通过承载无关呼叫控制带外协商用于传输业务的编解码方案。

4.根据权利要求3所述的基于IP的汇接局多业务传输方法，其特征在于，所述步骤D中所述媒体网关之间通过基于IP的承载控制协议协商或重协商所述承载资源。

5.根据权利要求4所述的基于IP的汇接局多业务传输方法，其特征在于，所述基于IP的承载控制协议协商过程中，

在呼叫建立阶段，所述媒体网关控制器下发H.248信令支持所述基于IP的承载控制协议协商，配置承载资源和虚拟编解码方案；

在呼叫过程中，当所述编解码方案发生切换时，所述媒体网关控制器下发H.248信令，忽略所述承载资源信息，并通知所切换的编解码方案，同时触发所述基于IP的承载控制协议重协商。

6.根据权利要求5所述的基于IP的汇接局多业务传输方法，其特征在于，所述承载资源是指IP地址或端口号。

7.根据权利要求6所述的基于IP的汇接局多业务传输方法，其特征在于，所述步骤A还包含子步骤：

主叫汇接局的所述媒体网关控制器发送初始地址消息，在其中携带本局支持的编解码方案；

被叫汇接局的所述媒体网关控制器发回应用传送消息，在其中携带协商后的编解码方案；

所述被叫端发回振铃及应答消息；

主被叫汇接局的所述媒体网关控制器向对应媒体网关下发检测所述业务相关信号或事件的请求。

8.根据权利要求7所述的基于IP的汇接局多业务传输方法，其特征在于，当所述步骤B中所述媒体网关检测到所述业务相关信号或事件并上报给对应媒体网关控制器时，所述步骤C包含子步骤：

该媒体网关控制器下发请求指示该媒体网关切换到对应业务类型的编解码方案；

该媒体网关控制器通过所述承载无关呼叫控制指示对端媒体网关控制器对应业务类型的编解码方案；

对端媒体网关控制器下发请求指示对应媒体网关切换到对应业务类型的编解码方案。

9.根据权利要求1-8任意一项所述的基于IP的汇接局多业务传输方法，其特征在于，所述业务包含：语音业务、传真业务、数据业务。

10.根据权利要求9所述的基于IP的汇接局多业务传输方法，其特征在于，所述编解码方案包含：G.729编解码方案、G.711编解码方案、G.711冗余编解码方案、T.38编解码方案。

Images