CN100539723C - Ip多媒体子系统及其编解码转换控制方法 - Google Patents

Abstract

本发明提供一种编解码转换控制方法，包括：预判被叫用户支持的编解码类型；根据预判的被叫用户支持的编解码类型和主叫用户支持的编解码类型判断主被叫用户间的会话是否需进行编解码转换；若主叫用户支持的编解码类型与被叫用户支持的编解码类型存在交集，判断不需进行编解码转换，继续会话处理；若主叫用户支持的编解码类型与被叫用户支持的编解码类型不存在交集，判断需进行编解码转换，控制协商主被叫用户分别支持的编解码类型，将协商确定的主被叫用户分别支持的编解码类型通知媒体网关。本发明还公开了IP多媒体子系统、互通边界控制功能实体、服务呼叫会话控制功能实体。可以降低维护成本，减少呼叫接续时间，灵活方便的实现编解码转换。

Description

IP多媒体子系统及其编解码转换控制方法

技术领域

本发明涉及IP多媒体子系统(IMS)技术领域，更具体的说，本发明涉及一种IMS系统及其编解码转换控制方法。

背景技术

目前，鉴于互联网和电信网融合的趋势，国际标准化组织第三代合作伙伴计划(3GPP)在分组承载网的基础上引入了支持多媒体业务的全IP业务网络架构的IP多媒体子系统(IMS)，IMS的目标是按照个性化的用户数据，屏蔽用户接入方式，控制业务能力的开放程度，提供全新的多媒体的通信体验。

IMS中最主要的功能实体包括呼叫控制实体(CSCF)，CSCF有三种类型：服务CSCF(S-CSCF)、代理CSCF(P-CSCF)、查询CSCF(I-CSCF)。其中，S-CSCF是最主要的业务控制实体，不同的S-CSCF由于所连接的应用服务器(AS)不同，可完成不同的业务功能。

另外，在IMS网络中，由于主被叫用户终端所支持的编解码类型可能不一样，主叫支持的媒体编解码类型，被叫有可能不支持；而被叫支持的编解码类型，主叫则有可能不支持。因此为了实现主被叫间的会话，需要网络具有一种能够在主被叫间进行媒体编解码转换的能力，保证主被叫双方通讯的媒体流均为主被叫支持的编解码类型。

目前，在3GPP23218.740协议中提供了一种实现主被叫间编解码转换的方案，其主要是在S-CSCF采用基于初始过滤准则(IFC)的数据中配置编解码AS进行编解码转换控制，通过媒体资源功能控制器(MRFC)来实现主被叫之间的编解码转换，但由于无法动态获知被叫用户支持的编解码类型，因此所有的用户都需要在IFC中配置相关的编解码AS进行编解码转换，灵活性不够，维护成本较高，接续时间较长。

发明内容

本发明实施例解决的技术问题是提供一种IMS系统、IBCF、S-CSCF以及编解码转换控制方法，以降低维护成本，减少接续时间，灵活方便的实现编解码转换。

为解决上述问题，本发明具体实施例的一种服务呼叫会话控制功能实体，包括有：

预判处理单元，用于预判被叫用户支持的编解码类型；

编解码转换判断处理单元，用于根据所述预判处理单元预判的被叫用户支持的编解码类型和主叫用户支持的编解码类型判断主被叫用户间的会话是否需进行编解码转换，在主叫用户支持的编解码类型与所述预判的被叫用户支持的编解码类型不存在交集时，判断需进行编解码转换，指示编解码控制器进行编解码转换控制。

相应地，本发明具体实施例的一种互通边界控制功能实体，包括有：

媒体转换协商控制单元，用于控制协商主被叫用户分别支持的编解码类型；

媒体转换指示单元，将协商确定的主被叫用户分别支持的编解码类型通知媒体网关；

预判处理单元，用于预判被叫用户支持的编解码类型；

编解码转换判断处理单元，根据所述预判处理单元预判的被叫用户支持的编解码类型和主叫用户支持的编解码类型判断主被叫用户间的会话是否需进行编解码转换，在主叫用户支持的编解码类型与所述预判的被叫用户支持的编解码类型不存在交集时，判断需进行编解码转换，指示媒体转换协商控制单元控制协商主被叫用户分别支持的编解码类型。

相应地，本发明具体实施例的一种IP多媒体子系统，包括服务呼叫会话控制功能实体和互通边界控制功能实体，所述互通边界控制功能实体包括有：

媒体转换协商控制单元，用于控制协商主被叫用户分别支持的编解码类型；

媒体转换指示单元，将协商确定的主被叫用户分别支持的编解码类型通知媒体网关；

所述服务呼叫会话控制功能实体包括有：

预判处理单元，用于预判被叫用户支持的编解码类型；

编解码转换判断处理单元，根据所述预判处理单元预判的被叫用户支持的编解码类型和主叫用户支持的编解码类型判断主被叫用户间的会话是否需进行编解码转换，在主叫用户支持的编解码类型与被叫用户支持的编解码类型不存在交集时，判断需进行编解码转换，指示互通边界控制功能实体进行编解码转换控制。

相应地，本发明具体实施例的一种IP多媒体子系统，包括有服务呼叫会话控制功能实体，所述IP多媒体子系统包括独立功能单元的编解码控制应用服务器，用于控制媒体网关进行编解码转换；

所述服务呼叫会话控制功能实体包括有：

预判处理单元，用于预判被叫用户支持的编解码类型；

编解码转换判断处理单元，根据所述预判处理单元预判的被叫用户支持的编解码类型和主叫用户支持的编解码类型判断主被叫用户间的会话是否需进行编解码转换，在主叫用户支持的编解码类型与被叫用户支持的编解码类型不存在交集时，判断需进行编解码转换，指示编解码控制应用服务器进行编解码转换控制。

相应地，本发明具体实施例的一种IP多媒体子系统，包括有互通边界控制功能实体，所述互通边界控制功能实体包括有：

预判处理单元，用于预判被叫用户支持的编解码类型；

媒体转换协商控制单元，用于控制协商主被叫用户分别支持的编解码类型；

媒体转换指示单元，将协商确定的主被叫用户分别支持的编解码类型通知媒体网关；

编解码转换判断处理单元，根据所述预判处理单元预判的被叫用户支持的编解码类型和主叫用户支持的编解码类型判断主被叫用户间的会话是否需进行编解码转换，在主叫用户支持的编解码类型与被叫用户支持的编解码类型不存在交集时，判断需进行编解码转换，指示所述媒体转换协商控制单元控制协商主被叫用户分别支持的编解码类型。

相应地，本发明具体实施例的一种服务呼叫会话控制功能实体，包括有：

预判处理单元，用于预判被叫用户支持的编解码类型；

媒体转换协商控制单元，用于控制协商主被叫用户分别支持的编解码类型；

媒体转换指示单元，将协商确定的主被叫用户分别支持的编解码类型通知媒体网关；

编解码转换判断处理单元，根据所述预判处理单元预判的被叫用户支持的编解码类型和主叫用户支持的编解码类型判断主被叫用户间的会话是否需进行编解码转换，在主叫用户支持的编解码类型与被叫用户支持的编解码类型不存在交集时，判断需进行编解码转换，指示媒体转换协商控制单元控制协商主被叫用户分别支持的编解码类型。

