一种通信方法和系统与流程

本发明涉及通信技术，尤其涉及一种通信方法和系统。

背景技术：

在4G移动互联网时代，互联网厂家在移动应用领域快速发展，出现了一批类似微信、QQ、米聊等的OTT应用，它们具有免费、体验丰富等特色，并且迭代快速，能不断为用户提供新业务特性，因此逐渐蚕食着运营商的用户群与收入。

与OTT应用相比，运营商传统的，作为基础电信业务的短彩信业务常年体验单一，无法支持丰富的媒体类型和业务功能，无法满足用户增长的使用需求，因此，对传统短彩信业务进行升级，增强用户粘度，成为了运营商必须面对的课题。

为解决这个问题，运营商大多采用了两种不同的方式，推出了自身的即时消息业务：

第一种是运营商直接学习互联网厂家，推出自身使用OTT技术的即时消息软件(以下称OTT方式)，例如中国移动的飞信和中国电信的易信等，这种方式完全使用互联网解决方案，用户需要下载安装特定的APP，并进行注册账户(对于运营商的OTT即时消息软件，通常使用手机号作为用户账号进展注册，即用户名为手机号，而实际消息路由分发等使用OTT内部标识)、添加好友等操作，通过APP的互联网私有通信协议与其他好友进行即时消息通信，可以说，该方式是一种以用户社交属性为核心的方式；

第二种是使用电信国际标准，通过对GSMA RCS国际协议的支持，推动手机厂家升级终端上原有的通话、短/彩信和通讯录三大通信入口，以终端原生方 式(Native，即终端在出厂时就已具备功能)支持即时消息(以下称融合通信方式)，如中国移动融合通信。该方式用户无需下载安装特定APP或添加好友，可以继承用户原有通信习惯。同时，由于使用国际标准，该方式保证了运营商基础通信业务全球可达性和电信级服务质量，可以说，该方式是以通信能力为核心的方式。

进入移动互联网时代时，运营商通常会首先选择第一方式提供即时消息，从而积累了一定的OTT即时消息用户，随着国际标准的发展和终端、芯片等产业的推进，在手机上通过融合通信方式提供即时消息成为了可能。同时，随着移动互联网产品竞争压力的加大，运营商单纯使用自身并不擅长的OTT方式很难在竞争中获得优势，因此越来越多运营商开始将升级基础电信能力，以通信能力为核心的融合通信方式作为了即时消息的发展方向。但是，早期运营商OTT即时消息已积累的一定的用户，如何继续充分利用这些用户资源，使得融合通信方式提供的即时消息可以尽快被更多用户使用，成为了运营商需要考虑的问题。

解决这一问题的方式，就是实现运营商互联网即时通信系统与基于电信标准的即时通信系统的充分融合，保留用户数据和关键业务功能，实现业务发展的“冷启动”。用户可以在手机、PC、Pad等终端上使用即使消息功能，对于同一个用户来讲，他在不同终端上使用的即时消息功能应具备同样的用户身份。移动互联网时代，用户已更多将手机而非PC作为主要通信设备使用，因此融合时，考虑将手机作为用户的主设备，即手机侧以用户的E.164号码为通信基础，以融合通信方式实现即时消息，同时将该用户OTT即时消息使用的标识与该用户E.164号码关联，继续在PC、Pad等客户端上使用OTT方式提供即时消息，并将OTT形成的群聊等社交关系导入电信标准即时消息系统中。

这种方式，可以充分利用运营商OTT即时消息积累的用户，并可享受电信即使消息带来的基础电信互通、可达等优势，但这种方式需要将两种原理机制不同的即时消息系统在用户体验层面整合，如用户在自身一个设备上发送或收到消息，在另一个使用不同方式实现的设备上也需要对这些消息进行同步，即 也能显示出已发送或收到了同样的消息。由于互联网和电信系统相互实现方式有很大区别，因此融合存在巨大挑战。

现阶段，不同消息系统之间，一般通过设置互通网关的方式进行互通，如图1所示。该方式由网关完成不同消息系统间的协议转化工作。

多终端之间的消息同步，通常是在同构系统中的不同终端之间进行，如电信系统中IMS的多终端消息机制和OTT即时消息系统在不同平台上同时登录时的消息收发方式等。

其中，IMS多终端消息机制如图2所示，该方式要求同一用户使用的全部终端均基于SIP实现，都具有同样的SIP用户身份标识(IMPI/IMPU)，通过不同的SIP实例(sip.instance或GRUU)在IMS中进行注册，所有消息都被存入集中消息存储平台中，在接收消息时，通过IMS的forking机制将同一个消息拆成多条，分别发到每一个终端实例，对于不在线的终端，在其上线后通过集中消息存储平台使用推送的方式实现消息同步。

OTT即时消息系统使用的方式与之类似，对于接收方有多个设备的场景，一般发送时根据接收方登陆状态将消息分别写入多个消息队列中，并且分别通知接收方的各个终端有消息更新，由接收方对比本地消息记录后，到服务器拉取相应消息，此后接收设备通知服务器某消息已接收，服务器可以将该设备的这部分消息从对应消息队列中删除。

图1所示设置互通网关的方式，只能用于发送方和接收方使用不同消息协议的场景，无法满足同一个用户使用不同协议类型终端发送和接收到的消息进行同步需求。

图2所示IMS网络中多终端的方案，不支持非IMS终端，并且要求IMS具备forking功能，现有电信网络中的设备通常并不具备，需要改造，同时，要求新部署集中消息存储平台。

图3所示OTT即时消息系统中多终端消息的方法要求所有终端都使用相同的消息协议实现，无法提供使用不同协议的终端之间的消息同步和转化。

因此，现有多终端技术只实现了同一个即时消息系统内的多终端消息同步， 对于互联网与电信两类不同机制的即时消息系统融合构成的系统，现有互联网领域或电信领域的多终端消息技术均较难满足多终端消息收发和同步需求。

技术实现要素：

