一种播放视频彩铃的方法以及主叫用户设备与流程

本发明涉及通信领域，尤其涉及一种播放视频彩铃的方法以及主叫用户设备。

背景技术：

随着基于互联网协议多媒体子系统(Internet Protocol Multimedia Subsystem，IMS)的语音业务(Voice over Long Term Evolution，VoLTE)的引入，语音通话质量相比2/3G时代有了明显的提高，可提供高清语音通话和视频通话，而彩铃业务作为运营商最重要的语音增值业务，对比2/3G下的标清彩铃体验，VoLTE彩铃可以提供高清彩铃和视频彩铃体验。

但对于VoLTE视频彩铃的体验，在目前的解决方案下，只有主叫VoLTE用户按视频起呼方式拨打被叫VoLTE彩铃用户的场景下才能体验视频彩铃，即在视频通话的前提下才能体验视频彩铃，存在呼叫流程复杂，对网络承载要求较高的问题。

技术实现要素：

本发明实施例提供了一种播放视频彩铃的方法以及主叫用户设备，用于发起音频起呼，实现视频彩铃播放的功能。

本发明技术方案主要应用的是VoLTE基本网络组网架构，可包括：主叫用户设备，被叫用户设备，核心网和彩铃平台。其中，彩铃平台作为重要的电信增值业务平台，可包括彩铃应用服务器(RBT AS，Ring Back Tone Application Server)和彩铃媒体资源服务器(RBT MRS，Ring Back Tone Media Resource Server)。彩铃平台的信令面与核心网S-CSCF(Serving-Call session Control Function，服务类型的呼叫会话控制功能)相连，媒体面与SBC(Session Border Controller，会话边界控制)相连，为用户提供彩铃的媒体放音。

本发明实施例第一方面提供一种播放视频彩铃的方法，可包括：主叫用户设备向被叫用户设备发起音频呼叫；该主叫用户设备根据该音频呼叫与彩铃平台完成音频彩铃媒体协商之后，接收该彩铃平台发送的视频彩铃媒体协商信息；若该主叫用户设备支持视频彩铃媒体，则该主叫用户设备根据该视频彩铃媒体协商信息和该主叫用户设备的媒体能力信息，进行视频媒体协商，确定视频媒体协商结果；该主叫用户设备向该彩铃平台发送该视频媒体协商结果，该视频媒体协商结果用于该彩铃平台进行视频彩铃播放。

在本发明实施例中，主叫UE向被叫用户设备发起音频呼叫之后，先进行音频媒体协商，再进行视频媒体协商，实现音频起呼播放视频彩铃的功能。本发明解决了只有在用户发起视频通话的前提下才有可能体验视频彩铃的限制，基于本发明技术方案，可以解决VoLTE用户在发起语音通话的场景下也能体验视频彩铃，从而为VoLTE下的彩铃业务创新提供了良好的技术保障，也为彩铃能够创造和挖掘更大的商业价值。

结合本发明实施例的第一方面，在一种可能的实现方式中，该视频媒体协商结果包括该主叫用户设备支持视频彩铃媒体的信息，该主叫用户设备接收视频媒体的互联网协议IP地址、视频通道端口的信息和视频编/解码的信息。

在本发明实施例中，对视频媒体协商结果做了一个具体的说明，应理解，这里的视频媒体协商结果是由SDP协议携带的，视频媒体协商结果包括但不限于该主叫用户设备支持视频彩铃媒体的信息，该主叫用户设备接收视频媒体的互联网协议IP地址、视频通道端口的信息和视频编/解码的信息，主叫用户设备和彩铃平台根据视频媒体协商结果包括的信息传输视频媒体流信息。

本发明实施例第二方面提供一种播放视频彩铃的方法，可包括：彩铃平台接收主叫用户设备发起的音频呼叫；该彩铃平台根据该音频呼叫完成与该主叫用户设备的音频彩铃媒体协商之后，该彩铃平台向该主叫用户设备发送视频彩铃媒体协商信息；该彩铃平台接收该主叫用户设备发送的视频媒体协商结果；该彩铃平台根据该视频媒体协商结果，进行视频彩铃播放。

在本发明实施例中，主叫UE向被叫用户设备发起音频呼叫之后，彩铃平台获取音频呼叫，先进行音频媒体协商，再进行视频媒体协商，实现音频起呼播放视频彩铃的功能。本发明解决了只有在用户发起视频通话的前提下才有可能体验视频彩铃的限制，基于本发明技术方案，可以解决VoLTE用户在发起语音通话的场景下也能体验视频彩铃，从而为VoLTE下的彩铃业务创新提供了良好的技术保障，也为彩铃能够创造和挖掘更大的商业价值。

结合本发明实施例的第二方面，在第一种可能的实现方式中，该视频媒体协商结果包括该主叫用户设备支持视频彩铃媒体的信息，该主叫用户设备接收视频媒体的互联网协议IP地址、视频通道端口的信息和视频编/解码的信息。

在本发明实施例中，对视频媒体协商结果做了一个具体的说明，应理解，这里的视频媒体协商结果是由SDP协议携带的，视频媒体协商结果包括但不限于该主叫用户设备支持视频彩铃媒体的信息，该主叫用户设备接收视频媒体的互联网协议IP地址、视频通道端口的信息和视频编/解码的信息，主叫用户设备和彩铃平台根据视频媒体协商结果包括的信息传输视频媒体流信息。

结合本发明实施例的第二方面、第一种可能的实现方式，在第二种可能的实现方式中，该彩铃平台向主叫用户设备发送视频彩铃媒体协商信息，包括：若被叫用户设备开通视频彩铃业务或该彩铃平台确定播放视频彩铃，则该彩铃平台向该主叫用户设备发送该视频彩铃媒体协商信息。

在本发明实施例中，对彩铃平台发送视频彩铃媒体协商信息的条件作了进一步的限定，该彩铃平台完成音频彩铃媒体协商之后，若被叫用户设备开通视频彩铃业务或该彩铃平台确定播放视频彩铃，则该彩铃平台向该主叫用户设备发送该视频彩铃媒体协商信息。彩铃平台可以灵活的根据业务侧的控制决定是否要播放视频彩铃，若播放，则发送视频彩铃媒体协商信息。

本发明实施例第三方面提供一种播放视频彩铃的方法，可包括：主叫用户设备向被叫用户设备发起音频呼叫；该主叫用户设备接收彩铃平台发送的视频彩铃媒体协商信息；若该主叫用户设备支持视频彩铃媒体，则该主叫用户设备根据该视频彩铃媒体协商信息和该主叫用户设备的媒体能力信息，进行视频媒体协商，确定视频媒体协商结果；该主叫用户设备向该彩铃平台发送该视频媒体协商结果，该视频媒体协商结果用于该彩铃平台进行视频彩铃播放。

在本发明实施例中，主叫UE向被叫用户设备发起音频呼叫之后，直接将原有的音频媒体协商，替换为视频媒体协商，实现音频起呼播放视频彩铃的功能。减少一次音频媒体协商的过程，节约时间和网络资源。

