CN107770033A - 一种多系统中的终端之间通信的方法及装置 - Google Patents
一种多系统中的终端之间通信的方法及装置 Download PDFInfo
- Publication number
- CN107770033A CN107770033A CN201610674892.2A CN201610674892A CN107770033A CN 107770033 A CN107770033 A CN 107770033A CN 201610674892 A CN201610674892 A CN 201610674892A CN 107770033 A CN107770033 A CN 107770033A
- Authority
- CN
- China
- Prior art keywords
- terminal
- message
- rcs
- app
- type
- 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.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
- H04L51/043—Real-time or near real-time messaging, e.g. instant messaging [IM] using or handling presence information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/56—Unified messaging, e.g. interactions between e-mail, instant messaging or converged IP messaging [CPM]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Transfer Between Computers (AREA)
Abstract
本发明的实施例提供一种多系统中的终端之间通信的方法及装置,其中方法包括:获取第一类型终端采用第一通信系统进行登录的第一登录状态信息以及第二类型终端采用第二通信系统进行登录的第二登录状态信息,并将第一登录状态信息和第二登录状态信息存储在用户状态数据库中;第一类型终端和第二类型终端是基于相同应用的相同帐户进行登录的不同类型的终端;将第一登录状态信息和第二登录状态信息发送给在后登录的第二类型终端对应的第二通信系统,使第二通信系统根据第一登录状态信息和第二登录状态信息,以及预先存储的不同类型终端之间的登录冲突规则,确定是否允许第二类型终端进行登录。本发明的方案实现多个通信系统中的终端之间相同通信。
Description
技术领域
本发明涉及通信技术领域,特别是指一种多系统中的终端之间通信的方法及装置。
背景技术
在4G移动互联网时代,互联网厂家在移动应用领域快速发展,出现了微信、QQ、米聊等一批OTT应用,它们具有免费、体验丰富等特色,并且迭代快速,能不断为用户提供新业务特性,因此逐渐蚕食着运营商的用户群与收入。
为解决这个问题,运营商大多采用了两种不同的方式,推出了自身的融合通信即时消息业务:
第一种是运营商直接学习互联网厂家,推出自身使用OTT技术,基于私有通信协议实现的即时消息软件(以下称OTT私有系统,使用的终端称为OTTAPP),例如中国移动的飞信和中国电信的易信等,这种方式完全使用互联网解决方案,用户需要下载安装特定的APP,并进行注册账户(对于运营商的OTT即时消息软件,通常使用手机号作为用户账号进展注册,即用户名为手机号,而实际消息路由分发等使用OTT内部标识);
第二种是使用电信国际标准,通过对GSMARCS即融合通信国际协议的支持实现即时消息系统(以下称融合通信标准即时消息系统),如中国移动融合通信。该方式又分为推动手机厂家升级终端上原有的通话、短/彩信和通讯录三大通信入口,以终端原生方式(Native,即终端在出厂时就已具备功能)的支持即时消息(以下称标准Native方式,使用的终端称为Native终端),和下载基于融合通信标准的APP实现的即时消息(以下称标准APP方式,使用的终端称为RCS APP)。由于使用国际标准,该方式保证了运营商基础通信业务全球可达性和电信级服务质量,可以说,该方式是以通信能力为核心的方式。
部分较大的运营商,如中国移动,由于自身具备较强的技术能力,同时具有较强的产业推动力,因此同时具有融合通信标准即时消息系统和OTT私有即时消息系统,这样,同一个用户可能在拥有Native终端的同时使用APP,而APP可能是OTT APP也可能是RCS APP,同时,这个用户还可能具有PC客户端、Pad客户端等各种客户端,这样,同一个用户就会拥有很多不同的终端,而同一终端上具有相同功能的APP或Native入口也可能有多个,这样,如果消息分别发到他的不同终端不同入口,这个用户就需要在不同终端不同入口间反复切换,会给用户的使用带来困扰。同时,运营商传统的短彩信系统仍然存在,这就会进一步加大用户使用的困难。
将运营商拥有的众多消息通道,包括电信标准即时消息通道、OTT即时消息通道、传统短彩信通道进行合理整合,使用户具有的不同消息入口具有较好使用感受,是运营商提升用户消息体验,增加用户粘性的重要手段。例如:对于不同终端,保证都收到全量消息,用户看不同终端时,都可以有完整消息历史,但是,只在用户目前有操作的终端进行声音等提示,其他终端进行静默处理;对于同一终端,只有1个消息入口显示消息(或者是终端Native原生消息入口,或者是唯一一个APP消息入口,不需要在各消息入口反复切换)。
对于这类多终端场景,目前现有技术一般分为IMS系统内的多终端处理方式和OTT系统内的多终端处理方式两种,其中:
IMS多终端消息机制如图1所示,该方式要求同一用户使用的全部终端均基于SIP实现,都具有同样的SIP用户身份标识(IMPI/IMPU),通过不同的SIP实例(sip.instance或GRUU)在IMS中进行注册,对于不同的终端,有2种处理方式:终端标识完全相同,后注册的终端将先注册的终端踢下线,只有在线的终端会收到消息。
不同终端通过GRUU或sip.instance等参数进行区别,可同时注册,所有消息都被存入集中消息存储平台中,在接收消息时,通过IMS的forking机制将同一个消息复制成多份,分别发到每一个终端实例,对于不在线的终端,在其上线后通过集中消息存储平台使用推送的方式实现消息同步。
OTT即时消息系统使用的方式与之类似,但一般多个终端分为主终端和从终端(例如微信与微信web版)。通常,一个设备上,同一个账户只能有一个终端登录(例如手机上不能登录2个同账户的微信),此外,从终端的登录需要依赖于主终端,如手机登录时,才能有PC侧Web客户端登录等。对于接收方有多个设备的场景,一般发送时根据接收方登录状态将消息分别写入多个消息队列中,并且分别通知接收方的各个终端有消息更新,由接收方对比本地消息记录后,到服务器拉取相应消息,此后接收设备通知服务器某消息已接收,服务器可以将该设备的这部分消息在应消息队列中置为已读。
对于具有多个消息系统的运营商,各类型终端的即时消息下发通道如图3所示。可见,各消息系统是分别独立的竖井式结构,用户拥有的多个终端和消息入口关系也较为复杂,现有的技术方案无法实现这种场景下的多终端管理与消息需求。
上述图1和图2,不管是IMS系统中的多终端方案,还是OTT系统中的多终端方案,均不能满足统一运营商IMS消息系统与OTT消息系统共存,多终端分别存在于不同系统内的场景,即不能统一管理不同系统内的多个终端。也因为各个系统相互独立,无法实现消息在不同系统内的终端之间的分发,IMS系统内的消息只能发到IMS系统内的终端,OTT系统内的消息也只能发到OTT系统内的终端。
发明内容
本发明提供了一种多系统中的终端之间通信的方法及装置,从而实现多个通信系统中的终端之间相同通信。
为解决上述技术问题,本发明的实施例提供如下方案:
一种多系统中的终端之间通信的方法,包括:
获取第一类型终端采用第一通信系统进行登录的第一登录状态信息以及第二类型终端采用第二通信系统进行登录的第二登录状态信息,并将所述第一登录状态信息和所述第二登录状态信息存储在用户状态数据库中;所述第一类型终端和所述第二类型终端是基于相同应用的相同帐户进行登录的不同类型的终端;
将所述第一登录状态信息和第二登录状态信息发送给在后登录的第二类型终端对应的第二通信系统,使所述第二通信系统根据所述第一登录状态信息和第二登录状态信息,以及预先存储的不同类型终端之间的登录冲突规则,确定是否允许所述第二类型终端进行登录。
其中,所述登录冲突规则包括:所述第一类型终端为出厂即可支持即时消息收发并支持安装其它即时消息应用的Native的终端,所述第二类型终端为出厂即可支持即时消息收发但不支持安装其它即时消息应用非Native的终端时,两种类型的终端均可同时在线。
其中,所述登录冲突规则包括:所述第一类型终端为安装即时消息应用富媒体通信RCS APP1的终端,所述第二类型终端为安装RCS APP1的终端时,两种类型的终端均可同时在线,但与安装RCS APP2、OTT APP 1和OTT APP2的终端均不可同时在线,在后登录的将在前登录的踢下线;其中,RCS APP1与所述RCS APP2是基于相同通信协议的不同应用,OTTAPP 1与OTT APP 2是基于相同通信协议的不同应用。
所述登录冲突规则包括:所述第一类型终端为安装即时消息应用富媒体通信RCSAPP2的终端,所述第二类型终端为安装RCS APP2的终端时,两种类型的终端均可同时在线,但与安装RCS APP1、OTT APP 1和OTT APP 2的终端均不可同时在线,在后登录的将在前登录的踢下线;其中,RCS APP1与所述RCS APP2是基于相同通信协议的不同应用,OTT APP 1与OTT APP 2是基于相同通信协议的不同应用。
所述登录冲突规则包括:所述第一类型终端为安装私有通信协议的即时消息应用OTT APP 1的终端,所述第二类型终端为安装OTT APP 1时,两种类型的终端均可同时在线,但与安装RCS APP1、RCS APP 2和OTT APP 2的终端均不可同时在线,在后登录的将在前登录的踢下线;其中,RCS APP1与所述RCS APP2是基于相同通信协议的不同应用,OTT APP 1与OTT APP 2是基于相同通信协议的不同应用。
所述登录冲突规则包括:所述第一类型终端为安装私有通信协议的即时消息应用OTT APP 2的终端,所述第二类型终端为安装OTT APP 2的终端时,两种类型的终端均可同时在线,但与安装RCS APP1、RCS APP 2和OTT APP1的终端均不可同时在线,在后登录的将在前登录的踢下线;其中,RCS APP1与所述RCS APP2是基于相同通信协议的不同应用,OTTAPP 1与OTT APP 2是基于相同通信协议的不同应用。
所述登录冲突规则包括:所述第一类型终端为计算机PC1,所述第二类型终端为计算机PC2时,两种终端不可同时在线,在后登录的将在前登录的踢下线;其中,PC1与PC2为不同的计算机。
其中,不同类型的终端,用终端标识进行区分:Native的终端,通过基于会话初始协议的实例sip.instance=imei,获得终端标识;安装RCS APP 1的终端,通过基于会话初始协议的实例sip.instance=UUid1获得终端标识;安装RCS APP 2的终端,通过基于会话初始协议的实例sip.instance=UUid2获得终端标识;安装OTT APP 1的终端,对应的终端标识为Eid1;安装OTT APP 2的终端,对应的终端标识为Eid2;PC1终端,对应的终端标识为PCid1;PC2终端,对应的终端标识为PCid2;其中,Eid1与Eid2不同,PCid1与PCid2不同。
其中,多系统中的终端之间通信的方法还包括:获取发送终端发送的消息,存储在该发送终端的第一消息队列中;
从所述用户状态数据库中获取当前处于登录状态的至少一个类型的接收方终端;
根据所述消息,分别为所述至少一类型的接入方终端的通知队列中写入一个通知消息,并由所述至少一个类型的接收方终端对应的系统服务器,将通知队列中的通知消息分别发送给接收方终端。
其中,多系统中的终端之间通信的方法还包括:发送终端的第一消息队列向接收方终端的第二消息队列进行消息同步。
其中,所述发送终端发送的消息中具有一标识,所述标识用于标识:该消息是发送终端向与所述发送终端同时处于登录状态且基于相同应用的相同帐户的接收终端发送的。
其中,发送终端的第一消息队列向接收方终端的第二消息队列进行消息同步后还包括:至少一个类型的接收方终端对应的通信系统,将此次更新的消息发送给接收方终端。
其中,多系统中的终端之间通信的方法还包括:接收方终端在接收到此次更新的消息时,该此次更新的消息如果已经在所述至少一个类型的其它接收方终端上接收过,则该接收方终端进行静默处理。
其中,多系统中的终端之间通信的方法还包括:若至少一个类型的接收方终端中,只有出厂即可支持即时消息收发但不支持安装其它即时消息应用的非Native终端处于登录状态,则由非Native终端采用的通信系统将此次更新的消息转为短信或者彩信,通过短信中心发送给接收方终端。
本发明的实施例还提供一种多系统中的终端之间通信的装置,包括:
获取模块,用于获取第一类型终端采用第一通信系统进行登录的第一登录状态信息以及第二类型终端采用第二通信系统进行登录的第二登录状态信息,并将所述第一登录状态信息和所述第二登录状态信息存储在用户状态数据库中;所述第一类型终端和所述第二类型终端是基于相同应用的相同帐户进行登录的不同类型的终端;
发送模块,用于将所述第一登录状态信息和第二登录状态信息发送给在后登录的第二类型终端对应的第二通信系统,使所述第二通信系统根据所述第一登录状态信息和第二登录状态信息,以及预先存储的不同类型终端之间的登录冲突规则,确定是否允许所述第二类型终端进行登录。
其中,所述登录冲突规则包括:所述第一类型终端为出厂即可支持即时消息收发并支持安装其它即时消息应用的Native的终端,所述第二类型终端为出厂即可支持即时消息收发但不支持安装其它即时消息应用非Native的终端时,两种类型的终端均可同时在线;或者
所述第一类型终端为安装即时消息应用富媒体通信RCS APP1的终端,所述第二类型终端为安装RCS APP1的终端时,两种类型的终端均可同时在线,但与安装RCS APP2、OTTAPP 1和OTT APP 2的终端均不可同时在线,在后登录的将在前登录的踢下线;或者
所述第一类型终端为安装即时消息应用富媒体通信RCS APP2的终端,所述第二类型终端为安装RCS APP2的终端时,两种类型的终端均可同时在线,但与安装RCS APP1、OTTAPP 1和OTT APP 2的终端均不可同时在线,在后登录的将在前登录的踢下线;或者
所述第一类型终端为安装私有通信协议的即时消息应用OTT APP 1的终端,所述第二类型终端为安装OTT APP 1时,两种类型的终端均可同时在线,但与安装RCS APP1、RCSAPP 2和OTT APP 2的终端均不可同时在线,在后登录的将在前登录的踢下线;或者
所述第一类型终端为安装私有通信协议的即时消息应用OTT APP 2的终端,所述第二类型终端为安装OTT APP 2的终端时,两种类型的终端均可同时在线,但与安装RCSAPP1、RCS APP 2和OTT APP 1的终端均不可同时在线,在后登录的将在前登录的踢下线;或者
所述第一类型终端为计算机PC1,所述第二类型终端为计算机PC2时,两种终端不可同时在线,在后登录的将在前登录的踢下线;
其中,RCS APP1与所述RCS APP2是基于相同通信协议的不同应用,OTT APP 1与OTT APP 2是基于相同通信协议的不同应用,PC1与PC2为不同的计算机。
其中,不同类型的终端,用终端标识进行区分:Native的终端,通过基于会话初始协议的实例sip.instance=imei,获得终端标识;安装RCS APP 1的终端,通过基于会话初始协议的实例sip.instance=UUid1获得终端标识;安装RCS APP 2的终端,通过基于会话初始协议的实例sip.instance=UUid2获得终端标识;安装OTT APP 1的终端,对应的终端标识为Eid1;安装OTT APP 2的终端,对应的终端标识为Eid2;PC1,对应的终端标识为PCid1;PC2,对应的终端标识为PCid2;其中,Eid1与Eid2不同,PCid1与PCid2不同。
其中,多系统中的终端之间通信的装置还包括:消息同步模块,用于获取发送终端发送的消息,存储在该发送终端的第一消息队列中;从所述用户状态数据库中获取当前处于登录状态的至少一个类型的接收方终端;根据所述消息,分别为所述至少一类型的接入方终端的通知队列中写入一个通知消息,并由所述至少一个类型的接收方终端对应的系统服务器,将通知队列中的通知消息分别发送给接收方终端。
其中,所述消息同步模块还用于:发送终端的第一消息队列向接收方终端的第二消息队列进行消息同步。
其中,所述发送终端发送的消息中具有一标识,所述标识用于标识:该消息是发送终端向与所述发送终端同时处于登录状态且基于相同应用的相同帐户的接收终端发送的。
其中,多系统中的终端之间通信的装置还包括:至少一个类型的接收方终端对应的通信系统,将此次更新的消息发送给接收方终端。
其中,多系统中的终端之间通信的装置还包括:接收方终端在接收到此次更新的消息时,该此次更新的消息如果已经在所述至少一个类型的其它接收方终端上接收过,则该接收方终端进行静默处理。
其中,多系统中的终端之间通信的装置还包括:若至少一个类型的接收方终端中,只有出厂即可支持即时消息收发但不支持安装其它即时消息应用的非Native终端处于登录状态,则由非Native终端采用的通信系统将此次更新的消息转为短信或者彩信,通过短信中心发送给接收方终端。
本发明的上述方案至少包括以下有益效果:
本发明的上述方案,通过获取第一类型终端采用第一通信系统进行登录的第一登录状态信息以及第二类型终端采用第二通信系统进行登录的第二登录状态信息,并将所述第一登录状态信息和所述第二登录状态信息存储在用户状态数据库中;所述第一类型终端和所述第二类型终端是基于相同应用的相同帐户进行登录的不同类型的终端;将所述第一登录状态信息和第二登录状态信息发送给在后登录的第二类型终端对应的第二通信系统,使所述第二通信系统根据所述第一登录状态信息和第二登录状态信息,以及预先存储的不同类型终端之间的登录冲突规则,确定是否允许所述第二类型终端进行登录。实现不同系统间的多终端在线状态管理和消息通信管理。
附图说明
图1为现有技术中,IMS多终端消息通信机制;
图2为现有技术中,OTT系统多终端消息通信机制;
图3为现有技术中,各类型终端的即时消息下发通道的示意图;
图4为本发明的多系统中的终端之间通信的方法流程图;
图5为本发明的多系统中的终端之间通信的系统架构图;
图6为本发明的多系统中的终端之间通信的方法中,初始时用户终端状态示意图;
图7为本发明的多系统中的终端之间通信的方法中,用户OTT APP 1在终端B上线的示意图;
图8为本发明的多系统中的终端之间通信的方法中,用户OTT APP在Native终端上登录的示意图;
图9为本发明的多系统中的终端之间通信的方法中,用户PC APP注销的状态示意图;
图10为本发明的多系统中的终端之间通信的方法的另一流程图;
图11为图10所示流程中,主叫侧多终端消息发送流程;
图12为图10所示流程中,被叫侧多终端消息接收流程;
图13为图10所示流程中,被叫只有短信终端在线的流程。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。
针对现有技术中,各个通信系统相互独立,无法实现消息在不同系统内的终端之间的分发,IMS系统内的消息只能发到IMS系统内的终端,OTT系统内的消息也只能发到OTT系统内的终端的问题,本发明的实施例通过建立统一数据层,将各系统的终端状态数据和消息数据等数据整合到统一数据层中的方式,实现不同系统间的多终端在线状态管理和消息管理。
如图4所示,本发明的实施例提供一种多系统中的终端之间通信的方法,包括:
步骤41:获取第一类型终端采用第一通信系统进行登录的第一登录状态信息以及第二类型终端采用第二通信系统进行登录的第二登录状态信息,并将所述第一登录状态信息和所述第二登录状态信息存储在用户状态数据库中;所述第一类型终端和所述第二类型终端是基于相同应用的相同帐户进行登录的不同类型的终端;
步骤42:将所述第一登录状态信息和第二登录状态信息发送给在后登录的第二类型终端对应的第二通信系统,使所述第二通信系统根据所述第一登录状态信息和第二登录状态信息,以及预先存储的不同类型终端之间的登录冲突规则,确定是否允许所述第二类型终端进行登录。
本发明的该实施例中,多系统可以是针对同一运营商拥有多个不同的即时消息系统以及传统短彩信系统,用户具有多个不同的终端,并且同一终端上可能有不同的Native/APP入口的场景,通过建立统一数据层,将各系统的终端数据和消息数据等数据整合到统一数据层中的方式,实现不同系统间的多终端在线状态管理和消息管理。
本发明的实施例中,客户端可以类型分为以下4类:
1.1)PC类客户端:基于PC OTT私有协议实现的PC上的APP。
1.2)RCS APP类客户端:基于RCS标准实现的手机上的APP。
1.3)OTT APP类客户端:基于手机OTT私有协议实现的手机上的APP。
1.4)Native:手机原生消息入口,若已升级具备RCS消息能力,则可以收发RCS即时消息、短彩信,否则只能收发短彩信。该类型为独立类型,手机客户端APP与native,不论APP与native是否处于同一终端上,均可以同时在线。
客户端的在线规则,即各类型的终端的登录冲突规则如下:
2.1)Native终端因为与用户SIM卡绑定,每个用户只能有唯一的Native终端,并且该终端不能被其他终端踢下线。
2.2)当Native终端具有数据连接时,它具有RCS即时消息接收能力。
2.3)当Native终端没有数据连接时,依然具有传统短彩信接收能力。
2.4)非Native终端,只有短彩信接收能力。
2.5)RCS APP与OTT APP都可以安装在Native终端或非Native终端上。
2.6)同一终端上,RCS APP与OTT APP只能有一个在线,后上线的客户端将另外的客户端踢下线。
2.7)同一类型客户端不同版本不能同时在线。
2.8)当Native终端上安装APP时,不管是哪一个版本的APP,即时消息都将只送给Native终端,若用户直接从APP入口进入,则APP从Native终端的数据库中读取历史记录。
2.9)PC客户端可与手机Native/APP同时在线,并且会收到全部消息。
各类终端之间的冲突关系如表1所示。若有不同的冲突规则,则可以通过重新对该冲规则表进行配置的方式实现新的规则。
表1
其中,上述表格中,N/A表示允许在线,╳表示不允许在线。当登录的终端间存在冲突时,均为后登录的终端将先登录的终端踢下线。
对于不同终端,通过其设备标识进行区别:
3.1)Native终端以及RCS APP都是基于融合通信标准即时消息系统的,使用基于IMS的RCS标准,其标识都基于IMS码号体系:Native设备标识和设备类型通过sip.instance=imei获得;RCS APP设备标识和设备类型通过sip.instance=uuid获得。
3.2)OTT允许在不同设备上分别注册登录,每在一个设备上注册时,由OTT服务器为该设备分配一个设备标识,形如:APP1:标识为eid1,APP2:标识为eid2;
3.3)PC客户端与OTT APP类似:PC客户端1:标识为PCid1,PC客户端2:标识为PCid2;其中,Eid1与Eid2不同,PCid1与PCid2不同。
各类终端标识如表2所示。
表2
如图5所示,为实现上述方法的系统架构,为在同一运营商拥有多个不同的即时消息系统以及传统短彩信系统之上设置统一的用户状态数据库,在各即时消息系统和短信系统之上设置统一消息队列。图中,单向实线箭头表示消息下发,双向虚线箭头表示可安装,双向实线箭头表示可读取消息。
原本相互独立的各竖井式消息系统需要于新设的用户状态数据库对接,将各自终端在自身系统内的登录状态经过数据接口提交给用户状态数据库,接收用户状态数据库返回的该用户全部登录设备的状态信息。
原本相互独立的各竖井式消息系统需要于新设的统一消息队列对接,该消息队列又分为消息队列和通知队列两部分,消息队列用于存储收发的消息本身,通知队列用于通知各对应终端有新消息到来。
多终端登录管理方法的一具体实现实例:用户的各类设备登录或注销时,其接入系统中的对应服务器(RCS即时消息系统中的IM AS,OTT即时消息系统中的OTT AS,PC系统中的PC AS)均需要将设备的登录或注销信息写入用户状态数据库(用户的短信默认在线,用户状态数据库中默认有短信终端信息,除非用户在CS(电路)域已不可达),用户状态数据库向该服务器返回的信息中带有该用户全部登录设备的信息。
各系统中的服务器根据数据库返回和设备互斥策略判断是否需要将其他端踢下线,若需要则向该端所在服务器发起注销请求。因为短彩信系统不与其他系统互斥,所以短彩信中心不需要向其他系统发起注销请求。
举例步骤如下:
(1)用户Native终端(号码为138XXXXXXXX)在线,如图6所示,有一个RCS APP安装在Native终端上,则此时用户状态数据库内的信息如下表3所示:
表3
(2)用户用OTT APP在终端B(号码为139XXXXXXXX)上登录,如图7所示,OTT AS为其分配eid1,并将OTT APP在终端B登录的信息写入用户状态数据库,用户状态数据库返回当前全部在线终端信息给OTT AS,OTTAS根据冲突规则,判断目前不存在冲突,不需要发起注销请求。
此时,用户的状态信息如下表4:
表4
(3)用户OTT APP在Native终端上登录,如图8所示。OTT AS为其分配eid2,并将OTTAPP在终端B登录的信息写入用户状态数据库,用户状态数据库返回当前全部在线终端信息给OTT AS,OTT AS根据冲突规则,判断同一终端上存在RCS APP与OTT APP2之间的冲突,因此后登录的OTT APP2需要将先登录的RCS APP踢下线,因此,OTT AS通过Network API调用方式,向RCS AS发起注销请求,将RCS即时消息系统中的RCS APP踢下线。此时用户的状态如下表5所示:
表5
(4)终端注销时,同理。如图9所示。例如,用户PC APP注销,则PCAS将此信息写入用户状态数据库,用户状态数据库返回当前全部在线终端信息给PC AS,此时终端无冲突,不需要发起注销。
此时用户的状态如下表6所示:
表6
如图10所示,本发明的实施例提供一种多系统中的终端之间通信的方法,包括:
步骤101:获取第一类型终端采用第一通信系统进行登录的第一登录状态信息以及第二类型终端采用第二通信系统进行登录的第二登录状态信息,并将所述第一登录状态信息和所述第二登录状态信息存储在用户状态数据库中;所述第一类型终端和所述第二类型终端是基于相同应用的相同帐户进行登录的不同类型的终端;
步骤102:将所述第一登录状态信息和第二登录状态信息发送给在后登录的第二类型终端对应的第二通信系统,使所述第二通信系统根据所述第一登录状态信息和第二登录状态信息,以及预先存储的不同类型终端之间的登录冲突规则,确定是否允许所述第二类型终端进行登录;
步骤103:获取处于登录状态的发送终端发送的消息,存储在该发送终端的第一消息队列中;其中,所述发送终端发送的消息中具有一标识,所述标识用于标识:该消息是发送终端向与所述发送终端同时处于登录状态且基于相同应用的相同帐户的接收终端发送的;
步骤104:从所述用户状态数据库中获取当前处于登录状态的至少一个类型的接收方终端;
步骤105:根据所述消息,分别为所述至少一类型的接入方终端的通知队列中写入一个通知消息,并由所述至少一个类型的接收方终端对应的系统服务器,将通知队列中的通知消息分别发送给接收方终端;
并进一步的,该方法还可以包括:
步骤106:发送终端的第一消息队列向接收方终端的第二消息队列进行消息同步。
步骤107:至少一个类型的接收方终端对应的通信系统,将此次更新的消息发送给接收方终端。
步骤108:接收方终端在接收到此次更新的消息时,该此次更新的消息如果已经在所述至少一个类型的其它接收方终端上接收过,则该接收方终端进行静默处理。
本发明的该实施例中,在短信系统之上设置统一消息队列的方式实现多终端消息收发,其中又可以包括主叫侧的多终端消息发送机制和被叫侧的多终端消息接收机制。主叫侧多终端消息发送机制如下:
每个用户(电话号码)具有一个归属的消息队列,作为主队列,非用户归属的另一节点的消息队列作为从队列,与主队列保持同步;主叫发出的消息同时写入自身接收消息队列中,用于实现主叫侧其他端的抄送。消息下发方式与接收方相同,但消息中带有特殊标识,表明这是一条自身的消息。主叫其他终端不形成递送报告消息。
如图11所示,主叫侧多终端消息发送流程:
①主叫A发送一条消息;
②其归属的服务器将消息写入自身的接收消息队列,此消息有特殊标志标明是一条自身发送的消息;
③消息队列数据库服务根据A用户状态数据库内的信息,查询用户A有哪些端在线,写入相应通知队列;
④通知队列通知相应服务器由新消息;
⑤相应服务器从消息队列拉取消息;
⑥相应服务器将消息下发给主叫A其他端,其他端根据消息内标志判断这是一条自身发送的消息,显示在发送消息中。因为这些消息不会提示给发送用户,因此虽然发送方用户的其他端都会收到该用户发出的同样的消息记录,但是该用户不需要在自己的各个消息入口之间切换。
此后,发送方用户A的消息队列向接收方用户B的消息队列进行消息同步。
被叫侧多终端消息接收机流程如下:
被叫侧同样采用统一消息队列提供被叫侧多终端消息接收,处理规则如下:
同一用户的不同终端设备在一个消息通知队列中分别设置不同的指针,用于标识该终端所取到的消息。若当前被叫用户B状态数据库中,被叫用户B的手机号码的那部手机上除了短信外,没有任何终端在线,即没有通知队列需要被写入时,各服务器获得的用户在线列表也为空,这种状态下,RCS AS会将此即时消息拉取过来,并将其转为短信,通过短信方式投递给被叫用户B。因为只有基于电信标准的RCS融合通信即时消息系统具有与电信信令网内的短信交互的能力,因此转短信的功能需要由RCS AS完成。若某一设备的指针低于该用户的最高指针,则表明该终端的消息需要进行静默处理。各终端递送报告同样按照消息规则写入消息队列,对于已送达和已读报告,消息队列进行排重处理,只保留第一个递送报告。对于已转短信报告,由IMS AS单独作为新一条消息写入消息队列,与其他递送报告不做排重处理。
如图12所示,被叫侧多终端消息接收流程:首先,完成用户B消息队列写入/同步,以及通知队列写入。根据用户B用户状态数据库查询当前B的在线终端,例如,此时接收方用户B有Native和PC客户端,且最新消息的状态如下:
流程包括:
①通知Native和PC客户端有新消息;
②IMS AS获取IMS客户端当前指针以后的消息(73-85),将Native指针更新到85,最新已读更新到85;
③IMS服务器采用IMS方式推送给RCS Native;
④PC客户端上线或用户点击接收消息;
⑤PC服务器获取PC客户端当前指针以后的消息(56-85),将PC指针更新到85;
⑥PC客户端获取消息前指针55小于最高已读指针85,PC需做静默处理,PCAS在下发消息中添加静默标志,即用户其他在线终端虽然仍会收到同样的消息,但是不会提醒用户,用户也不需要在各个消息入口之间来回切换。当用户主动从另一个消息入口进入时,因为之前该入口已经收到过消息,因此仍能看到同样的消息记录。
如图13所示,当被叫方只有短信在线时,流程包括:
完成用户B消息队列写入/同步,以及通知队列写入。根据用户B用户状态数据库查询当前B的在线终端。且最新消息的状态如下:
最新消息 | 85 |
最新已读 | 85 |
RCS Native | 85 |
RCS APP | 60 |
OTT APP 1 | 68 |
OTT APP 2 | 3 |
PC | 85 |
流程如下:
①用户状态数据库查询发现发往被叫用户B的手机号码的那部手机上目前所有具有即时消息能力的终端都不在线,则需要通知具有转短信能力的RCS AS来拉取新的消息;
②RCS AS查询目前最新已读到最新消息之间有3条消息(86-88),则将这3条消息拉倒本地,将RCS Native的最新已读指针置为88;
③RCS AS将这3条消息转为短信,通过7号信令网发往主叫用户的短信中心;
④主叫用户的短信中心按照标准短信流程将3条短信发送给被叫用户B。
本发明的上述实施例中,多个系统可以是同一运营商拥有的多个不同的即时消息系统以及传统短彩信系统,本发明的上述实施例通过在同一运营商拥有多个不同的即时消息系统以及传统短彩信系统之上设置统一的用户状态数据库,在该数据库中统一存储用户在线端的信息的方式实现多终端的在线状态管理;通过在各即时消息系统和短信系统之上设置统一消息队列的方式,实现多终端之间的消息分发。从而实现了原本相互独立的各个消息系统之间终端在线状态的统一管理;以及实现原本属于各个相互独立的消息系统的多个终端之间的消息分发,不同的终端都可以看到相同的消息记录,但是只有用户当前在操作的终端会对用户进行提示,用户不需要在各个终端之间反复切换,提高了用户体验。
对于不同终端,保证都收到全量消息,用户看不同终端时,都可以有完整消息历史,但是,只在用户目前有操作的终端进行声音等提示,其他终端进行静默处理,对于同一终端,只有1个消息入口显示消息(或者是终端Native原生消息入口,或者是唯一的一个APP消息入口,不需要在各消息入口反复切换)。
本发明的实施例还提供一种多系统中的终端之间通信的装置,包括:
获取模块,用于获取第一类型终端采用第一通信系统进行登录的第一登录状态信息以及第二类型终端采用第二通信系统进行登录的第二登录状态信息,并将所述第一登录状态信息和所述第二登录状态信息存储在用户状态数据库中;所述第一类型终端和所述第二类型终端是基于相同应用的相同帐户进行登录的不同类型的终端;
发送模块,用于将所述第一登录状态信息和第二登录状态信息发送给在后登录的第二类型终端对应的第二通信系统,使所述第二通信系统根据所述第一登录状态信息和第二登录状态信息,以及预先存储的不同类型终端之间的登录冲突规则,确定是否允许所述第二类型终端进行登录。
其中,所述登录冲突规则包括:第一类型终端为出厂即可支持即时消息收发并支持安装其它即时消息应用的Native的终端,第二类型终端为出厂即可支持即时消息收发但不支持安装其它即时消息应用非Native的终端时,两种类型的终端均可同时在线;或者
第一类型终端为安装即时消息应用富媒体通信RCS APP1的终端,第二类型终端为安装RCS APP1的终端时,两种类型的终端均可同时在线,但与安装RCS APP2、OTT APP 1和OTT APP 2的终端均不可同时在线,在后登录的将在前登录的踢下线;或者
第一类型终端为安装即时消息应用富媒体通信RCS APP2的终端,第二类型终端为安装RCS APP2的终端时,两种类型的终端均可同时在线,但与安装RCS APP1、OTT APP 1和OTT APP 2的终端均不可同时在线,在后登录的将在前登录的踢下线;或者
第一类型终端为安装私有通信协议的即时消息应用OTT APP 1的终端,第二类型终端为安装OTT APP 1时,两种类型的终端均可同时在线,但与安装RCS APP1、RCS APP 2和OTT APP 2的终端均不可同时在线,在后登录的将在前登录的踢下线;或者
第一类型终端为安装私有通信协议的即时消息应用OTT APP 2的终端,第二类型终端为安装OTT APP 2的终端时,两种类型的终端均可同时在线,但与安装RCS APP1、RCSAPP 2和OTT APP 1的终端均不可同时在线,在后登录的将在前登录的踢下线;或者
第一类型终端为计算机PC1,第二类型终端为计算机PC2时,两种终端不可同时在线,在后登录的将在前登录的踢下线;
其中,RCS APP1与所述RCS APP2是基于相同通信协议的不同应用,OTT APP 1与OTT APP 2是基于相同通信协议的不同应用,PC1与PC2为不同的计算机。
其中,不同类型的终端,用终端标识进行区分:Native终端,通过基于会话初始协议的实例sip.instance=imei,获得终端标识;安装RCS APP 1终端,通过基于会话初始协议的实例sip.instance=UUid1获得终端标识;安装RCS APP 2终端,通过基于会话初始协议的实例sip.instance=UUid2获得终端标识;OTT APP 1终端,对应的终端标识为Eid1;OTT APP 2终端,对应的终端标识为Eid2;PC1终端,对应的终端标识为PCid1;PC2终端,对应的终端标识为PCid2。
其中,多系统中的终端之间通信的装置还包括:消息同步模块,用于获取发送终端发送的消息,存储在该发送终端的第一消息队列中;从所述用户状态数据库中获取当前处于登录状态的至少一个类型的接收方终端;根据所述消息,分别为所述至少一类型的接入方终端的通知队列中写入一个通知消息,并由所述至少一个类型的接收方终端对应的系统服务器,将通知队列中的通知消息分别发送给接收方终端。
其中,所述消息同步模块还用于:发送终端的第一消息队列向接收方终端的第二消息队列进行消息同步。
其中,所述发送终端发送的消息中具有一标识,所述标识用于标识:该消息是发送终端向与所述发送终端同时处于登录状态且基于相同应用的相同帐户的接收终端发送的。
其中,多系统中的终端之间通信的装置还包括:至少一个类型的接收方终端对应的通信系统,将此次更新的消息发送给接收方终端。
其中,多系统中的终端之间通信的装置还包括:接收方终端在接收到此次更新的消息时,该此次更新的消息如果已经在所述至少一个类型的其它接收方终端上接收过,则该接收方终端进行静默处理。
其中,多系统中的终端之间通信的装置还包括:若至少一个类型的接收方终端中,只有出厂即可支持即时消息收发但不支持安装其它即时消息应用的非Native终端处于登录状态,则由非Native终端采用的通信系统将此次更新的消息转为短信或者彩信,通过短信中心发送给接收方终端。
该装置是与上述方法对应的装置,上述方法中所有实现方式均适用于该终端的实施例中,也能达到相同的技术效果。
本发明的该装置实施例中,多个系统可以是同一运营商拥有的多个不同的即时消息系统以及传统短彩信系统,本发明的上述实施例通过在同一运营商拥有多个不同的即时消息系统以及传统短彩信系统之上设置统一的用户状态数据库,在该数据库中统一存储用户在线端的信息的方式实现多终端的在线状态管理;通过在各即时消息系统和短信系统之上设置统一消息队列的方式,实现多终端之间的消息分发。从而实现了原本相互独立的各个消息系统之间终端在线状态的统一管理;以及实现原本属于各个相互独立的消息系统的多个终端之间的消息分发,不同的终端都可以看到相同的消息记录,但是只有用户当前在操作的终端会对用户进行提示,用户不需要在各个终端之间反复切换,提高了用户体验。
以上所述是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明所述原理的前提下,还可以作出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。
Claims (23)
1.一种多系统中的终端之间通信的方法,其特征在于,包括:
获取第一类型终端采用第一通信系统进行登录的第一登录状态信息以及第二类型终端采用第二通信系统进行登录的第二登录状态信息,并将所述第一登录状态信息和所述第二登录状态信息存储在用户状态数据库中;所述第一类型终端和所述第二类型终端是基于相同应用的相同帐户进行登录的不同类型的终端;
将所述第一登录状态信息和第二登录状态信息发送给在后登录的第二类型终端对应的第二通信系统,使所述第二通信系统根据所述第一登录状态信息和第二登录状态信息,以及预先存储的不同类型终端之间的登录冲突规则,确定是否允许所述第二类型终端进行登录。
2.根据权利要求1所述的方法,其特征在于,所述登录冲突规则包括:
所述第一类型终端为出厂即可支持即时消息收发并支持安装其它即时消息应用的Native的终端,所述第二类型终端为出厂即可支持即时消息收发但不支持安装其它即时消息应用非Native的终端时,两种类型的终端均可同时在线。
3.根据权利要求1所述的方法,其特征在于,所述登录冲突规则包括:
所述第一类型终端为安装即时消息应用富媒体通信RCS APP1的终端,所述第二类型终端为安装RCS APP1的终端时,两种类型的终端均可同时在线,但与安装RCS APP2、OTT APP1和OTT APP 2的终端均不可同时在线,在后登录的将在前登录的踢下线;
其中,RCS APP1与所述RCS APP2是基于相同通信协议的不同应用,OTT APP 1与OTTAPP 2是基于相同通信协议的不同应用。
4.根据权利要求1所述的方法,其特征在于,所述登录冲突规则包括:
所述第一类型终端为安装即时消息应用富媒体通信RCS APP2的终端,所述第二类型终端为安装RCS APP2的终端时,两种类型的终端均可同时在线,但与安装RCS APP1、OTT APP1和OTT APP 2的终端均不可同时在线,在后登录的将在前登录的踢下线;
其中,RCS APP1与所述RCS APP2是基于相同通信协议的不同应用,OTT APP 1与OTTAPP 2是基于相同通信协议的不同应用。
5.根据权利要求1所述的方法,其特征在于,所述登录冲突规则包括:
所述第一类型终端为安装私有通信协议的即时消息应用OTT APP 1的终端,所述第二类型终端为安装OTT APP 1时,两种类型的终端均可同时在线,但与安装RCS APP1、RCS APP2和OTT APP 2的终端均不可同时在线,在后登录的将在前登录的踢下线;
其中,RCS APP1与所述RCS APP2是基于相同通信协议的不同应用,OTT APP 1与OTTAPP 2是基于相同通信协议的不同应用。
6.根据权利要求1所述的方法,其特征在于,所述登录冲突规则包括:
所述第一类型终端为安装私有通信协议的即时消息应用OTT APP 2的终端,所述第二类型终端为安装OTT APP 2的终端时,两种类型的终端均可同时在线,但与安装RCS APP1、RCS APP 2和OTT APP 1的终端均不可同时在线,在后登录的将在前登录的踢下线;
其中,RCS APP1与所述RCS APP2是基于相同通信协议的不同应用,OTT APP 1与OTTAPP 2是基于相同通信协议的不同应用。
7.根据权利要求1所述的方法,其特征在于,所述登录冲突规则包括:
所述第一类型终端为计算机PC1,所述第二类型终端为计算机PC2时,两种终端不可同时在线,在后登录的将在前登录的踢下线;
其中,PC1与PC2为不同的计算机。
8.根据权利要求2-7任一项所述的方法,其特征在于,不同类型的终端,用终端标识进行区分:
Native的终端,通过基于会话初始协议的实例sip.instance=imei,获得终端标识;
安装RCS APP 1的终端,通过基于会话初始协议的实例sip.instance=UUid1获得终端标识;
安装RCS APP 2的终端,通过基于会话初始协议的实例sip.instance=UUid2获得终端标识;
安装OTT APP 1的终端,对应的终端标识为Eid1;
安装OTT APP 2的终端,对应的终端标识为Eid2;
PC1,对应的终端标识为PCid1;
PC2,对应的终端标识为PCid2;
其中,Eid1与Eid2不同,PCid1与PCid2不同。
9.根据权利要求1所述的方法,其特征在于,还包括:
获取发送终端发送的消息,存储在该发送终端的第一消息队列中;
从所述用户状态数据库中获取当前处于登录状态的至少一个类型的接收方终端;
根据所述消息,分别为所述至少一类型的接入方终端的通知队列中写入一个通知消息,并由所述至少一个类型的接收方终端对应的系统服务器,将通知队列中的通知消息分别发送给接收方终端。
10.根据权利要求9所述的方法,其特征在于,还包括:
发送终端的第一消息队列向接收方终端的第二消息队列进行消息同步。
11.根据权利要求9所述的方法,其特征在于,所述发送终端发送的消息中具有一标识,所述标识用于标识:该消息是发送终端向与所述发送终端同时处于登录状态且基于相同应用的相同帐户的接收终端发送的。
12.根据权利要求10所述的方法,其特征在于,发送终端的第一消息队列向接收方终端的第二消息队列进行消息同步后还包括:
至少一个类型的接收方终端对应的通信系统,将此次更新的消息发送给接收方终端。
13.根据权利要求12所述的方法,其特征在于,还包括:
接收方终端在接收到此次更新的消息时,该此次更新的消息如果已经在所述至少一个类型的其它接收方终端上接收过,则该接收方终端进行静默处理。
14.根据权利要求12所述的方法,其特征在于,还包括:
若至少一个类型的接收方终端中,只有出厂即可支持即时消息收发但不支持安装其它即时消息应用的非Native终端处于登录状态,则由非Native终端采用的通信系统将此次更新的消息转为短信或者彩信,通过短信中心发送给接收方终端。
15.一种多系统中的终端之间通信的装置,其特征在于,包括:
获取模块,用于获取第一类型终端采用第一通信系统进行登录的第一登录状态信息以及第二类型终端采用第二通信系统进行登录的第二登录状态信息,并将所述第一登录状态信息和所述第二登录状态信息存储在用户状态数据库中;所述第一类型终端和所述第二类型终端是基于相同应用的相同帐户进行登录的不同类型的终端;
发送模块,用于将所述第一登录状态信息和第二登录状态信息发送给在后登录的第二类型终端对应的第二通信系统,使所述第二通信系统根据所述第一登录状态信息和第二登录状态信息,以及预先存储的不同类型终端之间的登录冲突规则,确定是否允许所述第二类型终端进行登录。
16.根据权利要求15所述的装置,其特征在于,所述登录冲突规则包括:
所述第一类型终端为出厂即可支持即时消息收发并支持安装其它即时消息应用的Native的终端,所述第二类型终端为出厂即可支持即时消息收发但不支持安装其它即时消息应用非Native的终端时,两种类型的终端均可同时在线;或者所述第一类型终端为安装即时消息应用富媒体通信RCS APP1的终端,所述第二类型终端为安装RCS APP1的终端时,两种类型的终端均可同时在线,但与安装RCS APP2、OTT APP 1和OTT APP 2的终端均不可同时在线,在后登录的将在前登录的踢下线;或者
所述第一类型终端为安装即时消息应用富媒体通信RCS APP2的终端,所述第二类型终端为安装RCS APP2的终端时,两种类型的终端均可同时在线,但与安装RCS APP1、OTT APP1和OTT APP 2的终端均不可同时在线,在后登录的将在前登录的踢下线;或者
所述第一类型终端为安装私有通信协议的即时消息应用OTT APP 1的终端,所述第二类型终端为安装OTT APP 1时,两种类型的终端均可同时在线,但与安装RCS APP1、RCS APP2和OTT APP 2的终端均不可同时在线,在后登录的将在前登录的踢下线;或者
所述第一类型终端为安装私有通信协议的即时消息应用OTT APP 2的终端,所述第二类型终端为安装OTT APP 2的终端时,两种类型的终端均可同时在线,但与安装RCS APP1、RCS APP 2和OTT APP 1的终端均不可同时在线,在后登录的将在前登录的踢下线;或者
所述第一类型终端为计算机PC1,所述第二类型终端为计算机PC2时,两种终端不可同时在线,在后登录的将在前登录的踢下线;
其中,RCS APP1与所述RCS APP2是基于相同通信协议的不同应用,OTT APP 1与OTTAPP 2是基于相同通信协议的不同应用,PC1与PC2为不同的计算机。
17.根据权利要求16所述的装置,其特征在于,不同类型的终端,用终端标识进行区分:
Native的终端,通过基于会话初始协议的实例sip.instance=imei,获得终端标识;
安装RCS APP 1的终端,通过基于会话初始协议的实例sip.instance=UUid1获得终端标识;
安装RCS APP 2的终端,通过基于会话初始协议的实例sip.instance=UUid2获得终端标识;
安装OTT APP 1的终端,对应的终端标识为Eid1;
安装OTT APP 2的终端,对应的终端标识为Eid2;
PC1,对应的终端标识为PCid1;
PC2,对应的终端标识为PCid2;
其中,Eid1与Eid2不同,PCid1与PCid2不同。
18.根据权利要求15所述的装置,其特征在于,还包括:
消息同步模块,用于获取发送终端发送的消息,存储在该发送终端的第一消息队列中;从所述用户状态数据库中获取当前处于登录状态的至少一个类型的接收方终端;根据所述消息,分别为所述至少一类型的接入方终端的通知队列中写入一个通知消息,并由所述至少一个类型的接收方终端对应的系统服务器,将通知队列中的通知消息分别发送给接收方终端。
19.根据权利要求18所述的装置,其特征在于,所述消息同步模块还用于:发送终端的第一消息队列向接收方终端的第二消息队列进行消息同步。
20.根据权利要求18所述的装置,其特征在于,所述发送终端发送的消息中具有一标识,所述标识用于标识:该消息是发送终端向与所述发送终端同时处于登录状态且基于相同应用的相同帐户的接收终端发送的。
21.根据权利要求19所述的装置,其特征在于,还包括:
至少一个类型的接收方终端对应的通信系统,将此次更新的消息发送给接收方终端。
22.根据权利要求21所述的装置,其特征在于,还包括:
接收方终端在接收到此次更新的消息时,该此次更新的消息如果已经在所述至少一个类型的其它接收方终端上接收过,则该接收方终端进行静默处理。
23.根据权利要求21所述的装置,其特征在于,还包括:
若至少一个类型的接收方终端中,只有出厂即可支持即时消息收发但不支持安装其它即时消息应用的非Native终端处于登录状态,则由非Native终端采用的通信系统将此次更新的消息转为短信或者彩信,通过短信中心发送给接收方终端。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610674892.2A CN107770033A (zh) | 2016-08-16 | 2016-08-16 | 一种多系统中的终端之间通信的方法及装置 |
PCT/CN2017/096803 WO2018033015A1 (zh) | 2016-08-16 | 2017-08-10 | 多系统中的终端之间通信的方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610674892.2A CN107770033A (zh) | 2016-08-16 | 2016-08-16 | 一种多系统中的终端之间通信的方法及装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN107770033A true CN107770033A (zh) | 2018-03-06 |
Family
ID=61196410
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201610674892.2A Pending CN107770033A (zh) | 2016-08-16 | 2016-08-16 | 一种多系统中的终端之间通信的方法及装置 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN107770033A (zh) |
WO (1) | WO2018033015A1 (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109286904A (zh) * | 2018-10-15 | 2019-01-29 | 京信通信系统(中国)有限公司 | Ims系统、消息处理方法、装置和存储介质 |
CN111294327A (zh) * | 2019-01-28 | 2020-06-16 | 展讯半导体(成都)有限公司 | 消息冲突解决方法和终端设备 |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112988408A (zh) * | 2019-12-17 | 2021-06-18 | 北京沃东天骏信息技术有限公司 | 一种多端交互方法和装置 |
CN113326224B (zh) * | 2021-06-24 | 2022-08-02 | 卡斯柯信号有限公司 | 一种基于2取2架构的串口通信方法 |
CN114125732B (zh) * | 2021-11-11 | 2023-06-16 | 中国电信股份有限公司 | 消息处理方法及装置、存储介质、电子设备 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1750518A (zh) * | 2005-11-03 | 2006-03-22 | 中国移动通信集团公司 | 一种实现即时消息通信的方法 |
CN101212719A (zh) * | 2006-12-31 | 2008-07-02 | 华为技术有限公司 | 一种无线通信网络中实现融合消息业务的方法及系统 |
CN103259770A (zh) * | 2012-02-17 | 2013-08-21 | 腾讯科技(深圳)有限公司 | 登录方法及登录服务器 |
US20140317205A1 (en) * | 2013-04-18 | 2014-10-23 | Infinite Convergence Solutions, Inc. | Method and Devices to Invite a User from an External Chat Service to a Group Chat Session |
CN105721408A (zh) * | 2014-12-05 | 2016-06-29 | 中国移动通信集团公司 | 融合通信客户端的实现方法、终端、相关平台及系统 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103701835A (zh) * | 2012-09-27 | 2014-04-02 | 中国电信股份有限公司 | 基于浏览器建立融合通信的方法与融合通信系统 |
US9397878B2 (en) * | 2013-01-29 | 2016-07-19 | Qualcomm Incorporated | Cross-platform module that is shared by client applications for access to rich communications suite resources on a client device |
CN103532983A (zh) * | 2013-10-31 | 2014-01-22 | 北京云巢动脉科技有限公司 | 多点登陆的处理方法和装置 |
CN105024907A (zh) * | 2014-04-22 | 2015-11-04 | 中国电信股份有限公司 | 一种推送im信息的方法和系统、服务器以及平台 |
-
2016
- 2016-08-16 CN CN201610674892.2A patent/CN107770033A/zh active Pending
-
2017
- 2017-08-10 WO PCT/CN2017/096803 patent/WO2018033015A1/zh active Application Filing
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1750518A (zh) * | 2005-11-03 | 2006-03-22 | 中国移动通信集团公司 | 一种实现即时消息通信的方法 |
CN101212719A (zh) * | 2006-12-31 | 2008-07-02 | 华为技术有限公司 | 一种无线通信网络中实现融合消息业务的方法及系统 |
CN103259770A (zh) * | 2012-02-17 | 2013-08-21 | 腾讯科技(深圳)有限公司 | 登录方法及登录服务器 |
US20140317205A1 (en) * | 2013-04-18 | 2014-10-23 | Infinite Convergence Solutions, Inc. | Method and Devices to Invite a User from an External Chat Service to a Group Chat Session |
CN105721408A (zh) * | 2014-12-05 | 2016-06-29 | 中国移动通信集团公司 | 融合通信客户端的实现方法、终端、相关平台及系统 |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109286904A (zh) * | 2018-10-15 | 2019-01-29 | 京信通信系统(中国)有限公司 | Ims系统、消息处理方法、装置和存储介质 |
CN111294327A (zh) * | 2019-01-28 | 2020-06-16 | 展讯半导体(成都)有限公司 | 消息冲突解决方法和终端设备 |
Also Published As
Publication number | Publication date |
---|---|
WO2018033015A1 (zh) | 2018-02-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN107770033A (zh) | 一种多系统中的终端之间通信的方法及装置 | |
CN101635772B (zh) | 一种呼叫信息管理的方法及其系统 | |
CN102970362B (zh) | 一种云端数据共享的方法及装置 | |
CN101159778B (zh) | 一种基于虚拟号码进行多媒体通信的系统 | |
CN1729468B (zh) | 数据同步 | |
CN101515949B (zh) | 便于用户设备间会话转移的方法和系统 | |
CN104768135B (zh) | 集群通信 | |
CN101207660B (zh) | 用于联系电话会议参与者的方法和设备 | |
US7142856B2 (en) | System and method for providing subscriber presence information in a dispatch network | |
US20050073999A1 (en) | Delivery of profile-based third party content associated with an incoming communication | |
CN102232291B (zh) | 一种通信的方法、系统及装置 | |
CN101018353A (zh) | 利用移动单元配置业务数据 | |
MXPA04006881A (es) | Metodo y sistema para facilitar servicios en red de comunicacion por medio de publicacion de datos mediante un servidor de senalizacion. | |
JP2002544608A (ja) | 様々なネットワークを介して匿名ユーザ間でのインテリジェントなセッションを確立する分散システム | |
WO2011163087A2 (en) | Automated mobile intelligent communication processing system | |
CN104753877A (zh) | 一种群组通信方法及装置 | |
CN101543022A (zh) | 通信系统 | |
CN102611805A (zh) | 通信信息通知方法、信息上报方法、服务器及通信终端 | |
CN106487644A (zh) | 一种通信方法和系统 | |
WO2014028512A2 (en) | Messaging in a hosted private branch exchange | |
CN102065099B (zh) | 信令与承载分离的通信系统 | |
US7586898B1 (en) | Third party content for internet caller-ID messages | |
CN110247971A (zh) | 减少消息中间件连接数量的方法及其系统 | |
JP2004535141A (ja) | オープンサービスアクセスのための拡張された遠隔通信システムアーキテクチャ | |
CN101385293A (zh) | 与多个用户的通信方法、装置、通信管理服务器以及通信终端 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20180306 |
|
RJ01 | Rejection of invention patent application after publication |