首页> 中国专利> 多会话转移方法及呼叫控制设备和业务连续性服务器

多会话转移方法及呼叫控制设备和业务连续性服务器

摘要

本发明公开了多会话转移方法及呼叫控制设备和业务连续性服务器。本发明实施例中,在多会话跨网络转移过程中,且待转移的第二个会话包含视频频媒体时,移动交换中心服务器对当前网络支持的能力进行判断,在当前网络无法传输视频媒体时,发起对所述第二个待转移会话的语音媒体的转移请求,集中业务和业务连续性服务器(SCC AS)接收所述转移请求,将第二个待转移会话转移转换为语音会话或者释放所述第二个待转移会话,以避免现有技术中出现的网络无法完成会话转移的问题,使得跨网络的多会话转移业务更加完善。

著录项

  • 公开/公告号CN102006645A

    专利类型发明专利

  • 公开/公告日2011-04-06

    原文格式PDF

  • 申请/专利权人 华为终端有限公司;

    申请/专利号CN200910171816.X

  • 发明设计人 衣强;金辉;龙水平;段小嫣;

    申请日2009-08-31

  • 分类号H04W36/14(20090101);H04W76/04(20090101);H04W80/10(20090101);H04L29/06(20060101);

  • 代理机构深圳市深佳知识产权代理事务所(普通合伙);

  • 代理人彭愿洁;李文红

  • 地址 518129 广东省深圳市龙岗区坂田华为基地B区2号楼

  • 入库时间 2023-12-18 01:56:30

法律信息

  • 法律状态公告日

    法律状态信息

    法律状态

  • 2019-01-04

    专利权的转移 IPC(主分类):H04W36/14 登记生效日:20181218 变更前: 变更后: 申请日:20090831

    专利申请权、专利权的转移

  • 2019-01-04

    专利权人的姓名或者名称、地址的变更 IPC(主分类):H04W36/14 变更前: 变更后: 申请日:20090831

    专利权人的姓名或者名称、地址的变更

  • 2012-01-04

    授权

    授权

  • 2011-05-25

    实质审查的生效 IPC(主分类):H04W36/14 申请日:20090831

    实质审查的生效

  • 2011-04-06

    公开

    公开

说明书

技术领域

本发明涉及通信技术领域,具体涉及多会话转移方法及呼叫控制设备和业务连续性服务器。

背景技术

IMS会话连续性(IMS Service Continuity,SC)技术是实现IP多媒体子系统(IP multimedia subsystem,IMS)用户(User Equipment,UE)在不同接入网络之间移动时,不中断当前正在进行的IMS会话,确保良好的用户体验,SC的核心是集中业务和业务连续性服务器(Service Centralization and ContinuityAS,SCC AS),SCC AS用于对用户在多个网络的会话转移进行控制。

IMS集中业务(IMS Centralized Service,ICS)UE是一个增强了ICS能力的IMS UE,具有ICS能力通常指支持Gm或I1接口的能力,反之non ICS UE指不支持Gm、I1接口,或支持此接口但在通信过程不使用此接口传送信令的UE。

对于Non ICS UE普通语音会话由分组交换(Packet Switched,PS)域转移到电路交换(Circuit Switched,CS)域,在CS域发起CS域信令(例如:setup消息)作为转移请求,请求包含的会话转移号码(Session Transfer Number,STN)为被叫号码,SCCAS收到该请求并由STN值获知该请求为转移请求,则关联与之相关的PS域会话,更新对端,释放PS域相关会话,完成转移过程。

由于Non ICS UE的PS到CS的多会话(session)转移只支持转移两个会话的情况,UE在发起转移请求前释放待转移两个会话外的其它会话,如果UE没有释放成功,SCC AS收到转移请求后,需要将此转移请求与待转移会话关联,如果此时存在多于两个会话,SCC AS也可以发起会话释放。具体解决方案为,首先转移激活状态会话(若无激活状态会话,则只转移最近保持的会话),转移后SCC AS将除最近激活状态会话外的前一个激活状态会话或最近被hold状态会话信息发送给移动交换中心服务器(MSC Server),由MSC Server代替UE发起第二个会话的转移。

