CN101795330A - 在通话期间播放多媒体铃音的方法、服务器及终端设备 - Google Patents

Abstract

本发明实施例提供一种在通话期间播放多媒体铃音的方法、服务器及终端设备，所述方法包括：接收主叫终端或被叫终端发送的请求标志；根据所述请求标志触发在通话期间继续播放多媒体铃音。通过本发明实施例的在通话期间继续播放多媒体铃音的方法、服务器及终端设备，解决了现有技术方案中无法实现多媒体铃音在通话期间为用户继续播放的问题。

Description

在通话期间播放多媒体铃音的方法、服务器及终端设备

技术领域

本发明涉及多媒体铃音，尤其涉及在通话期间继续播放多媒体铃音的方法、服务器及终端设备。

背景技术

当前，多媒体铃音业务主要包括：多媒体回铃音、多媒体振铃音、多媒体背景音。多媒体回铃音(Customized Alerting Tone，CAT)又称为多媒体彩铃，即主叫拨打被叫时，在被叫摘机接听之前，主叫欣赏到多媒体回铃音。多媒体振铃音(Customized Ringing Signal，CRS)又称为多媒体彩振，即主叫拨打被叫时，在被叫摘机接听之前，被叫欣赏到多媒体振铃音。多媒体背景音(Customized Background Tone，CBT)又称为多媒体彩像，即主叫和被叫通话过程中，主被叫双方都能欣赏到多媒体背景音。而多媒体铃音的内容可以是音乐、视频、图片、文字、电子名片、甚至用户自己上传的音视频片段等各种形式的媒体内容。

发明人在实现本发明的过程中，发现，对于多媒体振铃音(CRS)业务来说，现有技术中，主叫用户呼叫被叫用户时，被叫用户会收到彩振服务器下发的CRS，当被叫用户摘机应答后，彩振服务器会停止播放CRS，从而进入正常通话阶段；对于多媒体回铃音(CAT)业务来说，现有技术中，主叫用户呼叫被叫用户时，主叫用户会收到彩铃服务器下发的CAT，当被叫用户摘机应答后，彩铃服务器会停止播放CAT，从而进入正常通话阶段。因此，现有技术方案中无法在通话期间为用户继续播放多媒体铃音。

发明内容

本发明实施例的主要目的在于提供一种在通话期间继续播放多媒体铃音的方法、服务器及终端设备，以解决现有技术方案中无法实现多媒体铃音在通话期间为用户继续播放的问题。

一方面、提供一种在通话期间播放多媒体铃音的方法，所述方法包括：分别向主叫终端和被叫终端发送会话更新请求以分别与主叫终端和被叫终端建立会话；当接收到所述被叫终端的摘机消息时，指示媒体资源功能执行混音处理，继续为主叫终端或被叫终端中至少一方播放多媒体铃音。

另一方面、提供另一种在通话期间播放多媒体铃音的方法，所述方法包括；接收主叫终端发来的携带会话请求的呼叫请求消息，将所述会话请求替换为媒体资源功能会话请求，然后发送给被叫终端；向主叫终端发送携带媒体资源功能会话请求的更新消息；为主叫终端或被叫终端中至少一方播放多媒体铃音；当接收到所述被叫终端的摘机消息时，指示媒体资源功能执行混音处理，继续主叫终端或被叫终端中至少一方播放多媒体铃音。

另一方面、提供另一种在通话期间播放多媒体铃音的方法，所述方法包括；向主叫终端或被叫终端中至少一方发送多媒体铃音会话请求，使接收到所述多媒体铃音会话请求的主叫终端或被叫终端中的一方或双方预留通话媒体资源、多媒体铃音资源和用于混音的资源；

当接收到所述被叫终端的摘机消息时，指示媒体资源功能继续为主叫终端或被叫终端中至少一方播放多媒体铃音，使主叫终端或被叫终端中的一方或双方在接收到媒体流时开始执行对通话媒体流和多媒体铃音媒体流的混音处理。

另一方面、提供另一种在通话期间播放多媒体铃音的方法，所述方法包括；

当接收到多媒体铃音服务器发送的多媒体铃音会话请求后，预留通话媒体资源、多媒体铃音资源和用于混音的资源；返回多媒体铃音会话应答；建立通话后，对接收到的通话媒体流和多媒体铃音媒体流进行混音。

一方面、提供一种多媒体铃音服务器，所述服务器包括：

会话更新请求发送模块：用于分别向主叫终端和被叫终端发送会话更新请求以分别与主叫终端和被叫终端建立会话；

指示播放模块：用于当接收到所述被叫终端的摘机消息时，指示媒体资源功能执行混音处理，继续为主叫终端或被叫终端中至少一方播放多媒体铃音。

另一方面、提供另一种多媒体铃音服务器，所述服务器包括：

呼叫请求消息接收模块：用于接收主叫终端发来的携带会话请求的呼叫请求消息，将所述会话请求替换为媒体资源功能会话请求，然后发送给被叫终端；

更新消息发送模块：用于向主叫终端发送携带媒体资源功能会话请求的更新消息；

多媒体铃音播放模块：用于为主叫终端或被叫终端中至少一方播放多媒体铃音；

指示混音模块：用于当接收到所述被叫终端的摘机消息时，指示媒体资源功能执行混音处理，继续主叫终端或被叫终端中至少一方播放多媒体铃音。

另一方面、提供另一种多媒体铃音服务器，所述服务器包括：

多媒体铃音会话请求发送模块：用于向主叫终端或被叫终端中至少一方发送多媒体铃音会话请求，使接收到所述多媒体铃音会话请求的主叫终端或被叫终端中的一方或双方预留通话媒体资源、多媒体铃音资源和用于混音的资源；

指示混音处理模块：用于当接收到所述被叫终端的摘机消息时，指示媒体资源功能继续为主叫终端或被叫终端中至少一方播放多媒体铃音，使主叫终端或被叫终端中的一方或双方在接收到媒体流时开始执行对通话媒体流和多媒体铃音媒体流的混音处理。

另一方面、提供一种终端，所述终端包括：

预留资源模块：用于当接收到多媒体铃音服务器发送的多媒体铃音会话请求后，预留通话媒体资源、多媒体铃音资源和用于混音的资源；

应答模块：用于返回多媒体铃音会话应答；

混音模块：用于建立通话后，对接收到的通话媒体流和多媒体铃音媒体流进行混音。

通过本发明实施例的在通话期间继续播放多媒体铃音的方法、服务器及终端，解决了现有技术方案中无法实现多媒体铃音在通话期间为用户继续播放的问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，并不构成对本发明的限定。在附图中：

图1为本发明实施例的方法流程图；

图2为本发明一实施例的组网结构示意图；

图3为图2所示实施例的一交互流程图；

图4为图2所示实施例的另一交互流程图；

图5为图2所示实施例的另一交互流程图；

图6为图2所示实施例的另一交互流程图；

图7为本发明另一实施例的组网结构示意图；

图8为图7所示实施例的交互流程图；

图9为本发明实施例的铃音服务器组成框图；

图10为本发明另一实施例的方法流程图；

图11为本发明实施例的终端设备组成框图；

图12为本发明实施例十一的交互流程图；

图13为本发明实施例十二的交互流程图；

图14为本发明实施例十三的交互流程图；

图15为本发明实施例十四的方法示意图；

图16为本发明实施例十五的方法示意图；

图17为本发明实施例十六的方法示意图；

图18为本发明实施例十七的方法示意图；

图19为本发明实施例十八的多媒体铃音服务器示意图；

图20为本发明实施例十八的另一多媒体铃音服务器示意图；

图21为本发明实施例十八的另一多媒体铃音服务器示意图；

图22为本发明实施例十九的终端示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚明白，下面结合实施例和附图，对本发明实施例做进一步详细说明。在此，本发明的示意性实施例及其说明用于解释本发明，但并不作为对本发明的限定。

实施例一

本发明实施例提供一种在通话期间播放多媒体铃音的方法，以下结合附图对本实施例进行详细说明。

图1为本发明实施例的方法流程图，请参照图1，本发明实施例的方法主要包括：

101：接收主叫终端或被叫终端发送的请求标志；

102：根据所述请求标志触发在通话期间继续播放多媒体铃音。

通过本发明实施例的在通话期间继续播放多媒体铃音的方法，可以实现在通话期间为主叫终端或被叫终端继续播放多媒体铃音。

实施例二

本发明实施例还提供一种在通话期间播放多媒体铃音的方法，以下结合附图对本实施例进行详细说明。

图1为本发明实施例的方法流程图，请参照图1，本发明实施例的方法主要包括：

步骤101：接收主叫终端或被叫终端发送的请求标志；

在本实施例中，被叫终端发送的请求标志可以通过IMS域的摘机应答消息200OK消息，或者在摘机应答消息之后以INFO消息或MESSAGE消息的头域或消息体携带；或者通过CS域的UUI消息、或者FACILITY消息携带，或者通过DTMF(双音多频)方式携带；或者通过带外方式或离线方式从被叫获取该请求标志，本发明实施例并不以此作为限制。

在本实施例中，请求标志可以是多媒体振铃音混频标志，以请求服务器对多媒体振铃音和主叫终端到被叫终端的通话媒体流进行混频操作，这种情况下，只有被叫终端能在通话过程中听到多媒体振铃音。

在本实施例中，请求标志可以是多媒体回铃音混频标志，以请求服务器对多媒体回铃音和被叫终端到主叫终端的通话媒体流进行混频操作，这种情况下，只有主叫终端能在通话过程中听到多媒体回铃音。

在本实施例中，请求标志也可以是多媒体背景音混频标志，以请求服务器对多媒体振铃音或多媒体回铃音和主叫终端与被叫终端之间的通话媒体流进行混频操作，这种情况下，主叫终端和被叫终端都能在通话过程中听到多媒体振铃音或多媒体回铃音，此时多媒体振铃音或多媒体回铃音充当一个多媒体背景音的工作。

在本实施例中，请求标志也可以是多媒体铃音链接下载标志，以请求服务器下发多媒体铃音的链接，以供主叫终端或被叫终端下载该多媒体铃音后，在通话过程中进行本地播放。

在本实施例中，请求标志还可以是终端混频能力标志，以请求服务器端不必停止多媒体铃音的播放，以在主叫终端或被叫终端对多媒体铃音和通话媒体流进行混频后进行本地播放，这种情况下，主叫终端或被叫终端需要具备混频能力。

步骤102：根据所述请求标志触发在通话期间继续播放多媒体铃音。

在本实施例中，如果接收到的请求标志为多媒体振铃音混频标志，则根据所述请求标志触发在通话期间继续播放多媒体铃音的步骤为：

向媒体资源功能实体发送携带有多媒体振铃音混频标志的指示消息，指示媒体资源功能实体对多媒体振铃音和主叫终端到被叫终端的通话媒体流进行混音/混频。

在本实施例中，如果接收到的请求标志为多媒体回铃音混频标志，则根据所述请求标志触发在通话期间继续播放多媒体铃音的步骤为：

向媒体资源功能实体发送携带有多媒体回铃音混频标志的指示消息，指示媒体资源功能实体对多媒体回铃音和被叫终端到主叫终端的通话媒体流进行混音/混频。

在本实施例中，如果接收到的请求标志为多媒体背景音混频标志，则根据请求标志触发在通话期间继续播放多媒体铃音的步骤为：

向媒体资源功能实体发送携带有多媒体背景音混频标志的指示消息，指示媒体资源功能实体对多媒体振铃音或多媒体回铃音和主叫终端与被叫终端之间的通话媒体流进行混音/混频。