为解决现有存在的技术问题，本发明实施例提供一种融合通信方法和系统。

本发明实施例提供的一种通信方法，所述方法包括：

确定接入第一即时消息系统的移动通信终端在所述第一即时消息系统所使用的功能，所述第一即时消息系统基于电信系统实现即时消息通信，所述功能基于第一协议；

将所述功能抽象为应用程序编程接口API，所述API采用第二协议；

所述第一即时消息系统通过所述API与第二即时消息系统进行交互，使接入所述第二即时消息系统的客户端获取所述移动通信终端通过所述第一即时消息系统进行通信的信息，所述客户端使用所述移动终端的唯一识别码进行的注册，所述第二即时消息系统基于互联网实现即时消息通信；

所述第一协议与所述第二协议不相同。

其中，所述API基于OMA表述性状态转移架构RESTful，所述第二协议采用HTTP协议；所述第一即时消息系统通过所述API与所述第二即时消息系统进行交互包括：

所述第一即时消息系统通过所述API和REST接口与所述第二即时消息系统进行交互；

所述API能够供所述第二即时消息系统通过所述第二协议调用，或者所述第一即时消息系统内的消息或功能以HTTP调用或响应的方式告知所述第二即时消息系统。

其中，所述功能包括至少以下功能中的一种：登记功能、即时消息功能、文件传输功能、群聊功能；所述第一协议为SIP协议；

所述将第一即时消息系统的功能抽象为API包括至少以下抽象中的一种：

将SIP登记通告抽象为RESTful注册；

将SIP即时消息抽象为RESTful消息；

将SIP Invite/MSRP文件传输抽象为RESTful消息；

将SIP Invite/MSRP群聊抽象为RESTful群聊。

其中，所述移动通信终端通过SIP协议接入第一即时消息系统的IMS；

所述第二即时消息系统为OTT即时消息系统，客户端通过HTTP协议接入OTT即时消息系统。

其中，所述第一即时消息系统通过所述API与第二即时消息系统进行交互包括：

所述第一即时消息系统的即时消息AS通过所述API和第二即时消息系统的OTT服务器进行交互。

其中，所述方法还包括：获取所述第二即时消息系统的登录记录；

根据所述登录记录，确定所述第二即时消息系统所处的状态；

当所述第二即时消息系统处于第一状态时，将所述第二即时消息系统具有客户端的信息进行登记。

其中，所述第一即时消息系统通过所述API与第二即时消息系统进行交互包括：

当所述移动通信终端发送的消息到达主叫归属的即时消息AS时，所述即时消息AS判断主叫用户是否具有客户端的登记，若有，则在所述即时消息系统内进行正常的后续消息流程的同时，将即时消息业务通过所述API转发到第二即时消息系统的OTT服务器，后续由所述OTT服务器下发给此主叫用户的OTT客户端。

其中，所述第一即时消息系统通过所述API与第二即时消息系统进行交互包括：

当即时消息到达被叫归属的即时消息AS时，所述即时消息AS判断被叫用户是否具有客户端的登记，若有，则在所述即时消息系统内进行正常的后续消息流程的同时，将即时消息业务通过所述API转发到第二即时消息系统的OTT服务器，后续由所述OTT服务器下发给此被叫用户的OTT客户端。

其中，所述方法还包括：获取所述客户端的信息收发记录；

根据所述信息收发记录，确定所述客户端的类别；

当所述客户端为第一类别时，向所述客户端发送的消息中包括第一标识字段，所述第一标识字段用于指示所述客户端在收到所述消息后不做提示处理。

本发明实施例提供一种即时消息系统，所述即时消息系统包括电信系统，所述即时消息系统基于所述电信系统实现即时消息通信，所述电信系统用于确定接入所述即时消息系统的移动通信终端在所述即时消息系统所使用的功能，所述功能基于第一协议；所述即时消息系统还包括Network API设备：

所述Network API设备，用于将所述功能抽象为应用程序编程接口API，所述API采用第二协议；

所述电信系统，用于通过所述API与第二即时消息系统进行交互，使接入所述第二即时消息系统的客户端获取所述移动通信终端通过所述即时消息系统进行通信的信息，所述客户端使用所述移动终端的唯一识别码进行的注册，所述第二即时消息系统基于互联网实现即时消息通信；

所述第一协议与所述第二协议不相同。

其中，所述API基于OMA表述性状态转移架构RESTful，所述第二协议采用HTTP协议；

所述电信系统，用于通过所述API和REST接口与所述第二即时消息系统进行交互；

所述API能够供所述第二即时消息系统通过所述第二协议调用，或者将所述即时消息系统内的消息或功能以HTTP调用或响应的方式告知所述第二即时消息系统。

其中，所述功能包括至少以下功能中的一种：登记功能、即时消息功能、文件传输功能、群聊功能；所述第一协议为SIP协议；

所述Network API设备，用于将SIP登记通告抽象为RESTful注册；将SIP即时消息抽象为RESTful消息；将SIP Invite/MSRP文件传输抽象为RESTful消息；将SIP Invite/MSRP群聊抽象为RESTful群聊。

其中，所述移动通信终端通过SIP协议接入所述电信系统的IMS；

所述第二即时消息系统为OTT即时消息系统，客户端通过HTTP协议接入OTT即时消息系统。

其中，所述电信系统的即时消息AS通过所述API和第二即时消息系统的OTT服务器进行交互。

其中，所述电信系统的即时消息AS，用于获取所述第二即时消息系统的登录记录；

根据所述登录记录，确定所述第二即时消息系统所处的状态；

当所述第二即时消息系统处于第一状态时，将所述第二即时消息系统具有客户端的信息进行登记。

其中，当所述移动通信终端发送的消息到达主叫归属的即时消息AS时，所述即时消息AS用于判断主叫用户是否具有客户端的登记，若有，则在所述即时消息系统内进行正常的后续消息流程的同时，将即时消息业务通过所述API转发到第二即时消息系统的OTT服务器，后续由所述OTT服务器下发给此主叫用户的OTT客户端。