发明人在对现有技术的研究和实践过程中,本发明的发明人发现当UE从PS网络向CS网络转移,且UE中包含多个会话,当转移的第二个会话是多媒体会话时,现有技术没有考虑可能存在由于UE当前无线接入网(radio accessnetwork,RAN)不支持Video媒体传输或当前网络资源不足以支持视频(Video)媒体传输而出现的无法转移第二个会话的异常情况。

发明内容

本发明实施例提供多会话转移方法及呼叫控制设备和业务连续性服务器,可以实现多会话转移过程中,对当前网络不支持视频媒体的处理。

本发明实施例提供的一种多会话转移方法,当完成将终端的第一个会话由源网络域向目标网络域的转移后,包括:

所述终端在目标网络域所属的移动交换中心服务器MSC Server接收集中,业务和业务连续性服务器SCC AS发送的所述终端第二个待转移会话的状态信息;所述状态信息包含所述第二个待转移会话的媒体类型,所述媒体类型包含视频类型;

若所述MSC Server判断所述目标网络域无法传输视频数据,则所述MSCServer向所述SCC AS发起对所述第二个待转移会话的语音媒体的转移请求,以使所述SCC AS收到该请求后,将所述第二个待转移会话转换为语音会话进行转移或者释放所述第二个待转移会话。

本发明实施例提供的一种多媒体会话转移方法,当完成将终端的第一个会话由源网络域向目标网络域的转移后,包括:

所述SCC AS向终端在目标网络域所属的MSC Server发送所述终端第二个待转移会话的状态信息;所述状态信息包含所述第二个待转移会话的媒体类型,所述媒体类型包含视频类型;

若所述SCC AS收到所述MSC Server因为目标网络域无法传输视频数据而发送的所述第二个待转移会话转移失败指示,则将第二个待转移会话转移转换为语音会话进行转移或者释放所述第二个待转移会话。

本发明实施例提供的一种呼叫控制设备,包括:

接收单元,用于接收SCC AS发送的所述终端第二个待转移会话的状态信息;所述状态信息包含所述第二个待转移会话的媒体类型,所述媒体类型包含视频类型;

会话转移控制单元,用于判断会话转移的目标网络域是否可以传输视频数据,若不可以,则向SCC AS发起对所述第二个待转移会话的语音媒体的转移请求,以使所述SCC AS收到该请求后,将所述第二个待转移会话转移转换为语音会话或者释放所述第二个待转移会话。

本发明实施例提供的一种呼叫控制设备,包括:

接收单元,用于接收SCC AS发送的所述终端第二个待转移会话的状态信息;所述状态信息包含所述第二个待转移会话的媒体类型,所述媒体类型包含视频类型;

会话转移控制单元,用于判断会话转移的目标网络域是否可以传输视频数据,若不可以,则向所述SCC AS发起所述第二个待转移会话转移失败指示,以使所述SCC AS收到该请求后,将所述第二个待转移会话转移转换为语音会话或者释放所述第二个待转移会话。

本发明实施例提供的一种业务连续性服务器,包括:

发送单元,用于终端所属的所述MSC Server发送所述终端第二个待转移会话的状态信息;所述状态信息包含所述第二个待转移会话的媒体类型,所述媒体类型包含视频类型;

会话处理单元,用于接收所述MSC Server发起的对所述第二个待转移会话的语音媒体的转移请求,将第二个待转移会话转移转换为语音会话进行转移或者释放所述第二个待转移会话。

本发明实施例提供的一种业务连续性服务器,包括:

发送单元,用于向终端所属的MSC Server发送所述终端第二个待转移会话的状态信息,所述状态信息包含所述第二个待转移会话的媒体类型,所述媒体类型包含视频类型;

会话处理单元,用于接收所述MSC Server因为目标网络域无法传输视频数据而发送的所述第二个待转移会话转移失败指示,将第二个待转移会话转移转换为语音会话进行转移或者释放所述第二个待转移会话。

本发明实施例中,在多会话跨网络转移过程中,且待转移的第二个会话包含视频频媒体时,移动交换中心服务器对当前网络支持的能力进行判断,在当前网络无法传输视频媒体时,发起对所述第二个待转移会话的语音媒体的转移请求,集中业务和业务连续性服务器(SCC AS)接收所述转移请求,将第二个待转移会话转移转换为语音会话或者释放所述第二个待转移会话,以避免现有技术中出现的网络无法完成会话转移的问题,使得跨网络的多会话转移业务更加完善。

