软交换架构下的编解码转换控制方法、媒体网关及系统

技术领域

本发明涉及一种VOIP(Voice over Internet Protocol，互联网协议语音技术， 简称网络电话)呼叫相关的H248协议，特别是指一种软交换架构下的编解码 转换控制方法、媒体网关及系统。

背景技术

NGN(Next Generation Network，下一代网络)是一种可以提供包括话音、 数据和多媒体等业务的综合开放的网络构架。软交换是该网络的控制功能实 体，为下一代网络(NGN)提供具有实时性要求的业务的呼叫控制和连接控制功 能。目前的NGN网络是在已有网络基础上添加了软交换系统设备，如MGC (Media Gateway Controller，媒体网关控制器)、MG(Media Gateway，媒体 网关)等，从而达到在现有网络基础上提供软交换业务的目的；其中，MGC 也叫做呼叫代理或软交换，如主叫软交换或者被叫软交换，应用在IP语音架 构的系统，来控制很多终端和媒体网关，H248协议就是MGC和MG之间传 输业务所采用的协议。

但目前在NGN网络中，由于主、被叫用户支持的编解码算法可能不一样， 主叫支持的编解码算法，被叫有可能不支持；被叫支持的编解码算法，主叫有 可能不支持。因此，为了实现主、被叫用户的VOIP通话，需要在主、被叫之 间提供编解码转换能力，保证主、被叫的媒体流均使用各自支持的编解码算法， 这种主、被叫的编解码转换功能称为Transcoding功能。

目前的Transcoding功能存在以下不足：

当主、被叫编解码算法一致时也会占用2条VTC(Voice Transcoder Card， 语音码型转换板)通道，该VTC通道的作用是将经过该通道的数据进行语音 码型转换，输出转换后的数据；而此时由于主、被叫编解码算法一样，并不需 要进行编解码转换，浪费了宝贵的VTC资源，增加了设备成本和维护成本， 也降低了通讯效率(因为增加了操作VTC通道的时间)和接通率(因为VTC 操作有可能超时或者失败)。

发明内容

本发明要解决的技术问题是提供一种节省VTC资源的软交换架构下的编 解码转换控制方法、媒体网关及系统。

为解决上述技术问题，本发明的实施例提供一种软交换架构下的编解码转 换控制方法，包括：

媒体网关获取第一终端支持的编解码算法能力集；

所述媒体网关获取第二终端使用的编解码算法；

所述媒体网关判断所述第二终端使用的编解码算法是否在所述第一终端 支持的编解码算法能力集中，若在，则不申请语音码型变换板VTC通道，直 接对所述第一终端、所述第二终端的业务进行透传；若不在，则申请VTC通 道，利用所述VTC通道对所述第一终端、第二终端的业务进行编解码算法转 换，并对转换后的业务进行传输。

其中，所述媒体网关获取第二终端使用的编解码算法的步骤包括：

所述媒体网关接收第一终端软交换发送的上下文，所述上下文是所述第一 终端软交换根据第一终端的呼叫请求消息创建的，所述上下文中添加了携带有 编解码算法转换标记的第一终端终结点和第二终端终结点，所述第一终端终结 点对应一个实时传输协议RTP资源，所述第二终端终结点对应一个RTP资源；

所述媒体网关根据所述编解码算法转换标记，向所述第一终端软交换回复 所述第一终端终结点支持的第一编解码算法能力集和所述第二终端终结点支 持的第二编解码算法能力集；

所述媒体网关根据所述第一终端软交换和所述第二终端软交换协商的协 商结果，从所述第一终端软交换获取所述第二终端使用的编解码算法。

其中，所述第一终端软交换和所述第二终端软交换协商的过程包括：

所述第一终端软交换发送呼叫请求消息给所述第二终端软交换，所述呼叫 请求消息中携带有所述第二编解码算法能力集；

所述第二终端软交换将所述第二编解码算法能力集与其自身支持的编解 码算法能力集进行匹配，产生匹配结果，并在所述匹配结果中确定一个所述第 二终端使用的编解码算法，并将所述第二终端使用的编解码算法回复给所述第 一终端软交换。

其中，所述媒体网关从所述第一终端软交换获取所述第二终端使用的编解 码算法的步骤包括：

所述媒体网关中的所述第二终端终结点接收所述第一终端软交换发送的 修改消息，所述修改消息中携带有所述第二终端使用的编解码算法；

所述第二终端终结点确定所述第二终端终结点的远端支持的编解码算法 能力集为：所述第二终端使用的编解码算法，并发送所述第二终端终结点的远 端支持的编解码算法能力集给所述第一终端软交换，并将所述第二终端终结点 的远端支持的编解码算法能力集写入所述第一终端终结点的数据区中。