其中，当即时消息到达被叫归属的即时消息AS时，所述即时消息AS用于判断被叫用户是否具有客户端的登记，若有，则在所述即时消息系统内进行正常的后续消息流程的同时，将即时消息业务通过所述API转发到第二即时消息系统的OTT服务器，后续由所述OTT服务器下发给此被叫用户的OTT客户端。

其中，所述即时消息AS用于获取所述客户端的信息收发记录；根据所述信息收发记录，确定所述客户端的类别；

当所述客户端为第一类别时，向所述客户端发送的消息中包括第一标识字段，所述第一标识字段用于指示所述客户端在收到所述消息后不做提示处理。

由上可知，本发明实施例的技术方案包括：确定接入第一即时消息系统的移动通信终端在所述第一即时消息系统所使用的功能，所述第一即时消息系统基于电信系统实现即时消息通信，所述功能基于第一协议；将所述功能抽象为应用程序编程接口API，所述API采用第二协议；所述第一即时消息系统通过 所述API与第二即时消息系统进行交互，使接入所述第二即时消息系统的客户端获取所述移动通信终端通过所述第一即时消息系统进行通信的信息，所述客户端使用所述移动终端的唯一识别码进行的注册，所述第二即时消息系统基于互联网实现即时消息通信；所述第一协议与所述第二协议不相同。由此，本发明实施例具备下述有益效果：1、通过API调用的方式，使同一用户使用同样的移动电话号码身份可以使用多种不同的终端，这些终端分别使用不同的协议并且可以分别处于互联网和电信网等不同架构网络环境中的，可以分别收发消息并实现不同终端之间的消息同步；2、电信网即时通信系统与互联网OTT即时通信系统相对独立，分别自身控制向另外一方的消息抄送，可以实现多终端一对一消息、群聊和管理的流程。3、不需要对电信核心网设备就行修改，不改变IMS路由流程，所有到PC侧的消息抄送逻辑由应用服务器进行，同时不需要改变OTT侧的协议和实现模式，由OTT服务器作为API调用方控制消息流程。

附图说明

图1为不同即时消息系统通过设置互通网关的方式进行互通的示意图；

图2为IMS网络中多终端消息的原理示意图；

图3为OTT即时消息系统中多终端消息的原理示意图；

图4为本发明提供的一种通信方法的第一实施例的流程示意图；

图5为本发明提供的一种通信方法的第二实施例的流程示意图；

图6为本发明提供的一种通信方法的第三实施例的流程示意图；

图7为本发明提供的一种通信方法的第四实施例的流程示意图；

图8为本发明提供的一种即时消息系统的一实施例的结构示意图；

图9为互联网即时通信系统与电信即时通信系统融合后的系统总体架的示意图；

图10为Network API将电信网即时消息系统能力抽象为OTT系统可理解的API的示意图；

图11为为OTT客户端到融合通信系统的注册的流程示意图；

图12为Native终端/APP客户端实现远程控制的架构示意图；

图13为用户Native终端/APP客户端获取自身PC客户端登录状态的流程示意图；

图14为PC客户端强制注销的流程示意图；

图15为用户A使用手机向用户B发送消息的流程示意图；

图16为用户A使用OTT客户端向用户B发送消息的流程示意图；

图17为用户手机向自身OTT客户端发送消息的流程示意图；

图18为用户PC客户端向自身Native/APP发送消息的流程示意图；

图19为过渡期结束后UE_A发起群聊的流程示意图；

图20为过渡期结束后PC_A发起群聊的流程示意图。

具体实施方式

本发明提供的一种通信方法的第一实施例，如图4所示，所述方法包括：

步骤401、确定接入第一即时消息系统的移动通信终端在所述第一即时消息系统所使用的功能；

所述第一即时消息系统基于电信系统实现即时消息通信，所述功能基于第一协议；这里，所述第一协议可以为SIP协议；

所述功能包括至少以下功能中的一种：登记功能、即时消息功能、文件传输功能、群聊功能；

在实际应用中，所述移动通信终端通过SIP协议接入第一即时消息系统的IMS。

这里要说明的是，所述第一即时消息系统可以是电信即时消息系统。所述移动通信终端以终端原生方式(Native，即终端在出厂时就已具备功能)支持即时消息，本文中也称为融合通信方式。

步骤402、将所述功能抽象为应用程序编程接口API；

这里，所述API采用第二协议；

在实际应用中，参见图10所示，所述将第一即时消息系统的功能抽象为API包括至少以下抽象中的一种：

将SIP登记通告抽象为RESTful注册；

将SIP即时消息抽象为RESTful消息；

将SIP Invite/MSRP文件传输抽象为RESTful消息；

将SIP Invite/MSRP群聊抽象为RESTful群聊。

下面举例对如何进行抽象进行说明。

例如，电信系统中的注册功能，可以抽象为：HTTP POST方法，调用连接为http://{serverRoot}/register/{apiVersion}/{userId}/sessions，其中，serverRoot标识要注册的服务器地址，apiVersion为OTT系统调用电信系统注册能力时使用的API版本号，userId为发起注册的用户的ID，例如，发起注册的用户电话号码为19585550100，则此处值为tel:+19585550100。

即时消息功能可抽象为HTTP POST方法，调用链接为http://{serverRoot}/messaging/{apiVersion}/outbound/{senderAddress}/requests，其中，serverRoot标识即时消息服务器地址，apiVersion为OTT系统调用电信系统注册能力时使用的API版本号，senderAddress标识为发送用户标识，同时，通过http消息的消息体携带聊天相关信息，如表1所示。

表1

步骤403、所述第一即时消息系统通过所述API与第二即时消息系统进行交互，使接入所述第二即时消息系统的客户端获取所述移动通信终端通过所述第一即时消息系统进行通信的信息；

这里，需要说明的是，所述客户端使用所述移动终端的唯一识别码如MSISDN进行的注册，所述第二即时消息系统基于互联网实现即时消息通信；所述第一协议与所述第二协议不相同。