相应地，本发明具体实施例的一种IP多媒体子系统，包括有服务呼叫会话控制功能实体，所述服务呼叫会话控制功能实体包括有：

预判处理单元，用于预判被叫用户支持的编解码类型；

媒体转换协商控制单元，用于控制协商主被叫用户分别支持的编解码类型；

媒体转换指示单元，将协商确定的主被叫用户分别支持的编解码类型通知媒体网关；

编解码转换判断处理单元，根据所述预判处理单元预判的被叫用户支持的编解码类型和主叫用户支持的编解码类型判断主被叫用户间的会话是否需进行编解码转换，在主叫用户支持的编解码类型与被叫用户支持的编解码类型不存在交集时，判断需进行编解码转换，指示媒体转换协商控制单元控制协商主被叫用户分别支持的编解码类型。

相应地，本发明具体实施例的一种编解码转换控制方法，该方法主要包括：

预判被叫用户支持的编解码类型；

根据预判的被叫用户支持的编解码类型和主叫用户支持的编解码类型判断主被叫用户间的会话是否需进行编解码转换；

若主叫用户支持的编解码类型与被叫用户支持的编解码类型存在交集，则判断不需进行编解码转换，继续会话处理；

若主叫用户支持的编解码类型与被叫用户支持的编解码类型不存在交集，则判断需进行编解码转换，控制协商主被叫用户分别支持的编解码类型，将协商确定的主被叫用户分别支持的编解码类型通知媒体网关。

相应地，本发明具体实施例的一种编解码类型协商控制方法，该方法主要包括：

服务呼叫会话控制功能实体收到被叫用户设备返回的被叫用户不支持主叫编解码类型消息后，判断是否已经协商过主被叫用户分别支持的编解码类型，并在判断结果为否时，根据所述返回的消息中携带的被叫用户支持的编解码类型信息，控制重新协商主被叫用户分别支持的编解码类型并将重新协商确定的主被叫用户分别支持的编解码类型通知媒体网关。

相应地，本发明具体实施例的一种编解码类型协商控制方法，该方法主要包括：

服务呼叫会话控制功能实体收到被叫用户设备返回的被叫用户不支持主叫编解码类型消息后，判断是否已经协商过主被叫用户分别支持的编解码类型，并在判断结果为否时，根据所述返回的消息中携带的被叫用户支持的编解码类型信息，指示编解码控制器控制重新协商主被叫用户分别支持的编解码类型并将重新协商确定的主被叫用户分别支持的编解码类型通知媒体网关。

相应地，本发明具体实施例的一种编解码类型协商控制方法，该方法主要包括：

互通边界控制功能实体先后收到不同IMS网络返回的被叫用户不支持主叫编解码类型消息，根据所述消息携带的所述不同IMS网络支持的编解码类型交集信息，控制重新协商主被叫用户分别支持的编解码类型并将重新协商确定的主被叫用户分别支持的编解码类型通知媒体网关。

根据本发明的具体实施例，通过在发起会话时预判被叫用户支持的编解码类型；根据预判的被叫用户支持的编解码类型和主叫用户支持的编解码类型判断主被叫用户间的会话是否需进行编解码转换；若主叫用户支持的编解码类型与被叫用户支持的编解码类型存在交集，则判断不需进行编解码转换，继续会话处理；若主叫用户支持的编解码类型与被叫用户支持的编解码类型不存在交集，则判断需进行编解码转换，控制协商主被叫用户分别支持的编解码类型，将协商确定的主被叫用户分别支持的编解码类型通知媒体网关，由于无需在IFC中为每个用户静态配置一个编解码AS进行编解码转换，可降低维护成本，减少接续时间，灵活方便的实现编解码转换。

附图说明

图1是本发明编解码转换控制方法的一个具体实施例的主要流程图；

图2是本发明IBCF控制进行编解码转换的一个具体实施例示意图；

图3是本发明发起会话重建立时通过IBCF控制进行编解码转换的一个具体实施例示意图；

图4是本发明IBCF处理编解码失败的一个具体实施例示意图；

图5是本发明编解码控制方法的第一具体实施例消息处理流程图；

图6是本发明编解码控制方法的第二具体实施例消息处理流程图；

图7是本发明编解码控制方法的第三具体实施例消息处理流程图；

图8是本发明编解码控制方法的第四具体实施例消息处理流程图；

图9是本发明编解码控制方法的第五具体实施例消息处理流程图；

图10是本发明IMS域间编解码控制的第一应用场景示意图；

图11是本发明IMS域间编解码控制的第二应用场景示意图；

图12是本发明IMS域间编解码控制的第三应用场景示意图；

图13是本发明IMS域间编解码控制的第四应用场景示意图；

图14是本发明IMS域间编解码控制的第五应用场景示意图；

图15是本发明IMS域间编解码控制的第六应用场景示意图；

图16是本发明IMS域间编解码控制的第七应用场景示意图；

图17是本发明IMS域间编解码控制的第八应用场景示意图；

图18是本发明IMS系统第一具体实施例结构示意图；

图19是本发明IMS系统第二具体实施例结构示意图；

图20是本发明IMS系统第三具体实施例结构示意图；

图21是本发明IMS系统第四具体实施例结构示意图。

具体实施方式

参考图1，该图是本发明编解码转换控制方法的一个具体实施例的主要流程图，具体主要包括如下步骤：

步骤s101，预判被叫用户支持的编解码类型，具体实现时，可以由S-CSCF在会话建立时预判被叫用户支持的编解码类型，例如，S-CSCF在收到发起会话建立的Invite消息后，可采用下述方式获取被叫用户支持的编解码类型：

(1)基于对Request URI的号码分析结果，判断被叫用户所在网络类型，进而判断被叫用户终端支持的编解码类型，具体实现时，例如可以在S-CSCF配置一张被叫用户所在域媒体属性表来实现，通过查询本地配置即可获取被叫用户所在网络支持的编解码类型。

(2)S-CSCF注册时保存用户带上来的P-Access-Network-Info头域，通过被叫用户所在的接入网类型，来判断被叫用户终端支持的编解码类型。

(3)通过RFC3840、RFC3841协议所描述的方式，UE在注册时将自己支持的编解码能力带给S-CSCF，S-CSCF在注册时保存下来，在呼叫时通过查询用户数据来获取被叫用户终端支持的编解码类型，上述判断方式的优先级可依次递增，例如按照(1)<(2)<(3)。

需要说明的，具体实现时，也可以由互通边界控制功能实体(IBCF)或其他网络实体预判被叫用户支持的编解码类型，具体预判被叫用户的编解码类型可采用上述或其他多种方式，这里不再赘述。