其中，所述媒体网关获取第一终端支持的编解码算法能力集的步骤包括：

所述媒体网关中的所述第一终端终结点接收所述第一终端软交换发送修 改消息，所述修改消息中携带有所述第一终端终结点的远端支持的编解码算法 能力集，所述第一终端终结点的远端支持的编解码算法能力集为：所述第一终 端软交换从所述第一终端的呼叫请求消息中获取的所述第一终端支持的编解 码算法能力集。

其中，所述直接对所述第一终端、所述第二终端的业务进行透传；或者对 转换后的业务进行传输的步骤具体为：

通过媒体IP接口板NIPI通道直接对所述第一终端、所述第二终端的业务 进行透传；或者通过NIPI通道对转换后的业务进行传输。

其中，所述通过媒体IP接口板NIPI通道直接对所述第一终端、所述第二 终端的业务进行透传的步骤之前还包括：设定时器；

所述通过媒体IP接口板NIPI通道直接对所述第一终端、所述第二终端的 业务进行透传的步骤包括：

所述第一终端终结点打开NIPI通道，通知所述第二终端终结点进行所述 第一终端、所述第二终端的业务的透传；

若所述第二终端终结点打开NIPI通道成功，则向所述第一终端终结点回 复成功，打开NIPI通道失败或者超时时，给所述第一终端终结点回复失败；

所述第一终端终结点收到所述第二终端终结点成功回复时，向所述第一终 端软交换回复成功，否则，向所述第一终端软交换回复失败。

其中，所述通过NIPI通道对转换后的业务进行传输的步骤之前还包括：

设定时器；

利用所述VTC通道对所述第一终端、所述第二终端的业务进行编解码算 法转换，通过NIPI通道对转换后的业务进行传输的步骤包括：

所述第一终端终结点打开VTC通道和NIPI通道，通知所述第二终端终结 点进行编解码算法转换；

若所述第二终端终结点打开VTC通道和NIPI通道成功，则向所述第一终 端终结点回复成功，打开VTC通道和NIPI通道失败或者超时时，给所述第一 终端终结点回复失败；

所述第一终端终结点收到所述第二终端终结点成功回复时，向所述第一终 端软交换回复成功，否则，向所述第一终端软交换回复失败。

其中，上述所有方法中，所述第一终端、所述第二终端的的业务进入透传 后，若所述第一终端终结点收到所述第一终端软交换的修改消息，判断所述第 二终端使用的编解码算法不在所述第一终端支持的编解码算法能力集中，需要 进行编解码算法转换时，则将所述第一终端终结点和所述第二终端终结点的业 务从透传切换到编解码算法转换。

其中，所述将所述第一终端终结点和所述第二终端终结点的业务从透传切 换到编解码算法转换的步骤包括：

所述第一终端终结点打开VTC通道，修改NIPI通道，通知所述第二终端 终结点进行编解码算法转换；

所述第二终端终结点打开VTC通道和修改NIPI通道成功后，所述第一终 端终结点和所述第二终端终结点利用VTC通道进行编解码算法转换，通过所 述NIPI通道对转换后的业务进行传输。

其中，所述第一终端为主叫，所述第二终端为被叫。

为解决上述技术问题，本发明的实施例还提供一种媒体网关，包括：

第一获取模块，用于获取第一终端支持的编解码算法能力集；

第二获取模块，用于获取第二终端使用的编解码算法；

编解码转换控制模块，用于判断所述第二终端使用的编解码算法是否在所 述第一终端支持的编解码算法能力集中，若在，则不申请语音码型变换板VTC 通道，直接对所述第一终端、所述第二终端的业务进行透传；若不在，则申请 VTC通道，利用所述VTC通道对所述第一终端、所述第二终端的业务进行编 解码算法转换，并对转换后的业务进行传输。

其中，所述第二获取模块包括：

接收模块，用于接收第一终端软交换发送的上下文，所述上下文是所述第 一终端软交换根据所述第一终端的呼叫请求消息创建的，所述上下文中添加了 携带有编解码算法转换标记的第一终端终结点和第二终端终结点，所述第一终 端终结点对应一个实时传输协议RTP资源，所述第二终端终结点对应一个RTP 资源；

发送模块，用于根据所述编解码算法转换标记，向所述第一终端软交换回 复所述第一终端终结点支持的第一编解码算法能力集和所述第二终端终结点 支持的第二编解码算法能力集；

获取子模块，用于根据所述第一终端软交换和所述第二终端软交换协商的 协商结果，从所述第一终端软交换获取所述第二终端使用的编解码算法。

