CN1921478B - 基于网际协议的业务信号传输方法 - Google Patents

Abstract

本发明涉及业务信号传输方法，公开了一种基于网际协议的业务信号传输方法，使得语音、传真、数据等业务能在IP承载上确保成功建立并传输，同时又能尽量节约传输带宽。本发明中，在建立呼叫之前主被叫先协商业务类型及相应编解码方案，然后在正常建立呼叫后，在呼叫过程中MGW一直检测业务相关信令，并上报MGC，由其判断业务类型，并切换至相应编解码方案。对于传真业务或Modem业务，根据特征信令判断其是否为高速传真或Modem业务，并在采用可承载语音、传真、数据的G.711Red编码的基础上，确定高速传真或Modem业务后，切换到更高效的T.38编解码方案。根据带内的V21、CM等特征信令判断业务类型。

Description

基于网际协议的业务信号传输方法

技术领域

本发明涉及业务信号传输方法，特别涉及基于网际协议的业务信号传输方法。

背景技术

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

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

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

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

在移动域，传统的移动交换中心(Mobile Switching Center，简称“MSC”)主要是以时分复用(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还具有更高的效率。因此，一般在传输高速传真或调制解调器(Modulation & Demodulation，简称“Modem”)业务的时候， 都会采用T.38编解码。

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

现有的技术方案一般在呼叫建立前就采用能够同时支持语音、数据、传真的承载方式或编解码方案来建立传输通道。比如用TDM或IP承载下的G.711/G.711Red编解码方式，即可满足各种语音、传真业务的传输。

另外，也有是根据呼叫建立前的信令，来判断业务类型，比如是否是传真、数据业务，然后对于传真、数据业务再采用G.711/G.711Red编解码方案进行传输，如果不是，则采用G.729传输语音业务。

这两种方法实现起来很简单方便，但在网络带宽利用率、业务传输可靠性上面就具有缺点，这是由于业务类型的判断不够准确或者业务类型与其编解码方案的选择不够合理的原因所致。

在实际应用中，上述方案存在以下问题：对于传统的TDM承载方式，其组网成本太高，灵活性不高，不符合将来NGN网络演变的要求。而对于IP承载的方式，如果不分业务类型直接采用通用的G.711/G.711Red编码将会浪费IP传输带宽，因为MSC的主要业务还是语音，普通的话音采用G.729编码可以完全满足要求，没有必要因为传真、数据业务而采用G.711/G.711Red来传输语音业务。

对于第二种方案中只是在呼叫建立前通过信令判断传真、数据业务并不够准确。因呼叫过程中很多业务相关信令才能体现出来，仅仅在呼叫建立之前的信令交互，并不能判断准确的业务类型，比如固网传真机接入时发起的呼叫在信令上与普通的PSTN呼叫信令一样，无法判断。况且下一代网络业务有可能是先建立语音业务之后还会使用传真业务从信令上判断并不准确。这些情况都会导致IP带宽的严重浪费，或由于带宽不足等导致传真、数据业务无法建立。比如出现判断失误，选择了不支持传真的编解码，则会导致后续传真业务的失败，严重影响服务质量保证。

造成这种情况的主要原因在于，仅通过呼叫建立前信令无法准确判断业务类型，无法选择合适的编解码方案进行传输，从而使得带宽浪费或业务传输失败。

发明内容

有鉴于此，本发明的主要目的在于提供一种基于网际协议的业务信号传输方法，使得语音、传真、数据等业务能在IP承载上确保成功建立并传输，同时又能尽量节约传输带宽。

为实现上述目的，本发明提供了一种基于网际协议的业务信号传输方法，其主叫媒体网关和被叫媒体网关之间的传输由网际协议承载，包含以下步骤，

A在建立呼叫之前，主叫端与被叫端协商并配置用于传输业务的编解码方案；

B在呼叫过程中，所述主叫媒体网关或所述被叫媒体网关在带内检测业务相关信令并分别上报给主叫媒体网关控制器或被叫媒体网关控制器；

C在呼叫过程中，所述主叫媒体网关控制器或所述被叫媒体网关控制器根据上报的所述业务相关信令判断业务类型，根据业务类型通知并控制相应媒体网关切换相应的编解码方案；

其中，当根据业务类型切换到T.38编解码方案后，在业务结束后，切换回原来的编解码方案；

在步骤C中，包含以下子步骤：

根据上报的所述业务相关信令判断业务类型的媒体网关控制器，向与其 对应的媒体网关发送修改消息，控制其切换到相应的所述编解码方案，接收其返回的响应消息；

根据上报的所述业务相关信令判断业务类型的媒体网关控制器，还向另一媒体网关控制器发送应用传输消息，通知其切换所述编解码方案；

所述另一媒体网关控制器收到通知后，向与其对应的媒体网关发送所述修改消息，控制其切换到相应的所述编解码方案，接收其返回的响应消息；

所述另一媒体网关控制器再返回所述应用传输消息响应消息。

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

所述主叫媒体网关控制器向所述被叫媒体网关控制器发送初始地址消息，该初始地址消息携带主叫端支持的编解码方案；

所述被叫媒体网关控制器向所述主叫媒体网关控制器返回应用传输消息，该应用传输消息携带协商后确定的编解码方案；

所述被叫媒体网关控制器向所述主叫媒体网关控制器返回地址完成振铃消息和应答消息。

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

所述主叫媒体网关控制器向所述主叫媒体网关发送修改消息，发起检测所述业务相关信令的请求；

所述主叫媒体网关向所述主叫媒体网关控制器返回修改响应消息；

所述被叫媒体网关控制器向所述被叫媒体网关发送修改消息，发起检测所述业务相关信令的请求；

所述被叫媒体网关向所述被叫媒体网关控制器返回修改响应消息。

此外在所述方法中，所述步骤B包含以下子步骤，

当所述主叫媒体网关或所述被叫媒体网关检测到所述业务相关信令，分 别向所述主叫媒体网关控制器或所述被叫媒体网关控制器发送通知消息，通知所述业务相关信令的检测事件；

所述主叫媒体网关控制器或所述被叫媒体网关控制器分别向所述主叫媒体网关或所述被叫媒体网关返回通知响应消息。

此外在所述方法中，所述步骤C还包含以下子步骤，

当所述主叫媒体网关控制器或所述被叫媒体网关控制器中任意一者接收到所述业务相关信令的检测事件时，判断所述业务类型。

此外在所述方法中，所述步骤B还包含以下子步骤，

当所述主叫媒体网关或所述被叫媒体网关检测到所述业务相关信令后，采用无损传输在承载面传递所述业务相关信令，或者采用扩展方式在带外传递所述业务相关信令。

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

此外在所述方法中，所述传真业务进一步包含普通传真业务和高速传真业务；

所述调制解调器业务进一步包含普通调制解调器业务和高速调制解调器业务。

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

此外在所述方法中，对于所述普通传真业务，所述业务相关信令包含CNG、CED、V21，相应的所述编解码方案为所述G.711冗余编解码方案、T.38编解码方案，且：

在所述步骤B中，所述主叫媒体网关检测到所述CNG、CED、V21信令后上报给所述主叫媒体网关控制器；

接着在所述步骤C中，所述主叫媒体网关控制器判断当且仅当上报的信令为所述V21信令时，才控制切换到所述G.711冗余编解码方案或者所述T.38编解码方案。

此外在所述方法中，对于所述高速传真业务，所述业务相关信令包含/ANSam、ANSam、V21、CM，相应的所述编解码方案为所述G.711冗余编解码方案、T.38编解码方案，且：

在所述步骤B中，所述主叫媒体网关检测到所述/ANSam或ANSam信令后上报给所述主叫媒体网关控制器；

接着在所述步骤C中，所述主叫媒体网关控制器判断上报的信令为所述/ANSam或所述ANSam信令时，控制切换到所述G.711冗余编解码方案。

此外在所述方法中，当因检测到所述/ANSam或所述ANSam信令而切换到所述G.711冗余编解码方案后，

在所述步骤B中，所述被叫媒体网关检测到所述V21或CM信令后上报给所述被叫媒体网关控制器；

接着在所述步骤C中，所述被叫媒体网关控制器判断上报的信令为所述V21或所述CM信令时，控制切换到所述T.38编解码方案。

此外在所述方法中，当因判断业务类型为所述传真业务而切换到所述T.38编解码方案后，

在所述步骤B中，所述主叫媒体网关检测到所述EOP、ProcInterrupt、EOF、PI、Disconnect信令后上报给所述主叫媒体网关控制器；

接着在所述步骤C中，所述主叫媒体网关控制器判断上报的信令为所述EOP、ProcInterrupt、EOF、PI、Disconnect信令中的任意一种时，控制切换到所述T.38编解码方案切换前的编解码方案。

此外在所述方法中，所述调制解调业务相关信令包含所述/ANSam、 ANSam、/ANS及CM，相应的所述编解码方案为所述G.711冗余编解码方案或T.38编解码方案，且：

在所述步骤B中，所述主叫媒体网关检测到所述/ANS、/ANSam、ANSam信令后上报给所述主叫媒体网关控制器；

接着在所述步骤C中，所述主叫媒体网关控制器判断上报的信令为所述/ANS、/ANSam、ANSam中的任意一种时，控制切换到所述G.711冗余编解码方案。

此外在所述方法中，当因检测到所述/ANSam或所述ANSam信令而切换到所述G.711冗余编解码方案后，还包含以下步骤：

所述被叫媒体网关进一步检测到所述CM信令后上报给所述被叫媒体网关控制器；

所述被叫媒体网关控制器判断上报的信令为所述CM信令时，控制切换到所述T.38编解码方案。

通过比较可以发现，本发明的技术方案与现有技术的主要区别在于，在建立呼叫之前主被叫先协商业务类型及相应编解码方案，然后在正常建立呼叫后，在呼叫过程中MGW一直检测业务相关信令，并上报MGC，由其判断业务类型，并切换至相应编解码方案。

对于传真业务或Modem业务，根据特征信令判断其是否为高速传真或Modem业务，并在采用可承载语音、传真、数据的G.711Red编码的基础上，确定高速传真或Modem业务后，切换到更高效的T.38编解码方案。

根据带内的V21、CM等特征信令判断业务类型。

对于只能承载传真、Modem业务的T.38编解码，当传真或Modem业务结束后，即切换回原来的编解码方案，以支持语音通话的恢复。

这种技术方案上的区别，带来了较为明显的有益效果，即呼叫过程中对 业务相关信令的带内检测和上报，能够确保业务类型的准确判断，从而选择合适的编解码方案，即不浪费带宽也能保证业务成功传输，进一步提高系统性能和服务质量。

用G.711Red、T.38等编解码方式分别传输普通或高速的传真、数据、Modem业务，能够更好的提高高速业务的服务质量。

T.38编解码方式在传真业务结束时的倒回机制，保证了语音、传真业务在呼叫中不会因切换而中断，保持业务连续性。

附图说明

图1是IP承载的业务传输组网示意图；

图2是根据本发明的第一实施例的主被叫协商编解码方案的信令交互流程图；

图3是根据本发明的第二实施例的用G.711Red传输普通传真业务的信令交互流程图；

图4是根据本发明的第二实施例的用T.38传输普通传真业务的信令交互流程图；

图5是根据本发明的第三实施例的传输高速传真业务的信令交互流程图；

图6是根据本发明的第四实施例的传输MODEM业务的信令交互流程图。

具体实施方式

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

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

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

下面按照具体应用情况的实施例详细描述本发明的技术实现细节。

IP承载包括局间承载为IP，即主叫MGC(MGC1)通过H.28协议控制主叫MGW(MGW1)，而被叫MGC(MGC2)控制被叫MGW(MGW2)；和网关跨IP，即MGC1同时控制MGW1、MGW2。两种情况的组网如图1中所示，两端的MGW为TDM和IP交接的端点，或异步传输模式(Asynchronous Transfer Mode，简称“ATM”)和IP交接的端点。而基于IP承载的数据业务、传真功能的提供需要MGC和MGW共同完成，由于IP承载的普通语音编码，比如G.729、自适应多速率(Adaptive Multi-Rate，简称“AMR”)等，不能支持传真业务，需要在检测到传真事件时切换为支持传真、数据的编码类型，如切换为G.711Red、T.38编码。

本发明在呼叫建立前通过传输无关呼叫控制协议(Transport Independent Call Control，简称“TICC”)，比如承载无关呼叫控制协议(Bearer Independent Call Control，简称“BICC”)、会话初始协议(Session Initiation Protocol，简称“SIP”)，来进行编解码带外协商，呼叫应答成功后，如果协商后支持 G.711Red或T.38等编码，则MGC在IP端点向网关下发传真数据信号、传真事件带内检测请求，MGW检测到后向MGC上报，MGC通过编解码修改流程将IP端点的语音编码修改为可传递传真数据的编码，比如G.711Red、T.38等，从而实现传真数据功能。

如前所述，本发明的基于IP的业务传输方法包含三个步骤：主叫端与被叫端协商并配置用于传输业务的编解码方案；在呼叫过程中，主叫MGW或被叫MGW检测业务相关信令并分别上报给主叫MGC或被叫MGC；接着，主叫MGC或被叫MGC根据上报的业务相关信令判断业务类型，通知并控制切换相应的编解码方案。下面分别给出本发明的第一实施例中的每个步骤具体实现的信令交互流程。

在主被叫协商备用编解码方案的过程中，呼叫建立前的编解码协商及事件检测请求的信令交互流程如图2所示。

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

在检测过程中，当MGW1或MGW2检测到业务相关信令，分别向MGC1或MGC2发送通知(Notify)消息，通知业务相关信令的检测事件；然后，MGC1或MGC2返回Notify响应消息。

然后MGC进行业务类型的判断以及CODEC切换的控制，具体的信令交互过程如下所示：

当MGC1或MGC2中一方接收到业务相关信令的检测事件时，根据特征信令判断业务类型；

然后给与其对应的MGW发送Modify消息，控制其切换到相应的编解码方案，并接收其返回的响应消息，Modify消息中携带欲切换的CODEC方案等参数；

同时还向另一个MGC发送APM消息，通知其切换编解码方案；

另一MGC收到通知后，向与其对应的MGW发送Modify消息，同样地控制其切换到相应的编解码方案，接收其返回的响应消息；

切换完成后，被通知的MGC再返回APM响应消息。

在MGC向MGW发起带内检测后，之后MGC根据MGW上报的信号，按上报信号不同分业务进行处理，可以支持普通Fax、高速Fax、MODEM数据业务。下面按业务类型不同、速率要求不同和采用的编解码方案不同，分别描述几个具体的实施例及其信令交互流程。本发明涉及的业务类型主要有语音(VoIP)、传真(Fax)、数据(Data)及MODEM，其中传真和MODEM又可以分为高速和普通两种，高速业务需要更高的带宽和效率。所选用的CODEC有G.729、G.711Red、T.38，其中G.729带宽较小，只能传输语音业务，而G.711Red带宽足够传输传真、数据等业务，也可以传输语音业务，但是这样较浪费带宽，资源利用率不够高，另外T.38仅能传输传真、数据业 务，不能传输语音业务，但是T.38效率很高，适合传输高速传真业务。

本发明的第二实施例中，针对普通传真业务给出检测、切换信令交互流程。对于普通传真业务，业务相关信令包含CNG、CED、V21，可以用于传输的编解码方案为G.711Red、T.38。MGW1检测到CNG、CED、V21信令后上报给MGC1；接着MGC1判断当且仅当上报的信令为V21信令时，才控制切换到G.711冗余编解码方案或者T.38编解码方案。

图3中是以G.711Red为例的普通Fax透传业务流程，该流程适用于协商结果两端网关都支持G.711Red的情况。

(1)语音通道建立后，对普通Fax，MGW1上报CNG、CED、V21信号，MGC1根据V21信号通知MGW切换到Fax通道，虽然CNG和CED不能作为MGC切换的依据，但仍然上报作为业务相关信令参考；

(2)MGC1下发Modify，修改IP端点的CODEC为G.711Red；

(3)通过BICC携带G.711Red编码到对端，要求MGC2修改CODEC为G.711Red；

(4)MGC2下发Modify，修改被叫IP端点CODEC为G.711Red；

(5)完成CODEC修改，返回响应，建立G.711Red的传真通道。

图4是以T.38编解码为例的普通Fax T.38业务流程，该流程适用于协商结果两端网关都支持T.38的情况。值得注意的是，这里与G.711Red不同的地方在于，在传真结束后，T.38编解码要倒换回到切换之前原来的CODEC，这是因为T.38只支持Fax业务，因此在Fax业务结束后，如果还有后续语音等业务，就需要原来的CODEC进行传输。而G.711Red本身可以传数据或传真也支持话音，因此不用倒换回原来的CODEC。

因此当判断业务类型为传真业务而切换到T.38编解码方案后，MGW1在检测到传真结束信令，上报给MGC1；MGC1判断上报的信令为传真结束 信令中的任意一种时，控制切换到T.38编解码方案切换前的编解码方案。

图4的流程前半部与图3类似，后面半部即是从T.38倒回到原先CODEC的流程。

(1)语音通道建立后，对普通Fax，MGW1上报CNG、CED、V21信号，MGC1根据V21信号通知MGW切换到Fax透传通道；

(2)MGC1下发Modify，修改IP端点为CODEC为T.38；

(3)通过BICC携带T.38到对端，要求MGC2修改CODEC为T.38；

(4)MGC2下发Modify，修改被叫IP端点CODEC为T.38；

(5)完成CODEC修改，即建立Fax业务传输通道；

(6)MGW1上报Fax结束信令。Fax结束信号可能为：EOP(0x0007)——流程结束(Procedures Complete)、ProcInterrupt(0x0008)——流程中断处理(Procedure Interrupt Processing)、EOF(0x0009)——传真会话结束/呼叫终结(end of fax session/call terminating)、PI(0x000A)——优先中止(Priority Interrupt)、切换至语音(Switch to Voice)、Disconnect(0x000B)——中断连接(Premature Disconnect)；

(10)MGC1下发Modify修改CODEC为原来通话时的CODEC；

(11)通过BICC携带原来通话时的CODEC到对端，要求MGC2修改原来的CODEC；

(12)MGC2下发Modify，修改被叫IP端点CODEC为原来的CODEC；

(13)完成CODEC修改，恢复原来的编解码通道。

当然对于传真结束后从T.38回退到原来的编码的情况，某些网关可能不支持，这样倒回流程将失败，呼叫将自动终结。

本发明的第三实施例中，针对高速传真业务给出检测、切换信令交互流 程。对于高速传真业务，分为两个阶段，第一阶段可以由ANSam、/ANSam信令判断，但此时并不能确定是高速传真业务，只有在第二阶段，如果再出现V21或CM(Fax)，则表示真正进入到第二阶段高速传真。对于高速业务，最好用T.38来进行更高效率的传输。

因此/ANSam、ANSam是高速传真起始阶段的信号，但不能根据其确定传真业务类型，也就是说就算发生了ANSam信号，也只能说明可能出现高速传真，也可能还有语音通话，因此不能贸然切换到T.38，只有V21或CM(Fax)出现才表示真正开始传真。

有鉴于此，本发明的第三实施例，首先检测/ANSam、ANSam信令，检测到后转入G.711Red编解码方案，之后再检测V21或CM(Fax)信令，检测到后再转入T.38编解码方案。于是对于高速传真业务，业务相关信令包含/ANSam、ANSam、V21、CM(Fax)，相应的编解码方案为G.711Red、T.38编解码方案。

图5中是整个高速Fax业务传输流程。其中第一阶段是以G.711Red为例的高速Fax透传业务流程，该流程适用于协商结果两端网关都支持G.711Red的情况。MGW1检测到/ANSam、ANSam信令后上报给MGC1；MGC1判断上报的信令为/ANSam或ANSam信令时，控制切换到G.711Red。以下流程适用于协商结果两端网关均支持G.711Red的情况。

(1)语音通道建立后，MGW1上报ANSam、/ANSam信号，通知MGW切换到Fax透传通道；

(2)MGC1下发Modify，修改IP端点为CODEC为G.711Red；

(3)通过BICC携带G.711Red编码到对端，要求MGC2修改CODEC为G.711Red；

(4)MGC2下发Modify，修改被叫IP端点CODEC为G.711Red；

(5)完成CODEC修改，从而建立G.711Red Fax业务通道；

第二阶段的流程中，当因检测到/ANSam或ANSam信令而切换到G.711冗余编解码方案后，MGW2检测到V21、CM(Fax)信令后上报给MGC2；MGC2判断上报的信令为V21或CM(Fax)信令时，控制切换到T.38编解码方案，以更高效率传输高速Fax业务。

(6)MGC2接收到V21信号或者CM信号，其中CM参数值是“FAX”，MGC2再次通知MGW切换到T.38通道，对不支持CM信号检测的网关，不上报CM信号，没有二次切换过程，所以高速传真的透传流程和T.38流程对MGC统一；

(7)MGC2下发Modify，修改IP端点为CODEC为T.38；

(8)通过BICC携带T.38到对端，要求MGC1修改CODEC为T.38；

(9)MGC1下发Modify，修改被叫IP端点CODEC为T.38；

(10)完成CODEC修改，建立T.38高速传真业务通道。

之后的流程与图4的第二部分一样，即为传真结束时T.38编解码倒回原来的编解码的流程。

本发明的第四实施例中，针对MODEM业务给出检测、切换信令交互流程。对于MODEM业务，其业务相关信令包含/ANSam、ANSam及/ANS、CM(Modem)，相应的编解码方案也为G.711Red或T.38编解码方案，MGW1检测/ANS、/ANSam、ANSam信令后上报给MGC1；MGC1判断上报的信令为/ANS、/ANSam、ANSam中的任意一种时，控制切换到G.711冗余编解码方案。

图6给出普通MODEM业务的传输流程。对于普通MODEM业务，只要检测/ANS信令，检测到后转入G.711Red编解码方案：

(1)语音通道建立后，对普通Modem业务，MGW1上报/ANS信号， 软交换(SOFTX1)通知MGW切换到Modem透传通道；

(2)MGC1下发Modify，修改IP端点为CODEC为G.711Red；

(3)通过BICC携带G.711Red到对端，要求MGC2修改CODEC为G.711Red；

(4)MGC2下发Modify，修改被叫IP端点CODEC为G.711Red；

(5)完成CODEC修改，建立基于G.711Red的普通MODEM业务通道。

可见图6的流程与图3关于普通传真业务的流程基本相同，而对于高速MODEM业务，同样的也与图5的流程相似，这里不再赘述。其关键点在于，在图6的(1)中，对高速MODEM业务，MGW1上报/ANSam或ANSam信号，然后SOFTX1通知MGW切换到MODEM透传通道，用G.711Red编码，而在此之后，如果检测到CM(MODEM)信令，则与高速传真业务的T.38处理流程相同，一样转入T.38编解码通道。

对于其它数据业务，低速率的可以采用G.711Red和T.38进行编解码，其流程与图3、图4相同。对于高速率的数据业务，采用T.38编解码，其流程参考图5。

另外，在上述信令检测过程中，如果要求信号无损传递，MGW检测到传真、MODEM等业务相关信令后，可以直接采用无损传输(参考RFC 2833)在承载面传递，或者网关检测传真、MODEM信号后采用扩展方式进行带外传递，这样可以保证信令在检测到后仍然能够无损传递。

熟悉本领域的技术人员可以理解，上面实施例中的业务类型包括VoIP、高低速Fax、Data、高低速MODEM业务，所采用的编解码方案为G.729、G.711Red、T.38等，对于其它应用环境和要求，可以对其它业务检测其相关信令并采用其它编解码方案实现高效传输，实现发明目的，而不影响本发明的实质和范围。

同样，对于Fax、MODEM等业务，其业务相关信令除了V21，ANSam等，也可以采用其它能够判断业务类型的相关信令，或者将来扩展的新特征信令，也能用于检测判断业务类型，从而成功切换合适编解码方案，实现发明目的，而不影响本发明的实质和范围。

另外，针对不同的TICC协议可能有不同的实现方式，如BICC，还可以通过编码重协商流程来实现传真、数据编码的修改，实现发明目的，而不影响本发明的实质和范围。

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

Claims (15)

1.一种基于网际协议的业务信号传输方法，其主叫媒体网关和被叫媒体网关之间的传输由网际协议承载，其特征在于，包含以下步骤，

A在建立呼叫之前，主叫端与被叫端协商并配置用于传输业务的编解码方案；

B在呼叫过程中，所述主叫媒体网关或所述被叫媒体网关在带内检测业务相关信令并分别上报给主叫媒体网关控制器或被叫媒体网关控制器；

C在呼叫过程中，所述主叫媒体网关控制器或所述被叫媒体网关控制器根据上报的所述业务相关信令判断业务类型，根据业务类型通知并控制相应媒体网关切换相应的编解码方案；

其中，当根据业务类型切换到T.38编解码方案后，在业务结束后，切换回原来的编解码方案；

在所述步骤C中，包含以下子步骤：

根据上报的所述业务相关信令判断业务类型的媒体网关控制器，向与其对应的媒体网关发送修改消息，控制其切换到相应的所述编解码方案，接收其返回的响应消息；

根据上报的所述业务相关信令判断业务类型的媒体网关控制器，还向另一媒体网关控制器发送应用传输消息，通知其切换所述编解码方案；

所述另一媒体网关控制器收到通知后，向与其对应的媒体网关发送所述修改消息，控制其切换到相应的所述编解码方案，接收其返回的响应消息；

所述另一媒体网关控制器再返回所述应用传输消息响应消息。

2.根据权利要求1所述的基于网际协议的业务信号传输方法，其特征在于，所述步骤A包含以下子步骤，

所述主叫媒体网关控制器向所述被叫媒体网关控制器发送初始地址消息，该初始地址消息携带主叫端支持的编解码方案；

所述被叫媒体网关控制器向所述主叫媒体网关控制器返回应用传输消息，该应用传输消息携带协商后确定的编解码方案；

所述被叫媒体网关控制器向所述主叫媒体网关控制器返回地址完成振铃消息和应答消息。

3.根据权利要求2所述的基于网际协议的业务信号传输方法，其特征在于，所述步骤A还包含以下子步骤，

所述主叫媒体网关控制器向所述主叫媒体网关发送修改消息，发起检测所述业务相关信令的请求；

所述主叫媒体网关向所述主叫媒体网关控制器返回修改响应消息；

所述被叫媒体网关控制器向所述被叫媒体网关发送修改消息，发起检测所述业务相关信令的请求；

所述被叫媒体网关向所述被叫媒体网关控制器返回修改响应消息。

4.根据权利要求3所述的基于网际协议的业务信号传输方法，其特征在于，所述步骤B包含以下子步骤，

当所述主叫媒体网关或所述被叫媒体网关检测到所述业务相关信令，分别向所述主叫媒体网关控制器或所述被叫媒体网关控制器发送通知消息，通知所述业务相关信令的检测事件；

所述主叫媒体网关控制器或所述被叫媒体网关控制器分别向所述主叫媒体网关或所述被叫媒体网关返回通知响应消息。

5.根据权利要求4所述的基于网际协议的业务信号传输方法，其特征在于，所述步骤C还包含以下子步骤，

当所述主叫媒体网关控制器或所述被叫媒体网关控制器中任意一者接收到所述业务相关信令的检测事件时，判断所述业务类型。

6.根据权利要求5所述的基于网际协议的业务信号传输方法，其特征在于，所述步骤B还包含以下子步骤，

当所述主叫媒体网关或所述被叫媒体网关检测到所述业务相关信令后，采用无损传输在承载面传递所述业务相关信令，或者采用扩展方式在带外传递所述业务相关信令。

7.根据权利要求1所述的基于网际协议的业务信号传输方法，其特征在于，所述业务包含：语音业务、传真业务、数据业务、调制解调器业务。

8.根据权利要求7所述的基于网际协议的业务信号传输方法，其特征在于，所述传真业务进一步包含普通传真业务和高速传真业务；

所述调制解调器业务进一步包含普通调制解调器业务和高速调制解调器业务。

9.根据权利要求8所述的基于网际协议的业务信号传输方法，其特征在于，所述编解码方案包含：G.729编解码方案、G.711冗余编解码方案、T.38编解码方案。

10.根据权利要求9所述的基于网际协议的业务信号传输方法，其特征在于，对于所述普通传真业务，所述业务相关信令包含CNG、CED、V21，相应的所述编解码方案为所述G.711冗余编解码方案、T.38编解码方案，且：

在所述步骤B中，所述主叫媒体网关检测到所述CNG、CED、V21信令后上报给所述主叫媒体网关控制器；

接着在所述步骤C中，所述主叫媒体网关控制器判断当且仅当上报的信令为所述V21信令时，才控制切换到所述G.711冗余编解码方案或者所述T.38编解码方案。

11.根据权利要求10所述的基于网际协议的业务信号传输方法，其特征在于，对于所述高速传真业务，所述业务相关信令包含/ANSam、ANSam、V21、CM，相应的所述编解码方案为所述G.711冗余编解码方案、T.38编解码方案，且：

在所述步骤B中，所述主叫媒体网关检测到所述/ANSam或ANSam信令后上报给所述主叫媒体网关控制器；

接着在所述步骤C中，所述主叫媒体网关控制器判断上报的信令为所述/ANSam或所述ANSam信令时，控制切换到所述G.711冗余编解码方案。

12.根据权利要求11所述的基于网际协议的业务信号传输方法，其特征在于，当因检测到所述/ANSam或所述ANSam信令而切换到所述G.711冗余编解码方案后，

在所述步骤B中，所述被叫媒体网关检测到所述V21或CM信令后上报给所述被叫媒体网关控制器；

接着在所述步骤C中，所述被叫媒体网关控制器判断上报的信令为所述V21或所述CM信令时，控制切换到所述T.38编解码方案。

13.根据权利要求10或12中所述的基于网际协议的业务信号传输方法，其特征在于，当因判断业务类型为所述传真业务而切换到所述T.38编解码方案后，

在所述步骤B中，所述主叫媒体网关检测到所述EOP、ProcInterrupt、EOF、PI、Disconnect信令后上报给所述主叫媒体网关控制器；

接着在所述步骤C中，所述主叫媒体网关控制器判断上报的信令为所述EOP、ProcInterrupt、EOF、PI、Disconnect信令中的任意一种时，控制切换到所述T.38编解码方案切换前的编解码方案。

14.根据权利要求9所述的基于网际协议的业务信号传输方法，其特征在于，所述调制解调业务相关信令包含所述/ANSam、ANSam、/ANS及CM，相应的所述编解码方案为所述G.711冗余编解码方案或T.38编解码方案，且：

在所述步骤B中，所述主叫媒体网关检测到所述/ANS、/ANSam、ANSam信令后上报给所述主叫媒体网关控制器；

接着在所述步骤C中，所述主叫媒体网关控制器判断上报的信令为所述/ANS、/ANSam、ANSam中的任意一种时，控制切换到所述G.711冗余编解码方案。

15.根据权利要求14所述的基于网际协议的业务信号传输方法，其特征在于，当因检测到所述/ANSam或所述ANSam信令而切换到所述G.711冗余编解码方案后，还包含以下步骤：

所述被叫媒体网关进一步检测到所述CM信令后上报给所述被叫媒体网关控制器；

所述被叫媒体网关控制器判断上报的信令为所述CM信令时，控制切换到所述T.38编解码方案。

Images