CN101686192A - 在多设备环境中进行会话处理方法、装置和系统 - Google Patents
在多设备环境中进行会话处理方法、装置和系统 Download PDFInfo
- Publication number
- CN101686192A CN101686192A CN200810223205A CN200810223205A CN101686192A CN 101686192 A CN101686192 A CN 101686192A CN 200810223205 A CN200810223205 A CN 200810223205A CN 200810223205 A CN200810223205 A CN 200810223205A CN 101686192 A CN101686192 A CN 101686192A
- Authority
- CN
- China
- Prior art keywords
- session
- equipment
- response message
- called subscriber
- selection information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Telephonic Communication Services (AREA)
Abstract
本发明提供了一种在多设备环境中进行会话处理的方法、装置和系统,该方法主要包括:向多设备环境下的被叫用户的设备发送会话邀请请求;接收所述被叫用户的设备返回的应答消息,对所述应答消息进行解析,获取所述应答消息中携带的会话建立方式的选择信息,根据该会话建立方式的选择信息进行相应的会话处理。利用本发明,可以实现在多设备环境下的会话建立过程中,根据用户实时输入的用户意愿来执行不同的会话处理逻辑,从而提高了业务服务器的处理能力和网络服务质量。
Description
技术领域
本发明涉及通信技术领域,尤其涉及一种在多设备环境中进行会话处理的方法、装置和系统。
背景技术
近年来,出现了各种在用户之间传送数据、语音、视频等媒体信息的通信技术,电信网运营商和互联网服务提供商也随之提供了各种新型、多样的应用和业务,以吸引用户。
SIP(会话发起协议,Session Initiation Protocol)协议是一个应用层控制(信令)协议,可用来创建、修改和终结一个或者多个参与者之间的多媒体会话。通过SIP协议,用户可以邀请其他参与者加入一个已经存在的会话或者创建一个新的会话,还可以动态地修改会话媒体。
当前,为一个业务用户的地址绑定多个设备,并为每个设备提供一个全局可路由的GRUU(终端设备标识符),该GRUU为设备在网络层的地址标识。用户利用该多个设备进行业务通信逐渐成为个人通信技术的一个发展方向和重要需求。
现有技术中的一种基于SIP/IP核心网的业务用户之间的会话的建立过程如图1所示,具体处理过程包括如下步骤:
步骤11-12、当业务用户A想要和业务用户B建立会话时,业务用户A经SIP/IP核心网A向业务服务器A发送会话邀请请求。
上述SIP/IP核心网负责SIP请求和应答的路由,业务服务器负责处理具体的业务逻辑(如,存储用户的业务相关信息、SIP请求的鉴权、创建和管理会话等等),业务用户负责发起和接收SIP请求、传送和接收媒体等。
步骤13-15、业务服务器A根据其业务逻辑处理上述业务用户A发送过来的会话邀请请求,然后,将该会话邀请请求经SIP/IP核心网A转发到SIP/IP核心网B,SIP/IP核心网B再将该会话邀请请求转发至和业务服务器A对等的业务服务器B。
步骤16-17、业务服务器B根据其业务逻辑处理其收到的上述会话邀请请求,并将该会话邀请请求经SIP/IP核心网B转发给业务用户B。
步骤18-114、业务用户B接收到上述SIP/IP核心网B转发过来的会话邀请请求后,如果接受该会话邀请请求,则构造成功应答(SIP 200 OK应答)消息,该成功应答消息经业务服务器B、SIP/IP核心网B、SIP/IP核心网A、业务服务器A返回给业务用户A。
步骤115-121、业务用户A接收到上述成功应答消息后,生成该成功应答消息的确认消息(SIP ACK消息),并将该成功应答消息经业务服务器A、SIP/IP核心网A、SIP/IP核心网B、业务服务器B发送给业务用户B。
步骤122、至此,业务用户A和业务用户B之间的会话建立完毕,业务用户双方开始利用会话传输媒体。
在实现本发明过程中,发明人发现上述现有技术中至少存在如下问题:上述基于SIP/IP核心网的业务用户之间的会话的建立过程只适用于单设备环境。当被叫方用户拥有多个设备时,该过程没有明确地描述主被叫用户之间如何建立会话。
发明内容
本发明的实施例提供了一种在多设备环境中进行会话处理的方法、装置和系统,以解决当被叫方用户拥有多个设备时,主被叫用户之间如何建立会话的问题。
一种在多设备环境中进行会话处理的方法,包括:
向多设备环境下的被叫用户的设备发送会话邀请请求;
接收所述被叫用户的设备返回的应答消息,对所述应答消息进行解析,获取所述应答消息中携带的会话建立方式的选择信息,根据该会话建立方式的选择信息进行相应的会话处理。
一种在多设备环境中进行会话处理的装置,包括:
会话邀请请求发送模块,用于向多设备环境下的被叫用户的设备发送会话邀请请求;
选择信息获取模块,用于接收所述被叫用户的设备返回的应答消息,对所述应答消息进行解析,获取所述应答消息中携带的会话建立方式的选择信息;
会话处理模块,用于根据所述选择信息获取模块所获取的会话建立方式的选择信息,进行相应的会话处理。
一种在多设备环境中进行会话处理的系统,包括:如权利要求10到12任一项所述的装置和被叫用户的设备,
所述装置,用于向多设备环境下的被叫用户的设备发送会话邀请请求,接收所述被叫用户的设备返回的应答消息,对所述应答消息进行解析,获取所述应答消息中携带的会话建立方式的选择信息,根据所述选择信息获取模块所获取的会话建立方式的选择信息,进行相应的会话处理;
所述被叫用户的设备,用于接收所述装置发送的会话邀请请求,向所述装置发送携带会话建立方式的选择信息的应答消息。
由上述本发明的实施例提供的技术方案可以看出,本发明实施例通过在被叫用户的设备返回的应答消息中携带的会话建立方式的选择信息,可以实现在多设备环境下的会话建立过程中,根据用户实时输入的用户意愿来执行不同的会话处理逻辑,从而提高了业务服务器的处理能力和网络服务质量。
附图说明
为了更清楚地说明本发明实施例的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1为现有技术中的一种基于SIP/IP核心网的业务用户之间的会话的建立过程示意图;
图2为本发明实施例一提供的一种基于用户动态输入的选择信息来建立会话的方法的处理流程图;
图3为本发明实施例二提供的一种通知其他设备关于某设备成功接受会话邀请请求和成功建立会话的信息的方法的处理流程图;
图4为本发明实施例三提供的一种基于用户动态输入的选择信息进行会话建立的方法的处理流程图;
图5为本发明实施例三提供的一种基于“高优先级设备优先”机制进行会话建立的方法的处理流程图;
图6为本发明实施例四提供的多设备会话邀请处理状态集的树形存储结构示意图;
图7为本发明实施例四提供的一种通知其他设备关于某设备成功接受会话邀请请求和成功建立会话的信息的方法的处理流程图;
图8为本发明实施例五提供的一种在多设备环境中实现会话建立的方法的处理流程图;
图9为本发明实施例六提供的一种在多设备环境中实现会话建立的方法的处理流程图;
图10为本发明实施例七提供的一种在多设备环境中实现会话建立的方法的处理流程图;
图11为本发明实施例八提供的一种在多设备环境中实现会话建立的方法的处理流程图;
图12为本发明实施例提供的一种在多设备环境中进行会话处理的装置的具体实现结构图。
具体实施方式
在本发明实施例中,分别向多设备环境下的被叫用户的各个设备发送会话邀请请求,在接收到所述被叫用户的设备返回的应答消息后,对所述应答消息进行解析,获取所述应答消息中携带的会话建立方式的选择信息,根据该会话建立方式的选择信息进行相应的会话处理。
进一步地,在会话邀请请求中携带会话邀请请求被发送到被叫用户的多个同址设备的指示信息。
进一步地,被叫用户的设备在收到所述会话邀请请求后,检查出该会话邀请请求中包含所述会话邀请请求被发送到多个同址设备的指示信息。所述被叫用户根据当前意愿和所述指示信息选择会话建立方式,所述被叫用户的设备向所述业务服务器发送携带所述会话建立方式的选择信息的应答消息。
进一步地,所述会话建立方式包括:接受、仅在此设备上接受、仅在此设备上拒绝和在本设备和其他设备上全部拒绝。
进一步地,当所述业务服务器获取的会话建立方式的选择信息为接受时,所述业务服务器将所述应答消息转发给主叫用户,不向所述被叫用户的其它设备发送会话取消请求,所述主叫用户和返回所述应答消息的被叫用户的设备之间进行会话建立;
当所述业务服务器获取的会话建立方式的选择信息为仅在此设备上接受时,业务服务器将所述应答消息转发给主叫用户,向所述被叫用户的其它设备发送会话取消请求,所述主叫用户和返回所述应答消息的被叫用户的设备之间进行会话建立;
当所述业务服务器获取的会话建立方式的选择信息为仅在此设备上拒绝时,业务服务器不将所述应答消息转发给主叫用户,不向所述被叫用户的其它设备发送会话取消请求,所述主叫用户和返回所述应答消息的被叫用户的设备之间不进行会话建立;
当所述业务服务器获取的会话建立方式的选择信息为在本设备和其他设备上全部拒绝时,业务服务器将所述应答消息转发给主叫用户,向所述被叫用户的其它设备发送会话取消请求,所述主叫用户和返回所述应答消息的被叫用户的设备之间不进行会话建立。
进一步地,当在小于设定时间内接收到多个所述被叫用户的设备返回的多个应答消息时,根据第一个接收到的应答消息中携带的会话建立方式的选择信息,进行相应的会话处理,
如果后续接收到的应答消息中携带的会话建立方式的选择信息与所述第一个接收到的应答消息中携带的会话建立方式的选择信息不互相冲突,则对后续接收到的应答消息进行相应的处理;否则,对后续接收到的应答消息不处理。
进一步地,当在小于设定时间内接收到多个所述被叫用户的设备返回的多个应答消息时,根据优先级最高的设备返回的应答消息中携带的会话建立方式的选择信息,进行相应的会话处理,
如果优先级不是最高的设备返回的应答消息中携带的会话建立方式的选择信息与所述优先级最高的设备返回的应答消息中携带的会话建立方式选择信息不互相冲突,则对优先级不是最高的设备返回的应答消息进行相应的处理;否则,对优先级不是最高的设备返回的应答消息不处理。
进一步地,在将会话邀请请求发送给被叫用户的多个设备后,为该会话邀请请求建立并维护多设备会话邀请处理状态集,该多设备会话邀请处理状态集中包括主叫用户信息、被叫用户信息、主被叫用户之间请求建立的会话的标识信息、已经返回过所述会话邀请请求的应答消息的被叫用户的设备信息和被发送过会话取消请求的被叫用户的设备信息;
当接收到被叫用户的某个设备返回的携带接受会话邀请请求的选择信息的应答消息后,向所述被叫用户的其它设备发送通知消息,该通知消息中携带所述某个设备接受会话邀请请求的信息;并且,当根据所述多设备会话邀请处理状态集判断所述其它设备没有返回过所述会话邀请请求的应答消息或没有被发送过会话取消请求时,所述通知消息中还携带会话建立方式的选择信息。
利用本发明实施例,可以实现在多设备环境下的会话建立过程中,根据用户实时输入的用户意愿并结合相关策略来执行不同的应答处理逻辑,向其他设备发送关于某设备成功接受应答和成功建立会话的通知信息,该通知消息中还可以携带会话建立方式的选择信息。
为便于对本发明实施例的理解,下面将结合附图以几个具体实施例为例做进一步的解释说明,且各个实施例并不构成对本发明实施例的限定。
实施例一
在该实施例中,不是基于静态设置的策略(如业务运营商策略、存储于网络中的用户偏好、设备能力集等),而是基于用户当前实时意愿来建立会话。
该实施例提供的基于用户动态输入的选择信息来建立会话的方法的处理流程如图2所示,包括如下步骤:
步骤21、当业务服务器收到发向其所服务的被叫用户的会话邀请请求;或者,业务服务器根据业务逻辑需要向其所服务的被叫用户发送会话邀请请求时,该业务服务器查询用户注册信息数据库,判断上述被叫用户的地址拥有多设备环境,即该被叫用户绑定了多个注册设备。
步骤22、业务服务器向上述被叫用户的多个设备发送会话邀请请求,并在会话邀请请求中包含扩展的SIP头域,在该SIP头域中携带“会话邀请请求被发送到多个同址设备”的指示信息。
步骤23、上述被叫用户的各个设备收到会话邀请请求后,获取该会话邀请请求中的“会话邀请请求被发送到多个同址设备”的指示信息。
在上述被叫用户的各个设备的客户端程序中需要增加一些实现代码,使得各个设备在收到上述指示信息时,在用户界面向用户提示可供“选择”的几种会话建立方式信息。
步骤24、被叫用户基于其当前的实时意愿,在各个设备上动态输入选择项以接受或拒绝会话邀请请求,各个设备的客户端程序基于该选择项代表的会话建立方式的选择信息构造应答消息,并将会话建立方式的选择信息包含在应答消息的扩展SIP头域中。
被叫用户的各个设备将上述应答消息发送给业务服务器。
步骤25、业务服务器收到被叫用户的各个设备发送的应答消息后,解析该应答消息的扩展SIP头域中携带的会话建立方式的选择信息,以根据用户的实时意愿,并结合相关静态设置的策略,执行不同的应答处理逻辑,完成会话建立/结束流程。
该实施例实现了在多设备环境下,在会话建立时根据用户实时输入的用户意愿并结合相关策略来执行不同的应答处理逻辑。
实施例二
在多设备环境下,为了将一个用户的某设备成功接受会话邀请请求和成功建立会话的信息通知给该用户的其他同址设备,以优化业务逻辑和丰富用户体验,该实施例提出的一种通知其他设备关于某设备成功接受会话邀请请求和成功建立会话的信息的方法的处理流程如图3所示,包括如下处理步骤:
步骤31、当接受会话邀请请求的被叫用户的地址拥有多设备环境时,业务服务器为该会话邀请请求创建一个多设备会话邀请处理状态集,用于记录上述被叫用户的各个设备处理会话邀请请求的情况。
步骤32、当业务服务器收到上述被叫用户的某个设备返回的上述会话邀请请求的应答消息,或者向被叫用户的某个设备发送对应上述会话邀请请求的会话取消请求时,业务服务器更新上述多设备会话邀请处理状态集,以更新各个设备对会话邀请请求的处理状态。
步骤33、当业务服务器收到上述被叫用户的某设备返回的上述会话邀请请求的成功应答消息,或者确定被叫用户的某设备与主叫方成功建立了会话时,业务服务器向被叫用户的其它设备发送关于此信息的通知消息。
此时,业务服务器根据多设备会话邀请处理状态集,将被叫用户的各个设备划分为两种类型的设备:未处理会话邀请请求的设备和已处理会话邀请请求的设备,其中,未处理会话邀请请求的设备包括:没有返回过应答消息且没有被发送过会话取消请求的设备,已处理会话邀请请求的设备包括:返回过应答消息或者被发送过会话取消请求的设备。
业务服务器准备给不同类型的设备分别发送包含不同内容的通知消息。
步骤34a.对于已处理会话邀请请求的设备,业务服务器向其发送以简单文本信息作为消息体的通知消息,该简单文本信息描述了某设备“成功接受应答”/“成功建立会话”的信息。
步骤34b.对于未处理会话邀请请求的设备,业务服务器向其发送携带扩展头域的通知消息,且该通知消息的消息体中包含可供用户选择的会话建立方式信息。该设备的客户端将此信息提示给用户选择,并向业务服务器发送包含该用户的选择信息的应答消息。
业务服务器根据应答消息中的选择信息来执行不同的应答处理逻辑和会话建立/结束处理流程。
实施例三
该实施例进一步详细描述了基于用户动态输入的选择信息进行会话建立的方案。在该实施例中,对SIP中的Subject头域、业务服务器逻辑、业务客户端逻辑进行扩展。
1、对SIP中的Subject头域进行扩展。
SIP中的Subject头域用于指示呼叫的概要信息,例如指示呼叫的目的用户、消息发送者的逻辑用户身份等,本发明实施例通过对Subject头域进行扩展,以携带在多设备环境下关于会话建立的相关信息。
在扩展后的Subject头域中携带“会话邀请请求被发送到多个设备”的指示信息,例如,扩展后的Subject头域值为:Subject:An Invitation to multiple devices;purpose=multi-devices”,其中参数purpose=multi-devices用于指示多设备环境。在业务服务器给被叫用户的各个设备发送的会话邀请请求中携带该扩展后的Subject头域。
在扩展后的Subject头域中携带包含用户动态输入的选择信息,例如,扩展后的Subject头域值是下述头域值的一种:
“Subject:1接受;purpose=multi-devices”;
“Subject:2仅在此设备上接受:purpose=multi-devices”;
“Subject:3仅在此设备上拒绝;purpose=multi-devices”;
“Subject:4在本设备和其他设备上全部拒绝;purpose=multi-devices”。
在被叫用户的各个设备给业务服务器发送的对于会话邀请请求的应答消息中携带该扩展后的Subject头域。
2、扩展业务服务器的业务逻辑
在被叫用户处于多设备环境下时,业务服务器在构造的会话邀请请求中包含上述扩展后的Subject头域,该扩展后的Subject头域中携带“会话邀请请求被发送到多个同址设备”的指示信息。然后,业务服务器将上述构造的会话邀请请求发送给被叫用户的各个设备。
业务服务器在收到被叫用户的设备返回的上述会话邀请请求的应答消息后,获取和解析应答消息中包含的扩展后的Subject头域值,并根据该扩展后的Subject头域中携带的用户动态输入的选择信息,执行不同的应答处理逻辑,以完成会话建立/结束流程。上述业务服务器执行的不同的应答处理逻辑包括:
当用户动态输入的选择信息为“接受”时,业务服务器接收成功应答消息并转发至主叫方,且不向被叫用户的其他设备发送会话取消请求;
当用户动态输入的选择信息为“仅在此设备上接受”时,业务服务器接收成功应答消息并转发至主叫方,且向被叫用户的其他设备发送会话取消请求;
当用户动态输入的选择信息为“仅在此设备上拒绝”时,业务服务器接收失败应答消息但不转发至主叫方,且不向被叫用户的其他设备发送会话取消请求;
当用户动态输入的选择信息为“在本设备和其他设备上全部拒绝”时,业务服务器接收失败应答消息并转发至主叫方,且向被叫用户的其他设备发送会话取消请求。
3、扩展业务客户端的业务逻辑。
被叫用户的设备在收到业务服务器发送的会话邀请请求时,检查该会话邀请请求中是否包含扩展的Subject头域,如果存在且值为“Subject:An Invitation to multiple devices;purpose=multi-devices”,则该被叫用户的设备的用户界面提示如下选择信息:
主叫方想与您建立会话,请选择:
1、接受;
2、仅在此设备上接受;
3、仅在此设备上拒绝;
4、在本设备和其他设备上全部拒绝。
当被叫用户在用户界面上选择上述于1、2选项时,该被叫用户的设备构造成功应答消息,当被叫用户在用户界面上选择上述于3、4选项时,该被叫用户的设备构造失败应答消息。被叫用户的设备将上述选择信息携带在成功/失败应答消息中的Subject头域中。
基于上述扩展,该实施例提供的一种基于用户动态输入的选择信息进行会话建立的方法的处理流程如图4所示,包括如下处理步骤:
步骤41、在被叫方用户处于多设备环境下时,业务服务器为该被叫方用户的各个选定设备构造出会话邀请请求,在该会话邀请请求中包含扩展的Subject头域,其值为“An Invitation to multipledevices;purpose=multi-devices”以指示“会话邀请请求被发送到多个同址设备”。
在该会话邀请请求中还使用GRUU机制标识出选定设备的设备地址。
步骤42、业务服务器将此上述构造的会话邀请请求发送到被叫方的各个选定设备。
步骤43、被叫方的各选定设备收到上述会话邀请请求后,检查到该会话邀请请求包含Subject头域且值为“An Invitation to multiple devices;purpose=muiti-devices”,则在各选定设备的用户界面提供可供用户选择的会话建立方式信息。
被叫方用户根据自身当前意愿,在各选定设备的用户界面上选择相应的会话建立方式信息,比如,在其某个或某些设备上选择接受会话邀请或拒绝会话邀请,然后由各选定设备的业务客户端程序根据用户的选择信息构造成功/失败应答消息,并将选择信息包含在成功/失败应答消息中的Subject头域。
步骤44、业务服务器收到某设备(假设为设备1#)返回的对应上述会话邀请请求的应答消息时,将解析出该应答消息的Subject头域中所携带的用广动态输入的选择信息,并根据该选择信息执行不同的应答处理逻辑。
44a1、当业务服务器收到设备1#返回的成功应答消息,且解析出成功应答消息中包含的选择信息为“接受”;
44a2、业务服务器将上述成功应答消息转发到主叫方,并将主叫方随后发送的上述成功应答消息的确认请求转发到设备1#。
44b1、业务服务器收到设备1#返回的成功应答消息,且解析出应答包含的选择信息为“仅在此设备上接受”;
44b2、业务服务器将该成功应答消息转发到主叫方,并将主叫方随后发送的上述成功应答消息的确认请求转发到设备1#;以在该设备与主叫方之间建立会话;
44b3.业务服务器向被叫用户的其他设备发送会话取消请求,以取消其先前发送到这些设备的会话邀请请求;
44b4、业务服务器接收其他设备返回的会话取消请求的应答消息。
44c1、业务服务器收到设备1#返回的失败应答消息,且解析出该失败应答消息中包含的选择信息为“仅在此设备上拒绝”,则业务服务器终止该设备的会话建立流程,且不向主叫方返回失败应答,不向其他设备发送会话取消请求。此时,业务服务器等待其他设备返回应答消息并按照上述处理流程进行处理,业务服务器可以向主叫方发送临时应答消息“会话处理中”。
44d1、业务服务器收到设备1#返回的失败应答消息,且解析出该失败应答消息中包含的选择信息为“在本设备和其他设备上全部拒绝”,则业务服务器终止该设备的会话建立流程。并将该失败应答消息转发给主叫方,以结束被叫方与主叫方正在进行的会话建立流程;
44d2、业务服务器向被叫用户的其它设备发送会话取消请求,以取消其先前发送到这些设备的会话邀请请求;
44d3、业务服务器接收其他设备返回的会话取消请求的应答消息。
在某些情况下,单个逻辑用户的多个设备可能被多人操作,比如,逻辑用户的手机终端为逻辑用户本人随身携带,而固定电话终端放在家中且其本人不在家中,或者逻辑用户同时在两个或多个设备上处理会话邀请请求,那么两个或多个同址设备可能几乎同时返回成功或失败应答消息,而同时返回的应答消息中包含不同的选择信息,可能会引起业务服务器执行应答处理逻辑时的冲突。
因此,该实施例还提供了一种在两个或多个设备几乎同时返回应答消息的情况下的冲突处理机制。该冲突处理机制包括:“先来先服务”机制或“高优先级设备优先”机制。
(1)、“先来先服务”机制
虽然对于多个设备来讲,应答几乎是同时返回的,但对于业务服务器来讲,总是有且仅有一个应答消息在“第一时刻”最先返回。在本机制下,业务服务器遵循“先来先服务”原则,对于最先收到的应答消息进行立即处理,对于后续到来的应答消息进行适当处理或不处理,业务服务器的具体处理过程可以包括如下过程:
1、如果“第一时刻”返回的应答消息中的选择信息为“接受”,随后的几乎同时到达的应答消息中的选择信息为“仅在此设备上接受”,则业务服务器为先返回应答消息的设备执行会话建立流程,对于后返回应答消息的设备也执行会话建立流程;
如果随后的几乎同时到达的应答消息中的选择信息为“仅在此设备上拒绝”,则业务服务器按照正常流程为先返回应答消息的设备执行会话建立流程,为后返回应答消息的设备终止会话邀请事务;
如果随后的几乎同时到达的应答消息中的选择信息为“在本设备和其他设备上全部拒绝”,则业务服务器为先返回应答消息的设备执行会话建立流程,为后返回应答消息的设备终止会话邀请事务,且向不包含上述两个设备的其他设备发送会话取消请求。
2、如果“第一时刻”返回的应答消息中的选择信息为“仅在此设备上接受”,随后的几乎同时到达的应答消息中的选择信息为“接受”,则业务服务器为先返回应答消息的设备执行会话建立流程,向其他设备发送会话取消请求。忽略后返回的应答消息,不处理该应答消息。
如果随后的几乎同时到达的应答消息中的选择信息为“仅在此设备上拒绝”或者“在本设备和其他设备上全部拒绝”,则同样忽略此后到达的应答消息,不处理该后到达的应答消息。
3、如果“第一时刻”返回的应答消息中的选择信息为“仅在此设备上拒绝”,随后的几乎同时到达的应答消息中的选择信息为“接受”,则业务服务器为先返回应答消息的设备终止会话邀请事务,为后返回应答消息的设备执行会话建立流程;
如果随后的几乎同时到达的应答消息中的选择信息为“仅在此设备上接受”,则业务服务器为先返回应答消息的设备终止会话邀请事务,为后返回应答消息的设备执行会话建立流程,且向不包括上述两个设备的其他设备发送会话取消请求;
如果随后的几乎同时到达的应答消息中的选择信息为“在本设备和其他设备上全部拒绝”,则业务服务器为先返回应答消息的设备终止会话邀请事务,为后返回应答消息的设备终止会话邀请事务,且向不包括上述两个设备的其他设备发送会话取消请求;
4、如果“第一时刻”返回的应答消息中的选择信息为“在本设备和其他设备上全部拒绝”,随后的儿乎同时到达的应答消息中的选择信息为“接受”,则业务服务器为先返回应答消息的设备终止会话邀请事务,向其它设备发送会话取消请求,忽略后到达的应答消息,不处理该后到达的应答消息;
如果随后的几乎同时到达的应答消息中的选择信息为“仅在此设备上接受”或者“仅在此设备上拒绝”,则同样忽略此后到达的应答消息,不处理该后到达的应答消息。
(2)、“高优先级设备优先”机制
当多个设备几乎同时返回应答消息时,可能由于通信线路原因,“第一时间”到达的应答消息可能并不代表逻辑用户的实时意愿。对于业务服务器来讲,可以为其提供一种“高优先级设备优先”的应答处理机制,以根据设备的优先级标识来处理各个设备同时返回的应答消息。
当收到第一个设备返回的应答消息时,业务服务器设置一个多设备应答等待时间(例如1s),在此时间内,如果有其他设备返回的应答消息到达,而且两个应答消息所包含的用户意愿出现冲突时,则业务服务器从应答消息中的Contact头域中或者在本地存储的用户注册信息库中获取设备的优先级标识符,比较该两个设备的优先级标识符的高低,并优先处理最高优先级设备所返回的应答消息,而忽略其他设备返回的应答消息;在此时间内,如果没有其他设备返回的应答消息到达,则只处理第一个设备返回的应答消息。
该实施例提供的一种基于“高优先级设备优先”机制进行会话建立的方法的处理流程如图5所示,包括如下处理步骤:
步骤51、在被叫方用户处于多设备环境下时,业务服务器为该被叫方用户的各个选定设备构造出会话邀请请求,在该会话邀请请求中包含扩展的Subject头域,其值为“An Invitation to multipledevices;purpose=multi-devices”以指示“会话邀请请求被发送到多个同址设备”。
在该会话邀请请求中还使用GRUU机制标识出选定设备的设备地址。
步骤52、业务服务器将此上述构造的会话邀请请求发送到被叫方的各个选定设备。
步骤53、被叫方的各选定设备收到上述会话邀请请求后,检查到该会话邀请请求中包含Subject头域且值为“An Invitation to multiple devices;purpose=multi-devices”,则在各选定设备的用户界面提供可供用户选择的会话建立方式信息。
被叫方用户根据自身当前意愿,在各选定设备的用户界面上选择相应的会话建立方式信息,比如,在其某个或某些设备上选择接受会话邀请或拒绝会话邀请,然后由各选定设备的业务客户端程序根据用户的选择信息构造成功/失败应答消息,并将选择信息包含在成功/失败应答消息中的Subject头域。
步骤54、业务服务器收到某设备(假设为设备1#)返回的对应上述会话邀请请求的应答消息时,将解析出该应答消息的Subject头域中所携带的用户动态输入的选择信息。
步骤55、如果业务服务器采取“高优先级设备优先”机制来处理应答,则启动一个多设备应答等待时间T的计时,以等待接收其他设备返回的应答。
步骤6a1、在时间段T内,业务服务器接收到其他设备返回的对应会话邀请请求的应答消息(第二个、第三个…)。
步骤6a2、上述多设备应答时间T的计时时间到达,业务服务器停止等待其他设备返回的应答消息。
步骤6a3、业务服务器检查各个设备返回的各个应答消息之间是否存在冲突,即是否存在以下应答消息同时被返回的情况:“接受”和“仅在此设备上接受”、“接受”和“在本设备和其他设备上全部拒绝”、“仅在此设备上接受”和“在本设备和其他设备上全部拒绝”。如果存在上述冲突情况,则比较返回应答消息的各个设备的优先级,然后,选择最高优先级设备返回的应答消息来处理;如果不存在上述冲突情况,则按照正常流程执行各个互相不冲突的应答消息。
步骤66b、多设备应答时间T的计时时间到达,业务服务器停止等待其他设备返回的应答。由于业务服务器没有收到其他设备在此时间段内返回的应答消息,则处理其接收到的第一个应答消息。
实施例四
该实施例进一步详细描述了其他设备关于某设备成功接受应答和成功建立会话的信息的方案。在该实施例中,需要建立多设备会话邀请处理状态集,并且对业务服务器逻辑、业务客户端逻辑进行扩展。
(1)多设备会话邀请处理状态集
业务服务器在判断会话邀请请求的被叫用户为多设备环境时,便为该会话邀请请求建立多设备会话邀请处理状态集。该多设备会话邀请处理状态集主要用于判断哪些接收会话邀请请求的设备已经返回终结应答或者被发送过会话取消请求,以将被叫方的多个设备分为“已处理会话邀请请求的设备”和“未处理会话邀请请求的设备”。
上述多设备会话邀请处理状态集的树形存储结构如图6所示,其中:
根元素multi-devices包含三个属性:主叫用户的地址、被叫用户的地址和主被叫用户之间请求建立的会话的标识session-id(都从会话邀请请求中获得);
根元素multi-devices包含子元素:device(设备)元素,每个device元素代表一个被发送了会话邀请请求的被叫用户的设备,device由属性“设备标识”来唯一标识,而“设备标识”的值从用户注册信息中获取,例如从gr参数中获取。
每个device元素又包含如下子元素:
1、“设备优先级”用于描述该设备在会话邀请请求中所处的优先级,用数字0~1来标识,其中1代表最高优先级,该信息可以从用户注册信息中获取;
2、“应答类型”用于描述该设备返回的对应会话邀请请求的应答消息的类型,包括接受”、“仅在此设备上接受”和“仅在此设备上拒绝”等应答类型;
3、“是否正参与该会话”用于描述该设备是否正在参与该会话,使用BOOL类型(TRUE或FALSE)标识;
4、“是否被发送过会话取消请求”用于描述该设备是否被业务服务器发送过会话取消请求(即SIPCANCEL请求),使用BOO L类型(TRUE或FALSE)标识。
业务服务器对多设备会话邀请处理状态集的处理过程为:
业务服务器基于会话邀请请求创建多设备会话邀请处理状态集,该多设备会话邀请处理状态集中包含的初始信息包括:主叫方和被叫方用户地址以及主被叫之间的会话标识、被发送会话邀请请求的设备(设备标识),可选的包含设备优先级。
当业务服务器收到被叫方用户的某设备返回的应答消息时,更新该设备在多设备会话邀请处理状态集中的“应答类型”项;当被叫用户的某设备被发送会话取消请求时,更新其在多设备会话邀请处理状态集中的“是否被发送过会话取消请求”项;当被叫用户的某设备与主叫方成功建立起会话后,更新其在多设备会话邀请处理状态集中的“是否正参与该会话”项;当由session-id标识的被叫用户与主叫用户之间的会话结束后,删除多设备会话邀请处理状态集。
在具体实施时,多设备会话邀请处理状态集可以由业务服务器存储于数据库中,或者采用XML(Extensible Markup Language,可扩展标记语言)文档的形式。下面例子展示了使用XML文档形式描述的多设备会话邀请处理状态集,其中,黑体部分表示多设备会话邀请处理状态集在被创建时的表结构,其余元素在后续过程中由业务服务器根据各设备返回的应答及其是否为该设备发送过会话取消请求,进行相应更新。
<multi-devices invitee=″alice@homel.net″;session-id=″s34ad″;invitor=″bob@home2.net″>
<device gr=″urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6″>
<priority>1<priority> //该设备优先级标识符
<response>200<response> //该设备返回的对应该会话邀请请求的应答类型
<session-ongoing>yes<session-ongoing> //该设备是否参与该会话(可选的)
<CANCEL-sent>no<CANCEL-sent> //是否发送过CANCE请求给该设备
<device>
<device gr=″urn:uuid:h90d4fae-8dec-33d0-a432-01b0d92d6cf8″>
<priority>0.6<priority>
<response>404<response>
<session-ongoing>no<session-ongoing>
<CANCEL-sent>no<CANCEL-sent>
<device>
<device gr=″urn:uuid:e85d4fae-4dec-33d0-a654-03a0c92c6gf4″>
<priority>0.4<priority>
<response>408<response>
<session-ongoing>no<session-ongoing>
<CANCEL-sent>yes<CANCEL-sent>
<device>
<multi-devices>
(2)扩展业务服务器的业务逻辑
业务服务器为每个会话邀请请求创建和维护一个多设备会话邀请处理状态集,当收到某设备返回的对应会话邀请请求的应答消息或者向某设备发送会话取消请求时,更新该设备在多设备会话邀请处理状态集中的状态信息。
当拥有多设备环境的被叫用户的某个设备返回成功接受应答或者某个设备与主叫方成功建立会话时,业务服务器通过MESSAGE(消息)请求将此信息以文本内容通知给其他被发送过会话邀请请求的设备。
业务服务器根据多设备会话邀请处理状态集判断哪些设备已返回过应答消息或被发送过会话取消请求,哪些设备还对会话邀请请求保持未决状态;对于“已处理会话邀请请求的设备”的设备,仅发送提示“成功接受应答”/“成功建立会话”的简短文本;对于未处理会话邀请请求的设备,还额外提供可供用户选择的会话建立方式信息,并在MESSAGE请求中包含某个扩展头域(比如Subject头域),以指示该MESSAGE请求所对应的会话邀请请求(会话标识符)。
(3)扩展业务客户端的业务逻辑
业务客户端判断其收到的MESSAGE请求中是否包含上述指示会话标识符信息的扩展头域,如果不包含该扩展头域,则仅将文本内容信息显示到用户界面;如果包含该扩展头域,而且该业务客户端先前没有返回过对应会话邀请请求的应答消息(通过检查客户端程序中仍然未处理“通知消息的扩展头域中会话标识符”所指示的会话邀请事务),说明该设备还未处理会话邀请请求,则业务客户端显示给用户界面的信息中还包含可供用户动态输入的选择信息。在特殊情况下,如果包含该扩展头域,但是该业务客户端先前已经返回过对应会话邀请请求的应答消息,业务服务器还未及时更新多设备会话邀请处理状态集,则不向用户界面提供可供用户动态输入的选择信息,仅提供某设备“成功接受应答”的简短文本信息。
业务客户端向用户界面提供的可供选择的会话建立方式包括:1拒绝会话邀请请求;2接受会话邀请请求并将会话切换到本设备;3接受邀请并继续先前其他设备与主叫用户建立的会话。
业务客户端根据用户动态输入的选择信息构造对应会话邀请请求的应答消息,并将选择信息包含在对应会话邀请请求的应答消息中的扩展头域中。
基于上述扩展,该实施例提供的通知其他设备关于某设备成功接受会话邀请请求和成功建立会话的信息的方法的处理流程如图7所示,包括如下步骤:
步骤71、在多设备环境下的会话建立过程中,业务服务器为每个会话邀请请求构造和维护一个上述多设备会话邀请处理状态集,当某用户设备返回对应会话邀请请求的应答消息,或某用户设备被发送会话取消请求时,对上述多设备会话邀请处理状态集进行相应的更新。
业务服务器收到被叫用户的设备1#返回对应所述会话邀请请求的成功应答消息时,或者被叫用户的设备1#与主叫用户成功建立会话时,业务服务器除了执行相应的业务逻辑并更新多设备会话邀请处理状态集外,还准备发送关于此信息的通知消息给其他设备。
步骤72、业务服务器获取多设备会话邀请处理状态集;
步骤73、业务服务器根据多设备会话邀请处理状态集中的<response>和<CANCEL-sent>项值,获取上述:“已处理会话邀请请求的设备”和“未处理会话邀请请求的设备”信息。
在特殊情况下,业务服务器可能几乎同时收到另一个设备返回的应答消息,这时它还来不及更新会话邀请处理状态集,导致业务服务器认为该设备没有返回应答消息。
步骤74、对于已处理会话邀请请求的设备X#,业务服务器为其构造MESSAGE请求,并发送给该设备,MESSAGE请求的消息体内容为:“设备1#已接受来自主叫用户的会话邀请请求”或者“设备1#正在与主叫用户进行会话”。该设备接收到该MESSAGE请求后,通过业务客户端直接将文本内容显示到用户界面。
步骤75a、对于未处理会话邀请请求的设备X#,业务服务器为其构造MESSAGE请求,并发送给该设备,MESSAGE请求的消息体内容为:
“设备1#已经接受来自主叫用户的会话邀请请求,请选择:拒绝会话邀请请求;接受邀请并将会话切换到本设备;接受邀请并继续先前其他设备与主叫方建立的会话”;
或者:
“设备1#正在与主叫用户进行会话,请选择:拒绝会话邀请请求;接受邀请并将会话切换到本设备;接受邀请并继续先前其他设备与主叫用户建立的会话”。
上述MESSAGE请求中包含扩展Subject头域,其值为“Subject:This is a notification inmulti-device environment,session-id=″s34ad″”;
75b、设备X#的业务客户端收到上述MESSAGE请求后,将消息体显示到用户界面以供用户进行选择。
设备X#的业务客户端检查和判断MESSAGE请求中的Subject头域值以及其自身是否已经发送过对应会话邀请请求的应答消息,如果确定虽然MESSAGE请求中包含Subject头域,但是该业务客户端已经发送过应答消息,则仅提供某设备“成功接受应答”的简短文本信息;如果确定MESSAGE请求中包含Subject头域(含session-id参数),且业务客户端还未给session-id所关联的会话邀请请求返回应答消息,则向用户界而提供的可供选择的会话建立方式,并根据用户动态输入的选择信息构造成功或失败应答,并将选择信息包含进应答消息中的Subject头域。
然后,设备X#将成功或失败应答消息返回给业务服务器;
75c、业务服务器收到设备X#返回的对应会话邀请请求的应答消息后,判断和解析Subject头域中携带的用户动态输入的选择信息,并进行相应的业务逻辑处理。
如果解析得到的选择信息为“拒绝会话邀请请求”,则业务服务器终止其到设备X#的会话建立事务;
如果解析得到的选择信息为“接受邀请并将会话切换到本设备”,则业务服务器将会话从设备1#(和/或其他设备)转移到设备X#。
如果解析得到的选择信息为“接受邀请并继续先前其他设备与主叫方建立的会话”,则业务服务器扮演群组会话管理员的身份,按照“加入群组会话”的相关处理流程处理被叫用户的多个设备同时与主叫方之间进行的会话;
实施例五
业务用户B在其同一个用户地址上绑定了三个设备1#、2#、3#,即被叫用户拥有多设备环境,该实施例提供的一种在多设备环境中实现会话建立的方法的处理流程如图8所示,包括如下步骤:
步骤81、业务用户A构造和发送目标用户地址为B的会话邀请请求,该会话邀请请求被底层SIP/IP核心网路由到为业务用户B服务的业务服务器。可选的,上述会话邀请请求可以由业务服务器根据业务需要主动发起,而无须接收来自其他用户的会话邀请请求后再发送。
步骤82、业务服务器根据SIP/IP核心网或者业务服务器中存储的用户注册信息库中对目标用户地址进行多设备环境判断。如果判断目标用户地址为多设备环境,则根据用户注册信息(包含用户设备能力集)、用户偏好、运营商策略等策略,选出适合接收会话邀请请求的多个设备。在本实施例中,虽然用户B拥有1#、2#、3#三个设备,但基于策略(或出于计费考虑、或3#不适合接收SDP体中指示的媒体类型等等),判断3#不适合接收会话邀请请求,因此只选择设备1#、设备2#作为适合的接收设备。
业务服务器在本地为该会话邀请请求构造一个多设备会话邀请处理状态集(以数据库或者XML文档的形式存储),以动态表述各个设备处理会话邀请请求的状态信息。
步骤83、业务服务器为选定的设备1#构造和发送会话邀请请求,该会话邀请请求的目标地址为使用GRUU机制的目标用户设备1#的标识,而且将“Subject:An Invitation to multipledevices;purpose=multi-devices”头域及头域值包含进会话邀请请求中,以指示会话邀请请求被同时分发到其他同址设备。
步骤84、业务服务器为选定的设备2#构造和发送会话邀请请求,该会话邀请请求的目标地址为使用GRUU机制的目标用户设备2#的标识,而且将“Subject:An Invitation to multipledevices;purpose=multi-devices”头域及头域值包含进会话邀请请求中,以指示会话邀请请求被同时分发到其他同址设备。
步骤85、当设备1#收到上述会话邀请请求后,通过检查该会话邀请请求的Subject头域,发现该会话邀请请求处于多设备环境,则提示用户基于当前意愿实时选择几种不同的会话建立方式:1.接受;2.仅在此设备上接受;3.仅在此设备上拒绝;4.在本设备和其他设备上全部拒绝。
本实施例中,被叫方用户在设备1#选择“1.接受”,于是,1#上的业务客户端构造对应会话邀请请求的成功应答消息,并将“1.接受”信息携带在该成功应答消息的Subject头域中。
步骤86、设备1#将成功应答返回给业务服务器。
步骤87、业务服务器对设备1#返回的应答消息进行处理,解析出该应答消息中包含的“1.接受”信息,则构造成功应答消息给主叫用户,其Contact地址为可直接联系到设备1#的地址,不向其他设备发送会话取消请求。此外,业务服务器更新多设备会话邀请处理状态集中的设备1#的<response>项。
步骤88、业务服务器发送设备1#返回的成功应答消息给主叫用户。
步骤89、业务服务器发送“设备1#已经接受来自主叫用户的会话邀请请求”通知消息给设备2#。在本实施例中,设备1#先前没有指示业务服务器向设备2#发送会话取消请求,而且设备2#没有返回对应会话邀请请求的应答消息,则业务服务器可以获取和判断多设备会话邀请处理状态集中设备2#的状态,发现它对会话邀请请求处于未决状态,于是发送SIP MESSAGE请求给设备2#,消息体携带供设备2#选择的会话建立方式的信息:
设备1#已经接受来自主叫方的会话邀请请求,请选择:拒绝会话邀请请求;接受邀请并将会话切换到本设备;接受邀请并继续先前其他设备与主叫用户建立的会话。而且,在MESSAGE请求中包含扩展的Subject头域,其值为“Subject:This is a notification in multi-device environment,session-id=″s34ad″”以指示此通知所对应会话邀请请求的会话标识符。
步骤810、设备2#将收到的MESSAGE请求的消息体内容显示到用户界面,并根据通知消息的扩展Subject头域所包含的会话标识符匹配到先前的会话邀请请求,然后根据用户所选择的会话建立方式构造相应的成功/失败应答消息,将选择信息放在成功/失败应答消息的Subject头域中。
步骤811、设备2#将成功/失败应答消息发送给业务服务器。
步骤812、业务服务器接收设备2#返回的对应会话邀请请求的应答消息,解析Subject头域所携带的选择信息,并进行相应的业务逻辑处理。
步骤813、业务用户A返回对应设备1#的成功应答消息的确认消息给业务服务器。
步骤814、业务服务器将对应设备1#的成功应答消息的确认消息发送到设备1#。
步骤815、业务用户B的设备1#与业务用户A之间成功建立起会话。
步骤816、业务服务器根据对多设备会话邀请处理状态集的判断,将“设备1#正在与主叫方进行会话”的信息通过MESSAGE请求发送给设备2#。在本实施例中,因为设备2#已经返回对应原会话邀请请求的应答消息,所以此MESSAGE请求中不再包含关于选择会话建立方式的信息。
实施例六
业务用户B在其同一个用户地址上绑定了三个设备1#、2#、3#,即被叫方用户拥有多设备环境,该实施例提供的一种在多设备环境中实现会话建立的方法的处理流程如图9所示,包括如下步骤:
步骤91、业务用户A构造和发送目标用户地址为B的会话邀请请求,该会话邀请请求被底层SIP/IP核心网路由到为业务用户B服务的业务服务器。可选的,上述会话邀请请求可以由业务服务器根据业务需要主动发起,而无须接收来自其他用户的会话邀请请求后再发送。
步骤92、业务服务器根据SIP/IP核心网或者业务服务器中存储的用户注册信息库中对目标用户地址进行多设备环境判断。如果判断目标用户地址为多设备环境,则根据用户注册信息(包含用户设备能力集)、用户偏好、运营商策略等策略,选出适合接收会话邀请请求的多个设备。在本实施例中,虽然用户B拥有1#、2#、3#三个设备,但基于策略(或出于计费考虑、或3#不适合接收SDP体中指示的媒体类型等等),判断3#不适合接收会话邀请请求,因此只选设择设备1#、设备2#作为适合的接收设备。
业务服务器在本地为该会话邀请请求构造一个多设备会话邀请处理状态集(以数据库或者XML文档的形式存储),以动态表述各个设备处理会话邀请请求的状态信息。
步骤93、业务服务器为选定的设备1#构造和发送会话邀请请求,该会话邀请请求的目标地址为使用GRUU机制的目标用户设备1#的标识,而且将“Subject:An Invitation to multipledevices;purpose=multi-devices”头域及头域值包含进会话邀请请求中,以指示会话邀请请求被同时分发到其他同址设备。
步骤94、业务服务器为选定的设备2#构造和发送会话邀请请求,该会话邀请请求的目标地址为使用GRUU机制的目标用户设备2#的标识,而且将“Subject:An Invitation to multipledevices;purpose=multi-devices”头域及头域值包含进会话邀请请求中,以指示会话邀请请求被同时分发到其他同址设备。
步骤95、当设备1#收到会话邀请请求后,通过检查Subject头域,发现该会话邀请请求处于多设备环境,则提示用户基于当前意愿实时选择几种不同的会话建立方式:1.接受;2.仅在此设备上接受;3.仅在此设备上拒绝;4.在本设备和其他设备上全部拒绝。本实施例中,被叫方用户在设备1#选择“2.仅在此设备上接受”,则设备1#上的业务客户端构造对应会话邀请请求的成功应答消息,并将“2.仅在此设备上接受”信息携带在成功应答消息的Subject头域中。
步骤96、设备1#将上述成功应答消息返回给业务服务器。
步骤97、业务服务器对设备1#返回的成功应答消息进行处理,解析出设备1#返回的成功应答消息中所携带的“2.仅在此设备上接受”信息,则构造成功应答消息给主叫用户,其Contact地址为可直接联系到设备1#的地址。
业务服务器基于“2.仅在此设备上接受”的指示,为其他设备构造会话取消请求。此外,业务服务器更新多设备会话邀请处理状态集中的设备1#的<response>项和设备2#的<CANCEL-sent>项。
步骤98、业务服务器发送设备1#返回的成功应答消息给主叫用户。
步骤99、业务服务器发送构造好的会话取消请求给其他设备。
步骤910、业务服务器接收其他设备返回的对应会话取消请求的应答消息。
步骤911、因为经设备1#先前返回应答的指示,业务服务器向设备2#发送过会话取消请求,所以业务服务器认为已经终止了设备2#的会话邀请事务,便发送仅包含“设备1#已经接受来自主叫用户的会话邀请请求”简单文本的通知消息给设备2#。
步骤912、业务用户A返回对应设备1#的成功应答消息的确认消息给业务服务器。
步骤913、业务服务器将对应设备1#的成功应答消息的确认消息发送到业务用户B的设备1#。
步骤914、业务用户B的设备1#与业务用户A之间成功建立起会话。
步骤915、业务服务器根据对多设备会话邀请处理状态集的判断,将“设备1#正在与主叫方进行会话”的信息通过MESSAGE请求发送给设备2#。在本实施例中,因为设备2#已经被发送过会话取消请求,所以此通知中不再包含关于选择会话建立方式的信息。
实施例七
业务用户B在其同一个用户地址上绑定了三个设备1#、2#、3#,即被叫方用户拥有多设备环境,该实施例提供的一种在多设备环境中实现会话建立的方法的处理流程如图10所示,包括如下步骤:
步骤101、业务用户A构造和发送目标用户地址为B的会话邀请请求,该会话邀请请求被底层SIP/IP核心网路由到为业务用户B服务的业务服务器。可选的,上述会话邀请请求可以由业务服务器根据业务需要主动发起,而无须接收来自其他用户的会话邀请请求后再发送。
步骤102、业务服务器根据SIP/IP核心网或者业务服务器中存储的用户注册信息库中对目标用户地址进行多设备环境判断。如果判断目标用户地址为多设备环境,则根据用户注册信息(包含用户设备能力集)、用户偏好、运营商策略等策略,选出适合接收会话邀请请求的多个设备。在本实施例中,虽然用户B拥有1#、2#、3#三个设备,但基于策略(或出于计费考虑、或3#不适合接收SDP体中指示的媒体类型等等),判断3#不适合接收会话邀请请求,因此只选设择设备1#、设备2#作为适合的接收设备。
业务服务器在本地为该会话邀请请求构造一个多设备会话邀请处理状态集(以数据库或者XML文档的形式存储),以动态表述各个设备处理会话邀请请求的状态信息。
步骤103、业务服务器为选定的设备1#构造和发送会话邀请请求,该会话邀请请求的目标地址为使用GRUU机制的目标用户设备1#的标识,而且将“Subject:An Invitation to multipledevices;purpose=multi-devices”头域及头域值包含进会话邀请请求中,以指示会话邀请请求被同时分发到其他同址设备。
步骤104、业务服务器为选定的设备2#构造和发送会话邀请请求,该会话邀请请求的目标地址为使用GRUU机制的目标用户设备2#的标识,而且将“Subject:An Invitation to multipledevices;purpose=multi-devices”头域及头域值包含进会话邀请请求中,以指示会话邀请请求被同时分发到其他同址设备。
步骤105、当设备1#收到会话邀请请求后,通过检查该会话邀请请求的Subject头域,发现该会话邀请请求处于多设备环境,则提示用户基于当前意愿实时选择几种不同的会话建立方式:1.接受;2.仅在此设备上接受;3.仅在此设备上拒绝;4.在本设备和其他设备上全部拒绝。
本实施例中,被叫用户在设备1#选择“3.仅在此设备上拒绝”,则设备1#上的业务客户端构造对应会话邀请请求的失败应答消息,并将“仅在此设备上拒绝”信息携带进该失败应答消息中的Subject头域。
步骤106、业务客户端将此失败应答消息返回给业务服务器。
步骤107、业务服务器对设备1#返回的失败应答消息进行处理,解析出该失败应答消息中携带的“3.仅在此设备上拒绝”信息,则终止设备1#的会话邀请事务,并对其他设备保持未决状态。
因为设备1#没有返回成功应答消息,所以业务服务器也不向其他设备发送通知消息。此外业务服务器更新多设备会话邀请处理状态集中的设备1#的<response>项。
实施例八
业务用户B在其同一个用户地址上绑定了三个设备1#、2#、3#,即被叫方用户拥有多设备环境,该实施例提供的一种在多设备环境中实现会话建立的方法的处理流程如图11所示,包括如下步骤:
步骤111、业务用户A构造和发送目标用户地址为B的会话邀请请求,该会话邀请请求被底层SIP/IP核心网路由到为业务用户B服务的业务服务器。可选的,上述会话邀请请求可以由业务服务器根据业务需要主动发起,而无须接收来自其他用户的会话邀请请求后再发送。
步骤112、业务服务器根据SIP/IP核心网或者业务服务器中存储的用户注册信息库中对目标用户地址进行多设备环境判断。如果判断目标用户地址为多设备环境,则根据用户注册信息(包含用户设备能力集)、用户偏好、运营商策略等策略,选出适合接收会话邀请请求的多个设备。在本实施例中,虽然用户B拥有1#、2#、3#三个设备,但基于策略(或出于计费考虑、或3#不适合接收SDP体中指示的媒体类型等等),判断3#不适合接收会话邀请请求,因此只选设择设备1#、设备2#作为适合的接收设备。
业务服务器在本地为该会话邀请请求构造一个多设备会话邀请处理状态集(以数据库或者XML文档的形式存储),以动态表述各个设备处理会话邀请请求的状态信息。
步骤113、业务服务器为选定的设备1#构造和发送会话邀请请求,该会话邀请请求的目标地址为使用GRUU机制的目标用户设备1#的标识,而且将“Subject:An Invitation to multipledevices;purpose=multi-devices”头域及头域值包含进会话邀请请求中,以指示会话邀请请求被同时分发到其他同址设备。
步骤114、业务服务器为选定的设备2#构造和发送会话邀请请求,该会话邀请请求的目标地址为使用GRUU机制的目标用户设备2#的标识,而且将“Subject:An Invitation to multipledevices;purpose=multi-devices”头域及头域值包含进会话邀请请求中,以指示会话邀请请求被同时分发到其他同址设备。
步骤115、当设备1#收到会话邀请请求后,通过检查该会话邀请请求的Subject头域,发现该会话邀请请求处于多设备环境,则提示用户基于当前意愿实时选择儿种不同的会话建立方式:1.接受;2.仅在此设备上接受;3.仅在此设备上拒绝;4.在本设备和其他设备上全部拒绝。
本实施例中,被叫方用户在设备1#选择“4.在本设备和其他设备上全部拒绝”,则设备1#上的业务客户端构造对应会话邀请请求的失败应答消息,并将“4.在本设备和其他设备上全部拒绝”信息携带进该失败应答消息的Subject头域。
步骤116、业务客户端将此失败应答消息返回给业务服务器。
步骤117、业务服务器对设备1#返回的失败应答消息进行处理。它解析出设备1#返回的失败应答消息中所携带的“4.在本设备和其他设备上全部拒绝”信息,则终止设备1#的会话邀请事务,并为其他设备构造会话取消请求。
因为设备1#没有返回成功应答消息,所以业务服务器也不向其他设备发送通知消息。此外,业务服务器删除多设备会话邀请处理状态集。
步骤118、业务服务器根据设备1#返回的应答,构造和发送失败应答消息给主叫方用户A。
步骤119、业务服务器发送构造好的会话取消请求给其他设备。
步骤120、业务服务器接收其他设备返回的对应会话取消请求的应答消息。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,所述的程序可存储于一计算机可读取存储介质中,该程序在执行时,可包括如上述各方法的实施例的流程。其中,所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-0nlyMemory,ROM)或随机存储记忆体(Random Access Memory,RAM)等。
本发明实施例还提供了一种在多设备环境中进行会话处理的装置,其具体实现结构如图12所示,具体可以包括:
会话邀请请求发送模块121,用于向多设备环境下的被叫用户的设备发送会话邀请请求;
选择信息获取模块122,用于接收所述被叫用户的设备返回的应答消息,对所述应答消息进行解析,获取所述应答消息中携带的会话建立方式的选择信息;
会话处理模块123,用于根据所述选择信息获取模块所获取的会话建立方式的选择信息,进行相应的会话处理。
所述装置还可以包括:
多设备会话邀请处理状态集维护模块124,用于在将会话邀请请求发送给被叫用户的多个设备后,为该会话邀请请求建立并维护多设备会话邀请处理状态集,该多设备会话邀请处理状态集中包括主叫用户信息、被叫用户信息、主被叫用户之间请求建立的会话的标识信息、已经返回过所述会话邀请请求的应答消息的被叫用户的设备信息和被发送过会话取消请求的被叫用户的设备信息;
通知消息发送模块125,用于当接收到被叫用户的某个设备返回的携带接受会话邀请请求的选择信息的应答消息后,向所述被叫用户的其它设备发送通知消息,该通知消息中携带所述某个设备接受会话邀请请求的信息;并且。当根据所述多设备会话邀请处理状态集判断所述其它设备没有返回过所述会话邀请请求的应答消息或没有被发送过会话取消请求时,所述通知消息中还携带会话建立方式的选择信息。
所述会话处理模块123可以包括:
第一会话处理模块1231,用于当所述选择信息获取模块所获取的会话建立方式的选择信息为接受时,将所述应答消息转发给主叫用户,不向所述被叫用户的其它设备发送会话取消请求,所述主叫用户和返回所述应答消息的被叫用户的设备之间进行会话建立;
第二会话处理模块1232,当所述选择信息获取模块所获取的会话建立方式的选择信息为仅在此设备上接受时,将所述应答消息转发给主叫用户,向所述被叫用户的其它设备发送会话取消请求,所述主叫用户和返回所述应答消息的被叫用户的设备之间进行会话建立;
第三会话处理模块1233,当所述选择信息获取模块所获取的会话建立方式的选择信息为仪在此设备上拒绝时,不将所述应答消息转发给主叫用户,不向所述被叫用户的其它设备发送会话取消请求,所述主叫用户和返回所述应答消息的被叫用户的设备之间不进行会话建立;
第四会话处理模块1234,当所述选择信息获取模块所获取的会话建立方式的选择信息为在本设备和其他设备上全部拒绝时,将所述应答消息转发给主叫用户,向所述被叫用户的其它设备发送会话取消请求,所述主叫用户和返回所述应答消息的被叫用户的设备之间不进行会话建立。
所述装置可以为业务服务器。
本发明实施例还提供了一种在多设备环境中进行会话处理的系统,该系统包括:上述图12所示的装置和被叫用户的设备,
所述装置,用于向多设备环境下的被叫用户的设备发送会话邀请请求,接收所述被叫用户的设备返回的应答消息,对所述应答消息进行解析,获取所述应答消息中携带的会话建立方式的选择信息,根据所述选择信息获取模块所获取的会话建立方式的选择信息,进行相应的会话处理;
所述被叫用户的设备,用于接收所述装置发送的会话邀请请求,向所述装置发送携带会话建立方式的选择信息的应答消息。
综上所述,使用本发明实施例提供的方法和装置,可以实现在多设备环境下的会话建立过程中,根据用户实时输入的用户意愿并结合相关策略来执行不同的应答处理逻辑,向其他设备发送关于某设备成功接受应答和成功建立会话的通知信息,该通知消息中还可以携带会话建立方式的选择信息。
本发明实施例可以提供多设备环境下的会话建立的方法,提高了业务服务器的处理能力和网络服务质量,丰富了用户体验。
以上所述,仅为本发明较佳的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到的变化或替换,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应该以权利要求的保护范围为准。
Claims (13)
1、一种在多设备环境中进行会话处理的方法,其特征在于,包括:
向多设备环境下的被叫用户的设备发送会话邀请请求;
接收所述被叫用户的设备返回的应答消息,对所述应答消息进行解析,获取所述应答消息中携带的会话建立方式的选择信息,根据该会话建立方式的选择信息进行相应的会话处理。
2、根据权利要求1所述的方法,其特征在于,所述向多设备环境下的被叫用户的设备发送会话邀请请求的过程,包括:
当业务服务器收到主叫用户发向被叫用户的会话邀请请求;或者,业务服务器作为主叫用户向被叫用户发送会话邀请请求时,该业务服务器查询用户注册信息,获取所述被叫用户绑定的多个设备信息;
业务服务器向所述被叫用户的各个设备分别发送会话邀请请求,并在会话邀请请求中携带会话邀请请求被发送到多个同址设备的指示信息。
3、根据权利要求2所述的方法,其特征在于,所述接收所述被叫用户的设备返回的应答消息的过程,包括:
被叫用户的设备在收到所述会话邀请请求后,检查出该会话邀请请求中包含所述会话邀请请求被发送到多个同址设备的指示信息;
所述被叫用户根据当前意愿和所述指示信息选择会话建立方式,所述会话建立方式包括:接受、仅在此设备上接受、仅在此设备上拒绝和在本设备和其他设备上全部拒绝;
所述被叫用户的设备向所述业务服务器发送携带所述会话建立方式的选择信息的应答消息,所述业务服务器接收所述应答消息。
4、根据权利要求3所述的方法,其特征在于,所述对所述应答消息进行解析,获取所述应答消息中携带的会话建立方式的选择信息,根据该会话建立方式的选择信息进行相应的会话处理的过程,包括:
当所述业务服务器获取的会话建立方式的选择信息为接受时,所述业务服务器将所述应答消息转发给主叫用户,不向所述被叫用户的其它设备发送会话取消请求,所述主叫用户和返回所述应答消息的被叫用户的设备之间进行会话建立;
当所述业务服务器获取的会话建立方式的选择信息为仅在此设备上接受时,业务服务器将所述应答消息转发给主叫用户,向所述被叫用户的其它设备发送会话取消请求,所述主叫用户和返回所述应答消息的被叫用户的设备之间进行会话建立;
当所述业务服务器获取的会话建立方式的选择信息为仅在此设备上拒绝时,业务服务器不将所述应答消息转发给主叫用户,不向所述被叫用户的其它设备发送会话取消请求,所述主叫用户和返回所述应答消息的被叫用户的设备之间不进行会话建立;
当所述业务服务器获取的会话建立方式的选择信息为在本设备和其他设备上全部拒绝时,业务服务器将所述应答消息转发给主叫用户,向所述被叫用户的其它设备发送会话取消请求,所述主叫用户和返回所述应答消息的被叫用户的设备之间不进行会话建立。
5、根据权利要求1至4任一项所述的方法,其特征在于,所述方法还包括:
当在小于设定时间内接收到多个所述被叫用户的设备返回的多个应答消息时,根据第一个接收到的应答消息中携带的会话建立方式的选择信息,进行相应的会话处理,
如果后续接收到的应答消息中携带的会话建立方式的选择信息与所述第一个接收到的应答消息中携带的会话建立方式的选择信息不互相冲突,则对后续接收到的应答消息进行相应的处理;否则,对后续接收到的应答消息不处理。
6、根据权利要求1至5任一项所述的方法,其特征在于,所述方法还包括:
当在小于设定时间内接收到多个所述被叫用户的设备返回的多个应答消息时,根据优先级最高的设备返回的应答消息中携带的会话建立方式的选择信息,进行相应的会话处理;
如果优先级不是最高的设备返回的应答消息中携带的会话建立方式的选择信息与所述优先级最高的设备返回的应答消息中携带的会话建立方式选择信息不互相冲突,则对优先级不是最高的设备返回的应答消息进行相应的处理;否则,对优先级不是最高的设备返回的应答消息不处理。
7、根据权利要求1至5任一项所述的方法,其特征在于,所述方法还包括:
在将会话邀请请求发送给被叫用户的多个设备后,为该会话邀请请求建立并维护多设备会话邀请处理状态集,该多设备会话邀请处理状态集中包括主叫用户信息、被叫用户信息、主被叫用户之间请求建立的会话的标识信息、已经返回过所述会话邀请请求的应答消息的被叫用户的设备信息和被发送过会话取消请求的被叫用户的设备信息;
当接收到被叫用户的某个设备返回的携带接受会话邀请请求的选择信息的应答消息后,向所述被叫用户的其它设备发送通知消息,该通知消息中携带所述某个设备接受会话邀请请求的信息;并且,当根据所述多设备会话邀请处理状态集判断所述其它设备没有返回过所述会话邀请请求的应答消息或没有被发送过会话取消请求时,所述通知消息中还携带会话建立方式的选择信息。
8、根据权利要求7所述的方法,其特征在于,所述多设备会话邀请处理状态集中还包括:被叫用户的设备的优先级、被叫用户的设备返回的应答消息中携带的会话建立方式的选择信息。
9、根据权利要求7所述的方法,其特征在于,所述通知消息中携带的会话建立方式的选择信息包括:拒绝会话邀请请求、接受会话邀请请求并将会话切换到本设备和接受邀请并继续先前其他设备与主叫用户建立的会话。
10、一种在多设备环境中进行会话处理的装置,其特征在于,包括:
会话邀请请求发送模块,用于向多设备环境下的被叫用户的设备发送会话邀请请求;
选择信息获取模块,用于接收所述被叫用户的设备返回的应答消息,对所述应答消息进行解析,获取所述应答消息中携带的会话建立方式的选择信息;
会话处理模块,用于根据所述选择信息获取模块所获取的会话建立方式的选择信息,进行相应的会话处理。
11、根据权利要求10所述的装置,其特征在于,所述会话处理模块具体包括:
第一会话处理模块,用于当所述选择信息获取模块所获取的会话建立方式的选择信息为接受时,将所述应答消息转发给主叫用户,不向所述被叫用户的其它设备发送会话取消请求,所述主叫用户和返回所述应答消息的被叫用户的设备之间进行会话建立;
第二会话处理模块,当所述选择信息获取模块所获取的会话建立方式的选择信息为仅在此设备上接受时,将所述应答消息转发给主叫用户,向所述被叫用户的其它设备发送会话取消请求,所述主叫用户和返回所述应答消息的被叫用户的设备之间进行会话建立;
第三会话处理模块,当所述选择信息获取模块所获取的会话建立方式的选择信息为仅在此设备上拒绝时,不将所述应答消息转发给主叫用户,不向所述被叫用户的其它设备发送会话取消请求,所述主叫用户和返回所述应答消息的被叫用户的设备之间不进行会话建立;
第四会话处理模块,当所述选择信息获取模块所获取的会话建立方式的选择信息为在本设备和其他设备上全部拒绝时,将所述应答消息转发给主叫用户,向所述被叫用户的其它设备发送会话取消请求,所述主叫用户和返回所述应答消息的被叫用户的设备之间不进行会话建立。
12、根据权利要求10或11所述的装置,其特征在于,所述装置还包括:
多设备会话邀请处理状态集维护模块,用于在将会话邀请请求发送给被叫用户的多个设备后,为该会话邀请请求建立并维护多设备会话邀请处理状态集,该多设备会话邀请处理状态集中包括主叫用户信息、被叫用户信息、主被叫用户之间请求建立的会话的标识信息、已经返回过所述会话邀请请求的应答消息的被叫用户的设备信息和被发送过会话取消请求的被叫用户的设备信息;
通知消息发送模块,用于当接收到被叫用户的某个设备返回的携带接受会话邀请请求的选择信息的应答消息后,向所述被叫用户的其它设备发送通知消息,该通知消息中携带所述某个设备接受会话邀请请求的信息;并且,当根据所述多设备会话邀请处理状态集判断所述其它设备没有返回过所述会话邀请请求的应答消息或没有被发送过会话取消请求时,所述通知消息中还携带会话建立方式的选择信息。
13、一种在多设备环境中进行会话处理的系统,其特征在于,包括:如权利要求10到12任一项所述的装置和被叫用户的设备,
所述装置,用于向多设备环境下的被叫用户的设备发送会话邀请请求,接收所述被叫用户的设备返回的应答消息,对所述应答消息进行解析,获取所述应答消息中携带的会话建立方式的选择信息,根据所述选择信息获取模块所获取的会话建立方式的选择信息,进行相应的会话处理;
所述被叫用户的设备,用于接收所述装置发送的会话邀请请求,向所述装置发送携带会话建立方式的选择信息的应答消息。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 200810223205 CN101686192B (zh) | 2008-09-27 | 2008-09-27 | 在多设备环境中进行会话处理方法、装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 200810223205 CN101686192B (zh) | 2008-09-27 | 2008-09-27 | 在多设备环境中进行会话处理方法、装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101686192A true CN101686192A (zh) | 2010-03-31 |
CN101686192B CN101686192B (zh) | 2012-12-19 |
Family
ID=42049173
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN 200810223205 Active CN101686192B (zh) | 2008-09-27 | 2008-09-27 | 在多设备环境中进行会话处理方法、装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101686192B (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103970710A (zh) * | 2013-01-24 | 2014-08-06 | 三星电子株式会社 | 自适应服务控制器、片上系统和控制其的方法 |
CN105511858A (zh) * | 2015-11-27 | 2016-04-20 | 小米科技有限责任公司 | 活动参与用户确定方法及装置 |
CN111193941A (zh) * | 2020-01-07 | 2020-05-22 | 北京东土科技股份有限公司 | 一种媒体数据的传输方法、装置、设备及存储介质 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070058637A1 (en) * | 2005-09-14 | 2007-03-15 | Tun Han Felix Lo | Method for multi-channel multi-device call transfer |
-
2008
- 2008-09-27 CN CN 200810223205 patent/CN101686192B/zh active Active
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103970710A (zh) * | 2013-01-24 | 2014-08-06 | 三星电子株式会社 | 自适应服务控制器、片上系统和控制其的方法 |
CN103970710B (zh) * | 2013-01-24 | 2018-11-13 | 三星电子株式会社 | 自适应服务控制器、片上系统和控制其的方法 |
CN105511858A (zh) * | 2015-11-27 | 2016-04-20 | 小米科技有限责任公司 | 活动参与用户确定方法及装置 |
CN105511858B (zh) * | 2015-11-27 | 2019-07-02 | 小米科技有限责任公司 | 活动参与用户确定方法及装置 |
CN111193941A (zh) * | 2020-01-07 | 2020-05-22 | 北京东土科技股份有限公司 | 一种媒体数据的传输方法、装置、设备及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN101686192B (zh) | 2012-12-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101138172B (zh) | 用于无线一键通网络中分离终端的方法和系统 | |
CN101515949B (zh) | 便于用户设备间会话转移的方法和系统 | |
CN1703690B (zh) | 用于会议控制中成员资格管理的侧信道 | |
CN100524280C (zh) | 参与通信会话的方法和装置 | |
CN100499598C (zh) | 即时消息用户使用其它即时消息系统聊天室的方法及系统 | |
US9426295B2 (en) | Method and device for distributing mobile attendant call | |
US9426108B2 (en) | Method for storing conversation upon user's request in CPM system, and system thereof | |
CN101548556B (zh) | 建立和管理用于执行多媒体呼叫业务的多媒体基于蜂窝网络的即按即说会话的系统及其方法和用户设备 | |
JP5274668B2 (ja) | 統合ipメッセージングサービスにおけるインターワーキングのためのセッションを制御する方法及び装置とそのシステム | |
EP2040494B1 (en) | Method and system for network multimedia conference access | |
CN102388631A (zh) | 用于在满足特定条件时建立会话的系统和方法 | |
CN102355631A (zh) | 传输和施加发言权控制方案的用户设备、服务器及方法 | |
CN101854703B (zh) | 获取状态信息的方法、服务器及系统 | |
CN101938498A (zh) | 数字电视终端进行即时通讯的方法和装置及系统 | |
CN111225176A (zh) | 在线会议建立方法、服务器及计算机可读存储介质 | |
CN101453459B (zh) | 一种实现媒体协商的方法和装置 | |
CN110740161A (zh) | 一种适配融合通信的系统及方法 | |
CN101834730A (zh) | 一种多媒体会议控制方法和系统 | |
CN104580247A (zh) | 基于ims多方通话的信息同步方法和信息同步装置 | |
CN1988546A (zh) | 获取会话起始协议消息传输路径的方法及系统 | |
WO2008006311A1 (fr) | Procédé et dispositif d'utilisation d'un identificateur de terminal utilisateur | |
CN101247370B (zh) | 消息呈现业务的实现方法和系统 | |
CN101686192B (zh) | 在多设备环境中进行会话处理方法、装置 | |
CN102065099A (zh) | 信令与承载分离的通信系统 | |
CN101594597B (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 |