根据本实施例，如果指示消息为指示对多媒体振铃音或多媒体回铃音和主叫终端与被叫终端之间的通话媒体流进行混音/混频，则意味着要将多媒体振铃音或多媒体回铃音转换为背景音，因此，在本实施例的方法中，还要包括下列与主叫终端和被叫终端协商多媒体背景音的步骤：

向主叫终端和被叫终端发送多媒体背景音请求，协商多媒体背景音会话；

接收主叫终端和被叫终端对所述多媒体背景音请求的应答消息。

在本实施例中，多媒体背景音请求可以通过re-INVITE消息传递，也可以通过REFER消息传递，本实施例并不以此作为限制。

根据本实施例的方法，在主叫终端和被叫终端通话过程中，主叫终端或者被叫终端或者主叫终端和被叫终端可以继续听到多媒体铃音，由于该多媒体铃音是由服务器端在通话过程中对多媒体振铃音或多媒体回铃音和通话媒体流混频后播放，因此，在主叫终端或被叫终端挂机后，本实施例的方法还包括下列步骤：

在接收到挂机消息后，向媒体资源功能实体发送停止消息，指示媒体资源功能实体停止混音/混频操作及停止播放多媒体铃音；

接收媒体资源功能实体返回的停止确认消息，确认停止混音/混频操作及停止播放多媒体铃音。

在本实施例中，在IMS域中，该挂机消息可以是BYE消息；在CS域中，该挂机消息可以是disconnect消息。

在本实施例中，如果接收到的请求标志为多媒体铃音链接下载标志，则根据所述请求标志触发在通话期间继续播放多媒体铃音的步骤包括：

向媒体资源功能实体发送携带有多媒体铃音链接下载标志的指示消息，指示媒体资源功能实体发送多媒体铃音链接；

接收媒体资源功能实体返回的包含多媒体铃音链接的对所述指示消息的应答消息。

根据本实施例，在接收到主叫终端对摘机应答消息的确认消息后，即可发送携带有多媒体铃音链接的确认消息到请求终端，请求终端获取了多媒体铃音下载链接，下载该多媒体铃音后，即可以进行本地播放。

在本实施例中，如果接收到的请求标志为终端混频能力标志，则根据所述请求标志触发在通话期间继续播放多媒体铃音的步骤包括：

在接收到摘机应答消息后，继续多媒体铃音播放。

根据本实施例的方法，由于服务器端没有停止发送多媒体铃音，故可以由请求终端对多媒体铃音和通话媒体流混频后在本地播放，因此，在主被叫终端挂机后，本实施例的方法还包括下列步骤：

在接收到挂机消息后，向媒体资源功能实体发送停止消息，指示媒体资源功能实体停止播放多媒体铃音；

接收媒体资源功能实体返回的停止确认消息，确认停止播放多媒体铃音。

在本实施例中，如果为用户播放的多媒体铃音文件是图片、文本或电子名片等文件，则多媒体铃音服务器在收到相应的请求标志后，在接收到200OK消息后，不进行混频或混音操作，而只是继续播放多媒体铃音文件即可。

通过本实施例的方法，使得通话过程中的主叫终端或者被叫终端或者主被叫终端都可以继续听到多媒体铃音，解决了现有技术中无法实现多媒体铃音在通话期间为用户继续播放的问题，以及多媒体振铃音或多媒体回铃音在通话期间转换为多媒体背景音的问题。

本实施例的方法不仅可以应用于电路交换域(CS域)的呼叫过程，也可以应用于IMS域(IP多媒体子系统)的呼叫过程，实现CRS(或CAT)在IMS域的早期会话方式、多会话方式、网关方式，以及CS域的跨接方式、非跨接方式下的通话过程中继续播放，下面分别以不同的实施例加以说明。

实施例三

本实施例的方法应用于IMS域的早期会话方式，由服务器端对多媒体振铃音和通话媒体流进行混频，实现单向“CRS+通话”到被叫。

在本实施例中，当被叫终端的用户摘机时，在被叫终端发送的200OK消息中携带请求服务器混频标志，在本实施例中，该标志为多媒体振铃音混频标志，多媒体振铃音应用服务器CRS AS接收到此标志后触发相应的动作，即指示媒体资源功能实体MRF对CRS和通话媒体流进行混频操作，并将混频后的媒体流发送给被叫终端。

在本实施例中，请求终端为被叫，假设主叫终端A的用户为被叫终端B的用户定制了多媒体振铃音CRS业务。A呼叫B时，CRS AS指示MRF为B播放多媒体振铃音，当B摘机应答时，UE B发送的200OK消息中携带请求服务器混频标志，该标志可以由主叫终端的用户在主叫终端上预先进行设置，CRS AS解析此标志后，指示MRF对CRS和A到B方向的通话进行混频处理。终端B的用户就可以在和终端A的用户通话过程中，继续欣赏CRS多媒体内容。其中，CRS和通话媒体流均可以为音频或视频形式，如果CRS为音频，则直接与通话流混音；如果CRS为视频，则可以将CRS视频和通话视频流混频后分屏显示。

图2为本实施例的组网结构图，如图2所示，其中：

UE(User Equipment)为用户设备。在本实施例中，UE-A为主叫终端，UE-B为被叫终端。

Node B为WCDMA系统的基站，即无线收发信机，主要完成Uu接口物理层协议的处理。

RNC(Radio Network Controller)为无线网络控制器，用于控制UTRAN的无线资源。

SGSN(Serving GPRS Support Node)为服务器GPRS支持节点，是WCDMA核心网PS域功能节点，主要提供PS域的路由转发、移动性管理、会话管理、鉴权、加密等功能。

P-CSCF(Proxy Call Session Control Function)为代理呼叫会话控制功能。P-CSCF是IMS网络中用户的第一个接触点，主要负责验证请求，处理和转发响应。

S-CSCF(Serving Call Session Control Function)为服务呼叫会话控制功能。S-CSCF在IMS网络中处于核心控制地位，是IMS多进程控制的关键所在。其负责记录并控制用户进程状态，执行会话路由功能，并不断与应用服务和计费功能进行交互，根据规则进行增值业务触发与业务控制。

HSS(Home Subscriber Server)为归属用户服务器。HSS是一个存储用户和服务相关数据的数据库，是一个升级的HLR。HSS以XML形式记录了用户身份、注册信息、接入参数和服务触发信息等。

CRS AS(Customized Ringing Signal Application Server)为多媒体振铃音应用服务器。CRS AS是IMS网络中为用户提供IM增值业务的服务器，可以位于用户归属网，也可以由第三方提供。CRS AS主要用于提供CRS业务，并控制MRF进行媒体资源的播放。

MRF(Multimedia Resource Function)为媒体资源功能实体。MRF包括控制部分(MRFC)和用户平面的处理部分(MRFP)，对与承载相关的业务提供支持，如多媒体资源播放、视频会议、用户公告等，能够完成数据媒体流的混合、媒体流的分发、承载代码的转换、计费信息的发送等。

其中，CRS AS和MRF合起来可以称为多媒体振铃音服务器，同样道理，多媒体回铃音应用服务器CTS AS和MRF合起来可以称为多媒体回铃音服务器，多媒体背景音应用服务器CBT AS和MRF合起来可以称为多媒体背景音服务器，CRS AS、CTS AS、CBT AS和MRF合起来可以称为多媒体铃音服务器。

图3为本实施例的呼叫流程示意图，如图3所示：

步骤301～步骤302：主叫终端UE-A发送一个带有正常会话(Session)SDP(Session description protocol，会话描述协议)Offer(O1)的INVITE请求以建立与被叫终端UE-B之间的通话。INVITE请求首先到达S-CSCF，并根据S-CSCF中的初始过滤准则iFC被路由到多媒体彩振服务器CRS AS。

步骤303～步骤304：CRS AS确定UE-A已为UE-B订阅了CRS业务，即发送一个不带有SDP的INVITE请求给媒体资源功能MRF。MRF返回200OK消息进行应答，200OK消息携带了早期会话(Early-session)的SDP Offer(CRS-O)，目的是用于建立UE-B与MRF之间的CRS媒体流。

步骤305～步骤307：CRS AS产生一个INVITE请求，途径S-CSCF和P-CSCF到达UE-B。其中，INVITE请求包含了两个SDP：正常会话的SDPOffer(O1)和早期会话的SDP Offer(CRS-O)。并且，INVITE的Require头域中包含了early-session选项标签。

步骤308～步骤3010：被叫终端UE-B对INVITE请求中的早期会话的SDP Offer(CRS-O)进行应答，返回可靠的183临时响应，183中携带了早期会话的SDP Answer(CRS-A)，并且183的Require头域中包含了100rel选项标签。

步骤3011：CRS AS接收到183之后，向MRF发送确认消息ACK，ACK中携带了早期会话的SDP Answer(CRS-A)。

步骤3012～步骤3013：CRS AS发送183到S-CSCF，S-CSCF再将183转发到主叫终端UE-A。

步骤3014～步骤3018：UE-A返回对183的可靠响应PRACK，途径S-CSCF、CRS AS、S-CSCF、P-CSCF之后到达UE-B。

步骤3019～步骤3021：UE-B返回对PRACK的确认消息200OK，途径P-CSCF、S-CSCF到达CRS AS。

步骤3022～步骤3023：CRS AS发送INFO消息给MRF，指示MRF开始为UE-B播放多媒体彩振CRS。MRF返回200OK作为确认，并开始播放多媒体彩振。此时被叫用户B就从UE-B收听/收看到了主叫用户A为其定制的多媒体彩振。

步骤3024～步骤3028：UE-B返回180振铃消息，途径P-CSCF、S-CSCF、CRS AS、S-CSCF到达UE-A。

步骤3029～步骤3031：被叫用户B摘机应答，UE-B发送带有正常会话SDP Answer(A1)的200OK消息，根据本实施例的方法，200OK消息同时携带了混音/混频请求(Mixing请求)标志，即多媒体振铃音混频标志，该标志可通过SIP头域、或SDP、或XML文件来携带。对于XML的携带方式，可以将SIP头域中的content-type置为multipart/mixed类型，然后在SDP消息体后携带XML文件即可。200OK消息途径P-CSCF、S-CSCF到达CRS AS。

步骤3032～步骤3033：根据本实施例的方法，CRS AS接收到带有Mixing请求标志的200OK之后，发送INFO消息给MRF，INFO通过SDP或头域字段携带Mixing请求标志，以指示MRF启动MIX单元，准备对CRS和通话媒体流进行混音/混频。MRF返回对INFO的应答消息200OK。

步骤3034～步骤3035：CRS AS转发带有正常会话SDP Answer(A1)的200OK消息，途径S-CSCF，到达UE-A。

步骤3036～步骤3040：UE-A返回对200OK消息的确认消息ACK，途径S-CSCF、CRS AS、S-CSCF、P-CSCF到达UE-B。此时UE-A和UE-B之间的正常通话建立，根据本实施例的方法，MRF此时作为一个Mixer(混音/混频器)锚定在主被叫通话路径上，将主叫用户的语音/视频与CRS进行MIX操作，合并为一路媒体流发送给被叫终端UE-B。MRF对UE-B到UE-A方向的语音/视频媒体流不做MIX操作。

步骤3041～步骤3052：被叫用户B挂机，UE-B发送BYE消息给UE-A，中间途径P-CSCF、S-CSCF、CRS AS和S-CSCF。根据本实施例的方法，CRS AS在接收到BYE消息后，发送BYE消息给MRF，指示MRF停止MIX操作及停止播放CRS。UE-A返回200OK消息给UE-B。通话结束。