结合本发明实施例的第三方面，在一种可能的实现方式中，该视频媒体协商结果包括该主叫用户设备支持视频彩铃媒体的信息，该主叫用户设备接收视频媒体的互联网协议IP地址、视频通道端口的信息和视频编/解码的信息。

在本发明实施例中，对视频媒体协商结果做了一个具体的说明，应理解，这里的视频媒体协商结果是由SDP协议携带的，视频媒体协商结果包括但不限于该主叫用户设备支持视频彩铃媒体的信息，该主叫用户设备接收视频媒体的互联网协议IP地址、视频通道端口的信息和视频编/解码的信息，主叫用户设备和彩铃平台根据视频媒体协商结果包括的信息传输视频媒体流信息。

本发明实施例第四方面提供一种播放视频彩铃的方法，可包括：彩铃平台接收主叫用户设备发起的音频呼叫；该彩铃平台向该主叫用户设备发送视频彩铃媒体协商信息；该彩铃平台接收该主叫用户设备发送的视频媒体协商结果；该彩铃平台根据该视频媒体协商结果，进行视频彩铃播放。

在本发明实施例中，主叫UE向被叫用户设备发起音频呼叫之后，直接将原有的音频媒体协商，替换为视频媒体协商，实现音频起呼播放视频彩铃的功能。减少一次音频媒体协商的过程，节约时间和网络资源。

结合本发明实施例的第四方面，在第一种可能的实现方式中，该视频媒体协商结果包括该主叫用户设备支持视频彩铃媒体的信息，该主叫用户设备接收视频媒体的互联网协议IP地址、视频通道端口的信息和视频编/解码的信息。

在本发明实施例中，对视频媒体协商结果做了一个具体的说明，应理解，这里的视频媒体协商结果是由SDP协议携带的，视频媒体协商结果包括但不限于该主叫用户设备支持视频彩铃媒体的信息，该主叫用户设备接收视频媒体的互联网协议IP地址、视频通道端口的信息和视频编/解码的信息，主叫用户设备和彩铃平台根据视频媒体协商结果包括的信息传输视频媒体流信息。

结合本发明实施例的第四方面、第一种可能的实现方式，在第二种可能的实现方式中，该彩铃平台向该主叫用户设备发送视频彩铃媒体协商信息，可包括：若被叫用户设备开通视频彩铃业务或该彩铃平台确定播放视频彩铃，则该彩铃平台向该主叫用户设备发送该视频彩铃媒体协商信息。

在本发明实施例中，对彩铃平台发送视频彩铃媒体协商信息的条件作了进一步的限定，若被叫用户设备开通视频彩铃业务或该彩铃平台确定播放视频彩铃，则该彩铃平台向该主叫用户设备发送该视频彩铃媒体协商信息。彩铃平台可以灵活的根据业务侧的控制决定是否要播放视频彩铃，若播放，则发送视频彩铃媒体协商信息。

本发明实施例第五方面提供一种主叫用户设备，具有实现对应于上述第一方面提供的实现视频播放的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。

本发明实施例第六方面提供一种彩铃平台，具有实现对应于上述第二方面提供的实现视频播放的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。

本发明实施例第七方面提供一种主叫用户设备，具有实现对应于上述第三方面提供的实现视频播放的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。

本发明实施例第八方面提供一种彩铃平台，具有实现对应于上述第四方面提供的实现视频播放的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。

本发明实施例第九方面提供一种主叫用户设备，可包括：收发器，处理器，该收发器和该处理器通过总线连接；

该收发器，用于向被叫用户设备发起音频呼叫；该主叫用户设备根据该音频呼叫与彩铃平台完成音频彩铃媒体协商之后，接收该彩铃平台发送的视频彩铃媒体协商信息；向该彩铃平台发送该视频媒体协商结果，该视频媒体协商结果用于该彩铃平台进行视频彩铃播放；

该处理器，用于若该主叫用户设备支持视频彩铃媒体，则该处理器根据该视频彩铃媒体协商信息和该主叫用户设备的媒体能力信息，进行视频媒体协商，确定视频媒体协商结果。

本发明实施例第十方面提供一种彩铃平台，可包括：收发器，处理器，该收发器和该处理器通过总线连接；

该收发器，用于接收主叫用户设备发起的音频呼叫；该彩铃平台根据音频呼叫完成与该主叫用户设备的音频彩铃媒体协商之后，该发送单元向该主叫用户设备发送视频彩铃媒体协商信息；接收该主叫用户设备发送的视频媒体协商结果；

该处理器，用于根据该视频媒体协商结果，进行视频彩铃播放。

本发明实施例第十一方面提供一种主叫用户设备，可包括：收发器，处理器，该收发器和该处理器通过总线连接；

该收发器，用于向被叫用户设备发起音频呼叫；接收彩铃平台发送的视频彩铃媒体协商信息；向该彩铃平台发送该视频媒体协商结果，该视频媒体协商结果用于该彩铃平台进行视频彩铃播放；

该处理器，用于若该主叫用户设备支持视频彩铃媒体，则该处理器根据该视频彩铃媒体协商信息和该主叫用户设备的媒体能力信息，进行视频媒体协商，确定视频媒体协商结果。

本发明实施例第十二方面提供一种彩铃平台，可包括：收发器，处理器，该收发器和该处理器通过总线连接；

该收发器，用于接收主叫用户设备发起的音频呼叫；向该主叫用户设备发送视频彩铃媒体协商信息；接收该主叫用户设备发送的视频媒体协商结果；

该处理器，用于根据该视频媒体协商结果，进行视频彩铃播放。

本发明实施例第十三方面提供一种系统，包括：主叫用户设备和彩铃平台；

所述主叫用户设备为执行上述第一方面及任一可能的实现方式中的主叫用户设备；

所述彩铃平台为执行上述第二方面及任一可能的实现方式中的彩铃平台。

本发明实施例第十四方面提供一种系统，包括：主叫用户设备和彩铃平台；

所述主叫用户设备为执行上述第三方面及任一可能的实现方式中的主叫用户设备；

所述彩铃平台为执行上述第四方面及任一可能的实现方式中的彩铃平台。

本发明实施例第十五方面提供一种存储介质，需要说明的是，本发的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产口的形式体现出来，该计算机软件产品存储在一个存储介质中，用于储存为上述设备所用的计算机软件指令，其包含用于执行上述第一方面、第二方面、第三方面或第四方面为设备所设计的程序。

该存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

从以上技术方案可以看出，本发明实施例具有以下优点：