其中，所述获取子模块具体为：

第二终端终结点模块，用于接收所述第一终端软交换发送的修改消息，所 述修改消息中携带有所述第二终端使用的编解码算法；并确定所述第二终端终 结点的远端支持的编解码算法能力集为：所述第二终端使用的编解码算法，并 发送所述第二终端终结点的远端支持的编解码算法能力集给所述第一终端软 交换，并将所述第二终端终结点的远端支持的编解码算法能力集写入所述第一 终端终结点的数据区中。

其中，所述第一获取模块具体为：

第一终端终结点模块，用于接收所述第一终端软交换发送修改消息，所述 修改消息中携带有所述第一终端终结点的远端支持的编解码算法能力集，所述 第一终端终结点的远端支持的编解码算法能力集为：所述第一终端软交换从所 述第一终端的呼叫请求消息中获取的所述第一终端支持的编解码算法能力集。

其中，上述媒体网关还包括：

切换模块，用于在所述第一终端、所述第二终端的业务进入透传后，若所 述第一终端终结点收到所述第一终端软交换的修改消息，判断所述第二终端使 用的编解码算法不在所述第一终端支持的编解码算法能力集中，需要进行编解 码算法转换时，则将所述第一终端终结点和所述第二终端终结点的业务从透传 切换到编解码算法转换。

为解决上述技术问题，本发明的实施例还提供一种软交换架构下的编解码 转换控制系统，包括：

第一终端软交换，用于获取与所述第一终端软交换对应的第一终端支持的 编解码算法能力集；

第二终端软交换，用于获取与所述第二终端软交换对应的第二终端使用的 编解码算法；

媒体网关，用于判断所述第二终端使用的编解码算法是否在所述第一终端 支持的编解码算法能力集中，若在，则不申请语音码型变换板VTC通道，直 接对所述第一终端、所述第二终端的业务进行透传；若不在，则申请VTC通 道，利用所述VTC通道对所述第一终端、所述第二终端的业务进行编解码算 法转换，并对转换后的业务进行传输。

本发明的上述技术方案的有益效果如下：

上述方案中，媒体网关通过判断第二终端(即被叫)使用的编解码算法是 否在第一终端(即主叫)支持的编解码算法能力集中，即将被叫使用的编解码 算法与主叫支持的编解码算法能力集进行匹配，若在，即匹配成功，不需要申 请VTC通道资源，直接进行业务的透传；而现有技术中，无论主、被叫的编 解码算法是否一致，都需要申请VTC通道资源，进行主、被叫的编解码算法 转换；由此可见，本发明的上述方案相比于现有的方法，节省了VTC通道资 源，降低设备成本和维护成本，提高主、被叫的通讯效率和接通率。

附图说明

图1为本发明的实施例软交换架构下的编解码转换控制方法流程示意图；

图2为图1所示的方法的一具体实现流程示意图；

图3为图2所示的方法的一具体实现流程示意图；

图4为图3所示的方法的一具体实现流程示意图；

图5为图1-图4所示方法应用到NGN网络中的具体流程示意图；

图6为本发明的实施例媒体网关的结构示意图；

图7为图6所示媒体网关的一具体实施例结构示意图；

图8为图7所示媒体网关的一具体实施例结构示意图；

图9为图8所示媒体网关的一具体实施例结构示意图；

图10为图6-图9所示媒体网关中具有切换模块的结构示意图；

图11为本发明的软交换架构下的编解码转换控制系统结构示意图。

具体实施方式

为使本发明要解决的技术问题、技术方案和优点更加清楚，下面将结合附 图及具体实施例进行详细描述。

本发明针对现有的NGN网络中主、被叫实现VOIP通话时，主、被叫的 编解码算法转换Transcoding功能，浪费VTC资源的问题，提供一种节省VTC 资源的软交换架构下的编解码转换控制方法、媒体网关及系统。

如图1所示，本发明的实施例软交换架构下的编解码转换控制方法包括：

步骤11，媒体网关获取第一终端支持的编解码算法能力集；

步骤12，媒体网关获取第一终端使用的编解码算法；

步骤13，媒体网关判断该第二终端使用的编解码算法是否在该第一终端 支持的编解码算法能力集中，若在，转向步骤14，若不在，转向步骤15；

步骤14，不申请语音码型变换板VTC通道，直接对第一终端、第二终端 的业务进行透传；

步骤15，申请VTC通道，利用所述VTC通道对第一终端、第二终端的 业务进行编解码算法转换，并对转换后的业务进行传输。