在本实施例的第3029～3031步骤中，除了使用200OK携带请求服务器混频标志(多媒体振铃音混频标志)外，还可以在200OK之后使用INFO或MESSAGE等消息携带。本实施例并不以此作为限制。另外，被叫用户除了在摘机时通过200OK消息携带请求混频标志外，还可以通过带外方式(如短消息)或离线方式(如Web)实现混频请求。

在本实施例中，由于是服务器端进行混频(MIX)操作，现有的网络实体即可支持该项功能。且对终端侧无要求，普通终端即可实现通话期间正常接收CRS。

实施例四

本实施例的方法应用于IMS域的早期会话方式，由服务器端对多媒体振铃音和通话媒体流进行混频，实现双向“CRS+通话”到主、被叫。

在本实施例中，当被叫终端的用户摘机时，被叫终端发送的200OK消息中携带请求服务器混频标志，在本实施例中，该标志为多媒体背景音混频标志，CRS AS接收到此标志后触发相应的动作，即指示MRF进行多媒体背景音CBT混频操作。CRS AS发送re-INVITE请求给主叫终端及被叫终端，请求中携带有CBT会话SDP Offer，主被叫终端进行应答之后，MRF进入CBT放音模式，即在主被叫终端通话过程中进行多媒体背景音的播放。

在本实施例中，请求终端为被叫终端，假设被叫终端B的用户摘机时，CRS AS指示MRF进行CRS模式转CBT模式的操作。这样，主被叫终端的用户通话过程中，双方都可以欣赏到MRF播放的多媒体背景音(音频或视频等多媒体内容)。

该实施例的组网结构及其功能与实施例三相同，在此不再赘述。

图4为本实施例的呼叫流程示意图，如图4所示：

步骤401～步骤402：主叫终端UE-A发送一个带有正常会话(Session)SDP Offer(O1)的INVITE请求以建立与被叫终端UE-B之间的通话。INVITE请求首先到达S-CSCF，并根据S-CSCF中的初始过滤准则iFC被路由到多媒体彩振服务器CRS AS。

步骤403～步骤404：CRS AS确定UE-A已为UE-B订阅了CRS业务，即发送一个不带有SDP的INVITE请求给媒体资源功能MRF。MRF返回200OK消息进行应答，200OK消息携带了早期会话(Early-session)的SDP Offer(CRS-O)，目的是用于建立UE-B与MRF之间的CRS媒体流。

步骤405～步骤407：CRS AS产生一个INVITE请求，途径S-CSCF和P-CSCF到达UE-B。其中，INVITE请求包含了两个SDP：正常会话的SDPOffer(O1)和早期会话的SDP Offer(CRS-O)。并且，INVITE的Require头域中包含了early-session选项标签。

步骤408～步骤4010：被叫终端UE-B对INVITE请求中的早期会话的SDP Offer(CRS-O)进行应答，返回可靠的183临时响应，183中携带了早期会话的SDP Answer(CRS-A)，并且183的Require头域中包含了100rel选项标签。

步骤4011：CRS AS接收到183之后，向MRF发送确认消息ACK，ACK中携带了早期会话的SDP Answer(CRS-A)。

步骤4012～步骤4013：CRS AS发送183到S-CSCF，S-CSCF再将183转发到主叫终端UE-A。

步骤4014～步骤4018：UE-A返回对183的可靠响应PRACK，途径S-CSCF、CRS AS、S-CSCF、P-CSCF之后到达UE-B。

步骤4019～步骤4021：UE-B返回对PRACK的确认消息200OK，途径P-CSCF、S-CSCF到达CRS AS。

步骤4022～步骤4023：CRS AS发送INFO消息给MRF，指示MRF开始为UE-B播放多媒体彩振CRS。MRF返回200OK作为确认，并开始播放多媒体彩振。此时被叫用户B就从UE-B收听/收看到了主叫用户A为其定制的多媒体彩振。

步骤4024～步骤4028：UE-B返回180振铃消息，途径P-CSCF、S-CSCF、CRS AS、S-CSCF到达UE-A。

步骤4029～步骤4031：被叫用户B摘机应答，UE-B发送带有正常会话SDP Answer(A1)的200OK消息，根据本实施例的方法，200OK消息同时携带了混音/混频请求(Mixing请求)标志，即多媒体背景音混频标志，该标志可通过第二个SDP、或头域字段、或XML文件携带，途径P-CSCF、S-CSCF到达CRS AS。

步骤4032～步骤4033：根据本实施例的方法，CRS AS接收到带有Mixing请求标志的200OK之后，发送INFO消息给MRF，INFO通过SDP或头域字段携带Mixing请求标志，以指示MRF启动MIX单元，准备对CRS和通话媒体流进行混音/混频。MRF返回对INFO的应答消息200OK。

步骤4034～步骤4035：CRS AS转发带有正常会话SDP Answer(A1)的200OK消息，途径S-CSCF，到达UE-A。

步骤4036～步骤4040：UE-A返回对200OK消息的确认消息ACK，途径S-CSCF、CRS AS、S-CSCF、P-CSCF到达UE-B。

步骤4041～步骤4043：根据本实施例的方法，CRS AS发送re-INVITE请求给UE-B，以重新协商多媒体背景音CBT会话，其中re-INVITE消息携带了CBT会话的SDP Offer(O2)。

步骤4044～步骤4045：根据本实施例的方法，CRS AS发送re-INVITE请求给UE-A，以重新协商多媒体背景音CBT会话，其中re-INVITE消息携带了CBT会话的SDP Offer(O2)。

步骤4046～步骤4048：根据本实施例的方法，UE-B返回对re-INVITE的响应200OK给CRS AS，200OK消息携带了CBT会话的SDP Answer(A2)。

步骤4049～步骤4050：根据本实施例的方法，UE-A返回对re-INVITE的响应200OK给CRS AS，200OK消息携带了CBT会话的SDP Answer(A2)。

此时，UE-A和UE-B之间的正常通话建立，MRF作为一个Mixer(混音/混频器)锚定在主被叫通话路径上，将主/被叫用户的语音/视频与CRS进行MIX操作，并分别发送给主/被叫双方。此时的多媒体彩振CRS可以称为多媒体背景音CBT。

步骤4051～步骤4062：被叫用户B挂机，UE-B发送BYE消息给UE-A，中间途径P-CSCF、S-CSCF、CRS AS和S-CSCF。根据本实施例的方法，CRS AS在接收到BYE消息后，发送BYE消息给MRF，指示MRF停止MIX操作及停止播放CBT。UE-A返回200OK消息给UE-B。通话结束。

在本实施例的第4041～4054步骤中，re-INVITE方法也可以替换为REFER方法。即CRS AS向主被叫终端发送REFER请求，邀请主被叫加入CBT模式，其中Refer-to字段携带了CBT模式的URI。主被叫终端返回Accepted响应，并发送NOTIFY消息，以告知MRF终端已接收请求。MRF返回200OK。这样，主被叫终端即进入了CBT模式。

在本实施例中，由于是服务器端进行混频，所以对终端侧没有要求。且在通话期间CRS转换为CBT模式，使得主被叫双方均可欣赏到多媒体背景内容。

实施例五

本实施例的方法应用于IMS域的早期会话方式，由终端对多媒体振铃音和通话媒体流进行混频，实现单向“CRS+通话”到被叫。

在本实施例中，当被叫终端的用户摘机后，被叫终端在200OK消息中携带终端混频能力标志，CRS AS接收到该标志后，不向MRF发送BYE消息，MRF在主被叫终端通话期间继续播放CRS，被叫终端同时接收到两路媒体流，并使用被叫终端本地的混频单元进行混频操作。

在本实施例中，请求终端为被叫终端，假设被叫终端B具有将两路媒体流混频的功能，可以在通话过程中，仍然接收CRS媒体流，并将两路媒体流进行混频后显示(或播放)给被叫终端的用户。

该实施例的组网结构及其功能与实施例三相同，在此不再赘述。

图5为本实施例的呼叫流程示意图，如图5所示：

步骤501～步骤502：主叫终端UE-A发送一个带有正常会话(Session)SDP Offer(O1)的INVITE请求以建立与被叫终端UE-B之间的通话。INVITE请求首先到达S-CSCF，并根据S-CSCF中的初始过滤准则iFC被路由到多媒体彩振服务器CRS AS。

步骤503～步骤504：CRS AS确定UE-A已为UE-B订阅了CRS业务，即发送一个不带有SDP的INVITE请求给媒体资源功能MRF。MRF返回200OK消息进行应答，200OK消息携带了早期会话(Early-session)的SDP Offer(CRS-O)，目的是用于建立UE-B与MRF之间的CRS媒体流。

步骤505～步骤507：CRS AS产生一个INVITE请求，途径S-CSCF和P-CSCF到达UE-B。其中，INVITE请求包含了两个SDP：正常会话的SDPOffer(O1)和早期会话的SDP Offer(CRS-O)。并且，INVITE的Require头域中包含了early-session选项标签。

步骤508～步骤5010：被叫终端UE-B对INVITE请求中的早期会话的SDP Offer(CRS-O)进行应答，返回可靠的183临时响应，183中携带了早期会话的SDP Answer(CRS-A)，并且183的Require头域中包含了100rel选项标签。

步骤5011：CRS AS接收到183之后，向MRF发送确认消息ACK，ACK中携带了早期会话的SDP Answer(CRS-A)。

步骤5012～步骤5013：CRS AS发送183到S-CSCF，S-CSCF再将183转发到主叫终端UE-A。

步骤5014～步骤5018：UE-A返回对183的可靠响应PRACK，途径S-CSCF、CRS AS、S-CSCF、P-CSCF之后到达UE-B。

步骤5019～步骤5021：UE-B返回对PRACK的确认消息200OK，途径P-CSCF、S-CSCF到达CRS AS。

步骤5022～步骤5023：CRS AS发送INFO消息给MRF，指示MRF开始为UE-B播放多媒体彩振CRS。MRF返回200OK作为确认，并开始播放多媒体彩振。此时被叫用户B就从UE-B收听/收看到了主叫用户A为其定制的多媒体彩振。

步骤5024～步骤5028：UE-B返回180振铃消息，途径P-CSCF、S-CSCF、CRS AS、S-CSCF到达UE-A。

步骤5029～步骤5031：被叫用户B摘机应答，UE-B发送带有正常会话SDP Answer(A1)的200OK消息，根据本实施例的方法，200OK消息同时携带了终端Mix能力标志，以表示终端具有混音/混频的能力，该标志可通过第二个SDP、或头域字段、或XML文件携带，途径P-CSCF、S-CSCF到达CRS AS。

步骤5032～步骤5033：CRS AS转发带有正常会话SDP Answer(A1)的200OK消息，途径S-CSCF，到达UE-A。

步骤5034～步骤5038：UE-A返回对200OK消息的确认消息ACK，途径S-CSCF、CRS AS、S-CSCF、P-CSCF到达UE-B。

此时UE-A和UE-B之间的正常通话建立，主被叫之间的音频/视频通话通过RTP流媒体进行传输。同时，MRF继续为UE-B播放多媒体彩振CRS，UE-B对接收到的两路媒体流进行MIX操作，合并为一路媒体流之后进行播放。

步骤5039～步骤5050：被叫用户B挂机，UE-B发送BYE消息给UE-A，中间途径P-CSCF、S-CSCF、CRS AS和S-CSCF。根据本实施例的方法，CRSAS接收到BYE消息之后，发送BYE消息给MRF，指示MRF停止播放CRS。MRF返回对BYE的应答消息200OK。UE-A返回200OK消息给UE-B。通话结束。