在本发明实施例中，主叫用户设备向被叫用户设备发起音频呼叫；所述主叫用户设备根据所述音频呼叫与彩铃平台完成音频彩铃媒体协商之后，接收所述彩铃平台发送的视频彩铃媒体协商信息；若所述主叫用户设备支持视频彩铃媒体，则所述主叫用户设备根据所述视频彩铃媒体协商信息和所述主叫用户设备的媒体能力信息，进行视频媒体协商，确定视频媒体协商结果；所述主叫用户设备向所述彩铃平台发送所述视频媒体协商结果，所述视频媒体协商结果用于所述彩铃平台进行视频彩铃播放。实现了音频起呼的情况下，实现视频彩铃的功能，降低了视频彩铃呼叫流程的复杂度，减少了网络承载压力。

附图说明

为了更清楚地说明本发明实施例技术方案，下面将对实施例和现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1.a为本发明实施例中提供的一个系统架构示意图；

图1.b为本发明实施例中提供的会话描述协议SDP组网模型的示意图；

图2为本发明实施例中播放视频彩铃的方法的一个实施例示意图；

图3为本发明实施例中播放视频彩铃的方法的另一个实施例示意图；

图4为本发明实施例中播放视频彩铃的方法的另一个实施例示意图；

图5为本发明实施例中主叫用户设备的一个实施例示意图；

图6为本发明实施例中彩铃平台的一个实施例示意图；

图7为本发明实施例中主叫用户设备的另一个实施例示意图；

图8为本发明实施例中彩铃平台的另一个实施例示意图；

图9为本发明实施例中主叫用户设备的另一个实施例示意图；

图10为本发明实施例中彩铃平台的另一个实施例示意图。

具体实施方式

本发明实施例提供了一种播放视频彩铃的方法以及主叫用户设备，用于发起音频起呼，实现视频彩铃播放的功能。

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

本发明技术方案主要应用的VoLTE基本网络组网架构如图1所示，为本发明实施例的一个系统架构图，可包括：主叫用户设备，被叫用户设备，核心网和彩铃平台。其中，彩铃平台作为重要的电信增值业务平台，可包括彩铃应用服务器(RBT AS，Ring Back Tone Application Server)和彩铃媒体资源服务器(RBT MRS，Ring Back Tone Media Resource Server)，需要说明的是，RBT AS和RBT MRS可以是单独的实体，也可以集成在一起，逻辑上是相互独立的两个模块，位于被叫IMS域核心网侧。彩铃平台的信令面与核心网S-CSCF(Serving-Call session Control Function，服务类型的呼叫会话控制功能)相连，媒体面与SBC(Session Border Controller，会话边界控制)相连，为用户提供彩铃的媒体放音。

在图1.a所示的架构图中，主叫IMS域可包括主叫IMS域核心网和EPC(Evolved Packet Core，演进分组核心网)。在主叫IMS域核心网包括：HSS(Home Subscriber Server，归属用户服务器)，TAS(Telephony Application Server，电话应用服务器)，I/S-CSCF(I-CSCF，Interrogating-Call session Control Function，查询类型的呼叫会话控制)和SBC/P-CSCF(P-CSCF，Proxy-Call session Control Function，代理类型的呼叫会话控制功能)。EPC中包括S/P-GW(P-GW，public data network gateway，分组数据网网关，S-GW:serving gateway服务网关)和MME(Mobile Management Entity，移动管理实体)。

在被叫IMS域除了包括上述主叫IMS域中所说明的网元之外，还包括RBT AS/RBT MRS。需要说明的是，上述的说明并不构成对发明实施例的系统架构图的限定，本发明实施例的系统架构图包括但不限于在图1所示。

下面对上述中所提及的一些关键网元做一个简要的说明：

S-CSCF：英文全称：Serving-Call session Control Function，中文翻译：服务类型的呼叫会话控制功能，是IMS(IP多媒体子系统)核心网的中心节点，主要用于用户的注册、鉴权控制、会话路由和业务触发控制，并维持会话状态信息等。

I-CSCF：英文全称：Interrogating-Call session Control Function，中文翻译：查询类型的呼叫会话控制，是IMS网络的统一初步入口点，负责用户注册的S-CSCF的指配和查询等。

P-CSCF：英文全称：Proxy-Call session Control Function，中文翻译：代理类型的呼叫会话控制功能，是SIP(Session Initiation Protocol，会话初始协议)用户接入IMS网络的入口节点，主要负责信令和消息的代理等。

TAS：英文全称：Telephony Application Server，中文翻译：电话应用服务器)，MMTel AS(Multimedia Telephony Application Server，多媒体电话应用服务器)提供多媒体电话基本业务及补充业务；SCC AS(service centralization and continuity application server Application Server，连续性应用服务器)提供接入域选择T-ADS(terminating access domain selection，被叫接入域选)的能力以及和其他网元配合保证切换，即SRVCC(Single Radio Voice Call Continuity，单一无线制式语音呼叫连续性)和eSRVCC(Enhanced Single Radio Voice Call Continuity，增强的单一无线语音呼叫连续性)业务连续性。

HSS：Home Subscriber Server，归属用户服务器，是存储用户签约信息和位置信息的用户数据库系统。

SBC：Session Border Controller，会话边界控制，提供安全接入和媒体处理。

MME：Mobile Management Entity，移动管理实体，是EPC(Evolved Packet Core，演进分组核心网)网络的核心设备，提供了MME逻辑实体的功能。

S/P-GW:是EPC网络的核心设备，提供了服务网关(serving gateway，S-GW)和分组数据网网关(public data network gateway，P-GW)逻辑实体的功能。

RBT AS/RBT MRS：彩铃应用服务器和彩铃媒体资源服务器，信令面AS与IMS核心网S-CSCF相连，媒体面MRS与SBC相连，用于彩铃呼叫时负责接续被叫和触发彩铃放音。

IMS域彩铃SIP路由触发简述：

IMS域彩铃触发主要遵循的3GPP 24.182协议规范，采用被叫IMS域触发原则，当主叫IMS域发起的INVITE(请求)消息送至被叫IMS域S-CSCF后，被叫S-CSCF通过用户的iFC(initial Filter Criteria，初始过滤规则)签约信息，触发到彩铃平台，彩铃平台处理之后，呼叫消息回到S-CSCF，继续后续呼叫流程。彩铃平台收到被叫振铃消息(180)后启动向主叫用户的放音流程，当被叫摘机后，彩铃平台发起re-INVITE(重请求)流程，完成主被叫之间的媒体协商，并最终完成主、被叫用户之间的通话。

在现有技术中，主叫用户要想体验视频彩铃，只有在视频起呼被叫视频彩铃用户的条件下，才能体验视频彩铃，所以，对视频彩铃的普及造成了一定的限制。在本发明技术方案中，提出了一种音频起呼被叫视频彩铃用户，也能体验视频彩铃，提高了视频彩铃的应用。基于现有的VoLTE音频彩铃呼叫放音流程，本发明技术方案核心思路就是改变彩铃与主叫终端之间的媒体协商，用视频媒体替代音频媒体进行重协商，一种方法是在原流程音频媒体协商的基础上增加一次彩铃平台与主叫终端的视频媒体协商过程，另一种方法是直接用彩铃视频媒体协商替换原流程中彩铃音频媒体协商过程，相比第一种方法不再进行多一次的音频媒体协商过程。