附图说明

图1是本发明实施例一多会话转移方法的流程图;

图2是本发明实施例二多会话转移方法的流程图;

图3是本发明实施例中将第二个待转移会话转移转换为语音会话进行转移的流程图;

图4是本发明实施例应用例一的信令流程图;

图5是本发明实施例应用例二的信令流程图;

图6是本发明实施例应用例三的信令流程图;

图7是本发明实施例三呼叫控制设备的结构示意图;

图8是本发明实施例四呼叫控制设备的结构示意图;

图9是本发明实施例五业务连续性服务器的结构示意图;

图10是本发明实施例六业务连续性服务器的结构示意图。

具体实施方式

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

本发明实施例提供多会话转移方法及呼叫控制设备和业务连续性服务器。以下分别进行详细说明。

实施例一、一种多会话转移方法,流程图如图1所示,当完成将终端的第一个会话由源网络域向目标网络域的转移后,包括:

B1,终端在目标网络域所属的移动交换中心服务器(MSC Server)接收集中业务和业务连续性服务器(Service Centralization and Continuity AS,SCCAS)发送的所述终端第二个待转移会话的状态信息;所述状态信息包含所述第二个待转移会话的媒体类型,所述媒体类型包含视频类型;

本实施例中,所述终端为Non ICS UE或具有类似功能的用户设备,所述源网络域为PS网络域名,所述目标网络域为CS域。

B2,若所述移动交换中心服务器判断所述目标网络域无法传输视频数据,则移动交换中心服务器向SCC AS发起对所述第二个待转移会话的语音媒体的转移请求,SCC AS收到该请求后,将所述第二个待转移会话转移转换为语音会话或者释放所述第二个待转移会话。

本发明实施例中,所述SCC AS释放所述第二个待转移会话之后还可以包括:

MSC Server接收SCC AS发送的对所述转移请求的失败响应消息,将所述第二个待转移会话的会话状态信息删除。

可以理解,目标网络无法传输视频数据可能有多种原因,例如:接入网络不支持、网络带宽不支持、网络资源不足(视频业务相对于语音业务需要占用较多的资源)。

本实施例中,所述向SCC AS发起对所述第二个待转移会话的语音媒体的转移请求可以通过以下方式实现:

具体的,核心网设备向SCC AS仅发送语音媒体的会话转移请求,即将请求中的媒体行信息中的视频媒体传输端口号置0,仅请求语音媒体的转移,这样SCC AS在收到该请求后,则可以将所述第二个待转移会话转换为语音会话进行转移或者释放所述第二个待转移会话。具体的移动交换中心服务器请求所述SCC AS将视频会话转换为语音会话的方式还可以有多种,不构成对本发明的限制。

实施例一中在多会话跨网络转移过程中,且待转移的第二个会话包含视频频媒体时,移动交换中心服务器对当前网络支持的能力进行判断,在当前网络无法传输视频媒体时,发起对所述第二个待转移会话的语音媒体的转移请求,集中业务和业务连续性服务器(SCC AS)接收所述转移请求,将第二个待转移会话转移转换为语音会话或者释放所述第二个待转移会话,以避免现有技术中出现的网络无法完成会话转移的问题,使得跨网络的多会话转移业务更加完善。

实施例二、一种多会话转移方法,流程图如图2所示,当完成将终端的第一个会话由源网络域向目标网络域的转移后,包括:

C1,SCC AS向终端在目标网络域所属的所述移动交换中心服务器发送所述终端第二个待转移会话的状态信息;所述状态信息包含所述第二个待转移会话的媒体类型,所述媒体类型包含视频类型;

C2,若SCC AS收到所述移动交换中心服务器因为目标网络域无法传输视频数据而发送的所述第二个待转移会话转移失败指示,则将第二个待转移会话转移转换为语音会话进行转移或者释放所述第二个待转移会话。

本实施例中,所述释放所述第二个待转移会话包括:在源网络域释放所述第二个待转移会话,并与所述终端的通信对端交互完成通信对端接入分支的更新过程。可以理解,本实施例还可以采取现有的其他方式完成会话的释放,具体的方式不构成对本发明的限制。