在本实施例中，由于是被叫终端进行混频，所以对服务器无要求，可以减少服务器的处理过程，降低服务器负荷。但对终端要求较高，需要在现有终端中增加专门的混频模块。

实施例六

本实施例的方法应用于IMS域的早期会话方式，由终端通过带外方式下载多媒体振铃音，实现在通话过程中被叫本地播放。

在本实施例中，当被叫终端的用户摘机后，被叫终端在200OK消息中携带多媒体振铃音下载标志，请求服务器下发CRS URI链接以进行下载和本地播放。CRS AS接收到标志后，指示MRF为被叫终端下发CRS URI，并停止目前的CRS的播放。被叫终端接收到CRS URI之后，通过HTTP协议从第三方Web服务器下载CRS，并在通话期间进行本地播放。

在本实施例中，请求终端为被叫终端，假设被叫终端B的用户希望在通话期间能够下载CRS并进行本地播放。

该实施例的组网结构及其功能与实施例三相同，在此不再赘述。

图6为本实施例的呼叫流程示意图，如图6所示：

步骤601～步骤602：主叫终端UE-A发送一个带有正常会话(Session)SDP Offer(O1)的INVITE请求以建立与被叫终端UE-B之间的通话。INVITE请求首先到达S-CSCF，并根据S-CSCF中的初始过滤准则iFC被路由到多媒体彩振服务器CRS AS。

步骤603～步骤604：CRS AS确定UE-A已为UE-B订阅了CRS业务，即发送一个不带有SDP的INVITE请求给媒体资源功能MRF。MRF返回200OK消息进行应答，200OK消息携带了早期会话(Early-session)的SDP Offer(CRS-O)，目的是用于建立UE-B与MRF之间的CRS媒体流。

步骤605～步骤507：CRS AS产生一个INVITE请求，途径S-CSCF和P-CSCF到达UE-B。其中，INVITE请求包含了两个SDP：正常会话的SDPOffer(O1)和早期会话的SDP Offer(CRS-O)。并且，INVITE的Require头域中包含了early-session选项标签。

步骤608～步骤6010：被叫终端UE-B对INVITE请求中的早期会话的SDP Offer(CRS-O)进行应答，返回可靠的183临时响应，183中携带了早期会话的SDP Answer(CRS-A)，并且183的Require头域中包含了100rel选项标签。

步骤6011：CRS AS接收到183之后，向MRF发送确认消息ACK，ACK中携带了早期会话的SDP Answer(CRS-A)。

步骤6012～步骤6013：CRS AS发送183到S-CSCF，S-CSCF再将183转发到主叫终端UE-A。

步骤6014～步骤6018：UE-A返回对183的可靠响应PRACK，途径S-CSCF、CRS AS、S-CSCF、P-CSCF之后到达UE-B。

步骤6019～步骤6021：UE-B返回对PRACK的确认消息200OK，途径P-CSCF、S-CSCF到达CRS AS。

步骤6022～步骤6023：CRS AS发送INFO消息给MRF，指示MRF开始为UE-B播放多媒体彩振CRS。MRF返回200OK作为确认，并开始播放多媒体彩振。此时被叫用户B就从UE-B收听/收看到了主叫用户A为其定制的多媒体彩振。

步骤6024～步骤6028：UE-B返回180振铃消息，途径P-CSCF、S-CSCF、CRS AS、S-CSCF到达UE-A。

步骤6029～步骤6031：被叫用户B摘机应答，UE-B发送带有正常会话SDP Answer(A1)的200OK消息，根据本实施例的方法，200OK消息同时携带了CRS URI的请求标志，该标志可通过第二个SDP、或Alert-Info/Call-Info头域、或XML文件携带，途径P-CSCF、S-CSCF到达CRS AS。

步骤6032～步骤6033：CRS AS接收到200OK之后，发送BYE消息给MRF，指示MRF停止播放CRS，根据本实施例的方法，BYE消息通过SDP携带了CRS URI的请求标志，以指示MRF发送一个CRS的HTTP URI。MRF返回对BYE的应答消息200OK，根据本实施例的方法，200OK通过SDP或头域字段携带了CRS的HTTP URI。

步骤6034～步骤6035：CRS AS转发带有正常会话SDP Answer(A1)的200OK消息，途径S-CSCF，到达UE-A。

步骤6036～步骤6040：UE-A返回对200OK消息的确认消息ACK，途径S-CSCF到达CRS AS。根据本实施例的方法，CRS AS将CRS的HTTP URI添加到ACK消息的SDP或头域字段中，并发送给被叫终端UE-B，中间途径S-CSCF和P-CSCF。

此时，UE-B通过接收到的CRS的HTTP URI从第三方Web服务器下载CRS，并进行本地播放。

此时，UE-A和UE-B之间的正常通话建立，主被叫之间的音频/视频通话通过RTP流媒体进行传输。

步骤6041～步骤6050：被叫用户B挂机，UE-B发送BYE消息给UE-A。UE-A返回200OK消息给UE-B。通话结束。

在本实施例中，对CRS服务器、终端均无混频要求，是一种最经济的方案。但由于需要从Web服务器下载CRS，所以可能会造成延迟，且只能播放音频CRS。

实施例七

本实施例的方法应用于CS域的跨接方式，由服务器端对多媒体振铃音和通话媒体流进行混频，实现单向“CRS+通话”到被叫。

在本实施例中，当被叫终端的用户摘机时，被叫终端在CONNECT消息中携带请求混频标志，CRS Server对CRS和主叫终端到被叫终端方向的通话媒体流进行混频，实现通话期间被叫终端的用户可以欣赏CRS的目的。

在本实施例中，假设被叫终端的用户希望在通话过程中能继续欣赏CRS多媒体内容。

图7为本实施例的组网结构图，如图7所示，其中：

MSC Server(Mobile Switching Center Server)为移动交换中心服务器。主要由MSC的呼叫控制和移动控制组成，负责完成CS域的呼叫处理等功能。MSC Server终接用户-网络信令，并将其转换成网络-网络信令。MSCServer可控制MGW中媒体通道的属于连接控制的部分呼叫状态。

VLR(Visitor Location Register)为拜访位置寄存器。其为电路域特有的设备，存储着进入该控制区内已登记用户的相关信息，为移动用户提供呼叫接续的必要数据。

MGW(Media Gateway)为媒体网关。它是PSTN/PLMN的传输终接点，并通过Iu接口连接核心网和UTRAN。MGW可支持媒体转换、承载控制和有效载荷处理，例如，多媒体数字信号编码器、回音消除器、会议桥等。

HLR(Home Location Register)为归属位置寄存器。其为CS域和PS域公用设备，是一个负责管理移动用户的数据库系统。HLR存储着本归属区的所有移动用户数据，如识别标志、位置信息、签约业务等。

AuC(Authentication Center)为鉴权中心。其是存储用户鉴权算法和加密密钥的实体。AuC将鉴权和加密数据通过HLR发往VLR、MSC以及SGSN，以保证通信的合法和安全。

CRS Server为多媒体振铃音服务器。CRS Server为CS域多媒体振铃音系统的核心组件，用于存储CRS的业务逻辑和播放多媒体资源。

图8为本实施例的呼叫流程示意图，如图8所示：

步骤801：主叫终端UE A向MSC Server A发送SETUP消息，以初始化呼叫。

步骤802：MSC Server A向HLR发起SRI请求，以获取被叫终端UE B的路由信息。

步骤803：HLR向UE B所附着的MSC Server B中的VLR取漫游号码。

步骤804：MSC Server B中的VLR向HLR返回PRN_ACK消息，消息中携带了UE B的漫游号码。

步骤805：HLR向MSC Server A返回SRI_ACK消息，消息中携带了UE B的路由信息、漫游号码、以及用户A为用户B定制的多媒体彩振CRS业务标志。

步骤806：MSC Server A向UE A发起Call_Proceeding，以表明MSCServer A正在进行呼叫操作。

步骤807：MSC Server A向多媒体彩振服务器CRS Server发起BICC IAM消息，以建立到CRS Server的电路连接，其中IAM消息携带了CRS的业务标志。CRS Server根据CRS业务标志确定主叫用户A为被叫用户B所定制的CRS业务。

步骤808：CRS Server向MSC Server B发送BICC IAM消息，以建立到MSC Server B的电路连接，其中IAM消息携带了CRS的业务标志。

步骤809：MSC Server B向UE B发起寻呼请求消息PAGING。

步骤8010：UE B返回寻呼响应消息PAGING_RSP。

步骤8011：MSC Server B向UE B发SETUP消息，以建立和被叫终端UE B的呼叫连接。SETUP消息中携带了CRS业务标志。UE B接收到CRS业务标志后，抑制本地振铃音，并等待接收CRS。

步骤8012：UE B返回Call_Confirmed消息，以响应SETUP消息。

步骤8013：UE B振铃，并向MSC Server B返回ALERTING消息。

步骤8014～步骤8015：MSC Server B向MSC Server A返回BICC ACM消息，用以确认被叫端局侧相应的中继电路已经建立，中间途径CRS Server。

步骤8016：MSC Server A向UEA发送ALERTING消息，UEA产生回铃音。

步骤8017：CRS Server与UE B之间建立H.245连接，并通过H.245协议建立媒体信道。此时CRS Server开始向UE B播放多媒体彩振CRS。

步骤8018：被叫终端UE B摘机，发送应答消息CONNECT。根据本实施例的方法，CONNECT消息携带了Mixing请求标志，具体携带方式可以通过CONNECT消息的User-to-user信元或Facility信元来携带。

步骤8019：MSC Server B发送BICC ANM消息到CRS Server。根据本实施例的方法，ANM消息携带了Mixing请求标志，具体携带方式可以通过ANM消息的Optional Part中的User-to-user或Facility等可选参数来携带。CRS Server根据接收到的Mixing请求标志，触发服务器内部的MIX单元，准备为CRS和视频通话过程进行混音/混频。

re-INVITE8020：MSC Server B返回确认消息CONNECT_ACK到被叫终端UE B。

步骤8021：CRS Server发送BICC ANM消息给MSC Server A。

步骤8022～步骤8023：MSC Server A发送CONNECT消息给UE A，UEA返回CONNECT_ACK进行确认。

步骤8024：UE A与CRS Server建立H.245连接，并通过H.245协议建立媒体信道。主被叫用户之间开始通话。

根据本实施例的方法，CRS Server内部的MIX单元对UEA到UE B方向的音频/视频通话流与CRS进行MIX操作，并发送给UE B。但对于UE B到UEA方向的音频/视频通话流不做MIX处理。

步骤8025：UE A挂机，CRS Server拆除与UE A及UE B之间的H.245连接。通话结束。

在本实施例的第8018步骤中，除了使用CONNECT消息携带请求混频标志外，还可以在发送CONNECT之后使用USER INFORMATION消息或FACILITY消息来实现携带。

根据本实施例的方法，对应于实施例四，CS域中也可以实现通话期间CRS转CBT的方案。对应于实施例五，CS域中也可以实现通话期间从Web服务器下载CRS并本地播放的方案。

本实施例虽然属于CS域的跨接方案，但也可扩展至CS域的非跨接方案，基本原理相同，在此不再赘述。

在本实施例中，由于使用服务器端进行混频，使得不支持IMS域、且无混频能力的终端可以实现在通话期间继续播放CRS多媒体内容。