在本发明技术方案中，所用到的协议主要为SDP(Session Description Protocol，会话描述协议)，用于两个会话实体之间的媒体协商，并达成一致，属信令语言族，采用文本(字符)描述形式。SDP组网模型主要是一个请求/响应模型(offer/answer)，如图1.b所示，包括请求/响应的实体和不同阶段的操作行为，如初始协商过程和重协商过程，并简单介绍消息中各种参数的含义。

Offer/Answer模型包括两个实体，一个是请求主体Offerer，另外一个是响应实体Answerer，两个实体只是在逻辑上进行区分，在一定条件下可以转换。例如，手机A发起媒体协商请求，那么A就是Offerer，反之如果A为接收请求则为Offerer。

Offerer发给Answerer的请求消息称为请求offer，内容包括媒体流类型、各个媒体流使用的编码集，以及将要用于接收媒体流的IP和端口等信息。Answerer收到offer之后，回复给Offerer的消息称为响应，内容包括要使用的媒体编码，是否接收该媒体流以及告诉Offerer其用于接收媒体流的IP和端口等信息。

现有彩铃呼叫流程主要参考Gateway Precondition(网关前置条件)和Gateway no-Precondition(网关非前置条件)两种模式，主要差异在于Precondition模式需要终端、核心网共同配合做预留资源，而no-Precondition模式则不需要。下面以实施例的方式，对本发明技术方案做一个说明。在本发明实施例中，彩铃平台包括的RBT AS和RBT MRS，逻辑上是两个独立的个体，也可以是集成在一起实现，也可以作为单独的个体实现，在下述的实施例示意图中以分别示出来进行说明。

(一)Gateway Precondition模式：

如图2所示，为本发明实施例中播放视频彩铃的方法的一个实施例示意图，包括：

201、主叫用户设备向被叫用户设备发起音频呼叫，并完成主叫UE和被叫UE的资源预留；

在本发明实施例中，主叫用户设备向被叫用户设备发起音频呼叫，并完成主叫用户设备和被叫用户设备的资源预留。本发明实施例应用的系统架构可包括主叫UE，被叫UE，S-CSCF，RBT AS和RBT MRS；其中被叫UE，S-CSCF，RBT AS和RBT MRS都属于被叫IMS域；RBT AS和RBT MRS可认为是彩铃平台。

具体的，可包括：1：主叫用户设备(User Equipment，UE)发出初始请求(Invite)消息，该Invite消息包括主叫UE的SDP会话描述协议信息和音频呼叫；

2：通过S-CSCF将Invite消息传输到RBT AS；

3：RBT AS收到Invite消息，再将该Invite消息发送到S-CSCF；

4：S-CSCF将Invite消息透传至被叫UE；

5：被叫UE接收到Invite消息后，返回183消息至S-CSCF，183消息包括被叫UE的会话描述协议信息，完成被叫UE的资源预留；

6：S-CSCF将183消息发送至RBT AS；

7：RBT AS再将183消息发送至S-CSCF；

8：S-CSCF将183消息发送至主叫UE；

9：主叫UE接收183消息之后，再返回确认(PRACK)消息；

10：通过S-CSCF将确认(PRACK)消息发送至RBT AS；

11：RBT AS再将确认(PRACK)消息返回至S-CSCF；

12：S-CSCF透传确认(PRACK)消息至被叫UE；

13：被叫UE接收确认(PRACK)消息之后，返回200消息，携带PRACK信息至S-CSCF；

14：S-CSCF将200消息发送至RBT AS；

15：RBT AS将200消息发送至S-CSCF；

16：S-CSCF将200消息发送至主叫UE；

17：主叫UE接收200消息，主叫资源预留成功，返回update消息，update消息包括主叫UE的SDP信息；

18：通过S-CSCF将update消息发送到RBT AS；

19：RBT AS将update消息返回至S-CSCF；

20：S-CSCF通过透传将update消息发送至被叫UE；

21：被叫UE接收update消息，返回200消息，200消息包括被叫UE的SDP信息；

22：S-CSCF接收200消息，将200消息发送至RBT AS；

23：RBT AS将200消息返回S-CSCF；

24：S-CSCF将200消息发送至主叫UE；

25：被叫UE发送180消息；

26：S-CSCF接收180消息，将180消息向RBT AS发送。

202、进行音频媒体协商；

在本发明实施例中，该步骤主要是主叫用户设备和彩铃平台完成音频媒体协商的过程。具体的，可包括：

27：RBT AS接收180消息；向RBT MRS发送Invite消息，Invite消息携带音频彩铃SDP信息，进行放音资源准备；

28：RBT MRS根据业务侧的控制判断此次音频呼叫是否要放视频彩铃；如果放视频彩铃，先返回200消息携带音频彩铃SDP信息，音频彩铃SDP信息也可称呼为音频彩铃媒体协商信息，进行音频媒体协商；如果业务侧控制不放视频彩铃，则保持原有音频起呼播放音频彩铃流程不变。或者，RBT MRS确定被叫UE是否开通视频彩铃业务，若开通，则返回200消息携带音频彩铃SDP信息进行音频媒体协商；

应理解，不是所有的音频起呼场景都需要播放视频彩铃，彩铃AS是否修改与主叫UE的音频媒体为视频媒体，还可以取决于彩铃业务管理侧的业务控制，该业务控制有许多方法，但核心思路都是判断此次呼叫是否满足视频媒体协商的条件。

29：RBT AS接收200消息，发起更新(update)消息，该update消息中携带音频彩铃SDP信息；

30：通过S-CSCF，向主叫UE传输update消息，该update消息中携带音频彩铃SDP信息；

31：主叫UE接收update消息，根据update消息中携带音频彩铃SDP信息和主叫UE的媒体能力信息，进行音频媒体协商，确定音频媒体协商结果，并发送200消息，200消息中携带该音频媒体协商结果；

32：通过S-CSCF将200消息传输至RBT AS；

33：RBT AS接收200消息，根据音频媒体协商结果向RBT MRS发送确认(ACK)消息。

下面以示例的形式，对音频彩铃SDP信息做一个说明，如下所示：

v＝0/*协议版本信息，此处为使用SDP版本号为0*/

o＝HuaWei 419 419IN IP4 10.137.2.197/*所有者/创建者和会话标识符(此处会话发起端的用户名为HuaWei；会话标识符为419；会话版本为419；网络类型为"IN"，表示"Internet"；地址类型目前定义了"IP4"、"IP6"，此处为IP4；地址为10.137.2.197。)*/

s＝Sip Call/*会话名称("s＝"域指示会话名，此处为Sip Call)*/

c＝IN IP4 10.135.66.188/*连接信息(网络类型：IN标识为"Internet"，地址类型：IP4，连接地址：10.135.66.188)*/

t＝0 0/*会话活动时间(开始、结束时间都为0，表示为持久会话)*/

