专利名称：通话过程中继续播放彩铃和彩振的方法和服务器的制作方法
技术领域：
本发明实施例涉及通信技术领域，尤其涉及一种通话过程中继续播放彩铃和彩振 的方法和服务器。
背景技术：
随着移动通信网络的发展以及移动用户设备的普及，移动网络的网络运营商在基 本通话业务之外为用户终端提供了更为丰富的增值业务，如彩铃业务和彩振业务。彩铃即主叫用户设备呼叫被叫用户设备时，在被叫用户设备摘机之前，主叫用户 设备欣赏到的多媒体回铃音；彩振即主叫用户设备呼叫被叫用户设备时，在被叫用户设备 摘机接听之前，被叫用户设备欣赏到的多媒体振铃音。在实现本发明的过程中，发明人发现现有技术中至少存在如下问题彩铃服务器和彩振服务器彼此并不知道对方是否激活或执行了继续播放的更新 流程，因此彩铃服务器和彩振服务器会各自执行各自的更新流程，从而导致在通话过程中 继续播放彩铃和彩振时，时间延迟过大，被叫用户设备摘机之后，需要等待较长时间之后才 能进入正常通话。
发明内容
本发明实施例提供一种通话过程中继续播放彩铃和彩振的方法和服务器，以缩短 在通话过程中继续播放彩铃和彩振时的时间延迟。本发明实施例提供一种通话过程中继续播放彩铃和彩振的方法，包括根据接收到的临时响应消息和更新消息确定在通话过程中继续播放彩铃，将所述 更新消息中会话描述协议请求的因特网协议地址和端口号修改为彩振服务器的媒体资源 功能实体的因特网协议地址和端口号，并将修改后的更新消息发送至主叫用户设备；接收所述主叫用户设备发送的针对修改后的更新消息的响应消息，将所述响应消 息中会话描述协议应答的因特网协议地址和端口号修改为所述彩振服务器的媒体资源功 能实体的因特网协议地址和端口号，并将修改后的响应消息发送至彩铃服务器；指示所述彩振服务器的媒体资源功能实体在通话过程中进行混音处理。本发明实施例还提供一种通话过程中继续播放彩铃和彩振的方法，包括第二服务器接收第一服务器在通话过程中继续播放的铃音标识；根据所述铃音标识请求所述第二服务器的媒体资源功能实体预留与所述铃音标 识对应的播放资源和混音资源；在所述第二服务器的媒体资源功能实体与被叫用户设备之间建立媒体通道，并在 所述第二服务器的媒体资源功能实体与主叫用户设备之间建立媒体通道；指示所述第二服务器的媒体资源功能实体在通话过程中进行混音处理。本发明实施例还提供一种彩振服务器，包括确定模块，用于根据接收到的临时响应消息和更新消息确定在通话过程中继续播放彩铃；第一修改模块，用于在所述确定模块确定在通话过程中继续播放彩铃之后，将所 述更新消息中会话描述协议请求的因特网协议地址和端口号修改为所述彩振服务器的媒 体资源功能实体的因特网协议地址和端口号；第一发送模块，用于将所述第一修改模块修改后的更新消息发送至主叫用户设 备；接收模块，用于接收所述主叫用户设备发送的针对修改后的更新消息的响应消 息；第二修改模块，用于将所述接收模块接收的响应消息中会话描述协议应答的因特 网协议地址和端口号修改为所述彩振服务器的媒体资源功能实体的因特网协议地址和端
口号；第二发送模块，用于将所述第二修改模块修改后的响应消息发送至彩铃服务器；指示模块，用于指示所述彩振服务器的媒体资源功能实体在通话过程中进行混音处理。本发明实施例还提供一种彩铃服务器，包括标识接收模块，用于接收彩振服务器在通话过程中继续播放的铃音标识；资源预留模块，用于根据所述标识接收模块接收的铃音标识请求所述彩铃服务器 的媒体资源功能实体预留与所述铃音标识对应的播放资源和混音资源；通道建立模块，用于在所述彩铃服务器的媒体资源功能实体与被叫用户设备之间 建立媒体通道，并在所述彩铃服务器的媒体资源功能实体与主叫用户设备之间建立媒体通 道；混音指示模块，用于指示所述彩铃服务器的媒体资源功能实体在通话过程中进行
混音处理。通过本发明实施例，彩铃服务器可以识别出彩振会在通话过程中继续播放，或者， 彩振服务器可以识别出彩铃会在通话过程中继续播放，然后彩铃服务器或彩振服务器再执 行更新流程，实现在通话过程中继续播放彩铃和彩振，并缩短了在通话过程中继续播放彩 铃和彩振时的时间延迟，提高了用户体验度。
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现 有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发 明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根 据这些附图获得其他的附图。图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，然后转发该ISORinging消息。步骤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返回临时响应确认的成功处理消息，即2000K (PRACK)消息，该 2000K (PRACK)消息中携带UE-B的early-session类型的SDPanswer，用于应答彩振的早期 会话。步骤212，CAT-AS接收到2000K(PRACK)消息后，不做任何处理，直接将该 2000K (PRACK)消息转发至 CRS-AS。步骤213，CRS-AS 接收到 2000K (PRACK)消息后，提取该 2000K (PRACK)消息中 UE-B 的early-session类型的SDP answer,从而完成彩振早期媒体协商，然后CRS-AS将空的200 OK(PRACK)消息转发给UE-A0此时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 返回 2000K (re-INVITE)消息，该 2000K(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 接收到 2000K(UPDATE)消息后，从该 2000K(UPDATE)中提取出 SDP answer,从而完成与UE-A之间的会话协商，即建立了 UE-A与CRS-AS的MRF实体之间 的媒体通道。然后CRS-AS将UE-A的SDP answer中的IP地址和端口号均修改为该CRS-AS 的MRF实体的IP地址和端口号之后，将修改后的SDP answer插入到2000K (UPDATE)消息 中，然后将该2000K (UPDATE)转发给CAT-AS，目的是建立CRS-AS的MRF实体与CAT-AS的 MRF实体之间的会话。步骤223，CAT-AS接收到2000K(UPDATE)消息后，完成了用于CATcontinue功能的 会话更新。这时，CRS-AS的MRF实体与CAT-AS的MRF实体之间建立了媒体通道，但CAT-AS 对此是不感知的。然后CAT-AS向UE-A返回2000K(INVITE)消息。步骤224，CRS-AS 将 2000K (INVITE)消息转发给 UE-A。步骤225，UE-A返回ACK消息。
步骤2 ，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的2000K(PRACK)消息)、或者在步骤218的UPDATE 消息中携带彩铃继续播放(CAT continue)标识，以明确告知CRS-AS “彩铃会在通话过程 中继续播放”，从而CRS-AS无需对比IP地址，可以根据接收到的临时响应消息、响应消息或 更新消息所携带的彩铃继续播放标识，确定在通话过程中继续播放彩铃。对于CAT Continue标识的携带方法，可以为在临时响应消息、响应消息或更新 消息的contact头域或acc印t-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消息的头域中的CAI^ontinue标 识，确定彩铃会在通话过程中继续为主叫用户设备播放，从而开始准备后续的流程，并将该 180消息转发给UE-A0步骤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 返回 2000K(PRACK)消息，该 2000K(PRACK)消息中携带了 UE-B 的 early-session类型的SDP answer，用于应答彩振的早期会话。步骤411，CAT-AS接收到2000K (PRACK)消息后，不做任何处理，直接将该 2000K (PRACK)消息转发至 CRS-AS。步骤412，CRS-AS 接收到 2000K(PRACK)消息后，提取该 2000K(PRACK)消息中 UE-B 的early-session类型的SDP answer,从而完成彩振早期媒体协商，然后CRS-AS将空的 2000K (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返回2000K(INF0)消息，表示同意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发送2000K(INVITE)摘 机消息。步骤418，CAT-AS收到2000K(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 返回 2000K (re-INVITE)消息，该 2000K (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-A0步骤423，UE-A 返回 2000K (UPDATE)消息，该 2000K (UPDATE)消息中携带了 UE-A 的 session 类型的 SDP answer。步骤424，CRS-AS接收到2000K(UPDATE)消息后，将该2000K(UPDATE)消息转发给 CAT-AS0步骤425，CAT-AS 接收到 2000K(UPDATE)消息后，完成 了用于 CATcontinue 功 能的会话更新，建立了 UE-A与CAT-AS的MRF实体之间的媒体通道。然后CAT-AS返回 2000K(INVITE)消息。步骤426，CRS-AS 将 2000K (INVITE)消息转发给 UE-A。步骤427，UE-A返回ACK消息。
步骤似8，CRS-AS将ACK消息转发给CAT-AS。步骤似9，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都可以正常播放，实现了在通话过程中既为主叫用户设备播放彩 铃，又为被叫用户设备播放彩振，并且减少了交互的信令数，缩短了在通话过程中继续播放 彩铃和彩振时的时间延迟，提高了用户体验度。本领域普通技术人员可以理解实现上述方法实施例的全部或部分步骤可以通过 程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序 在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括R0M、RAM、磁碟或者 光盘等各种可以存储程序代码的介质。图5为本发明彩振服务器一个实施例的结构示意图，本实施例中的彩振服务器可 以实现本发明图1所示实施例的流程。如图5所示，该彩振服务器可以包括确定模块51、 第一修改模块52、第一发送模块53、接收模块M、第二修改模块55、第二发送模块56和指 示模块57。其中，确定模块51，用于根据接收到的临时响应消息和更新消息确定在通话过程 中继续播放彩铃；第一修改模块52，用于在确定模块51确定在通话过程中继续播放彩铃之后，将上 述更新消息中会话描述协议请求的IP地址和端口号修改为彩振服务器的媒体资源功能实 体的IP地址和端口号。第一发送模块53，用于将第一修改模块52修改后的更新消息发送至主叫用户设 备。接收模块M，用于接收主叫用户设备发送的针对修改后的更新消息的响应消息。第二修改模块55，用于将接收模块M接收的响应消息中会话描述协议应答的因 特网协议地址和端口号修改为彩振服务器的媒体资源功能实体的IP地址和端口号。第二发送模块56，用于将第二修改模块55修改后的响应消息发送至彩铃服务器；CN 102130888 A
说明书
12/17页
本实施例中，第二发送模块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 Subscriberkrver ；以下简称 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所示实 施例的描述，在此不再赘述。上述系统中，彩铃服务器可以识别出彩振会在通话过程中继续播放，或者，彩振服 务器可以识别出彩铃会在通话过程中继续播放，然后彩铃服务器或彩振服务器再执行更新 流程，实现在通话过程中继续播放彩铃和彩振，并缩短了在通话过程中继续播放彩铃和彩 振时的时间延迟，提高了用户体验度。本领域技术人员可以理解附图只是一个优选实施例的示意图，附图中的模块或流程并不一定是实施本发明所必须的。本领域技术人员可以理解实施例中的装置中的模块可以按照实施例描述进行分 布于实施例的装置中，也可以进行相应变化位于不同于本实施例的一个或多个装置中。上 述实施例的模块可以合并为一个模块，也可以进一步拆分成多个子模块。最后应说明的是以上实施例仅用以说明本发明的技术方案，而非对其限制；尽 管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解其依然 可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替 换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精 神和范围。
权利要求
1.一种通话过程中继续播放彩铃和彩振的方法，其特征在于，包括根据接收到的临时响应消息和更新消息确定在通话过程中继续播放彩铃，将所述更新 消息中会话描述协议请求的因特网协议地址和端口号修改为彩振服务器的媒体资源功能 实体的因特网协议地址和端口号，并将修改后的更新消息发送至主叫用户设备；接收所述主叫用户设备发送的针对修改后的更新消息的响应消息，将所述响应消息中 会话描述协议应答的因特网协议地址和端口号修改为所述彩振服务器的媒体资源功能实 体的因特网协议地址和端口号，并将修改后的响应消息发送至彩铃服务器； 指示所述彩振服务器的媒体资源功能实体在通话过程中进行混音处理。
2.根据权利要求1所述的方法，其特征在于，所述彩铃的模式包括早期会话模式或分 支模式；所述彩铃的模式为早期会话模式时，所述根据接收到的临时响应消息和更新消息确定在通话过程中继续播放彩铃包括 存储接收到的所述临时响应消息中早期会话类型的会话描述协议请求的因特网协议 地址；当接收到的所述更新消息中包括会话类型的会话描述协议请求时，如果所述会话类型 的会话描述协议请求的因特网协议地址与存储的因特网协议地址相同，则确定在通话过程 中继续播放彩铃；或者，所述彩铃的模式为分支模式时，所述根据接收到的临时响应消息和更新消息确定在通话过程中继续播放彩铃包括 存储接收到的所述临时响应消息中会话描述协议的因特网协议地址，所述临时响应消 息包括早期媒体授权头域，所述早期媒体授权头域的内容为发送接收或仅发送；当接收到的所述更新消息的对话标识与所述临时响应消息的对话标识不同时，如果所 述更新消息中会话描述协议的因特网协议地址与存储的因特网协议地址相同，则确定在通 话过程中继续播放彩铃。
3.根据权利要求1或2所述的方法，其特征在于，所述方法还包括确定在通话过程中继续播放彩铃之后，当接收到的更新消息中会话描述协议请求的视 频行的方向属性为发送接收时，请求所述彩振服务器的媒体资源功能实体预留用于实现音 频混音和视频混频的资源；或者，当接收到的更新消息中会话描述请求的视频行的方向属性不是发送接收，或者所述会 话描述请求没有视频行时，请求所述彩振服务器的媒体资源功能实体预留用于实现音频混 音的资源。
4.根据权利要求1或2所述的方法，其特征在于，所述指示所述彩振服务器的媒体资源 功能实体在通话过程中进行混音处理包括指示所述彩振服务器的媒体资源功能实体在通话过程中将所述主叫用户设备发送的 媒体流与彩振媒体流混合为一路媒体流后转发至被叫用户设备；并将来自彩铃服务器的媒 体流直接转发至所述主叫用户设备。
5.一种通话过程中继续播放彩铃和彩振的方法，其特征在于，包括 第二服务器接收第一服务器在通话过程中继续播放的铃音标识；根据所述铃音标识请求所述第二服务器的媒体资源功能实体预留与所述铃音标识对应的播放资源和混音资源；在所述第二服务器的媒体资源功能实体与被叫用户设备之间建立媒体通道，并在所述 第二服务器的媒体资源功能实体与主叫用户设备之间建立媒体通道；指示所述第二服务器的媒体资源功能实体在通话过程中进行混音处理。
6.根据权利要求5所述的方法，其特征在于，所述铃音标识是所述第一服务器根据所 述第二服务器发送的临时响应消息携带的继续播放标识，确定所述第二服务器已触发在通 话过程中的继续播放功能，并抑制所述第一服务器在通话过程中的继续播放功能的触发之 后发送的。
7.根据权利要求5所述的方法，其特征在于，所述在所述第二服务器的媒体资源功能 实体与被叫用户设备之间建立媒体通道包括所述第二服务器向所述被叫用户设备发送重邀请消息，所述重邀请消息包括会话类 型的会话描述协议请求，所述会话描述协议请求由所述第二服务器的媒体资源功能实体生 成，所述会话描述协议请求的因特网协议地址和端口号均指向所述第二服务器的媒体资源 功能实体；接收所述被叫用户设备返回的响应消息，所述响应消息携带所述被叫用户设备的会话 类型的会话描述协议应答。
8.根据权利要求7所述的方法，其特征在于，所述第二服务器向所述被叫用户设备发 送重邀请消息之前，还包括当所述第一服务器在通话过程中继续播放的铃音的媒体类型为视频类型，且所述主叫 用户设备与所述被叫用户设备之间的通话媒体类型不包括视频类型时，所述第二服务器在 所述重邀请消息的会话描述协议请求中携带视频行，并将所述视频行的方向属性设置为仅 发送；或者，当所述第一服务器在通话过程中继续播放的铃音的媒体类型为视频类型，且所述主叫 用户设备与所述被叫用户设备之间的通话媒体类型包括视频类型时，所述第二服务器在所 述重邀请消息的会话描述协议请求中携带视频行，并将所述视频行的方向属性设置为发送 接收。
9.根据权利要求5所述的方法，其特征在于，所述指示所述第二服务器的媒体资源功 能实体在通话过程中进行混音处理包括所述第二服务器指示所述第二服务器的媒体资源功能实体在通话过程中将所述被叫 用户设备发送的媒体流与彩铃媒体流混合为一路媒体流后转发至所述主叫用户设备；并将 所述主叫用户设备发送的媒体流与彩振媒体流混合为一路媒体流后转发至所述被叫用户 设备。
10.根据权利要求5-9任意一项所述的方法，其特征在于，所述第一服务器为彩振服务器时，所述第二服务器为彩铃服务器；或者，所述第一服务 器为彩铃服务器时，所述第二服务器为彩振服务器。
11.一种彩振服务器，其特征在于，包括确定模块，用于根据接收到的临时响应消息和更新消息确定在通话过程中继续播放彩钤.K 9第一修改模块，用于在所述确定模块确定在通话过程中继续播放彩铃之后，将所述更新消息中会话描述协议请求的因特网协议地址和端口号修改为所述彩振服务器的媒体资 源功能实体的因特网协议地址和端口号；第一发送模块，用于将所述第一修改模块修改后的更新消息发送至主叫用户设备； 接收模块，用于接收所述主叫用户设备发送的针对修改后的更新消息的响应消息； 第二修改模块，用于将所述接收模块接收的响应消息中会话描述协议应答的因特网 协议地址和端口号修改为所述彩振服务器的媒体资源功能实体的因特网协议地址和端口 号；第二发送模块，用于将所述第二修改模块修改后的响应消息发送至彩铃服务器； 指示模块，用于指示所述彩振服务器的媒体资源功能实体在通话过程中进行混音处理。
12.根据权利要求11所述的彩振服务器，其特征在于，所述确定模块包括第一存储子模块，用于在所述彩铃的模式包括早期会话模式时，存储接收到的临时响 应消息中早期会话类型的会话描述协议请求的因特网协议地址；第一确定子模块，用于当接收到的更新消息中包括会话类型的会话描述协议请求时， 如果所述会话类型的会话描述协议请求的因特网协议地址与所述第一存储子模块存储的 因特网协议地址相同，则确定在通话过程中继续播放彩铃；或者，第二存储子模块，用于在所述彩铃的模式包括分支模式时，存储接收到的临时响应消 息中会话描述协议的因特网协议地址，所述临时响应消息包括早期媒体授权头域，所述早 期媒体授权头域的内容为发送接收；第二确定子模块，用于当接收到的更新消息的对话标识与所述临时响应消息的对话标 识不同时，如果所述更新消息中会话描述协议的因特网协议地址与所述第二存储子模块存 储的因特网协议地址相同，则确定在通话过程中继续播放彩铃。
13.根据权利要求11或12所述的彩振服务器，其特征在于，还包括请求模块，用于在所述确定模块确定在通话过程中继续播放彩铃之后，当接收到的更 新消息中会话描述协议请求的视频行的方向属性为发送接收时，请求所述彩振服务器的媒 体资源功能实体预留用于实现音频混音和视频混频的资源；或者，当接收到的更新消息中 会话描述请求的视频行的方向属性不是发送接收，或者所述会话描述请求没有视频行时， 请求所述彩振服务器的媒体资源功能实体预留用于实现音频混音的资源。
14.一种彩铃服务器，其特征在于，包括标识接收模块，用于接收彩振服务器在通话过程中继续播放的铃音标识； 资源预留模块，用于根据所述标识接收模块接收的铃音标识请求所述彩铃服务器的媒 体资源功能实体预留与所述铃音标识对应的播放资源和混音资源；通道建立模块，用于在所述彩铃服务器的媒体资源功能实体与被叫用户设备之间建立 媒体通道，并在所述彩铃服务器的媒体资源功能实体与主叫用户设备之间建立媒体通道；混音指示模块，用于指示所述彩铃服务器的媒体资源功能实体在通话过程中进行混音 处理。
15.根据权利要求14所述的彩铃服务器，其特征在于，所述通道建立模块包括消息发送子模块，用于向所述被叫用户设备发送重邀请消息，所述重邀请消息包括会 话类型的会话描述协议请求，所述会话描述协议请求由所述彩铃服务器的媒体资源功能实体生成，所述会话描述协议请求的因特网协议地址和端口号均指向所述彩铃服务器的媒体 资源功能实体；消息接收子模块，用于接收所述被叫用户设备返回的响应消息，所述响应消息携带所 述被叫用户设备的会话类型的会话描述协议应答。
16.根据权利要求15所述的彩铃服务器，其特征在于，所述通道建立模块还包括 携带子模块，用于当所述彩振服务器在通话过程中继续播放的铃音的媒体类型为视频 类型，且所述主叫用户设备与所述被叫用户设备之间的通话媒体类型不包括视频类型时， 在所述重邀请消息的会话描述协议请求中携带视频行，所述视频行的方向属性为仅发送； 或者，当所述彩振服务器在通话过程中继续播放的铃音的媒体类型为视频类型，且所述主 叫用户设备与所述被叫用户设备之间的通话媒体类型包括视频类型时，在所述重邀请消息 的会话描述协议请求中携带视频行，所述视频行的方向属性为发送接收。
全文摘要
本发明实施例提供一种通话过程中继续播放彩铃和彩振的方法和服务器，该方法包括确定在通话过程中继续播放彩铃之后，将接收到的更新消息中SDP offer的IP地址和端口号修改为彩振服务器的MRF实体的IP地址和端口号，并将修改后的更新消息发送至主叫用户设备；接收主叫用户设备发送的针对修改后的更新消息的响应消息，将该响应消息中SDP answer的IP地址和端口号修改为彩振服务器的MRF实体的IP地址和端口号，并将修改后的响应消息发送至彩铃服务器；指示彩振服务器的MRF实体在通话过程中进行混音处理。本发明实施例实现了在通话过程中继续播放彩铃和彩振，缩短了在通话过程中继续播放彩铃和彩振时的时间延迟，提高了用户体验度。
文档编号H04L29/06GK102130888SQ20101000338
公开日2011年7月20日 申请日期2010年1月19日 优先权日2010年1月19日
发明者杨健, 王雷, 范姝男, 郜文美 申请人:华为终端有限公司