需要说明的是，上述实施例三至实施例七是针对请求终端为被叫终端，通话期间继续为被叫终端播放多媒体振铃音或为主被叫终端播放振铃音的情况。而对于多媒体回铃音的情况与多媒体振铃音情况类似，不同的是，由主叫终端作为请求终端，向多媒体彩铃应用服务器(CAT AS)发送请求标志，以请求在通话期间继续听到多媒体回铃音，而多媒体彩铃应用服务器根据主叫终端发送的请求标志，触发在通话期间继续播放多媒体回铃音，触发的流程也与前述实施例类似，在此不再赘述。

实施例八

本发明实施例还提供一种多媒体铃音应用服务器，以下结合附图对本实施例进行详细说明。

图9为本实施例的多媒体铃音应用服务器的组成结构框图，如图9所示，本实施例的多媒体铃音应用服务器主要包括：请求标志接收单元91、多媒体铃音播放触发单元93，其中：

请求标志接收单元91用于接收主叫终端或被叫终端发送的请求标志；

多媒体铃音播放触发单元93用于根据所述请求标志触发在通话期间继续播放多媒体铃音。

根据本实施例，多媒体铃音应用服务器还可以包括判断单元92，在本实施例中，判断单元92用于根据所述请求标志接收单元91接收到的请求标志判断所述请求标志的类型，以提供给多媒体铃音播放触发单元93触发相应的流程，其中，该请求标志可以为多媒体振铃音混频标志，或多媒体回铃音混频标志，或多媒体背景音混频标志，或多媒体铃音链接下载标志，或终端混频能力标志。

根据本实施例，多媒体铃音播放触发单元93可以包括混频指示发送模块931，在本实施例中，当判断单元92判断的结果为，请求标志为多媒体振铃音混频标志时，则混频指示发送单元931发送携带有多媒体振铃音混频标志的指示消息到媒体资源功能实体，指示该媒体资源功能实体对多媒体振铃音和主叫终端到被叫终端的通话媒体流进行混音/混频。

在本实施例中，当判断单元92判断的结果为，请求标志为多媒体回铃音混频标志时，则混频指示发送单元931发送携带有多媒体回铃音混频标志的指示消息到媒体资源功能实体，指示该媒体资源功能实体对多媒体回铃音和被叫终端到主叫终端的通话媒体流进行混音/混频。

在本实施例中，当判断单元92判断的结果为，请求标志为多媒体背景音混频标志时，则混频指示发送单元931发送携带有多媒体背景音混频标志的指示消息到媒体资源功能实体，指示该媒体资源功能实体对多媒体振铃音或多媒体回铃音和主叫终端与被叫终端之间的通话媒体流进行混音/混频。其中，多媒体铃音播放触发单元93还可以包括背景音请求发送模块932，当请求标志为多媒体背景音混频标志时，混频指示发送单元931发送指示消息到媒体资源功能实体后，由背景音请求发送模块932向主叫终端和被叫终端发送多媒体背景音请求，协商多媒体背景音会话。

根据本实施例，多媒体铃音播放触发单元93还可以包括链接指示发送模块933、多媒体铃音链接接收模块934以及多媒体铃音链接发送模块935，在本实施例中，当判断单元92判断的结果为，请求标志为多媒体铃音链接下载标志时，则链接指示发送模块933发送携带有多媒体铃音链接下载标志的指示消息到媒体资源功能实体，指示该媒体资源功能实体发送多媒体铃音链接。在本实施例中，当多媒体铃音链接接收模块934接收到媒体资源功能实体返回的多媒体铃音链接后，则多媒体铃音链接发送模块935发送携带有多媒体铃音链接的确认消息到请求终端。

根据本实施例，当判断单元92判断的结果为，请求标志为终端混频能力标志时，则多媒体铃音播放触发单元93在多媒体振铃音播放过程中，触发正常的呼叫流程，由具备混频能力的请求终端对接收到的多媒体振铃音或多媒体回铃音和通话媒体流进行混频后在本地播放，也可以实现该请求终端在通话过程中继续收听多媒体振铃音或多媒体回铃音。

根据本实施例，该多媒体铃音应用服务器可以包含于多媒体铃音服务器中，该多媒体铃音服务器还包括媒体资源功能实体，该媒体资源功能实体用于对多媒体振铃音或多媒体回铃音和通话媒体流进行混频；和播放多媒体振铃音和或混频后的多媒体振铃音；或者播放多媒体回铃音和或混频后的多媒体回铃音。

本实施例的多媒体铃音服务器和多媒体铃音应用服务器的各组成部分分别用于实现前述方法的各步骤的功能，例如多媒体铃音应用服务器可以实现前述CRS AS、CTS AS以及或者CBT AS的功能，多媒体铃音服务器可以实现前述CRS AS、CTS AS以及或者CBT AS与MRF的功能，具体已在前述作了详细说明，在此不再赘述。

通过本实施例的多媒体铃音应用服务器，使得通话过程中的主叫终端或者被叫终端或者主被叫终端都可以继续听到多媒体振铃音或多媒体回铃音，解决了现有技术中无法实现多媒体振铃音或多媒体回铃音在通话期间为用户继续播放的问题，以及多媒体振铃音或多媒体回铃音在通话期间转换为多媒体背景音的问题。

实施例九

本发明实施例还提供一种在通话期间播放多媒体铃音的方法，以下结合附图对本实施例进行详细说明。

图10为本实施例的方法流程图，本实施例的方法应用于终端设备，如图10所示，本实施例的方法主要包括：

1001：向多媒体铃音服务器发送请求标志，所述请求标志用于请求多媒体铃音服务器在通话期间继续播放多媒体铃音。

根据本实施例，该向多媒体铃音服务器发送请求标志的步骤可以是：

向多媒体铃音服务器发送多媒体振铃音混频标志，所述多媒体振铃音混频标志用于请求多媒体铃音服务器对多媒体振铃音和主叫终端到被叫终端的通话媒体流进行混音/混频后播放。

根据本实施例，该向多媒体铃音服务器发送请求标志的步骤也可以是：

向多媒体铃音服务器发送多媒体回铃音混频标志，所述多媒体回铃音混频标志用于请求多媒体铃音服务器对多媒体回铃音和被叫终端到主叫终端的通话媒体流进行混音/混频后播放。

根据本实施例，该向多媒体铃音服务器发送请求标志的步骤也可以是：

向多媒体铃音服务器发送多媒体背景音混频标志，所述多媒体背景音混频标志用于请求多媒体铃音服务器对多媒体回铃音或多媒体振铃音和主叫终端与被叫终端之间的通话媒体流进行混音/混频后播放。

根据本实施例，该向多媒体铃音服务器发送请求标志的步骤也可以是：

向多媒体铃音服务器发送多媒体铃音链接下载标志，所述多媒体铃音链接下载标志用于请求多媒体铃音服务器下发多媒体铃音的链接，以下载该多媒体铃音后进行本地播放。

在本实施例中，向多媒体铃音服务器发送多媒体铃音链接下载标志的步骤之后还包括：

1003：接收并下载所述多媒体铃音链接的多媒体铃音；

1004：对下载后的多媒体铃音进行本地播放。

根据本实施例，该向多媒体铃音服务器发送请求标志的步骤也可以是：

向多媒体铃音服务器发送终端混频能力标志，所述终端混频能力标志用于请求多媒体铃音服务器继续播放多媒体铃音，并对多媒体铃音与接收到的通话媒体流混频后进行本地播放。

在本实施例中，向多媒体铃音服务器发送终端混频能力标志的步骤之后还包括：

1005：对接收到的多媒体铃音和通话媒体流进行混频；以及

1006：播放所述混频后的多媒体铃音和通话媒体流的步骤，以实现在通话过程中对所述的多媒体铃音进行本地播放。

根据本实施例，也可以无须发送请求标志，主叫或被叫用户可以通过带外方式预先在多媒体铃音服务器上进行相应的设置，以使得用户在通话过程中仍可以欣赏到彩振或彩铃。

通过本实施例的方法，使得通话过程中的主叫终端或者被叫终端或者主被叫终端都可以继续听到多媒体振铃音或多媒体回铃音，解决了现有技术中无法实现多媒体振铃音或多媒体回铃音在通话期间为用户继续播放的问题，以及多媒体振铃音或多媒体回铃音在通话期间转换为多媒体背景音的问题。

实施例十

本发明实施例还提供一种终端设备，以下结合附图对本实施例进行详细说明。

图11为本实施例的终端设备的组成结构框图，如图11所示，本实施例的终端设备主要包括请求标志发送单元111，用于向多媒体铃音服务器发送请求标志，所述请求标志用于请求多媒体铃音服务器在通话期间触发继续播放多媒体铃音。

根据本实施例，该请求标志发送单元111可以包括：

多媒体振铃音混频标志发送模块1111，用于向多媒体铃音服务器发送多媒体振铃音混频标志，所述多媒体振铃音混频标志用于请求多媒体铃音服务器对多媒体振铃音和主叫终端到被叫终端的通话媒体流进行混音/混频后播放。

根据本实施例，该请求标志发送单元111还可以包括：

多媒体回铃音混频标志发送模块1112，用于向多媒体铃音服务器发送多媒体回铃音混频标志，所述多媒体回铃音混频标志用于请求多媒体铃音服务器对多媒体回铃音和被叫终端到主叫终端的通话媒体流进行混音/混频后播放。

根据本实施例，该请求标志发送单元111还可以包括：

多媒体背景音混频标志发送模块1113，用于向多媒体铃音服务器发送多媒体背景音混频标志，所说多媒体背景音混频标志用于请求多媒体铃音服务器对多媒体回铃音或多媒体振铃音和主叫终端与被叫终端之间的通话媒体流进行混音/混频后播放。

根据本实施例，该请求标志发送单元111还可以包括：

多媒体铃音链接下载标志发送模块1114，用于向多媒体铃音服务器发送多媒体铃音链接下载标志，所述多媒体铃音链接下载标志用于请求多媒体铃音服务器下发多媒体铃音的链接，以下载该多媒体铃音后进行本地播放。

在本实施例中，所述终端设备还包括：多媒体铃音链接接收单元113，用于接收多媒体铃音服务器下发的多媒体铃音链接；多媒体铃音下载单元114，用于根据所述多媒体铃音链接下载所述多媒体铃音。

根据本实施例，该请求标志发送单元111还可以包括：

终端混频能力标志发送模块1115，用于向多媒体铃音服务器发送终端混频能力标志，所述终端混频能力标志用于请求多媒体铃音服务器继续播放多媒体铃音，并对多媒体铃音与接收到的通话媒体流混频后进行本地播放。

在本实施例中，所述终端设备还包括：混频单元115，用于对接收到的多媒体铃音和通话媒体流进行混频。

根据本实施例，所述终端设备还包括：

多媒体铃音播放单元116，用于播放多媒体铃音下载单元114下载的多媒体铃音或混频单元115混频后的多媒体铃音和通话媒体流。

通过本实施例的终端设备，使得通话过程中的主叫终端或者被叫终端或者主被叫终端都可以继续听到多媒体振铃音或多媒体回铃音，解决了现有技术中无法实现多媒体振铃音或多媒体回铃音在通话期间为用户继续播放的问题，以及多媒体振铃音或多媒体回铃音在通话期间转换为多媒体背景音的问题。

实施例十一