这里要说明的是，所述第二即时消息系统可以是OTT即时消息系统。

本发明提供的一种通信方法的第二实施例，如图5所示，所述方法包括：

步骤501、确定接入第一即时消息系统的移动通信终端在所述第一即时消息系统所使用的功能；

这里，所述第一即时消息系统基于电信系统实现即时消息通信，所述功能基于第一协议；

步骤502、将所述功能抽象为应用程序编程接口API；

这里，所述API采用第二协议；所述第二协议采用HTTP协议；

在实际应用中，所述API基于OMA表述性状态转移架构RESTful；

步骤503、所述第一即时消息系统通过所述API和REST接口与所述第二即时消息系统进行交互；使接入所述第二即时消息系统的客户端获取所述移动通信终端通过所述第一即时消息系统进行通信的信息；

这里，所述API能够供所述第二即时消息系统通过所述第二协议调用，或者所述第一即时消息系统内的消息或功能以HTTP调用或响应的方式告知所述第二即时消息系统。

需要说明的是，所述客户端使用所述移动终端的唯一识别码进行的注册， 所述第二即时消息系统基于互联网实现即时消息通信；所述第一协议与所述第二协议不相同。

在实际应用中，所述第二即时消息系统为OTT即时消息系统，客户端通过HTTP协议接入OTT即时消息系统。

具体的，所述第一即时消息系统通过所述API与第二即时消息系统进行交互包括：

所述第一即时消息系统的即时消息AS通过所述API和第二即时消息系统的OTT服务器进行交互。

本发明提供的一种通信方法的第三实施例，如图6所示，所述方法包括：

步骤601、确定接入第一即时消息系统的移动通信终端在所述第一即时消息系统所使用的功能；

这里，所述第一即时消息系统基于电信系统实现即时消息通信，所述功能基于第一协议；所述第一协议为SIP协议；

可以理解的是，所述功能包括至少以下功能中的一种：登记功能、即时消息功能、文件传输功能、群聊功能；

在实际应用中，所述移动通信终端通过SIP协议接入第一即时消息系统的IMS；

步骤602、将所述功能抽象为应用程序编程接口API；

这里，所述API采用第二协议；

在实际应用中，所述将第一即时消息系统的功能抽象为API包括至少以下抽象中的一种：

将SIP登记通告抽象为RESTful注册；

将SIP即时消息抽象为RESTful消息；

将SIP Invite/MSRP文件传输抽象为RESTful消息；

将SIP Invite/MSRP群聊抽象为RESTful群聊。

步骤603、所述第一即时消息系统通过所述API与第二即时消息系统进行交互，使接入所述第二即时消息系统的客户端获取所述移动通信终端通过所述 第一即时消息系统进行通信的信息；

这里，所述客户端使用所述移动终端的唯一识别码进行的注册，所述第二即时消息系统基于互联网实现即时消息通信；所述第一协议与所述第二协议不相同。

步骤604、获取所述第二即时消息系统的登录记录；

步骤605、根据所述登录记录，确定所述第二即时消息系统所处的状态；

步骤606、当所述第二即时消息系统处于第一状态时，将所述第二即时消息系统具有客户端的信息进行登记；

步骤607、将所述移动通信终端通过所述第一即时消息系统进行通信的信息通过所述API转发给所述第二即时消息系统，以使所述客户端获取所述信息。

具体的，将所述移动通信终端通过所述第一即时消息系统进行通信的信息通过所述API转发给所述第二即时消息系统包括：

当所述移动通信终端发送的消息到达主叫归属的即时消息AS时，所述即时消息AS判断主叫用户是否具有客户端的登记，若有，则在所述即时消息系统内进行正常的后续消息流程的同时，将即时消息业务通过所述API转发到第二即时消息系统的OTT服务器，后续由所述OTT服务器下发给此主叫用户的OTT客户端；或者，

当即时消息到达被叫归属的即时消息AS时，所述即时消息AS判断被叫用户是否具有客户端的登记，若有，则在所述即时消息系统内进行正常的后续消息流程的同时，将即时消息业务通过所述API转发到第二即时消息系统的OTT服务器，后续由所述OTT服务器下发给此被叫用户的OTT客户端。

这里，所述第一状态是指所述第二即时消息系统处于活跃状态，如没有超过一周未登录。

本发明提供的一种通信方法的第四实施例，如图7所示，所述方法包括：

步骤701、确定接入第一即时消息系统的移动通信终端在所述第一即时消息系统所使用的功能；

这里，所述第一即时消息系统基于电信系统实现即时消息通信，所述功能 基于第一协议；所述第一协议为SIP协议；

在实际应用中，所述功能包括至少以下功能中的一种：登记功能、即时消息功能、文件传输功能、群聊功能；

可以理解的是，所述移动通信终端通过SIP协议接入第一即时消息系统的IMS；

步骤702、将所述功能抽象为应用程序编程接口API；

这里，所述API采用第二协议；

可以理解的是，所述将第一即时消息系统的功能抽象为API包括至少以下抽象中的一种：

将SIP登记通告抽象为RESTful注册；

将SIP即时消息抽象为RESTful消息；

将SIP Invite/MSRP文件传输抽象为RESTful消息；

将SIP Invite/MSRP群聊抽象为RESTful群聊。

步骤703、所述第一即时消息系统通过所述API与第二即时消息系统进行交互，使接入所述第二即时消息系统的客户端获取所述移动通信终端通过所述第一即时消息系统进行通信的信息；

这里，所述客户端使用所述移动终端的唯一识别码进行的注册，所述第二即时消息系统基于互联网实现即时消息通信；所述第一协议与所述第二协议不相同。

步骤704、获取所述客户端的信息收发记录；

步骤705、根据所述信息收发记录，确定所述客户端的类别；

步骤706、当所述客户端为第一类别时，向所述客户端发送的消息中包括第一标识字段，所述第一标识字段用于指示所述客户端在收到所述消息后不做提示处理。

