具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚明白,下面结合实施例和附图,对本发明实施例做进一步详细说明。在此,本发明的示意性实施例及其说明用于解释本发明,但并不作为对本发明的限定。
实施例一
本发明实施例提供一种在通话期间播放多媒体铃音的方法,以下结合附图对本实施例进行详细说明。
图1为本发明实施例的方法流程图,请参照图1,本发明实施例的方法主要包括:
101:接收主叫终端或被叫终端发送的请求标志;
102:根据所述请求标志触发在通话期间继续播放多媒体铃音。
通过本发明实施例的在通话期间继续播放多媒体铃音的方法,可以实现在通话期间为主叫终端或被叫终端继续播放多媒体铃音。
实施例二
本发明实施例还提供一种在通话期间播放多媒体铃音的方法,以下结合附图对本实施例进行详细说明。
图1为本发明实施例的方法流程图,请参照图1,本发明实施例的方法主要包括:
步骤101:接收主叫终端或被叫终端发送的请求标志;
在本实施例中,被叫终端发送的请求标志可以通过IMS域的摘机应答消息200 OK消息,或者在摘机应答消息之后以INFO消息或MESSAGE消息的头域或消息体携带;或者通过CS域的UUI消息、或者FACILITY消息携带,或者通过DTMF(双音多频)方式携带;或者通过带外方式或离线方式从被叫获取该请求标志,本发明实施例并不以此作为限制。
在本实施例中,请求标志可以是多媒体振铃音混频标志,以请求服务器对多媒体振铃音和主叫终端到被叫终端的通话媒体流进行混频操作,这种情况下,只有被叫终端能在通话过程中听到多媒体振铃音。
在本实施例中,请求标志可以是多媒体回铃音混频标志,以请求服务器对多媒体回铃音和被叫终端到主叫终端的通话媒体流进行混频操作,这种情况下,只有主叫终端能在通话过程中听到多媒体回铃音。
在本实施例中,请求标志也可以是多媒体背景音混频标志,以请求服务器对多媒体振铃音或多媒体回铃音和主叫终端与被叫终端之间的通话媒体流进行混频操作,这种情况下,主叫终端和被叫终端都能在通话过程中听到多媒体振铃音或多媒体回铃音,此时多媒体振铃音或多媒体回铃音充当一个多媒体背景音的工作。
在本实施例中,请求标志也可以是多媒体铃音链接下载标志,以请求服务器下发多媒体铃音的链接,以供主叫终端或被叫终端下载该多媒体铃音后,在通话过程中进行本地播放。
在本实施例中,请求标志还可以是终端混频能力标志,以请求服务器端不必停止多媒体铃音的播放,以在主叫终端或被叫终端对多媒体铃音和通话媒体流进行混频后进行本地播放,这种情况下,主叫终端或被叫终端需要具备混频能力。
步骤102:根据所述请求标志触发在通话期间继续播放多媒体铃音。
在本实施例中,如果接收到的请求标志为多媒体振铃音混频标志,则根据所述请求标志触发在通话期间继续播放多媒体铃音的步骤为:
向媒体资源功能实体发送携带有多媒体振铃音混频标志的指示消息,指示媒体资源功能实体对多媒体振铃音和主叫终端到被叫终端的通话媒体流进行混音/混频。
在本实施例中,如果接收到的请求标志为多媒体回铃音混频标志,则根据所述请求标志触发在通话期间继续播放多媒体铃音的步骤为:
向媒体资源功能实体发送携带有多媒体回铃音混频标志的指示消息,指示媒体资源功能实体对多媒体回铃音和被叫终端到主叫终端的通话媒体流进行混音/混频。
在本实施例中,如果接收到的请求标志为多媒体背景音混频标志,则根据请求标志触发在通话期间继续播放多媒体铃音的步骤为:
向媒体资源功能实体发送携带有多媒体背景音混频标志的指示消息,指示媒体资源功能实体对多媒体振铃音或多媒体回铃音和主叫终端与被叫终端之间的通话媒体流进行混音/混频。
根据本实施例,如果指示消息为指示对多媒体振铃音或多媒体回铃音和主叫终端与被叫终端之间的通话媒体流进行混音/混频,则意味着要将多媒体振铃音或多媒体回铃音转换为背景音,因此,在本实施例的方法中,还要包括下列与主叫终端和被叫终端协商多媒体背景音的步骤:
向主叫终端和被叫终端发送多媒体背景音请求,协商多媒体背景音会话;
接收主叫终端和被叫终端对所述多媒体背景音请求的应答消息。
在本实施例中,多媒体背景音请求可以通过re-INVITE消息传递,也可以通过REFER消息传递,本实施例并不以此作为限制。
根据本实施例的方法,在主叫终端和被叫终端通话过程中,主叫终端或者被叫终端或者主叫终端和被叫终端可以继续听到多媒体铃音,由于该多媒体铃音是由服务器端在通话过程中对多媒体振铃音或多媒体回铃音和通话媒体流混频后播放,因此,在主叫终端或被叫终端挂机后,本实施例的方法还包括下列步骤:
在接收到挂机消息后,向媒体资源功能实体发送停止消息,指示媒体资源功能实体停止混音/混频操作及停止播放多媒体铃音;
接收媒体资源功能实体返回的停止确认消息,确认停止混音/混频操作及停止播放多媒体铃音。
在本实施例中,在IMS域中,该挂机消息可以是BYE消息;在CS域中,该挂机消息可以是disconnect消息。
在本实施例中,如果接收到的请求标志为多媒体铃音链接下载标志,则根据所述请求标志触发在通话期间继续播放多媒体铃音的步骤包括:
向媒体资源功能实体发送携带有多媒体铃音链接下载标志的指示消息,指示媒体资源功能实体发送多媒体铃音链接;
接收媒体资源功能实体返回的包含多媒体铃音链接的对所述指示消息的应答消息。
根据本实施例,在接收到主叫终端对摘机应答消息的确认消息后,即可发送携带有多媒体铃音链接的确认消息到请求终端,请求终端获取了多媒体铃音下载链接,下载该多媒体铃音后,即可以进行本地播放。
在本实施例中,如果接收到的请求标志为终端混频能力标志,则根据所述请求标志触发在通话期间继续播放多媒体铃音的步骤包括:
在接收到摘机应答消息后,继续多媒体铃音播放。
根据本实施例的方法,由于服务器端没有停止发送多媒体铃音,故可以由请求终端对多媒体铃音和通话媒体流混频后在本地播放,因此,在主被叫终端挂机后,本实施例的方法还包括下列步骤:
在接收到挂机消息后,向媒体资源功能实体发送停止消息,指示媒体资源功能实体停止播放多媒体铃音;
接收媒体资源功能实体返回的停止确认消息,确认停止播放多媒体铃音。
在本实施例中,如果为用户播放的多媒体铃音文件是图片、文本或电子名片等文件,则多媒体铃音服务器在收到相应的请求标志后,在接收到200OK消息后,不进行混频或混音操作,而只是继续播放多媒体铃音文件即可。
通过本实施例的方法,使得通话过程中的主叫终端或者被叫终端或者主被叫终端都可以继续听到多媒体铃音,解决了现有技术中无法实现多媒体铃音在通话期间为用户继续播放的问题,以及多媒体振铃音或多媒体回铃音在通话期间转换为多媒体背景音的问题。
本实施例的方法不仅可以应用于电路交换域(CS域)的呼叫过程,也可以应用于IMS域(IP多媒体子***)的呼叫过程,实现CRS(或CAT)在IMS域的早期会话方式、多会话方式、网关方式,以及CS域的跨接方式、非跨接方式下的通话过程中继续播放,下面分别以不同的实施例加以说明。
实施例三
本实施例的方法应用于IMS域的早期会话方式,由服务器端对多媒体振铃音和通话媒体流进行混频,实现单向“CRS+通话”到被叫。
在本实施例中,当被叫终端的用户摘机时,在被叫终端发送的200 OK消息中携带请求服务器混频标志,在本实施例中,该标志为多媒体振铃音混频标志,多媒体振铃音应用服务器CRS AS接收到此标志后触发相应的动作,即指示媒体资源功能实体MRF对CRS和通话媒体流进行混频操作,并将混频后的媒体流发送给被叫终端。
在本实施例中,请求终端为被叫,假设主叫终端A的用户为被叫终端B的用户定制了多媒体振铃音CRS业务。A呼叫B时,CRS AS指示MRF为B播放多媒体振铃音,当B摘机应答时,UE B发送的200 OK消息中携带请求服务器混频标志,该标志可以由主叫终端的用户在主叫终端上预先进行设置,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、CBTAS和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消息进行应答,200 OK消息携带了早期会话(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的确认消息200 OK,途径P-CSCF、S-CSCF到达CRS AS。
步骤3022~步骤3023:CRS AS发送INFO消息给MRF,指示MRF开始为UE-B播放多媒体彩振CRS。MRF返回200 OK作为确认,并开始播放多媒体彩振。此时被叫用户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)的200 OK消息,根据本实施例的方法,200 OK消息同时携带了混音/混频请求(Mixing请求)标志,即多媒体振铃音混频标志,该标志可通过SIP头域、或SDP、或XML文件来携带。对于XML的携带方式,可以将SIP头域中的content-type置为multipart/mixed类型,然后在SDP消息体后携带XML文件即可。200 OK消息途径P-CSCF、S-CSCF到达CRS AS。
步骤3032~步骤3033:根据本实施例的方法,CRS AS接收到带有Mixing请求标志的200 OK之后,发送INFO消息给MRF,INFO通过SDP或头域字段携带Mixing请求标志,以指示MRF启动MIX单元,准备对CRS和通话媒体流进行混音/混频。MRF返回对INFO的应答消息200 OK。
步骤3034~步骤3035:CRS AS转发带有正常会话SDP Answer(A1)的200 OK消息,途径S-CSCF,到达UE-A。
步骤3036~步骤3040:UE-A返回对200 OK消息的确认消息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返回200 OK消息给UE-B。通话结束。
在本实施例的第3029~3031步骤中,除了使用200 OK携带请求服务器混频标志(多媒体振铃音混频标志)外,还可以在200 OK之后使用INFO或MESSAGE等消息携带。本实施例并不以此作为限制。另外,被叫用户除了在摘机时通过200 OK消息携带请求混频标志外,还可以通过带外方式(如短消息)或离线方式(如Web)实现混频请求。
在本实施例中,由于是服务器端进行混频(MIX)操作,现有的网络实体即可支持该项功能。且对终端侧无要求,普通终端即可实现通话期间正常接收CRS。
实施例四
本实施例的方法应用于IMS域的早期会话方式,由服务器端对多媒体振铃音和通话媒体流进行混频,实现双向“CRS+通话”到主、被叫。
在本实施例中,当被叫终端的用户摘机时,被叫终端发送的200 OK消息中携带请求服务器混频标志,在本实施例中,该标志为多媒体背景音混频标志,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消息进行应答,200 OK消息携带了早期会话(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的确认消息200 OK,途径P-CSCF、S-CSCF到达CRS AS。
步骤4022~步骤4023:CRS AS发送INFO消息给MRF,指示MRF开始为UE-B播放多媒体彩振CRS。MRF返回200 OK作为确认,并开始播放多媒体彩振。此时被叫用户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)的200 OK消息,根据本实施例的方法,200 OK消息同时携带了混音/混频请求(Mixing请求)标志,即多媒体背景音混频标志,该标志可通过第二个SDP、或头域字段、或XML文件携带,途径P-CSCF、S-CSCF到达CRS AS。
步骤4032~步骤4033:根据本实施例的方法,CRS AS接收到带有Mixing请求标志的200 OK之后,发送INFO消息给MRF,INFO通过SDP或头域字段携带Mixing请求标志,以指示MRF启动MIX单元,准备对CRS和通话媒体流进行混音/混频。MRF返回对INFO的应答消息200 OK。
步骤4034~步骤4035:CRS AS转发带有正常会话SDP Answer(A1)的200 OK消息,途径S-CSCF,到达UE-A。
步骤4036~步骤4040:UE-A返回对200 OK消息的确认消息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的响应200 OK给CRS AS,200 OK消息携带了CBT会话的SDP Answer(A2)。
步骤4049~步骤4050:根据本实施例的方法,UE-A返回对re-INVITE的响应200 OK给CRS AS,200 OK消息携带了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返回200 OK消息给UE-B。通话结束。
在本实施例的第4041~4054步骤中,re-INVITE方法也可以替换为REFER方法。即CRS AS向主被叫终端发送REFER请求,邀请主被叫加入CBT模式,其中Refer-to字段携带了CBT模式的URI。主被叫终端返回Accepted响应,并发送NOTIFY消息,以告知MRF终端已接收请求。MRF返回200 OK。这样,主被叫终端即进入了CBT模式。
在本实施例中,由于是服务器端进行混频,所以对终端侧没有要求。且在通话期间CRS转换为CBT模式,使得主被叫双方均可欣赏到多媒体背景内容。
实施例五
本实施例的方法应用于IMS域的早期会话方式,由终端对多媒体振铃音和通话媒体流进行混频,实现单向“CRS+通话”到被叫。
在本实施例中,当被叫终端的用户摘机后,被叫终端在200 OK消息中携带终端混频能力标志,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消息进行应答,200 OK消息携带了早期会话(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的确认消息200 OK,途径P-CSCF、S-CSCF到达CRS AS。
步骤5022~步骤5023:CRS AS发送INFO消息给MRF,指示MRF开始为UE-B播放多媒体彩振CRS。MRF返回200 OK作为确认,并开始播放多媒体彩振。此时被叫用户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)的200 OK消息,根据本实施例的方法,200 OK消息同时携带了终端Mix能力标志,以表示终端具有混音/混频的能力,该标志可通过第二个SDP、或头域字段、或XML文件携带,途径P-CSCF、S-CSCF到达CRS AS。
步骤5032~步骤5033:CRS AS转发带有正常会话SDP Answer(A1)的200 OK消息,途径S-CSCF,到达UE-A。
步骤5034~步骤5038:UE-A返回对200 OK消息的确认消息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的应答消息200 OK。UE-A返回200 OK消息给UE-B。通话结束。
在本实施例中,由于是被叫终端进行混频,所以对服务器无要求,可以减少服务器的处理过程,降低服务器负荷。但对终端要求较高,需要在现有终端中增加专门的混频模块。
实施例六
本实施例的方法应用于IMS域的早期会话方式,由终端通过带外方式下载多媒体振铃音,实现在通话过程中被叫本地播放。
在本实施例中,当被叫终端的用户摘机后,被叫终端在200 OK消息中携带多媒体振铃音下载标志,请求服务器下发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消息进行应答,200 OK消息携带了早期会话(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的确认消息200 OK,途径P-CSCF、S-CSCF到达CRS AS。
步骤6022~步骤6023:CRS AS发送INFO消息给MRF,指示MRF开始为UE-B播放多媒体彩振CRS。MRF返回200 OK作为确认,并开始播放多媒体彩振。此时被叫用户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)的200 OK消息,根据本实施例的方法,200 OK消息同时携带了CRS URI的请求标志,该标志可通过第二个SDP、或Alert-Info/Call-Info头域、或XML文件携带,途径P-CSCF、S-CSCF到达CRS AS。
步骤6032~步骤6033:CRS AS接收到200 OK之后,发送BYE消息给MRF,指示MRF停止播放CRS,根据本实施例的方法,BYE消息通过SDP携带了CRS URI的请求标志,以指示MRF发送一个CRS的HTTP URI。MRF返回对BYE的应答消息200 OK,根据本实施例的方法,200 OK通过SDP或头域字段携带了CRS的HTTP URI。
步骤6034~步骤6035:CRS AS转发带有正常会话SDP Answer(A1)的200 OK消息,途径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返回200 OK消息给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 ServerA向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到UE A方向的音频/视频通话流不做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以及或者CBTAS的功能,多媒体铃音服务器可以实现前述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混频后的多媒体铃音和通话媒体流。
通过本实施例的终端设备,使得通话过程中的主叫终端或者被叫终端或者主被叫终端都可以继续听到多媒体振铃音或多媒体回铃音,解决了现有技术中无法实现多媒体振铃音或多媒体回铃音在通话期间为用户继续播放的问题,以及多媒体振铃音或多媒体回铃音在通话期间转换为多媒体背景音的问题。
实施例十一
本实施例的组网结构及其功能与实施例三相同,在此不再赘述,此外,本实施例应用场景如下:运营商或用户可以预先在服务器上配置通话过程中继续播放彩铃/彩振的策略,当CRS AS接收到被叫终端发来的摘机消息时,指示MRF(媒体资源功能)进行相应会场资源的预留或通话期间混音的资源的预留(注:CRS AS也可以在接收到主叫呼叫请求消息时即指示MRF进行相应会场资源的预留或通话期间混音的资源的预留),然后执行后续的会话更新和混音流程。
参见图12,具体流程如下:
步骤1201至步骤1228与实施例四中的步骤401-4028相同,此处不再赘述;
步骤1229~步骤1231:UE-B发送摘机消息,该消息途径P-CSCF、S-CSCF,到达CRS-AS;
步骤1232~步骤1234:CRS-AS向UE-B返回确认消息;
步骤1235~步骤1236:CRS-AS向MRF请求会场资源或请求用于通话期间混音的资源,需要说明的是这两步也可以放在步骤1202和1231之间的任意时间点执行;
步骤1237~步骤1239:CRS-AS向UE-B发送re-INVITE消息,消息中携带了MRF生成的Offer SDP,并且SDP中的IP地址和端口号均指向MRF。
步骤1240~步骤1242:UE-B向CRS-AS返回响应消息,消息中携带了Answer SDP;
步骤1243:CRS-AS向UE-A发送UPDATE消息或者发送re-INVITE消息,消息中携带了MRF生成的Offer SDP,并且SDP中的IP地址和端口号均指向MRF;
步骤1244:UE-A向CRS返回响应消息,消息中携带了Answer SDP;
步骤1245:CRS-AS向UE-A发送摘机消息;
步骤1246:UE-A向CRS-AS返回确认消息;
步骤1247至步骤1258与实施例四中的步骤4051至步骤4062相同,此处不再赘述。
需要说明的是,CRS-AS接收UE-A的确认消息后,指示MRF进行混音处理,此时,UE-A和UE-B之间的正常通话建立,MRF作为一个Mixer(混音/混频器)锚定在主被叫通话媒体路径上,将主/被叫用户的语音/视频与彩振媒体进行MIX操作,并分别发送给主/被叫双方。注:在通话过程中,MRF可以将彩振媒体进行双向的混音,也可以进行单向的混音,即可以同时向主被叫双方播放彩振,也可以仅为主叫播放彩振、或仅为被叫播放彩振。
本实施例提供的方法的优点在于实现了实现多媒体铃音在通话期间为用户继续播放的问题,且无须用户在通话过程中参与任何操作,给用户带来一种全新的体验,有利于该技术的实现与推广。
实施例十二
本实施例的组网结构和与应用场景与实施例十一相同,此处不再赘述。
参见图13,一种在通话期间播放多媒体铃音的方法,包括如下步骤:
步骤1301、接收被叫终端的摘机消息;
CRS-AS接收被叫终端的摘机消息;
步骤1302、分别向主叫终端和被叫终端发送消息以更新会话;
CRS-AS向主叫终端发送携带用于协商新的会话的请求(SDP offer)的更新消息(UPDATE)或呼叫请求消息(re-INVITE),向被叫终端发送携带用于协商新的会话的请求(SDP offer)的呼叫请求消息(re-INVITE);其中向主叫终端和被叫终端发送消息的顺序不做限定,可以先向主叫终端发送消息,也可以先向被叫终端发送消息,也可以同时发送;
步骤1303、指示媒体资源功能执行混音处理,从而在通话期间继续播放多媒体铃音。
CRS-AS指示媒体资源功能执行混音处理,从而在通话期间继续播放多媒体铃音,具体为:CRS-AS指示媒体资源功能对多媒体铃音和正常通话媒体进行混音处理,从而在通话过程中向被叫终端、主叫终端或主被叫终端继续播放多媒体铃音。
以上方法步骤具体可参见实施例十一中的相关内容和附图12。
本实施例提供的方法的优点在于实现了实现多媒体铃音在通话期间为用户继续播放的问题,且无须用户在通话过程中参与任何操作,给用户带来一种全新的体验,有利于该技术的实现与推广。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到本发明可以通过硬件实现,也可以可借助软件加必要的通用硬件平台的方式来实现,基于这样的理解,本发明的技术方案可以以软件产品的形式体现出来,该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM,U盘,移动硬盘等)中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述的方法。
以上所述的具体实施例,对本发明的目的、技术方案和有益效果进行了进一步详细说明,所应理解的是,以上所述仅为本发明的具体实施例而已,并不用于限定本发明的保护范围,凡在本发明的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。