本实施例的网络架构与实施例三相同，不同之处在于在附图2网络架构中的CRS AS可以被替换为CTS AS，也可以同时部署CRS AS和CTS AS；此外，本实施例应用场景如下：主/被叫用户预先为对方(或为自己)订阅了彩铃/彩振，并且预先设置了呼叫过程中继续播放彩铃/彩振(该功能也可由运营商预先配置)，通话建立过程中，彩铃/彩振服务器会向主、被叫终端均发起会话更新，从而预留好通话过程中可以同时支持彩铃/彩振+通话的媒体资源；或者是，主/被叫用户预先为对方(或为自己)订阅了彩铃/彩振，但并未预先设置呼叫过程中继续播放彩铃/彩振的功能，通话建立过程中，主/被叫用户可以向彩铃/彩振服务器发送动态请求信息，以请求在通话过程中继续播放彩铃/彩振。

参见图12，具体流程如下：

步骤1201至步骤1202、主叫终端(UE-A)发起呼叫，向被叫终端(UE-B)发送呼叫请求(INVITE)消息，消息中携带了主叫终端的会话请求(sessionSDP Offer)；

步骤1203、被叫终端返回振铃(180)消息，消息中携带了被叫终端的会话应答(session SDP Answer)；

步骤1204、如果用户订阅了彩铃业务，则多媒体铃音服务器在振铃(180)消息中添加彩铃早期会话媒体请求(early-session SDP offer)，然后将振铃(180)消息转发给主叫终端；

步骤1205、主叫终端返回临时响应确认(PRACK)消息，如果振铃(180)消息中携带了彩铃早期会话媒体请求(early-session SDP offer)，则临时响应确认(PRACK)消息中会携带彩铃早期会话媒体应答(early-session SDPanswer)；

步骤1206、如果用户订阅了彩铃业务，则多媒体铃音服务器指示媒体资源功能(MRF)为主叫终端开始播放彩铃；

步骤1207、如果用户订阅了彩振业务，则多媒体铃音服务器接收到主叫终端发来的临时响应确认(PRACK)消息后，在其中添加彩振早期会话媒体请求(early-session SDP offer)，同时检查如果用户预先配置了通话中继续播放多媒体铃音的功能，则可以在临时响应确认(PRACK)中添加一个会话请求(session SDP offer)，该会话请求(session SDP offer)中包含了同时支持正常通话和多媒体铃音的媒体参数(注：如果根据用户的配置或动态请求判断出无需在通话过程中为被叫继续播放多媒体铃音而只需为主叫继续播放多媒体铃音，则该会话请求中只需包含用于正常通话的媒体参数即可)，而且该会话请求的IP地址和端口号均指向MRF。然后，多媒体铃音服务器将临时响应确认(PRACK)消息转发给被叫终端；

需要说明的是：步骤1207中的临时响应确认消息中的会话请求(sessionSDP offer)也可以由步骤1213的更新(UDPATE)消息中携带，相应的临时响应确认消息的成功响应(200OK(PRACK))消息中的会话请求(session SDPoffer)则可以由步骤1214的更新消息的成功响应200OK(UPDATE)消息携带；

步骤1208、UE-B接收到PRACK消息后，对其中的early-session和session资源均进行预留，并返回临时响应确认消息的成功响应(200OK(PRACK))消息，消息中携带了对收到的所有请求(offer)的应答；

步骤1209、多媒体铃音服务器将临时响应确认消息的成功响应(200OK(PRACK))转发给主叫终端；

步骤1210、多媒体铃音服务器指示媒体资源功能(MRF)向被叫终端播放彩振；

步骤1211、多媒体铃音服务器向主叫终端发送更新(UDPATE)消息，消息中携带了会话请求(session SDP offer)，其中包含了同时支持正常通话和多媒体铃音的媒体参数(注：如果根据用户的配置或动态请求判断出无需在通话过程中为主叫继续播放多媒体铃音而只需为被叫继续播放多媒体铃音，则该会话请求中只需包含用于正常通话的媒体参数即可)，而且该会话请求的IP地址和端口号均指向MRF；

步骤1212、主叫终端向多媒体铃音服务器返回更新消息的成功响应(200OK(UPDATE))消息，消息中携带了对请求(offer)的应答(answer)，此时主叫终端与媒体资源功能(MRF)之间就建立了会话通道；

步骤1213至1214、多媒体铃音服务器向被叫终端发送更新(UDPATE)

消息，消息中携带了会话请求(session SDP offer)，该请求中包含同时支持正常通话和多媒体铃音的媒体参数(注：如果根据用户的配置或动态请求判断出无需在通话过程中为被叫继续播放多媒体铃音而只需为主叫继续播放多媒体铃音，则该会话请求中只需包含用于正常通话的媒体参数即可)，而且该会话请求的IP地址和端口号均指向MRF。被叫终端返回更新消息的成功响应(200OK(UPDATE))消息，

消息中携带了对请求(offer)的应答(answer)；

需要说明的是：步骤1213、步骤1214两步消息的发送是可选的：即如果多媒体铃音服务器已经在1207消息中携带了会话请求(session SDPoffer)，则1213和1214两消息就可以不发送。但如果多媒体铃音服务器接收到了终端发来的继续多媒体铃音播放的动态请求，则应当发送1213和1214两消息。

步骤1215至步骤1218、被叫用户摘机，被叫终端发送摘机(200OK)消息，该消息途径多媒体铃音服务器，到达主叫终端。主叫终端返回确认(ACK)消息。通话建立；

步骤1219、多媒体铃音服务器指示媒体资源功能(MRF)开始对通话媒体流和多媒体铃音进行混音处理，从而实现继续为主叫、或被叫、或主被叫双方继续播放多媒体铃音的功能。

可以理解的：上述流程中只叙述了用户预先配置了通话中继续播放多媒体铃音的功能，其实该流程也适用于用户在通话建立之前动态请求多媒体铃音在通话中继续播放，用户的请求信息可以通过带内双音多频(DTMF)(即通过实时传输协议传输双音多频信号)或带外双音多频(即通过信令消息传输双音多频信号)来实现。多媒体铃音服务器接收到用户的动态请求信息后，会触发执行步骤1211、步骤1212、步骤1213和步骤1214四个步骤(即分别向主被叫终端发送更新(UPDATE)消息)来分别与主被叫终端建立会话；另外，在通话过程中(也可以在通话开始之前)，主/被叫终端可以向多媒体铃音服务器发送请求信息(例如通过带内或带外方式向多媒体铃音服务器发送双音多频信号)，请求服务器不要在通话过程中继续播放多媒体铃音、或者请求仅播放其中的一路媒体流、或者请求调节多媒体铃音的音量。服务器接收到请求信息后，根据请求信息指示媒体资源功能执行相应的动作即可。而且上述流程中的180(振铃)消息均可替换为183(会话进行中)消息。

本实施例提供的方法的优点在于实现了实现多媒体铃音在通话期间为用户继续播放的问题，当通话开始后，服务器可以继续为主被叫播放彩铃/彩振，无需任何更新或切换流程，没有任何延迟，本实施例是在现有的早期会话(early-session)模式基础上的方案，但现有的早期会话模式无任何影响，而且终端不支持早期会话模式时，服务器可以不执行本实施例中的会话更新操作，从而对正常的通话无任何影响，且无须用户在通话过程中参与任何操作，给用户带来一种全新的体验，有利于该技术的实现与推广。

实施例十二

本实施例的网络架构和实施例十一相同，此处不再赘述。应用场景如下：主/被叫用户预先为对方(或为自己)订阅了彩振/彩铃，并且预先设置了呼叫过程中继续播放彩振/彩铃(该功能也可由运营商预先配置)。当呼叫建立初始，彩振/彩铃服务器就执行本实施例的流程，即充当一个会议中心的角色，然后在通话建立之前为被叫播放彩振、或为主叫播放彩铃、也可以两者同时播放。当被叫摘机时，彩振/彩铃服务器在通话过程中继续为主叫、或被叫、或主被叫双方播放多媒体铃音。

参见图13，具体流程如下：

步骤1301、主叫终端(UE-A)向被叫终端(UE-B)发起呼叫请求，呼叫请求消息(INVITE)中携带了UE-A的会话请求(session offer)，INVITE消息根据初始过滤规则到达多媒体铃音服务器；

步骤1302、多媒体铃音服务器接收到呼叫请求(INVITE)消息后，将其中的SDP offer(会话请求)替换为媒体资源功能(MRF)的会话请求(sessionSDP offer)，其中包含了用于播放多媒体铃音的媒体参数和用于正常通话的媒体参数，而且该会话请求的IP地址和端口号均指向MRF，并在Require(需求)头域中添加100rel标志，然后将呼叫请求(INVITE)消息转发给被叫终端；

步骤1303、UE-B返回振铃(180)消息，消息中携带了被叫终端的会话应答(SDP Answer)；

步骤1304、多媒体铃音服务器此时指示媒体资源功能(MRF)为被叫终端播放彩振；

步骤1305、多媒体铃音服务器向UE-A返回振铃(180)消息，消息中携带了媒体资源功能(MRF)的会话应答(SDP Answer)；

步骤1306～步骤1309、主叫终端向被叫终端发送临时响应确认(PRACK)，UE-B向UE-A返回临时响应确认消息的成功响应(200OK(PRACK))消息；

步骤1310、多媒体铃音服务器向主叫终端发送更新(UDPATE)消息用于建立主叫终端与媒体资源功能(MRF)之间的会话，消息中携带了媒体资源功能(MRF)的请求(Offer)，请求中包含了用于播放多媒体铃音的媒体参数和用于正常通话的媒体参数，而且该会话请求的IP地址和端口号均指向MRF；

步骤1311、主叫终端向多媒体铃音服务器返回更新消息的成功响应(200OK(UPDATE))消息，消息中携带了主叫终端的会话应答(SDP Answer)；

步骤1312、此时多媒体铃音服务器可以指示媒体资源功能(MRF)为主叫终端播放彩铃；

步骤1313～步骤1316、被叫用户摘机，被叫终端向主叫终端发送200OK(INVITE)摘机消息。主叫终端向被叫终端返回ACK确认消息。通话建立；

步骤1317、多媒体铃音服务器指示媒体资源功能(MRF)开始进行混音处理，即对多媒体铃音和主被叫通话媒体进行混音。从而在通话过程中为主叫、或被叫、或主被叫双方继续播放多媒体铃音。

可以理解的：上述流程中的180(振铃)消息均可替换为183(会话进行中)消息；另外，在通话过程中(也可以在通话开始之前)，主/被叫终端可以向多媒体铃音服务器发送请求信息(例如通过带内或带外方式向多媒体铃音服务器发送双音多频信号)，请求服务器不要在通话过程中继续播放多媒体铃音、或者请求仅播放其中的一路媒体流、或者请求调节多媒体铃音的音量。服务器接收到请求信息后，根据请求信息指示媒体资源功能执行相应的动作即可。

本实施例提供的方法的优点在于实现了实现多媒体铃音在通话期间为用户继续播放的问题，此外，本实施例中服务器在呼叫建立初始即充当会议中心的角色，将主被叫终端分别接入到媒体资源功能，然后可以为主被叫播放彩铃/彩振，从而实现了一种新的彩铃、彩振播放模式。且当通话开始后，服务器可以继续为主被叫播放彩铃/彩振，无需任何更新或切换流程，没有任何延迟。

实施例十三

本实施例的网络架构和实施例十一相同，此处不再赘述。应用场景如下：主/被叫用户预先为对方(或为自己)订阅了彩铃/彩振，并且预先设置了呼叫过程中继续播放彩铃/彩振的功能(该功能也可由运营商预先配置)。当通话开始后，多媒体铃音服务器继续播放彩铃/彩振，主叫终端或被叫终端对多路媒体流进行混音处理，然后播放出来。

参见图14，具体流程如下：

