CN101080097A - 一种实现多媒体呼叫业务的方法、系统及装置 - Google Patents

Abstract

本发明公开了一种在电路域中实现多媒体呼叫业务的方法、系统及装置，以缩短通过承载业务通道进行媒体协商，建立视频对话所需的时长。本发明方法包括：A.参与多媒体呼叫业务的各方通过呼叫控制信令通道进行多媒体呼叫业务类型和/或媒体的协商；B.根据所述协商结果，完成媒体流逻辑通道的建立，以实现多媒体呼叫业务。由于本发明基于带外协商，所以协商的开始时刻不受承载业务通道建立的约束，进而缩短建立视频对话过程的耗时。

Description

一种实现多媒体呼叫业务的方法、系统及装置

技术领域

本发明涉及无线通信领域，特别是涉及一种在电路域中实现多媒体呼叫业务的方法、系统及装置。

背景技术

移动电路域(CS DOMAIN)多媒体呼叫业务是第三代移动通信系统中的一项重要业务，是第三代移动通信区别于第二代的标志性业务之一。这种业务使得用户在进行语音通话的同时，还可以看到对方的图像，是一项有重要实际应用价值的业务。

WCDMA第三代移动通信定义了一套系统构架来完成各种业务，其中包括多媒体呼叫业务。此系统构架包含的基本网元为：用户设备UE，WCDMA系统基站NODE B，WCDMA系统基站控制器RNC，MGW和MSC SERVER，该系统构架的一种基本的组网关系参见图1所示。

UE：即用户使用的终端设备，常称为手机。

NODE B：主要负责无线信号收发。

RNC：主要负责无线接入网络的管理。

MGW：主要负责各种承载资源的管理，进行接网的实际操作。

MSC SERVER：是系统的核心，主要负责各种业务的逻辑控制，统一调度各种网络资源，生成通话记录。

a接口：空中接口信令通道。

b接口：业务数据通道。

c接口：媒体网关控制信令通道。

d接口：BICC/ISUP/SIP信令通道。

基于上述系统构架，WCDMA第三代移动通信系统提供了一种称作Multimedia call的多媒体呼叫业务(参见3GPP TS 24.008)，其实现构架示意图参见图2所示，这种业务不但可以完成语音呼叫功能和数据通讯功能，还可以完成多媒体呼叫功能。

为了实现多媒体呼叫业务需要用到以下信令和协议：

1、呼叫控制信令：分为两类，一类是终端与网络侧设备进行呼叫控制的空中接口信令，另一类是网络设备之间的呼叫控制信令(即中继信令)。它们都用于传递呼叫的发起、振铃、应答、拆线等消息，以及协商建立承载业务通道。

2、H.245多媒体通信控制协议：ITU-T制订的H.245协议定义了如何在单条业务数据通道内通过一系列协商，建立多条媒体流逻辑通道的过程；规定了终端能力协商过程(该过程进行后通讯双方就可以知道对方支持的媒体类型，如语音、视频，等)、主从判别(确定主从关系)、复用控制信息交互(为了支持在一条业务通道中同时传递多条媒体流)、打开与关闭媒体流逻辑通道等。

3、H.223低比特率多媒体通信复用协议：ITU-T制订的H.223协议使通信双方可以利用单个业务数据通道同时传输多条语音、视频和数据媒体流，它需要结合H.245协同操作。参见图3所示，为H.223的结构层次示意图，其应用层(也就是H.223的服务对象)是提供和接收各种语音、视频或数据的模块(比如：一个手机终端的麦克风，显示屏或摄像头)，最下层即物理层是一条业务数据通道，从图3可见，H.223支持利用单条物理业务通道传递多种媒体流。

4、3G-324M终端是3GPP定义的一种可用于多媒体呼叫业务的终端，参见图4所示，其主要包括三大部分：一是媒体处理模块，包括：语音、视频和数据处理部分；二是系统控制模块，它一方面负责与网络侧交互，进行呼叫控制，另一方面通过H.245协议与对端设备进行逻辑通道的建立与释放等操作；三是H.223协议处理模块，负责语音、视频、数据和H.245控制信息的复用与分解。

结合图2所示，所述3GPP TS 24.008提及的多媒体呼叫业务具有以下特点：

该业务中，网络的作用仅限于完成呼叫接续，以及为通讯双方建立一条承载业务通道，而不参与媒体流逻辑通道的建立；建立媒体流逻辑通道的操作由通讯双方在呼叫接通后，以带内端到端的方式完成。因此，建立视频对话的过程由两个阶段组成：第一阶段，完成呼叫发起、振铃及应答等的呼叫接续处理；当被叫应答后，网络将为呼叫双方用户间建立一条承载业务通道；第二阶段，呼叫双方用户通过各自的终端在已建立的承载业务通道内，按H.245规定的方式进行带内协商，在该承载业务通道内建立各种媒体流逻辑通道，以传递各语音、视频及数据媒体流，各媒体流在该承载业务通道内，按照H.223规定的复用方式进行传递。

由于现有方案以“带内端到端”的方式完成媒体协商，所以必须在承载业务通道建立后才能开始协商，导致在建立视频对话的过程中必然要经历上述两个阶段，这样使得建立视频对话的时间相对较长。与建立普通语音呼叫只需第一阶段即可完成相比，若完成第一阶段需要约6秒钟，完成第二阶段需要约5秒钟，那么从用户发起呼叫开始，要经过超过10秒钟才能与对方建立视频对话。由于现有方案建立视频对话的过程耗时长，因此该方案在此方面的用户体验较差。