m＝audio 34318RTP/AVP 104/*开始音频媒体信息描述。音频媒体数据将发送到34318端口，发送协议是基于UDP的RTP协议，格式为104(动态RTP载荷类型)*/

a＝rtpmap:104AMR-WB/16000/*对载荷类型104进行说明，为AMR-WB编码方式，采样时钟为16000Hz*/

a＝ptime:20/*媒体流打包时长，此处为20ms*/

a＝maxptime:240/*媒体流打包的最多时长，此处为240ms。*/

203、进行视频媒体协商；

在本发明实施例中，该步骤主要是主叫用户设备和彩铃平台完成视频媒体协商的过程。具体的，可包括：

34：RBT MRS接收确认(ACK)消息后，向RBT AS发起一次重请求(re-Invite)消息，re-Invite消息中包括视频彩铃SDP信息；

35：RBT AS接收重请求之后，再发起一次update消息，该update消息中携带视频彩铃SDP信息，视频彩铃SDP信息也可称呼为视频彩铃媒体协商信息；

36：通过S-CSCF，向主叫UE传输update消息，该update消息中携带视频彩铃SDP信息；

37：主叫UE接收update消息，若主叫UE支持视频彩铃媒体，根据update消息中携带视频彩铃SDP信息和主叫UE的媒体能力信息，进行视频媒体协商，确定视频媒体协商结果，并发送200消息，200消息中携带该视频媒体协商结果；

应理解，这里的视频媒体协商结果也是由SDP协议携带的，视频媒体协商结果包括但不限于所述主叫用户设备支持视频彩铃媒体的信息，所述主叫用户设备接收视频媒体的互联网协议IP地址、视频通道端口的信息和视频编/解码的信息。

38：通过S-CSCF将200消息传输至RBT AS；

39：RBT AS接收200消息，向RBT MRS发送该200消息，200消息中包括视频媒体协商结果；

40：RBT MRS收到200消息之后，根据视频媒体协商结果向RBT AS发送ACK消息。

下面以示例的形式，对视频彩铃SDP信息做一个说明，如下所示：

v＝0/*协议版本信息，此处为使用SDP版本号为0*/

o＝HuaWei 419 419IN IP4 10.137.2.197/*所有者/创建者和会话标识符(此处会话发起端的用户名为HuaWei；会话标识符为419；会话版本为419；网络类型为"IN"，表示"Internet"；地址类型目前定义了"IP4"、"IP6"，此处为IP4；地址为10.137.2.197。)*/

s＝Sip Call/*会话名称("s＝"域指示会话名，此处为Sip Call)*/

c＝IN IP4 10.135.66.188/*连接信息(网络类型：IN标识为"Internet"，地址类型：IP4，连接地址：10.135.66.188)*/

t＝0 0/*会话活动时间(开始、结束时间都为0，表示为持久会话)*/

m＝audio 34318RTP/AVP 104/*开始音频媒体信息描述。音频媒体数据将发送到34318端口，发送协议是基于UDP的RTP协议，格式为104(动态RTP载荷类型)*/

a＝rtpmap:104AMR-WB/16000/*对载荷类型104进行说明，为AMR-WB编码方式，采样时钟为16000Hz*/

a＝ptime:20/*媒体流打包时长，此处为20ms*/

a＝maxptime:240/*媒体流打包的最多时长，此处为240ms。*/

m＝video 5098RTP/AVP 102/*开始视频媒体信息描述。视频媒体数据将发送到5098端口，发送协议是基于UDP的RTP协议，格式为102*/

a＝rtpmap:102H264/90000/*对载荷类型102进行说明，为H264编码方式，采样时钟为90000Hz*/

a＝fmtp:102profile-level-id＝42801F；packetization-mode＝0/*进一步给出载荷类型102的参数为“profile-level-id＝42801F；packetization-mode＝0”。*/

204、主叫UE振铃。

在本发明实施例中，是主叫UE振铃的过程。具体的，可包括：

41：RBT AS发送180消息；

42：通过S-CSCF发送至主叫UE；

彩铃平台播放视频彩铃，主叫UE显示该视频彩铃。需要说明的是，RBT AS与RBT MRS之间的信令交互为彩铃平台内部模块间的交互流程，供参考。RBT AS与RBT MRS之间的信令交互不局限于上述流程中列举的方式，可以有多种实现，能完成从音频SDP到视频SDP的重协商过程的信令交互都可以。

在本发明实施例中，是在Gateway Precondition模式下，主叫UE发起音频呼叫之后，先进行音频媒体协商，再进行视频媒体协商，实现音频起呼播放视频彩铃的功能。本发明解决了只有在用户发起视频通话的前提下才有可能体验视频彩铃的限制，基于本发明技术方案，可以解决VoLTE用户在发起语音通话的场景下也能体验视频彩铃，从而为VoLTE下的彩铃业务创新提供了良好的技术保障，也为彩铃能够创造和挖掘更大的商业价值。

如图3所示，为本发明实施例中播放视频彩铃的方法的另一个实施例示意图，包括：

301、主叫用户设备向被叫用户设备发起音频呼叫，并完成主叫UE和被叫UE的资源预留；

在本发明实施例中，步骤301与图2所示的实施例中的步骤201相同，此处不再赘述。

302、进行视频媒体协商；

在本发明实施例中，该步骤主要是主叫用户设备和彩铃平台将音频媒体协商重置为视频媒体协商，并完成视频媒体协商的过程。具体的，可包括：

27：RBT AS接收180消息；向RBT MRS发送Invite消息，Invite消息携带音频彩铃SDP信息，进行放音资源准备；

28：RBT MRS根据业务侧的控制判断此次音频呼叫是否要放视频彩铃，如果放视频彩铃，通过183消息携带音频彩铃SDP信息应答音频主叫offer；如果业务侧控制不允许放视频彩铃，则保持原有音频起呼播放音频彩铃流程不变；或者，RBT MRS确定被叫UE是否开通视频彩铃业务，若开通，通过183消息携带音频彩铃SDP信息应答音频主叫offer。

应理解，不是所有的音频起呼场景都需要播放视频彩铃，彩铃AS是否修改与主叫UE的音频媒体为视频媒体，还可以取决于彩铃业务管理侧的业务控制，该业务控制有许多方法，但核心思路都是判断此次呼叫是否满足视频媒体协商的条件。

29：RBT MRS再回复200消息携带视频彩铃SDP信息，指示RBT AS直接使用视频彩铃SDP信息与主叫UE进行媒体协商；

30：RBT AS接收200消息之后，发起更新(update)消息，该update消息中携带视频彩铃SDP信息，视频彩铃SDP信息也可称呼为视频彩铃媒体协商信息；

31：通过S-CSCF，向主叫UE传输update消息，该update消息中携带视频彩铃SDP信息；