步骤s102，根据预判的被叫用户支持的编解码类型和主叫用户支持的编解码类型判断主被叫用户间的会话是否需进行编解码转换，例如，根据会话建立时，会话邀请消息中携带的主叫用户支持的编解码类型和所述预判的被叫用户支持的编解码类型即可判定是否需要进行编解码转换，具体实现时，若上述步骤s101是由S-CSCF预判确定被叫用户支持的编解码类型，则本步骤继续由S-CSCF判断确定是否需进行编解码转换，若上述步骤s101是由IBCF预判确定被叫用户支持的编解码类型，则本步骤继续由IBCF判断确定是否需进行编解码转换。

另外，本实施例中在步骤s103，若主叫用户支持的编解码类型与被叫用户支持的编解码类型存在交集，则判断不需进行编解码转换，可继续会话处理，这里不再赘述；

另外，本实施例中，在步骤s104，若主叫用户支持的编解码类型与被叫用户支持的编解码类型不存在交集，则判断需进行编解码转换，可控制协商主被叫用户分别支持的编解码类型，并将协商确定的主被叫用户分别支持的编解码类型通知媒体网关，具体实现时，例如可以由S-CSCF指示IBCF控制协商主被叫用户分别支持的编解码类型，并将协商确定的主被叫用户分别支持的编解码类型通知媒体网关，一个具体的例子，例如S-CSCF在Invite消息中构造扩展头域，用于指示需进行编解码转换，并将携带该指示需进行编解码转换的扩展头域的Invite消息转发给IBCF，例如扩展头域可以为：

Called-Required-Codecs：CALLED-REQUIRED；audio-codec-list＝PCMA，PCMU，G729，AMR。

即表示携带信息为被叫用户必选的音频编解码类型(codec)为PCMA，PCMU，G729，AMR。

IBCF即可通过检查S-CSCF发送来的Invite消息中是否含有指示需要进行编解码转换的扩展头域信息，例如IBCF检测到S-CSCF发送来的Invite消息中含有Called-Required-Codecs扩展头域，则IBCF判断需要进行编解码转换，启动协商主被叫用户支持的编解码类型，并将协商确定的主被叫分别支持的编解码类型通知媒体网关。

参考图2，该图是在会话建立时IBCF实现编解码转换控制的一个具体实施例示意图，IBCF作为IMS网络边界，可完成网络拓扑隐藏、IMS-ALG、媒体控制、服务质量(QoS)管理、信令过滤、引入IWF与非会话初始协议(SIP)的IP网络互通等功能，本实施例中IBCF控制进行编解码转换主要包括以下流程：

(1)IBCF检查S-CSCF发来的Invite消息中是否含有需要进行编解码转换的扩展头域信息，例如本实施例中IBCF检测到Invite消息中含有Called-Required-Codecs扩展头域，则IBCF判断需要进行编解码转换；

(2)IBCF从S-CSCF发来的Invite消息SDP中获取媒体的IP地址IP1以及主叫用户支持的编解码类型codec 1，2，然后向I-BGF发送携带所述IP1及主叫用户支持的编解码类型codec1，2的Req消息。

(3)I-BGF返回Rsp消息，其中携带转化后的IP地址IP3。

(4)IBCF根据I-BGF返回的地址IP3修改Invite消息的SDP消息体，将扩展头域Called-Required-Codecs中的codec添加到SDP Offer中相应m行下a行的codec后面，并删除扩展头域，根据Route头域中的地址将Invite消息转发给被叫用户，同时保存Invite消息中的SDP。

(5)IBCF收到被叫用户返回的200消息，从所述200消息的SDP中获取媒体的IP地址IP4以及被叫用户支持的编解码类型codec3，4信息。

(6)IBCF向I-BGF发送携带所述IP4以及主叫用户支持的编解码类型codec1，2以及被叫用户支持的编解码类型codec3，4信息的Req消息。

(7)I-BGF返回Rsp消息，携带转化后的IP地址IP2，此时，I-BGF已经获知主被叫用户双方分别支持的编解码能力，能够在主被叫用户之间进行编解码转换。

上述为会话建立过程中IBCF进行编解码转换控制，在其他的场景下，IBCF也可以进行编解码转换控制，例如：

参考图3，呼叫建立后IBCF收到re-Invite消息后的处理如下：

呼叫建立后IBCF收到re-Invite消息，如果没有媒体流(”m”行)的增加和删除，例如进行了编解码转换的媒体流(”m”行)的连接信息(IP和port)或者编解码发生了变化，则IBCF可控制更新发生更改的用户与I-BGF的媒体信息；而如果有媒体流(”m”行)的增加，则IBCF可控制进行媒体流增加的编解码转换的处理；或者，如果有媒体流(”m”行)的删除，即端口变为零，IBCF可控制进行媒体流删除的编解码转换处理，例如删除连接信息。

或者，参考图4，在会话建立时，IBCF与RACS交互进行编解码转换控制，若RACS返回编解码失败的AA响应(AAA)消息后，则IBCF向主叫用户回4xx消息拆除会话。

另外，需要说明的，在具体应用环境下，也可以由S-CSCF预判被叫用户支持的编解码类型，由S-CSCF指示编解码控制AS控制协商主被叫用户分别支持的编解码类型，并将协商确定的主被叫用户分别支持的编解码类型通知媒体网关；或由S-CSCF预判被叫用户支持的编解码类型，由S-CSCF直接控制协商主被叫用户分别支持的编解码类型，并将协商确定的主被叫用户分别支持的编解码类型通知媒体网关，或由IBCF预判被叫用户支持的编解码类型，由IBCF控制协商主被叫用户分别支持的编解码类型并将协商确定的主被叫用户分别支持的编解码类型通知媒体网关，这里不再一一赘述。

另外，还需要说明的，在具体的应用环境下，例如在发起会话建立时，若S-CSCF预判主被叫用户间的会话不需要做编解码转换，而没有将会话邀请消息发送给IBCF，而是直接转发给了被叫侧，若S-CSCF收到被叫用户设备返回的被叫用户不支持主叫编解码类型消息后，例如，收到被叫用户返回的488/606响应消息时，S-CSCF可首先判断是否已经协商过主被叫用户分别支持的编解码类型，并在判断结果为否时，根据所述返回的消息中携带的被叫用户支持的编解码类型信息，直接控制重新协商主被叫用户分别支持的编解码类型并将重新协商确定的主被叫用户分别支持的编解码类型通知媒体网关，或指示编解码控制器(所述编解码控制器可以是IBCF也可以是编解码应用服务器或者其他可实现编解码控制的功能实体)重新协商主被叫用户分别支持的编解码类型并将重新协商确定的主被叫用户分别支持的编解码类型通知媒体网关。

另外，还需要说明的，在具体的应用环境下，例如，在发起会话建立时，若S-CSCF预判主被叫用户间的会话需要做编解码转换，将会话邀请消息发送给IBCF，由于不同网络的本地策略检查，可能会禁止某些编解码通过，IBCF可能先后收到不同网络返回的网络不支持主叫编解码类型消息，则可根据所述所述不同网络支持的编解码类型的交集信息，控制重新协商主被叫用户分别支持的编解码类型，将重新协商确定的主被叫用户分别支持的编解码类型通知媒体网关。