而且，由于上述方案建立媒体流逻辑通道的过程完全是通讯双方在承载业务通道内，以“带内端到端”的方式完成的，所以网络侧MSC SERVER对承载业务通道内的媒体流逻辑通道的建立情况毫不知情，使得难以为多媒体呼叫增加一些附加功能。比如：呼叫建立过程中的媒体插入功能(当呼叫因拔错号、发生前转或要对主叫用户播放彩铃时，网络侧为主叫用户播放语音或视频提示)；通话过程中的媒体插入(当HOLD发生时，网络侧为被HOLD一方播放等待音或视频；或者在通话过程中的智能放音，其中包括余额提示、充值提示等)；以及一些呼叫完成类的补充业务。

这些业务已经在2G网络中普遍使用，3G网络作为一种更先进的网络，不应该不支持类似功能。由于现有WCDMA电路域的构架及多媒体呼叫业务实现方案的局限，使得目前3G网络无法实现一些需要网络侧设备参与的与媒体流处理相关的功能。

发明内容

本发明实施例提供一种在电路域中实现多媒体呼叫业务的方法、系统及装置，以缩短通过承载业务通道进行媒体协商，建立视频对话所需的时长。

本发明实施例的方法包括：A、参与多媒体呼叫业务的各方通过呼叫控制信令通道进行多媒体呼叫业务类型和/或媒体的协商；B、根据协商结果，完成媒体流逻辑通道的建立，以实现多媒体呼叫业务。

本发明实施例的实现多媒体呼叫业务的系统，包括：支持业务数据传输的MGW，所述系统还包括：MSC SERVER，其支持利用呼叫控制信令通道传递媒体流控制信息；参与多媒体呼叫业务的各方终端，其通过所述MSC SERVER，利用呼叫控制信令通道进行多媒体呼叫业务类型和/或媒体的协商，并通过所述MGW实现多媒体呼叫业务。

本发明实施例的移动交换中心服务器，具有控制呼叫接续的功能，包括：空中接口，用于传输与媒体流控制相关的信息；中继信令接口，用于传输与媒体流控制相关的信息；媒体网关控制接口，用于传递媒体流控制信息；媒体流控制模块，用于通过空中接口和中继信令接口参与多媒体呼叫业务类型和/或媒体的协商，以及通过媒体网关控制接口控制媒体流传输。

本发明实施例的终端，包括：封装单元，用于将媒体控制信息携带于呼叫建立信令中；或者按照空中接口信令规范封装多媒体呼叫业务类型和/或媒体的协商信息；或者将多媒体呼叫业务类型信息和/或媒体协商信息携带于UUS信令消息中；空中接口，用于将封装单元封装的信令消息向网络侧发送。

本发明实施例中，参与多媒体呼叫业务的各方通过呼叫接续时建立的呼叫控制信令通道(带外)进行媒体协商，而不再通过承载业务通道(带内)进行媒体协商，所以建立视频对话的过程不是必须经过现有方案的两个阶段，这样就为缩短建立视频对话的时间提供了条件。

附图说明

图1为现有WCDMA系统构架示意图；

图2为现有多媒体呼叫业务实现构架示意图；

图3为现有H.223的结构层次示意图；

图4为现有3G-324M终端结构示意图；

图5为本发明实施例的系统结构示意图；

图6为本发明实施例的终端结构示意图；

图7为本发明实施例的MSC服务器参与媒体协商和控制媒体流传输的实现构架示意图；

图8为本发明实施例的MSC服务器结构示意图；

图9为本发明实施例的方法步骤流程图；

图10为本发明实施例的主叫方在发起呼叫时进行媒体协商的流程图；

图11为本发明实施例的MSC服务器作为媒体协商的一方，参与媒体协商的实现构架示意图；

图12为本发明实施例的MSC服务器执行代理功能，以参与媒体协商的实现构架示意图；

图13为本发明实施例的MSC服务器作为媒体协商各方的透传网元，参与媒体协商的实现构架示意图；

图14为本发明实施例的建立了呼叫控制信令通道之后的任意时刻进行媒体协商的流程图；

图15为本发明实施例的互通实现构架示意图；

图16为方法实施例一的信令流程图；

图17为方法实施例二的信令流程图；

图18为方法实施例三的信令流程图；

图19为方法实施例三中，媒体流传输方式的实现构架示意图；

图20为方法实施例四中，媒体流传输方式的实现构架示意图；

图21为方法实施例五的信令流程图；

图22为方法实施例五中，媒体流传输方式的实现构架示意图；

图23为方法实施例六的信令流程图；

图24为方法实施例七的信令流程图。

具体实施方式

为了在呼叫控制信令通道中进行多媒体呼叫业务类型和/或媒体的协商，从而缩短建立多媒体通话所需的时长，本发明实施例提供了一种实现多媒体呼叫业务的系统，参见图5所示，其包括：MSC SERVER、MGW和参与多媒体呼叫业务的各方终端。

所述MSC SERVER，支持利用呼叫控制信令通道传递媒体流控制信息，并进行呼叫接续控制。

所述MGW，支持业务数据的传输。

所述终端，通过所述MSC SERVER，利用呼叫控制信令通道进行媒体协商，与其它通讯方建立媒体流通道用于多媒体通讯。

参见图6所示，所述终端(即本发明实施例的终端)中包括：相互连接的封装单元和空中接口。

所述封装单元，用于将媒体控制信息携带于呼叫建立信令中；或者按照空中接口信令规范封装多媒体呼叫业务类型和/或媒体的协商信息；或者将多媒体呼叫业务类型信息和/或媒体协商信息携带于UUS信令消息中。

所述空中接口，用于将封装单元封装的信令消息向网络侧发送。