该实施例中，第一终端与第二终端是对等的两个实体，第一终端可以为主 叫，也可以为被叫；该第二终端可以为被叫，也可以为主叫；在本发明的以下 实施例中，以该第一终端为主叫，第二终端为被叫为例进行说明；当然，对于 第一终端为被叫，第二终端为主叫的编解码控制方法，同样适用于以下所有的 实施例，其控制方法与第一终端为主叫，第二终端为被叫的控制方法相同，下 文中不再赘述，但本发明的方案应当包括第一终端为被叫，第二终端为主叫的 编解码控制方法实施例。

该实施例中，媒体网关通过判断第二终端(即被叫)使用的编解码算法是 否在第一终端(即主叫)支持的编解码算法能力集中，即将被叫使用的编解码 算法与主叫支持的编解码算法能力集进行匹配，若在，即匹配成功，不需要申 请VTC通道资源，这样主、被叫就直接进行业务的透传，若不在，即匹配不 成功，再申请VTC通道资源，对主、被叫的业务进行编解码算法转换，对转 换后的业务进行传输；

而现有技术中，无论主、被叫的编解码算法是否一致，都需要申请VTC 资源，进行主、被叫的编解码算法转换；由此可见，本发明的上述实施例相比 于现有的方法，节省了VTC通道资源，降低成本，提高主、被叫的通讯效率 和接通率。

在第一终端为主叫，第二终端为被叫时，下述的第一终端软交换可以为主 叫软交换，第一终端终结点可以为主叫终结点，第二终端软交换可以为被叫软 交换，第二终端终结点可以为被叫终结点；

如图2所示，上述图1所示实施例中，步骤12具体可包括以下步骤：

步骤121，媒体网关接收第一终端软交换发送的上下文，该上下文是第一 终端软交换根据第一终端的呼叫请求消息创建的，该上下文中添加了携带有编 解码算法转换标记的第一终端终结点和第二终端终结点，其中，第一终端终结 点对应一个实时传输协议RTP资源，第二终端终结点对应一个RTP资源；具 体来讲，以第一终端为主叫，第二终端为被叫的具体实现过程为：

主叫软交换根据主叫的呼叫请求消息(该呼叫请求消息中通过SDP (Session Description Protocol，会话描述协议)描述符携带主叫支持的编解码 算法能力集)，向媒体网关发送上下文(Context)，该上下文中添加了携带有 编解码算法转换标记(Transcoding)的主叫终结点和被叫终结点，该主叫终结 点对应一个实时传输协议RTP资源，该被叫终结点对应一个RTP资源；

该步骤中，主叫向主叫软交换发起一呼叫请求消息，主叫软交换收到该呼 叫请求消息后，认为要发起一个主、被叫呼叫流程，该主叫软交换就会创建一 个上下文(Context)，上下文是一些终端间的联系，它描述终端之间的拓扑关 系及媒体混合/交换的参数，该上下文中添加了两个RTP资源，其中一个为主 叫终结点，另一个为被叫终结点，这两个RTP资源分别被添加了编解码算法 转换标记(Transcoding)，媒体网关在接收到该两个RTP资源时，就会根据该 编解码算法转换标记进入编解码转换控制流程；

步骤122，媒体网关根据该编解码算法转换标记，向第一终端软交换回复 该第一终端终结点支持的第一编解码算法能力集和第二终端终结点支持的第 二编解码算法能力集；

步骤123，媒体网关根据第一终端软交换和第二终端软交换协商的协商结 果，从第一终端软交换获取第二终端使用的编解码算法；具体来讲，以第一终 端为主叫，第二终端为被叫的具体实现过程为：

主叫软交换根据该第一编解码算法能力集和该第二编解码算法能力集与 被叫软交换进行协商，产生协商结果；目的是为了获得被叫使用的编解码算法， 以便后续与主叫支持的编解码算法能力集进行匹配，判断主、被叫的编解码算 法是否一致；媒体网关根据该协商结果获取被叫使用的编解码算法。

如图3所示，上述图2所示流程中，步骤123中，第一终端软交换和第二 终端软交换协商的过程可具体包括如下步骤：

步骤1231，第一终端软交换发送呼叫请求消息给第二终端软交换，该呼 叫请求消息中携带有第二终端终结点支持的编解码算法能力集：即第二编解码 算法能力集；

步骤1232，第二终端软交换将该第二编解码算法能力集与其自身支持的 编解码算法能力集进行匹配，产生匹配结果，即该匹配结果是该第二编解码算 法能力集与第二终端支持的编解码算法能力集的交集，该交集可能是一个编解 码算法能力集的集合，也可能是一个编解码算法，但在该协商过程中，第二终 端使用的编解码算法为该交集中的一个编解码算法，因此，第二终端软交换还 需要在该匹配结果中确定一个该第二终端使用的编解码算法，并将该第二终端 使用的编解码算法回复给第一终端软交换。