32：主叫UE接收update消息后，若主叫UE支持视频彩铃媒体，根据update消息中携带视频彩铃SDP信息和主叫UE的媒体能力信息，进行视频媒体协商，确定视频媒体协商结果，并发送200消息，200消息中携带该视频媒体协商结果；

应理解，这里的视频媒体协商结果也是由SDP协议携带的，视频媒体协商结果包括但不限于所述主叫用户设备支持视频彩铃媒体的信息，所述主叫用户设备接收视频媒体的互联网协议IP地址、视频通道端口的信息和视频编/解码的信息。

33：通过S-CSCF将200消息传输至RBT AS；

34：RBT AS接收200消息，向RBT MRS发送该ACK消息，ACK消息中包括视频媒体协商结果。

下面以示例的形式，对视频彩铃SDP信息做一个说明，如下所示：

v＝0/*协议版本信息，此处为使用SDP版本号为0*/

o＝HuaWei 419 419IN IP4 10.137.2.197/*所有者/创建者和会话标识符(此处会话发起端的用户名为HuaWei；会话标识符为419；会话版本为419；网络类型为"IN"，表示"Internet"；地址类型目前定义了"IP4"、"IP6"，此处为IP4；地址为10.137.2.197。)*/

s＝Sip Call/*会话名称("s＝"域指示会话名，此处为Sip Call)*/

c＝IN IP4 10.135.66.188/*连接信息(网络类型：IN标识为"Internet"，地址类型：IP4，连接地址：10.135.66.188)*/

t＝0 0/*会话活动时间(开始、结束时间都为0，表示为持久会话)*/

m＝audio 34318RTP/AVP 104/*开始音频媒体信息描述。音频媒体数据将发送到34318端口，发送协议是基于UDP的RTP协议，格式为104(动态RTP载荷类型)*/

a＝rtpmap:104AMR-WB/16000/*对载荷类型104进行说明，为AMR-WB编码方式，采样时钟为16000Hz*/

a＝ptime:20/*媒体流打包时长，此处为20ms*/

a＝maxptime:240/*媒体流打包的最多时长，此处为240ms。*/

m＝video 5098RTP/AVP 102/*开始视频媒体信息描述。视频媒体数据将发送到5098端口，发送协议是基于UDP的RTP协议，格式为102*/

a＝rtpmap:102H264/90000/*对载荷类型102进行说明，为H264编码方式，采样时钟为90000Hz*/

a＝fmtp:102profile-level-id＝42801F；packetization-mode＝0/*进一步给出载荷类型102的参数为“profile-level-id＝42801F；packetization-mode＝0”。*/

303、主叫UE振铃。

在本发明实施例中，是主叫UE振铃的过程。具体的，可包括：

35：RBT AS发送180消息；

36：通过S-CSCF发送至主叫UE。

彩铃平台播放视频彩铃，主叫UE显示视频彩铃。需要说明的是，RBT AS与RBT MRS之间的信令交互为彩铃平台内部模块间的交互流程，供参考。RBT AS与RBT MRS之间的信令交互不局限于上述流程中列举的方式，可以有多种实现，能完成视频媒体协商过程的信令交互都可以。

在本发明实施例中，是在Gateway Precondition模式下，主叫UE发起音频呼叫之后，直接将原有的音频媒体协商，替换为视频媒体协商，实现音频起呼播放视频彩铃的功能。相对于图2所示的实施例，减少一次音频媒体协商的过程，节约时间和网络资源。

(二)Gateway no-Precondition模式：

如图4所示，为本发明实施例中播放视频彩铃的方法的另一个实施例示意图，包括：

401、主叫用户设备向被叫用户设备发起音频呼叫；

本发明实施例应用的系统架构可包括主叫UE，被叫UE，S-CSCF，RBT AS和RBT MRS；其中被叫UE，S-CSCF，RBT AS和RBT MRS都属于被叫IMS域；RBT AS和RBT MRS可认为是彩铃平台。

主叫用户设备向被叫用户设备发起音频呼叫，具体的，可包括：

1：主叫用户设备(User Equipment，UE)发出初始请求(Invite)消息，该Invite消息包括主叫UE的SDP会话描述协议信息和音频呼叫；

2：通过S-CSCF将Invite消息传输到RBT AS；

3：RBT AS收到Invite消息，再将该Invite消息发送到S-CSCF；

4：S-CSCF将Invite消息透传至被叫UE；

5：被叫UE接收到Invite消息后，返回180消息至S-CSCF；

6：S-CSCF接收180消息，并向RBT AS发送180消息。

402、进行视频媒体协商；

在本发明实施例中，该步骤主要是主叫用户设备和彩铃平台完成视频媒体协商的过程。具体的，可包括：

7：RBT AS接收180消息；向RBT MRS发送Invite消息，Invite消息携带音频彩铃SDP信息，进行放音资源准备；

8：RBT MRS根据业务侧的控制判断此次音频呼叫是否要放视频彩铃；如果放视频彩铃，先返回200消息携带音频彩铃SDP信息，音频彩铃SDP信息也可称呼为音频彩铃媒体协商信息，进行音频媒体协商；如果业务侧控制不放视频彩铃，则保持原有音频起呼播放音频彩铃流程不变。或者，RBT MRS确定被叫UE是否开通视频彩铃业务，若开通，则返回200消息携带音频彩铃SDP信息进行音频媒体协商；

应理解，不是所有的音频起呼场景都需要播放视频彩铃，彩铃AS是否修改与主叫UE的音频媒体为视频媒体，还可以取决于彩铃业务管理侧的业务控制，该业务控制有许多方法，但核心思路都是判断此次呼叫是否满足视频媒体协商的条件。

9：RBT AS接收200消息，发起183消息，该183消息中携带音频彩铃SDP信息；

10：通过S-CSCF，向主叫UE传输183消息，该183消息中携带音频彩铃SDP信息；

11：主叫UE接收183消息，根据183消息中携带音频彩铃SDP信息和主叫UE的媒体能力信息，进行音频媒体协商，确定音频媒体协商结果，并发送PRACK消息；

12：通过S-CSCF将PRACK消息传输至RBT AS；

13：RBT AS接收PRACK消息，向S-CSCF发送200消息，200消息中携带PRACK消息；

14：通过S-CSCF向主叫UE发送200消息，200消息中携带PRACK消息。

15：RBT AS发送ACK消息至RBT MRS；

16：RBT MRS接收确认(ACK)消息后，向RBT AS发起一次重请求(re-Invite)消息，re-Invite消息中包括视频彩铃SDP信息；

17：RBT AS接收重请求之后，发起update消息，该update消息中携带视频彩铃SDP信息，视频彩铃SDP信息也可称呼为视频彩铃媒体协商信息；

18：通过S-CSCF，向主叫UE传输update消息，该update消息中携带视频彩铃SDP信息；

19：主叫UE接收update消息，若主叫UE支持视频彩铃媒体，根据update消息中携带视频彩铃SDP信息和主叫UE的媒体能力信息，进行视频媒体协商，确定视频媒体协商结果，并发送200消息，200消息中携带该视频媒体协商结果；