为了使网络能够为用户提供与媒体流处理相关的附加功能，如：使3G网络可兼容2G网络中的媒体插入功能(失败放音、显示呼叫转移等功能)，参见图7所示(图7中空口即空中接口)，本发明实施例的系统包括的MSC SERVER还可参与媒体协商和控制媒体流传输，本发明实施例的系统包括的MGW还支持将多条单独媒体流合并到一条承载业务通道中传输，支持将复用流分解为各个单独媒体流，以及支持对各条媒体流进行接网处理。

参见图8所示，所述MSC SERVER(即本发明实施例的MSC SERVER)中包括：分别与媒体流控制模块相连的空中接口、中继信令接口和媒体网关控制接口。

所述空中接口用于与终端侧交互，所述中继信令接口用于与其它局的MSCSERVER交互，从而可将多媒体呼叫业务类型和/或媒体的协商相关的信令在主叫方与被叫方之间传送，并可使媒体流控制模块获知或参与交互多媒体呼叫业务类型和/或媒体的协商信息。所述多媒体呼叫业务类型信息可代表缺省的媒体流控制信息(至少包括以下信息之一：媒体流编解码方式、媒体流特定参数以及复用控制参数)。所述与媒体协商信息包括但不限于：携带有多媒体呼叫业务类型和/或媒体的协商信息的呼叫控制信令消息，以空中接口和中继信令接口信令规范定义的新的媒体协商消息，以及携带有媒体协商信令的UUS信令消息。

所述媒体流控制模块，用于通过媒体网关控制接口控制MGW，并根据媒体协商结果控制媒体流传输。

所述媒体网关控制接口，用于传输媒体流控制信息，以完成媒体流控制模块对媒体流的控制。

为了实现与现有技术的互通，所述MSC SERVER中还包括：识别模块，用于识别参与多媒体呼叫业务各方的类型是否相同，并使MSC SERVER根据识别结果，相应与各方进行多媒体呼叫业务类型和/或媒体的协商，并完成互通。

所述系统中的MSC SERVER与MGW可以合并，则所述媒体网关控制接口为内部接口；所述系统中的MSC SERVER与MGW可以分离(不限于一一对应)，则所述媒体网关控制接口为Mc接口。

应用上述系统和装置，本发明实施例提供了一种实现多媒体呼叫业务的方法，参见图9所示，包括下列主要步骤：

S1、参与多媒体呼叫业务的各方通过呼叫控制信令通道进行所述协商。

按照发起协商的时机，本发明实施例的方法可分为两种情况：

情况一：主叫方在发起呼叫时，在呼叫建立信令中携带进行所述协商所需的信息，即在建立呼叫控制信令通道的同时，向被叫方发起协商。

情况二：在建立了呼叫控制信令通道之后的任意时刻，主叫方和/或被叫方利用单独的媒体协商消息向对方进行协商。

若MSC SERVER参与协商，则上述两种情况中MSC SERVER均可作为协商的一方，或者执行代理功能，或者作为协商各方的透传网元。

S2、根据协商结果，完成媒体流逻辑通道的建立，以实现多媒体呼叫业务。

S3、主叫方、被叫方或网络拆除呼叫，网络释放为多媒体呼叫分配的各项资源，结束呼叫。

进一步，针对上述两种情况分别进行描述。

针对情况一：主叫方在发起呼叫时，在呼叫建立信令中携带进行协商所需的信息，以进行协商。参见图10所示，包括下列步骤：

101、主叫方发起多媒体呼叫。

本情况中只能由主叫方发起协商。

主叫方向被叫方发起多媒体呼叫，并在现有呼叫控制信令(呼叫建立信令)中携带进行协商所需的多媒体呼叫业务类型和/或媒体的相关信息，并向对方发送。

所述多媒体呼叫业务类型信息可代表缺省的媒体控制信息(至少包括以下信息之一：媒体流编解码方式、媒体流特定参数以及复用控制参数)。

所述媒体控制信息包括：复用控制参数(用于控制如何使用单条承载业务通道传递多条媒体流)及欲操作信息(即欲对媒体流进行什么样的操作)。其中，所述欲操作信息包括：新建媒体流信息、修改媒体流信息或关闭媒体流信息。

一般情况下，若欲操作信息为新建媒体流信息，则其中包括：流媒体的媒体类型(语音、视频或数据)、编解码方式、媒体流特定参数(如：视频幅面大小)和媒体流方向(前向或后向或双向)。

一般情况下，若欲操作信息为修改媒体流信息，则其中包括：需要修改的参数和媒体流的标识。

一般情况下，若欲操作信息为关闭媒体流信息，则其中包括：媒体流标识。

特殊情况下，依据通讯实体对多媒体呼叫中媒体流参数的预先隐式约定不同，需要显式传递的媒体流信息也不相同，被预先约定的信息不需要再显式传递给对方。(比如：若约定新建的媒体流必须采用固定的方向，则该类信息不需要显式传递，其它同理)。

102、MSC SERVER将呼叫接续至被叫方(MSC SERVER本身可作为被叫方)，同时进行多媒体呼叫业务类型和/或媒体的协商的处理。

若MSC SERVER不参与协商，则由主被叫双方通过呼叫控制信令通道进行协商；若MSC SERVER参与协商，则MSC SERVR在进行协商处理时，有以下方式：

a、参见图11所示(图11中空口即空中接口)，MSC SERVER可以作为协商的一方与对方进行协商(如：呼叫失败放音场景)。MSC SERVER通过呼叫控制信令通道与对方进行协商。

b、参见图12所示(图12中空口即空中接口)，MSC SERVER执行代理功能(如：多媒体彩铃场景、ECT场景)。MSC SERVER通过呼叫控制信令通道分别与各方进行协商。