相应的，上述步骤123中，媒体网关从第一终端软交换获取第二终端使用 的编解码算法可具体包括：

步骤1233，第一终端软交换发送修改消息给媒体网关中的第二终端终结 点，该修改消息中携带有上述步骤1232中获得的第二终端使用的编解码算法；

步骤1234，第二终端终结点根据该修改消息确定该第二终端终结点的远 端支持的编解码算法能力集为：该第二终端使用的编解码算法，发送回复消息 给第一终端软交换，该回复消息中携带有：第二终端终结点的远端支持的编解 码算法能力集，同时，该第二终端终结点并将该第二终端终结点的远端支持的 编解码算法能力集写入第一终端终结点的数据区中，以便第一终端终结点将第 一终端支持的编解码算法能力集与该第二终端使用的编解码算法进行匹配。

如图4所示，结合上述图1、图2、图3所示的具体实施例，上述步骤11 可具体包括：

步骤111，第一终端软交换从上述步骤121中，获得第一终端的呼叫请求 消息，并从该呼叫请求消息中获取第一终端支持的编解码算法能力集；

步骤112，媒体网关中的第一终端终结点接收第一终端软交换发送的修改 消息，该修改消息中携带有第一终端终结点的远端支持的编解码算法能力集， 该第一终端终结点的远端支持的编解码算法能力集为：第一终端支持的编解码 算法能力集；

这样，该第一终端终结点就获得了第一终端支持的编解码算法能力集和第 二终端使用的编解码算法，该第一终端终结点获得了第一终端支持的编解码算 法能力集和第二终端使用的编解码算法之后，对二者进行匹配，判断第二终端 使用的编解码算法是否在该第一终端支持的编解码算法能力集中，若在，就不 申请VTC通道，直接对第一终端、第二终端的业务进行透传(即对主、被叫 之间的业务不经过任何处理的传输)，若不在，申请VTC通道和透传通道，利 用VTC通道对第一终端、第二终端的业务进行编解码转换后，利用透传通道 进行透传，这样相比于现有的无论主、被叫的编解码算法是否一致，都申请 VTC通道，节省了VTC通道资源，提高了主、被叫业务的通讯效率和接通率。

另外，在上述所有实施例中，直接对第一终端、第二终端的业务进行透传； 或者对转换后的业务进行传输的步骤可具体为：

通过NIPI通道(媒体IP接口板)直接对第一终端、第二终端的业务进行 透传；或者通过NIPI通道对转换后的业务进行传输。

第一终端终结点、第二终端终结点在利用NIPI通道直接对第一终端、第 二终端的业务进行透传时，具有以下三种情况：

(1)不需要编解码转换的透传

当第一终端终结点判断第二终端使用的编解码算法跟自己的远端支持的 编解码算法能力集有交集时，不需要申请VTC通道资源，第一终端终结点打 开NIPI通道，设定时器，通知第二终端终结点进行第一终端、第二终端的业 务的透传；

若第二终端终结点打开NIPI通道成功，则向第一终端终结点回复成功， 打开NIPI通道失败或者超时时，向第一终端终结点回复失败；

第一终端终结点收到第二终端终结点成功回复时，向第一终端软交换回复 成功，否则，向第一终端软交换回复失败。

(2)需要编解码算法转换的透传

当第一终端终结点判断第二终端使用的编解码算法跟自己的远端支持的 编解码算法能力集没有交集时，要申请VTC通道资源进行编解码算法转换；

第一终端终结点打开VTC通道和NIPI通道，设定时器，通知第二终端终 结点进行编解码算法转换；

若第二终端终结点打开VTC通道和NIPI通道成功，则向第一终端终结点 回复成功，打开VTC通道和NIPI通道失败或者超时时，给第一终端终结点回 复失败；

第一终端终结点收到第二终端终结点成功回复时，向第一终端软交换回复 成功，否则，向第一终端软交换回复失败。

(3)如果有第一终端软交换向媒体网关发送新的编解码算法能力集，第 一终端和第二终端的编解码算法可能匹配不一致，则需要从透传到编解码算法 转换的切换；

具体来讲，在第一终端、第二终端的业务进入透传后，若第一终端终结点 收到第一终端软交换的修改消息，判断第二终端使用的编解码算法不在第一终 端支持的编解码算法能力集中，需要进行编解码算法转换时，则第一终端终结 点和第二终端终结点将业务从透传切换到编解码算法转换；