本发明实施例二中,在当前网络不支持视频会话时,由集中业务和业务连续性服务器(SCC AS)将第二个待转移会话转移转换为语音会话或者释放所述第二个待转移会话,以避免现有技术中出现的网络无法完成会话转移的问题,使得跨网络的多会话转移业务更加完善。

实施例二中,SCC AS收到所述移动交换中心服务器因为目标网络域无法传输视频数据而发送的所述第二个待转移会话转移失败指示可以采取以下方式实现:

方式一、SCC AS接收移动交换中心服务器发送的所述第二个待转移会话转移失败指示;所述第二个待转移会话转移失败指示中包含:转移失败原因参数,所述转移失败原因参数指示目标网络域无法传输视频数据的传输。所述第二个待转移会话转移失败指示可以通过会话初始协议(Session InitiationProtocol,SIP)的信息传递请求消息(INFO消息)或即时消息(Massage)携带。

方式二、所述SCC AS收到所述移动交换中心服务器因为目标网络域无法传输视频数据而发送的所述第二个待转移会话转移失败指示之前包括:

所述SCC AS向所述移动交换中心服务器发送订阅请求(SUBSCRIBE)消息;

SCC AS接收所述移动交换中心服务器因为目标网络域无法传输视频数据而发送的所述第二个待转移会话转移失败指示包括:

接收所述核心网设备返回的订阅请求的通知(Notify)消息,所述Notify消息包含所述第二个待转移会话转移失败指示。

本发明实施例二中将第二个待转移会话转移转换为语音会话进行转移,可以采取以下方式实现,流程图如图3所示,具体包括:

D1,在源网络域释放所述待转移会话的视频媒体;

D2,通知所述移动交换中心服务器重新发起语音媒体类型的会话转移请求,以建立在所述第二个待转移会话在目标网络域的接入分支;可以理解,所述通知所述移动交换中心服务器重新发起语音会话转移请求的方式可以采取向所述移动交换中心服务器返回所述INFO消息或者的Notify消息的回复消息200OK或者Massage消息的响应实现。

D3,与所述终端的通信对端交互完成通信对端接入分支的更新过程。

具体的完成通信对端接入分支的更新可以通过以下流程实现:

SCC AS将所述第二个待转移会话在目标网络域的呼叫分支和与SCC AS与所述通信对端的呼叫分支绑定;

SCC AS在将两个呼叫分支绑定的过程中,SCC AS相当于一个B2BUA(背靠背代理),通过SCC AS实现双方的通信。

与所述终端的通信对端交互将所述第二个待转移会话的视频媒体更新为音频媒体。因为在源网络中所述终端和通信对端进行第二会话为视频会话,那么SCC AS将视频会话转换为语音会话需要与通信对端进行媒体协商,更新相关的编解码信息,媒体协商可以通过会话描述协议(SDP)信息实现。

可以理解,在完成多会话转移后,终端在源网络中的第二会话已经成为冗余,SCC AS释放与所述终端在源网络域的呼叫分支。

为了更好的理解本发明,下面提供本基于本发明实施例一和实施例二应用具体通信协议的应用例,下述应用例中,源网络域为PS域、目标网络域为CS域。

应用例一、

MSC Server在收到第二个待转移会话的多媒体会话状态信息后,由于各种原因而无法发起多媒体会话转移,则发起语音媒体的转移请求,原因可能是UE当前无线接入网(radio access network,RAN)不支持视频(Video)媒体的传输或网络资源不足等情况,流程图如图4所示:

F1-F4,与现有技术的图1中步骤A1到步骤A4所描述内容相同不在赘述。

F5,SCC AS判断UE所在MSC Server是否支持Video。若支持则下发多媒体会话的会话状态信息,需要在会话状态信息中指示媒体类型包括Video。

若MSC Server不支持Video传输则SCC AS在后续步骤中释放该会话在原PS域的Video媒体,下发语音会话的会话状态信息,在会话状态信息中指出语音(audio)媒体类型,并令视频媒体(video)的媒体行端口号置0。