这里，所述第一类别是指所述客户端为静默客户端。具体的，即时消息AS将最近一条消息来自的客户端判定其为活跃客户端，另外一种客户端为静默客户端，当超过一定时间长度(如5分钟)时，若即时消息AS没有再收到消息， 则即时消息AS认为所有在线客户端均应视为活跃客户端。

本发明提供的一种即时消息系统的实施例，如图8所示，所述即时消息系统包括电信系统801，所述即时消息系统基于所述电信系统801实现即时消息通信，所示电信系统801用于确定接入所述即时消息系统的移动通信终端在所述即时消息系统所使用的功能，所述功能基于第一协议；所述即时消息系统还包括Network API设备802：

所述Network API设备802，用于将所述功能抽象为应用程序编程接口API，所述API采用第二协议；

所述电信系统801，用于通过所述API与第二即时消息系统进行交互，使接入所述第二即时消息系统的客户端获取所述移动通信终端通过所述即时消息系统进行通信的信息，所述客户端使用所述移动终端的唯一识别码进行的注册，所述第二即时消息系统基于互联网实现即时消息通信；

所述第一协议与所述第二协议不相同。

在实际应用中，所述移动通信终端通过SIP协议接入所述电信系统801的IMS；

所述第二即时消息系统为OTT即时消息系统，客户端通过HTTP协议接入OTT即时消息系统。

具体的，所述电信系统801的即时消息AS通过所述API和第二即时消息系统的OTT服务器进行交互。

在一实施例中，所述API基于OMA表述性状态转移架构RESTful，所述第二协议采用HTTP协议；

所述电信系统801，用于通过所述API和REST接口与所述第二即时消息系统进行交互；

所述API能够供所述第二即时消息系统通过所述第二协议调用，或者将所述即时消息系统内的消息或功能以HTTP调用或响应的方式告知所述第二即时消息系统。

在一实施例中，所述功能包括至少以下功能中的一种：登记功能、即时消 息功能、文件传输功能、群聊功能；所述第一协议为SIP协议；

参见图10所示，所述Network API设备802，用于将SIP登记通告抽象为RESTful注册；将SIP即时消息抽象为RESTful消息；将SIP Invite/MSRP文件传输抽象为RESTful消息；将SIP Invite/MSRP群聊抽象为RESTful群聊。

在一实施例中，所述电信系统801的即时消息AS，用于获取所述第二即时消息系统的登录记录；

根据所述登录记录，确定所述第二即时消息系统所处的状态；

当所述第二即时消息系统处于第一状态时，将所述第二即时消息系统具有客户端的信息进行登记。

当所述移动通信终端发送的消息到达主叫归属的即时消息AS时，所述即时消息AS用于判断主叫用户是否具有客户端的登记，若有，则在所述即时消息系统内进行正常的后续消息流程的同时，将即时消息业务通过所述API转发到第二即时消息系统的OTT服务器，后续由所述OTT服务器下发给此主叫用户的OTT客户端。

当即时消息到达被叫归属的即时消息AS时，所述即时消息AS用于判断被叫用户是否具有客户端的登记，若有，则在所述即时消息系统内进行正常的后续消息流程的同时，将即时消息业务通过所述API转发到第二即时消息系统的OTT服务器，后续由所述OTT服务器下发给此被叫用户的OTT客户端。

在一实施例中，所述即时消息AS用于获取所述客户端的信息收发记录；

根据所述信息收发记录，确定所述客户端的类别；

当所述客户端为第一类别时，向所述客户端发送的消息中包括第一标识字段，所述第一标识字段用于指示所述客户端在收到所述消息后不做提示处理。

下面结合附图和具体实施例对本发明的技术方案进一步详细阐述。

为解决同一用户分别拥有互联网和电信两类即时消息系统这一场景下的多终端消息收发问题，本发明提出了一种使用电信能力开放思想，将互联网即时消息系统作为电信能力开放的调用者，通过API方式与电信即时消息系统交互实现用户多终端消息收发和同步的技术方案。该方案整体架构如图9所示。

该方案中，通过在电信即时消息系统中设置Network API设备，将电信即时消息系统的能力，包含基于SIP协议的注册、即时消息、文件传输、群聊等抽象成使用HTTP协议，基于OMA表述性状态转移(representational state transfer,RESTFul)架构设计的的一组应用程序编程接口(Application Programming Interface,API)，这些API可以供OTT即时消息系统通过HTTP方法调用，或者将电信即时消息系统内的消息或能力以HTTP调用/响应的方式告知OTT即时消息系统。

该架构下，用户A和B的手机(UE_A、UE_B)使用电信融合通信方式实现即时消息，通过SIP协议接入电信融合通信系统中的IMS，其他客户端，如PC等(PC_A、PC_B)，使用互联网OTT方式实现即时消息，通过HTTP协议接入互联网OTT系统，同时，假设用户的所有OTT客户端均使用该用户的手机号码MSISDN进行注册，并且能够注册的用户应具备手机，同时其手机具有融合通信功能。融合通信系统和OTT系统分别负责各自客户端的接入、鉴权、业务处理工作。融合通信系统内的Network API负责将融合通信的能力抽象为RESTFul风格的API，而OTT系统内的Network API网关负责对这些API进行调用，两个消息系统间通过REST接口进行交互。这里需要说明的是，OTT系统内不设置Network API，仅通过Network API网关对电信系统能力进行调用以及被电信系统抽象出的HTTP方法进行访问。此处是假设OTT系统本身是基于HTTP相关方式实现，因此只需要设置网关即可，不需要再设置一个网管设备用于转化能力。但是，若OTT系统使用的私有协议是非标准协议，则需要设置一个OTT的Network API，将非标准协议转化为标准HTTP协议。