该第一终端终结点和第二终端终结点将业务从透传切换到编解码算法转 换的步骤包括：

第一终端终结点打开VTC通道，修改NIPI通道，通知第二终端终结点进 行编解码算法转换；

第二终端终结点打开VTC通道和修改NIPI通道成功后，第一终端终结点 和第二终端终结点利用VTC通道进行编解码算法转换，通过NIPI通道对转换 后的业务进行传输。

下面再结合图5对上述方法在具体的NGN网络的应用进行描述，该方法 主要是在主、被叫软交换与媒体网关之间的控制协议H248协议的SDP(会话 描述协议)描述符中增加一个Transcoding属性，指示媒体网关进行Transcoding 流程：如图5所示，该方法包括：

1.主叫(即上述第一终端)发送Invite消息给主叫软交换(即上述第一 终端软交换)，该Invite消息的作用是：发起呼叫请求，该Invite消息中的SDP 描述符为S1，该S1表示该主叫支持的编解码算法能力集；

2.主叫软交换收到该Invite消息后，向媒体网关发送命令 Add(C＝$，A＝$，Codec＝c，A＝$，Codec＝c，a＝transcoding)，该命令的作用是：创建一 个上下文(Context)，并在该上下文中添加2个RTP(实时传输协议)资源， 带上Transcoding标记(编解码算法转换标记)，指示媒体网关进入Transcoding 流程；这里，2个RTP如可以分别为Ra和Rb，其中，Ra可以代表主叫终结 点(即上述第一终端终结点)对应的RTP资源，Rb可以代表被叫终结点(即 上述第二终端终结点)对应的RTP资源，这里的Ra和Rb是为表示方便而被 命名，并不限定该主叫终结点的RTP资源必须是Ra，也可以是Rb，同样道理， Rb也不限定是该被叫终结点的RTP资源，被叫终结点对应的RTP资源也可以 是Ra；

3.媒体网关在收到主叫软交换的Add命令后，向主叫软交换回复 Reply(C＝C1，A＝Ra(SDP＝Sa’)，A＝Rb(SDP＝Sb’))消息，该消息的作用是：回 复主叫终结点支持的编解码算法能力集和被叫终结点支持的编解码算法能力 集给主叫软交换；在这里，主叫终结点和被叫终结点支持的编解码算法能力集 均是该媒体网关支持的编解码算法能力集，其中，C1为该上下文的编号，A ＝Ra(SDP＝Sa’)，表示主叫终结点Ra支持的编解码算法能力集为Sa’，即上述 实施例中的主叫终结点支持的第一编解码算法能力集；A＝Rb(SDP＝Sb’)，表 示被叫终结点Rb支持的编解码算法能力集为Sb’，即上述实施例中的被叫终 结点支持的第二编解码算法能力集，其中该Sa’和该Sb’为相同的集合，因为 它们均是媒体网关支持的编解码算法能力集；

4.主叫软交换发送Invite消息给被叫软交换(即上述第二终端软交换)， 该Invite消息的作用是：向被叫软交换发起呼叫请求，该Invite消息中的SDP 描述符为Sb’，即将被叫终结点支持的第二编解码算法能力集Sb’告诉被叫软 交换；该步骤中，若上述被叫终结点支持的编解码算法能力集为Sa’表示，那 么该Invite消息中的SDP描述符也可以为Sa’；

5.被叫软交换将Sb’和自己支持的编解码算法能力集进行匹配，若有交 集，则被叫软交换在该交集中确定一个被叫(即上述第二终端)使用的编解码 算法S2；若该交集用数组进行表示，那么该被叫使用的编解法算法通常就是 该数组中的第一个编解码算法；被叫软交换并向主叫软交换回复Ring消息， 其中SDP描述符为S2，即将被叫使用的编解码算法回复给主叫软交换，若被 叫软交换将Sb’和自己支持的编解码算法能力集进行匹配，没有交集时，就向 主叫软交换回复协商失败；

6.主叫软交换发送Modify消息给媒体网关中的被叫终结点Rb，该Modify 消息用命令：MF(C＝C1，MF＝Rb(MO＝SR，Remote＝S2))表示，该命令的作用 是确定被叫终结点Rb的远端支持的编解码算法能力集为S2；

7.媒体网关中的被叫终结点Rb向主叫软交换回复Modify Reply，其中 SDP描述符为S2，并将该S2写入主叫终结点Ra的数据区，以便Ra以后进 行主、被叫编解码算法匹配；