F6,SCC AS将选择的会话状态信息通过INVITE请求的回复消息(200OK)发送到服务会话控制功能实体(Server Call Session Control Function,S-CSCF)或访问会话控制功能实体(interrogating,I-CSCF),以下以S-CSCF为例进行说明,对于I-CSCF的处理情况相同。

F7,S-CSCF将200OK回复消息发送到MSC Server。

F8,MSC Server收到第二个会话(多媒体会话)的会话状态信息,根据当前UE RAN和资源状况判断是否可以支持Video传输。

F9a,若当前网络支持Video传输,则按现有技术发起多媒体会话的转移请求,并完成对端更新和会话转移。

F9b,若当前网络不能支持Video传输则对该转移会话只转移语音媒体,则发起语音会话转移请求,具体的是在发送的Invite请求中SDP信息中将Video媒体的端口号置0。

F10,所述Invite请求被S-CSCF发送到SCC AS。

F11b-F12b,SCC AS判断转移请求对应会话为包含视频媒体的多媒体会话,选择将多媒体会话转换为语音会话,则释放原PS域的Video媒体,即SCC AS根据保存的SDP信息生成re-INVITE请求,并将SDP信息中Video媒体行对应的端口号置0,释放媒体请求经S-CSCF发送到本端UE。

当然本实施例中,SCCAS也可以收到所述Invite请求后,发现对应会话存在Video媒体,根据策略拒绝将多媒体会话转换为语音会话,则返回4**响应(如403 forbidden),并释放多媒体会话,多媒体会话释放后,可以更新对端,并执行步骤F22。本发明实施例中,具体的策略可以预先在SCC AS上配置。MSCServer收到4**返回消息后将所述会话的会话状态信息删除。

F13b-F14b,UE上的Video媒体被删除,UE发出re-INVITE请求的回复消息200OK,回复消息经S-CSCF发送到SCC AS。

F15b-F16b,SCC AS发送回复消息的确认消息ACK,并由S-CSCF发送到UE。

F17b,SCC AS利用MSC Server发送的INVITE请求的SDP信息更新对端。

F18b-F19b,SCC AS对INVITE请求回复200OK响应,200OK响应经S-CSCF发送到MSC Server。

F20b-F21b,MSC Server发出确认消息ACK,ACK经S-CSCF发送到SCCAS,完成第二个会话在CS域的呼叫分支(access leg)建立。

F22,SCC AS释放所述UE在原PS域的会话。

本实施例MSC Server端判断CS域不支持Video媒体传输时,由MSCServer发起对多媒体会话的语音媒体的转移,进一步触发SCC AS将原网络域的Video媒体释放,实现在网络条件不允许的情况下,将多媒体会话将为语音会话的转移。

应用例二、

当MSC Server由于CS网络原因无法发起对视频会话的转移时,本实施例意在通过已建立的第一个会话的信令信道发送INFO消息,指示SCCAS第二个会话的无法转移指示消息及无法转移原因,SCC AS收到该消息后释放PS域的Video媒体,并再通过INFO消息指示MSC Server发起对语音媒体的转移。流程图如图5所示:

G1-G9a,与应用例一F1至F9a相同,不再赘述。

G9b,若当前网络不支持Video传输,则MSC Server发起INFO消息,该INFO消息在第一个会话建立的信道内传输,INFO消息中携带第二个会话无法转移指示。具体无法转移指示可以通过消息头或消息体携带,具体如下:

一、消息头携带:例如:在INFO消息的目的头subject中携带无法转移指示:由于subject头原意是指示通话的目的,因此,本实施例中,对subject头进行扩展,即INFO消息的目的是指示会话无法转移,并包含无法转移的原因,。

二、消息体携带:在INFO的消息体中指出INFO消息的所要传递的无法转移指示,以及具体无法转移原因“不支持视频(Video_not_supported)”或“资源不足(lack_resource)”。具体的消息体可以采用可扩展标记语言(ExtensibleMarkup Language,XML)格式,具体如下:

<?xml version=″1.0″?>

<ati xmlns=″urn:3gpp:ns:imscont:ati″>

<aes        i=″callIdOfSessionY″ lt=″UEATag″  rt″SCCASTag″lUri=″tel:+1-237-555-1111″rUri=″sip:UE3@operato r.net″s=″fail″