步骤1401、主叫终端UE-A向被叫终端UE-B发起呼叫请求，呼叫请求消息(INVITE)中携带了UE-A的会话请求(session offer)，呼叫请求消息根据初始过滤规则到达多媒体铃音服务器；

步骤1402、如果用户预先配置了通话过程中继续播放彩振的业务，则多媒体铃音服务器接收到呼叫请求消息后，将消息体中添加通话过程中需要继续播放的多媒体铃音的媒体行，并将该媒体行的“c＝”行(地址行)设置为指向媒体资源功能(MRF)，相应的端口号也设置为媒体资源功能(MRF)提供的端口号；

步骤1403、被叫终端接收到呼叫请求消息后，对请求(SDP offer)中的通话媒体资源和多媒体铃音资源进行预留，并预留相应的用于混音的资源，然后返回180振铃消息，消息中携带了被叫终端的应答(answer)，该应答中包含了对正常通话请求的应答和对多媒体铃音请求的应答；

步骤1404、多媒体铃音服务器接收到180振铃消息后，将其中的用于应答多媒体铃音请求的媒体行提取出来，预留相应的媒体播放资源，这样就协商完成了通话过程中可以继续播放的多媒体铃音的会话。另外，如果用户订阅了彩铃业务，多媒体铃音服务器需要在180振铃消息中添加早期会话(early-session)类型的请求(offer)，然后将180振铃消息转发给主叫终端，用于与主叫终端协商彩铃早期媒体；

步骤1405、主叫终端返回临时响应确认(PRACK)消息，消息中携带了早期会话(early-session)类型的应答(SDP answer)，多媒体铃音服务器接收到临时响应确认(PRACK)消息后，将其中的应答(answer)提取出来，完成了彩铃早期媒体的协商；

步骤1406、如果用户订阅了彩振业务，多媒体铃音服务器需要在临时响应确认(PRACK)消息中添加早期会话(early-session)类型的请求(offer)，然后将该消息转发给被叫终端，用于与被叫终端协商彩振早期媒体；

步骤1407、被叫终端返回临时响应确认消息的成功响应(200OK(PRACK))消息，消息中携带了早期会话(early-session)类型的应答(answer)；

步骤1408～步骤1410、多媒体铃音服务器接收到临时响应确认消息的成功响应(200OK(PRACK))消息后，将其中的应答(answer)提取出来，完成了彩振早期媒体的协商，然后将该消息转发给主叫终端。此时，多媒体铃音服务器根据用户的订阅情况向被叫播放彩振，向主叫播放彩铃；

步骤1411、如果用户预先配置了通话过程中继续播放彩铃的业务，则多媒体铃音服务器向主叫终端发送更新(UPDATE)消息，消息中携带了会话(session)类型的请求(offer)，请求(offer)中包含了基于步骤1404中的180消息中会话应答(session SDP answer)的媒体行，还包含了用于在通话中播放多媒体铃音的媒体行；

步骤1412、主叫终端向多媒体铃音服务器返回更新消息的成功响应(200OK(UPDATE))消息，消息中携带了主叫终端的应答(answer)；

步骤1413～步骤1416、被叫用户摘机，被叫终端向主叫终端发送200OK(INVITE)摘机消息。主叫终端向被叫终端返回ACK确认消息。通话建立；

步骤1417～步骤1418、多媒体铃音服务器根据预先的配置策略，指示媒体资源功能继续为主叫播放彩铃、或继续为被叫播放彩振、或继续为主/被叫双方播放彩铃/彩振；

步骤1419、被叫终端在接收到媒体流时即开始对接收到的通话媒体流和多媒体铃音媒体流进行本地的混音处理并播放。

步骤1420、主叫终端在接收到媒体流时即开始对接收到的通话媒体流和多媒体铃音媒体流进行本地的混音处理并播放。

可以理解的：如果用户未预先设置通话过程中继续播放铃音的功能，则在通话建立之前，主叫终端可以向多媒体铃音服务器发送请求信息(例如通过带内或带外的双音多频信号)以动态请求通话中继续播放彩铃；相应的上述流程图中的步骤1411和步骤1412应当在服务器接收到主叫终端的动态请求信息时才触发；

另外，如果用户未预先设置通话过程中继续播放铃音的功能，则在通话建立之前，被叫终端可以向多媒体铃音服务器发送请求信息(例如通过带内或带外的双音多频信号)以动态请求通话中继续播放彩振。相应的上述流程图中的步骤1402消息中则只携带主叫终端的会话请求、步骤1403消息中只携带被叫终端的会话应答-1；而服务器应当在接收到被叫终端的动态请求信息时触发向被叫终端发送UPDATE更新消息，消息中携带主叫终端的会话请求和通话中需要继续播放的彩振的媒体行，被叫终端返回响应消息，消息中携带相应的应答；

在通话过程中(也可以在通话开始之前)，主/被叫终端可以向多媒体铃音服务器发送请求信息(例如通过带内或带外方式向多媒体铃音服务器发送双音多频信号)，请求服务器不要在通话过程中继续播放多媒体铃音、或者请求仅播放其中的一路媒体流、或者请求调节多媒体铃音的音量。服务器接收到请求信息后，根据请求信息指示媒体资源功能执行相应的动作即可。

上述流程中的180(振铃)消息均可替换为183(会话进行中)消息。

本实施例提供的方法的优点在于实现了实现多媒体铃音在通话期间为用户继续播放的问题，此外，本实施例无需服务器进行混音处理，没有增加网络负载；本实施例只需在会话协商消息中添加多媒体铃音媒体流即可，基本上没有增加新的会话流程，即对现有的彩铃/彩振业务流程的改动最小；而且当通话开始后，服务器可以继续为主被叫播放彩铃/彩振，无需任何更新或切换流程，没有任何延迟。

实施例十四

本实施例网络架构与应用场景与实施例十一相同，本实施例提供一种在通话期间播放多媒体铃音的方法，如图15所示，步骤如下：

步骤1501、多媒体铃音服务器分别向主叫终端和被叫终端发送会话更新请求以分别与主叫终端和被叫终端建立会话；

步骤502、当多媒体铃音服务器接收到所述被叫终端的摘机消息时，指示媒体资源功能执行混音处理，继续为主叫终端或被叫终端中至少一方播放多媒体铃音。

需要说明的是：所述方法执行触发条件包括：

当接收到主叫终端发来的呼叫请求消息时，根据运营商或用户预先的配置来触发执行；

或者在会话建立过程中，根据所述主叫终端或所述被叫终端发来的动态请求信息来触发执行。

所述会话更新请求的IP地址和端口号均指向媒体资源功能。

步骤1501具体包括：

向被叫终端发送的会话更新请求包括支持正常通话和多媒体铃音播放的媒体参数，向主叫终端发送的会话更新请求包括支持正常通话和多媒体铃音播放的媒体参数；或者，

向被叫终端发送的会话更新请求包括支持正常通话的媒体参数，向主叫终端发送的会话更新请求包括支持正常通话和多媒体铃音播放的媒体参数；或者，

向被叫终端发送的会话更新请求包括支持正常通话和多媒体铃音播放的媒体参数，向主叫终端发送的会话更新请求包括支持正常通话的媒体参数。

其中，向被叫终端发送的会话更新请求通过临时响应确认消息或更新消息携带；向主叫终端发送的会话更新请求通过更新消息来携带。

所述方法还包括：接收主叫终端或被叫终端发来的动态请求信息，以执行相应的处理，所述处理包括：禁止多媒体铃音中的一路或多路媒体流的播放、停止多媒体铃音的播放或调节多媒体铃音的音量。

本实施例提供的方法的优点在于实现了实现多媒体铃音在通话期间为用户继续播放的问题，当通话开始后，服务器可以继续为主被叫播放彩铃/彩振，无需任何更新或切换流程，没有任何延迟，本实施例是在现有的早期会话(early-session)模式基础上的方案，但现有的早期会话模式无任何影响，而且终端不支持早期会话模式时，服务器可以不执行本实施例中的会话更新操作，从而对正常的通话无任何影响，且无须用户在通话过程中参与任何操作，给用户带来一种全新的体验，有利于该技术的实现与推广。

实施例十五

本实施例网络架构与应用场景与实施例十二相同，本实施例提供一种在通话期间播放多媒体铃音的方法，如图16所示，步骤如下：

步骤1601、接收主叫终端发来的携带会话请求的呼叫请求消息，将所述会话请求替换为媒体资源功能会话请求，然后发送给被叫终端；

步骤1602、向主叫终端发送携带媒体资源功能会话请求的更新消息；

步骤1603、为主叫终端或被叫终端中至少一方播放多媒体铃音；

步骤1604、当接收到所述被叫终端的摘机消息时，指示媒体资源功能执行混音处理，继续主叫终端或被叫终端中至少一方播放多媒体铃音。

以上步骤的执行主体是多媒体铃音服务器；所述媒体资源功能会话请求包括：支持正常通话和多媒体铃音播放的媒体参数，且IP地址和端口号均指向媒体资源功能。

所述方法还包括：接收主叫终端或被叫终端发来的动态请求信息，以执行相应的处理，所述处理包括：禁止多媒体铃音中的一路或多路媒体流的播放、停止多媒体铃音的播放或调节多媒体铃音的音量。

本实施例提供的方法的优点在于实现了实现多媒体铃音在通话期间为用户继续播放的问题，此外，本实施例中服务器在呼叫建立初始即充当会议中心的角色，将主被叫终端分别接入到媒体资源功能，然后可以为主被叫播放彩铃/彩振，从而实现了一种新的彩铃、彩振播放模式。且当通话开始后，服务器可以继续为主被叫播放彩铃/彩振，无需任何更新或切换流程，没有任何延迟。

实施例十六

本实施例网络架构与应用场景与实施例十三相同，本实施例提供一种在通话期间播放多媒体铃音的方法，如图17所示，步骤如下：

步骤1701、向主叫终端或被叫终端中至少一方发送多媒体铃音会话请求，使接收到所述多媒体铃音会话请求的主叫终端或被叫终端中的一方或双方预留通话媒体资源、多媒体铃音资源和用于混音的资源；

步骤1702、当接收到所述被叫终端的摘机消息时，指示媒体资源功能继续为主叫终端或被叫终端中至少一方播放多媒体铃音，使主叫终端或被叫终端中的一方或双方在接收到媒体流时开始执行对通话媒体流和多媒体铃音媒体流的混音处理。

以上步骤的执行主体是多媒体铃音服务器；其中，所述多媒体铃音会话请求与正常通话会话请求同时存在于信令消息中。

所述方法执行触发条件包括：

当接收到主叫终端发来的呼叫请求消息时，根据运营商或用户预先的配置来触发执行；

或者在会话建立过程中，根据所述主叫终端或所述被叫终端发来的动态请求信息来触发执行。

所述多媒体铃音会话请求包括：支持多媒体铃音播放的媒体参数，且IP地址和端口号均指向媒体资源功能。

所述步骤1701中：向被叫终端发送的多媒体铃音会话请求可以通过呼叫请求消息、或更新消息来携带；向主叫终端发送的多媒体铃音会话请求通过更新消息来携带。

所述方法还包括：接收主叫终端或被叫终端发来的动态请求信息，以执行相应的处理，所述处理包括：禁止多媒体铃音中的一路或多路媒体流的播放、停止多媒体铃音的播放或调节多媒体铃音的音量。