该方案中，同一用户不同终端之间的消息分发分别由融合通信系统内的即时消息AS和OTT系统内的OTT服务器通过API交互实现。若用户具备电信即时消息系统的同时还具备OTT即时消息系统，并且该OTT即时消息系统处于活跃状态(没有超过一周未登录)，则该用户具有OTT即时消息客户端这一信息将通过Network API在电信融合通信系统内登记。若OTT客户端一段时间未活跃，则用户具有OTT即时消息客户端这一信息将通过Network API在电信 融合通信系统内去除登记状态。

当用户在电信即时消息系统内的终端发送的消息到达主叫归属的电信融合通信系统应用服务器时，该服务器判断此主叫用户是否具有OTT客户端的登记，若有，则在电信即时消息系统内进行正常的后续消息流程的同时，将所有的即时消息、文件传输、群聊等即时消息业务均通过Network API设备转发到OTT即时消息系统的应用服务器，后续由OTT即时通信系统应用服务器下发给此主叫用户的OTT客户端，实现即时消息在主叫用户的电信即时消息客户端和OTT即时消息客户端之间的同步；

当电信系统内的即时消息到达被叫融合通信系统应用服务器时，该服务器判断此被叫用户是否具有OTT客户端的登记，若有，则在电信即时消息系统内进行正常的后续消息流程的同时，将所有的即时消息、文件传输、群聊等即时消息业务均通过Network API设备转发到OTT即时消息系统的应用服务器，后续由OTT即时通信系统应用服务器下发给此被叫用户的OTT客户端，实现即时消息同时发往被叫用户的电信即时消息客户端和OTT即时消息客户端。

此方法，不需要对电信网内的IMS系统进行改造。

该方案所涉及主要流程包括：

1互联网与电信即时通信系统融合后多终端管理

1.1多终端同时注册

由于融合通信客户端和OTT客户端分别属于不同系统，因此他们可以分别直接使用自身在本系统内原有的用户标识进行登录，而不需要对标识进行重新规划和分配。

为使融合通信系统内的IMS AS实现消息分发和后续路由，对于用户其他OTT客户端，每一个OTT客户端均会分配一个“伪”IMPU，形如MSISDN@pc.ims.mnc000.mcc460.3gppnetwork.org，其中MSISDN为用户手机号，该伪IMPU在IMS中无需写入HSS、无需EnumDNS配置、仅在用户同时具有OTT客户端时，将用户拥有OTT客户端这一信息通过登记的方式告知即时消息AS，即时消息AS根据该标识，无条件将收到的消息抄送一份到Network API，由 Network API进行后续路由。OTT客户端在融合通信系统的登记流程如下图所示：

用户具有手机UE_A，且UE_A已完成到融合通信系统的注册流程，同时，用户具有PC客户端PC_A，当PC_A第一次登陆时，需要向融合通信系统进行注册，参见图11所示，其流程如下：

1～2)PC_A通过OTT接入点向OTT服务器进行注册；

3～5)OTT服务器判断此用户是否曾经进行过注册，若有，则仅向PC_A回复注册成功响应；

6～7)否则，OTT服务器使用基于RESTFul架构的Network API，经过Network API GW，向融合通信系统内部的Network API设备发起登记请求，此登记请求携带用户的身份信息PC_A@pc.ims.mnc000.mcc460.3gppnetwork.org(其中PC_A为该用户A的MSISDN)，该用户PC客户端具备哪些业务能力；

8)Network API设备将此登记请求转为SIP Notify通知，告知融合通信即时消息AS用户A拥有PC客户端；

9)融合通信即时消息AS根据PC用户身份标识，将PC_A与已注册的融合通信用户UE_A进行关联，记录此用户同时具有Native/APP客户端UE_A以及PC客户端PC_A；

10)融合通信即时消息AS向融合通信Network API设备回复SIP 200OK确认消息

11)融合通信Network API设备使用基于RESTFul架构的Network API，经过Network API GW向OTT服务器回复登记成功响应。

对于OTT服务器，由于用户使用MSISDN进行注册，因此注册后OTT服务器可知该用户具有的手机端所在的服务器地址(可在用户OTT客户端注册时通过发起携带MSISDN的API查询等方式获得)，当消息需要同时发往该用户的手机时，OTT服务器可以将消息复制一份，直接通过API调用的方式将该复制的消息发往用户手机端所在的服务器地址。

1.2多终端远程控制

融合架构下，用户手机UE具有对自身OTT客户端进行远程控制的能力，可以获取当前OTT客户端的登录状态，并可以将OTT客户端强制注销，参见图12所示。

场景1：获取PC客户端登陆状态，参见图13所示：

1)UE_A直接向OTT接入发起Http查询请求；

2)OTT接入将查询请求转给用户OTT服务器；

3)用户OTT服务器向OTT接入返回用户OTT客户端当前登陆状态；

4)OTT接入将用户OTT客户端当前登陆状态返回给UE_A。

场景2：PC客户端强制注销，参见图14所示：

1～2)UE_A向OTT接入发起强制注销请求，OTT接入将强制注销请求转给用户OTT服务器；

3～6)用户OTT服务器更新OTT客户端注册状态，并将注销命令经OTT接入发往OTT客户端，OTT客户端回复注销成功响应；

7～8)OTT服务器经OTT接入向UE_A返回注销成功响应。

2互联网与电信即时通信系统融合后多终端消息收发方案

2.1消息收发总体策略

互联网与电信即时通信系统融合后，用户手机与OTT客户端之间的消息交互采用Network API方式进行。

对于手机，其收到的消息是基于SIP的融合通信消息，可通过消息SIP头中的From、To、Request-URI和P-Asserted-Identity四个头域的不同组合，判断多终端消息的业务类型。例如，用户B有手机UE_B，其标识为SIP URI＝“UE_B”，同时拥有OTT客户端，其标识为SIP URI＝“PC_B”,A的SIP URI＝“URI_A”各业务类型的消息头组合如下表，表2手机侧收到的各类消息业务SIP头域组合：

表2

即时消息AS在此场景下的路由规则如下：

收到来自IMS的SIP消息，则进行正常IMS后续路由流程，并判断是否需要使用Network API对OTT侧进行消息抄送