cause=″Video_not_supported/lack_resource″/>

</ati>

其中aes项描述了第二个session的相关信息,i属性表示第二个会话在PS域对话的Call-ID,lt属性表示本端(与该MSC Server对应端)的UE标识,rt属性表示对端UE标识,lUri表示本端UE身份标识,rUri表示对端UE身份表识,s表示转移状态可选项有:成功“success”、失败“fail”、重试“retry”,如果失败,则cause表示失败的原因,可能的原因有“Video_not_supported”或“lack_resource”。

INFO消息的accept头和Content-Type头设为application/vnd.3gpp.ati+xml。

G10b-G11b,INFO消息经过S-CSCF发送到SCC AS。

G12b-G13b,SCC AS收到INFO消息返回成功响应200 OK,200 OK经过S-CSCF发送到MSC Server。

G14b,SCC AS解析INFO消息的消息体的s字段和cause字段,发现由于上述原因导致多媒体会话不能成功转移,则将多媒体会话转换为语音会话进行转移,释放多媒体会话的video媒体过程同应用例一步骤F11b-F15b,并完成对端更新过程。当然,SCC AS可以选择不转移该会话而将会话释放,如果SCC AS释放会话,则直接执行步骤G20b。如果MSC Server在一定时间内没有收到INFO消息则不发起转移请求,而将第二个待转移会话的相关会话状态信息删除。

如果Video媒体释放成功,则SCC AS生成INFO消息,指示Video媒体已成功释放需要MSC Server重新发起对该会话语音媒体的转移请求。再次发起转移请求的指示可以在INFO消息的xml类型的消息体中或subject消息头指出,若在subject消息头给出,则在消息头写入“transFEr_voice”,若在消息体指出,消息体形式如下:

<?xml version=″1.0″?>

<ati xmlns=″urn:3gpp:ns:imscont:ati″>

<aes        i=″callIdOfSessionY″  lt=″UEATag″  rt=″SCCASTag″lUri=″tel:+1-237-555-1111″rUri=″sip:UE3@operator.net″

s=”retry”cause=”transfer_voice”/>

</ati>

G15b-G16b,INFO消息经过S-CSCF发送到MSC Server。

G17b-G18b,MSC Server收到INFO消息返回成功响应200 OK,200 OK经S-CSCF发送到SCC AS。

G19b,MSC Server收到INFO消息解析s字段和cause字段,并利用会话信息重新发起对该会话的转移请求Invite。

G20b,SCC AS收到MSC Server在CS域的转移请求,执行对端更新过程。

G21,SCC AS释放UE在原PS域会话。

本发明实施例中,SIP的Message的paper模式可以取代INFO消息完成上述操作,操作过程与上相同。如果SCC AS没有成功释放Video媒体,不必发送INFO消息通知MSC Server,进一步在原PS网络中将第二个会话释放。如果MSCServer在一定时间内没有收到INFO消息则不发起转移请求,而将第二个待转移会话的相关会话状态信息删除。

本实施例利用会话初始协议(SIP)的INFO(或Message消息paper模式)实现对转移失败信息的指示,以使得在网络情况不支持Video或网络资源不足的情况下,SCC AS将多媒体会话转换为语音会话,通过INFO或Message消息通知MSC Server,由MSC Server重新发起对语音会话的转移请求。由于INFO消息和paper模式的Message消息都在已建立的第一个会话信道内传输,假设MSC Server判断网络情况和与SCC AS交换信息的过程中,第一个会话不会被释放。

应用例三、

本应用例中,MSC Server订阅第二个会话的转移状态,获知会话是否转移成功,如果失败且失败的原因是由于目标网络无法传输视频媒体(video)则进一步释放Video媒体,并告知MSC Server发起对第二个待转移会话的语音媒体的转移。由于订阅请求不依赖于会话而存在,因此这里可以在第一个已建立会话信道内订阅,也可以新建立会话订阅。具体流程图如图6所示,包括:

H1-H7,同应用例一F1至F7的,在此不再赘述。

H8,SCC AS下发订阅请求(Subscribe),订阅UE相关事件则请求的request-URI为UE身份信息,订阅请求通过event头或请求消息体指明订阅事件,这里订阅事件为第二个待转移会话是否转移成功,设置event头为“second_transfer”。