应理解，这里的视频媒体协商结果也是由SDP协议携带的，视频媒体协商结果包括但不限于所述主叫用户设备支持视频彩铃媒体的信息，所述主叫用户设备接收视频媒体的互联网协议IP地址、视频通道端口的信息和视频编/解码的信息。

20：通过S-CSCF将200消息传输至RBT AS；

21：RBT AS接收200消息，向RBT MRS发送该200消息，200消息中包括视频媒体协商结果；

22：RBT MRS收到200消息之后，根据视频媒体协商结果向RBT AS发送ACK消息。

下面以示例的形式，对视频彩铃SDP信息做一个说明，如下所示：

v＝0/*协议版本信息，此处为使用SDP版本号为0*/

o＝HuaWei 419 419IN IP4 10.137.2.197/*所有者/创建者和会话标识符(此处会话发起端的用户名为HuaWei；会话标识符为419；会话版本为419；网络类型为"IN"，表示"Internet"；地址类型目前定义了"IP4"、"IP6"，此处为IP4；地址为10.137.2.197。)*/

s＝Sip Call/*会话名称("s＝"域指示会话名，此处为Sip Call)*/

c＝IN IP4 10.135.66.188/*连接信息(网络类型：IN标识为"Internet"，地址类型：IP4，连接地址：10.135.66.188)*/

t＝0 0/*会话活动时间(开始、结束时间都为0，表示为持久会话)*/

m＝audio 34318RTP/AVP 104/*开始音频媒体信息描述。音频媒体数据将发送到34318端口，发送协议是基于UDP的RTP协议，格式为104(动态RTP载荷类型)*/

a＝rtpmap:104AMR-WB/16000/*对载荷类型104进行说明，为AMR-WB编码方式，采样时钟为16000Hz*/

a＝ptime:20/*媒体流打包时长，此处为20ms*/

a＝maxptime:240/*媒体流打包的最多时长，此处为240ms。*/

m＝video 5098RTP/AVP 102/*开始视频媒体信息描述。视频媒体数据将发送到5098端口，发送协议是基于UDP的RTP协议，格式为102*/

a＝rtpmap:102H264/90000/*对载荷类型102进行说明，为H264编码方式，采样时钟为90000Hz*/

a＝fmtp:102profile-level-id＝42801F；packetization-mode＝0/*进一步给出载荷类型102的参数为“profile-level-id＝42801F”；packetization-mode＝0。*/

403、主叫UE振铃。

在本发明实施例中，是主叫UE振铃的过程。具体的，可包括：

23：RBT AS发送180消息；

24：通过S-CSCF发送至主叫UE；

彩铃平台播放视频彩铃，主叫UE显示该视频彩铃。需要说明的是，RBT AS与RBT MRS之间的信令交互为彩铃平台内部模块间的交互流程，供参考。

在本发明实施例中，提供的是在Gateway no-Precondition模式下，主叫UE发起音频呼叫之后，直接将原有的音频媒体协商，替换为视频媒体协商，实现音频起呼播放视频彩铃的功能一个实施例。相对于图2所示的实施例，提供的是在Gateway no-Precondition模式下，一种可实现的方案，并且减少一次音频媒体协商的过程，节约时间和网络资源。

上面对本发明实施例中的播放视频彩铃的方法进行了描述，下面对本发明实施例中的主叫用户设备和彩铃平台分别进行描述。

如图5所示，为本发明实施例中的主叫用户设备的一个实施例示意图，包括：

发送单元501，用于向被叫用户设备发起音频呼叫；

接收单元502，用于主叫用户设备根据音频呼叫与彩铃平台完成音频彩铃媒体协商之后，接收彩铃平台发送的视频彩铃媒体协商信息；

处理单元503，用于若主叫用户设备支持视频彩铃媒体，则处理单元根据视频彩铃媒体协商信息和主叫用户设备的媒体能力信息，进行视频媒体协商，确定视频媒体协商结果；

发送单元501，还用于向彩铃平台发送视频媒体协商结果，视频媒体协商结果用于彩铃平台进行视频彩铃播放。

可选的，在本发明的一些实施例中，视频媒体协商结果包括主叫用户设备支持视频彩铃媒体的信息，主叫用户设备接收视频媒体的互联网协议IP地址、视频通道端口的信息和视频编/解码的信息。

如图6所示，为本发明实施例中的彩铃平台的一个实施例示意图，包括：

接收单元601，用于接收主叫用户设备发起的音频呼叫；

发送单元602，用于彩铃平台根据音频呼叫完成与主叫用户设备的音频彩铃媒体协商之后，发送单元向主叫用户设备发送视频彩铃媒体协商信息；

接收单元601，还用于接收主叫用户设备发送的视频媒体协商结果；

处理单元603，用于根据视频媒体协商结果，进行视频彩铃播放。

可选的，在本发明的一些实施例中，视频媒体协商结果包括主叫用户设备支持视频彩铃媒体的信息，主叫用户设备接收视频媒体的互联网协议IP地址、视频通道端口的信息和视频编/解码的信息。

可选的，在本发明的一些实施例中，

发送单元602，具体用于若被叫用户设备开通视频彩铃业务或彩铃平台确定播放视频彩铃，则发送单元向主叫用户设备发送视频彩铃媒体协商信息。

如图7所示，为本发明实施例中的彩铃平台的另一个实施例示意图，包括：

发送单元701，用于向被叫用户设备发起音频呼叫；

接收单元702，用于接收彩铃平台发送的视频彩铃媒体协商信息；

处理单元703，用于若主叫用户设备支持视频彩铃媒体，则处理单元根据视频彩铃媒体协商信息和主叫用户设备的媒体能力信息，进行视频媒体协商，确定视频媒体协商结果；

发送单元701，还用于向彩铃平台发送视频媒体协商结果，视频媒体协商结果用于彩铃平台进行视频彩铃播放。

可选的，在本发明的一些实施例中，视频媒体协商结果包括主叫用户设备支持视频彩铃媒体的信息，主叫用户设备接收视频媒体的互联网协议IP地址、视频通道端口的信息和视频编/解码的信息。

如图8所示，为本发明实施例中的彩铃平台的另一个实施例示意图，包括：

接收单元801，用于接收主叫用户设备发起的音频呼叫；

发送单元802，用于向主叫用户设备发送视频彩铃媒体协商信息；

接收单元801，还用于接收主叫用户设备发送的视频媒体协商结果；

处理单元803，用于根据视频媒体协商结果，进行视频彩铃播放。

可选的，在本发明的一些实施例中，视频媒体协商结果包括主叫用户设备支持视频彩铃媒体的信息，主叫用户设备接收视频媒体的互联网协议IP地址、视频通道端口的信息和视频编/解码的信息。

可选的，在本发明的一些实施例中，

发送单元802，具体用于若被叫用户设备开通视频彩铃业务或彩铃平台确定播放视频彩铃，则发送单元向主叫用户设备发送视频彩铃媒体协商信息。