收到来自Network API的消息，则只进行正常IMS后续路由流程，不对OTT侧进行消息抄送。

2.2多终端消息抄送

用户可使用手机或OTT客户端发送消息。当用户拥有多个终端时，用户若使用某一客户端发送消息，另一个客户端可见同样发送出去的消息，当接收方用户拥有多个终端时，用户在一个设备上收到消息时，在另一个设备上也会收到同样的业务。下面以Pager Mode消息为例，说明多终端场景下的消息流程。Large Message Mode及文件传输路由方式与Pager Mode消息相同，流程省略递送报告过程。

场景1：用户A使用手机向用户B发送消息，参见图15所示：

用户A使用手机向用户B发送消息的流程如下

1～4)发送方UE_A经过主叫IMS发送即时消息到主叫所属的即时消息AS，主叫即时消息AS返回已收到即时消息的应答；

5～10)主叫即时消息AS经过主叫IMS和被叫IMS，向接收方用户UE_B 所归属的即时消息AS发送即时消息，被叫即时消息AS返回已收到即时消息的应答；

11)UE_A归属即时消息AS检查用户A是否有OTT客户端PC_A登记过，若有，则将Message消息复制一份发往融合通信Network API设备；

12～15)Network API设备使用基于RESTFul架构的Network API，经过Network API GW，向OTT服务器发送消息，OTT服务器返回已收到即时消息的应答；

16)Network API设备向UE_A归属即时消息AS返回已收到即时消息的应答；

17～20)OTT服务器通过OTT私有协议向PC_A发送此消息，PC_A收到此抄送消息并向OTT服务器返回已收到即时消息的应答；

21～24)被叫即时消息AS向接收方UE_B递送即时消息，接收方UE_B返回成功收到即时消息的应答；

25)UE_B归属即时消息AS检查用户A是否有PC客户端PC_B登记过，若有，则将Message消息复制一份发往融合通信Network API设备；

26～29)Network API设备使用基于RESTFul架构的Network API，经过Network API GW，向OTT服务器发送消息，OTT服务器返回已收到即时消息的应答；

30)Network API设备向UE_B归属即时消息AS返回已收到即时消息的应答；

31～35)OTT服务器通过OTT私有协议向PC_B发送此消息，PC_B收到此消息并向OTT服务器返回已收到即时消息的应答；

场景2：用户A使用OTT客户端向用户B发送消息

用户A使用OTT客户端向用户B发送消息的流程，参见图16所示，

1～4)发送方PC_A通过OTT私有协议向OTT服务器发送此消息，OTT服务器收到此消息并向PC_A返回已收到即时消息的应答；

5～6)OTT服务器使用基于RESTFul架构的Network API，经过Network API GW，向UE_A归属的Network API设备发送消息，此消息中包含有不转短信的标识；

7～8)UE_A归属的Network API设备将消息转为SIP Messge，发往用户UE_A归属的即时消息AS，UE_A归属的即时消息AS返回已收到即时消息的应答；

9～10)UE_A归属的Network API设备向OTT服务器返回已收到即时消息的应答；

11～14)UE_A归属的即时消息AS向抄送方UE_A递送即时消息，抄送方UE_A返回成功收到即时消息的应答；

15～16)OTT服务器使用基于RESTFul架构的Network API，经过Network API GW，向UE_B归属的Network API设备发送消息，此消息中包含有是否转短信的标识；

17～18)UE_B归属的Network API设备将消息转为SIP Messge，发往用户UE_B归属的即时消息AS，UE_B归属的即时消息AS返回已收到即时消息的应答；

19～20)UE_B归属的Network API设备向OTT服务器返回已收到即时消息的应答；

21～24)被叫UE_B归属的即时消息AS判断此消息是否需要转短信，此后向接收方UE_B递送即时消息，接收方UE B返回成功收到即时消息的应答，若UE_B不在线且消息需要转短信，则进行转短信处理；

25～28)OTT服务器通过OTT私有协议向PC_B发送此消息，PC_B收到此消息并向OTT服务器返回已收到即时消息的应答；

2.3消息静默提醒

为避免消息在OTT客户端和手机上双收双提示，需要增加静默功能。

多终端消息接收和抄送过程中，即时消息AS负责静默逻辑，即时消息AS将最近一条消息来自的客户端判定其为活跃客户端，另外一种客户端为静默客户端，此后，即时消息AS向需要静默的客户端发送的消息中加入需要静默标 志字段，客户端收到含有静默标志字段的消息后，不做提示处理。

当超过一定时间长度(如5分钟)时，若即时消息AS没有再收到消息，则即时消息AS认为所有在线客户端均应视为活跃客户端，均需要提醒消息。此时，即时消息AS向所有客户端发送的消息内都将不包含静默标志字段。

2.4定向消息

定向消息指同一用户的手机与OTT客户端之间可以互相发送消息。定向消息可分为用户手机向自身OTT客户端发送消息，以及OTT客户端向自身手机发送消息两种场景。

场景1：用户手机向自身OTT客户端发送消息，参见图17所示，

1～4)发送方UE_A经过主叫IMS发送到主叫所属的即时消息AS，主叫即时消息AS返回已收到即时消息的应答；

5)UA_A归属即时消息AS检查用户A是否有PC客户端PC_A登记过，若有，则将Message消息复制一份发往融合通信Network API设备；

6～9)Network API设备使用基于RESTFul架构的Network API，经过Network API GW，向OTT服务器发送消息，OTT服务器返回已收到即时消息的应答；

10)Network API设备向UE_A归属即时消息AS返回已收到即时消息的应答；

11～14)OTT服务器通过OTT私有协议向PC_A发送此消息，PC_A收到此消息并向OTT服务器返回已收到即时消息的应答；

场景2：用户OTT客户端向自身手机发送消息，参见图18所示，

1～4)发送方PC_A通过OTT私有协议向OTT服务器发送消息，OTT服务器收到此消息并向PC_A返回已收到即时消息的应答；