请求的accept头指出所支持的Notify消息的消息体格式,此处使用xml类型,设为:“application/vnd.3gpp.ati+xml”。SCC AS可以只在第二个需转移的会话为多媒体会话时发出该订阅请求。此处省略了订阅成功相关的响应消息。

H9,订阅请求经过S-CSCF发送到MSC Server。

H10,MSC Server收到第二个待转移会话(多媒体会话)的会话状态信息,根据当前UE的网络状况判断是否支持Video传输。

H11a,若当前网络(网络状况或网络资源)支持Video传输,则按现有技术发起多媒体会话的转移请求。

H12a,第二个待转移会话(多媒体会话)转移成功,MSC Server发送Notify消息通知SCC AS。通知消息内容在Notify的xml格式消息体中体现,xml消息体格式为application/vnd.3gpp.ati+xml,见应用例二,s属性置位“success”。Cause属性置空。

H13a,Notify消息经过S-CSCF发送到SCC AS。

H14a,MSC Server与SCC AS在CS域的access leg建立成功,SCC AS更新对端。

H11b,MSC Server判断出当前网络无法转移video媒体,则生成转移失败的Notify消息,格式为application/vnd.3gpp.ati+xml,s属性为“fail”,cause写入无法转移第二个会话的原因“Video_not_supported”或“lack_resource”,具体含义同应用例二。

<?xml version=″1.0″?>

<ati xmlns=″urn:3gpp:ns:imscont:ati″>

<aes       i=″callIdOfSessionY″  lt=″UEATag″  rt=″SCCASTag″lUri=″tel:+1-237-555-1111″rUri=″sip:UE3@operator.net″s=”fail”cause=”Video_not_supported/lack_resource”/>

</ati>

application/vnd.3gpp.ati+xml格式的消息体中还包括转移会话的会话相关信息,此处Notify回复消息可以包括该会话信息(除“s”、“cause”属性外的其他项),以利于SCC AS执行判断和释放操作,也可以不包含会话信息而只包括属性s和cause,SCC AS知道订阅事件并根据保存的会话信息可以获知第二个待转移会话的会话信息。H12b,Notify消息被发送到S-CSCF。

H13b,Notify消息由S-CSCF发送到SCC AS。

H14b,SCC AS收到Notify消息,解析通知消息内容s和cause值域,获知由于上述原因导致多媒体会话无法转移成功,SCC AS选择将多媒体会话转换为语音会话则按应用例一步骤F11b-F15b在PS域释放Video媒体,并完成对端更新过程。或者SCC AS也可以选择不转移该会话而将会话释放,如果SCC AS释放会话,对Notify消息回复200OK,并更新对端后直接执行步骤H21。MSC Server在一定时间内没有收到重新发起请求的指示则不再发起转移请求,而将第二个待转移会话的相关会话状态信息删除。

H15b,SCC AS发出Notify的响应消息200OK,且如果SCC AS成功释放Video媒体,在200OK的消息体中指示MSC Server重新发起对该会话语音媒体的请求。消息体同应用例二:

<?xml version=″1.0″?>

<ati xmlns=″urn:3gpp:ns:imscont:ati″>

<aes    i=″callIdOfSessionY″lt=″UEATag″rt=″SCCASTag″lUri=″tel:+1-237-555-1111″rUri=″sip:UE3@operator.net″

s=”retry”cause=”transfer_voice”/>

</ati>

如果SCC AS释放Video媒体失败,则进一步尝试将第二个会话释放,而不向MSC Server发出任何指示信息。MSC Server在一定时间内没有收到重新发起请求的指示则不再发起转移请求,而将第二个待转移会话的相关会话状态信息删除。

H16b,200OK响应经S-CSCF发送到MSC Server。

H17b,MSC Server收到响应消息,通过解析消息体获知需要对发起语音媒体的转移请求。

H18b-H19b,转移成功则向SCC AS发送通知消息,具体消息内容同H12a中描述。

H20b,更新对端,完成UE和通信对端的会话连接。

H21,释放原PS网络会话。

SCC AS在一定时间后,可以取消与MSC Server的订阅关系。