如图9所示，为本发明实施例中的主叫用户设备的另一个实施例示意图，包括：

图9示出的是与本发明实施例提供的主叫用户设备，即手机的相关部分结构的框图。参考图9，手机包括：射频(Radio Frequency，RF)电路910、存储器920、输入单元930、显示单元940、传感器950、音频电路960、无线保真(wireless fidelity，WiFi)模块970、处理器980、以及电源990等部件。本领域技术人员可以理解，图9中示出的手机结构并不构成对手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图9对手机的各个构成部件进行具体的介绍：

RF电路910可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，给处理器980处理；另外，将设计上行的数据发送给基站。通常，RF电路910包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(Low Noise Amplifier，LNA)、双工器等。此外，RF电路910还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统(Global System of Mobile communication，GSM)、通用分组无线服务(General Packet Radio Service，GPRS)、码分多址(Code Division Multiple Access，CDMA)、宽带码分多址(Wideband Code Division Multiple Access,WCDMA)、长期演进(Long Term Evolution，LTE)、电子邮件、短消息服务(Short Messaging Service，SMS)等。

存储器920可用于存储软件程序以及模块，处理器980通过运行存储在存储器920的软件程序以及模块，从而执行手机的各种功能应用以及数据处理。存储器920可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器920可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

输入单元930可用于接收输入的数字或字符信息，以及产生与手机的用户设置以及功能控制有关的键信号输入。具体地，输入单元930可包括触控面板931以及其他输入设备932。触控面板931，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板931上或在触控面板931附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触控面板931可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器980，并能接收处理器980发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板931。除了触控面板931，输入单元930还可以包括其他输入设备932。具体地，其他输入设备932可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元940可用于显示由用户输入的信息或提供给用户的信息以及手机的各种菜单。显示单元940可包括显示面板941，可选的，可以采用液晶显示器(Liquid Crystal Display，LCD)、有机发光二极管(Organic Light-Emitting Diode,OLED)等形式来配置显示面板941。进一步的，触控面板931可覆盖显示面板941，当触控面板931检测到在其上或附近的触摸操作后，传送给处理器980以确定触摸事件的类型，随后处理器980根据触摸事件的类型在显示面板941上提供相应的视觉输出。虽然在图9中，触控面板931与显示面板941是作为两个独立的部件来实现手机的输入和输入功能，但是在某些实施例中，可以将触控面板931与显示面板941集成而实现手机的输入和输出功能。

手机还可包括至少一种传感器950，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板941的亮度，接近传感器可在手机移动到耳边时，关闭显示面板941和/或背光。作为运动传感器的一种，加速计传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于手机还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

音频电路960、扬声器961，传声器962可提供用户与手机之间的音频接口。音频电路960可将接收到的音频数据转换后的电信号，传输到扬声器961，由扬声器961转换为声音信号输出；另一方面，传声器962将收集的声音信号转换为电信号，由音频电路960接收后转换为音频数据，再将音频数据输出处理器980处理后，经RF电路910以发送给比如另一手机，或者将音频数据输出至存储器920以便进一步处理。

WiFi属于短距离无线传输技术，手机通过WiFi模块970可以帮助用户收发、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图9示出了WiFi模块970，但是可以理解的是，其并不属于手机的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。

处理器980是手机的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器920内的软件程序和/或模块，以及调用存储在存储器920内的数据，执行手机的各种功能和处理数据，从而对手机进行整体监控。可选的，处理器980可包括一个或多个处理单元；优选的，处理器980可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器980中。

手机还包括给各个部件供电的电源990(比如电池)，优选的，电源可以通过电源管理系统与处理器980逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

尽管未示出，手机还可以包括摄像头、蓝牙模块等，在此不再赘述。

在本发明的一个实施例中，该主叫用户设备所包括的RF电路910还具有以下功能：向被叫用户设备发起音频呼叫；主叫用户设备根据音频呼叫与彩铃平台完成音频彩铃媒体协商之后，接收彩铃平台发送的视频彩铃媒体协商信息；向彩铃平台发送视频媒体协商结果，视频媒体协商结果用于彩铃平台进行视频彩铃播放；

处理器980还具有以下功能：若主叫用户设备支持视频彩铃媒体，则处理器980根据视频彩铃媒体协商信息和主叫用户设备的媒体能力信息，进行视频媒体协商，确定视频媒体协商结果。

在本发明的另一个实施例中，该主叫用户设备所包括的RF电路910还具有以下功能：发起向被叫用户设备音频呼叫；接收彩铃平台发送的视频彩铃媒体协商信息；向彩铃平台发送视频媒体协商结果，视频媒体协商结果用于彩铃平台进行视频彩铃播放；

处理器980还具有以下功能：若主叫用户设备支持视频彩铃媒体，则处理器980根据视频彩铃媒体协商信息和主叫用户设备的媒体能力信息，进行视频媒体协商，确定视频媒体协商结果。

如图10所示，为本发明实施例中的彩铃平台的另一个实施例示意图，包括：

该彩铃平台可因配置或性能不同而产生比较大的差异，可以包括收发器1001，一个或一个以上中央处理器(central processing units，CPU)1002(例如，一个或一个以上处理器)和存储器1003，一个或一个以上存储应用程序10041或数据10042的存储介质1004(例如一个或一个以上海量存储设备)。其中，存储器1003和存储介质1004可以是短暂存储或持久存储。存储在存储介质1004的程序可以包括一个或一个以上模块(图10中没示出)，每个模块可以包括对彩铃平台中的一系列指令操作。更进一步地，中央处理器1002可以设置为与存储介质1004通信，在彩铃平台上执行存储介质1004中的一系列指令操作。

在本发明的一个实施例中，收发器1001还具有如下功能：用于接收主叫用户设备发起的音频呼叫；用于彩铃平台根据音频呼叫完成与主叫用户设备的音频彩铃媒体协商之后，收发器向主叫用户设备发送视频彩铃媒体协商信息；还用于接收主叫用户设备发送的视频媒体协商结果；

中央处理器1002还具有如下功能：用于根据视频媒体协商结果，进行视频彩铃播放。

可选的，在本发明的一些实施例中，

收发器1001，具体用于若被叫用户设备开通视频彩铃业务或彩铃平台确定播放视频彩铃，则收发器向主叫用户设备发送视频彩铃媒体协商信息。

在本发明的另一个实施例中，收发器1001还具有如下功能：用于接收主叫用户设备发起的音频呼叫；用于向主叫用户设备发送视频彩铃媒体协商信息；还用于接收主叫用户设备发送的视频媒体协商结果；

中央处理器1002还具有如下功能：根据视频媒体协商结果，进行视频彩铃播放。

可选的，在本发明的一些实施例中，

收发器1001，具体还用于若被叫用户设备开通视频彩铃业务或彩铃平台确定播放视频彩铃，则收发器向主叫用户设备发送视频彩铃媒体协商信息。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。