专利名称：一种切换媒体流编解码格式的方法
技术领域：
本发明涉及通信技术领域，尤其涉及通过MEGACO/MGCP协议实现媒体网关主动切换媒体流编解码格式的方法。
背景技术：
软交换(Soft Switch)及媒体网关(Media Gateway，简称MG)分别是下一代网络(Next Generation Network，简称NGN)中的核心设备。软交换主要完成呼叫控制、媒体网关接入控制、资源分配、协议处理、路由、认证、计费等主要功能，并向用户提供基本话音业务、多媒体业务、移动业务以及多样化的第三方业务；媒体网关则在软交换的控制下实现语音媒体流的建立、传送及释放。
如图1所示是软交换和媒体网关在NGN中的系统组网图。软交换通过MEGACO(Media Gateway Control，媒体网关控制，简称MEGACO)协议或MGCP(Media Gateway Control Protocol，简称MGCP)协议来控制网关完成呼叫过程。当MG1上的用户A和MG2上的用户B呼叫建立进入通话后，在MG1上会建立一个RTP端口，用于把用户A的语音编码为RTP(Real TransportProtocol，实时传输协议，简称RTP)媒体流，经分组交换网发送到MG2；该RTP资源同时会把从来自于MG2上用户B的RTP媒体流解码还原为语音送到用户A。MG2实现通话的方式和MG1相同。这样用户A和用户B即实现了语音的双向互通。
以RTP流实时传输的编解码格式根据压缩的比率高低也分为多种，如一个以G.711格式传送、打包时长为20毫秒的话音速率达到87200bps(bit persecond，即位每秒，简称bps)；而一个以G.723.1格式传送，打包时长为30毫秒的话音速率只有6300bps。很明显，在同样带宽情况下，低速率的编解码格式能传送更多的话路。当然低速率传送的语音在话音质量会有一些的下降。
在NGN网络上，媒体流都是在分组交换网上传送，当网络上一个端点到另一端点的话路媒体流过多时，该网络就会出现拥塞。拥塞后的网络在其上传送的所有媒体流就会出现丢包过多，时延过大，在该网络上承载的正常语音通话就会无法正常进行。理想情况是建设足够大带宽的分组交换网，使其不会产生拥塞，这样一方面成本过高，另一方面巨大带宽的分组网大多时间话务量不高时其上面只传送很少的媒体流，产生巨大的浪费。
如果能够有一种方法，当话路不多时，以高速率的编解码格式传送媒体流，提供给用户清晰、高质量的话音或数据业务；而当网络出现拥塞时，动态调整一些媒体流的编解码格式到低速率的格式，降低网络上的整体流量，避免出现网络拥塞影响所有的业务；同时保证这些被调整的媒体流降低到低速率的格式后，虽然清晰度稍有下降，但仍能保持正在进行的业务继续进行而不中断。
传统的动态语音编解码切换方法，当媒体网关检测到整个网络出现拥塞时一种是媒体网关向软交换上报网络拥塞事件，软交换对该网关上以后新建立的呼叫切换为低速率的编解码格式。这种方法无法对已建立的呼叫进行速率调整，网络的拥塞无法及时消除，而且由于网络已经拥塞，新的呼叫也不能再进行多少，原有的呼叫由于媒体流的丢包及时延太大也不能正常进行；另一种是软交换对已建立的所有呼叫直接向媒体网关下命令向低速率强行切换。这种方法如果有一侧网关不支持低速率的编解码格式，媒体流就会中断；另外有一些软交换不直接参与业务控制，而由媒体网关自适应提供的、只能在高速率编解码格式上承载的业务，媒体流格式一变原有的业务就会中断，如VBD(VoiceBand Data，简称VBD)传真。
发明内容
本发明所要解决的技术问题在于提供一种切换媒体流编解码格式的方法，使得媒体网关在软交换的配合下，能够根据网络拥塞的情况及每一个呼叫的实时传输协议终结点的编解码能力、业务类型，主动、动态、及时地切换语音编解码格式，从而实现了在网络出现拥塞时能及时消除拥塞，有效地提高了NGN网络中的呼叫接通率。
为了实现上述目的，本发明提供了一种切换媒体流编解码格式的方法，用于当呼叫的媒体流在网络上出现拥塞时进行媒体流编解码格式的切换，包括建立媒体网关间呼叫媒体流的步骤和媒体网关检测所述拥塞的步骤，其中，还包括
步骤A，所述媒体网关中的一第一媒体网关请求软交换对所述媒体流编解码格式进行切换，且在所述请求中包含所述第一媒体网关准备要切换到的编解码格式；及步骤B，所述软交换接收所述第一媒体网关的切换请求，并根据所述请求中包含的准备要切换到的编解码格式切换所述媒体流编解码格式。
所述的切换媒体流编解码格式的方法，其中，所述媒体网关检测所述拥塞的步骤进一步包括所述软交换向所述媒体网关发送修改命令，使所述媒体网关检测所述媒体流编解码格式需动态切换的事件的步骤。
所述的切换媒体流编解码格式的方法，其中，所述步骤A进一步包括所述第一媒体网关判断当前呼叫的媒体流能否切换到低速率编解码格式的步骤；如是，则向软交换发起切换请求。
所述的切换媒体流编解码格式的方法，其中，包含在所述请求中的准备要切换到的编解码格式包括当前正在使用的编解码格式及准备要切换到的速率低于当前正在使用的编解码格式的一个或多个编解码格式；且所述准备要切换到的编解码格式具有确定的优先级顺序。
所述的切换媒体流编解码格式的方法，其中，所述请求中进一步包括当前呼叫的终结点名称；所述确定的优先级顺序为低速率较高速率优先，其中，所述当前正在使用的编解码格式排在最低优先级。
所述的切换媒体流编解码格式的方法，其中，所述第一媒体网关根据所述媒体流上所承载的业务类型和实时传输协议端口能力确定所述准备要切换到的编解码格式。
所述的切换媒体流编解码格式的方法，其中，所述步骤B进一步包括步骤B1，所述软交换在接收到所述切换请求后，向一第二媒体网关发送一命令，以根据所述第一媒体网关发出的切换请求中包含的所述准备要切换到的编解码格式修改所述第二媒体网关和所述第一媒体网关对应的呼叫媒体流的编解码格式；步骤B2，所述第二媒体网关收到所述命令后，按照所述指定的编解码格式及优先级顺序，选择一当前呼叫能支持的编解码格式进行格式切换，并向所述软交换发送一应答命令，其中，所述应答命令中包含所述第二媒体网关所选择的编解码格式；
步骤B3，所述软交换收到所述第二媒体网关发送的应答命令后，通知所述第一媒体网关根据所述第二媒体网关选择的编解码格式进行媒体流编解码格式的切换；步骤B4，所述第一媒体网关收到所述软交换在步骤B3中发送的通知后，进行媒体流的编解码格式切换。
所述的切换媒体流编解码格式的方法，其中，在所述步骤B2中，若所述第二媒体网关选择的当前呼叫能支持的编解码格式为当前正在使用的媒体流编解码格式，则所述呼叫的媒体流不发生切换。
所述的切换媒体流编解码格式的方法，其中，进一步包括一订阅MEGACO协议扩展包的步骤，所述扩展包描述了媒体流编解码切换请求的事件并定义了当所述事件在媒体网关上发生时，所述媒体网关向所述软交换上报所述事件时需带有的参数，其中，所述参数以会话描述协议格式的字符串来描述；所述步骤A通过所述第一媒体网关向所述软交换发送一包含所述切换请求事件的通知命令来请求切换。
所述的切换媒体流编解码格式的方法，其中，所述以会话描述协议格式的字符串来描述的切换请求事件参数包括如下属性媒体流的类型、媒体流的IP地址、媒体流的端口号、准备切换到的按确定的优先级顺序排列的媒体流的编解码格式。
所述的切换媒体流编解码格式的方法，其中，在所述步骤B1中，所述软交换向所述第二媒体网关发送一修改命令，所述修改命令的远端媒体描述符中包含所述描述切换请求事件参数的会话描述协议信息；在所述步骤B2中，所述第二媒体网关发送的应答命令中包含一近端媒体描述符，所述近端媒体描述符中的媒体流格式部分只包含所述第二媒体网关选择的媒体编解码格式；在所述步骤B3中，所述软交换通过一修改命令将所述第二媒体网关选择的媒体编解码格式信息发送给所述第一媒体网关上当前呼叫对应的实时传输协议终结点，其中，所述第二媒体网关选择的媒体编解码格式信息包含在所述修改命令的远端媒体描述符中；在所述步骤B4中，所述第一媒体网关收到所述修改命令后，将所述第一媒体网关上当前呼叫对应的实时传输协议终结点的媒体流编解码格式切换为第二媒体网关选择的媒体编解码格式。
所述切换媒体流编解码格式的方法，其中，进一步包括当所述拥塞解除后，将所述媒体流的编解码格式切换回高速率的编解码格式的步骤，具体包括步骤a，所述第一媒体网关请求软交换对所述媒体流编解码格式进行切换，且在所述请求中包含所述第一媒体网关准备要切换回的编解码格式；及步骤b，所述软交换接收所述第一媒体网关的切换请求，并根据所述请求中包含的准备要切换回的编解码格式切换所述媒体流编解码格式。
采用本发明技术方案，能够有效地对媒体网关的编解码格式进行动态切换。当网络出现拥塞时，媒体网关根据自身的能力及业务类型，对当前正在进行呼叫，把媒体流编解码向低速率的格式切换，有效的降低网络流量，让更多的新呼叫可以进行；当网络拥塞消除后，仍可切换向高速度的媒体流编解码格式，恢复高语音质量的呼叫；当有一侧的媒体网关不支持编解码格式的切换时原有的呼叫不受影响，仍可正常继续，即可对已建立的所有呼叫保持正常继续进行而不中断，在网络出现拥塞时或话务量高负荷的情况下有效地提高了NGN网络中的呼叫接通率。
以下结合附图和具体实施例对本发明进行详细描述，但不作为对本发明的限定。
图1示出了现有技术的NGN网络中软交换和媒体网关的组网示意图；图2示出了本发明实现网关主动切换媒体流格式的过程原理示意图；图3示出了本发明用MEGACO协议实现的一种信令交互过程示意图。
具体实施例方式
下面将结合附图，举例说明在MEGACO协议中本发明的一个实施的方式。在说明本发明在MEGACO协议的一个实施方式前，先简单地介绍一下MEGACO协议。
MEGACO协议是IETF的3525协议，其采用了分离网关思想，将原来信令和媒体集中处理的网关分解为两部分媒体网关(Media Gateway，简称MG)和软交换。软交换通过MEGACO协议控制MG的动作软交换向MG发出要执行的命令，MG执行并将结果返回，软交换也要处理MG主动上报所发生的事件请求。MEGACO协议中的逻辑关系是通过连接模型来表示，连接模型中两个最基本的构件就是关联和终结点，关联表示了终结点之间的连接和拓扑关系。MEGACO协议通过包(Package)来描述不同的业务属性，包是可以根据业务的需要进行扩展的。
软交换和MG之间的主要命令包括SERVICECHANGE(注册)，ADD(增加)，MODIFY(修改)，SUBTRACT(删除)，NOTIFY(通知)等等。
SDP协议(Session Description Protocol，简称SDP，会话描述协议)是IETF的2327协议，用来描述媒体流的格式、类型以及网络地址等信息。MEGACO协议中用SDP协议来描述媒体流相关的属性。
图2示出了本发明实现网关主动切换媒体流格式的过程原理示意图。本发明的实现网关主动切换媒体流格式的方法包括如下步骤步骤201，媒体网关间(MG1和MG2)的呼叫媒体流建立后，软交换通过修改命令，让媒体网关检测该媒体流编解码格式需动态切换的事件；步骤202，媒体网关检测到该呼叫的媒体流在网络上出现了拥塞，并判断该呼叫的媒体流可以切换到低速率的编解码格式后，则媒体网关向软交换上报通知消息，请求对媒体流编解码进行切换，在通知消息中包含有a、该呼叫的终结点名称；b、准备切换到低速率的编解码格式；c、目前已建立呼叫的编解码格式；d、编解码格式的优选顺序，按从低速率到高速率的顺序排列，但要把该呼叫当前正在使用的编解码格式排在低优先级；步骤203，软交换收到该请求消息后，向另一个媒体网关发送修改命令来修改和第一个媒体网关对应的该呼叫媒体流的编解码格式，修改命令中媒体流的编解码格式采用第一个媒体网关在步骤202中上报的编解码格式，并按第一个媒体网关上报的请求消息，标明这些编解码格式的优选顺序；步骤204，另一个媒体网关收到该修改命令后，按指定的编解码格式及优选顺序，选择一种该呼叫能支持编解码格式进行媒体流格式切换，并在给软交换的应答命令中包含其所选用的编解码格式；
步骤205，软交换收到该应答后，把该编解码格式类型用修改命令通知第一个媒体网关进行媒体流的编解码格式切换；步骤206，第一个媒体网关收到该命令后，进行媒体流的编解码格式切换(如将媒体流编解码格式C切换到格式D)，这时两个媒体网关间的媒体都切换到低速率的媒体流格式；在步骤204中如果另一个媒体网关不支持低速率的格式，则它仍可按优选顺序选择位于低优先级的当前呼叫正在使用的编解码格式，即编解码格式不发生切换，原有呼叫不受影响正常进行；当媒体网关检测到网络上的拥塞消除后，仍可按步骤201至步骤206中所述的方式把编解码向高速率的方式切换，这时在步骤202中只需把优选顺序按高速率到低速率的顺序排列，但把当前呼叫正在使用的编解码格式排在低优先级即可。
图3示出了在MEGACO协议中的实现媒体流编解码格式动态切换的信令流程图。在说明信令流程前，首先定义一个MEGACO协议的扩展包CodecChgReq，该包中描述了媒体流编解码切换请求的事件CodecChg；同时定义了在MG上该事件发生时，MG向软交换上报的事件中需带有的参数。上报事件的参数以SDP格式的字符串来描述，SDP必须包括以下几个属性媒体流的类型(语音流、视频流)、媒体流的IP地址、媒体流的PORT号、准备切换的媒体流的编解码格式，其中媒体流的编解码格式可以为多项，按MG推荐的优先级顺序从高到低排列。
步骤301，当一个呼叫以媒体流格式C建立后，软交换立刻分别对MG1、MG2上该呼叫所对应的RTP终结点发送MODIFY命令，MODIFY命令中包含一个事件描述符，该事件描述符中的事件是上述定义的CodecChgReq/CodecChg事件。信令的形式可以如下MEGACO/1[123.123.123.4]:2944Transaction=9999{Context=789{Modify=RTP0001{Events=2222{CodecChgReq/CodecChg}}} }
MG1和MG2收到该事件后，即对该呼叫的媒体流进行监测。
步骤302，当MG1检测到该呼叫的媒体流在分组交换网上传送时出现了拥塞，MG1根据媒体流上所承载的业务类型以及该RTP端口能力，判断到可以把该呼叫的媒体流切换到比当前媒体流格式C速率低的低速率格式D、较低速率格式E后，向软交换发送NOTIFY命令。该NOTIFY命令中包含有上述定义的CodecChgReq/CodecChg事件，同时包含有该事件的参数，即上述说明的SDP描述字符串。信令的形式可以如下MEGACO/1[124.124.124.222]:2944 Transaction=10000{Context=789{Notift=RTP0001{ObservedEvents=2222{20050605T22000000:CodecChgReq/CodecChg{MediaInfo=″v=0c=IN IP4 124.124.124.222m=audio 6666 RTP/AVP D E C″}}}}}其中CodecChgReq/CodecChg事件标识该呼叫的RTP0001终结点请求切换编解码的格式；MediaInfo包含了RTP0001请求切换媒体流的SDP描述，其中D E C标识了准备切换的编解码格式，在三种格式都支持的情况下，优先选择格式D，最后一位的格式C是呼叫当前正在采用的格式。带有呼叫当前正在使用的编解码格式，主要是为了该呼叫对应的另一侧网关不支持切换到其它速率的格式时，仍以原有的格式继续正常进行，而不致因为切换失败而使呼叫中断。
步骤303，软交换把MG1通过NOTIFY命令在通知事件参数带来SDP描述信息，通过MODIFY命令发送给MG2，该描述信息包含在MODIFY命令中的远端媒体描述符中。
步骤304，MG2收到该MODIFY命令，MG2根据该RTP终结点的能力，判断能否把媒体流切换到格式D、格式E。如果格式D、格式E都可以切换，根据优选顺序，MG2首选格式D。MG2即把该呼叫的RTP媒体流格式立即切换到格式D，并在给软交换的应答消息包含近端媒体描述符，近端媒体描述符中媒体流格式部分只包含MG2已采用的格式D。信令的形式可以如下<pre listing-type="program-listing"> MEGACO/1[124.124.124.222]:2944 Reply=50003{ Context=5000{ MODIFY=RTP0010{ Media{Stream=1{ Local{ v=0 c=IN IP4 125.125.125.111 m=audio 1111 RTP/AVP D } } }}}}</pre>步骤305，软交换收到MG2的应答后，把MG2在应答包含的媒体信息通过MODIFY命令发送给MG1上该呼叫所对应的RTP终结点，其中MG2在304)中返回的媒体信息包含在该MODIFY命令的远端媒体描述符中。MG1收到该MODIFY后，把该RTP终结点的媒体流格式切换为格式D。
这时MG1和MG2上该呼叫的媒体流以低速率的格式D来传送。
以上是MG2支持向低速率的媒体格式切换，如果MG2不支持媒体流格式切换，则在步骤304中，如果MG2既不支持格式D，也不支持格式E，由于在302)中MG1上报的请求切换的媒体格式信息中，最低优先级选择的格式中已包含呼叫当前正在使用的媒体流格式C，因此MG2仍选择格式C，该呼叫的媒体流不发生切换。MG2在给软交换的MODIFY命令应答中，媒体流格式信息中只包含格式C。在步骤305中MG1收到软交换的MODIFY命令后，媒体流格式继续切换到格式C，即呼叫仍以格式C继续正常进行。
尽管参照实施例对所公开的涉及使用MEGACO协议实现信令代理的方法进行了特别描述，本领域技术人员将能理解，在不偏离本发明的范围和精神的情况下，可以对它进行形式和细节的种种显而易见的修改。例如，由于MEGACO协议和MGCP协议的相似性，本方法的技术方案的实质内容对于使用MGCP协议实现媒体网关主动切换媒体流编解码格式同样适用。因此，以上描述的实施例是说明性的而不是限制性的，本发明还可有其他多种实施例，在不脱离本发明的精神和范围的情况下，熟悉本领域的技术人员当可根据本发明作出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。
权利要求
1.一种切换媒体流编解码格式的方法，用于当呼叫的媒体流在网络上出现拥塞时进行媒体流编解码格式的切换，包括建立媒体网关间呼叫媒体流的步骤和媒体网关检测所述拥塞的步骤，其特征在于，还包括步骤A，所述媒体网关中的第一媒体网关请求软交换对所述媒体流编解码格式进行切换，且在所述请求中包含所述第一媒体网关准备要切换到的编解码格式；及步骤B，所述软交换接收所述第一媒体网关的切换请求，并根据所述请求中包含的准备要切换到的编解码格式切换所述媒体流编解码格式。
2.根据权利要求1所述的切换媒体流编解码格式的方法，其特征在于，所述媒体网关检测所述拥塞的步骤进一步包括所述软交换向所述媒体网关发送修改命令，使所述媒体网关检测所述媒体流编解码格式需动态切换的事件的步骤。
3.根据权利要求1或2所述的切换媒体流编解码格式的方法，其特征在于，所述步骤A进一步包括所述第一媒体网关判断当前呼叫的媒体流能否切换到低速率编解码格式的步骤；如是，则向软交换发起切换请求。
4.根据权利要求3所述的切换媒体流编解码格式的方法，其特征在于，包含在所述请求中的准备要切换到的编解码格式包括当前正在使用的编解码格式及准备要切换到的速率低于当前正在使用的编解码格式的一个或多个编解码格式；且所述准备要切换到的编解码格式具有确定的优先级顺序。
5.根据权利要求4所述的切换媒体流编解码格式的方法，其特征在于，所述请求中进一步包括当前呼叫的终结点名称；所述确定的优先级顺序为低速率较高速率优先，其中，所述当前正在使用的编解码格式排在最低优先级。
6.根据权利要求5所述的切换媒体流编解码格式的方法，其特征在于，所述第一媒体网关根据所述媒体流上所承载的业务类型和实时传输协议端口能力确定所述准备要切换到的编解码格式。
7.根据权利要求1、2、4、5或6所述的切换媒体流编解码格式的方法，其特征在于，所述步骤B进一步包括步骤B1，所述软交换在接收到所述切换请求后，向第二媒体网关发送一命令，以根据所述第一媒体网关发出的切换请求中包含的所述准备要切换到的编解码格式修改所述第二媒体网关和所述第一媒体网关对应的呼叫媒体流的编解码格式；步骤B2，所述第二媒体网关收到所述命令后，按照所述指定的编解码格式及优先级顺序，选择当前呼叫能支持的编解码格式进行格式切换，并向所述软交换发送应答命令，其中，所述应答命令中包含所述第二媒体网关所选择的编解码格式；步骤B3，所述软交换收到所述第二媒体网关发送的应答命令后，通知所述第一媒体网关根据所述第二媒体网关选择的编解码格式进行媒体流编解码格式的切换；步骤B4，所述第一媒体网关收到所述软交换在步骤B3中发送的通知后，进行媒体流的编解码格式切换。
8.根据权利要求7所述的切换媒体流编解码格式的方法，其特征在于，在所述步骤B2中，若所述第二媒体网关选择的当前呼叫能支持的编解码格式为当前正在使用的媒体流编解码格式，则所述呼叫的媒体流编解码格式不发生切换。
9.根据权利要求1、2、4、5、6或8所述的切换媒体流编解码格式的方法，其特征在于，进一步包括订阅MEGACO协议扩展包的步骤，所述扩展包描述了媒体流编解码切换请求的事件并定义了当所述事件在媒体网关上发生时，所述媒体网关向所述软交换上报所述事件时需带有的参数，其中，所述参数以会话描述协议格式的字符串来描述；所述步骤A通过所述第一媒体网关向所述软交换发送包含所述切换请求事件的通知命令来请求切换。
10.根据权利要求9所述的切换媒体流编解码格式的方法，其特征在于，所述以会话描述协议格式的字符串来描述的切换请求事件参数包括如下属性媒体流的类型、媒体流的IP地址、媒体流的端口号、准备切换到的按确定的优先级顺序排列的媒体流的编解码格式。
11.根据权利要求10所述的切换媒体流编解码格式的方法，其特征在于，在所述步骤B1中，所述软交换向所述第二媒体网关发送一修改命令，所述修改命令的远端媒体描述符中包含所述描述切换请求事件参数的会话描述协议信息；在所述步骤B2中，所述第二媒体网关发送的应答命令中包含近端媒体描述符，所述近端媒体描述符中的媒体流格式部分只包含所述第二媒体网关选择的媒体编解码格式；在所述步骤B3中，所述软交换通过修改命令将所述第二媒体网关选择的媒体编解码格式信息发送给所述第一媒体网关上当前呼叫对应的实时传输协议终结点，其中，所述第二媒体网关选择的媒体编解码格式信息包含在所述修改命令的远端媒体描述符中；在所述步骤B4中，所述第一媒体网关收到所述修改命令后，将所述第一媒体网关上当前呼叫对应的实时传输协议终结点的媒体流编解码格式切换为第二媒体网关选择的媒体编解码格式。
12.根据权利要求1、2、4、5、6、8、10或11所述切换媒体流编解码格式的方法，其特征在于，进一步包括当所述拥塞解除后，将所述媒体流的编解码格式切换回高速率的编解码格式的步骤，具体包括步骤a，所述第一媒体网关请求软交换对所述媒体流编解码格式进行切换，且在所述请求中包含所述第一媒体网关准备要切换回的编解码格式；及步骤b，所述软交换接收所述第一媒体网关的切换请求，并根据所述请求中包含的准备要切换回的编解码格式切换所述媒体流编解码格式。
全文摘要
本发明涉及一种切换媒体流编解码格式的方法，用于当呼叫的媒体流在网络上出现拥塞时进行媒体流编解码格式的切换，包括建立媒体网关间呼叫媒体流的步骤和媒体网关检测所述拥塞的步骤，其特征在于，还包括步骤A，所述媒体网关中的一第一媒体网关请求软交换对所述媒体流编解码格式进行切换，且在所述请求中包含所述第一媒体网关准备要切换到的编解码格式；及步骤B，所述软交换接收所述第一媒体网关的切换请求，并根据所述请求中包含的准备要切换到的编解码格式切换所述媒体流编解码格式。采用本发明的技术方案，能够当网络出现拥塞时，媒体网关根据自身的能力及业务类型，对当前正在进行呼叫，把媒体流编解码向低速率的格式切换，有效降低网络流量。
文档编号H04L12/56GK1885837SQ200510012009
公开日2006年12月27日 申请日期2005年6月24日 优先权日2005年6月24日
发明者乔克智, 程宁, 王云贵 申请人:中兴通讯股份有限公司