另外，还需要说明的，在具体的应用环境下，例如，在发起会话建立时，当预判主被叫用户间的会话需要做编解码转换，控制协商主被叫用户分别支持的编解码类型，若被叫用户返回的所支持的编解码类型与主叫用户支持的相同，即主被叫间不需作编解码转换，同样可将主被叫用户分别支持的编解码类型通知媒体网关(此种情况下，主被叫用户支持的编解码类型相同)，媒体网关对主被叫间的媒体并不作编解码转换。

下面以具体的应用场景对编解码转换控制的过程进行详细说明。

参考图5，该图是本发明编解码转换控制方法的第一具体实施例处理流程图。

本实施例中主被叫用户都为IMS域内用户，但是主被叫用户终端不支持相同的编解码类型，需要IMS网络提供编解码转换，本实施例中由被叫用户侧的S-CSCF、IBCF、RACS、I-BGF完成编解码转换，具体处理流程如下：

步骤s201：被叫S-CSCF预判被叫用户侧必选的编解码类型(本实施例中为codec4，5)与收到的主叫用户发送的Invite消息中SDP Offer携带的主叫用户支持的编解码类型(本实施例中为codec 1，2，3)做比较，若不存在交集则判断需要进行编解码转换；S-CSCF将预判的被叫用户支持的编解码类型(本实施例中为codec 4，5)添加到Invite消息中(本实施例中所述被叫用户支持的编解码类型codec 4，5通过Invite消息的扩展头域Called-Required-Codecs携带)，转发给IBCF。

步骤s202：IBCF发现S-CSCF发送来的Invite消息中携带有扩展头域Called-Required-Codecs，判定需要做编解码转换，向RACS发送AA请求(AAR)消息，所述AAR消息中携带有从Invite消息的SDP中获取的媒体IP地址IP1以及主叫用户支持的编解码类型codec 1，2，3。

步骤s203：RACS将AAR消息中的IP地址IP1、SDP Direction、媒体的本域和外域ID，以及主叫用户支持的编解码类型codec 1，2，3通过Add Termination发送给I-BGF。

步骤s204：I-BGF根据Add Termination消息中的SDP Direction、媒体的本域和外域ID，申请目的域的IP地址IP3通过Reply消息返回给RACS，同时保存IP地址IP1以及主叫用户支持的编解码类型codec 1，2，3。

步骤s205：RACS根据从Reply消息中获得的IP地址IP3，向IBCF返回AAA消息。

步骤s206：IBCF根据从AAA消息中获得的IP地址IP3，以及S-CSCF发送来的Invite消息中用于指示进行编解码转换的扩展头域Called-Required-Codecs中携带的被叫用户支持的编解码类型codec 4，5修改SDP，将主叫用户支持的编解码类型codec 1，2，3和被叫支持的编解码类型codec4，5合成codes 1，2，3，4，5添加到SDP消息体中，并删除所述扩展头域Called-Required-Codecs将Invite消息转发给被叫用户，被叫用户协商通过，返回携带被叫用户支持的编解码类型codec4，5的1xx/2xx消息。

步骤s207：IBCF收到被叫用户返回的1xx/2xx消息，从所述1xx/2xx消息的SDP中获取媒体的IP地址IP2和被叫用户支持的编解码类型codec4，5，向RACS发送AAR消息，所述AAR消息中携带有所述IP地址IP2、主叫用户支持的编解码类型Codec 1，2，3及被叫用户支持的编解码类型codec4，5。

步骤s208：RACS根据从AAR消息中获得的IP地址IP2、SDP Direction、本地保存的媒体本域、域ID、主叫用户支持的编解码类型Codec 1，2，3以及被叫用户支持的编解码类型codec 4，5发送Add Termination给I-BGF。

步骤s209：I-BGF根据从Add Termination消息中获得的SDP Direction和本地保存的媒体本域和外域ID，申请目的域的IP地址IP4，通过Reply消息返回给RACS，同时保存主叫用户支持的编解码类型Codec 1，2，3以及被叫用户支持的编解码类型codec 4，5。

步骤s210：RACS根据从Reply消息中获得的IPv4地址IP4向IBCF返回AAA消息。

步骤s211：IBCF根据从AAA消息中获得的IP地址IP4以及主叫用户支持的编解码类型codec 1，2，3修改SDP消息体，将200消息前传，最终通过S-CSCF转发给主叫用户。

参考图6，该图是本发明编解码转换控制方法的第二具体实施例处理流程图。

本实施例中主被叫用户都为IMS域内用户，但是主被叫终端不支持相同的编解码类型，需要IMS网络提供编解码转换业务，本实施例中同样由被叫用户侧的S-CSCF、IBCF、RACS、I-BGF完成编解码转换，其中被叫S-CSCF收到初始会话邀请Invite消息后，判断不需要做编解码转换，后续被叫S-CSCF收到被叫用户终端返回的被叫用户不支持主叫用户编解码类型的488/606响应消息，响应消息中携带了被叫用户支持的编解码类型，其中S-CSCF、IBCF、RACS、I-BGF完成编解码转换的过程与第一具体实施例类似(即步骤s302-s311)，其与第一具体实施例最大的不同在于步骤s301，被叫S-CSCF根据被叫用户终端返回的被叫用户不支持主叫用户编解码类型的488/606响应消息，将所述488/606响应消息中携带的被叫用户支持的编解码类型(本实施例中为codec4，5)添加到Invite消息的Called-Required-Codecs扩展头域中，转发给IBCF。

参考图7，该图是本发明编解码转换控制方法的第三具体实施例处理流程图。

本实施例中主被叫用户都为IMS域内用户，但是主被叫终端没有相同的编解码类型，需要IMS网络提供编解码转换业务，本实施例中同样由被叫用户侧的S-CSCF、IBCF、RACS、I-BGF完成编解码转换，其中IBCF先后收到第一个网络返回的488/606响应消息(该响应消息中携带了第一个网络允许的编解码类型)和第二个网络返回的488/606响应消息(该响应消息中携带了第二个网络支持的编解码类型)，具体处理流程如下：

步骤s401：被叫S-CSCF判断需进行编解码转换，将预判的被叫用户支持的编解码类型(codec 4，5)添加到Invite消息的扩展头域Called-Required-Codecs中，转发给IBCF。

步骤s402：IBCF检测发现S-CSCF发送来的Invite消息中携带有扩展头域Called-Required-Codecs，判定需要做编解码转换，向RACS发送AAR消息，所述AAR消息中携带有从Invite消息的SDP中获取的媒体IP地址IP1以及主叫用户支持的编解码类型codec 1，2，3。

步骤s403：RACS将AAR消息中的IP地址IP1、SDP Direction以及主叫用户支持的编解码类型codec 1，2，3通过Add Termination发送给I-BGF。

步骤s404：I-BGF根据Add Termination消息中的IP地址，SDPDirection和媒体的本域和外域ID，申请目的域的媒体域的IP地址IP3，通过Reply消息返回给RACS，同时将主叫用户支持的编解码类型codec 1，2，3保存下来。

步骤s405：RACS从Reply消息中获得的IP地址IP3，向IBCF返回AAA消息。