c、参见图13所示(图13中空口即空中接口)，作为MSC SERVER执行代理功能的特殊情况，在无需插入附加功能的一般呼叫场景下，为了提高效率和节约网络资源，MSC SERVER不干预各方的协商过程，仅作为协商各方的透传网元。各方从呼叫控制信令通道，通过MSC SERVER透传协商信息进行协商，在各方进行协商的同时，MSC SERVER记录透传的协商信息；当需要插入附加功能时，MSC SERVER可根据记录的协商信息，转换到a或b的方式。

103、被叫方向MSC SERVER发送经被叫方确认的协商结果。

被叫方可利用振铃、呼叫进展或应答消息向MSC SERVER发送经被叫方确认的协商结果消息。

104、MSC SERVER向主叫方传递媒商结果。

105、完成媒体流逻辑通道的建立，以实现多媒体呼叫业务。

当MSC SERVER为通讯各方建立好承载业务通道后，相对于步骤102中MSC SERVR的不同处理方式，MSC SERVER在参与媒体流建立和拆除时也采用不同的处理方式。

对应于a：MSC SERVER控制MGW在承载业务通道中与对方建立媒体流逻辑通道(包括但不限于两条媒体流逻辑通道)；之后，MSC SERVER可控制MGW在所述媒体流逻辑通道上发送和/或接收媒体流。

对应于b：MSC SERVER控制MGW在承载业务通道中分别与各方建立媒体流逻辑通道；之后，将建立的各部分媒体流逻辑通道适配相连，以实现各方的媒体流交互。

对应于c：MSC SERVER控制MGW透传通讯各方之间的复用媒体流。并且，MSC SERVER可根据自身业务逻辑的需要，根据其记录的媒体流通道建立情况切换到上述a或b所述的处理方式。

106、作为可选步骤，当通讯各方存在对已经进行的媒体协商有更改的意愿时，可由一方向另一方发起新的协商过程，若媒体流已经被建立，则需要对媒体流按新的结果进行相应的修改。

针对情况二：在建立了呼叫控制信令通道之后的任意时刻，主叫方和/或被叫方利用单独的协商消息向对方进行协商。参见图14所示，包括下列步骤：

201、主叫方发起多媒体呼叫，以建立呼叫控制信令通道。

本步骤与现有的呼叫接续流程相同。

202、主叫方和/或被叫方利用单独的媒体协商消息向对方发起协商。

本情况中，由于主叫方和/或被叫方利用单独的协商消息携带进行协商所需的信息向对方发起协商，所以各方可在呼叫被除拆之前的任何时刻(包括：承载业务通道建立之前或之后)进行任意次的消息交互，因此不用等待有呼叫控制消息交互时才能进行协商，不受现有呼叫接续过程的影响。

所述单独的媒体协商消息可以是：

1、在呼叫控制信令通道中新定义所述单独的协商消息。

2、携带有媒体协商信息UUS信令消息。

由于单独的协商消息可容纳内容的长度有限，若单独的协商消息可容纳内容的长度不能携带一条完整的媒体协商信息，则协商信息将被分段携带于单独的协商消息中。并以所述单独的协商消息中的特定字节或位的取值(如：最后一个字节或位)，来标识本单独的协商消息是否携带有完整的协商信息(如：0表示需要分段，为1表示包含完成信令)。

为了保证协商信令接收的完整性，若以多条单独的媒体协商消息分段携带一条完整的协商信息，则按照分段顺序对协商信息片段进行编号。对方对接收到的信息片段进行编号连续性检查，发现不连续，则可丢弃相关的协商信息。

主叫方和/或被叫方通过相关信令向对方发送的媒体控制信息包括的内容，与情况一的步骤101中描述相同，形式上可采用H.245的规定。

203、MSC SERVER将相关信令路由至对方(MSC SERVER本身可作为协商的参与方)，同时进行协商的处理。

与情况一的步骤102中描述相同。

204、对方向MSC SERVER发送经确认的协商结果。

本情况中不受呼叫接续流程的限制，对方可在协商被发起后的任何时候利用单独的消息向MSC SERVER发送经确认的协商结果。

205、MSC SERVER向协商发起方传递媒体协商结果。

206、完成媒体流逻辑通道的建立，以实现多媒体呼叫业务。

当MSC SERVER为通讯各方建立好承载业务通道后，相对于步骤203中MSC SERVR的不同处理方式，MSC SERVER在参与媒体流建立和拆除时也采用不同的处理方式。相关内容与情况一的步骤105中描述相同。

207、作为可选步骤，当通讯各方存在对已经进行的媒体协商有更改的意愿时，可由一方向另一方发起新的媒体协商过程，若媒体流已经被建立，则需要对媒体流按新的结果进行相应的修改。

至此对通过呼叫控制信令通道(带外)进行所述协商来实现多媒体呼叫业务的过程概述完毕。

由于目前还存在不支持本发明实施例的终端和网络，为了兼顾这些终端和网络，本发明实施例还提出了互通方案，参见图15所示(图15中空口即空中接口)。

首先，MSC SERVER识别参与多媒体呼叫业务各方的类型，据此判断其是否都支持通过呼叫控制信令通道进行多媒体呼叫业务类型和/或媒体的协商。

其中，若参与多媒体呼叫业务各方是指参与多媒体呼叫业务的终端，则所述MSC SERVER采用以下方式之一识别参与多媒体呼叫业务各方的类型：

1、在终端注册到网络时，由该终端向网络指示其类型，并由所述MSCSERVER保存；