8.主叫软交换发送Modify消息给媒体网关中的主叫终结点Ra，该Modify 消息用命令：MF(C＝C1，MF＝Ra(MO＝SR，Remote＝S1))表示，该命令的作用是 将主叫终结点Ra的远端支持的编解码算法能力集发送给主叫终结点Ra，其中 该Ra的远端支持的编解码算法能力集为：该主叫支持的编解码算法能力集S1；

9.媒体网关中的主叫终结点Ra根据其数据区中的S2和其远端支持的编 解码算法能力集S1进行比较，如果S2在该S1中，则主、被叫匹配成功，说 明Ra和Rb不需要进行编解码算法转换，不需要申请VTC通道资源，直接使 用NIPI通道对主、被叫的业务进行透传即可；如果S2不在该S1中，则主、 被叫匹配不成功，说明Ra和Rb需要进行编解码算法转换，需要申请VTC通 道资源和NIPI通道资源，进行编解码算法转换，该媒体网关中的Ra还将其自 身支持的编解码算法能力集Sa’与该S1进行匹配，若匹配成功，即Sa’与该S1 有交集，则在该交集中确定一个编解码算法Sa，回复给主叫软交换；若匹配 不成功，则向主叫软交换回复失败；

10.主叫软交换向主叫回复Ring消息，将Sa回复给主叫，主叫根据该 Sa算法将其业务通过VTC通道进行主、被叫业务的编解码转换，转换为一种 通用的格式，如TDM(时分复用)格式，利用NIPI通道对转换后的业务传输 到被叫时，再将该通用格式的业务转换为被叫支持的格式；从而使主、被叫进 入正常通话流程。

综上，本发明的上述实施例通过在H248协议的SDP描述符中增加一个 Transcoding标记，指示媒体网关对主、被叫的编解码算法进行匹配，若被叫 使用的编解码算法与主叫支持的编解码算法能力集匹配成功，则不申请VTC 通道资源，不进行主、被叫业务的编解码转换，这样就节省了宝贵的VTC通 道资源，在扩充H248协议包的同时，上述方法使主、被叫的通讯效率和接通 率得到提高，且降低网络成本。

如图6所示，本发明的实施例还提供一种媒体网关60，该媒体网关60应 用在软交换架构下的主、被叫的编解码转换控制方法中，该媒体网关60具体 包括：

第一获取模块61，用于获取第一终端支持的编解码算法能力集；

第二获取模块62，用于获取第二终端使用的编解码算法；

编解码转换控制模块63，用于判断第二终端使用的编解码算法是否在第 一终端支持的编解码算法能力集中，若在，则不申请语音码型变换板VTC通 道，直接对该第一终端、第二终端的业务进行透传；若不在，则申请VTC通 道，利用所述VTC通道对该第一终端、第二终端的业务进行编解码算法转换， 并对转换后的业务进行传输。

该实施例中，第一终端可以为主叫，也可以为被叫；该第二终端可以为被 叫，也可以为主叫；在本发明的媒体网关的以下实施例中，以该第一终端为主 叫，第二终端为被叫为例进行说明；当然，对于第一终端为被叫，第二终端为 主叫同样适用于以下所有的实施例，其控制方法与第一终端为主叫，第二终端 为被叫的控制方法相同，下文中不再赘述，但本发明的方案应当包括第一终端 为被叫，第二终端为主叫的实施例；

如图7所示，上述第二获取模块62可具体包括：

接收模块621，用于接收第一终端软交换发送的上下文，该上下文是第一 终端软交换根据第一终端的呼叫请求消息创建的，该上下文中添加了携带有编 解码算法转换标记的第一终端终结点和第二终端终结点，该第一终端终结点对 应一个实时传输协议RTP资源，第二终端终结点对应一个RTP资源；

发送模块622，用于根据该编解码算法转换标记，向第一终端软交换回复 第一终端终结点支持的第一编解码算法能力集和第二终端终结点支持的第二 编解码算法能力集；

获取子模块623，用于根据该第一终端软交换和第二终端软交换协商的协 商结果，从第一终端软交换获取第二终端使用的编解码算法。

具体来讲，该第一终端软交换和第二终端软交换协商的过程可具体包括如 下步骤：

第一终端软交换发送呼叫请求消息给第二终端软交换，该呼叫请求消息中 携带有第二终端终结点支持的编解码算法能力集：即第二编解码算法能力集；

第二终端软交换将该第二编解码算法能力集与其自身支持的编解码算法 能力集进行匹配，产生匹配结果，即该匹配结果是该第二编解码算法能力集与 第二终端支持的编解码算法能力集的交集，该交集可能是一个编解码算法能力 集的集合，也可能是一个编解码算法，但在该协商过程中，第二终端使用的编 解码算法为该交集中的一个编解码算法，因此，第二终端软交换还需要在该匹 配结果中确定一个该第二终端使用的编解码算法，并将该第二终端使用的编解 码算法回复给第一终端软交换。

