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

Description

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

本发明涉及一种互联网协议语音技术 （ 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为本发明软交换架构下的编解码转换控制方法的实施例的流程图， 如图 1所示， 包括以下步骤：

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

步骤 12, 媒体网关获取第二终端使用的编解码算法。

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

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

步骤 15, 申请 VTC通道， 利用申请到的 VTC通道对第一终端、 第二 终端的业务进行编解码算法转换， 并对转换后的业务进行传输。 图 1 所示流程中， 第一终端与第二终端是对等的两个实体， 第一终端 可以为主叫， 也可以为被叫； 第二终端可以为被叫， 也可以为主叫。 在本 发明的以下实施例中， 以该第一终端为主叫， 第二终端为被叫为例进行说 明； 当然， 对于第一终端为被叫， 第二终端为主叫的编解码控制方法， 同 样适用于以下所有的实施例， 其控制方法与第一终端为主叫， 第二终端为 被叫的控制方法相同， 下文中不再赘述， 但本发明的方案应当包括第一终 端为被叫， 第二终端为主叫的编解码控制方法实施例。

图 1 所示的实施例中， 媒体网关通过判断第二终端 （即被叫）使用的 编解码算法是否在第一终端 （即主叫） 支持的编解码算法能力集中， 即将 被叫使用的编解码算法与主叫支持的编解码算法能力集进行匹配， 若在， 即匹配成功， 不需要申请 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所示的具体实施例， 图 1中的 步骤 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所示， 具体实现包括：

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

步骤 52 : 主叫软交换收到 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。

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

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

步骤 55: 被叫软交换将 Sb，和自身支持的编解码算法能力集进行匹配， 若有交集， 则被叫软交换在该交集中确定一个被叫 （即上述第二终端）使 用的编解码算法 S2; 若该交集用数组进行表示， 那么该被叫使用的编解法 算法通常就是该数组中的第一个编解码算法； 被叫软交换并向主叫软交换 回复响铃 ( 180Ring )或 PRACK或 200OK等响应消息， 其中 SDP描述符 为 S2,即将被叫使用的编解码算法回复给主叫软交换，若被叫软交换将 Sb， 和自身支持的编解码算法能力集进行匹配， 没有交集时， 就向主叫软交换 回复协商失败。

步骤 56: 主叫软交换发送第一修改（Modify ) 消息给媒体网关中的被 叫 终结 点 Rb , 第 一 Modify 消 息 用 命令： MF(C = C1 , MF=Rb(MO=SR,Remote=S2))表示， 该命令的作用是确定被叫终结点 Rb的 远端支持的编解码算法能力集为 S2。

步骤 57: 媒体网关中的被叫终结点 Rb向主叫软交换回复第一修改响应 ( Modify Reply ), 命令为 Reply(C=Cl,MF=Rb(SDP=S2))， 其中 SDP描述符 为 S2, 并将该 S2写入主叫终结点 Ra的数据区， 以便 Ra以后进行主、 被叫编 解码算法匹配。

步骤 58:主叫软交换发送第二 Modify消息给媒体网关中的主叫终结点 Ra, 第二 Modify 消息用命令： MF(C = C1 , MF=Ra(MO=SR,Remote=Sl)) 表示，该命令的作用是将主叫终结点 Ra的远端支持的编解码算法能力集发 送给主叫终结点 Ra, 其中该 Ra的远端支持的编解码算法能力集为： 该主 叫支持的编解码算法能力集 S1;

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