步骤s406：IBCF根据从AAA消息中获得的IP地址IP3，修改SDP消息体，同时将主叫用户支持的编解码类型codec1，2，3和被叫支持的编解码类型codec 4，5合成codes 1，2，3，4，5添加到SDP消息体中，并删除扩展头域Called-Required-Codecs将Invite消息转发给被叫用户，由于不同网络的本地策略检查，可能会禁止某些编解码通过，IBCF收到第一个网络返回的488/606响应消息(该响应消息中携带了该第一个网络允许的编解码类型codes2，3，4，5)，后面又收到第二个网络返回的488/606响应消息(该响应消息中携带第二个网络支持的编解码类型codes 3，4，5，6。

步骤s407：IBCF根据先后返回的第一个网络支持的编解码类型codec2，3，4，5和第二个网络支持的编解码类型codec 3，4，5，6的交集codec 3，4，5修改SDP，将消息前传给被叫用户，被叫用户协商通过，返回携带被叫用户支持的编解码类型codec 4，5的183消息。

步骤s408：IBCF从被叫用户返回的183消息的SDP中获取媒体的IP地址IP2和被叫用户支持的编解码类型codec 4，5，向RACS发送AAR消息，所述AAR消息中携带有所述IP地址IP2、主叫用户支持的编解码类型Codec1，2，3及被叫用户支持的编解码类型codec 4，5。

步骤s409：RACS根据从AAR消息中获得的IP地址IP2、SDP Direction、本地保存的媒体本域、外域ID、主叫用户支持的编解码类型codec 1，2，3以及被叫用户支持的编解码类型codec4，5发送Add Termination给I-BGF。

步骤s410：I-BGF根据从Add Termination消息中获得的SDP Direction和本地保存的媒体本域和外域ID，申请目的域的IP地址IP4，通过Reply消息返回给RACS，同时保存主叫用户支持的编解码类型codec 1，2，3以及被叫用户支持的编解码类型codec 4，5。

步骤s411：RACS根据从Reply消息中获得的IP地址IP4向IBCF返回AAA消息。

步骤s412：IBCF根据从AAA消息中获得的IP地址IP4以及之前获取的主叫用户支持的编解码类型codec 1，2，3修改SDP消息体，将200消息前传，最终通过S-CSCF转发给主叫用户。

参考图8，该图是本发明编解码转换控制方法的第四具体实施例处理流程图。

本实施例中主被叫用户都为IMS域内用户，但是主被叫终端不支持相同的编解码类型，需要IMS网络提供编解码转换业务，本实施例中由被叫用户侧的S-CSCF、RACS、I-BGF完成编解码转换，具体处理流程如下：

步骤s501：被叫S-CSCF收到主叫用户发送的会话建立Invite消息，预判被叫用户侧必选的编解码类型(本实施例中为codec 4，5)与收到的主叫用户发送的Invite消息中SDP Offer携带的主叫用户支持的编解码类型(本实施例中为codec 1，2，3)做比较，若不存在交集则判断需要进行编解码转换；向RACS发送AAR消息，所述AAR消息中携带从Invite消息SDP中获取的IP地址IP1以及主叫用户支持的编解码类型codec 1，2，3。

步骤s502：RACS将AAR消息中的IP地址IP1、SDP Direction以及主叫用户支持的编解码类型codec 1，2，3通过Add Termination发送给I-BGF。

步骤s503：I-BGF根据Add Termination消息中的IP地址IP1，SDPDirection和媒体的本域和外域ID，申请目的域的媒体域的IP地址IP3，通过Reply消息返回给RACS，同时保存IP地址IP1以及主叫用户支持的编解码类型codec 1，2，3。

步骤s504：RACS从Reply消息中获得的IP地址IP3，向S-CSCF返回AAA消息。

步骤s505：S-CSCF根据RACS返回的地址IP3修改SDP消息体，同时将codec4，5和codec 1，2，3合成codes1，2，3，4，5添加到SDP消息体中，将Invite消息前传给被叫用户，被叫用户协商通过，返回携带被叫用户支持的编解码类型codec4，5的1xx/2xx消息。

步骤s506：S-CSCF从被叫用户返回的1xx/2xx消息的SDP中获取媒体的IP地址IP2和被叫用户支持的编解码类型codec4，5，向RACS发送AAR消息，所述AAR消息中携带所述媒体的IP地址IP2、主叫用户支持的编解码类型codec 1，2，3及被叫用户支持的编解码类型codec 4，5。

步骤s507：RACS根据从AAR消息中获得的IP地址IP2、SDP Direction、本地保存的媒体本域、外域ID、主叫用户支持的编解码类型codec 1，2，3、以及被叫用户支持的编解码类型codec 4，5发送Add Termination给I-BGF。

步骤s508：I-BGF根据从Add Termination消息中获得的SDP Direction和本地保存的媒体本域和外域ID，申请目的域的IP地址IP4，向RACS返回Reply消息，同时保存主叫用户支持的编解码类型codec 1，2，3以及被叫用户支持的编解码类型codec 4，5。

步骤s509：RACS根据从Reply消息中获得的IP地址IP4向S-CSCF返回AAA消息。

步骤s510：S-CSCF根据从AAA消息中获得的IP地址IP4以及之前获取的主叫用户支持的编解码类型codec 1，2，3修改SDP消息体，将200消息前传给主叫用户。

需要说明的，本实施例中仅以会话建立过程中的S-CSCF直接进行编解码转换控制为例进行说明，其他S-CSCF预判不需要做编解码转换，在收到被叫用户返回的不支持主叫用户编解码类型的消息后，重新直接进行编解码转换控制的场景与本实施例类似，这里不再赘述。

参考图9，该图是本发明编解码控制方法的第五具体实施例处理流程图。

本实施例中主被叫用户都为IMS域内用户，但是主被叫用户终端不支持相同的编解码类型，需要IMS网络提供编解码转换业务，会话建立过程中由被叫用户侧的S-CSCF、编解码控制AS、MRFC完成编解码转换，具体包括如下步骤：

步骤s601：S-CSCF收到触发结束的Invite消息，所述Invite消息SDP中携带了主叫用户支持的编解码类型(本实施例中为codec 1，2)。

步骤s602：S-CSCF预判被叫用户支持的编解码类型(本实施例中为codec3，4)，并判断是否需要进行编解码转换，本实施例中由于主被叫用户不支持相同的编解码类型，S-CSCF判定需要进行编解码转换，将预判的被叫用户支持的编解码类型codec 4，5添加到Invite消息的扩展头域Called-Required-Codecs携带；例如，扩展头域Called-Required-Codecs：CALLED-REQUIRED；audio-codec-list＝3，4。

步骤s603：S-CSCF将所述携带扩展头域Called-Required-Codecs的Invite消息转发给配置的编解码控制AS，其中Invite消息的route头域为如下形式：route：Transcoding AS，下一跳网元，即要求消息由编解码控制AS直接路由到下一跳网元。

步骤s604：编解码控制AS检查发现S-CSCF发送来的Invite消息中含有扩展头域Called-Required-Codecs，则编解码控制AS记录本次呼叫为Transcoding标志，如果类型为CALLED-REQUIRED，则将Called-Required-Codecs头域中的被叫用户支持的编解码类型codec 3，4添加到Inivite消息的SDP Offer中。

步骤s605：编解码控制AS删除Invite消息的扩展头域，将codec3，4和codec1，2合成codes 1，2，3，4添加到SDP消息体中，根据Route头域将Invite消息转发给被叫用户。

步骤s606：被叫用户协商通过后，将被叫用户支持的编解码类型codec 3，4返回给编解码控制AS。

步骤s607：编解码控制AS根据主叫用户支持的编解码类型codec 1，2和被叫用户支持的编解码类型codec 3，4通过MRFC建立与主被叫间的编解码转换。

步骤s608：后续会话建立流程与现有技术相同，这里不再赘述。

需要说明的，本实施例中仅以会话建立过程中的S-CSCF插入编解码控制AS进行编解码转换控制为例进行说明，其他S-CSCF预判不需要做编解码转换，在收到被叫用户返回的不支持主叫用户编解码类型的消息后，重新插入编解码控制AS协商进行编解码转换控制的场景与本实施例类似，这里不再赘述。

需要说明的，上述编解码转换控制方法既可以在IMS域内进行编解码转换控制，也可以在IMS域间或其他场景进行编解码转换，例如，参考图10，主叫IMS网络能够提供编解码转换业务，主被叫用户都为IMS用户，但是主被叫用户不在同一个IMS域内，并且主被叫用户终端没有相同的编解码类型，主叫IMS网络能够提供编解码转换业务，被叫IMS网络不能够提供编解码转换业务。这种场景下，主叫IMS网络能够提供编解码转换业务与前面描述的IMS域内编解码控制的场景类似，具体参考前述说明，这里不再赘述。

或者，参考图11，被叫IMS网络能够提供编解码转换业务，主被叫用户都为IMS用户，但是主被叫用户不在同一个IMS域内，并且主被叫用户终端没有相同的编解码类型，主叫IMS网络不能够提供编解码转换业务，被叫IMS网络能够提供编解码转换业务。这种场景下，被叫IMS网络能够提供编解码转换业务与前面描述的IMS域内编解码控制的场景类似，具体参考前述说明，这里不再赘述。

或者，参考图12，IMS用户为主叫，non-IMS SIP网络用户为被叫，IMS用户和non-IMS SIP网络用户互通时，IMS用户为主叫，non-IMS SIP网络用户为被叫，并且主被叫用户终端没有相同的编解码类型，需要IMS网络提供编解码转换业务。这种场景下，IMS网络提供编解码转换业务与前面描述的IMS域内编解码控制的场景类似，具体参考前述说明，这里不再赘述。

或者，参考图13，IMS用户为被叫，non-IMS SIP网络用户为主叫，IMS用户和non-IMS SIP网络用户互通时，IMS用户为被叫，non-IMS SIP网络用户为主叫，并且主被叫用户终端没有相同的编解码类型，需要IMS网络提供编解码转换业务。这种场景下，IMS网络提供编解码转换业务与前面描述的IMS域内编解码控制的场景类似，具体参考前述说明，这里不再赘述。

或者，参考图14，IMS用户为主叫，H.323网络或其它非SIP的IP网络用户为被叫，IMS用户和H.323网络或其它非SIP的IP网络用户互通，IMS用户为主叫，H.323网络或其它非SIP的IP网络用户为被叫，并且主被叫用户终端没有相同的编解码类型，需要IMS网络提供编解码转换业务。这种场景下，IMS网络提供编解码转换业务与前面描述的IMS域内编解码控制的场景类似，具体参考前述说明，这里不再赘述。

或者，参考图15，IMS用户为被叫，H.323网络或其它非SIP的IP网络用户为主叫，IMS用户和H.323网络或其它非SIP的IP网络用户互通，IMS用户为被叫，H.323网络或其它非SIP的IP网络用户为主叫，并且主被叫用户终端没有相同的编解码类型，需要IMS网络提供编解码转换业务。这种场景下，IMS网络提供编解码转换业务与前面描述的IMS域内编解码控制的场景类似，具体参考前述说明，这里不再赘述。

或者，参考图16，IMS用户为被叫，PSTN/ISDN用户或PLMN的CS域用户为主叫，IMS用户和PSTN/ISDN用户或PLMN的CS域用户互通，IMS用户为被叫，PSTN/ISDN用户或PLMN的CS域用户为主叫，并且主被叫用户终端没有相同的编解码类型，需要IMS网络提供编解码转换业务。这种场景下，IMS网络提供编解码转换业务与前面描述的IMS域内编解码控制的场景类似，具体参考前述说明，这里不再赘述。

或者，参考图17，主叫为PSTN/ISDN用户或PLMN的CS域用户，经过IMS中继网络，被叫为IMS或non-IMS SIP或其他IP网络用户，IMS网络作为中继网络，主叫为PSTN/ISDN用户或PLMN的CS域用户，经过IMS中继网络，被叫为IMS或non-IMS SIP或其他IP网络用户，由被叫的IMS或non-IMS SIP或其他IP网络提供编解码转换业务，其中对于被叫为IMS用户的场景可参考被叫IMS网络能够提供编解码转换业务，这里不再赘述。

下面说明说明另一方面。

参考图18，该图是本发明IMS系统的第一具体实施例结构示意图。

本实施例中IMS系统涉及编解码转换控制的实体主要包括有S-CSCF1和IBCF2，其中所述S-CSCF1可包括有：

预判处理单元11，本实施例中所述预判处理单元11主要用于预判被叫用户支持的编解码类型，具体预判方式可参考前述说明，这里不再赘述；

编解码转换判断处理单元12，本实施例中所述解码转换判断处理单元12主要用于根据所述预判处理单元11预判的被叫用户支持的编解码类型和主叫用户支持的编解码类型判断主被叫用户间的会话是否需进行编解码转换，即在主叫用户支持的编解码类型与被叫用户支持的编解码类型不存在交集时，判断需进行编解码转换，指示IBCF 2进行编解码转换控制，指示方式可采用在S-CSCF 1与IBCF 2交互的消息中通过扩展头域(例如Called-Required-Codecs)标识，具体可参考前述说明，这里不再赘述，另外，所述编解码转换判断处理单元12在主叫用户支持的编解码类型与被叫用户支持的编解码类型存在交集时，可判断不需进行编解码转换，指示继续会话处理。

具体实现时，所述S-CSCF 1还可包括消息解析处理单元13，在所述编解码转换判断处理单元12判断不需进行编解码转换，继续会话处理后，若收到被叫用户设备返回被叫用户不支持主叫编解码类型消息，则指示编解码控制器(本实施例即IBCF)进行编解码转换控制，所述IBCF进行编解码转换控制可参考前述说明，这里不再赘述。

而所述IBCF 2可包括有：

媒体转换协商控制单元21，本实施例中所述媒体转换协商控制单元21主要用于控制协商主被叫用户分别支持的编解码类型；

媒体转换指示单元22，本实施例中所述媒体转换指示单元22主要用于将协商确定的主被叫用户分别支持的编解码类型通知媒体网关。

参考图19，该图是本发明IMS系统的第二具体实施例结构示意图。

本实施例中IMS系统涉及编解码转换控制的主要包括有S-CSCF 1，另外所述IMS系统中还包括独立功能单元的编解码控制AS 3，用于控制媒体网关进行编解码转换，编解码控制AS 3控制媒体网关进行编解码转换可参考现有技术，这里不再赘述；

其中所述S-CSCF 1包括有：

预判处理单元21，本实施例中所述预判处理单元21主要用于预判被叫用户支持的编解码类型，具体预判方式可参考前述说明，这里不再赘述；

编解码转换判断处理单元22，本实施例中所述编解码转换判断处理单元22主要根据所述预判处理单元21预判的被叫用户支持的编解码类型和主叫用户支持的编解码类型判断主被叫用户间的会话是否需进行编解码转换，若主叫用户支持的编解码类型与被叫用户支持的编解码类型存在交集，则判断不需进行编解码转换，继续会话处理；若主叫用户支持的编解码类型与被叫用户支持的编解码类型不存在交集，则判断需进行编解码转换，指示编解码控制AS3进行编解码转换控制。

另外，所述S-CSCF 1还可包括：

消息解析处理单元23，本实施例中所述消息解析处理单元23主要用于在编解码转换判断处理单元22判断不需进行编解码转换，继续会话处理后，若收到被叫用户设备返回被叫用户不支持主叫编解码类型消息，则指示编解码控制器(本实施例中即编解码控制AS 3)进行编解码转换控制。

参考图20，该图是本发明IMS系统的第三具体实施例结构示意图。

本实施例中IMS系统涉及编解码转换控制的实体主要包括有IBCF 2，其中所述IBCF 2包括有：

预判处理单元31，本实施例中所述预判处理单元31主要用于预判被叫用户支持的编解码类型，具体预判方式可参考前述说明，这里不再赘述；

媒体转换协商控制单元32，本实施例中所述媒体转换协商控制单元32主要用于控制协商主被叫用户分别支持的编解码类型；

媒体转换指示单元33，本实施例中所述媒体转换指示单元33主要用于将协商确定的主被叫用户分别支持的编解码类型通知媒体网关；

编解码转换判断处理单元34，本实施例中所述编解码转换判断处理单元34主要根据所述预判处理单元31预判的被叫用户支持的编解码类型和主叫用户支持的编解码类型判断主被叫用户间的会话是否需进行编解码转换，若主叫用户支持的编解码类型与被叫用户支持的编解码类型存在交集，则判断不需进行编解码转换，继续会话处理；若主叫用户支持的编解码类型与被叫用户支持的编解码类型不存在交集，则判断需进行编解码转换，指示所述媒体转换协商控制单元32控制协商主被叫用户分别支持的编解码类型。

另外，所述IBCF 2还可包括：

消息解析处理单元35，本实施例中所述消息解析处理单元35主要用于在先后收到网络和被叫用户设备返回被叫用户不支持主叫编解码类型消息，则指示媒体转换协商控制单元控制重新协商主被叫用户分别支持的编解码类型。

参考图21，该图是本发明IMS系统的第四具体实施例结构示意图。

本实施例中IMS系统涉及编解码转换控制的实体主要包括有S-CSCF1，其中所述S-CSCF1包括有：

预判处理单元41，用于预判被叫用户支持的编解码类型，具体预判方式可参考前述说明，这里不再赘述；

媒体转换协商控制单元42，用于控制协商主被叫用户分别支持的编解码类型；

媒体转换指示单元43，将协商确定的主被叫用户分别支持的编解码类型通知媒体网关；

编解码转换判断处理单元44，根据所述预判处理单元预判的被叫用户支持的编解码类型和主叫用户支持的编解码类型判断主被叫用户间的会话是否需进行编解码转换，若主叫用户支持的编解码类型与被叫用户支持的编解码类型存在交集，则判断不需进行编解码转换，继续会话处理；若主叫用户支持的编解码类型与被叫用户支持的编解码类型不存在交集，则判断需进行编解码转换，指示媒体转换协商控制单元42控制协商主被叫用户分别支持的编解码类型。

另外，S-CSCF 1还可包括：

消息解析处理单元45，在所述编解码转换判断处理单元判断不需进行编解码转换，继续会话处理后，若收到被叫用户设备返回的被叫用户不支持主叫编解码类型消息，则指示媒体转换协商控制单元控制重新协商主被叫用户分别支持的编解码类型。

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

Claims (20)

1、一种服务呼叫会话控制功能实体，其特征在于，包括有：

预判处理单元，用于预判被叫用户支持的编解码类型；

编解码转换判断处理单元，用于根据所述预判处理单元预判的被叫用户支持的编解码类型和主叫用户支持的编解码类型判断主被叫用户间的会话是否需进行编解码转换，在主叫用户支持的编解码类型与所述预判的被叫用户支持的编解码类型不存在交集时，判断需进行编解码转换，指示编解码控制器进行编解码转换控制。

2、根据权利要求1所述的服务呼叫会话控制功能实体，其特征在于，还包括：

消息解析处理单元，在编解码转换判断处理单元判断不需进行编解码转换，继续会话处理后，若收到被叫用户设备返回被叫用户不支持主叫编解码类型消息，则指示编解码控制器进行编解码转换控制。

3、一种互通边界控制功能实体，其特征在于，包括有：

媒体转换协商控制单元，用于控制协商主被叫用户分别支持的编解码类型；

媒体转换指示单元，将协商确定的主被叫用户分别支持的编解码类型通知媒体网关；

预判处理单元，用于预判被叫用户支持的编解码类型；

编解码转换判断处理单元，根据所述预判处理单元预判的被叫用户支持的编解码类型和主叫用户支持的编解码类型判断主被叫用户间的会话是否需进行编解码转换，在主叫用户支持的编解码类型与所述预判的被叫用户支持的编解码类型不存在交集时，判断需进行编解码转换，指示媒体转换协商控制单元控制协商主被叫用户分别支持的编解码类型。

5、根据权利要求4所述的互通边界控制功能实体，其特征在于，还包括：

消息解析处理单元，若先后收到网络和被叫用户设备返回被叫用户不支持主叫编解码类型消息，则指示媒体转换协商控制单元控制重新协商主被叫用户分别支持的编解码类型。

6、一种IP多媒体子系统，包括服务呼叫会话控制功能实体和互通边界控制功能实体，其特征在于，所述互通边界控制功能实体包括有：

媒体转换协商控制单元，用于控制协商主被叫用户分别支持的编解码类型；

媒体转换指示单元，将协商确定的主被叫用户分别支持的编解码类型通知媒体网关；

所述服务呼叫会话控制功能实体包括有：

预判处理单元，用于预判被叫用户支持的编解码类型；

编解码转换判断处理单元，根据所述预判处理单元预判的被叫用户支持的编解码类型和主叫用户支持的编解码类型判断主被叫用户间的会话是否需进行编解码转换，在主叫用户支持的编解码类型与被叫用户支持的编解码类型不存在交集时，判断需进行编解码转换，指示互通边界控制功能实体进行编解码转换控制。

7、一种IP多媒体子系统，包括有服务呼叫会话控制功能实体，其特征在于，所述IP多媒体子系统包括独立功能单元的编解码控制应用服务器，用于控制媒体网关进行编解码转换；

所述服务呼叫会话控制功能实体包括有：

预判处理单元，用于预判被叫用户支持的编解码类型；

编解码转换判断处理单元，根据所述预判处理单元预判的被叫用户支持的编解码类型和主叫用户支持的编解码类型判断主被叫用户间的会话是否需进行编解码转换，在主叫用户支持的编解码类型与被叫用户支持的编解码类型不存在交集时，判断需进行编解码转换，指示编解码控制应用服务器进行编解码转换控制。

8、一种IP多媒体子系统，包括有互通边界控制功能实体，其特征在于，所述互通边界控制功能实体包括有：

预判处理单元，用于预判被叫用户支持的编解码类型；

媒体转换协商控制单元，用于控制协商主被叫用户分别支持的编解码类型；

媒体转换指示单元，将协商确定的主被叫用户分别支持的编解码类型通知媒体网关；

编解码转换判断处理单元，根据所述预判处理单元预判的被叫用户支持的编解码类型和主叫用户支持的编解码类型判断主被叫用户间的会话是否需进行编解码转换，在主叫用户支持的编解码类型与被叫用户支持的编解码类型不存在交集时，判断需进行编解码转换，指示所述媒体转换协商控制单元控制协商主被叫用户分别支持的编解码类型。

9、一种服务呼叫会话控制功能实体，其特征在于，包括有：

预判处理单元，用于预判被叫用户支持的编解码类型；

媒体转换协商控制单元，用于控制协商主被叫用户分别支持的编解码类型；

媒体转换指示单元，将协商确定的主被叫用户分别支持的编解码类型通知媒体网关；

编解码转换判断处理单元，根据所述预判处理单元预判的被叫用户支持的编解码类型和主叫用户支持的编解码类型判断主被叫用户间的会话是否需进行编解码转换，在主叫用户支持的编解码类型与被叫用户支持的编解码类型不存在交集时，判断需进行编解码转换，指示媒体转换协商控制单元控制协商主被叫用户分别支持的编解码类型。

10、根据权利要求9所述的服务呼叫会话控制功能实体，其特征在于，还包括：

消息解析处理单元，在所述编解码转换判断处理单元判断不需进行编解码转换，继续会话处理后，若收到被叫用户设备返回的被叫用户不支持主叫编解码类型消息，则指示媒体转换协商控制单元控制重新协商主被叫用户分别支持的编解码类型。

11、一种IP多媒体子系统，包括有服务呼叫会话控制功能实体，其特征在于，所述服务呼叫会话控制功能实体包括有：

预判处理单元，用于预判被叫用户支持的编解码类型；

媒体转换协商控制单元，用于控制协商主被叫用户分别支持的编解码类型；

媒体转换指示单元，将协商确定的主被叫用户分别支持的编解码类型通知媒体网关；

编解码转换判断处理单元，根据所述预判处理单元预判的被叫用户支持的编解码类型和主叫用户支持的编解码类型判断主被叫用户间的会话是否需进行编解码转换，在主叫用户支持的编解码类型与被叫用户支持的编解码类型不存在交集时，判断需进行编解码转换，指示媒体转换协商控制单元控制协商主被叫用户分别支持的编解码类型。

12、一种编解码转换控制方法，其特征在于，包括：

预判被叫用户支持的编解码类型；

根据预判的被叫用户支持的编解码类型和主叫用户支持的编解码类型判断主被叫用户间的会话是否需进行编解码转换；

若主叫用户支持的编解码类型与被叫用户支持的编解码类型存在交集，则判断不需进行编解码转换，继续会话处理；

若主叫用户支持的编解码类型与被叫用户支持的编解码类型不存在交集，则判断需进行编解码转换，控制协商主被叫用户分别支持的编解码类型，将协商确定的主被叫用户分别支持的编解码类型通知媒体网关。

13、根据权利要求12所述的编解码转换控制方法，其特征在于，所述预判被叫用户支持的编解码类型采用如下方式：

根据被叫用户所在网络类型判定被叫用户支持的编解码方式；或

根据被叫用户所在接入网络类型判定被叫用户支持的编解码方式；或

根据被叫用户的IP多媒体子系统注册信息判定被叫用户支持的编解码方式。

14、根据权利要求12所述的编解码转换控制方法，其特征在于，由服务呼叫会话控制功能实体预判被叫用户支持的编解码类型，由服务呼叫会话控制功能实体指示互通边界控制功能实体控制协商主被叫用户分别支持的编解码类型并将协商确定的主被叫用户分别支持的编解码类型通知媒体网关。

15、根据权利要求12所述的编解码转换控制方法，其特征在于，由服务呼叫会话控制功能实体预判被叫用户支持的编解码类型，由服务呼叫会话控制功能实体指示编解码控制应用服务器控制协商主被叫用户分别支持的编解码类型并将协商确定的主被叫用户分别支持的编解码类型通知媒体网关。

16、根据权利要求12所述的编解码转换控制方法，其特征在于，由互通边界控制功能实体预判被叫用户支持的编解码类型，由互通边界控制功能实体控制协商主被叫用户分别支持的编解码类型并将协商确定的主被叫用户分别支持的编解码类型通知媒体网关。

17、根据权利要求12所述的编解码转换控制方法，其特征在于，由服务呼叫会话控制功能实体预判被叫用户支持的编解码类型，由服务呼叫会话控制功能实体控制协商主被叫用户分别支持的编解码类型并将协商确定的主被叫用户分别支持的编解码类型通知媒体网关。

18、一种编解码类型协商控制方法，其特征在于，包括：

服务呼叫会话控制功能实体收到被叫用户设备返回的被叫用户不支持主叫编解码类型消息后，判断是否已经协商过主被叫用户分别支持的编解码类型，并在判断结果为否时，根据所述返回的消息中携带的被叫用户支持的编解码类型信息，控制重新协商主被叫用户分别支持的编解码类型并将重新协商确定的主被叫用户分别支持的编解码类型通知媒体网关。

19、一种编解码类型协商控制方法，其特征在于，包括：

服务呼叫会话控制功能实体收到被叫用户设备返回的被叫用户不支持主叫编解码类型消息后，判断是否已经协商过主被叫用户分别支持的编解码类型，并在判断结果为否时，根据所述返回的消息中携带的被叫用户支持的编解码类型信息，指示编解码控制器控制重新协商主被叫用户分别支持的编解码类型并将重新协商确定的主被叫用户分别支持的编解码类型通知媒体网关。

20、根据权利要求19所述的编解码类型协商控制方法，其特征在于，所述编解码控制器为互通边界控制功能实体或编解码控制应用服务器。

21、一种编解码类型协商控制方法，其特征在于，包括：

互通边界控制功能实体先后收到不同IMS网络返回的被叫用户不支持主叫编解码类型消息，根据所述消息携带的所述不同IMS网络支持的编解码类型交集信息，控制重新协商主被叫用户分别支持的编解码类型并将重新协商确定的主被叫用户分别支持的编解码类型通知媒体网关。

Images