2、主叫终端通过呼叫建立信令向所述MSC SERVER指示其类型；被叫终端通过由被叫发往网络的消息(如寻呼响应消息)向所述MSC SERVER指示其类型；

3、所述MSC SERVER根据终端发送的信令携带的媒体控制信息识别其类型；

4、所述MSC SERVER通过classmark查询获得终端的类型(所述classmark查询机制，即在终端侧定义并保存终端的特征信息，其中包括该终端的类型，以备网络侧查询)。

其中，若参与多媒体呼叫业务各方是指与所述MSC SERVER所在网络相邻的网络，则通过在所述MSC SERVER所在网络进行数据配置来标明邻近网络的类型。

之后，所述MSC SERVER执行代理功能，按照参与多媒体呼叫业务各方的类型，分别与各方进行多媒体呼叫业务类型和/或媒体的协商，并进行承载互通。以下针对步骤S1中所述的两种情况，分别描述如何互通。

针对情况一需要从以下三个方面进行互通：

1、呼叫信令的互通：发起呼叫、振铃、应答以及拆线的接续过程相同，呼叫接续的过程可直接互通。但现有多媒体呼叫业务的呼叫建立信令中不含有媒体控制信息，与本发明实施例不同，因此需要MSC SERVER对两边的呼叫接续信令的内容进行适配，将信令发送到对方时，按对方的规范进行转换的处理。

2、承载的互通：都采用BS30作为承载媒体流的方式，可直接互通承载。

3、媒体流的互通：现有方案采用带内H.245信令作为管理媒体流的手段，是在呼叫应答后才开始媒体协商，而本发明实施例的方案在呼叫应答时可能已完成了媒体协商。无论是信令方式还是协商时机都不相同，需要在这两方面进行媒体流控制的互通。第一：媒体建立过程的互通。由于新(本发明实施例)终端或网络完成协商后，旧(现有)的终端或网络才开始协商，因此需要MSCSERVER分段处理两边的媒体流，一方面代理旧终端或网络，建立与新终端或网络间的媒体流，另一方面建立与旧终端或网络间的媒体流，最后将两边的媒体流适配相连，完成媒体流的互通。第二：媒体控制信令方式的互通。MSC服务器与新终端或网络将采用新信令方式进行协商，MSC SERVER与旧终端或网络将采用H.245的方式传递媒体流控制信息。

针对情况二需要从以下三个方面进行互通：

1、呼叫信令的互通：发起呼叫、振铃、应答以及拆线的呼叫过程相同，接续过程可直接互通。

2、承载的互通：都采用BS30作为承载媒体流的方式，可直接互通承载。

3、媒体流的互通：现有方案是在呼叫应答后才开始协商，本发明实施例的方案在被叫收到呼叫建立信令时就可开始协商。因此协商时机不相同，需要进行媒体流建立流程的互通。由于新终端或网络完成协商后，旧的终端或网络才开始协商，因此需要MSC SERVER分段处理两边的媒体流，一方面代理旧终端或网络建立与新终端或网络间的媒体流，另一方面建立与旧终端或网络间的媒体流，最后将两边的媒体流适配相连，完成媒体流的互通。

至此互通的过程概述完毕。

以下通过五个实施例具体描述。

方法实施例一：多媒体呼叫业务类型和/或媒体的协商与呼叫接续松散关联方案。该实例的呼叫场景为用户1与用户2进行可视电话呼叫，经过两个局，分别是MSC 1和MSC 2。参见图16所示，包括下列步骤：

1、用户1向的用户2发起多媒体呼叫，呼叫经MSC1和MSC2到达UE2。UE2判断SETUP消息中的业务类型为多媒体呼叫，于是并发进行下面两个操作。

2、并发操作一是处理在用户间进行媒体流逻辑通道的协商过程，MSC可选择作为媒体协商一方、执行代理功能和作为透传网元之一，参与该过程。

3、并发操作二是继续进行呼叫接续，完成振铃和应答处理，当应答时，网络完成建立UE1与UE2间的双向的承载业务数据通道。此时，若MSC选择执行代理功能，则由MSC SERVER控制MGW与相邻的终端或MGW在承载业务数据通道中实际建立媒体流逻辑通道。若MSC选择作为透传网元，则由UE1与UE2在承载业务通道中实际建立媒体流逻辑通道。

4、当步骤2和步骤3步都完成后，用户进入通话状态，最后当呼叫结束时，进行拆线处理。

说明1：若运营商需要按用户间建立的媒体流的类型或条数对用户进行计费，那么MSC SERVER可根据媒体协商过程感知到用户间建立的媒体流的类型或条数，从而实现这一需求。

说明2：若主叫用户发起呼叫时拔打号码的是一个不存在的号码，主叫所在的MSC可以对主叫进行语音或视频提示，MSC将选择作为媒体协商一方，由MSC与主叫终端进行媒体流的协商及建立，当建立好媒体流逻辑通道后，MSC可对主叫用户进行语音或视频提示。

说明3：取漫游号码过程省略未画。

方法实施例二：实例一的优化，即简化的媒体流逻辑通道建立过程。该实施例的呼叫场景：用户1向用户2发起可视电话呼叫，经过两个局，分别是MSC 1和MSC 2。

另外，两个用户的终端经过一定的规范化，可以有选择性的制订以下规则：

1、终端有相同的能力，免去在呼叫时交换能力信息。

2、主从关系由以固定的方式确定，比如确定主叫方从为主控方，免去在呼叫时确定主从关系。

3、终端采用相同复用表，免去在呼叫时交互复用表信息。

基于上述制订的规则，有利于进一步减少从发起呼叫到建立视频对话的总时间。