5～6)OTT服务器使用基于RESTFul架构的Network API，经过Network API GW，向UE_A归属的Network API设备发送消息，此消息中包含有不转短信的标识；

7～8)UE_A归属的Network API设备将消息转为SIP Messge，发往用户UE_A归属的即时消息AS，UE_A归属的即时消息AS返回已收到即时消息的 应答；

9～10)UE_A归属的Network API设备向OTT服务器返回已收到即时消息的应答；

11～14)UE_A归属的即时消息AS向UE_A递送即时消息，UE_A返回成功收到即时消息的应答；

2.5群聊

场景1：用户A使用手机建立群聊，参见图19所示，

1～9)发送方UE_A经过主叫IMS发起群聊创建请求到UE_A归属群聊服务器，UE_A归属群聊服务器进行应答，UE_A与UE_A归属群聊服务器之间建立MSRP通道；

10～16)UE_A归属群聊服务器检查用户A是否有OTT客户端PC_A曾经登记过，若有，则通过Network API将群聊创建请求发往融合通信Network API设备，Network API设备通过基于RESTFul架构的消息将邀请发往OTT服务器，OTT服务器进行应答后，UE_A归属群聊服务器与UE_A归属Network API设备间建立MSRP通道；

17～20)OTT服务器将群聊创建请求通过OTT消息抄送给UE_A自身OTT客户端PC_A；

21～27)UE_A归属群聊服务器向UE_B归属群聊服务器(即时消息AS)发送群聊创建请求，UE_B归属群聊服务器(即时消息AS)进行应答，与UE_A归属群聊服务器之间建立MSRP通道；

28～29)UE_B归属群聊服务器(即时消息AS)向UE_B发送群聊创建请求；

30～34)UE_B归属群聊服务器(即时消息AS)检查用户B的OTT客户端PC_B是否登记过，若有，则将群聊创建请求发往融合通信Network API设备，Network API设备通过基于RESTFul架构的消息将邀请发往OTT服务器，OTT服务器将此邀请发往PC_B；

35～38)若UE_B先接受群聊创建请求，则UE_B归属群聊服务器(即时消 息AS)与UE_B之间建立MSRP通道；

39～48)UE_B归属群聊服务器(即时消息AS)更新PC_B状态，将其加入群聊，并通过Network API通知PC_B，此后群聊消息均抄送给PC_B；

49～53)若OTT客户端先接受群聊创建请求，则OTT服务器通过Network API通知UE_B归属即时消息AS；

54～57)UE_B归属群聊服务器(即时消息AS)更新UE_B状态，将其加入群聊，更新群列表服务器，并将UE_B已加入群聊这一群聊变化信息通过Notify发送给UE_B，UE_B本地获得此群聊列表。

58～65)UE_B所在群聊服务器(即时消息AS)发送Cancel消息，结束此前发往UE_B的群聊创建请求；

66～71)UE_B归属群聊服务器(即时消息AS)使用激活群聊的消息邀请UE_B加入群聊，UE_B接受邀请，与UE_B归属新消息模块建立MSRP通道。

场景2：用户A使用OTT客户端建立群聊，参见图20所示，

1～4)用户A的OTT客户端PC_A发起群聊，OTT服务器接受群聊请求；

5-12)OTT服务器检查用户A是否有手机客户端UE_A，若有，通过Network API将群聊建立请求抄送给手机侧，Network API将群聊创建请求发送给UE_A归属的群聊服务器，与UE_A归属的群聊服务器之间建立MSRP通道；

13～18)UE_A归属的群聊服务器更新用户更新UE_A状态，将UE_A加入群聊，更新群列表服务器，并将UE_A已加入群聊这一群聊变化信息通过Notify发送给UE_A，UE_A本地获得此群聊列表；

19～27)UE_A归属群聊服务器使用激活群聊的消息邀请UE_A加入群聊，UE_A接受邀请，与UE_A归属群聊服务器建立MSRP通道；

28～32)PC群聊服务器向UE_B归属群聊服务器(即时消息AS)发送群聊创建请求，UE_B归属群聊服务器(即时消息AS)进行应答，与UE_A归属群聊服务器之间建立MSRP通道；

33～34)UE_B归属群聊服务器(即时消息AS)向UE_B发送群聊创建请求；

35～36)OTT服务器向PC_B发送群聊创建请求；

37～40)若UE_B先接受群聊创建请求，则UE_B归属群聊服务器(即时消息AS)与UE_B之间建立MSRP通道；

41～50)UE_B归属群聊服务器(即时消息AS)更新PC_B状态，将其加入群聊，并通过Network API通知PC_B，此后群聊消息均抄送给PC_B；

51～55)若PC客户端先接受群聊创建请求，则OTT服务器通过Network API通知UE_B归属新消息模块；

56～59)UE_B归属群聊服务器(即时消息AS)更新UE_B状态，将其加入群聊，更新群列表服务器，并将UE_B已加入群聊这一群聊变化信息通过Notify发送给UE_B，UE_B本地获得此群聊列表。

60～67)UE_B所在群聊服务器(即时消息AS)发送Cancel消息，结束此前发往UE_B的群聊创建请求；

68～73)UE_B归属群聊服务器(即时消息AS)使用激活群聊的消息邀请UE_B加入群聊，UE_B接受邀请，与UE_B归属群聊服务器(即时消息AS)建立MSRP通道。

本发明相比其他技术具有以下优点：

实现了在电信网与互联网两种不同机制的网络中的实现异构多终端同时在线和消息同步的即时消息，同一个用户可以分别拥有基于电信标准的即时消息客户端和基于互联网OTT私有协议方式实现的的即时消息客户端，并且两类客户端就有相同的用户身份；

不需要对电信核心网设备就行修改，不改变IMS路由流程，所有到PC侧的消息抄送逻辑由应用服务器进行，同时不需要改变OTT侧的协议和实现模式，由OTT服务器作为API调用方控制消息流程。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用硬件实施例、软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储 器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。