CN101754489A - 多媒体彩振业务实现方法、多媒体彩振服务器及用户设备 - Google Patents
多媒体彩振业务实现方法、多媒体彩振服务器及用户设备 Download PDFInfo
- Publication number
- CN101754489A CN101754489A CN200810223750A CN200810223750A CN101754489A CN 101754489 A CN101754489 A CN 101754489A CN 200810223750 A CN200810223750 A CN 200810223750A CN 200810223750 A CN200810223750 A CN 200810223750A CN 101754489 A CN101754489 A CN 101754489A
- Authority
- CN
- China
- Prior art keywords
- message
- multimedia
- request
- color vibration
- crs
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
本发明实施例公开了一种多媒体彩振业务实现方法、多媒体彩振服务器及用户设备。该方法应用于同时存在多媒体彩铃服务器根据多媒体彩铃请求和多媒体彩铃应答进行多媒体彩铃业务时，包括发送多媒体彩振请求给被叫用户设备，所述多媒体彩振请求与多媒体彩铃应答不在同一消息中；接收所述被叫用户设备发送的多媒体彩振应答，所述多媒体彩振应答与多媒体彩铃请求不在同一消息中；根据所述多媒体彩振请求和多媒体彩振应答向所述被叫用户设备发送多媒体彩振。通过本发明实施例可以保证CRS业务和CAT业务并存时，CRS业务与CAT业务的成功实现。
Description
技术领域
本发明涉及移动通信技术，特别涉及一种多媒体彩振业务实现方法、多媒体彩振服务器及用户设备。
背景技术
多媒体铃音业务包括多媒体回铃音(Customized Alerting Tone，简称CAT)和多媒体振铃音(Customized Ringing Signal，简称CRS)。CAT又称为多媒体彩铃，为主叫拨打被叫时，在被叫摘机接听之前，主叫欣赏到多媒体回铃音；CRS又称为多媒体彩振，为主叫拨打被叫时，在被叫摘机接听之前，被叫欣赏到多媒体振铃音。在IP多媒体子系统(IP Multimedia Subsystem，简称IMS)域的多媒体彩铃实现系统中，CAT服务器(Application Server，简称AS)将CAT请求(offer)添加在会话初始协议(Session Initiation Protocol，简称SIP)的临时应答响应(180消息或者183消息)中，发送给主叫用户设备(User Equipment，简称UE)，主叫UE将对应该CAT请求的CAT应答(answer)携带在临时响应确认消息(Provisional Response Acknowledgement，简称PRACK)中返回给CAT服务器，之后CAT服务器建立基于该CAT请求/CAT应答的早期会话(CAT会话)，将CAT发送给主叫UE。若在实现CAT的同时还要实现CRS业务，现有技术中是CRS服务器将CRS请求携带在PRACK中通过主叫侧的服务呼叫会话控制功能(Serving Call SessionControl Function，简称S-CSCF)及被叫侧的S-CSCF发送给被叫UE。
发明人在实现本发明的过程中发现现有技术至少存在如下问题：由于CAT是被叫为主叫定制的，因此CAT服务器部署在被叫侧，并且根据初始过滤准则(Initial Filter Criteria，简称IFC)，经过被叫侧S-CSCF的信令需要经过CAT服务器后再返回给被叫侧S-CSCF，因此，携带CRS请求的临时响应确认消息需要发送给CAT服务器，即CAT服务器既要接收到携带CAT应答的消息也要接收到携带CRS请求的消息。由于CAT应答和CRS请求采用的会话描述协议(Session Description Protocol，简称SDP)中的内容部署类型的值均为早期媒体，因此CAT服务器是无法区分CAT应答和CRS请求的，CAT服务器随机提取一个早期媒体会话的SDP项，该SDP项可能为CAT应答，也可能为CRS请求，若CAT服务器随机提取的SDP项为CRS请求，则会造成CAT会话协商及CRS会话协商失败。即现有CAT业务及CRS业务共存时，由于携带CRS请求的SIP消息与携带CAT应答的SIP消息相同，很可能造成CAT业务及CRS业务实现失败。
发明内容
本发明是提供一种多媒体彩振业务实现方法、多媒体彩振服务器及用户设备，解决现有CAT业务及CRS业务共存时，CAT业务及CRS业务很可能失败的问题。
本发明实施例提供了一种多媒体彩振业务实现方法，应用于同时存在多媒体彩铃服务器根据多媒体彩铃请求和多媒体彩铃应答进行多媒体彩铃业务时，包括：
发送多媒体彩振请求给被叫用户设备，所述多媒体彩振请求与多媒体彩铃应答不在同一消息中；
接收所述被叫用户设备发送的多媒体彩振应答，所述多媒体彩振应答与多媒体彩铃请求不在同一消息中；
根据所述多媒体彩振请求和多媒体彩振应答向所述被叫用户设备发送多媒体彩振。
本发明实施例还提供了一种多媒体彩振业务实现方法，应用于同时存在多媒体彩铃服务器根据多媒体彩铃请求和多媒体彩铃应答进行多媒体彩铃业务时，包括：
接收多媒体彩振服务器发送的多媒体彩振请求，所述多媒体彩振请求与多媒体彩铃应答不在同一消息中；
发送多媒体彩振应答给所述多媒体彩振服务器，所述多媒体彩振应答与多媒体彩铃请求不在同一消息中；
接收所述多媒体彩振服务器根据所述多媒体彩振请求和多媒体彩振应答发送的多媒体彩振。
本发明实施例提供了一种多媒体彩振服务器，应用于同时存在多媒体彩铃服务器根据多媒体彩铃请求和多媒体彩铃应答进行多媒体彩铃业务时，包括：
发送模块，用于发送多媒体彩振请求给被叫用户设备，所述多媒体彩振请求与多媒体彩铃应答不在同一消息中；
接收模块，用于接收所述被叫用户设备发送的多媒体彩振应答，所述多媒体彩振应答与多媒体彩铃请求不在同一消息中；
彩振发送模块，用于根据所述多媒体彩振请求和多媒体彩振应答向所述被叫用户设备发送多媒体彩振。
本发明实施例提供了一种用户设备，应用于同时存在多媒体彩铃服务器根据多媒体彩铃请求和多媒体彩铃应答进行多媒体彩铃业务时，包括：
请求模块，用于接收多媒体彩振服务器发送的多媒体彩振请求，所述多媒体彩振请求与多媒体彩铃应答不在同一消息中；
应答模块，用于发送多媒体彩振应答给所述多媒体彩振服务器，所述多媒体应答与多媒体彩铃请求不在同一消息中；
彩振接收模块，用于接收所述多媒体彩振服务器根据所述多媒体彩振请求和多媒体彩振应答发送的多媒体彩振。
由上述技术方案可知，本发明实施例通过将携带多媒体彩振请求的消息与携带多媒体彩铃应答的消息不相同，且携带多媒体彩振应答的消息与携带多媒体彩铃请求的消息不相同，避免一个SIP消息中同时携带两种早期媒体会话的SDP项，使得CRS的协商过程与CAT的协商过程分离，使得两次协商不会相互干扰，从而保证CRS业务和CAT业务并存时，CRS业务与CAT业务的成功实现。
附图说明
图1为本发明多媒体彩振业务实现方法实施例一的流程示意图；
图2为本发明多媒体彩振业务实现方法对应的网络结构示意图；
图3为本发明多媒体彩振业务实现方法实施例二的流程示意图；
图4为本发明多媒体彩振业务实现方法实施例三的流程示意图；
图5为本发明多媒体彩振业务实现方法实施例四的流程示意图；
图6为本发明多媒体彩振业务实现方法实施例五的流程示意图；
图7为本发明多媒体彩振业务实现方法实施例六的流程示意图；
图8为本发明多媒体彩振业务实现方法实施例七的流程示意图；
图9为本发明多媒体彩振业务实现方法实施例八的流程示意图；
图10为本发明多媒体彩振业务实现方法实施例九的流程示意图；
图11为本发明多媒体彩振业务实现方法实施例十的流程示意图；
图12为本发明多媒体彩振服务器实施例的结构示意图；
图13为本发明用户设备实施例的结构示意图；
图14为本发明多媒体彩振业务实现方法对应的多媒体铃音系统实施例的结构示意图。
具体实施方式
下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。
IMS域是在分组交换域(Packet Switched Domain，简称PS域)基础上增加的一个子系统，IMS主要功能在控制层面，而承载通过PS域完成。多媒体铃音业务的IMS域实现具体分为早期会话(Early Session)方案和多会话(Multi Dialog)方案，早期会话方案是指在主被叫之间建立正常通话会话之前，通过进行早期媒体协商以建立早期会话来实现早期媒体(即多媒体铃音)的播放。在采用SIP的早期媒体协商的过程中，主叫UE向被叫UE发送INVITE消息，被叫UE接收到该INVITE消息后要向主叫UE返回一个临时应答响应(180消息或183消息)。如果INVITE消息中包含了一个请求(offer)，那么被叫UE就应该产生一个携带应答(answer)的临时应答响应(180消息或183消息)，这样就可以建立一个基于offer/answer的早期会话；如果INVITE消息中没有包含请求(offer)，那么被叫UE返回的临时应答响应中要携带一个请求(offer)，主叫UE接收到该携带请求的临时应答响应后产生一个携带应答(answer)的临时响应确认(PRACK)消息，这样就可以建立一个基于offer/answer的早期会话。在SIP中定义了临时应答响应，即上述的180消息或者183消息，180消息为被叫UE的振铃(Ringing)消息，183消息为被叫UE的会话进行中消息(Session Progress)，被叫UE接收到INVITE消息后，会向主叫UE返回180消息或者183消息及180消息(183消息发生在180消息之前)。为了保证临时应答响应的可靠传输，对应于每个临时应答响应存在临时响应确认消息(PRACK)，PRACK类似于确认消息(Acknowledgement，简称ACK)，与ACK消息不同的是PRACK只用于临时应答响应的确认，且PRACK消息有对应的响应，如处理成功消息(200OK)。
因此，在早期媒体(CRS和CAT)协商过程中SIP中的消息按照时序分为：INVITE消息、183消息、183消息的临时响应确认消息(PRACK)、183消息的临时响应确认消息的处理成功消息(200OK)、180消息、180消息的临时响应确认消息(PRACK)和180消息的临时响应确认消息的处理成功消息(200OK)。若按照传输方向划分，即将从主叫UE向被叫UE传输的消息定义为请求消息，将从被叫UE向主叫UE传输的消息定义为响应消息，则请求消息包括INVITE消息、183消息的临时响应确认消息(PRACK)和180消息的临时响应确认消息(PRACK)；响应消息包括183消息、183消息的临时响应确认消息的处理成功消息(200OK)、180消息和180消息的临时响应确认消息的处理成功消息(200OK)；由于CAT是被叫UE为主叫UE定制的，因此CAT服务器部署在被叫侧，在CAT会话协商过程中，CAT请求(offer)需要携带在从被叫侧向主叫侧的响应消息中，CAT应答(answer)需要携带在从主叫侧向被叫侧的请求消息中；由于CRS是主叫UE为被叫UE定制的，因此CRS服务器部署在主叫侧，在CRS会话协商过程中，CRS请求(offer)需要携带在从主叫侧向被叫侧的请求消息中，CRS应答(answer)需要携带在从被叫侧向主叫侧的响应消息中。并且在相关的标准中已定义了CAT业务实现过程中，CAT请求(offer)及CAT应答(answer)的两种携带方式，其一是CAT请求(offer)由180消息携带，CAT应答(answer)由180消息的临时响应确认(PRACK)携带；其二是CAT请求(offer)由183消息携带，CAT应答(answer)由183消息的临时响应确认(PRACK)携带；基于上述CAT请求/CAT应答建立CAT早期媒体会话，实现CAT服务器向主叫UE发送CAT。因此，为了避免同一个SIP消息中携带两个SDP项(CAT项及CRS项)造成CAT业务及CRS业务均实现失败的问题，在CAT请求/CAT应答的携带方式已被标准确定的情况下，并且根据上述分析可知：CRS请求(offer)需要携带在从主叫侧向被叫侧的请求消息中，CRS应答(answer)需要携带在从被叫侧向主叫侧的响应消息中，CAT请求(offer)需要携带在从被叫侧向主叫侧的响应消息中，CAT应答(answer)需要携带在从主叫侧向被叫侧的请求消息中。这样在实现CRS业务时，携带CRS请求(offer)的请求消息与携带CAT应答(answer)的请求消息(180消息的临时响应确认或183消息的临时响应确认)需要不相同，携带CRS应答(answer)的响应消息与携带CAT请求(offer)的响求消息(180消息或183消息)需要不相同。具体的CRS业务实现方法可参见下述的实施例。
图1为本发明多媒体彩振业务实现方法实施例一的流程示意图，应用于同时存在多媒体彩铃服务器根据多媒体彩铃请求和多媒体彩铃应答进行多媒体彩铃业务时，包括：
步骤11：CRS服务器将CRS请求(CRS offer SDP，下述简写为offer)发送给被叫UE。例如CRS服务器将CRS请求添加到请求消息中发送给被叫UE，所述请求消息与携带CAT应答(CRS answer SDP，下述简写为answer)的消息不相同。
根据上述分析，CAT应答(answer)由180消息的临时响应确认(PRACK)携带或者由183消息的临时响应确认(PRACK)携带，请求消息包括INVITE消息、183消息的临时响应确认消息(PRACK)和180消息的临时响应确认消息(PRACK)。因此当CAT应答(answer)由180消息的临时响应确认(PRACK)携带时，CRS请求(offer)可以携带在INVITE消息或183消息的临时响应确认消息(PRACK)中；当CAT应答(answer)由183消息的临时响应确认(PRACK)携带时，CRS请求(offer)可以携带在INVITE消息、180消息的临时响应确认消息(PRACK)中。
步骤12：CRS服务器接收该被叫UE发送的CRS应答。例如CRS服务器接收被叫UE根据该请求消息得到的携带CRS应答(answer)的响应消息，所述响应消息与携带CAT请求(offer)的消息不相同。
根据上述分析，CAT请求(offer)由180消息携带或者由183消息携带，响应消息包括183消息、183消息的临时响应确认消息的处理成功消息(200OK)、180消息和180消息的处理成功消息(200OK)。因此当CAT请求(offer)由180消息携带时，CRS应答(answer)可以携带在183消息或183消息的临时响应确认消息的处理成功消息(200OK)或180消息的临时响应确认消息的处理成功消息(200OK)中，当CAT请求(offer)由183消息携带时，CRS应答(answer)可以携带在180消息或180消息的临时响应确认消息的处理成功消息(200OK)或183消息的临时响应确认消息的处理成功消息(200OK)中，当然，具体的CRS应答(answer)的携带方式还需要进一步考虑CRS请求(offer)的携带方式，因为应答是发生在请求之后，因此携带CRS应答(answer)的消息需要发生在携带CRS请求(offer)的消息之后。
步骤13：CRS服务器与该被叫UE建立基于上述CRS请求(offer)和CRS应答(answer)的CRS会话，根据该CRS会话向该被叫UE发送CRS。
根据上述各因素的分析，CRS请求(offer)和CRS应答(answer)的携带方式包括：
方式一、当携带CAT请求(offer)的消息为SIP中的180消息，携带CAT应答(answer)的消息为所述180消息的临时响应确认消息时：携带CRS请求(offer)的请求消息可以为SIP中的INVITE消息，此时，携带CRS应答(answer)的响应消息为SIP中的183消息或者183消息的处理成功消息或者所述180消息的处理成功消息。或者
携带CRS请求(offer)的请求消息为SIP中的183消息的临时响应确认消息，此时，携带CRS应答(answer)的响应消息为所述183消息的处理成功消息或者所述180消息的处理成功消息。
方式二、当携带CAT请求(offer)的消息为SIP中的183消息，携带CAT应答(answer)的消息为所述183消息的临时响应确认消息时：携带CRS请求(offer)的请求消息可以为SIP中的INVITE消息，此时，携带CRS应答(answer)的响应消息为SIP中的180消息或者183消息的处理成功消息或者所述180消息的处理成功消息。或者
携带CRS请求(offer)的请求消息为SIP中的180消息的临时响应确认消息，此时，携带CRS应答(answer)的响应消息为所述180消息的处理成功消息。
对应于上述携带方式的CRS业务的具体实现流程可以分别参见下述各实施例。
上述从CRS侧描述了CRS业务实现流程，若从被叫UE侧描述则包括：
被叫UE接收多媒体彩振服务器发送的多媒体彩振请求，所述多媒体请求的消息与多媒体彩铃应答不在同一消息中；
被叫UE发送多媒体彩振应答给所述多媒体彩振服务器，所述多媒体应答的消息与多媒体彩铃请求不在同一消息中；
被叫UE接收所述多媒体彩振服务器根据所述多媒体彩振请求和多媒体彩振应答发送的多媒体彩振。
其中携带CRS请求和CRS应答的方式与上述CRS侧的方式相同，具体不再赘述。
本实施例通过将CRS请求添加到与携带CAT应答的消息不相同的请求消息中，且携带CRS应答的响应消息与携带CAT请求的消息不相同，避免一个SIP消息中同时携带两种早期媒体会话的SDP项，使得CRS的协商过程与CAT的协商过程分离，使得两次协商不会相互干扰，从而保证CRS业务和CAT业务并存时，CRS业务与CAT业务的成功实现。
图2为本发明多媒体彩振业务实现方法对应的网络结构示意图，包括用户设备(User Equipment，简称UE)，具体为主叫UE201和被叫UE202，基站(NodeB)203，无线网络控制器(Radio Network Controller，简称RNC)204，服务通用分组无线业务支持节点(Serving General Packet Radio Service，简称SGSN)205，代理呼叫会话控制功能(Proxy Call Session Control Function，简称P-CSCF)206，主叫侧服务呼叫会话控制功能(Serving Call Session ControlFunction，简称S-CSCF)207，被叫侧S-CSCF208，CRS服务器(CRS AS)/多媒体资源功能(Multimedia Resource Function，简称MRF)209，CAT服务器(CAT AS)/MRF210，主叫侧归属用户服务器(Home Subscriber Server，简称HSS)211，被叫侧HSS212。由于CAT是被叫为主叫定制的，因此CAT服务器位于被叫侧，与被叫侧S-CSCF通过SIP交互连接，CRS是主叫为被叫定制的，因此CRS服务器位于主叫侧，与主叫侧S-CSCF通过SIP交互连接，主叫侧S-CSCF与被叫侧S-CSCF通过SIP交互连接；主叫UE201通过NodeB203、RNC204、SGSN205、P-CSCF206与主叫侧S-CSCF207交互连接；被叫UE202通过NodeB203、RNC204、SGSN205、P-CSCF206与被叫侧S-CSCF208交互连接；主叫侧HSS211与主叫侧S-CSCF交互连接，被叫侧HSS212与被叫侧S-CSCF交互连接。主叫侧HSS211及被叫侧HSS212分别为主叫侧及被叫侧提供用户数据，MRF用于提供媒体资源支持。具体的，主叫UE201用于发起呼叫；被叫202用于接收呼叫；NodeB203用于完成空中接口的处理；RNC204用于控制无线资源；SGSN205用于提供PS域的路由转发、移动性管理、会话管理、鉴权、加密等功能；P-CSCF206是IMS网络中用户的第一个接触点，主要负责验证请求，处理和转发响应；主叫侧S-CSCF207及被叫侧S-CSCF208在IMS网络中处于核心控制地位，是IMS多进程控制的关键所在，其分别负责记录并控制主叫侧及被叫侧的用户进程状态，执行会话路由功能，并不断与应用服务和计费功能进行交互，根据规则进行增值业务触发与业务控制；CAT服务器210是IMS网络中为用户提供CAT增值业务的服务器，可主要用于提供CAT业务，并控制MRF进行媒体资源的播放；CRS服务器209是IMS网络中为用户提供CRS增值业务的服务器，可主要用于提供CRS业务，并控制MRF进行媒体资源的播放；主叫侧HSS211及被叫侧HSS212分别用于存储主叫侧及被叫的用户和服务相关数据，记录用户身份、注册信息、接入参数和服务触发信息等；MRF包括控制部分(MRFC)和用户平面的处理部分(MRFP)，对与承载相关的业务提供支持，如多媒体资源播放、视频会议、用户公告等，能够完成数据媒体流的混合、媒体流的分发、承载代码的转换、计费信息的发送等。
图3为本发明多媒体彩振业务实现方法实施例二的流程示意图。如图3所示，并参见图2所示的网络结构示意图，本实施例包括：
步骤301：主叫UE201发送INVITE消息(呼叫请求消息)，该INVITE消息中携带正常会话所需的SDP请求(主叫UE offer)，该INVITE消息首先到达主叫侧S-CSCF207。
步骤302：主叫侧S-CSCF207根据IFC将该INVITE请求路由给CRSAS/MRF209。
上述步骤301-302与现有技术相同，详细地可参见现有技术，在此不再赘述。
步骤303：CRS AS/MRF209将CRS请求(offer)插入到INVITE消息体中，发送给主叫侧S-CSCF207。该步骤实现了在INVITE消息中携带CRS请求。
步骤304：主叫侧S-CSCF207将该携带CRS请求的INVITE消息发送给被叫侧S-CSCF208。
步骤305：被叫侧S-CSCF208根据IFC将该携带CRS请求的INVITE消息路由给CAT AS/MRF210，并接收从CAT AS/MRF210返回该携带CRS请求的INVITE消息。
步骤306：被叫侧S-CSCF208将该携带CRS请求的INVITE消息发送给被叫UE202。
上述步骤304-306与现有INVITE消息的信令传输途径相同，与现有不同的是本实施例中的INVITE消息中携带CRS请求。
步骤307：被叫UE202发送振铃消息(180消息)，首先到达被叫侧S-CSCF208。
步骤308：被叫侧S-CSCF208根据IFC将180消息路由给CATAS/MRF210。
步骤309：CAT AS/MRF210将CAT请求(offer)插入到180消息的消息体中后返回给被叫侧S-CSCF208。
步骤310：被叫侧S-CSCF208将该携带CAT请求的180消息发送给主叫侧S-CSCF207。
步骤311：主叫侧S-CSCF207根据IFC将该携带CAT请求的180消息路由给CRS AS/MRF209，并接收从CRS AS/MRF209返回的该携带CAT请求的180消息。
步骤312：主叫侧S-CSCF207将该携带CAT请求的180消息发送给主叫UE201。
步骤313：主叫UE针对180消息返回临时响应确认消息(PRACK)，该确认消息的消息体中携带了CAT应答(answer)，该携带CAT应答的PRACK消息首先到达主叫侧S-CSCF207。
步骤314：主叫侧S-CSCF207根据IFC将该携带CAT应答的PRACK消息路由给CRS AS/MRF209，并接收从CRS AS/MRF209返回的携带CAT应答的PRACK消息。
步骤315：主叫侧S-CSCF207将该携带CAT应答的PRACK消息发送给被叫侧S-CSCF208。
步骤316：被叫侧S-CSCF208根据IFC将该携带CAT应答的PRACK消息路由给CAT AS/MRF210。
步骤317：CAT AS/MRF210将PRACK消息中的CAT应答提取出来，完成基于CAT请求/CAT应答的会话协商，之后，CAT AS/MRF210为主叫UE201播放CAT。
步骤318-319：CAT AS/MRF210将PRACK消息(由于CAT AS已经将CAT应答提取出，因此该PRACK消息中不再携带CAT应答)发送给被叫侧S-CSCF208，并最终到达被叫UE202。
上述步骤307-319与现有采用180消息携带CAT请求、180消息的临时响应确认消息携带CAT应答时的信令传输途径及信令携带方式相同，与该情形下CAT业务的实现方式相同。由于在进行CAT业务协商的过程中相应信令中没有携带CRS请求或CRS应答，因此，不会造成CAT业务与CRS业务混在一起，上述步骤307-319可以保证CAT业务的成功实现。
步骤320：被叫UE202返回针对上述PRACK的处理成功消息(200OK)，该消息中携带CRS应答(answer)，该携带CRS应答的200OK消息首先到达被叫侧S-CSCF208。
步骤321：被叫侧S-CSCF208根据IFC将该携带CRS应答的200OK消息路由给CAT AS/MRF210，并接收CAT AS/MRF210返回的携带CRS应答的200OK消息。
步骤322：被叫侧S-CSCF208将该携带CRS应答的200OK消息发送给主叫侧S-CSCF207。
步骤323：主叫侧S-CSCF207根据IFC将该携带CRS应答的200OK消息路由给CRS AS/MRF209。
步骤324：CRS AS/MRF209将200OK消息中的CRS应答提取出来，完成基于CRS请求/CRS应答的会话协商，之后，CRS AS/MRF209为被叫UE202播放CRS。
步骤325-326：CRS AS/MRF209将200OK消息(由于CRS AS已经将CRS应答提取出，因此该200OK消息中不再携带CRS应答)发送给主叫侧S-CSCF207，并最终到达主叫UE201。
上述步骤320-326在针对180消息的临时响应确认消息的处理成功消息中携带CRS应答，由于此时CAT业务已经成功实现，相关信令中不再携带CAT请求或CAT应答，因此，不会造成CAT业务与CRS业务混在一起，进而可以保证CRS业务的成功实现。
步骤327：被叫UE202摘机。
步骤328：被叫UE202发送针对INVITE消息的处理成功消息(200OK)，该针对INVITE消息的200OK消息中携带被叫UE应答(被叫UE answer)，该针对INVITE消息的200OK消息首先到达被叫侧S-CSCF208。
步骤329：被叫侧S-CSCF208根据IFC将该200OK消息路由给CATAS/MRF210，CAT AS/MRF210停止CAT的播放，被叫侧S-CSCF208接收从CAT AS/MRF210返回的针对INVITE消息的200OK消息。
步骤330：被叫侧S-CSCF208发送该针对INVITE消息的200OK消息给主叫侧S-CSCF207。
步骤331：主叫侧S-CSCF207根据IFC将该针对INVITE消息的200OK消息路由给CRS AS/MRF209，CRS AS/MRF209停止CRS的播放，主叫侧S-CSCF207接收从CRS AS/MRF209返回的针对INVITE消息的200OK消息。
步骤332：主叫侧S-CSCF207将该针对INVITE消息的200OK消息发送给主叫UE201。
上述步骤327-332实现了被叫UE摘机后CAT业务及CRS业务的停止。
步骤333：主叫UE201返回针对INVITE消息的200OK消息的确认消息(ACK)，该ACK消息首先到达主叫侧S-CSCF207。
步骤334：主叫侧S-CSCF207根据IFC将该ACK消息路由给CRSAS/MRF210，并接收从CRS AS/MRF210返回的该ACK消息。
步骤335：主叫侧S-CSCF207将该ACK消息发送给被叫侧S-CSCF208。
步骤336：被叫侧S-CSCF208根据IFC将该ACK消息路由给CATAS/MRF210，并接收从CAT AS/MRF210返回的该ACK消息。
步骤337：被叫侧S-CSCF208将该ACK消息发送给被叫UE202。
步骤338：主叫UE201和被叫UE202建立正常通话过程。
上述步骤333-338与现有CAT业务及CRS业务结束后的流程相同，详细地可参见现有技术，在此不再赘述。
本实施例是在CAT请求由180消息携带、CAT应答由180消息的PRACK消息携带的情形下，在同时实现CRS业务时，由INVITE消息携带CRS请求，由180消息的PRACK消息的200OK消息携带CRS应答。从上述流程可以看出CAT早期媒体协商与CRS早期媒体协商是完全分开进行的，从而避免了在一个SIP消息中同时携带两个早期媒体会话的SDP项，避免CRS AS或CAT AS无法识别自身所需的SDP项的情况，保证CRS业务与CAT业务的成功实现。
图4为本发明多媒体彩振业务实现方法实施例三的流程示意图。如图4所示，并参见图2所示的网络结构示意图，本实施例包括：
步骤401-406：INVITE消息中携带CRS请求到达被叫UE202。与实施例二中的步骤301-306对应相同，在此不再赘述，并且，为了使图4简要，图4中只对应示出步骤401和步骤406，其余的步骤402-405具体内容可参见图3的步骤302-305。
同实施例二，本实施例中的INVITE消息中携带CRS请求。
步骤407：被叫UE202发送会话进行中消息(183消息)，该183消息中携带CRS应答(answer)，该携带CRS应答的183消息首先到达被叫侧S-CSCF208。
步骤408：被叫侧S-CSCF208根据IFC将该携带CRS应答的183消息路由给CAT AS/MRF210，并接收CAT AS/MRF210返回的携带CRS应答的183消息。
步骤409：被叫侧S-CSCF208将该携带CRS应答的183消息发送给主叫侧S-CSCF207。
步骤410：主叫侧S-CSCF207根据IFC将该携带CRS应答的183消息路由给CRS AS/MRF209。
步骤411：CRS AS/MRF209将183消息中的CRS应答提取出来，完成基于CRS请求/CRS应答的会话协商，之后，CRS AS/MRF209为被叫UE202播放CRS。
步骤412-413：CRS AS/MRF209将183消息(由于CRS AS已经将CRS应答提取出，因此该183消息中不再携带CRS应答)发送给主叫侧S-CSCF207，并最终到达主叫UE201。
步骤414：主叫UE201针对183消息返回临时响应确认消息(PRACK)，PRACK消息首先到达主叫侧S-CSCF207。
步骤415：主叫侧S-CSCF207根据IFC将该183消息的PRACK消息路由给CRS AS/MRF209，并接收从CRS AS/MRF209返回的该183消息的PRACK消息。
步骤416：主叫侧S-CSCF207将该183消息的PRACK消息发送给被叫侧S-CSCF208。
步骤417：被叫侧S-CSCF208根据IFC将该183消息的PRACK消息路由给CAT AS/MRF210，并接收CAT AS/MRF210返回的该183消息的PRACK消息。
步骤418：被叫侧S-CSCF208将该183消息的PRACK消息发送给被叫UE202。
步骤419：被叫UE202发送针对183消息的PRACK消息的处理成功消息(200OK)，简称为183消息的200OK消息，该183消息的200OK消息首先到达被叫侧S-CSCF208。
步骤420：被叫侧S-CSCF208根据IFC将该183消息的200OK消息路由给CAT AS/MRF210，并接收从CAT AS/MRF210返回的该183消息的200OK消息。
步骤421：被叫侧S-CSCF208将该183消息的200OK消息发送给主叫侧S-CSCF207。
步骤422：主叫侧S-CSCF207根据IFC将该183消息的200OK消息路由给CRS AS/MRF209，并接收从CRS AS/MRF209返回的该183消息的200OK消息。
步骤423：主叫侧S-CSCF207将该183消息的200OK消息发送给主叫UE201。
上述步骤通过在INVITE消息中携带CRS请求，在183消息中携带CRS应答，保证了CRS业务的成功实现。
步骤424-436：被叫UE202振铃(发送180消息)，CAT AS/MRF210将CAT请求插入180消息中，并发送给主叫UE201，主叫UE201在180消息的PRACK中携带CAT应答返回给CAT AS/MRF210，使CAT AS/MRF向主叫UE201播放CAT。与实施例二中的步骤307-319对应相同，在此不再赘述，并且，为了使图4简要，图4中只对应示出步骤424和步骤434-436，其余的步骤425-433的具体内容可参见图3的步骤308-316。
步骤437：被叫UE202返回针对180消息的PRACK的处理成功消息(200OK)，简称180消息的200OK消息，该180消息的200OK消息首先到达被叫侧S-CSCF208。与实施例二不同的是，实施例是通过180消息的200OK消息携带CRS应答(answer)，而本实施例由于在上述的步骤中已经实现CRS，因此该180消息的200OK中不需要携带CRS应答。
步骤438：被叫侧S-CSCF208根据IFC将该180消息的200OK消息路由给CAT AS/MRF210，并接收CAT AS/MRF210返回的该180消息的200OK消息。
步骤439：被叫侧S-CSCF208将该180消息的200OK消息发送给主叫侧S-CSCF207。
步骤440：主叫侧S-CSCF207根据IFC将该180消息的200OK消息路由给CRS AS/MRF209，并接收从CRS AS/MRF209返回的该180消息的200OK消息。
步骤441：主叫侧S-CSCF207将该180消息的200OK消息发送给主叫UE201。
上述步骤424-441保证了CAT业务的成功实现。
步骤442-453：被叫UE202摘机，进行信令交互直至主被叫正常通话。与实施例二中的步骤327-338对应相同，在此不再赘述，并且，为了使图4简要，图4中只对应示出步骤442和步骤453，其余的步骤443-452的具体内容可参见图3的步骤328-337。
本实施例是在CAT请求由180消息携带、CAT应答由180消息的PRACK消息携带的情形下，在同时实现CRS业务时，由INVITE消息携带CRS请求，由183消息携带CRS应答。从上述流程可以看出CAT早期媒体协商与CRS早期媒体协商是完全分开进行的，从而避免了在一个SIP消息中同时携带两个早期媒体会话的SDP项，避免CRS AS或CAT AS无法识别自身所需的SDP项的情况，保证CRS业务与CAT业务的成功实现。
图5为本发明多媒体彩振业务实现方法实施例四的流程示意图。如图5所示，并参见图2所示的网络结构示意图，本实施例包括：
步骤501-506：INVITE消息中携带CRS请求到达被叫UE202。与实施例二中的步骤301-306对应相同，在此不再赘述，并且，为了使图5简要，图5中只对应示出步骤501和步骤506，其余的步骤502-505的具体内容可参见图3的步骤302-305。
同实施例二，本实施例中的INVITE消息中携带CRS请求。
步骤507：被叫UE202发送会话进行中消息(183消息)，该183消息首先到达被叫侧S-CSCF208。
步骤508：被叫侧S-CSCF208根据IFC将该183消息路由给CATAS/MRF210，并接收CAT AS/MRF210返回的183消息。
步骤509：被叫侧S-CSCF208将该183消息发送给主叫侧S-CSCF207。
步骤510：主叫侧S-CSCF207根据IFC将该183消息路由给CRSAS/MRF209，并接收从CRS AS/MRF209返回的183消息。
步骤511：主叫侧S-CSCF207将该183消息发送给主叫UE201。
步骤512：主叫UE201针对183消息返回临时响应确认消息(PRACK)，PRACK消息首先到达主叫侧S-CSCF207。
步骤513：主叫侧S-CSCF207根据IFC将该183消息的PRACK消息路由给CRS AS/MRF209，并接收从CRS AS/MRF209返回的该183消息的PRACK消息。
步骤514：主叫侧S-CSCF207将该183消息的PRACK消息发送给被叫侧S-CSCF208。
步骤515：被叫侧S-CSCF208根据IFC将该183消息的PRACK消息路由给CAT AS/MRF210，并接收CAT AS/MRF210返回的该183消息的PRACK消息。
步骤516：被叫侧S-CSCF208将该183消息的PRACK消息发送给被叫UE202。
步骤517：被叫UE202发送针对183消息的PRACK消息的处理成功消息(200OK)，简称为183消息的200OK消息，该183消息的200OK消息中携带CRS应答，并首先到达被叫侧S-CSCF208。
步骤518：被叫侧S-CSCF208根据IFC将该携带CRS应答的183消息的200OK消息路由给CAT AS/MRF210，并接收从CAT AS/MRF210返回的该携带CRS应答的183消息的200OK消息。
步骤519：被叫侧S-CSCF208将该携带CRS应答的183消息的200OK消息发送给主叫侧S-CSCF207。
步骤520：主叫侧S-CSCF207根据IFC将该携带CRS应答的183消息的200OK消息路由给CRS AS/MRF209。
步骤521：CRS AS/MRF209在该携带CRS应答的183消息的200OK消息中将CRS应答提取出来，完成基于CRS请求/CRS应答的会话协商，之后，CRS AS/MRF209为被叫UE202播放CRS。
步骤522-523：CRS AS/MRF209将183消息的200OK消息(由于CRS AS已经将CRS应答提取出，因此该183消息的200OK中不再携带CRS应答)发送给主叫侧S-CSCF207，并最终到达主叫UE201。
上述步骤通过在INVITE消息中携带CRS请求，在183消息的200OK消息中携带CRS应答，保证了CRS业务的成功实现。
步骤524-553：被叫UE202振铃(发送180消息)，CAT AS/MRF210将CAT请求插入180消息中，并发送给主叫UE201，主叫UE201在180消息的PRACK中携带CAT应答返回给CAT AS/MRF210，使CAT AS/MRF向主叫UE201播放CAT。及被叫UE202摘机，进行信令交互直至主被叫正常通话。与实施例三中的步骤424-453对应相同，在此不再赘述，并且，为了使图5简要，图5中只对应示出步骤524、步骤534和步骤553，其余的步骤525-533、步骤535-552的具体内容同样可参见图4的步骤425433、步骤435-452。
本实施例是在CAT请求由180消息携带、CAT应答由180消息的PRACK消息携带的情形下，在同时实现CRS业务时，由INVITE消息携带CRS请求，由183消息的PRACK消息的200OK消息携带CRS应答。从上述流程可以看出CAT早期媒体协商与CRS早期媒体协商是完全分开进行的，从而避免了在一个SIP消息中同时携带两个早期媒体会话的SDP项，避免CRS AS或CAT AS无法识别自身所需的SDP项的情况，保证CRS业务与CAT业务的成功实现。
图6为本发明多媒体彩振业务实现方法实施例五的流程示意图。如图6所示，并参见图2所示的网络结构示意图，本实施例包括：
步骤601：主叫UE201发送INVITE消息(呼叫请求消息)，该INVITE消息中携带正常会话所需的SDP请求(主叫UE offer)，该INVITE消息首先到达主叫侧S-CSCF207。
步骤602：主叫侧S-CSCF207根据IFC将该INVITE请求路由给CRSAS/MRF209，并接收CRS AS/MRF209返回的该INVITE消息。
步骤603：主叫侧S-CSCF207将该INVITE消息发送给被叫侧S-CSCF208。
步骤604：被叫侧S-CSCF208根据IFC将该INVITE消息路由给CATAS/MRF210，并接收从CAT AS/MRF210返回该INVITE消息。
步骤605：被叫侧S-CSCF208将该INVITE消息发送给被叫UE202。
上述步骤601-605与现有技术相同，详细地可参见现有技术，在此不再赘述。
步骤606：被叫UE202发送会话进行中消息(183消息)，该183消息首先到达被叫侧S-CSCF208。
步骤607：被叫侧S-CSCF208根据IFC将该183消息路由给CATAS/MRF210，并接收CAT AS/MRF210返回的183消息。
步骤608：被叫侧S-CSCF208将该183消息发送给主叫侧S-CSCF207。
步骤609：主叫侧S-CSCF207根据IFC将该183消息路由给CRSAS/MRF209，并接收从CRS AS/MRF209返回的183消息。
步骤610：主叫侧S-CSCF207将该183消息发送给主叫UE201。
步骤611：主叫UE201针对183消息返回临时响应确认消息(PRACK)，该183消息的PRACK消息首先到达主叫侧S-CSCF207。
上述步骤606-611与实施例四的步骤507-512对应相同，为了使图6简要，图6中只示出了步骤606和步骤611，其余的步骤607-610的具体内容可参见图5的步骤508-511。
步骤612：主叫侧S-CSCF207根据IFC将该183消息的PRACK消息路由给CRS AS/MRF209。
步骤613：CRS AS/MRF209将CRS请求(offer)插入到183消息的PRACK消息的消息体中，发送给主叫侧S-CSCF207。该步骤实现了在183消息的PRACK消息中携带CRS请求。
步骤614：主叫侧S-CSCF207将该携带CRS请求的183消息的PRACK消息发送给被叫侧S-CSCF208。
步骤615：被叫侧S-CSCF208根据IFC将该携带CRS请求的183消息的PRACK消息路由给CAT AS/MRF210，并接收CAT AS/MRF210返回的该携带CRS请求的183消息的PRACK消息。
步骤616：被叫侧S-CSCF208将该携带CRS请求的183消息的PRACK消息发送给被叫UE202。
步骤617：被叫UE202发送针对183消息的PRACK消息的处理成功消息(200OK)，简称为183消息的200OK消息，该183消息的200OK消息中携带CRS应答，并首先到达被叫侧S-CSCF208。
步骤618：被叫侧S-CSCF208根据IFC将该携带CRS应答的183消息的200OK消息路由给CAT AS/MRF210，并接收从CAT AS/MRF210返回的该携带CRS应答的183消息的200OK消息。
步骤619：被叫侧S-CSCF208将该携带CRS应答的183消息的200OK消息发送给主叫侧S-CSCF207。
步骤620：主叫侧S-CSCF207根据IFC将该携带CRS应答的183消息的200OK消息路由给CRS AS/MRF209。
步骤621：CRS AS/MRF209在该携带CRS应答的183消息的200OK消息中将CRS应答提取出来，完成基于CRS请求/CRS应答的会话协商，之后，CRS AS/MRF209为被叫UE202播放CRS。
步骤622-623：CRS AS/MRF209将183消息的200OK消息(由于CRS AS已经将CRS应答提取出，因此该183消息的200OK中不再携带CRS应答)发送给主叫侧S-CSCF207，并最终到达主叫UE201。
上述中的步骤617-623与实施例四的步骤517-523对应相同，为了使图6简要，图中只示出了步骤617、步骤621-623，其余的步骤618-620的具体内容可参见图5的步骤518-520。
上述步骤通过在183消息的PRACK消息中携带CRS请求，在183消息的200OK消息中携带CRS应答，保证了CRS业务的成功实现。
步骤624-653：被叫UE202振铃(发送180消息)，CAT AS/MRF210将CAT请求插入180消息中，并发送给主叫UE201，主叫UE201在180消息的PRACK中携带CAT应答返回给CAT AS/MRF210，使CAT AS/MRF向主叫UE201播放CAT。及被叫UE202摘机，进行信令交互直至主被叫正常通话。与实施例三中的步骤424-453对应相同，在此不再赘述，并且，为了使图6简要，图6中只对应示出步骤624、步骤634和步骤653，其余的步骤625-633、步骤635-652的具体内容同样可参见图4的步骤425-433、步骤435-452。
本实施例是在CAT请求由180消息携带、CAT应答由180消息的PRACK消息携带的情形下，在同时实现CRS业务时，由183消息的PRACK消息携带CRS请求，由183消息的PRACK消息的200OK消息携带CRS应答。从上述流程可以看出CAT早期媒体协商与CRS早期媒体协商是完全分开进行的，从而避免了在一个SIP消息中同时携带两个早期媒体会话的SDP项，避免CRS AS或CAT AS无法识别自身所需的SDP项的情况，保证CRS业务与CAT业务的成功实现。
图7为本发明多媒体彩振业务实现方法实施例六的流程示意图。如图7所示，并参见图2所示的网络结构示意图，本实施例包括：
步骤701-716：被叫UE202接收携带CRS请求的183消息的PRACK消息发送。与实施例五的步骤601-616对应相同，为了使图7简要，图7中只对应示出步骤701和步骤716，其余的步骤702-715的具体内容可参见图6的步骤602-615。
步骤717-721：被叫UE202发送针对183消息的PRACK消息的处理成功消息(200OK)，简称为183消息的200OK消息，该183消息的200OK消息首先到达被叫侧S-CSCF208，直至到达主叫UE201。与图4的步骤419-423对应相同，为了使图7简要，图7中只对应示出步骤717和步骤721，其余的步骤718-720的具体内容可参见图4的步骤420-422。
步骤722-753：先实现CAT再实现CRS，与图3的步骤307-338对应相同，为了使图7简要，图7中只对应示出步骤722、步骤732-742、步骤753，其余的步骤723-731、步骤743-752的具体内容可参见图3的步骤308-316、步骤328-337。
本实施例是在CAT请求由180消息携带、CAT应答由180消息的PRACK消息携带的情形下，在同时实现CRS业务时，由183消息的PRACK消息携带CRS请求，由180消息的PRACK消息的200OK消息携带CRS应答。从上述流程可以看出CAT早期媒体协商与CRS早期媒体协商是完全分开进行的，从而避免了在一个SIP消息中同时携带两个早期媒体会话的SDP项，避免CRS AS或CAT AS无法识别自身所需的SDP项的情况，保证CRS业务与CAT业务的成功实现。
图8为本发明多媒体彩振业务实现方法实施例七的流程示意图。如图8所示，并参见图2所示的网络结构示意图，本实施例包括：
步骤801-805：与实施例五的步骤601-605对应相同，图8中只示出了步骤801和步骤805，其余的步骤802-804可参见图6的步骤602-604。
步骤806-818：通过183消息携带CAT请求，通过183消息的PRACK携带CAT应答，CAT AS/MRF210基于上述CAT请求/CAT应答向主叫UE201发送CAT。与实施例二的步骤307-319途经的路径相同，只是本实施例中采用183消息，实施例二中采用180消息。
步骤819-823：被叫UE202发送针对183消息的200OK，并经过被叫侧S-CSCF208→CAT AS/MRF210→被叫侧S-CSCF208→主叫侧S-CSCF207→CRS AS/MRF209→主叫侧S-CSCF207→主叫UE201路经发送给主叫UE201。图中只示出了步骤819和步骤823。
步骤824-828：被叫发送180消息，并经过被叫侧S-CSCF208→CATAS/MRF210→被叫侧S-CSCF208→主叫侧S-CSCF207→CRS AS/MRF209→主叫侧S-CSCF207→主叫UE201路经发送给主叫UE201。图中只示出了步骤824和步骤828。
步骤829：主叫UE201发送针对180消息的PRACK，该180消息的PRACK首先到达主叫侧S-CSCF207。
步骤830：主叫侧S-CSCF207根据IFC将该180消息的PRACK路由给CRS AS/MRF209。
步骤831：CRS AS/MRF209将CRS请求(offer)插入180消息的PRACK的消息体中，并发送给主叫侧S-CSCF207。
步骤832：主叫侧S-CSCF207将携带CRS请求的180消息的PRACK发送给被叫侧S-CSCF208。
步骤833：被叫侧S-CSCF208根据IFC将携带CRS请求的180消息的PRACK路由给CAT AS/MRF210，并接收从CAT AS/MRF210返回的携带CRS请求的180消息的PRACK。
步骤834：被叫侧S-CSCF208将携带CRS请求的180消息的PRACK发送给被叫UE202。
步骤835：被叫UE202发送携带CRS应答的180消息的PRACK消息的200OK消息，简称180消息的200OK，首先到达被叫侧S-CSCF208。
步骤836：被叫侧S-CSCF208根据IFC将携带CRS应答的180消息的200OK路由给CAT AS/MRF210，并接收从CAT AS/MRF210返回的携带CRS应答的180消息的200OK。
步骤837：被叫侧S-CSCF208将携带CRS应答的180消息的200OK发送给主叫侧S-CSCF207。
步骤838：主叫侧S-CSCF207根据IFC将该携带CRS应答的180消息的200OK路由给CRS AS/MRF209。
步骤839：CRS AS/MRF209在该携带CRS应答的180消息的200OK中将CRS应答提取出来，完成基于CRS请求/CRS应答的会话协商，之后，CRSAS/MRF209为被叫UE202播放CRS。
步骤840-841：CRS AS/MRF209将180消息的200OK(由于CRS AS已经将CRS应答提取出，因此该180消息的200OK中不再携带CRS应答)发送给主叫侧S-CSCF207，并最终到达主叫UE201。
步骤842-853：被叫UE202摘机进行后续信令交互直至主被叫正常通话。与实施例二的步骤327-338对应相同，图8中只示出步骤842和步骤853，步骤843-852可参见图3的步骤328-337。
本实施例是在CAT请求由183消息携带、CAT应答由183消息的PRACK消息携带的情形下，在同时实现CRS业务时，由180消息的PRACK消息携带CRS请求，由180消息的PRACK消息的200OK消息携带CRS应答。从上述流程可以看出CAT早期媒体协商与CRS早期媒体协商是完全分开进行的，从而避免了在一个SIP消息中同时携带两个早期媒体会话的SDP项，避免CRS AS或CAT AS无法识别自身所需的SDP项的情况，保证CRS业务与CAT业务的成功实现。
图9为本发明多媒体彩振业务实现方法实施例八的流程示意图。如图9所示，并参见图2所示的网络结构示意图，本实施例包括：
步骤901-906：通过INVITE消息携带CRS请求，与实施例二的步骤301-306对应相同，图9中只示出了步骤901和步骤906，其余的步骤902-905可参见图3的步骤302-305。
步骤907-924：通过183消息携带CAT请求，通过183消息的PRACK携带CAT应答，CAT AS/MRF210基于上述CAT请求/CAT应答向主叫UE201发送CAT。与实施例七的步骤806-823对应相同，图9中只示出了步骤907、步骤917和步骤924，其余步骤可参见图8中的对应步骤。
步骤925：被叫UE202发送180消息，该180消息中携带CRS应答，该携带CRS应答的180消息首先到达被叫侧S-CSCF208。
步骤926：被叫侧S-CSCF208根据IFC将携带CRS应答的180消息路由给CAT AS/MRF210，并接收从CAT AS/MRF210返回的携带CRS应答的180消息。
步骤927：被叫侧S-CSCF208将携带CRS应答的180消息发送给主叫侧S-CSCF207。
步骤928：主叫侧S-CSCF207根据IFC将该携带CRS应答的180消息路由给CRS AS/MRF209。
步骤929：CRS AS/MRF209在该携带CRS应答的180消息中将CRS应答提取出来，完成基于CRS请求/CRS应答的会话协商，之后，CRSAS/MRF209为被叫UE202播放CRS。
步骤930-931：CRS AS/MRF209将180消息(由于CRS AS已经将CRS应答提取出，因此该180消息中不再携带CRS应答)发送给主叫侧S-CSCF207，并最终到达主叫UE201。
步骤932-936：主叫UE201发送180消息的PRACK，并经过主叫201→主叫侧S-CSCF207→CRS AS/MRF209→主叫侧S-CSCF207→被叫侧S-CSCF208→CAT AS/MRF210→被叫侧S-CSCF208→被叫UE202发送给被叫UE202。
步骤937-941：被叫发送180消息的200OK，并经过被叫侧S-CSCF208→CAT AS/MRF210→被叫侧S-CSCF208→主叫侧S-CSCF207→CRSAS/MRF209→主叫侧S-CSCF207→主叫UE201路经发送给主叫UE201。
步骤942-953：被叫UE202摘机进行后续信令交互直至主被叫正常通话。与实施例二的步骤327-338对应相同，图9中只示出步骤942和步骤953，步骤943-952可参见图3的步骤328-337。
本实施例是在CAT请求由183消息携带、CAT应答由183消息的PRACK消息携带的情形下，在同时实现CRS业务时，由INVITE消息携带CRS请求，由180消息携带CRS应答。从上述流程可以看出CAT早期媒体协商与CRS早期媒体协商是完全分开进行的，从而避免了在一个SIP消息中同时携带两个早期媒体会话的SDP项，避免CRS AS或CAT AS无法识别自身所需的SDP项的情况，保证CRS业务与CAT业务的成功实现。
图10为本发明多媒体彩振业务实现方法实施例九的流程示意图。如图10所示，并参见图2所示的网络结构示意图，本实施例包括：
步骤1001-1006：通过INVITE消息携带CRS请求，与实施例二的步骤301-306对应相同，图10中只示出了步骤1001和步骤1006，其余的步骤1002-1005可参见图3的步骤302-305。
步骤1007-1024：通过183消息携带CAT请求，通过183消息的PRACK携带CAT应答，CAT AS/MRF210基于上述CAT请求/CAT应答向主叫UE201发送CAT。与实施例七的步骤806-823对应相同，图10中只示出了步骤1007、步骤1017和步骤1024，其余步骤可参见图8中的对应步骤。
步骤1025：被叫UE202发送180消息，该180消息首先到达被叫侧S-CSCF208。
步骤1026：被叫侧S-CSCF208根据IFC将180消息路由给CATAS/MRF210，并接收从CAT AS/MRF210返回的180消息。
步骤1027：被叫侧S-CSCF208将180消息发送给主叫侧S-CSCF207。
步骤1028：主叫侧S-CSCF207根据IFC将该180消息路由给CRSAS/MRF209，并接收从CRS AS/MRF209返回的180消息。
步骤1029：主叫侧S-CSCF207将该180消息发送给主叫UE201。
步骤1030-1034：主叫UE201发送180消息的PRACK，并经过主叫201→主叫侧S-CSCF207→CRS AS/MRF209→主叫侧S-CSCF207→被叫侧S-CSCF208→CAT AS/MRF210→被叫侧S-CSCF208→被叫UE202发送给被叫UE202。
步骤1035：被叫UE202发送180消息的PRACK消息的200OK消息，简称180消息的200OK，该180消息的200OK中携带CRS应答，该携带CRS应答的180消息的200OK首先到达被叫侧S-CSCF208。
步骤1036：被叫侧S-CSCF208根据IFC将携带CRS应答的180消息的200OK路由给CAT AS/MRF210，并接收从CAT AS/MRF210返回的携带CRS应答的180消息的200OK。
步骤1037：被叫侧S-CSCF208将携带CRS应答的180消息的200OK发送给主叫侧S-CSCF207。
步骤1038：主叫侧S-CSCF207根据IFC将该携带CRS应答的180消息的200OK路由给CRS AS/MRF209。
步骤1039：CRS AS/MRF209在该携带CRS应答的180消息的200OK中将CRS应答提取出来，完成基于CRS请求/CRS应答的会话协商，之后，CRS AS/MRF209为被叫UE202播放CRS。
步骤1040-1041：CRS AS/MRF209将180消息的200OK(由于CRS AS已经将CRS应答提取出，因此该180消息的200OK中不再携带CRS应答)发送给主叫侧S-CSCF207，并最终到达主叫UE201。
步骤1042-1053：被叫UE202摘机进行后续信令交互直至主被叫正常通话。与实施例二的步骤327-338对应相同，图10中只示出步骤1042和步骤1053，步骤1043-1052可参见图3的步骤328-337。
本实施例是在CAT请求由183消息携带、CAT应答由183消息的PRACK消息携带的情形下，在同时实现CRS业务时，由INVITE消息携带CRS请求，由180消息的PRACK消息的200OK消息携带CRS应答。从上述流程可以看出CAT早期媒体协商与CRS早期媒体协商是完全分开进行的，从而避免了在一个SIP消息中同时携带两个早期媒体会话的SDP项，避免CRS AS或CAT AS无法识别自身所需的SDP项的情况，保证CRS业务与CAT业务的成功实现。
图11为本发明多媒体彩振业务实现方法实施例十的流程示意图。如图11所示，并参见图2所示的网络结构示意图，本实施例包括：
步骤1101-1106：通过INVITE消息携带CRS请求，与实施例二的步骤301-306对应相同，图11中只示出了步骤1101和步骤1106，其余的步骤1102-1105可参见图3的步骤302-305。
步骤1107-1119：通过183消息携带CAT请求，通过183消息的PRACK携带CAT应答，CAT AS/MRF210基于上述CAT请求/CAT应答向主叫UE201发送CAT。与实施例七的步骤806-818对应相同，图11中只示出了步骤1107、步骤1117-1119，其余步骤可参见图8中的对应步骤。
步骤1120：被叫UE202发送183消息PRACK消息的200OK消息，简称183消息的200OK，该183消息的200OK中携带CRS应答，该携带CRS应答的183消息的200OK首先到达被叫侧S-CSCF208。
步骤1121：被叫侧S-CSCF208根据IFC将携带CRS应答的183消息的200OK路由给CAT AS/MRF210，并接收从CAT AS/MRF210返回的携带CRS应答的183消息的200OK。
步骤1122：被叫侧S-CSCF208将携带CRS应答的183消息的200OK发送给主叫侧S-CSCF207。
步骤1123：主叫侧S-CSCF207根据IFC将该携带CRS应答的183消息的200OK路由给CRS AS/MRF209。
步骤1124：CRS AS/MRF209在该携带CRS应答的183消息的200OK将CRS应答提取出来，完成基于CRS请求/CRS应答的会话协商，之后，CRSAS/MRF209为被叫UE202播放CRS。
步骤1125-1126：CRS AS/MRF209将183消息的200OK(由于CRS AS已经将CRS应答提取出，因此该183消息的200OK中不再携带CRS应答)发送给主叫侧S-CSCF207，并最终到达主叫UE201。
步骤1127-1131：被叫UE202发送180消息，并经过被叫UE202→被叫侧S-CSCF208→CAT AS/MRF210→被叫侧S-CSCF208→主叫侧S-CSCF207→CRS AS/MRF209→主叫侧S-CSCF207→主叫UE201路经发送给主叫UE201。图11中只示出了步骤1127和步骤1131。
步骤1132-1136：主叫UE201发送180消息的PRACK，并经过主叫201→主叫侧S-CSCF207→CRS AS/MRF209→主叫侧S-CSCF207→被叫侧S-CSCF208→CAT AS/MRF210→被叫侧S-CSCF208→被叫UE202发送给被叫UE202。图11中只示出了步骤1132和步骤1136
步骤1137-1141：被叫UE202发送180消息的200OK，并经过被叫UE202→被叫侧S-CSCF208→CAT AS/MRF210→被叫侧S-CSCF208→主叫侧S-CSCF207→CRS AS/MRF209→主叫侧S-CSCF207→主叫UE201路经发送给主叫UE201。图11中只示出了步骤1137和步骤1141
步骤1142-1153：被叫UE202摘机进行后续信令交互直至主被叫正常通话。与实施例二的步骤327-338对应相同，图11中只示出步骤1142和步骤1153，步骤1143-1152可参见图3的步骤328-337。
本实施例是在CAT请求由183消息携带、CAT应答由183消息的PRACK消息携带的情形下，在同时实现CRS业务时，由INVITE消息携带CRS请求，由183消息的PRACK消息的200OK消息携带CRS应答。从上述流程可以看出CAT早期媒体协商与CRS早期媒体协商是完全分开进行的，从而避免了在一个SIP消息中同时携带两个早期媒体会话的SDP项，避免CRS AS或CAT AS无法识别自身所需的SDP项的情况，保证CRS业务与CAT业务的成功实现。
本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
图12为本发明多媒体彩振服务器实施例的结构示意图，包括发送模块121、接收模块122和彩振发送模块123。发送模块121将CRS请求添加到请求消息中发送给被叫UE，所述请求消息与携带CAT应答的消息不相同；接收模块122接收所述被叫UE发送的根据所述请求消息得到的携带CRS应答的响应消息，所述响应消息与携带CAT请求的消息不相同；彩振发送模块123根据发送模块121的CRS请求及接收模块122的CRS应答，与所述被叫UE建立CRS会话，根据该CRS会话向所述被叫UE发送CRS。
具体的，若携带CAT请求的消息为SIP中的180消息，携带CAT应答的消息为所述180消息的PRACK，则，发送模块121用于将所述CRS请求添加到SIP中的INVITE消息中；接收模块122用于接收携带所述CRS应答的SIP中的183消息或者183消息的PRACK消息的200OK或者所述180消息的PRACK消息的200OK。
或者，若携带CAT请求的消息为SIP中的180消息，携带CAT应答的消息为所述180消息的PRACK，则，发送模块121用于将所述CRS请求添加到SIP中的183消息的PRACK中；接收模块122用于接收携带所述CRS应答的SIP中的所述183消息的PRACK消息的200OK或者所述180消息的PRACK消息的200OK。
若携带CAT请求的消息为SIP中的183消息，携带CAT应答的消息为所述183消息的PRACK，则，发送模块121用于将所述CRS请求添加到SIP中的INVITE消息中；接收模块122用于接收携带所述CRS应答的SIP中的所述183消息的PRACK消息的200OK或者SIP中的180消息或者所述180消息的PRACK消息的200OK。
或者，若携带CAT请求的消息为SIP中的183消息，携带CAT应答的消息为所述183消息的PRACK，则，发送模块121用于将所述CRS请求添加到SIP中的180消息的PRACK中；接收模块122用于接收携带所述CRS应答的SIP中的180消息的PRACK消息的200OK。
本实施例通过将CRS请求添加到与携带CAT应答的消息不相同的请求消息中，且携带CRS应答的响应消息与携带CAT请求的消息不相同，避免一个SIP消息中同时携带两种早期媒体会话的SDP项，使得CRS的协商过程与CAT的协商过程分离，使得两次协商不会相互干扰，从而保证CRS业务和CAT业务并存时，CRS业务与CAT业务的成功实现。
图13为本发明用户设备实施例的结构示意图，包括请求模块131、应答模块132和彩振接收模块133。请求模块131接收CRS服务器发送的CRS请求，携带所述CRS请求的消息与携带CAT应答的消息不相同；应答模块132在请求模块131接收到CRS请求后，发送CRS应答给所述CRS服务器，携带所述CRS的消息与携带CAT请求的消息不相同；彩振接收模块133接收所述CRS服务器根据所述CRS请求和CRS应答发送的CRS。
具体的，若携带CAT请求的消息为SIP中的180消息，携带CAT应答的消息为所述180消息的PRACK，则，请求模块131用于接收携带所述CRS请求的SIP中的INVITE消息；应答模块132用于发送携带所述CRS应答的SIP中的183消息或者183消息的PRACK消息的200OK或者所述180消息的PRACK消息的200OK。
或者，若携带CAT请求的消息为SIP中的180消息，携带CAT应答的消息为所述180消息的PRACK，则，请求模块131用于接收携带所述CRS请求的SIP中的183消息的PRACK中；应答模块132用于发送携带所述CRS应答的SIP中的所述183消息的PRACK消息的200OK或者所述180消息的PRACK消息的200OK。
若携带CAT请求的消息为SIP中的183消息，携带CAT应答的消息为所述183消息的PRACK，则，请求模块131用于接收携带所述CRS请求的SIP中的INVITE消息中；应答模块132用于发送携带所述CRS应答的SIP中的所述183消息的PRACK消息的200OK或者SIP中的180消息或者所述180消息的PRACK消息的200OK。
或者，若携带CAT请求的消息为SIP中的183消息，携带CAT应答的消息为所述183消息的PRACK，则，请求模块131用于接收携带所述CRS请求的SIP中的180消息的PRACK中；应答模块132用于发送携带所述CRS应答的SIP中的180消息的PRACK消息的200OK。
本实施例通过将CRS请求添加到与携带CAT应答的消息不相同的请求消息中，且携带CRS应答的响应消息与携带CAT请求的消息不相同，避免一个SIP消息中同时携带两种早期媒体会话的SDP项，使得CRS的协商过程与CAT的协商过程分离，使得两次协商不会相互干扰，从而保证CRS业务和CAT业务并存时，CRS业务与CAT业务的成功实现。
图14为本发明多媒体彩振业务实现方法对应的多媒体铃音系统实施例的结构示意图，包括CAT服务器141、主叫UE142、CRS服务器143和被叫UE144。CAT服务器141部署在被叫侧，CRS服务器143部署在主叫侧。
其中，CAT服务器141可以将CAT请求添加到SIP中的180消息中；主叫UE接收携带所述CAT请求的所述180消息，并将CAT应答携带在所述180消息的PRACK中发送给所述CAT服务器；CAT服务器141还用于与主叫UE142建立基于所述CAT请求和CAT应答的CAT会话，根据所述CAT会话向所述主叫UE142发送多媒体彩铃。此时，
CRS服务器143通过S-CSCF与CAT服务器141通信连接，用于将CRS请求添加到SIP中的INVITE消息中；被叫UE144用于接收携带所述CRS请求的所述INVITE消息，并将CRS应答携带在SIP中的183消息或者183消息的PRACK消息的200OK或者所述180消息的PRACK消息的200OK中发送给所述CRS服务器；CRS服务器143还用于与所述被叫UE144建立基于所述CRS请求和CRS应答的CRS会话，根据所述CRS会话向所述被叫UE144发送CRS。
或者，CRS服务器143通过S-CSCF与CAT服务器141通信连接，用于将CRS请求添加到SIP中的183消息的PRACK中；被叫UE144用于接收携带所述CRS请求的所述183消息的PRACK，并将CRS应答携带在SIP中的所述183消息的PRACK消息的200OK或者所述180消息的PRACK消息的200OK中发送给所述CRS服务器；CRS服务器143还用于与所述被叫UE144建立基于所述CRS请求和CRS应答的CRS会话，根据所述CRS会话向所述被叫UE144发送CRS。
其中，CAT服务器141还可以将CAT请求添加到SIP中的183消息中；主叫UE接收携带所述CAT请求的所述183消息，并将CAT应答携带在所述183消息的PRACK中发送给所述CAT服务器；CAT服务器141还用于与主叫UE142建立基于所述CAT请求和CAT应答的CAT会话，根据所述CAT会话向所述主叫UE142发送多媒体彩铃。此时，
CRS服务器143通过S-CSCF与CAT服务器141通信连接，用于将CRS请求添加到SIP中的INVITE消息中；被叫UE144用于接收携带所述CRS请求的所述INVITE消息，并将CRS应答携带在SIP中的所述183消息的200OK或者SIP中的180消息或者所述180消息的PRACK消息的200OK中发送给所述CRS服务器；CRS服务器143还用于与所述被叫UE144建立基于所述CRS请求和CRS应答的CRS会话，根据所述CRS会话向所述被叫UE144发送CRS。
或者，CRS服务器143通过S-CSCF与CAT服务器141通信连接，用于将CRS请求添加到SIP中的180消息的PRACK中；被叫UE144用于接收携带所述CRS请求的所述180消息的PRACK，并将CRS应答携带在SIP中的所述180消息的PRACK消息的200OK中发送给所述CRS服务器；CRS服务器143还用于与所述被叫UE144建立基于所述CRS请求和CRS应答的CRS会话，根据所述CRS会话向所述被叫UE144发送CRS。
本实施例通过将CRS请求添加到与携带CAT应答的消息不相同的请求消息中，且携带CRS应答的响应消息与携带CAT请求的消息不相同，避免一个SIP消息中同时携带两种早期媒体会话的SDP项，使得CRS的协商过程与CAT的协商过程分离，使得两次协商不会相互干扰，从而保证CRS业务和CAT业务并存时，CRS业务与CAT业务的成功实现。
最后应说明的是：以上实施例仅用以说明本发明的技术方案而非对其进行限制，尽管参照较佳实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对本发明的技术方案进行修改或者等同替换，而这些修改或者等同替换亦不能使修改后的技术方案脱离本发明技术方案的精神和范围。
Claims (14)
1.一种多媒体彩振业务实现方法，应用于同时存在多媒体彩铃服务器根据多媒体彩铃请求和多媒体彩铃应答进行多媒体彩铃业务时，其特征在于，包括：
发送多媒体彩振请求给被叫用户设备，所述多媒体彩振请求与多媒体彩铃应答不在同一消息中；
接收所述被叫用户设备发送的多媒体彩振应答，所述多媒体彩振应答与多媒体彩铃请求不在同一消息中；
根据所述多媒体彩振请求和多媒体彩振应答向所述被叫用户设备发送多媒体彩振。
2.根据权利要求1所述的多媒体彩振业务实现方法，其特征在于：
当携带多媒体彩铃请求的消息为会话初始协议中的180消息，携带多媒体彩铃应答的消息为所述180消息的临时响应确认消息时，
携带所述多媒体彩振请求的消息为会话初始协议中的INVITE消息；
携带所述多媒体彩振应答的消息为会话初始协议中的183消息或者183消息的临时响应确认消息的处理成功消息或者所述180消息的临时响应确认消息的处理成功消息。
3.根据权利要求1所述的多媒体彩振业务实现方法，其特征在于：
当携带多媒体彩铃请求的消息为会话初始协议中的180消息，携带多媒体彩铃应答的消息为所述180消息的临时响应确认消息时，
携带所述多媒体彩振请求的消息为会话初始协议中的183消息的临时响应确认消息；
携带所述多媒体彩振应答的消息为所述183消息的临时响应确认消息的处理成功消息或者所述180消息的临时响应确认消息的处理成功消息。
4.根据权利要求1所述的多媒体彩振业务实现方法，其特征在于：
当携带多媒体彩铃请求的消息为会话初始协议中的183消息，携带多媒体彩铃应答的消息为所述183消息的临时响应确认消息时，
携带所述多媒体彩振请求的消息为会话初始协议中的INVITE消息；
携带所述多媒体彩振应答的消息为所述183消息的临时响应确认消息的处理成功消息或者会话初始协议中的180消息或者所述180消息的临时响应确认消息的处理成功消息。
5.根据权利要求1所述的多媒体彩振业务实现方法，其特征在于：
当携带多媒体彩铃请求的消息为会话初始协议中的183消息，携带多媒体彩铃应答的消息为所述183消息的临时响应确认消息时，
携带所述多媒体彩振请求的消息为会话初始协议中的180消息的临时响应确认消息；
携带所述多媒体彩振应答的消息为所述180消息的临时响应确认消息的处理成功消息。
6.根据权利要求1-5任一权利要求所述的多媒体彩振业务实现方法，其特征在于：
所述多媒体彩振请求为多媒体彩振早期会话协商过程中的offer SDP；
所述多媒体彩振应答为多媒体彩振早期会话协商过程中的answer SDP。
7.一种多媒体彩振业务实现方法，应用于同时存在多媒体彩铃服务器根据多媒体彩铃请求和多媒体彩铃应答进行多媒体彩铃业务时，其特征在于，包括：
接收多媒体彩振服务器发送的多媒体彩振请求，所述多媒体彩振请求与多媒体彩铃应答不在同一消息中；
发送多媒体彩振应答给所述多媒体彩振服务器，所述多媒体彩振应答与多媒体彩铃请求不在同一消息中；
接收所述多媒体彩振服务器根据所述多媒体彩振请求和多媒体彩振应答发送的多媒体彩振。
8.根据权利要求7所述的多媒体彩振业务实现方法，其特征在于：
当携带多媒体彩铃请求的消息为会话初始协议中的180消息，携带多媒体彩铃应答的消息为所述180消息的临时响应确认消息时，
所述接收多媒体彩振服务器发送的多媒体彩振请求包括：接收多媒体彩振服务器发送的携带多媒体彩振请求的会话初始协议中的INVITE消息；
所述发送多媒体彩振应答给所述多媒体彩振服务器包括：发送携带多媒体彩振应答的会话初始协议中的183消息或者183消息的临时响应确认消息的处理成功消息或者所述180消息的临时响应确认消息的处理成功消息给所述多媒体彩振服务器。
9.根据权利要求7所述的多媒体彩振业务实现方法，其特征在于：
当携带多媒体彩铃请求的消息为会话初始协议中的180消息，携带多媒体彩铃应答的消息为所述180消息的临时响应确认消息时，
所述接收多媒体彩振服务器发送的多媒体彩振请求包括：接收多媒体彩振服务器发送的携带多媒体彩振请求的会话初始协议中的183消息的临时响应确认消息；
所述发送多媒体彩振应答给所述多媒体彩振服务器包括：发送携带多媒体彩振应答的所述183消息的临时响应确认消息的处理成功消息或者所述180消息的临时响应确认消息的处理成功消息。
10.根据权利要求7所述的多媒体彩振业务实现方法，其特征在于：
当携带多媒体彩铃请求的消息为会话初始协议中的183消息，携带多媒体彩铃应答的消息为所述183消息的临时响应确认消息时，
所述接收多媒体彩振服务器发送的多媒体彩振请求包括：接收多媒体彩振服务器发送的携带多媒体彩振请求的会话初始协议中的INVITE消息；
所述发送多媒体彩振应答给所述多媒体彩振服务器包括：发送携带多媒体彩振应答的所述183消息的临时响应确认消息的处理成功消息或者会话初始协议中的180消息或者所述180消息的临时响应确认消息的处理成功消息给所述多媒体彩振服务器。
11.根据权利要求7所述的多媒体彩振业务实现方法，其特征在于：
当携带多媒体彩铃请求的消息为会话初始协议中的183消息，携带多媒体彩铃应答的消息为所述183消息的临时响应确认消息时，
所述接收多媒体彩振服务器发送的多媒体彩振请求包括：接收多媒体彩振服务器发送的携带多媒体彩振请求的会话初始协议中的180消息的临时响应确认消息；
所述发送多媒体彩振应答给所述多媒体彩振服务器包括：发送携带多媒体彩振应答的所述180消息的临时响应确认消息的处理成功消息给所述多媒体彩振服务器。
12.根据权利要求7-11任一权利要求所述的多媒体彩振业务实现方法，其特征在于：
所述多媒体彩振请求为多媒体彩振早期会话中的会话初始协议offerSDP；
所述多媒体彩振应答为多媒体彩振早期会话中的会话初始协议answerSDP。
13.一种多媒体彩振服务器，应用于同时存在多媒体彩铃服务器根据多媒体彩铃请求和多媒体彩铃应答进行多媒体彩铃业务时，其特征在于，包括：
发送模块，用于发送多媒体彩振请求给被叫用户设备，所述多媒体彩振请求与多媒体彩铃应答不在同一消息中；
接收模块，用于接收所述被叫用户设备发送的多媒体彩振应答，所述多媒体彩振应答与多媒体彩铃请求不在同一消息中；
彩振发送模块，用于根据所述多媒体彩振请求和多媒体彩振应答向所述被叫用户设备发送多媒体彩振。
14.一种用户设备，应用于同时存在多媒体彩铃服务器根据多媒体彩铃请求和多媒体彩铃应答进行多媒体彩铃业务时，其特征在于，包括：
请求模块，用于接收多媒体彩振服务器发送的多媒体彩振请求，所述多媒体彩振请求与多媒体彩铃应答不在同一消息中；
应答模块，用于发送多媒体彩振应答给所述多媒体彩振服务器，所述多媒体应答与多媒体彩铃请求不在同一消息中；
彩振接收模块，用于接收所述多媒体彩振服务器根据所述多媒体彩振请求和多媒体彩振应答发送的多媒体彩振。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200810223750XA CN101754489B (zh) | 2008-10-09 | 2008-10-09 | 多媒体彩振业务实现方法、多媒体彩振服务器及用户设备 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200810223750XA CN101754489B (zh) | 2008-10-09 | 2008-10-09 | 多媒体彩振业务实现方法、多媒体彩振服务器及用户设备 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101754489A true CN101754489A (zh) | 2010-06-23 |
| CN101754489B CN101754489B (zh) | 2012-05-23 |
Family
ID=42480663
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN200810223750XA Active CN101754489B (zh) | 2008-10-09 | 2008-10-09 | 多媒体彩振业务实现方法、多媒体彩振服务器及用户设备 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101754489B (zh) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110650256A (zh) * | 2019-08-15 | 2020-01-03 | 咪咕音乐有限公司 | 视频彩铃的播放方法、电子设备及计算机可读存储介质 |
| CN112087548A (zh) * | 2019-03-28 | 2020-12-15 | 华为技术有限公司 | 一种播放多媒体彩振、彩铃的方法、应用服务器 |
| US11849067B2 (en) | 2019-03-28 | 2023-12-19 | Huawei Technologies Co., Ltd. | Method for playing multimedia customized ringing signal and customized alerting tone, and application server |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN100425049C (zh) * | 2005-06-22 | 2008-10-08 | 北京邮电大学 | 移动终端下载多媒体振铃音的实现方法及系统 |
| CN1859480B (zh) * | 2005-12-22 | 2010-05-12 | 华为技术有限公司 | 被叫用户收听多彩振铃音方法及系统 |
| CN101188809A (zh) * | 2007-11-27 | 2008-05-28 | 中国电信股份有限公司 | 一种多媒体彩振的实现方法、电话终端和应用服务器 |
-
2008
- 2008-10-09 CN CN200810223750XA patent/CN101754489B/zh active Active
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112087548A (zh) * | 2019-03-28 | 2020-12-15 | 华为技术有限公司 | 一种播放多媒体彩振、彩铃的方法、应用服务器 |
| US11849067B2 (en) | 2019-03-28 | 2023-12-19 | Huawei Technologies Co., Ltd. | Method for playing multimedia customized ringing signal and customized alerting tone, and application server |
| CN110650256A (zh) * | 2019-08-15 | 2020-01-03 | 咪咕音乐有限公司 | 视频彩铃的播放方法、电子设备及计算机可读存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN101754489B (zh) | 2012-05-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101292489B (zh) | 用于电路交换子系统呼叫的多媒体子系统业务控制 | |
| CN1859475B (zh) | 一种实现多媒体回铃音的方法及系统 | |
| CN101262414B (zh) | 语音呼叫连续性业务中的域切换方法 | |
| CN101884205A (zh) | Ims集中式服务中i1-ps信令的动态发起 | |
| CN102123211A (zh) | 一种多方通话业务的实现方法和系统 | |
| CN101764802B (zh) | 在通话期间播放多媒体铃音的方法、服务器及终端设备 | |
| CN101459735B (zh) | 一种彩铃、彩像业务的实现方法及系统 | |
| CN102056249B (zh) | 一种带彩铃会话的起呼请求的切换系统及方法 | |
| CN102394989A (zh) | 在通话期间播放多媒体铃音的方法、服务器及终端设备 | |
| CN102006371B (zh) | 一种实现多媒体彩振业务的方法及设备 | |
| CN101754489B (zh) | 多媒体彩振业务实现方法、多媒体彩振服务器及用户设备 | |
| CN101202955B (zh) | 一种在ims网络中实现主叫彩像业务的方法以及装置 | |
| CN102017576A (zh) | 用于终止呼叫的方法和ip上的语音终端 | |
| CN102883376A (zh) | 一种集中控制业务用户建立优先级会话的方法、服务器及系统 | |
| CN101212778A (zh) | 修改振铃音的方法 | |
| CN101217703A (zh) | 一种在线彩铃彩像业务的实现方法 | |
| CN101459872B (zh) | 单对话彩铃彩像业务在应答后更新媒体的方法 | |
| CN101753517A (zh) | 发送及接收多媒体铃音文件的方法 | |
| CN101795330A (zh) | 在通话期间播放多媒体铃音的方法、服务器及终端设备 | |
| CN102665178B (zh) | 余额提醒方法、装置及系统、应用服务器 | |
| CN102664863B (zh) | 终端实现呼叫等待的方法、装置和系统 | |
| CN101668229A (zh) | 多媒体铃音业务的呼叫和控制方法、装置及系统 | |
| CN101998324B (zh) | 实现一号通顺振业务的方法和一号通顺振应用服务器 | |
| CN101631389B (zh) | Ip多媒体子系统异常提示音媒体播放方法及系统 | |
| CN102257784B (zh) | 一种实现多媒体铃音业务安全机制的方法、设备及系统 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| CP01 | Change in the name or title of a patent holder |
Address after: 518129 Building 2, B District, Bantian HUAWEI base, Longgang District, Shenzhen, Guangdong. Patentee after: Huawei terminal (Shenzhen) Co.,Ltd. Address before: 518129 Building 2, B District, Bantian HUAWEI base, Longgang District, Shenzhen, Guangdong. Patentee before: HUAWEI DEVICE Co.,Ltd. |
|
| CP01 | Change in the name or title of a patent holder | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20181224 Address after: 523808 Southern Factory Building (Phase I) Project B2 Production Plant-5, New Town Avenue, Songshan Lake High-tech Industrial Development Zone, Dongguan City, Guangdong Province Patentee after: HUAWEI DEVICE Co.,Ltd. Address before: 518129 Building 2, B District, Bantian HUAWEI base, Longgang District, Shenzhen, Guangdong. Patentee before: Huawei terminal (Shenzhen) Co.,Ltd. |
|
| TR01 | Transfer of patent right |