参见图17所示，本实例的主要步骤基本与实例一相同。

方法实施例三：多媒体呼叫业务类型和/或媒体的协商与呼叫接续强关联方案之一。该实施例的呼叫场景：用户1向用户2发起可视电话呼叫，经过两个局，分别是MSC 1和MSC 2。

本实例对可视电话进行规范化：

1、可视电话由一路语音、一路视频以及一路数据(可选)组成。

2、语音和视频的编解码有多种选择，需要在业务进行过程中协商使得各网元取得一致。

3、复用表由主叫终端确定，复用表除了具有H.223复用表的功能外，还增加域指明表中哪个表项用于传递语音、哪个表项用于传递视频以及哪个表项传递数据，并经沿途各局发送给被叫终端。(若再规定一个标准的复用表，则可免去在呼叫时传递复用表的操作，本实施例选择传递复用表)

参见图18所示，包括下列主要步骤：

1、用户1向用户2发起多媒体呼叫，呼叫经MSC1和MSC2到达UE2。UE1发起呼叫时，在SETUP消息中指明业务类型为多媒体呼叫业务，同时带上复用表信息，使得双方能够利用单条业务通道同时传递多条媒体流，SETUP消息还带上主叫UE支持的语音和视频编解列表，供被叫方选择，以进行编解码的协商。

2、被叫终端UE2接收到呼叫后，在SETUP消息中携带的主叫方支持的语音和视频编解码中进行选择，将结果放入发往主叫UE的ALERTING消息中，同时向被叫用户发出振铃提示。

3、当被叫应答并且UE1与MSC1、MSC1与MSC2以及MSC2与UE2的业务通道都建立完毕，主叫被叫UE1就能根据协商好的语音和视频编解码以及复用表建立起媒体流逻辑通道，以传递语音、视频以及数据(可选)。

媒体流传输的方式，参见图19所示。网络侧的媒体网关仅透明传输媒体流即可。(说明：取漫游号码过程省略未画)

方法实施例四：多媒体呼叫业务类型和/或媒体的协商与呼叫接续强关联方案之二。该实施例的呼叫场景：用户1向用户2发起可视电话呼叫，经过两个局，分别是MSC 1和MSC 2。该实例与实例三的控制流程相同，不同在于逻辑通道的建立方式，本实例采用分段建立方式：UE1与MSC1，MSC1与MSC2以及MSC2与UE2分段建立媒体流逻辑通道，参见图20所示。

方法实施例五：多媒体呼叫业务类型和/或媒体的协商与呼叫接续强关联方案之三。该实施例的呼叫场景：用户2签约有无应答前转业务，用户1向用户2发起可视电话呼叫，经过两个局，分别是MSC 1和MSC 2，用户2未应答，超时后该呼叫被前转到用户3。参见图21所示，包括下列主要步骤：

1和2、UE1与UE2间建立可视电话的过程同实例三。

3、UE2未接听该电话，由于UE2签约有无应答前转业务，MSC SERVER2无应答超时后，MSC2将呼叫向UE3(前转目的方)进行转接。由于在步骤1和步骤2中UE1的语音、视频编解码以及复用表都已经确立，因此在呼叫被转移到UE3后，则需要将媒体流处理分为两段来处理，一段是UE1与MSC2间的，另一段是MSC2与UE3间的。参见图22所示，MSC2需要对两段媒体流逻辑通道进行适配，首先要将两侧业务通道中的媒体流逻辑通道分解出来，然后进行媒体流逻辑通道适配连接。(说明：取漫游号码过程省略未画)

4、UE3应答，UE1与UE3间的承载双向接通，UE1与UE3的在此承载通道中进行各媒体流数据的传送。通话结束时拆除呼叫相关的信令与承载。

方法实施例六：多媒体呼叫业务类型和/或媒体的协商与呼叫接续强关联方案之四。该实施例的呼叫场景：用户1向用户2发起可视电话呼叫，经过两个局，分别是MSC 1和MSC 2。

本实施例用可视电话业务类型信息来代表缺省的媒体参数，在实体间只传递可视电话业务类型信息，各实体根据该业务类型信息控制各自媒体处理单元按缺省的媒体参数控制媒体流。参见图23所示，包括下列主要步骤：

1、用户1向用户2发起可视电话呼叫，呼叫经MSC1和MSC2到达UE2。UE1发起呼叫时，在SETUP消息中指明业务类型为可视电话呼叫业务。该业务类型向沿途各实体表明了所要建立的媒体流信息。比如是要建立两条双向媒体流，一条是语音流，编解码为AMR，一条是视频流，编解码是H.263，分辨率为128*96。该可视电话业务类型可以是的新定义的业务码，并列于3GPP TS22.003中定义的“speech”，或者是对BS30业务进行补充说明，在兼容性信息中说明该业务是可视电话业务：

2、被叫终端UE2接收到呼叫后，振铃，向主叫方回振铃消息。UE1、UE2按第1步中所示的业务类型信息所代表的媒体流参数控制媒体处理单元准备建立相应的媒体流。

3、被叫UE2应答，UE1与UE2间的承载双向接通，UE1与UE2的在此承载通道中进行各媒体流数据的传送。通话结束时拆除呼叫相关的信令与承载。

说明1：媒体流传输的方式：网络侧的媒体网关可透明传输媒体流。

说明2：UE1控制其媒体处理单元准备建立媒体流的操作可以开始于呼叫发起时。

说明3：UE2控制其媒体处理单元准备建立媒体流的操作可以开始于UE2接收到呼叫建立请求时。

说明4：取漫游号码过程省略未画。