如图8所示，上述获取子模块623可具体为：

第二终端终结点模块，用于接收第一终端软交换发送的修改消息，该修改 消息中携带有第二终端使用的编解码算法；并确定该第二终端终结点的远端支 持的编解码算法能力集为：第二终端使用的编解码算法，并发送该第二终端终 结点的远端支持的编解码算法能力集给该第一终端软交换，并将该第二终端终 结点的远端支持的编解码算法能力集写入第一终端终结点的数据区中。

如图9所示，上述第一获取模块61具体为：

第一终端终结点模块，用于接收第一终端软交换发送修改消息，该修改消 息中携带有第一终端终结点的远端支持的编解码算法能力集，该第一终端终结 点的远端支持的编解码算法能力集为：第一终端软交换从第一终端的呼叫请求 消息中获取的第一终端支持的编解码算法能力集。

如图10所示，上述图6-图9所示媒体网关60中，还包括：

切换模块64，用于在第一终端、第二终端的业务进入透传后，若该第一 终端终结点收到第一终端软交换的修改消息，判断该第二终端使用的编解码算 法不在第一终端支持的编解码算法能力集中，需要进行编解码算法转换时，则 将第一终端终结点和第二终端终结点的业务从透传切换到编解码算法转换；

该切换流程具体包括：

第一终端终结点打开VTC通道，修改NIPI通道，通知第二终端终结点进 行编解码算法转换；

第二终端终结点打开VTC通道和修改NIPI通道成功后，第一终端终结点 和第二终端终结点利用VTC通道进行编解码算法转换，通过NIPI通道对转换 后的业务进行传输。

本发明的实施例媒体网关中的编解码转换控制模块63通过判断第二终端 (即被叫)使用的编解码算法是否在第一终端(即主叫)支持的编解码算法能 力集中，即将被叫使用的编解码算法与主叫支持的编解码算法能力集进行匹 配，若在，即匹配成功，不需要申请VTC通道资源，这样主、被叫就直接进 行业务的透传，若不在，即匹配不成功，再申请VTC通道资源，对主、被叫 的业务进行编解码算法转换，对转换后的业务进行传输；

而现有技术中，无论主、被叫的编解码算法是否一致，都需要申请VTC 资源，进行主、被叫的编解码算法转换；由此可见，本发明的上述实施例相比 于现有的方法，节省了VTC通道资源，降低成本，提高主、被叫的通讯效率 和接通率。

如图11所示，本发明的实施例还提供一种软交换架构下的编解码转换控 制系统，包括：

第一终端软交换，用于获取与第一终端软交换对应的第一终端支持的编解 码算法能力集；

第二终端软交换，用于获取与第二终端软交换对应的第二终端使用的编解 码算法；

媒体网关，用于判断该第二终端使用的编解码算法是否在第一终端支持的 编解码算法能力集中，若在，则不申请语音码型变换板VTC通道，直接对第 一终端、第二终端的业务进行透传；若不在，则申请VTC通道，利用VTC通 道对第一终端、第二终端的业务进行编解码算法转换，并对转换后的业务进行 传输。

本发明的该系统实施例中，上述软交换架构下的编解码控制方法中的有关 第一终端软交换(即主叫软交换)和第二终端软交换(即被叫软交换)以及媒 体网关之间的所有交互流程，均适用于该系统实施例中，在此不再赘述。

该系统实施例中的媒体网关通过判断第二终端(即被叫)使用的编解码算 法是否在第一终端(即主叫)支持的编解码算法能力集中，即将被叫使用的编 解码算法与主叫支持的编解码算法能力集进行匹配，若在，即匹配成功，不需 要申请VTC通道资源，这样主、被叫就直接进行业务的透传，若不在，即匹 配不成功，再申请VTC通道资源，对主、被叫的业务进行编解码算法转换， 对转换后的业务进行传输；

而现有技术中，无论主、被叫的编解码算法是否一致，都需要申请VTC 资源，进行主、被叫的编解码算法转换；由此可见，本发明的上述实施例相比 于现有的方法，节省了VTC通道资源，降低成本，提高主、被叫的通讯效率 和接通率。

以上所述是本发明的优选实施方式，应当指出，对于本技术领域的普通技 术人员来说，在不脱离本发明所述原理的前提下，还可以作出若干改进和润饰， 这些改进和润饰也应视为本发明的保护范围。