本实施例通过SCC AS订阅第二个会话转移状态及接收MSC Server通知消息,在网络不允许多媒体会话转移的情况下触发SCC AS释放Video媒体,将多媒体会话转换为语音会话进行转移,由MSC Server再次对该会话的语音媒体发起转移,或SCC AS将第二个待转移会话释放而不进行转移。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成,该程序可以存储于一计算机可读存储介质中,存储介质可以包括:ROM、RAM、磁盘或光盘等。

实施例三、一种呼叫控制设备,结构示意图如图7所示,包括:

接收单元810,用于接收SCC AS发送的所述终端第二个待转移会话的状态信息;所述状态信息指示所述第二个待转移会话的媒体类型为视频类型;

会话转移控制单元820,用于判断会话转移的目标网络域是否能够传输视频数据,若无法传输,则向SCC AS发起对所述第二个待转移会话的语音媒体的转移请求,以使SCC AS收到该请求后,将所述第二个待转移会话转移转换为语音会话或者释放所述第二个待转移会话。

本实施例中的呼叫控制设备,在对用户的第二个待转移会话进行转移时,若发现目标网络域无法支持视频数据传输,则直接向请求所述SCC AS发起对所述第二个待转移会话的语音媒体的转移请求,例如:将请求中的媒体行信息中的视频媒体传输端口号置0,仅请求语音媒体的转移,这样SCC AS在收到该请求后,则可以将所述第二个待转移会话转换为语音会话进行转移或者释放所述第二个待转移会话。以避免现有技术中出现的网络无法完成会话转移的问题,使得跨网络的多会话转移业务更加完善。

实施例四,一种呼叫控制设备,结构示意图如图8所示,包括:

接收单元910,用于接收SCC AS发送的所述终端第二个待转移会话的状态信息;所述状态信息包含所述第二个待转移会话的媒体类型,所述媒体类型包含视频类型;

会话转移控制单元920,用于判断会话转移的目标网络域是否可以传输视频数据,若不可以,则向SCC AS发起所述第二个待转移会话转移失败指示,以使SCC AS收到该请求后,将所述第二个待转移会话转移转换为语音会话或者释放所述第二个待转移会话。

本实施例中的呼叫控制设备,在对用户的第二个待转移会话进行转移时,若发现目标网络域无法支持视频数据传输,则直向SCC AS发起所述第二个待转移会话转移失败指示,以使得SCC AS收到所述失败指示,进行后续处理。以避免现有技术中出现的网络无法完成会话转移的问题,使得跨网络的多会话转移业务更加完善。

实施例三和实施例四的呼叫控制设备可以是电路交换网络中具有呼叫控制功能的网络实体,如:移动交换中心服务器或者类似的设备。

实施例五、一种业务连续性服务器,结构示意图如图9所示,包括:

发送单元1010,用于向终端所属的所述移动交换中心服务器发送所述终端第二个待转移会话的状态信息;所述状态信息包含所述第二个待转移会话的媒体类型,所述媒体类型包含视频类型;

会话处理单元1020,用于在接收到所述移动交换中心服务器发起的对所述第二个待转移会话的语音媒体的转移请求,将所述第二个待转移会话转换为语音会话进行转移或者释放所述第二个待转移会话。

本发明实施例提供的呼叫控制设备和业务连续性服务器可以运行的方法,可参考上文对本发明提供的提供多个方法实施例的描述,在此不再重复。

实施例六、一种业务连续性服务器,结构示意图如图10所示,包括:

发送单元1110,用于向终端所属的移动交换中心服务器发送所述终端第二个待转移会话的状态信息;所述状态信息指示所述第二个待转移会话的媒体类型为视频类型;

会话处理单元1120,用于接收所述移动交换中心服务器因为目标网络域无法传输视频数据而发送的所述第二个待转移会话转移失败指示,将第二个待转移会话转移转换为语音会话进行转移或者释放所述第二个待转移会话。

以上对本发明实施例所提供的多会话转移方法及呼叫控制设备和业务连续性服务器进行了详细介绍,本文中应用了具体个例对本发明的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本发明的方法及其核心思想;同时,对于本领域的一般技术人员,依据本发明的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本发明的限制。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号