1.基于SIP的用户离线检测方法,其特征在于,包括步骤:
用户终端向呈现服务器发送其上线的状态发布消息后,向呈现服务器发送心跳请求消息;
呈现服务器接收到用户终端上线的状态发布消息后,创建该用户终端的用户记录,并在接收到该用户终端发送的心跳请求消息后,呈现服务器用本地配置的时间值刷新该用户终端对应的用户记录中的超时时间且启动计时,然后向该用户终端返回包括有刷新后超时时间信息的心跳响应消息;
用户终端接收到呈现服务器的心跳响应消息后,在本地记录心跳响应消息中的超时时间信息,根据该超时时间设置心跳维护周期,并在该心跳维护周期时间到达时向呈现服务器发送用于心跳维护的心跳请求消息;
当该用户记录中的超时时间到达时,呈现服务器未收到用户终端的心跳请求消息,则判断该用户离线,同时删除该用户终端对应的用户记录;当在用户记录中的超时时间内,呈现服务器收到用户终端的心跳请求消息,则判断该用户在线,并刷新该用户终端对应的用户记录中的超时时间。
2.如权利要求1所述基于SIP的用户离线检测方法,其特征在于,当呈现服务器收到用户终端的心跳请求消息,但无法找到该用户终端对应的用户记录时,呈现服务器则向该用户终端返回心跳错误响应消息;所述心跳错误响应消息将触发用户终端向呈现服务器发送其上线的状态发布消息;呈现服务器接收到该状态发布消息后,立即创建该用户终端的用户记录。
3.如权利要求2所述基于SIP的用户离线检测方法,其特征在于,所述心跳请求消息、心跳响应消息、心跳错误响应消息均基于用户数据报协议。
4.如上述任意一项权利要求所述基于SIP的用户离线检测方法,其特征在于,所述心跳请求消息的内容仅由该用户终端的SIP资源标志符组成。
5.SIP用户状态检测系统,其特征在于,包括呈现服务器和至少一个用户终端,所述用户终端用于,向呈现服务器发送其上线的状态发布消息后,再向呈现服务器发送心跳请求消息;在接收到呈现服务器的心跳响应消息后,在本地记录心跳响应消息中的超时时间信息,根据该超时时间设置心跳维护周期,并在该心跳维护周期时间到达时向呈现服务器发送心跳请求消息;
所述呈现服务器用于,在用户终端对应的用户记录中的超时时间内,接收到用户终端发送的心跳请求消息后,用本地配置的时间值刷新该用户终端对应的用户记录中的超时时间且启动计时,并向该用户终端返回心跳响应消息;在所述超时时间内,未收到用户终端的心跳请求消息,则判断该用户离线,删除该用户终端对应的用户记录。
6.如权利要求5所述SIP用户状态检测系统,其特征在于,所述呈现服务器还用于接收到用户终端的心跳请求消息后,在无法找到该用户终端对应的用户记录时,向用户终端返回心跳错误响应消息。
7.如权利要求5所述SIP用户状态检测系统,其特征在于,所述用户终端还用于,接收到呈现服务器的心跳错误响应消息后,向呈现服务器发送其上线的状态发布消息。
8.如权利要求6所述SIP用户状态检测系统,其特征在于,所述心跳请求消息、心跳响应消息、心跳错误响应消息均基于用户数据报协议;所述心跳请求消息的内容仅由该用户终端的SIP资源标志符组成。
9.如权利要求5所述SIP用户状态检测系统,其特征在于,用户终端包括有第一SIP处理模块、第一心跳处理模块,
第一SIP处理模块用于,向呈现服务器发送其上线的状态发布消息,接收呈现服务器的确认消息;
第一心跳处理模块用于,向呈现服务器发送心跳请求消息,并在接收到呈现服务器的心跳响应消息后,在本地记录心跳响应消息中的超时时间信息,根据该超时时间设置心跳维护周期,并在该心跳维护周期时间到达时向呈现服务器发送用于心跳维护的心跳请求消息;在接收到呈现服务器的心跳错误响应消息后,通知第一SIP处理模块向呈现服务器发送其上线的状态发布消息。
10.如权利要求5或9所述SIP用户状态检测系统,其特征在于,所述呈现服务器包括有第二SIP处理模块、第二心跳处理模块;
第二SIP处理模块用于,接收到通知用户终端已经上线的状态发布消息后,在用户记录模块中创建该用户终端的用户记录,并接收第二心跳处理模块的通知,用本地配置的时间值刷新该用户终端对应的用户记录中的超时时间或者删除该用户终端对应的用户记录;
第二心跳处理模块用于,接收到用户终端发送的心跳请求消息后,通知第二SIP处理模块刷新该用户终端对应的用户记录中的超时时间,并向该用户终端返回包括有刷新后的超时时间信息的心跳响应消息;在用户终端对应的用户记录的超时时间内,未收到用户终端的心跳请求消息,则判断该用户离线,通知第二SIP处理模块删除该用户终端对应的用户记录,并通知其好友,该用户已经下线;以及接收到用户终端的心跳维护消息后,在无法找到该用户终端对应的用户记录时,向用户终端返回心跳错误响应消息。
基于SIP的用户离线检测方法以及SIP用户状态检测系统\n技术领域\n[0001] 本发明涉及即时通信领域的呈现(Presence)技术,特别涉及到SIP(Session Initiation Protocol,会话发起协议)系统中的呈现技术。\n背景技术\n[0002] 近年来,即时通信发展迅速,呈现(presence)和即时消息(Instant Message,简称IM)已经成为继语音、视频、短信之后的基本通信业务,成为越来越多的工作或者日常联系的沟通工具。在即时通信系统中,呈现用以传达某一用户通过一组设备进行通信的能力和意愿。以MSN Messenger为例,MSN v7.5为用户提供的可选的呈现状态包括:联机、忙碌、马上回来、离开、接听电话、外出就餐和显示为离线。呈现状态表征了用户当前处于的某种状态和用户进行通信的意愿。同时,呈现状态还能反映出与该用户进行通信的能力,比如若用户处于“离线”状态的话,别的用户的即时消息一股不能直接与其完成通信,除了离线状态之外的其它呈现状态均可笼统称为“在线”状态。因此,在SIP协议中,一个最简单的呈现过程如下:一个用户(称为watcher,观察者)订阅(SUBSCRIBE)他感兴趣的另一用户(presentity,被观察主体)的呈现状态,被观察主体接受订阅请求,以后被观察主体的状态发生变化之后他会发布(PUBLISH)自己的新状态,这个新状态会通知(NOTIFY)会到达观察者。每个用户的呈现状态均由呈现服务器维护。其中订阅(SUBSCRIBE)、发布(PUBLISH)、通知(NOTIFY)这样的动作是分别通过发送SUBSCRIBE消息(状态订阅消息)、PUBLISH消息(状态发布消息)、NOTIFY消息(状态通知消息)实现的。呈现服务器通过接收被观察主体的PUBLISH消息来更新主体的呈现状态。在观察者与被观察主体之间收发的SUBSCRIBE消息、NOTIFY消息均通过呈现服务器转发。这里的观察者、被观察主体严格上来说指网络中的通信实体,进行扩展后,也可泛指人。\n[0003] 随着市场对呈现和即时消息的通信业务需求日益增大,多种实现方式也相继出现。IETF(互联网工作任务组)在1998年成立了IMPP(Instant Message and Presence Protocol,呈现/即时消息协议)工作组,以设计出安全和灵活的呈现/即时消息协议。\nIMPP定义了必要的协议和数据格式,用来构建一个具有接收、发布能力的即时信息系统。现在IMPP工作组已经提出了各种不同的协议草案或建议,如:SIMPLE、XMPP、PRIM等。其中,SIMPLE(SIP Instant Messaging and Presence Leveraging Extensions,针对即时消息和呈现业务的利用扩展的会话初始化协议)是目前为止制定的较为完善的一个规范,SIMPLE规范是在2001年2月由IETF SIMPLE工作组正式提出的,是SIP协议针对IM/presence的扩展。\n[0004] 目前,许多公司都致力于在它们的即时通讯系统中实现SIMPLE这个协议。但是在SIMPLE规范中,没有对如何能够快速检测到用户离线动作的描述,且也没有其它即时通讯系统公开如何快速检测用户离线状态的实现,但此功能对用户来说又尤为重要,因为在实际应用中用户一股不会正常的关闭客户端软件(因为忘记或者觉得麻烦),这样呈现服务器就无法立即得知此用户已经离线的最新状态,很长一段时间都认为此用户在线。之所以会出现用户在未正常关闭客户端软件时离线后,很长时间不能被呈现服务器发现,是因为现有的用户的在线状态均是由该用户终端定期向呈现服务器发送PUBLISH消息以刷新呈现服务器上的状态;由于用户的状态随时在变化,PUBLISH消息的数据量比较大,从呈现服务器处理能力考虑,SIMPLE规范将PUBLISH消息中携带的超时时间值设置得很长,有\n3600s,在未正常关闭客户端软件而离线时,用户终端不会主动发送一个PUBLISH消息通知呈现服务器用户已经离线。所以只要该用户终端的超时时间未到,呈现服务器就不能发现该用户离线。因此,在PUBLISH消息中携带的超时时间值较大时,使得呈现服务器不能快速检测出用户已经离线。但如果单纯地缩短PUBLISH消息中携带的超时时间值,呈现服务器处理起来困难较大,容易耗尽CPU资源。\n发明内容\n[0005] 本发明所要解决的技术问题是,提供一种更即时、快速的基于SIP的用户离线检测方法以及实现该方法的SIP系统。\n[0006] 本发明为解决上述技术问题所采用的技术方案是,基于SIP的用户离线检测方法,包括步骤:\n[0007] 用户终端向呈现服务器发送其上线的状态发布消息后,向呈现服务器发送心跳请求消息;\n[0008] 呈现服务器接收到用户终端上线的状态发布消息后,创建该用户终端的用户记录,并在接收到该用户终端发送的心跳请求消息后,用本地配置的时间值刷新该用户终端对应的用户记录中的超时时间且启动计时,然后向该用户终端返回包括有刷新后的超时时间的心跳响应消息;\n[0009] 用户终端接收到呈现服务器的心跳响应消息后,在本地记录心跳响应消息中的超时时间,根据该超时时间设置心跳维护周期,并在该心跳维护周期时间到达时向呈现服务器发送用于心跳维护的心跳请求消息;\n[0010] 当该用户记录中的超时时间到达时,呈现服务器未收到用户终端的心跳请求消息,则判断该用户离线,删除该用户终端对应的用户记录;当在用户记录中的超时时间内,呈现服务器收到用户终端的心跳请求消息,则判断该用户在线,并刷新该用户终端对应的用户记录中的超时时间。\n[0011] 心跳请求消息中并不携带超时时间值,一是为了不增加心跳请求消息的数据量,二是将用户记录中的超时时间的配置交由呈现服务器,使得呈现服务器根据其处理能力动态配置该超时时间值成为可能。采用消息量很小的心跳请求消息对用户记录中的超时时间进行刷新,呈现服务器能轻松处理,使得用户记录中的超时时间值有条件设置得远远小于在PUBLISH消息中携带的超时时间值。由于大大减小了用户记录中的超时时间值,因此呈现服务器能够快速检测出用户是否离线。\n[0012] 具体的,所述心跳请求消息的内容仅由该用户终端的SIP资源标志符组成。\n[0013] 心跳请求消息中仅由该用户终端的SIP资源标志符组成,使得呈现服务器在收到心跳请求消息后,能够根据在SIP系统中唯一分配的SIP资源标志符找到该用户终端在呈现服务器中对应的用户记录。\n[0014] 进一步的,为了应对呈现服务器出现的异常情况:当呈现服务器收到用户终端的心跳请求消息,但无法找到该用户终端对应的用户记录时,则呈现服务器则向该用户终端返回心跳错误响应消息;所述心跳错误响应消息将触发用户终端向呈现服务器发送其上线的PUBLISH消息;呈现服务器接收到该PUBLISH消息后,立即创建该用户终端的用户记录。\n[0015] 具体的,心跳请求消息、心跳响应消息、心跳错误响应消息均基于用户数据报协议。\n[0016] 为实现上述方法的SIP用户状态检测系统,包括呈现服务器和多个用户终端,所述任一个用户终端用于,向呈现服务器发送其上线的状态发布消息后,再向呈现服务器发送心跳请求消息;在接收到呈现服务器的心跳响应消息后,在本地记录心跳响应消息中的超时时间信息,根据该超时时间设置心跳维护周期,并在该心跳维护周期时间到达时向呈现服务器发送心跳请求消息;\n[0017] 所述呈现服务器用于,在用户终端对应的用户记录中的超时时间内,接收到用户终端发送的心跳请求消息后,用本地配置的时间值刷新该用户终端对应的用户记录中的超时时间且启动计时,并向该用户终端返回心跳响应消息;在所述超时时间内,未收到用户终端的心跳请求消息,则判断该用户离线,删除该用户终端对应的用户记录。\n[0018] 进一步的,所述呈现服务器还用于,接收到用户终端的心跳请求消息后,在无法找到该用户终端对应的用户记录时,向用户终端返回心跳错误响应消息。\n[0019] 进一步的,所述用户终端还用于,接收收到呈现服务器的心跳错误响应消息后,向呈现服务器发送其上线的状态发布消息。\n[0020] 具体的,用户终端包括有第一SIP处理模块、第一心跳处理模块,[0021] 第一SIP处理模块用于,向呈现服务器发送其上线的状态发布消息,接收呈现服务器的确认消息;\n[0022] 第一心跳处理模块用于,向呈现服务器发送心跳请求消息,并在接收到呈现服务器的心跳响应消息后,在本地记录心跳响应消息中的超时时间信息,根据该超时时间设置心跳维护周期,并在该心跳维护周期时间到达时向呈现服务器发送用于心跳维护的心跳请求消息;在接收到呈现服务器的心跳错误响应消息后,通知第一SIP处理模块向呈现服务器发送其上线的状态发布消息。\n[0023] 具体的,呈现服务器包括有第二SIP处理模块、第二心跳处理模块;\n[0024] 第二SIP处理模块用于,接收到通知用户终端已经上线的状态发布消息后,在用户记录模块中创建该用户终端的用户记录,并接收第二心跳处理模块的通知,用本地配置的时间值刷新该用户终端对应的用户记录中的超时时间或者删除该用户终端对应的用户记录;\n[0025] 第二心跳处理模块用于,接收到用户终端发送的心跳请求消息后,通知第二SIP处理模块刷新该用户终端对应的用户记录中的超时时间,并向该用户终端返回包括有刷新后的超时时间信息的心跳响应消息;在用户终端对应的用户记录的超时时间内,未收到用户终端的心跳请求消息,则判断该用户离线,通知第二SIP处理模块删除该用户终端对应的用户记录;以及接收到用户终端的心跳维护消息后,在无法找到该用户终端对应的用户记录时,向用户终端返回心跳错误响应消息。\n[0026] 本发明的有益效果是,使得呈现服务器可以快速检测到用户离线,为呈现服务器向观察者更准确地反映被观察者主体的在线状态提供了条件,让即时通信系统对用户来说更加友好。\n附图说明\n[0027] 图1是本发明的基础网络结构;\n[0028] 图2是本发明的系统示意图;\n[0029] 图3是用户上线流程;\n[0030] 图4是用户心跳维护流程;\n[0031] 图5是心跳维护异常流程;\n[0032] 图6是检测到用户离线。\n具体实施方式\n[0033] 图1为实施本发明所基于的通信系统,也可理解为实施本发明的环境,包括终端\n1-n,n为大于等于2的整数值,通信网络和呈现服务器,通信系统基于SIP协议运作。终端具备接收和发送SIP消息(PUBLISH消息、NOTIFY消息、SUBSCRIBE消息)的能力。通信网络基于Internet,呈现服务器支持对用户状态的管理,是收集用户状态的汇聚点。\n[0034] 如图2所示,本发明的SIP用户状态检测系统另一个实施例,\n[0035] 包括多个用户终端、呈现服务器,则每个用户终端需包括有用户终端包括有用第一SIP处理模块和第一心跳处理模块;呈现服务器包括第二SIP处理模块和第二心跳处理模块,其中:\n[0036] 第一SIP处理模块用于,向呈现服务器发送其上线的状态发布消息,接收呈现服务器的确认消息;\n[0037] 第一心跳处理模块用于,向呈现服务器发送心跳请求消息,并在接收到呈现服务器的心跳响应消息后,在本地记录心跳响应消息中的超时时间信息,根据该超时时间设置心跳维护周期,并在该心跳维护周期时间到达时向呈现服务器发送用于心跳维护的心跳请求消息;在接收到呈现服务器的心跳错误响应消息后,通知第一SIP处理模块向呈现服务器发送其上线的状态发布消息。\n[0038] 第二SIP处理模块用于,接收到通知用户终端已经上线的状态发布消息后,在用户记录模块中创建该用户终端的用户记录,并接收第二心跳处理模块的通知,用本地配置的时间值刷新该用户终端对应的用户记录中的超时时间或者删除该用户终端对应的用户记录;\n[0039] 第二心跳处理模块用于,接收到用户终端发送的心跳请求消息后,通知第二SIP处理模块刷新该用户终端对应的用户记录中的超时时间,并向该用户终端返回包括有刷新后的超时时间信息的心跳响应消息;在用户终端对应的用户记录的超时时间内,未收到用户终端的心跳请求消息,则判断该用户离线,通知第二SIP处理模块删除该用户终端对应的用户记录;以及接收到用户终端的心跳维护消息后,在无法找到该用户终端对应的用户记录时,向用户终端返回心跳错误响应消息。\n[0040] 以终端1为被观察主体,终端2为观察者为例来描述从终端上线至其离线,呈现服务器对其进行在线检测的全过程:\n[0041] 如图3所示,终端1上线流程:\n[0042] a1、终端1上线后,先向呈现服务器发送PUBLISH消息通知呈现服务器终端1已经上线,随后立即再向呈现服务器发送一个UDP心跳请求消息;\n[0043] 终端1向呈现服务器发送的上线通知是SIP协议中标准的PUBLISH消息,该消息中携带了一个超时时间值为3600s秒;且终端1向呈现服务器发送的心跳请求消息为UDP报文,心跳请求消息的内容仅由该用户终端的SIP资源标志符组成。UDP心跳请求消息使用的传输层协议为UDP(用户数据报协议),应用层协议基于文本协议进行设计。\n[0044] a2、呈现服务器接收到通知终端1已经上线的PUBLISH消息后,创建终端1的用户记录:\n[0045] \n 用户名 超时时间\n 终端1@test.com 3600\n[0046] \n[0047] a3、呈现服务器向终端1回复200ok确认消息;\n[0048] a4、随后呈现服务器收到用户终端1的UDP心跳请求消息;\n[0049] UDP心跳请求消息的目的是刷新超时时间,但UDP心跳请求消息中并没有携带超时时间信息,呈现服务器根据本地配置的超时时间刷新终端1对应的用户记录中的超时时间。对于该刷新用户终端状态的超时时间,呈现服务器可以灵活设置,使得用户记录中的超时时间值有条件设置得远远小于在PUBLISH消息中携带的超时时间值。一股呈现服务器上配置的心跳维护周期为3-10分钟,也就是说3-10分钟就可以检查出用户离线,这比PUBLISH消息中携带3600秒要小很多。例如呈现服务器上本地配置的超时时间值为180秒;那么呈现服务器中终端1的用户记录会改为:\n[0050] \n 用户名 超时时间\n 终端1@test.com 180\n[0051] 此处呈现服务器配置的超时时间不建议过小,过小的话会导致心跳刷新风暴。\n[0052] a5、呈现服务器回复UDP心跳响应消息;心跳响应消息的内容中包括有刷新后的用户记录中的超时时间信息,消息格式为:Ok 180;\n[0053] 其中,字符串ok表示呈现服务器上已经成功刷新了该终端的用户记录的超时时间,180表示呈现服务器允许维护此用户记录的超时时间为180秒。那么,终端1在180秒后都不去刷新此用户记录的话,该用户记录就会超时,随后呈现服务器会删除此用户记录。\n[0054] a6、终端1收到此UDP心跳响应消息后,取得用户记录的超时时间,并在本地记录这个180秒的超时时间信息。\n[0055] 如图4,如果终端1和呈现服务器之间的网络正常,会进行心跳的维护,心跳的维护主要的目的是刷新用户记录的超时时间:请求和响应的内容与上述步骤a4和a5中描述的一致:呈现服务器接收到该终端1发送的心跳请求消息,呈现服务器根据本地配置的超时时间刷新该终端对应的用户记录中的超时时间,并向终端1返回心跳响应消息;\n[0056] 终端1接收到UDP心跳响应消息后,在本地记录UDP心跳响应消息中的超时时间信息,并根据该UDP心跳响应消息中的超时时间信息,终端1设置向呈现服务器发送UDP心跳请求消息心跳维护周期,从而在该心跳维护周期到达时,发送心跳请求消息报文,以维护当前终端1的在线状态,并重新刷新终端1对应的用户记录中的超时时间。该心跳维护周期的设计为小于呈现服务器上配置的超时时间的一个值,一股不宜设计为小于超时时间过大,否则会导致终端频繁的发送UDP心跳请求消息,本实施例中终端1根据180秒的超时时间设置心跳维护周期为120秒,即终端1在接收到UDP心跳响应消息后开始计时,在第120秒到达时向呈现服务器发送UDP心跳请求消息;假如120秒后,呈现服务器收到从终端1发来的UDP心跳请求消息,呈现服务器上所维护的终端1的用户记录的超时时间重新刷新为\n180秒,如下:\n[0057] \n 用户名 超时时间\n 终端1@test.com 180\n[0058] 随后呈现服务器开始计时,即超时时间会进行递减,等待下一轮的刷新。这样的好处是用户刷新的PUBLISH消息就不需要发送了,取而代之的是UDP心跳请求消息,因为UDP心跳请求消息的消息量很小,呈现服务器处理起来也很轻松,如果使用PUBLISH来进行心跳维护的话,呈现服务器很快就没有CPU资源了。\n[0059] 如图5所示,呈现服务器也应该处理一些异常情况:\n[0060] b1、终端1向呈现服务器发送了UDP心跳请求消息,但是当呈现服务器进行处理的时候,却发现在呈现服务器上没有终端1所对应的用户记录,这是一种比较严重的错误,因为UDP心跳请求消息的唯一目的是去刷新用户记录的超时时间,而不是去创建一个新的用户记录。这可能是呈现服务器的问题也可能是终端1没有按照180秒的约定去定时的刷新用户记录所致;\n[0061] b2、这个时候呈现服务器需要向终端1回复如下所示的UDP心跳错误响应:Error errono reason;\n[0062] 其中,Error表示这是错误响应;Errno表示错误码;Reason描述了错误的原因信息;\n[0063] b3、终端1在收到了这样的UDP心跳错误响应以后,需要重新向呈现服务器发送PUBLISH消息,以便在呈现服务器上重新创建终端1的用户记录。\n[0064] 如图6所示,当终端1和呈现服务器之间的网络出现问题的时候,无论终端1如何发送心跳请求消息求,都无法刷新呈现服务器上对应的用户记录中超时时间;最终,呈现服务器在180秒的超时时间到达后,则会认为终端1离线,终端1的用户记录被呈现服务器删除,之后,呈现服务器使用标准NOTIFY消息,通知终端2,终端1已经离线了。
法律信息
- 2013-03-20
- 2011-02-02
实质审查的生效
IPC(主分类): H04L 29/06
专利申请号: 201010259183.0
申请日: 2010.08.20
- 2010-12-15
引用专利(该专利引用了哪些专利)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 |
1
| |
2007-09-26
|
2007-03-27
| | |
2
| |
2009-10-07
|
2009-05-14
| | |
3
| |
2004-06-02
|
2002-11-19
| | |
被引用专利(该专利被哪些专利引用)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 | 该专利没有被任何外部专利所引用! |