本实施例提供的方法的优点在于实现了实现多媒体铃音在通话期间为用户继续播放的问题，此外，本实施例无需服务器进行混音处理，没有增加网络负载；本实施例只需在会话协商消息中添加多媒体铃音媒体流即可，基本上没有增加新的会话流程，即对现有的彩铃/彩振业务流程的改动最小；而且当通话开始后，服务器可以继续为主被叫播放彩铃/彩振，无需任何更新或切换流程，没有任何延迟。

实施例十七

本实施例网络架构与应用场景与实施例十三相同，本实施例提供一种在通话期间播放多媒体铃音的方法，如图18所示，步骤如下：

步骤1801、当接收到多媒体铃音服务器发送的多媒体铃音会话请求后，预留通话媒体资源、多媒体铃音资源和用于混音的资源；

步骤1802、返回多媒体铃音会话应答；

步骤1803、建立通话后，对接收到的通话媒体流和多媒体铃音媒体流进行混音。

以上步骤的执行主体是终端。

本实施例提供的方法的优点在于实现了实现多媒体铃音在通话期间为用户继续播放的问题，而且由终端本身实现混音处理，无需多媒体铃音服务器的任何改动。

实施例十八

本实施例提供一种多媒体铃音服务器，如图19所示，包括：

会话更新请求发送模块1901：用于分别向主叫终端和被叫终端发送会话更新请求以分别与主叫终端和被叫终端建立会话；

指示播放模块1902：用于当接收到所述被叫终端的摘机消息时，指示媒体资源功能执行混音处理，继续为主叫终端或被叫终端中至少一方播放多媒体铃音。

可选的所述服务器还包括：

处理模块：用于接收主叫终端或被叫终端发来的动态请求信息，以执行相应的处理，所述处理包括：禁止多媒体铃音中的一路或多路媒体流的播放、停止多媒体铃音的播放或调节多媒体铃音的音量。

本实施例提供另一种多媒体铃音服务器，如图20所示，包括：

呼叫请求消息接收模块2001：用于接收主叫终端发来的携带会话请求的呼叫请求消息，将所述会话请求替换为媒体资源功能会话请求，然后发送给被叫终端；

更新消息发送模块2002：用于向主叫终端发送携带媒体资源功能会话请求的更新消息；

多媒体铃音播放模块2003：用于为主叫终端或被叫终端中至少一方播放多媒体铃音；

指示混音模块2004：用于当接收到所述被叫终端的摘机消息时，指示媒体资源功能执行混音处理，继续主叫终端或被叫终端中至少一方播放多媒体铃音。

本实施例提供另一种多媒体铃音服务器，如图21所示，包括：

多媒体铃音会话请求发送模块2101：用于向主叫终端或被叫终端中至少一方发送多媒体铃音会话请求，使接收到所述多媒体铃音会话请求的主叫终端或被叫终端中的一方或双方预留通话媒体资源、多媒体铃音资源和用于混音的资源；

指示混音处理模块2102：用于当接收到所述被叫终端的摘机消息时，指示媒体资源功能继续为主叫终端或被叫终端中至少一方播放多媒体铃音，使主叫终端或被叫终端中的一方或双方在接收到媒体流时开始执行对通话媒体流和多媒体铃音媒体流的混音处理。

本实施例提供的多媒体铃音服务器的优点在于实现了实现多媒体铃音在通话期间为用户继续播放的问题。

实施例十九

本实施例提供一种终端，如图22所示，包括：

预留资源模块2201：用于当接收到多媒体铃音服务器发送的多媒体铃音会话请求后，预留通话媒体资源、多媒体铃音资源和用于混音的资源；

应答模块2202：用于返回多媒体铃音会话应答；

混音模块2203：用于建立通话后，对接收到的通话媒体流和多媒体铃音媒体流进行混音。

本实施例提供的终端的优点在于实现了实现多媒体铃音在通话期间为用户继续播放的问题，而且由终端本身实现混音处理，无需多媒体铃音服务器的任何改动。

对于被叫终端来说，在通话建立之前，所播放的彩振是由终端的speaker(即扬声器)播放出来的；通话建立之后，所继续播放的彩振是由终端的speaker或receiver(即听筒)播放出来的。

以上所述的具体实施例，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施例而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (21)

1.一种在通话期间播放多媒体铃音的方法，其特征在于，所述方法包括：

分别向主叫终端和被叫终端发送会话更新请求以分别与主叫终端和被叫终端建立会话；

当接收到所述被叫终端的摘机消息时，指示媒体资源功能执行混音处理，继续为主叫终端或被叫终端中至少一方播放多媒体铃音。

2.根据权利要求1所述的方法，其特征在于，所述方法执行触发条件包括：

当接收到主叫终端发来的呼叫请求消息时，根据运营商或用户预先的配置来触发执行；

或者在会话建立过程中，根据所述主叫终端或所述被叫终端发来的动态请求信息来触发执行。

3.根据权利要求1所述的方法，其特征在于，所述会话更新请求的IP地址和端口号均指向媒体资源功能。

4.根据权利要求3所述的方法，其特征在于，

向被叫终端发送的会话更新请求包括支持正常通话和多媒体铃音播放的媒体参数，向主叫终端发送的会话更新请求包括支持正常通话和多媒体铃音播放的媒体参数；或者，

向被叫终端发送的会话更新请求包括支持正常通话的媒体参数，向主叫终端发送的会话更新请求包括支持正常通话和多媒体铃音播放的媒体参数；或者，

向被叫终端发送的会话更新请求包括支持正常通话和多媒体铃音播放的媒体参数，向主叫终端发送的会话更新请求包括支持正常通话的媒体参数。

5.根据权利要求1至3任一项所述的方法，其特征在于，

向被叫终端发送的会话更新请求通过临时响应确认消息或更新消息携带；

向主叫终端发送的会话更新请求通过更新消息来携带。

6.根据权利要求1至3任一项所述的方法，其特征在于，所述方法还包括：

接收主叫终端或被叫终端发来的动态请求信息，以执行相应的处理，所述处理包括：禁止多媒体铃音中的一路或多路媒体流的播放、停止多媒体铃音的播放或调节多媒体铃音的音量。

7.一种在通话期间播放多媒体铃音的方法，其特征在于，所述方法包括：

接收主叫终端发来的携带会话请求的呼叫请求消息，将所述会话请求替换为媒体资源功能会话请求，然后发送给被叫终端；

向主叫终端发送携带媒体资源功能会话请求的更新消息；

为主叫终端或被叫终端中至少一方播放多媒体铃音；

当接收到所述被叫终端的摘机消息时，指示媒体资源功能执行混音处理，继续主叫终端或被叫终端中至少一方播放多媒体铃音。

8.根据权利要求7所述的方法，其特征在于，所述媒体资源功能会话请求包括：

支持正常通话和多媒体铃音播放的媒体参数，且IP地址和端口号均指向媒体资源功能。

9.根据权利要求7或8所述的方法，其特征在于，所述方法还包括：

接收主叫终端或被叫终端发来的动态请求信息，以执行相应的处理，所述处理包括：禁止多媒体铃音中的一路或多路媒体流的播放、停止多媒体铃音的播放或调节多媒体铃音的音量。

10.一种在通话期间播放多媒体铃音的方法，其特征在于，所述方法包括：

向主叫终端或被叫终端中至少一方发送多媒体铃音会话请求，使接收到所述多媒体铃音会话请求的主叫终端或被叫终端中的一方或双方预留通话媒体资源、多媒体铃音资源和用于混音的资源；

当接收到所述被叫终端的摘机消息时，指示媒体资源功能继续为主叫终端或被叫终端中至少一方播放多媒体铃音，使主叫终端或被叫终端中的一方或双方在接收到媒体流时开始执行对通话媒体流和多媒体铃音媒体流的混音处理。

11.根据权利要求10所述的方法，其特征在于，所述多媒体铃音会话请求与正常通话会话请求同时存在于信令消息中。

12.根据权利要求10所述的方法，其特征在于，所述方法执行触发条件包括：

当接收到主叫终端发来的呼叫请求消息时，根据运营商或用户预先的配置来触发执行；

或者在会话建立过程中，根据所述主叫终端或所述被叫终端发来的动态请求信息来触发执行。

13.根据权利要求10至12任一项所述的方法，其特征在于，所述多媒体铃音会话请求包括：

支持多媒体铃音播放的媒体参数，且IP地址和端口号均指向媒体资源功能。

14.根据权利要求10至12任一项所述的方法，其特征在于，

向被叫终端发送的多媒体铃音会话请求可以通过呼叫请求消息、或更新消息来携带；

向主叫终端发送的多媒体铃音会话请求通过更新消息来携带。

15.根据权利要求10至12任一项所述的方法，其特征在于，所述方法还包括：接收主叫终端或被叫终端发来的动态请求信息，以执行相应的处理，所述处理包括：禁止多媒体铃音中的一路或多路媒体流的播放、停止多媒体铃音的播放或调节多媒体铃音的音量。

16.一种在通话期间播放多媒体铃音的方法，其特征在于，所述方法包括：

当接收到多媒体铃音服务器发送的多媒体铃音会话请求后，预留通话媒体资源、多媒体铃音资源和用于混音的资源；

返回多媒体铃音会话应答；

建立通话后，对接收到的通话媒体流和多媒体铃音媒体流进行混音。

17.一种多媒体铃音服务器，其特征在于，所述服务器包括：

会话更新请求发送模块：用于分别向主叫终端和被叫终端发送会话更新请求以分别与主叫终端和被叫终端建立会话；

指示播放模块：用于当接收到所述被叫终端的摘机消息时，指示媒体资源功能执行混音处理，继续为主叫终端或被叫终端中至少一方播放多媒体铃音。

18.根据权利要求17所述的服务器，其特征在于，所述服务器还包括：

处理模块：用于接收主叫终端或被叫终端发来的动态请求信息，以执行相应的处理，所述处理包括：禁止多媒体铃音中的一路或多路媒体流的播放、停止多媒体铃音的播放或调节多媒体铃音的音量。

19.一种多媒体铃音服务器，其特征在于，所述服务器包括：

呼叫请求消息接收模块：用于接收主叫终端发来的携带会话请求的呼叫请求消息，将所述会话请求替换为媒体资源功能会话请求，然后发送给被叫终端；

更新消息发送模块：用于向主叫终端发送携带媒体资源功能会话请求的更新消息；

多媒体铃音播放模块：用于为主叫终端或被叫终端中至少一方播放多媒体铃音；

指示混音模块：用于当接收到所述被叫终端的摘机消息时，指示媒体资源功能执行混音处理，继续主叫终端或被叫终端中至少一方播放多媒体铃音。

20.一种多媒体铃音服务器，其特征在于，所述服务器包括：

多媒体铃音会话请求发送模块：用于向主叫终端或被叫终端中至少一方发送多媒体铃音会话请求，使接收到所述多媒体铃音会话请求的主叫终端或被叫终端中的一方或双方预留通话媒体资源、多媒体铃音资源和用于混音的资源；

指示混音处理模块：用于当接收到所述被叫终端的摘机消息时，指示媒体资源功能继续为主叫终端或被叫终端中至少一方播放多媒体铃音，使主叫终端或被叫终端中的一方或双方在接收到媒体流时开始执行对通话媒体流和多媒体铃音媒体流的混音处理。

21.一种终端，其特征在于，所述终端包括：

预留资源模块：用于当接收到多媒体铃音服务器发送的多媒体铃音会话请求后，预留通话媒体资源、多媒体铃音资源和用于混音的资源；

应答模块：用于返回多媒体铃音会话应答；

混音模块：用于建立通话后，对接收到的通话媒体流和多媒体铃音媒体流进行混音。

Images