方法实施例七：多媒体呼叫业务类型和/或媒体的协商与呼叫接续强关联方案之五(与旧网络的互通)。该实施例的呼叫场景：用户1向用户2发起可视电话呼叫，经过两个局，分别是MSC 1和MSC 2，MSC 2是一个不支持新可视电话的旧局。

本实施例用可视电话业务类型信息来代表缺省媒体参数，在实体间只传递可视电话业务类型信息，各实体根据该业务类型信息控制各自媒体处理单元按缺省的媒体参数控制媒体流。参见图24所示，包括下列主要步骤：

1、用户1向用户2发起多媒体呼叫，呼叫经MSC1和MSC2到达UE2。UE1发起呼叫时，在SETUP消息中指明业务类型为可视电话呼叫业务，该业务类型向沿途各实体表明所要建立的媒体流信息。比如要建立两条媒体流，一条是语音流，编解码为AMR，一条是视频流，编解码是H.263，分辨率为128*96。

2、MSC1收到呼叫后，通过配置发现呼叫的下一跳MSC2是一个不支持新可视电话业务的局。

3、MSC1启动新网络MSC1与旧网络MSC2间的互通操作。体现为：一方面以旧的多媒体呼叫方面向MSC2发起呼叫，另一方面，MSC1通过其与MGW1间的Mc接口、MGW1与MGW2间的承载通道以及MGW2与UE2间的承载通道按H.245信令方式开始进行媒体流的协商，建立MGW1与UE2间的媒体流通道，并将该通道与MGW1与UE1间的相应媒体流通道接网。使得UE1与UE2可以进行可视电话。

说明1：若省去本实施例中的MSC2与MGW2，并将第2步改为“MSC 1发现UE2为一不支持新可视电话的旧终端。具体可体现为UE2在寻呼响应时未携带其是一个支持新可视电话的新终端的信息”。则可体现新网络MSC1与旧终端UE2是的互通处理过程。

说明2：取漫游号码过程省略未画。

说明3：第3步中，MSC1也可以等到对方回接通消息时才开始利用H.245与对端建立媒体流通道的过程。

综上所述，本发明实施例中，参与多媒体呼叫业务的各方通过呼叫接续时建立的呼叫控制信令通道(带外)进行媒体协商，而不再通过承载业务通道(带内)进行媒体协商，所以建立视频对话的过程不是必须经过现有方案的两个阶段，这样就为缩短建立视频对话的时间提供了条件。本发明实施例可在承载业务通道建立之前，通过呼叫控制信令通道完成多媒体呼叫业务类型和/或媒体的协商，从而缩短建立视频对话的时间。

同时，从实现的角度看，本发明实施例提供了另一种多媒体呼叫业务类型和/或媒体的协商途径，使得协商方式更加多样和灵活。

进一步，基于本发明实施例的带外媒体协商，本发明实施例还可使MSCSERVER作为媒体协商的一方，或者作为媒体协商各方的代理，或者作为媒体协商各方的透传网元，通过呼叫控制信令通道参与媒体协商。从而使MSCSERVER在各方媒体协商的过程中获知媒体流逻辑通道的建立情况，进而可以控制MGW对媒体流逻辑通道中传输的媒体流进行管理，插入一些附加功能，可兼容2G网络中普遍使用的业务；也为按媒体成分计费等附加功能提供了一个可行的基本构架。

又进一步，为了兼顾现有的终端和网络，本发明实施例还提供了互通方案。由MSC SERVER作为媒体协商各方的代理，分别与各方进行媒体协商，并完成互通。

本发明不局限于WCDMA系统，也适用于其他支持多媒体呼叫业务的通信系统。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (26)

1、一种实现多媒体呼叫业务的方法，其特征在于，包括下列步骤：

A、参与多媒体呼叫业务的各方通过呼叫控制信令通道进行多媒体呼叫业务类型和/或媒体的协商；

B、根据协商结果，完成媒体流逻辑通道的建立，以实现多媒体呼叫业务。

2、如权利要求1所述的方法，其特征在于，所述步骤A中，参与多媒体呼叫业务的各方在承载业务通道建立之前或之后，完成协商。

3、如权利要求1所述的方法，其特征在于，所述步骤A中，包括下列步骤：

主叫方在发起呼叫时，在呼叫建立信令中携带进行协商所需的多媒体呼叫业务类型信息和/或媒体控制信息，发送给被叫方。

4、如权利要求1所述的方法，其特征在于，所述步骤A中，主叫方或被叫方利用单独的协商消息向对方发起多媒体呼叫业务类型和/或媒体的协商。

5、如权利要求4所述的方法，其特征在于，所述单独的协商消息为呼叫控制信令通道中新定义的呼叫控制信令。

6、如权利要求4所述的方法，其特征在于，所述单独的协商消息中未携带媒体协商信息，则以该单独的协商消息携带的多媒体呼叫业务类型信息代表缺省的媒体协商信息。

7、如权利要求1至6任一项所述的方法，其特征在于，所述步骤A中，参与多媒体呼叫业务的各方以端到端的方式，通过呼叫控制信令通道进行所述协商。

8、如权利要求1至6任一项所述的方法，其特征在于，所述步骤A中，移动交换中心服务器MSC SERVER通过呼叫控制信令通道参与多媒体呼叫业务的所述协商。

9、如权利要求8所述的方法，其特征在于，MSC SERVER作为所述协商的一方参与协商，则所述步骤B包括下列步骤：

B11、MSC SERVER根据所述协商结果，控制媒体网关MGW在呼叫接续时建立的承载业务通道中与对方建立媒体流逻辑通道；

B12、MSC SERVER在所述媒体流逻辑通道上发送和/或接收媒体流。

