CN102130888B - 通话过程中继续播放彩铃和彩振的方法和服务器 - Google Patents
通话过程中继续播放彩铃和彩振的方法和服务器 Download PDFInfo
- Publication number
- CN102130888B CN102130888B CN201010003386.3A CN201010003386A CN102130888B CN 102130888 B CN102130888 B CN 102130888B CN 201010003386 A CN201010003386 A CN 201010003386A CN 102130888 B CN102130888 B CN 102130888B
- Authority
- CN
- China
- Prior art keywords
- server
- subscriber equipment
- communication process
- message
- color
- 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.)
- Expired - Fee Related
Links
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Telephonic Communication Services (AREA)
Abstract
本发明实施例提供一种通话过程中继续播放彩铃和彩振的方法和服务器，该方法包括：确定在通话过程中继续播放彩铃之后，将接收到的更新消息中SDP offer的IP地址和端口号修改为彩振服务器的MRF实体的IP地址和端口号，并将修改后的更新消息发送至主叫用户设备；接收主叫用户设备发送的针对修改后的更新消息的响应消息，将该响应消息中SDP answer的IP地址和端口号修改为彩振服务器的MRF实体的IP地址和端口号，并将修改后的响应消息发送至彩铃服务器；指示彩振服务器的MRF实体在通话过程中进行混音处理。本发明实施例实现了在通话过程中继续播放彩铃和彩振，缩短了在通话过程中继续播放彩铃和彩振时的时间延迟，提高了用户体验度。
Description
技术领域
本发明实施例涉及通信技术领域，尤其涉及一种通话过程中继续播放彩铃和彩振的方法和服务器。
背景技术
随着移动通信网络的发展以及移动用户设备的普及，移动网络的网络运营商在基本通话业务之外为用户终端提供了更为丰富的增值业务，如彩铃业务和彩振业务。
彩铃即主叫用户设备呼叫被叫用户设备时，在被叫用户设备摘机之前，主叫用户设备欣赏到的多媒体回铃音；彩振即主叫用户设备呼叫被叫用户设备时，在被叫用户设备摘机接听之前，被叫用户设备欣赏到的多媒体振铃音。
在实现本发明的过程中，发明人发现现有技术中至少存在如下问题：
彩铃服务器和彩振服务器彼此并不知道对方是否激活或执行了继续播放的更新流程，因此彩铃服务器和彩振服务器会各自执行各自的更新流程，从而导致在通话过程中继续播放彩铃和彩振时，时间延迟过大，被叫用户设备摘机之后，需要等待较长时间之后才能进入正常通话。
发明内容
本发明实施例提供一种通话过程中继续播放彩铃和彩振的方法和服务器，以缩短在通话过程中继续播放彩铃和彩振时的时间延迟。
本发明实施例提供一种通话过程中继续播放彩铃和彩振的方法，包括：
根据接收到的临时响应消息和更新消息确定在通话过程中继续播放彩铃，将所述更新消息中会话描述协议请求的因特网协议地址和端口号修改为彩振服务器的媒体资源功能实体的因特网协议地址和端口号，并将修改后的更新消息发送至主叫用户设备；
接收所述主叫用户设备发送的针对修改后的更新消息的响应消息，将所述响应消息中会话描述协议应答的因特网协议地址和端口号修改为所述彩振服务器的媒体资源功能实体的因特网协议地址和端口号，并将修改后的响应消息发送至彩铃服务器；
指示所述彩振服务器的媒体资源功能实体在通话过程中进行混音处理。
本发明实施例还提供一种通话过程中继续播放彩铃和彩振的方法，包括：
第二服务器接收第一服务器在通话过程中继续播放的铃音标识；
根据所述铃音标识请求所述第二服务器的媒体资源功能实体预留与所述铃音标识对应的播放资源和混音资源；
在所述第二服务器的媒体资源功能实体与被叫用户设备之间建立媒体通道，并在所述第二服务器的媒体资源功能实体与主叫用户设备之间建立媒体通道；
指示所述第二服务器的媒体资源功能实体在通话过程中进行混音处理。
本发明实施例还提供一种彩振服务器，包括：
确定模块，用于根据接收到的临时响应消息和更新消息确定在通话过程中继续播放彩铃；
第一修改模块，用于在所述确定模块确定在通话过程中继续播放彩铃之后，将所述更新消息中会话描述协议请求的因特网协议地址和端口号修改为所述彩振服务器的媒体资源功能实体的因特网协议地址和端口号；
第一发送模块，用于将所述第一修改模块修改后的更新消息发送至主叫用户设备；
接收模块，用于接收所述主叫用户设备发送的针对修改后的更新消息的响应消息；
第二修改模块，用于将所述接收模块接收的响应消息中会话描述协议应答的因特网协议地址和端口号修改为所述彩振服务器的媒体资源功能实体的因特网协议地址和端口号；
第二发送模块，用于将所述第二修改模块修改后的响应消息发送至彩铃服务器；
指示模块，用于指示所述彩振服务器的媒体资源功能实体在通话过程中进行混音处理。
本发明实施例还提供一种彩铃服务器，包括：
标识接收模块，用于接收彩振服务器在通话过程中继续播放的铃音标识；
资源预留模块，用于根据所述标识接收模块接收的铃音标识请求所述彩铃服务器的媒体资源功能实体预留与所述铃音标识对应的播放资源和混音资源；
通道建立模块，用于在所述彩铃服务器的媒体资源功能实体与被叫用户设备之间建立媒体通道，并在所述彩铃服务器的媒体资源功能实体与主叫用户设备之间建立媒体通道；
混音指示模块，用于指示所述彩铃服务器的媒体资源功能实体在通话过程中进行混音处理。
通过本发明实施例，彩铃服务器可以识别出彩振会在通话过程中继续播放，或者，彩振服务器可以识别出彩铃会在通话过程中继续播放，然后彩铃服务器或彩振服务器再执行更新流程，实现在通话过程中继续播放彩铃和彩振，并缩短了在通话过程中继续播放彩铃和彩振时的时间延迟，提高了用户体验度。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本发明通话过程中继续播放彩铃和彩振的方法一个实施例的流程图；
图2为本发明通话过程中继续播放彩铃和彩振的方法另一个实施例的流程图；
图3为本发明通话过程中继续播放彩铃和彩振的方法再一个实施例的流程图；
图4为本发明通话过程中继续播放彩铃和彩振的方法又一个实施例的流程图；
图5为本发明彩振服务器一个实施例的结构示意图；
图6为本发明彩振服务器另一个实施例的结构示意图；
图7为本发明第二服务器一个实施例的结构示意图；
图8为本发明第二服务器另一个实施例的结构示意图；
图9为本发明通话过程中继续播放彩铃和彩振的系统一个实施例的结构示意图；
图10为本发明通话过程中继续播放彩铃和彩振的系统另一个实施例的结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。
图1为本发明通话过程中继续播放彩铃和彩振的方法一个实施例的流程图，如图1所示，本实施例可以包括：
步骤101，根据接收到的临时响应消息和更新消息确定在通话过程中继续播放彩铃，将该更新消息中会话描述协议请求的IP地址和端口号修改为彩振服务器的媒体资源功能实体的IP地址和端口号，并将修改后的更新消息发送至主叫用户设备。
本实施例中，当彩铃的模式为早期会话模式时，根据接收到的临时响应消息和更新消息确定在通话过程中继续播放彩铃可以为：彩振服务器存储接收到的临时响应消息中早期会话类型的会话描述协议请求的IP地址；当该彩振服务器接收到的更新消息中包括会话类型的会话描述协议请求时，如果该会话类型的会话描述协议请求的IP地址与存储的IP地址相同，则该彩振服务器可以确定在通话过程中继续播放彩铃。
优选地，在彩振服务器存储接收到的临时响应消息中早期会话类型的会话描述协议请求的IP地址之前，该彩振服务器可以在临时响应消息包括请求(Require)头域和内容部署类型(Content-disposition)头域，且请求头域和内容部署类型头域的内容均为早期会话时，确定该临时响应消息中包括早期会话类型的会话描述协议请求。
当彩铃的模式为分支模式时，根据接收到的临时响应消息和更新消息确定在通话过程中继续播放彩铃可以为：彩振服务器存储接收到的临时响应消息中会话描述协议的IP地址，该临时响应消息包括早期媒体授权(P-early-media)头域，该早期媒体授权头域的内容为发送接收(sendrecv)或仅发送(sendonly)；然后，当该彩振服务器接收到的更新消息的对话标识与上述临时响应消息的对话标识不同时，如果更新消息中会话描述协议的IP地址与存储的IP地址相同，则彩振服务器可以确定在通话过程中继续播放彩铃。
另外，当彩铃的模式为早期会话模式或分支模式时，彩振服务器还可以根据接收到的临时响应消息、响应消息或更新消息确定在通话过程中继续播放彩铃，具体可以为：在临时响应消息、响应消息或更新消息中携带彩铃继续播放标识，彩振服务器根据接收到的临时响应消息、响应消息或更新消息所携带的彩铃继续播放标识，确定在通话过程中继续播放彩铃。其中，在临时响应消息、响应消息或更新消息中携带彩铃继续播放标识可以为：在临时响应消息、响应消息或更新消息的联系(contact)头域或接受联系(accept-contact)头域中携带“+g.3gpp.crs.continue”；当然，本发明实施例并不仅限于此，也可以采用其他方式在临时响应消息、响应消息或更新消息中携带彩铃继续播放标识，本发明实施例对彩铃继续播放标识的携带方式不作限定。
本实施例中，确定在通话过程中继续播放彩铃之后，修改接收到的更新消息中会话描述协议请求的IP地址和端口号之前，彩振服务器还需进一步判断接收到的更新消息中会话描述协议请求的视频行的方向属性是否为发送接收(sendrecv)；当接收到的更新消息中会话描述协议请求的视频行的方向属性为发送接收时，彩振服务器请求该彩振服务器的媒体资源功能实体预留用于实现音频混音和视频混频的资源；或者，当接收到的更新消息中会话描述请求的视频行的方向属性不是发送接收，或者该会话描述请求没有视频行时，彩振服务器请求该彩振服务器的媒体资源功能实体预留用于实现音频混音的资源。
步骤102，接收主叫用户设备发送的针对修改后的更新消息的响应消息，将该响应消息中会话描述协议应答中的IP地址和端口号修改为彩振服务器的媒体资源功能实体的IP地址和端口号，并将修改后的响应消息发送至彩铃服务器。
本实施例中，彩振服务器将修改后的响应消息发送至彩铃服务器之后，彩振服务器与彩铃服务器之间建立了媒体通道。在通话过程中，彩铃服务器可以指示该彩铃服务器的媒体资源功能实体将被叫用户设备发送的媒体流与彩铃媒体流混合为一路媒体流后转发至主叫用户设备；并将来自彩振服务器的媒体流直接转发至被叫用户设备。
步骤103，指示彩振服务器的媒体资源功能实体在通话过程中进行混音处理。
具体地，彩振服务器可以指示该彩振服务器的媒体资源功能实体在通话过程中将主叫用户设备发送的媒体流与彩振媒体流混合为一路媒体流后转发至被叫用户设备；并将来自彩铃服务器的媒体流直接转发至主叫用户设备。
上述实施例中，彩振服务器可以识别出彩铃会在通话过程中继续播放，然后彩振服务器代替主叫用户设备与彩铃服务器建立媒体通道，通话过程中彩振服务器将来自彩铃服务器的媒体流直接转发至主叫用户设备，并将主叫用户设备发送的媒体流与彩振媒体流混合为一路媒体流后转发至被叫用户设备，从而实现了在通话过程中继续播放彩铃和彩振，并缩短了在通话过程中继续播放彩铃和彩振时的时间延迟，提高了用户体验度。
图2为本发明通话过程中继续播放彩铃和彩振的方法另一个实施例的流程图，本实施例的应用场景为：主叫用户设备与被叫用户设备分别位于不同的网络中，例如：位于不同运营商的网络下，主叫用户设备为被叫用户设备订阅了彩振，并将该彩振设置为“在通话过程中继续为被叫用户设备播放”；被叫用户设备为主叫用户设备订阅了彩铃，并将该彩铃设置为“在通话过程中继续为主叫用户设备播放”。
如图2所示，本实施例可以包括：
步骤201，用户设备-A(User Equipment-A；以下简称：UE-A)发送呼叫请求(INVITE)消息。本实施例中，UE-A为主叫用户设备，UE-A发送的INVITE消息携带UE-A的会话(session)类型的SDP offer，该INVITE消息经过初始过滤规则(initial Filter Criteria；以下简称：iFC)触发后到达多媒体彩振应用服务器(Customized Ringing Signal Application Server；以下简称：CRS-AS)。
步骤202，CRS-AS根据该INVITE消息中的目标用户信息确定需要为UE-B播放彩振，然后转发该INVITE消息。该INVITE消息经过iFC触发后到达多媒体彩铃应用服务器(Customized Alerting Tone Application Server；以下简称：CAT-AS)。本实施例中，UE-B为被叫用户设备。
步骤203，CAT-AS根据该INVITE消息中的源用户信息确定需要为UE-A播放彩铃，然后转发该INVITE消息。
步骤204，UE-B接收到INVITE消息后，向UE-A返回180振铃(Ringing)消息，该180消息中携带了UE-B的session类型的SDP应答(SDP answer)。
步骤205，CAT-AS接收到180Ringing消息后，在该180Ringing消息中添加用于协商彩铃早期媒体的早期会话(early-session)类型的SDP offer，然后转发该180Ringing消息。
步骤206，CRS-AS接收到180Ringing消息之后，首先检查该180Ringing消息的消息体中是否包含early-session类型的SDP offer；具体地，CRS-AS可以检查该180Ringing消息中是否包含“Require：early-session”和“Content-disposition：early-session”这两个头域，如果包含，则CRS-AS可以确定该180Ringing消息的消息体中包含了early-session类型的SDP offer。然后，CRS-AS存储early-session类型的SDP offer的IP地址；具体地，CRS-AS可以缓存该SDP offer的IP地址，本实施例对具体的存储方式不作限定。
步骤207，CRS-AS将180Ringing消息转发给UE-A。
步骤208，UE-A针对180Ringing消息返回临时响应确认(ProvisionalResponse Acknowledgement；以下简称：PRACK)消息，该PRACK消息中携带UE-A的early-session类型的SDP answer，用于应答彩铃的早期会话。
步骤209，CRS-AS接收到PRACK消息后，在该PRACK消息中添加用于协商彩振早期媒体的early-session类型的SDP offer，然后转发添加后的PRACK消息。
步骤210，CAT-AS接收到PRACK消息后，提取该PRACK消息中UE-A的early-session类型的SDP answer，从而完成彩铃早期媒体协商，然后将仅携带用于协商彩振早期媒体的early-session类型的SDP offer的PRACK消息转发至UE-B。此时CAT-AS就可以为UE-A播放彩铃了。
步骤211，UE-B返回临时响应确认的成功处理消息，即200OK(PRACK)消息，该200OK(PRACK)消息中携带UE-B的early-session类型的SDPanswer，用于应答彩振的早期会话。
步骤212，CAT-AS接收到200OK(PRACK)消息后，不做任何处理，直接将该200OK(PRACK)消息转发至CRS-AS。
步骤213，CRS-AS接收到200OK(PRACK)消息后，提取该200OK(PRACK)消息中UE-B的early-session类型的SDP answer，从而完成彩振早期媒体协商，然后CRS-AS将空的200 OK(PRACK)消息转发给UE-A。此时CRS-AS就可以为UE-B播放彩振了。
步骤214，被叫用户设备UE-B听到振铃后摘机应答，UE-B发送200 OK(INVITE)摘机消息。
步骤215，CAT-AS收到200 OK(INVITE)消息后，由于需要执行彩铃继续播放的更新流程，因此先向UE-B返回ACK消息。
步骤216，CAT-AS紧接着向UE-B发送re-INVITE消息，该re-INVITE消息携带一个由CAT-AS的MRF实体生成的session类型的SDP offer，且该SDP offer的IP地址和端口号均指向CAT-AS的MRF实体，用于建立UE-B与CAT-AS的MRF实体之间的会话。
步骤217，UE-B向CAT-AS返回200OK(re-INVITE)消息，该200OK(re-INVITE)消息中携带UE-B的session类型的SDP answer，用于应答CAT-AS的MRF实体的会话，这时，CAT-AS的MRF实体与UE-B之间建立了媒体通道，从而取代了之前UE-A与UE-B之间协商的媒体通道。
步骤218，CAT-AS在向UE-B发送re-INVITE的同时，向UE-A发送UPDATE消息，该UPDATE消息携带一个由CAT-AS的MRF实体生成的session类型的SDP offer，且该SDP offer的IP地址和端口号均指向CAT-AS的MRF实体，用于建立UE-A与CAT-AS的MRF实体之间的会话。
步骤219，CRS-AS接收到UPDATE消息之后，需要检查该UPDATE消息中是否包含session类型的SDP offer，如果包含，则CRS-AS将该session类型的SDP offer的IP地址与之前缓存的early-session类型的SDP offer的IP地址进行对比，如果上述两个IP地址相同，则CRS-AS可以确定“个性化回铃音(Customized Alerting Tone；以下简称：CAT)会在通话过程中继续播放”，即确定了彩铃继续播放(CAT continue)功能的存在。
本实施例中，CRS-AS在确定CAT continue功能存在之后，还需进一步判断该UPDATE消息中SDP offer的视频(video)行的方向属性是否为“sendrecv”：
(1)如果SDP offer的视频行的方向属性是“sendrecv”，则说明主叫用户设备与被叫用户设备之间的通话是视频通话，CRS-AS会请求该CRS-AS的MRF实体预留可以实现音频(audio)混音和视频混频的资源，以便在通话过程中能够为UE-B播放音频+视频类型的彩振；
(2)如果SDP offer的视频行的方向属性不是“sendrecv”，而是“仅发送(sendonly)”或“非激活状态(inactive)”，或者该SDP offer中没有video行，则CRS-AS只需请求该CRS-AS的MRF实体预留可以实现音频混音的资源即可，从而在通话过程中能够为UE-B播放音频类型的彩振。
步骤220，CRS-AS将接收到的UPDATE消息中的SDP offer进行修改，即将该UPDATE中的IP地址和端口号均修改为该CRS-AS的MRF实体的IP地址和端口号，然后将修改后的UPDATE消息发送给UE-A，目的是建立UE-A与CRS-AS的MRF之间的会话。
步骤221，UE-A返回200 OK(UPDATE)消息，该200 OK(UPDATE)消息中携带UE-A的session类型的SDP answer。
步骤222，CRS-AS接收到200OK(UPDATE)消息后，从该200OK(UPDATE)中提取出SDP answer，从而完成与UE-A之间的会话协商，即建立了UE-A与CRS-AS的MRF实体之间的媒体通道。然后CRS-AS将UE-A的SDP answer中的IP地址和端口号均修改为该CRS-AS的MRF实体的IP地址和端口号之后，将修改后的SDP answer插入到200OK(UPDATE)消息中，然后将该200OK(UPDATE)转发给CAT-AS，目的是建立CRS-AS的MRF实体与CAT-AS的MRF实体之间的会话。
步骤223，CAT-AS接收到200OK(UPDATE)消息后，完成了用于CATcontinue功能的会话更新。这时，CRS-AS的MRF实体与CAT-AS的MRF实体之间建立了媒体通道，但CAT-AS对此是不感知的。然后CAT-AS向UE-A返回200OK(INVITE)消息。
步骤224，CRS-AS将200OK(INVITE)消息转发给UE-A。
步骤225，UE-A返回ACK消息。
步骤226，CRS-AS将ACK消息转发给CAT-AS。
步骤227，CAT-AS将ACK消息转发给UE-B。
步骤228，CAT-AS指示该CAT-AS的MRF实体在接收到UE-B发送的媒体流时进行混音处理，即将彩铃媒体流与UE-B发送的媒体流混合为一路媒体流之后转发给UE-A；并将来自CRS-AS的媒体流直接转发至UE-B。
步骤229，CRS-AS指示该CRS-AS的MRF实体在接收到UE-A发送的媒体流时进行混音处理，即将彩振媒体流与UE-A发送的媒体流混合为一路媒体流之后转发给UE-B；并将来自CAT-AS的媒体流直接转发至UE-A。
本实施例步骤219中，CRS-AS判断“CAT continue功能”是否存在时，使用的IP地址对比方法是专门针对early-session模式的彩铃的，而对于使用分支(forking)模式的彩铃，CRS-AS判断“CAT continue功能”是否存在的方法稍有不同，具体为：
如果彩铃使用forking模式，CRS-AS应对携带“P-early-media：sendrecv”或“P-early-media：sendonly”的18X消息中SDP的IP地址进行缓存；然后，当接收到的UPDATE消息的对话标识(Dialog Identifier；以下简称：Dialog-ID)与该18X消息的Dialog-ID不同时，CRS-AS检查该UPDATE中SDP的IP地址，如果该SDP的IP地址与之前缓存的IP地址相同，则CRS-AS可以确定“CAT continue功能”存在。
对于CRS-AS判断“CAT continue功能”是否存在的方法，本实施例中是通过CRS-AS主动对比IP地址来实现的，当然本实施例并不仅限于此，CRS-AS还可采用下面介绍的方法判断“CAT continue功能”是否存在，该方法可同时适用于early-session模式和forking模式的彩铃。具体地：CAT-AS可以主动在任何临时响应消息(例如：步骤205的180消息)、响应消息(例如：步骤212的200OK(PRACK)消息)、或者在步骤218的UPDATE消息中携带彩铃继续播放(CAT continue)标识，以明确告知CRS-AS：“彩铃会在通话过程中继续播放”，从而CRS-AS无需对比IP地址，可以根据接收到的临时响应消息、响应消息或更新消息所携带的彩铃继续播放标识，确定在通话过程中继续播放彩铃。
对于CAT Continue标识的携带方法，可以为：在临时响应消息、响应消息或更新消息的contact头域或accept-contact头域中携带“+g.3gpp.crs.continue”，以表明彩铃会在通话过程中继续播放；当然，本发明实施例并不仅限于此，也可以采用其他方式在临时响应消息、响应消息或更新消息中携带CAT Continue标识，本发明实施例对CAT Continue标识的携带方式不作限定。
上述实施例中，CRS-AS可以识别出彩铃会在通话过程中继续播放，然后CRS-AS代替UE-A与CAT-AS建立媒体通道，通话过程中CRS-AS将来自CAT-AS的媒体流直接转发至UE-A，并将UE-A发送的媒体流与彩振媒体流混合为一路媒体流后转发至UE-B，从而实现了在通话过程中继续播放彩铃和彩振，并且减少了交互的信令数，缩短了在通话过程中继续播放彩铃和彩振时的时间延迟，提高了用户体验度；另外，CAT-AS无需感知CRS-AS的存在，而且当CRS-AS使用对比IP地址的方法判断“CAT continue功能”是否存在时，无需对现有的信令或字段进行扩展；并且，本实施例对CAT-AS没有任何改动。
图3为本发明通话过程中继续播放彩铃和彩振的方法再一个实施例的流程图，如图3所示，该实施例可以包括：
步骤301，第二服务器接收第一服务器在通话过程中继续播放的铃音标识。该铃音标识是第一服务器根据第二服务器发送的临时响应消息携带的继续播放标识，确定第二服务器已触发在通话过程中的继续播放功能，并抑制第一服务器在通话过程中的继续播放功能的触发之后发送的。
本实施例中，第一服务器为彩振服务器时，第二服务器为彩铃服务器；或者，第一服务器为彩铃服务器时，第二服务器为彩振服务器。
步骤302，第二服务器根据上述铃音标识请求该第二服务器的媒体资源功能实体预留与该铃音标识对应的播放资源和混音资源。
步骤303，第二服务器在该第二服务器的媒体资源功能实体与被叫用户设备之间建立媒体通道，并在该第二服务器的媒体资源功能实体与主叫用户设备之间建立媒体通道。
其中，在第二服务器的媒体资源功能实体与被叫用户设备之间建立媒体通道可以为：第二服务器向被叫用户设备发送重邀请消息，该重邀请消息包括会话类型的会话描述协议请求，该会话描述协议请求由第二服务器的媒体资源功能实体生成，该会话描述协议请求的IP地址和端口号均指向第二服务器的媒体资源功能实体；然后，第二服务器接收被叫用户设备返回的响应消息，该响应消息携带被叫用户设备的会话类型的会话描述协议应答。
优选地，当第一服务器在通话过程中继续播放的铃音的媒体类型为视频类型，且主叫用户设备与被叫用户设备之间的通话媒体类型不包括视频类型时，第二服务器需要在重邀请消息的会话描述协议请求中携带视频行，并将该视频行的方向属性设置为仅发送；或者，
当第一服务器在通话过程中继续播放的铃音的媒体类型为视频类型，且主叫用户设备与被叫用户设备之间的通话媒体类型包括视频类型时，第二服务器在重邀请消息的会话描述协议请求中携带视频行，并将该视频行的方向属性设置为发送接收。
步骤304，第二服务器指示该第二服务器的媒体资源功能实体在通话过程中进行混音处理。
具体地，第二服务器可以指示该第二服务器的媒体资源功能实体在通话过程中将被叫用户设备发送的媒体流与彩铃媒体流混合为一路媒体流后转发至主叫用户设备；并将主叫用户设备发送的媒体流与彩振媒体流混合为一路媒体流后转发至被叫用户设备。
上述实施例中，第一服务器识别出第二服务器继续播放功能的存在之后，将要在通话过程中继续播放的铃音标识发送给第二服务器，然后由第二服务器在通话过程中既为主叫用户设备播放彩铃，又为被叫用户设备播放彩振，缩短了在通话过程中继续播放彩铃和彩振时的时间延迟，提高了用户体验度。
图4为本发明通话过程中继续播放彩铃和彩振的方法又一个实施例的流程图，本实施例中，第一服务器为CRS-AS，第二服务器为CAT-AS；本实施例的应用场景为：主叫用户设备与被叫用户设备位于同一网络，例如：同一运营商的网络中，或者主叫用户设备与被叫用户设备位于不同的网络，例如：不同运营商的网络中，但CAT-AS与CRS-AS使用相同的铃音标识寻址到的铃音文件是相同的，即CAT-AS与CRS-AS所使用的铃音由同一个铃音存储服务器或是多个镜像铃音存储服务器提供，但本实施例对CAT-AS与CRS-AS所使用铃音的来源不作限定，只要保证CAT-AS与CRS-AS使用相同的铃音标识寻址到的铃音文件是相同的即可。
本实施例中，主叫用户设备为被叫用户设备订阅了彩振，并将该彩振设置为“在通话过程中继续为被叫用户设备播放”；被叫用户设备为主叫用户设备订阅了彩铃，并将该彩铃设置为“在通话过程中继续为主叫用户设备播放”。
如图4所示，本实施例可以包括：
步骤401，UE-A发送INVITE消息。本实施例中，UE-A为主叫用户设备，UE-A发送的INVITE消息携带UE-A的session类型的SDP offer，该INVITE消息经过iFC触发后到达CRS-AS。
步骤402，CRS-AS根据该INVITE消息中的目标用户信息确定需要为UE-B播放彩振，然后转发该INVITE消息。该INVITE消息经过iFC触发后到达CAT-AS。本实施例中，UE-B为被叫用户设备。
步骤403，CAT-AS根据该INVITE消息中的源用户信息确定需要为UE-A播放彩铃，然后转发该INVITE消息。
步骤404，UE-B接收到INVITE消息后，向UE-A返回180(Ringing)消息，该180消息中携带了UE-B的session类型的SDP answer。
步骤405，CAT-AS接收到180消息后，在该180消息中添加用于协商彩铃早期媒体的early-session类型的SDP offer，并在该180消息的头域中携带彩铃继续播放(CAT continue)标识，例如：“+g.3gpp.crs.continue”，以表明彩铃会在通话过程中继续为主叫用户设备播放，然后转发设置后的180消息。
步骤406，CRS-AS接收到180消息后，根据该180消息的头域中的CATcontinue标识，确定彩铃会在通话过程中继续为主叫用户设备播放，从而开始准备后续的流程，并将该180消息转发给UE-A。
步骤407，UE-A针对180消息返回PRACK消息，该PRACK消息携带UE-A的early-session类型的SDP answer，用于应答彩铃的早期会话。
步骤408，CRS-AS接收到PRACK消息后，在该PRACK消息中添加用于协商彩振早期媒体的early-session类型的SDP offer，然后转发添加后的PRACK消息。
步骤409，CAT-AS接收到PRACK消息后，提取该PRACK消息中UE-A的early-session类型的SDP answer，从而完成彩铃早期媒体协商，然后将仅携带用于协商彩振早期媒体的early-session类型的SDP offer的PRACK消息转发至UE-B。此时CAT-AS就可以为UE-A播放彩铃了。
步骤410，UE-B返回200OK(PRACK)消息，该200OK(PRACK)消息中携带了UE-B的early-session类型的SDP answer，用于应答彩振的早期会话。
步骤411，CAT-AS接收到200OK(PRACK)消息后，不做任何处理，直接将该200OK(PRACK)消息转发至CRS-AS。
步骤412，CRS-AS接收到200OK(PRACK)消息后，提取该200OK(PRACK)消息中UE-B的early-session类型的SDP answer，从而完成彩振早期媒体协商，然后CRS-AS将空的200OK(PRACK)消息转发给UE-A。此时CRS-AS就可以为UE-B播放彩振了。
步骤413，CRS-AS根据步骤405中接收到的180消息携带的CAT continue标识，抑制彩振继续播放(CRS continue)的正常更新流程的触发。
步骤414，CRS-AS向CAT-AS发送信息(INFO)消息，该INFO消息携带彩振铃音的标识，并指示CAT-AS代替CRS-AS在通话过程中继续播放彩振。
步骤415，CAT-AS向CRS-AS返回200OK(INFO)消息，表示同意CRS-AS的请求。
步骤416，CAT-AS将彩振铃音的标识发送至CAT-AS的MRF实体，并请求CAT-AS的MRF实体预留与该标识对应的播放资源和混音资源。
本实施例中，步骤413～步骤416也可以在步骤405之后就开始执行，即可以先执行步骤413～步骤416，再执行步骤406～步骤412；或者，并行执行步骤413～步骤416与步骤406～步骤412。
步骤417，被叫用户设备UE-B听到振铃后摘机应答，UE-B发送200OK(INVITE)摘机消息。
步骤418，CAT-AS收到200OK(INVITE)消息后，由于需要执行彩铃继续播放的更新流程，因此先向UE-B返回ACK消息。
步骤419，CAT-AS紧接着向UE-B发送re-INVITE消息，该re-INVITE消息中携带一个由CAT-AS的MRF实体生成的session类型的SDP offer，且该SDP offer的IP地址和端口号均指向CAT-AS的MRF实体，用于建立UE-B与CAT-AS的MRF实体之间的会话。
如果彩振铃音的媒体类型为视频类型，那么CAT-AS还应做如下进一步的判断和处理：
(1)如果主被叫之间的通话媒体类型不包括视频，那么CAT-AS应当在re-INVITE的SDP offer中携带视频行，并将视频行的方向属性置为“sendonly”。
(2)如果主被叫之间的通话媒体类型也包括视频，那么CAT-AS应当在re-INVITE的SDP offer中携带视频行，并将视频行的方向属性置为“sendrecv”。
步骤420，UE-B向CAT-AS返回200OK(re-INVITE)消息，该200OK(re-INVITE)消息中携带了UE-B的session类型的SDP answer，用于应答CAT-AS的MRF实体的会话，这时，CAT-AS的MRF实体与UE-B之间建立了媒体通道，从而取代了之前UE-A与UE-B之间协商的媒体通道。
步骤421，CAT-AS在向UE-B发送re-INVITE的同时，向UE-A发送UPDATE消息，该UPDATE消息携带了一个由彩铃的MRF生成的session类型的SDP offer，且该SDP offer的IP地址和端口号均指向CAT-AS的MRF实体，用于建立UE-A与CAT-AS的MRF实体之间的会话。
步骤422，CRS-AS将接收到的UPDATE消息转发给UE-A。
步骤423，UE-A返回200OK(UPDATE)消息，该200OK(UPDATE)消息中携带了UE-A的session类型的SDP answer。
步骤424，CRS-AS接收到200OK(UPDATE)消息后，将该200OK(UPDATE)消息转发给CAT-AS。
步骤425，CAT-AS接收到200OK(UPDATE)消息后，完成了用于CATcontinue功能的会话更新，建立了UE-A与CAT-AS的MRF实体之间的媒体通道。然后CAT-AS返回200OK(INVITE)消息。
步骤426，CRS-AS将200OK(INVITE)消息转发给UE-A。
步骤427，UE-A返回ACK消息。
步骤428，CRS-AS将ACK消息转发给CAT-AS。
步骤429，CAT-AS将ACK消息转发给UE-B。
步骤430，CAT-AS指示CAT-AS的MRF实体进行混音处理，即在接收到UE-B发送的媒体流时，将彩铃媒体流与UE-B发送的媒体流混合为一路媒体流后转发给UE-A，同时在接收到UE-A发来的媒体流时，将彩振媒体流与UE-A发送的媒体流混合为一路媒体流后转发给UE-B。
本实施例中，CAT-AS向CRS-AS告知CAT continue功能的存在，然后CRS-AS将彩振铃音的标识发送给CAT-AS，由CAT-AS来指示该CAT-AS的MRF实体在通话过程中继续播放彩铃和彩振。
当然本发明实施例并不仅限于此，也可以由CRS-AS向CAT-AS告知CRScontinue功能的存在，然后CAT-AS将彩铃铃音的标识发送给CRS-AS，由CRS-AS来指示该CRS-AS的MRF实体在通话过程中继续播放彩铃和彩振；具体的实施过程与本发明图4所示实施例类似，在此不再赘述。
上述实施例中，CRS-AS识别出彩铃会在通话过程中继续播放，并将要在通话中继续播放的彩振铃音的标识发送给CAT-AS。这时，由于CAT-AS在被叫用户设备摘机之前就已经知道了需要在通话过程中继续播放的彩振铃音，因此后续CAT-AS在与被叫用户设备进行会话更新时，可以建立最合适的媒体通道，从而不论是音频类型的彩振铃音，还是视频类型的彩振铃音，CAT-AS都可以正常播放，实现了在通话过程中既为主叫用户设备播放彩铃，又为被叫用户设备播放彩振，并且减少了交互的信令数，缩短了在通话过程中继续播放彩铃和彩振时的时间延迟，提高了用户体验度。
本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
图5为本发明彩振服务器一个实施例的结构示意图，本实施例中的彩振服务器可以实现本发明图1所示实施例的流程。如图5所示，该彩振服务器可以包括：确定模块51、第一修改模块52、第一发送模块53、接收模块54、第二修改模块55、第二发送模块56和指示模块57。
其中，确定模块51，用于根据接收到的临时响应消息和更新消息确定在通话过程中继续播放彩铃；
第一修改模块52，用于在确定模块51确定在通话过程中继续播放彩铃之后，将上述更新消息中会话描述协议请求的IP地址和端口号修改为彩振服务器的媒体资源功能实体的IP地址和端口号。
第一发送模块53，用于将第一修改模块52修改后的更新消息发送至主叫用户设备。
接收模块54，用于接收主叫用户设备发送的针对修改后的更新消息的响应消息。
第二修改模块55，用于将接收模块54接收的响应消息中会话描述协议应答的因特网协议地址和端口号修改为彩振服务器的媒体资源功能实体的IP地址和端口号。
第二发送模块56，用于将第二修改模块55修改后的响应消息发送至彩铃服务器；本实施例中，第二发送模块56将第二修改模块55修改后的响应消息发送至彩铃服务器之后，彩振服务器与彩铃服务器之间建立了媒体通道。在通话过程中，彩铃服务器可以指示该彩铃服务器的媒体资源功能实体将被叫用户设备发送的媒体流与彩铃媒体流混合为一路媒体流后转发至主叫用户设备；并将来自彩振服务器的媒体流直接转发至被叫用户设备。
指示模块57，用于指示彩振服务器的媒体资源功能实体在通话过程中进行混音处理；具体地，指示模块57可以指示彩振服务器的媒体资源功能实体在通话过程中将主叫用户设备发送的媒体流与彩振媒体流混合为一路媒体流后转发至被叫用户设备；并将来自彩铃服务器的媒体流直接转发至主叫用户设备。
另外，当彩铃的模式包括早期会话模式或分支模式时，确定模块51还可以根据接收到的临时响应消息、响应消息或更新消息携带的彩铃继续播放标识，确定在通话过程中继续播放彩铃。
上述彩振服务器可以识别出彩铃会在通话过程中继续播放，然后彩振服务器代替主叫用户设备与彩铃服务器建立媒体通道，通话过程中彩振服务器将来自彩铃服务器的媒体流直接转发至主叫用户设备，并将主叫用户设备发送的媒体流与彩振媒体流混合为一路媒体流后转发至被叫用户设备，从而实现了在通话过程中继续播放彩铃和彩振，并减少了交互的信令数，缩短了在通话过程中继续播放彩铃和彩振时的时间延迟，提高了用户体验度。
图6为本发明彩振服务器另一个实施例的结构示意图，本实施例中的彩振服务器可以实现本发明图1或图2所示实施例的流程。如图6所示，该彩振服务器可以包括：确定模块61、第一修改模块62、第一发送模块63、接收模块64、第二修改模块65、第二发送模块66、指示模块67和请求模块68。
其中，确定模块61，用于根据接收到的临时响应消息和更新消息确定在通话过程中继续播放彩铃；另外，当彩铃的模式包括早期会话模式或分支模式时，确定模块61还可以根据接收到的临时响应消息、响应消息或更新消息携带的彩铃继续播放标识，确定在通话过程中继续播放彩铃。
在本实施例的一种实现方式中，确定模块61可以包括：第一存储子模块611和第一确定子模块612；其中，第一存储子模块611，用于在彩铃的模式包括早期会话模式时，存储接收到的临时响应消息中早期会话类型的会话描述协议请求的IP地址；第一确定子模块612，用于当接收到的更新消息中包括会话类型的会话描述协议请求时，如果该会话类型的会话描述协议请求的IP地址与第一存储子模块611存储的IP地址相同，则确定在通话过程中继续播放彩铃。
在本实施例的另一种实现方式中，确定模块61可以包括：第二存储子模块613和第二确定子模块614；其中，第二存储子模块613，用于在彩铃的模式包括分支模式时，存储接收到的临时响应消息中会话描述协议的IP地址，该临时响应消息包括早期媒体授权头域，该早期媒体授权头域的内容为发送接收或仅发送；第二确定子模块614，用于当接收到的更新消息的对话标识与临时响应消息的对话标识不同时，如果更新消息中会话描述协议的IP地址与第二存储子模块613存储的因特网协议地址相同，则确定在通话过程中继续播放彩铃。
第一修改模块62，用于在确定模块61确定在通话过程中继续播放彩铃之后，将接收到的更新消息中会话描述协议请求的IP地址和端口号修改为彩振服务器的媒体资源功能实体的IP地址和端口号。
第一发送模块63，用于将第一修改模块62修改后的更新消息发送至主叫用户设备。
接收模块64，用于接收主叫用户设备发送的针对修改后的更新消息的响应消息。
第二修改模块65，用于将接收模块64接收的响应消息中会话描述协议应答的因特网协议地址和端口号修改为彩振服务器的媒体资源功能实体的IP地址和端口号。
第二发送模块66，用于将第二修改模块65修改后的响应消息发送至彩铃服务器；本实施例中，第二发送模块66将第二修改模块65修改后的响应消息发送至彩铃服务器之后，彩振服务器与彩铃服务器之间建立了媒体通道。在通话过程中，彩铃服务器可以指示该彩铃服务器的媒体资源功能实体将被叫用户设备发送的媒体流与彩铃媒体流混合为一路媒体流后转发至主叫用户设备；并将来自彩振服务器的媒体流直接转发至被叫用户设备。
指示模块67，用于指示彩振服务器的媒体资源功能实体在通话过程中进行混音处理；具体地，指示模块67可以指示彩振服务器的媒体资源功能实体在通话过程中将主叫用户设备发送的媒体流与彩振媒体流混合为一路媒体流后转发至被叫用户设备；并将来自彩铃服务器的媒体流直接转发至主叫用户设备。
请求模块68，用于在确定模块61确定在通话过程中继续播放彩铃之后，当接收到的更新消息中会话描述协议请求的视频行的方向属性为发送接收时，请求彩振服务器的媒体资源功能实体预留用于实现音频混音和视频混频的资源；或者，当接收到的更新消息中会话描述请求的视频行的方向属性不是发送接收，或者该会话描述请求没有视频行时，请求彩振服务器的媒体资源功能实体预留用于实现音频混音的资源。
上述彩振服务器可以识别出彩铃会在通话过程中继续播放，然后彩振服务器代替主叫用户设备与彩铃服务器建立媒体通道，通话过程中彩振服务器将来自彩铃服务器的媒体流直接转发至主叫用户设备，并将主叫用户设备发送的媒体流与彩振媒体流混合为一路媒体流后转发至被叫用户设备，从而实现了在通话过程中继续播放彩铃和彩振，并减少了交互的信令数，缩短了在通话过程中继续播放彩铃和彩振时的时间延迟，提高了用户体验度。
图7为本发明第二服务器一个实施例的结构示意图，本实施例的第二服务器可以实现本发明图3所示实施例的流程图。如图7所示，该第二服务器可以包括：标识接收模块71、资源预留模块72、通道建立模块73和混音指示模块74。
其中，标识接收模块71，用于接收第一服务器在通话过程中继续播放的铃音标识；该铃音标识是第一服务器根据第二服务器发送的临时响应消息携带的继续播放标识，确定第二服务器已触发在通话过程中的继续播放功能，并抑制第一服务器在通话过程中的继续播放功能的触发之后发送的；
资源预留模块72，用于根据标识接收模块71接收的铃音标识请求第二服务器的媒体资源功能实体预留与该铃音标识对应的播放资源和混音资源；
通道建立模块73，用于在第二服务器的媒体资源功能实体与被叫用户设备之间建立媒体通道，并在第二服务器的媒体资源功能实体与主叫用户设备之间建立媒体通道；
混音指示模块74，用于指示第二服务器的媒体资源功能实体在通话过程中进行混音处理；具体地，混音指示模块74可以指示第二服务器的媒体资源功能实体在通话过程中将被叫用户设备发送的媒体流与彩铃媒体流混合为一路媒体流后转发至主叫用户设备；并将主叫用户设备发送的媒体流与彩振媒体流混合为一路媒体流后转发至被叫用户设备。
本实施例中，第一服务器为彩振服务器时，第二服务器为彩铃服务器；或者，第一服务器为彩铃服务器时，第二服务器为彩振服务器。
上述第二服务器可以接收第一服务器在通话过程中继续播放的铃音标识，然后由第二服务器在通话过程中既为主叫用户设备播放彩铃，又为被叫用户设备播放彩振，缩短了在通话过程中继续播放彩铃和彩振时的时间延迟，提高了用户体验度。
图8为本发明第二服务器另一个实施例的结构示意图，本实施例的第二服务器可以实现本发明图3或图4所示实施例的流程图。如图8所示，该第二服务器可以包括：标识接收模块81、资源预留模块82、通道建立模块83和混音指示模块84。
其中，标识接收模块81，用于接收第一服务器在通话过程中继续播放的铃音标识；该铃音标识是第一服务器根据第二服务器发送的临时响应消息携带的继续播放标识，确定第二服务器已触发在通话过程中的继续播放功能，并抑制第一服务器在通话过程中的继续播放功能的触发之后发送的；
资源预留模块82，用于根据标识接收模块81接收的铃音标识请求第二服务器的媒体资源功能实体预留与该铃音标识对应的播放资源和混音资源；
通道建立模块83，用于在第二服务器的媒体资源功能实体与被叫用户设备之间建立媒体通道，并在第二服务器的媒体资源功能实体与主叫用户设备之间建立媒体通道；
混音指示模块84，用于指示第二服务器的媒体资源功能实体在通话过程中进行混音处理；具体地，混音指示模块84可以指示第二服务器的媒体资源功能实体在通话过程中将被叫用户设备发送的媒体流与彩铃媒体流混合为一路媒体流后转发至主叫用户设备；并将主叫用户设备发送的媒体流与彩振媒体流混合为一路媒体流后转发至被叫用户设备。
具体地，通道建立模块83可以包括：消息发送子模块831和消息接收子模块832；其中，消息发送子模块831，用于向被叫用户设备发送重邀请消息，该重邀请消息包括会话类型的会话描述协议请求，该会话描述协议请求由第二服务器的媒体资源功能实体生成，该会话描述协议请求的IP地址和端口号均指向第二服务器的媒体资源功能实体；消息接收子模块832，用于接收被叫用户设备返回的响应消息，该响应消息携带被叫用户设备的会话类型的会话描述协议应答。
本实施例中，通道建立模块83还可以包括：携带子模块833，用于当第一服务器在通话过程中继续播放的铃音的媒体类型为视频类型，且主叫用户设备与被叫用户设备之间的通话媒体类型不包括视频类型时，在重邀请消息的会话描述协议请求中携带视频行，该视频行的方向属性为仅发送；或者，当第一服务器在通话过程中继续播放的铃音的媒体类型为视频类型，且主叫用户设备与被叫用户设备之间的通话媒体类型包括视频类型时，在重邀请消息的会话描述协议请求中携带视频行，该视频行的方向属性为发送接收。然后，再由消息发送子模块831将该重邀请消息发送至被叫用户设备。
本实施例中，第一服务器为彩振服务器时，第二服务器为彩铃服务器；或者，第一服务器为彩铃服务器时，第二服务器为彩振服务器。
上述第二服务器可以接收第一服务器在通话过程中继续播放的铃音标识，然后由第二服务器在通话过程中既为主叫用户设备播放彩铃，又为被叫用户设备播放彩振，缩短了在通话过程中继续播放彩铃和彩振时的时间延迟，提高了用户体验度。
图9为本发明通话过程中继续播放彩铃和彩振的系统一个实施例的结构示意图，如图9所示，该系统可以包括：彩铃服务器91和彩振服务器92。
在本发明实施例的一种实现方式中，彩振服务器92可以根据接收到的临时响应消息、响应消息或更新消息确定在通话过程中继续播放彩铃，或者，根据接收到的临时响应消息和更新消息确定在通话过程中继续播放彩铃之后，将接收到的更新消息中会话描述协议请求的因特网协议地址和端口号修改为彩振服务器92的媒体资源功能实体的IP地址和端口号，并将修改后的更新消息发送至主叫用户设备；然后，接收主叫用户设备发送的响应消息，将该响应消息中会话描述协议应答的IP地址和端口号修改为彩振服务器92的媒体资源功能实体的IP地址和端口号，并将修改后的响应消息发送至彩铃服务器91；并指示彩振服务器92的媒体资源功能实体在通话过程中将主叫用户设备发送的媒体流与彩振媒体流混合为一路媒体流后转发至被叫用户设备。具体地，该彩振服务器92可以由本发明图5或图6所示的彩振服务器实现。
在本发明实施例的另一种实现方式中，彩振服务器92接收彩铃服务器91在通话过程中继续播放的铃音标识，该铃音标识是彩铃服务器91根据彩振服务器92发送的临时响应消息携带的继续播放标识，确定彩振服务器92已触发在通话过程中的继续播放功能，并抑制彩铃服务器91在通话过程中的继续播放功能的触发之后发送的；然后，彩振服务器92根据该铃音标识请求彩振服务器92的媒体资源功能实体预留与该铃音标识对应的播放资源和混音资源；在彩振服务器92的媒体资源功能实体与被叫用户设备之间建立媒体通道，并在彩振服务器92的媒体资源功能实体与主叫用户设备之间建立媒体通道；指示彩振服务器92的媒体资源功能实体在通话过程中将被叫用户设备发送的媒体流与彩铃媒体流混合为一路媒体流后转发至主叫用户设备；并将主叫用户设备发送的媒体流与彩振媒体流混合为一路媒体流后转发至被叫用户设备。具体地，在该实现方式中，彩振服务器92可以由本发明图7或图8所示的第二服务器实现。
在本发明实施例的再一种实现方式中，彩铃服务器91接收彩振服务器92在通话过程中继续播放的铃音标识，该铃音标识是彩振服务器92根据彩铃服务器91发送的临时响应消息携带的继续播放标识，确定彩铃服务器91已触发在通话过程中的继续播放功能，并抑制彩振服务器92在通话过程中的继续播放功能的触发之后发送的；然后，彩铃服务器91根据该铃音标识请求彩铃服务器91的媒体资源功能实体预留与该铃音标识对应的播放资源和混音资源；在彩铃服务器91的媒体资源功能实体与被叫用户设备之间建立媒体通道，并在彩铃服务器91的媒体资源功能实体与主叫用户设备之间建立媒体通道；指示彩铃服务器91的媒体资源功能实体在通话过程中将被叫用户设备发送的媒体流与彩铃媒体流混合为一路媒体流后转发至主叫用户设备；并将主叫用户设备发送的媒体流与彩振媒体流混合为一路媒体流后转发至被叫用户设备。具体地，在该实现方式中，彩铃服务器91可以由本发明图7或图8所示实施例的第二服务器实现。
在具体实现时，图9所示的通话过程中继续播放彩铃和彩振的系统还可以进一步包括：UE、无线网络控制器(Radio Network Controller；以下简称：RNC)和服务通用分组无线业务支持节点(Serving General Packet RadioService Support Node；以下简称：SGSN)等设备，如图10所示。图10为本发明通话过程中继续播放彩铃和彩振的系统另一个实施例的结构示意图，该系统可以包括：UE 1001、基站(NodeB)1002、RNC 1003、SGSN 1004、代理呼叫会话控制功能(Proxy Call Session Control Function；以下简称：P-CSCF)实体1005、服务呼叫会话控制功能(Serving Call Session ControlFunction；以下简称：S-CSCF)实体1006、归属用户服务器(Home SubscriberServer；以下简称：HSS)1007、CAT-AS 1008和CRS-AS 1009。
本实施例中，UE 1001包括UE-A和UE-B；其中，UE-A为主叫用户设备，UE-B为被叫用户设备。
NodeB 1002为宽带码分多址(Wideband Code Division Multiple Access；以下简称：WCDMA)系统的基站，主要完成Uu接口物理层协议的处理。
RNC 1003，用于控制全球陆上无线接入(Universal Terrestrial Radio AccessNetwork；以下简称：UTRAN)的无线资源。
SGSN 1004是WCDMA核心网分组交换(Packet Switching；以下简称：PS)域功能节点，主要提供PS域的路由转发、移动性管理、会话管理、鉴权和加密等功能。
P-CSCF实体1005是IP多媒体子系统(IP Multimedia Subsystem；以下简称：IMS)网络中UE 1001的第一个接触点，主要用于验证请求，处理和转发响应。
S-CSCF实体1006在IMS网络中处于核心控制地位，是IMS多进程控制的关键所在。S-CSCF实体1006用于记录并控制UE 1001的进程状态，执行会话路由功能，并不断与应用服务和计费功能进行交互，根据规则进行增值业务触发与业务控制。
HSS 1007，用于存储UE 1001与服务相关的数据，是一个升级的归属位置寄存器(Home Location Register；以下简称：HLR)。HSS 1007以扩展标记语言(Extensible Markup Language；以下简称：XML)形式记录了用户身份、注册信息、接入参数和服务触发信息等；本实施例中，HSS 1007包括HSS-A和HSS-B，其中HSS-A为源网络的HSS，HSS-B为目标网络的HSS。
CAT-AS 1008主要用于提供CAT业务逻辑，并控制CAT-AS 1008的MRF实体进行媒体资源的播放。
CRS-AS 1009主要用于提供CRS业务逻辑，并控制CRS-AS 1009的MRF实体进行媒体资源的播放。
上述CAT-AS 1008的MRF实体和CRS-AS 1009的MRF实体包括控制部分和用户平面的处理部分，对与承载相关的业务提供支持，例如：多媒体资源播放、视频会议和用户公告等，能够完成数据媒体流的混合、媒体流的分发、承载代码的转换和计费信息的发送等功能。
本实施例中，CAT-AS 1008与CRS-AS 1009之间的交互过程同本发明图9所示实施例的描述，在此不再赘述。
上述系统中，彩铃服务器可以识别出彩振会在通话过程中继续播放，或者，彩振服务器可以识别出彩铃会在通话过程中继续播放，然后彩铃服务器或彩振服务器再执行更新流程，实现在通话过程中继续播放彩铃和彩振，并缩短了在通话过程中继续播放彩铃和彩振时的时间延迟，提高了用户体验度。
本领域技术人员可以理解附图只是一个优选实施例的示意图，附图中的模块或流程并不一定是实施本发明所必须的。
本领域技术人员可以理解实施例中的装置中的模块可以按照实施例描述进行分布于实施例的装置中，也可以进行相应变化位于不同于本实施例的一个或多个装置中。上述实施例的模块可以合并为一个模块，也可以进一步拆分成多个子模块。
最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。
Claims (15)
1.一种通话过程中继续播放彩铃和彩振的方法，其特征在于，包括：
根据接收到的临时响应消息和更新消息确定在通话过程中继续播放彩铃，将所述更新消息中会话描述协议请求的因特网协议地址和端口号修改为彩振服务器的媒体资源功能实体的因特网协议地址和端口号，并将修改后的所述更新消息发送至主叫用户设备；
接收所述主叫用户设备发送的针对所述修改后的所述更新消息的响应消息，将所述响应消息中会话描述协议应答的因特网协议地址和端口号修改为所述彩振服务器的媒体资源功能实体的因特网协议地址和端口号，并将修改后的所述响应消息发送至彩铃服务器；
指示所述彩振服务器的媒体资源功能实体在通话过程中进行混音处理。
2.根据权利要求1所述的方法，其特征在于，所述彩铃的模式包括早期会话模式或分支模式；
所述彩铃的模式为所述早期会话模式时，
所述根据接收到的临时响应消息和更新消息确定在通话过程中继续播放彩铃包括：
存储接收到的所述临时响应消息中早期会话类型的会话描述协议请求的因特网协议地址；
当接收到的所述更新消息中包括会话类型的会话描述协议请求时，如果所述会话类型的会话描述协议请求的因特网协议地址与存储的因特网协议地址相同，则确定在通话过程中继续播放彩铃；或者，
所述彩铃的模式为所述分支模式时，
所述根据接收到的临时响应消息和更新消息确定在通话过程中继续播放彩铃包括：
存储接收到的所述临时响应消息中会话描述协议的因特网协议地址，所述临时响应消息包括早期媒体授权头域，所述早期媒体授权头域的内容为发送接收或仅发送；
当接收到的所述更新消息的对话标识与所述临时响应消息的对话标识不同时，如果所述更新消息中会话描述协议的因特网协议地址与存储的因特网协议地址相同，则确定在通话过程中继续播放彩铃。
3.根据权利要求1或2所述的方法，其特征在于，所述方法还包括：
确定在通话过程中继续播放彩铃之后，当接收到的所述更新消息中会话描述协议请求的视频行的方向属性为发送接收时，请求所述彩振服务器的媒体资源功能实体预留用于实现音频混音和视频混频的资源；或者，
当接收到的所述更新消息中会话描述请求的视频行的方向属性不是发送接收，或者所述更新信息中会话描述请求没有视频行时，请求所述彩振服务器的媒体资源功能实体预留用于实现音频混音的资源。
4.根据权利要求1或2所述的方法，其特征在于，所述指示所述彩振服务器的媒体资源功能实体在通话过程中进行混音处理包括：
指示所述彩振服务器的媒体资源功能实体在通话过程中将所述主叫用户设备发送的媒体流与彩振媒体流混合为一路媒体流后转发至被叫用户设备；并将来自所述彩铃服务器的媒体流直接转发至所述主叫用户设备。
5.一种通话过程中继续播放彩铃和彩振的方法，其特征在于，包括：
第二服务器接收第一服务器在通话过程中继续播放的铃音标识，所述铃音标识是所述第一服务器根据所述第二服务器发送的临时响应消息携带的继续播放标识，确定所述第二服务器已触发在通话过程中的继续播放功能，并抑制所述第一服务器在通话过程中的继续播放功能的触发之后发送的；
根据所述铃音标识请求所述第二服务器的媒体资源功能实体预留与所述铃音标识对应的播放资源和混音资源；
在所述第二服务器的媒体资源功能实体与被叫用户设备之间建立媒体通道，并在所述第二服务器的媒体资源功能实体与主叫用户设备之间建立媒体通道；
指示所述第二服务器的媒体资源功能实体在通话过程中进行混音处理。
6.根据权利要求5所述的方法，其特征在于，所述在所述第二服务器的媒体资源功能实体与被叫用户设备之间建立媒体通道包括：
所述第二服务器向所述被叫用户设备发送重邀请消息，所述重邀请消息包括会话类型的会话描述协议请求，所述会话描述协议请求由所述第二服务器的媒体资源功能实体生成，所述会话描述协议请求的因特网协议地址和端口号均指向所述第二服务器的媒体资源功能实体；
接收所述被叫用户设备返回的响应消息，所述响应消息携带所述被叫用户设备的会话类型的会话描述协议应答。
7.根据权利要求6所述的方法，其特征在于，所述第二服务器向所述被叫用户设备发送重邀请消息之前，还包括：
当所述第一服务器在通话过程中继续播放的铃音的媒体类型为视频类型，且所述主叫用户设备与所述被叫用户设备之间的通话媒体类型不包括视频类型时，所述第二服务器在所述重邀请消息的会话描述协议请求中携带视频行，并将所述视频行的方向属性设置为仅发送；或者，
当所述第一服务器在通话过程中继续播放的铃音的媒体类型为视频类型，且所述主叫用户设备与所述被叫用户设备之间的通话媒体类型包括视频类型时，所述第二服务器在所述重邀请消息的会话描述协议请求中携带视频行，并将所述视频行的方向属性设置为发送接收。
8.根据权利要求5所述的方法，其特征在于，所述指示所述第二服务器的媒体资源功能实体在通话过程中进行混音处理包括：
所述第二服务器指示所述第二服务器的媒体资源功能实体在通话过程中将所述被叫用户设备发送的媒体流与彩铃媒体流混合为一路媒体流后转发至所述主叫用户设备；并将所述主叫用户设备发送的媒体流与彩振媒体流混合为一路媒体流后转发至所述被叫用户设备。
9.根据权利要求5-8任意一项所述的方法，其特征在于，
所述第一服务器为彩振服务器时，所述第二服务器为彩铃服务器；或者，所述第一服务器为彩铃服务器时，所述第二服务器为彩振服务器。
10.一种彩振服务器，其特征在于，包括：
确定模块，用于根据接收到的临时响应消息和更新消息确定在通话过程中继续播放彩铃；
第一修改模块，用于在所述确定模块确定在通话过程中继续播放彩铃之后，将所述更新消息中会话描述协议请求的因特网协议地址和端口号修改为所述彩振服务器的媒体资源功能实体的因特网协议地址和端口号；
第一发送模块，用于将所述第一修改模块修改后的所述更新消息发送至主叫用户设备；
接收模块，用于接收所述主叫用户设备发送的针对所述修改后的所述更新消息的响应消息；
第二修改模块，用于将所述接收模块接收的所述响应消息中会话描述协议应答的因特网协议地址和端口号修改为所述彩振服务器的媒体资源功能实体的因特网协议地址和端口号；
第二发送模块，用于将所述第二修改模块修改后的所述响应消息发送至彩铃服务器；
指示模块，用于指示所述彩振服务器的媒体资源功能实体在通话过程中进行混音处理。
11.根据权利要求10所述的彩振服务器，其特征在于，所述确定模块包括：
第一存储子模块，用于在所述彩铃的模式包括早期会话模式时，存储接收到的所述临时响应消息中早期会话类型的会话描述协议请求的因特网协议地址；
第一确定子模块，用于当接收到的所述更新消息中包括会话类型的会话描述协议请求时，如果所述会话类型的会话描述协议请求的因特网协议地址与所述第一存储子模块存储的因特网协议地址相同，则确定在通话过程中继续播放彩铃；或者，
第二存储子模块，用于在所述彩铃的模式包括分支模式时，存储接收到的所述临时响应消息中会话描述协议的因特网协议地址，所述临时响应消息包括早期媒体授权头域，所述早期媒体授权头域的内容为发送接收；
第二确定子模块，用于当接收到的所述更新消息的对话标识与所述临时响应消息的对话标识不同时，如果所述更新消息中会话描述协议的因特网协议地址与所述第二存储子模块存储的因特网协议地址相同，则确定在通话过程中继续播放彩铃。
12.根据权利要求10或11所述的彩振服务器，其特征在于，还包括：
请求模块，用于在所述确定模块确定在通话过程中继续播放彩铃之后，当接收到的所述更新消息中会话描述协议请求的视频行的方向属性为发送接收时，请求所述彩振服务器的媒体资源功能实体预留用于实现音频混音和视频混频的资源；或者，当接收到的所述更新消息中会话描述请求的视频行的方向属性不是发送接收，或者所述更新信息中会话描述请求没有视频行时，请求所述彩振服务器的媒体资源功能实体预留用于实现音频混音的资源。
13.一种彩铃服务器，其特征在于，包括：
标识接收模块，用于接收彩振服务器在通话过程中继续播放的铃音标识，所述铃音标识是所述彩振服务器根据所述彩铃服务器发送的临时响应消息携带的继续播放标识，确定所述彩铃服务器已触发在通话过程中的继续播放功能，并抑制所述彩振服务器在通话过程中的继续播放功能的触发之后发送的；
资源预留模块，用于根据所述标识接收模块接收的铃音标识请求所述彩铃服务器的媒体资源功能实体预留与所述铃音标识对应的播放资源和混音资源；
通道建立模块，用于在所述彩铃服务器的媒体资源功能实体与被叫用户设备之间建立媒体通道，并在所述彩铃服务器的媒体资源功能实体与主叫用户设备之间建立媒体通道；
混音指示模块，用于指示所述彩铃服务器的媒体资源功能实体在通话过程中进行混音处理。
14.根据权利要求13所述的彩铃服务器，其特征在于，所述通道建立模块包括：
消息发送子模块，用于向所述被叫用户设备发送重邀请消息，所述重邀请消息包括会话类型的会话描述协议请求，所述会话描述协议请求由所述彩铃服务器的媒体资源功能实体生成，所述会话描述协议请求的因特网协议地址和端口号均指向所述彩铃服务器的媒体资源功能实体；
消息接收子模块，用于接收所述被叫用户设备返回的响应消息，所述响应消息携带所述被叫用户设备的会话类型的会话描述协议应答。
15.根据权利要求14所述的彩铃服务器，其特征在于，所述通道建立模块还包括：
携带子模块，用于当所述彩振服务器在通话过程中继续播放的铃音的媒体类型为视频类型，且所述主叫用户设备与所述被叫用户设备之间的通话媒体类型不包括视频类型时，在所述重邀请消息的会话描述协议请求中携带视频行，所述视频行的方向属性为仅发送；或者，当所述彩振服务器在通话过程中继续播放的铃音的媒体类型为视频类型，且所述主叫用户设备与所述被叫用户设备之间的通话媒体类型包括视频类型时，在所述重邀请消息的会话描述协议请求中携带视频行，所述视频行的方向属性为发送接收。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201010003386.3A CN102130888B (zh) | 2010-01-19 | 2010-01-19 | 通话过程中继续播放彩铃和彩振的方法和服务器 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201010003386.3A CN102130888B (zh) | 2010-01-19 | 2010-01-19 | 通话过程中继续播放彩铃和彩振的方法和服务器 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN102130888A CN102130888A (zh) | 2011-07-20 |
| CN102130888B true CN102130888B (zh) | 2014-07-09 |
Family
ID=44268780
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201010003386.3A Expired - Fee Related CN102130888B (zh) | 2010-01-19 | 2010-01-19 | 通话过程中继续播放彩铃和彩振的方法和服务器 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN102130888B (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP3952265A4 (en) * | 2019-09-27 | 2022-06-01 | Huawei Technologies Co., Ltd. | CALL HANDLING METHOD AND DEVICE |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105323217B (zh) * | 2014-06-20 | 2020-03-10 | 中兴通讯股份有限公司 | 语音呼叫连续性业务中的媒体协商方法、系统及atcf |
| CN105516936B (zh) * | 2014-10-17 | 2019-07-02 | 中国移动通信集团设计院有限公司 | 一种在通话时进行彩铃传输的方法及装置 |
| CN110650109B (zh) * | 2018-06-26 | 2022-03-01 | 展讯通信（上海）有限公司 | 单向视频场景下回复特定响应消息的方法、装置及终端 |
| CN112671674B (zh) * | 2019-10-16 | 2023-03-28 | 华为技术有限公司 | 呼叫处理的方法、系统及相关装置 |
| CN113132923B (zh) * | 2019-12-31 | 2022-08-26 | 华为技术有限公司 | 呼叫处理的方法、系统及相关装置 |
| CN116566955B (zh) * | 2023-07-07 | 2023-09-19 | 杭州英旭智能科技有限公司 | 一种基于mqtt的数字语音通话方法、装置及应用 |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101478610A (zh) * | 2009-02-04 | 2009-07-08 | 深圳华为通信技术有限公司 | 在通话期间播放多媒体铃音的方法、服务器及终端设备 |
-
2010
- 2010-01-19 CN CN201010003386.3A patent/CN102130888B/zh not_active Expired - Fee Related
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101478610A (zh) * | 2009-02-04 | 2009-07-08 | 深圳华为通信技术有限公司 | 在通话期间播放多媒体铃音的方法、服务器及终端设备 |
Non-Patent Citations (1)
| Title |
|---|
| JP特開2003-134249A 2003.05.09 |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP3952265A4 (en) * | 2019-09-27 | 2022-06-01 | Huawei Technologies Co., Ltd. | CALL HANDLING METHOD AND DEVICE |
Also Published As
| Publication number | Publication date |
|---|---|
| CN102130888A (zh) | 2011-07-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1848189B1 (en) | A method for implementing a multi-media ringback and a system thereof | |
| CN102130888B (zh) | 通话过程中继续播放彩铃和彩振的方法和服务器 | |
| CN102857891B (zh) | 一种被叫用户的域选择方法和系统,以及系统中的hss | |
| CN102215238B (zh) | 融合视频会议业务处理方法与系统、主持人终端 | |
| CN109587172B (zh) | 基于区块链的通信方法及基于区块链的通信系统 | |
| CN101884205B (zh) | Ims集中式服务中i1-ps信令的动态发起 | |
| CN101317438B (zh) | 感知用户进行补充业务的方法及装置 | |
| CN108476448A (zh) | 一种业务处理方法及装置 | |
| CN101262414B (zh) | 语音呼叫连续性业务中的域切换方法 | |
| CN101090567B (zh) | 语音呼叫连续性业务中的终呼业务实现方法 | |
| CN101662738A (zh) | 一种多媒体彩铃播放方法、装置及其系统 | |
| KR101407383B1 (ko) | 통화하는 동안에 멀티미디어 링톤을 재생하는 방법, 서버 및 단말 장치 | |
| CN101699882B (zh) | 彩铃业务与补充业务交互的实现方法、装置及系统 | |
| CN102394989A (zh) | 在通话期间播放多媒体铃音的方法、服务器及终端设备 | |
| CN102006371B (zh) | 一种实现多媒体彩振业务的方法及设备 | |
| CN101111003B (zh) | 多媒体彩铃系统及其播放方法 | |
| CN101217703A (zh) | 一种在线彩铃彩像业务的实现方法 | |
| CN101795330A (zh) | 在通话期间播放多媒体铃音的方法、服务器及终端设备 | |
| CN102143280B (zh) | 一种播放多媒体彩振的方法和多媒体彩振应用服务器 | |
| CN101316269A (zh) | 集团彩铃业务实现方法及系统、视频网关 | |
| CN101247564B (zh) | 在呼叫前转业务基础上实现多媒体彩像业务的方法、装置、系统 | |
| CN101330750A (zh) | 同时向主叫用户和被叫用户播放多媒体信息的方法 | |
| CN101754489B (zh) | 多媒体彩振业务实现方法、多媒体彩振服务器及用户设备 | |
| CN102195948B (zh) | 数据处理方法、策略及计费执行功能和网关设备 | |
| CN102833715B (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 | ||
| CP03 | Change of name, title or address | ||
| CP03 | Change of name, title or address |
Address after: 518129 Building 2, B District, Bantian HUAWEI base, Longgang District, Shenzhen, Guangdong. Patentee after: Huawei terminal (Shenzhen) Co.,Ltd. Address before: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen Patentee before: HUAWEI DEVICE Co.,Ltd. |
|
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20190201 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. |
|
| CF01 | Termination of patent right due to non-payment of annual fee | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20140709 Termination date: 20220119 |