步骤 510: 主叫软交换向主叫回复 Ring或 PRACK或 200OK等响应消 息，将 Sa回复给主叫，主叫根据该 Sa算法将其业务通过 VTC通道进行主、 被叫业务的编解码转换， 转换为一种通用的格式， 如 TDM (时分复用）格 式， 利用 NIPI通道对转换后的业务传输到被叫时， 再将该通用格式的业务 转换为被叫支持的格式； 从而使主、 被叫进入正常通话流程。 综上， 本发明的上述实施例通过在 H248协议的 SDP描述符中增加一 个 Transcoding标记， 指示媒体网关对主、 被叫的编解码算法进行匹配， 若 被叫使用的编解码算法与主叫支持的编解码算法能力集匹配成功， 则不申 请 VTC通道资源， 不进行主、 被叫业务的编解码转换， 这样就节省了宝贵 的 VTC通道资源， 在扩充 H248协议包的同时， 本发明方法使得主、 被叫 的通讯效率和接通率得到了提高， 而且降低了网络成本。

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

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

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

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

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

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

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

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

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

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

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

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

如图 9所示， 图 7中的第一获取模块 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通道资源， 降低成本， 提高主、 被叫的通 讯效率和接通率。

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

Claims

权利要求书

1. 一种软交换架构下的编解码转换控制方法， 其特征在于， 包括： 媒体网关获取第一终端支持的编解码算法能力集；

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

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

2. 根据权利要求 1所述的编解码转换控制方法， 其特征在于， 所述媒 体网关获取第二终端使用的编解码算法包括：

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

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

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

3. 根据权利要求 2所述的编解码转换控制方法， 其特征在于， 所述第 一终端软交换和第二终端软交换协商的过程包括：

所述第一终端软交换发送呼叫请求消息给第二终端软交换， 在呼叫请 求消息中携带有所述第二编解码算法能力集； 所述第二终端软交换将第二编解码算法能力集与其自身支持的编解码 算法能力集进行匹配， 产生匹配结果， 并在产生的匹配结果中确定一个所 述第二终端使用的编解码算法， 并将所述第二终端使用的编解码算法回复 给所述第一终端软交换。

4. 根据权利要求 3所述的编解码转换控制方法， 其特征在于， 所述媒 体网关从第一终端软交换获取第二终端使用的编解码算法包括：

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

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

5. 根据权利要求 4所述的编解码转换控制方法， 其特征在于， 所述媒 体网关获取第一终端支持的编解码算法能力集包括：

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

6. 根据权利要求 2所述的编解码转换控制方法， 其特征在于， 所述直 接对所述第一终端、 所述第二终端的业务进行透传； 或者对转换后的业务 进行传输的具体为：

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

7. 根据权利要求 6所述的编解码转换控制方法， 其特征在于， 所述通 过媒体 IP接口板 NIPI通道直接对所述第一终端、所述第二终端的业务进行 透传之前， 还包括预先设定时器；

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

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

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

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

8. 根据权利要求 6所述的编解码转换控制方法， 其特征在于， 所述通 过 NIPI通道对转换后的业务进行传输之前， 还包括： 预先设定时器； 利用所述 VTC通道对所述第一终端、 所述第二终端的业务进行编解码 算法转换， 通过 NIPI通道对转换后的业务进行传输包括：

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

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

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

9. 根据权利要求 1 - 8任一项所述的编解码转换控制方法， 其特征在 于，

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

10. 根据权利要求 9所述的编解码转换控制方法， 其特征在于， 所述 将第一终端终结点和第二终端终结点的业务从透传切换到编解码算法转换 包括：

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

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

11. 根据权利要求 10所述的编解码转换控制方法， 其特征在于， 所述 第一终端为主叫， 所述第二终端为被叫。

12. 一种媒体网关， 其特征在于， 包括：

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

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

13. 根据权利要求 12所述的媒体网关， 其特征在于， 所述第二获取模 块包括：

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

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

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

14. 根据权利要求 13所述的媒体网关， 其特征在于， 所述获取子模块 具体为：

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

15. 根据权利要求 12~14任一项所述的媒体网关， 其特征在于， 所述 第一获取模块具体为：

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

16. 根据权利要求 13 - 14任一项所述的媒体网关， 其特征在于， 还包 括：

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

17. 一种软交换架构下的编解码转换控制系统， 其特征在于， 包括： 第一终端软交换， 用于获取与所述第一终端软交换对应的第一终端支 持的编解码算法能力集；

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

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