10、如权利要求8所述的方法，其特征在于，MSC SERVER作为协商各方的代理，则所述步骤B包括下列步骤：

B21、MSC SERVER根据所述协商结果，控制MGW在呼叫接续时建立的承载业务通道中分别与各方建立媒体流逻辑通道；

B22、将建立的各部分媒体流逻辑通道适配相连，以实现各方的媒体流交互。

11、如权利要求8所述的方法，其特征在于，MSC SERVER作为协商各方的透传网元，则其记录透传的多媒体呼叫业务类型和/或媒体的协商信息；所述步骤B包括下列步骤：

B31、各方根据所述协商结果，在呼叫接续时建立的载业务通道中建立媒体流逻辑通道，用以通过MGW透传媒体流；

B32、MSC SERVER根据记录的多媒体呼叫业务类型和/或媒体的协商信息，控制所述媒体流逻辑通道中传输的流媒体。

12、如权利要求8所述的方法，其特征在于，在步骤A之前，所述MSCSERVER先识别参与多媒体呼叫业务各方的类型，据此判断其是否都支持通过呼叫控制信令通道进行所述协商，若是，则进行步骤A；

否则，所述MSC SERVER执行代理功能，按照参与多媒体呼叫业务各方的类型，分别与各方进行协商，并进行承载互通。

13、如权利要求12所述的方法，其特征在于，所述参与多媒体呼叫业务各方是指参与多媒体呼叫业务的终端，或者是指与所述MSC SERVER所在网络相邻的网络。

14、如权利要求13所述的方法，其特征在于，参与多媒体呼叫业务各方是指参与多媒体呼叫业务的终端，则所述MSC SERVER采用以下方式之一识别参与多媒体呼叫业务各方的类型：

方式一：在终端注册到网络时，由该终端向网络指示其类型，并由所述MSC SERVER保存；

方式二：主叫终端通过呼叫建立信令向所述MSC SERVER指示其类型；被叫终端通过呼叫应答信令向所述MSC SERVER指示其类型；

方式三：所述MSC SERVER根据终端发送的信令携带的媒体控制信息识别其类型；

方式四：所述MSC SERVER向终端查询该终端的类型。

15、如权利要求13所述的方法，其特征在于，参与多媒体呼叫业务各方是指与所述MSC SERVER所在网络相邻的网络，则通过在所述MSC SERVER所在网络进行数据配置来标明邻近网络的类型。

16、一种实现多媒体呼叫业务的系统，包括：支持业务数据传输的MGW，其特征在于，所述系统还包括：

MSC SERVER，其支持利用呼叫控制信令通道传递媒体流控制信息；

参与多媒体呼叫业务的各方终端，其通过所述MSC SERVER，利用呼叫控制信令通道进行多媒体呼叫业务类型和/或媒体的协商，并通过所述MGW实现多媒体呼叫业务。

17、如权利要求16所述的系统，其特征在于，所述MSC SERVER还用于参与所述协商和控制媒体流传输。

18、如权利要求17所述的系统，其特征在于，所述终端与MSC SERVER之间的空中接口支持传输携带有媒体控制信息的呼叫建立信令；或者支持传输新定义的单独的协商消息；或者支持传输携带有协商信息的UUS信令消息。

19、如权利要求17所述的系统，其特征在于，所述MSC SERVER与其它局MSC SERVER之间的中继信令接口支持传输多媒体呼叫业务类型和/或携带有媒体控制信息的呼叫建立信令；或者支持新定义的单独的协商消息；或者支持传输携带有协商信息的UUS信令消息。

20、如权利要求17所述的系统，其特征在于，所述MSC SERVER与MGW之间的媒体网关控制接口用于传递媒体流控制信息。

21、如权利要求20所述的系统，其特征在于，在系统中MSC SERVER与MGW合并，则所述媒体网关控制接口作为内部接口传递媒体流控制信息；

在系统中MSC SERVER与MGW分离，则所述媒体网关控制接口作为Mc接口传递媒体流控制信息。

22、如权利要求16至21任一项所述的系统，其特征在于，所述MSCSERVER还用于识别参与多媒体呼叫业务各方的类型是否相同，并根据识别结果，相应与各方进行多媒体呼叫业务类型和/或媒体的协商，并完成互通。

23、一种移动交换中心服务器，具有控制呼叫接续的功能，其特征在于，包括：

空中接口，用于传输与媒体流控制相关的信息；

中继信令接口，用于传输与媒体流控制相关的信息；

媒体网关控制接口，用于传递媒体流控制信息；

媒体流控制模块，用于通过空中接口和中继信令接口参与多媒体呼叫业务类型和/或媒体的协商，以及通过媒体网关控制接口控制媒体流传输。

24、如权利要求23所述的服务器，其特征在于，所述与媒体流控制相关的信息包括：携带有所述协商相关信息的呼叫建立信令，以相应接口信令规范定义的新的协商消息，以及携带有多媒体呼叫业务类型和/或媒体的协商信息的UUS信令消息。

25、如权利要求23或24所述的服务器，其特征在于，所述服务器还包括：

识别模块，用于识别参与多媒体呼叫业务各方的类型是否相同，并使服务器根据识别结果，相应与各方进行协商，并完成互通。

26、一种终端，其特征在于，包括：

封装单元，用于将媒体控制信息携带于呼叫建立信令中；或者按照空中接口信令规范封装多媒体呼叫业务类型和/或媒体的协商信息；或者将多媒体呼叫业务类型信息和/或媒体协商信息携带于UUS信令消息中；

空中接口，用于将封装单元封装的信令消息向网络侧发送。

Images