CN109120502B - 用于多业务融合平台的通信方法、设备、系统及存储介质 - Google Patents

Abstract

本发明公开了一种用于多业务融合平台的通信方法、设备、系统及存储介质。其中，该系统包括：业务处理组件，包含至少两个业务处理节点，用于当接收到源用户的起呼消息后，通过源业务处理节点根据起呼消息向策略管理组件查询终呼消息的分发策略，并基于查询结果确定终呼消息的业务类型，再通过目的业务处理节点将业务类型的终呼消息发送至目的用户；策略管理组件，用于存储终呼消息的分发策略。本发明有效解决多业务融合平台上不同业务间消息内部互通的问题，帮助电信运营商改善用户体验，增强用户黏性，同时降低系统整体通信开销。

Description

用于多业务融合平台的通信方法、设备、系统及存储介质

技术领域

本发明涉及通信技术领域，特别是涉及一种用于多业务融合平台的通信方法、设备、系统及存储介质。

背景技术

随着全球移动业务的快速发展，包括短信、多媒体消息、移动电子邮件以及移动即时通信等消息类业务作为移动话音之外的重要业务，已经获得广泛的应用。各类消息业务提供了不同的用户体验，同时不同的消息业务构建了不同的架构和平台，随着用户使用习惯的改变，各种消息类业务的功能相互重合越来越严重，部分消息类产品的发展已趋于停滞。多平台的维护不仅仅带来维护人力上的增加，同时在各平台之间的消息互转也造成了通讯资源的浪费。

现阶段的通讯运营商，尤其是跨国运营商都面临着减低CAPEX(资本性输出)和OPEX(运营成本)的重任，新业务的部署，或者现网已有业务的扩容或替换，都要遵循降低TCO(总所有成本)的原则，以最小的投入，产生最大的收益。可融合多业务的统一平台成为一种解决方法。但是，如何在保证整体通信开销的前提下，实现多业务融合平台内部的消息互通成为各大运营商研究的一个重点。

发明内容

本发明提供一种用于多业务融合平台的通信方法、设备、系统及存储介质，用以在保证整体通信开销的前提下，实现多业务融合平台内部的消息互通。

为实现上述发明目的，本发明采用下述的技术方案：

依据本发明的一个方面，提供一种用于多业务融合平台的通信系统，包括：

业务处理组件，包含至少两个业务处理节点，用于当接收到源用户的起呼消息后，通过源业务处理节点根据所述起呼消息向策略管理组件查询终呼消息的分发策略，并基于查询结果确定终呼消息的业务类型，再通过目的业务处理节点将所述业务类型的终呼消息发送至目的用户；

所述策略管理组件，用于存储所述终呼消息的分发策略。

可选的，所述终呼消息的分发策略包括业务能力选择策略；所述业务处理组件具体用于：

当查询的业务能力选择策略为强制从某一业务终呼时，将该业务的业务类型作为所述终呼消息的业务类型；

当查询的业务能力选择策略为优先从某一业务终呼时，从所述策略管理组件查询目的用户状态，并结合所述目的用户状态确定所述终呼消息的业务类型。

可选的，所述终呼消息的分发策略还包括节点分发策略；所述业务处理组件具体用于：

当包含业务处理节点大于两个时，则根据所述节点分发策略从可处理所述业务类型的业务处理节点中选取所述目的业务处理节点。

可选的，所述节点分发策略包括轮询分发、按目的号码取模分发以及分发给所述源业务处理节点。

可选的，所述系统还包括统一终呼消息队列，用于存储所述终呼消息；所述业务处理组件，还用于：

通过源业务处理节点将所述终呼消息缓存至统一终呼消息队列中，并向所述目的业务处理节点转发呼叫请求；

待所述目的业务处理节点接收到所述呼叫请求，从所述统一终呼消息队列中获取所述终呼消息，并将所述终呼消息转发至目的用户。

可选的，所述系统还包括：

接口机组件，用于将接收的源用户的起呼消息和发送至目的用户的终呼消息进行协议转换和路由。

依据本发明的一个方面，提供一种用于多业务融合平台的通信方法，其特征在于，包括：

当接收到源用户的起呼消息后，通过源业务处理节点根据所述起呼消息查询终呼消息的分发策略，并基于查询结果确定终呼消息的业务类型；

通过目的业务处理节点将所述业务类型的终呼消息发送至目的用户。

可选的，所述终呼消息的分发策略包括业务能力选择策略；所述基于查询结果确定终呼消息的业务类型，包括：

当查询的业务能力选择策略为强制从某一业务终呼时，则将该业务的业务类型作为所述终呼消息的业务类型；

当查询的业务能力选择策略为优先从某一业务终呼时，则查询目的用户状态，并结合所述目的用户状态确定所述终呼消息的业务类型。

可选的，所述终呼消息的分发策略还包括节点分发策略；所述基于查询结果确定终呼消息的业务类型后，所述方法还包括：

根据节点分发策略的查询结果，从可处理所述业务类型的业务处理节点中选取所述目的业务处理节点。

可选的，所述节点分发策略包括轮询分发、按目的号码取模分发以及分发给所述源业务处理节点。

可选的，所述基于查询结果确定终呼消息的业务类型后，所述方法还包括：将终呼消息缓存至统一终呼消息队列中，并向所述目的业务处理节点转发呼叫请求；

所述通过目的业务处理节点将所述业务类型的终呼消息发送至目的用户，具体包括：通过所述目的业务处理节点接收到所述呼叫请求后，从所述统一终呼消息队列中获取所述终呼消息，并将所述终呼消息转发至目的用户。

可选的，所述方法还包括：

在接收到源用户的起呼消息之前以及在将终呼消息发送至目的用户之前，通过接口机将所述起呼消息和所述终呼消息进行协议转换和路由。

依据本发明的一个方面，提供一种用于多业务融合平台的通信设备，其特征在于，包括处理器和存储器；所述存储器上存储有可用在所述处理器上运行的计算机程序，当所述计算机程序被所述处理器执行时实现上述所述的方法中的步骤。

依据本发明的一个方面，提供一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现上述所述的方法中的步骤。

本发明有益效果如下：

本发明提供的用于多业务融合平台的通信方法、设备、系统及存储介质，在用户发送消息时，根据预设的分发策略进行综合判断，决定消息最终是以何种业务形式进行终呼。因此，本发明有效解决多业务融合平台上不同业务间消息内部互通的问题，帮助电信运营商改善用户体验，增强用户黏性，同时降低系统整体通信开销。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

为了更清楚地说明本发明实施例或现有中的方案，下面将对实施例或现有描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明一实施例中用于多业务融合平台的通信系统的结构框图；

图2为本发明一实施例中消息分发策略管理组件的配置示意图；

图3为本发明一实施例中业务间消息互通的流程图；

图4为本发明一实施例中短信业务转RCS业务的交互流程图；

图5为本发明一实施例中用于多业务融合平台的通信方法的流程图；

图6为本发明实施例中用于多业务融合平台的通信系统的原理框图。

具体实施方式

以下结合附图以及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不限定本发明。

在多业务融合平台上，不同用户可能开通了不同的业务能力。假设用户A开通了RCS(Rich Comunication Suit，融合通信)业务能力，用户B开通了短信业务能力，用户C开通了短信和RCS两种业务能力。在业务间没有实现消息互通的情况下，用户A给用户B发送了一条RCS消息，由于用户B不具备RCS业务能力，用户B接收不到消息，消息将发送失败；同样，用户A给用户C发送了一条RCS消息，虽然用户C开通了RCS业务能力，但是如果C不在线，也不能收到用户A的消息。

为了解决上述的问题，本发明的基本思路在于：在用户发送消息时，根据用户业务能力、用户状态或者用户归属等信息进行综合判断，决定消息最终以哪种业务类型进行终呼，提高用户的使用体验。基于以上例子中，本发明中在用户A给用户B发送RCS消息，根据用户B的业务能力将RCS消息转为短信，从短信业务通道终呼下发给用户B；用户A给用户C发送RCS消息时，本发明会根据用户C的业务能力和用户状态决定从RCS业务通道还是短信业务通道终下发呼消息给用户C。下面结合附图对本发明的技术内容进行详细说明

系统实施例

如图1所示，本发明实施例所提供的用于多业务融合平台的通信系统，包括业务处理组件11和策略管理组件12；其中，

业务处理组件11，包含至少两个业务处理节点，用于当接收到源用户的起呼消息后，通过源业务处理节点根据起呼消息向策略管理组件查询终呼消息的分发策略，并基于查询结果确定终呼消息的业务类型，再通过目的业务处理节点将业务类型的终呼消息发送至目的用户；

策略管理组件，用于存储终呼消息的分发策略。

可选的，为了满足大业务量要求，业务处理组件11中的业务处理节点可能包含多个。这些业务处理节点可以为同种类型业务能力，还可以为不同类型的业务能力。因此，在源业务处理节点发送起呼消息后，需要从多个业务处理节点中选取一业务处理节点作为目的业务处理节点，对于选取过程在后续进行介绍，这里不做具体的介绍。

其中，每个业务处理节点中都要部署一对业务进程和分发控制进程；其中，业务进程负责具体业务逻辑的处理。例如图1所示，一个业务进程对应一个业务类型(短信，彩信，RCS等)；分发控制进程负责终呼消息分发决策，决定由哪个业务能力通道以及业务处理节点负责消息终呼。

策略管理组件12用于存储终呼消息的分发策略。

具体地，策略管理组件12包括消息分发管理组件和用户状态管理组件；其中，消息分发管理组件用于管理和配置业务能力选择策略；用户状态管理组件用来配置和更新用户开户，用户状态等信息。

其中，业务能力选择策略按照源业务(起呼消息类型)进行分类配置，每种源业务配置一套终呼业务能力选择策略。例如，图2所示。这里，源业务包括短信、彩信和RCS。其中，针对短信/彩信业务可以配置强制源业务(本业务)终呼，强制RCS业务终呼，优先源业务(本业务)终呼，优先RCS业务终呼等；针对RCS业务可以配置强制源业务(本业务)终呼，强制短信业务终呼，优先源业务(本业务)终呼，优先短信业务终呼等。

其中，当配置了强制从某一业务(源业务或者其他业务)终呼，业务处理组件11通过源业务处理节点查询到该配置信息后，不需要作其他条件判断，直接判定某一业务(源业务/其他业务)对应的业务类型为终呼消息的类型，并从相应的他业务通道终呼；配置了优先从某一业务(源业务/其他业务)终呼，业务处理组件11通过源业务处理节点查询到该配置信息后，还需要进一步结合用户状态等信息综合决策从哪个业务通道终呼(确定终呼消息的类型)。

在结合目的用户状态确定终呼消息的业务类型时，判断优先的业务类型是否可以执行；当不能执行时，则选择其他业务的业务类型作为终呼消息的类型；否则，将优先业务的业务类型作为最终消息的类型。例如，当用户在线时，则可选择RCS消息进行终呼；当不在线时，则可选择短信消息进行终呼；当用户未开户时，则终呼失败。

可选的，消息分发管理组件中还设置有节点分发策略。当业务处理组件11中包含多个业务节点时，需要根据节点分发策略确定最终的目的业务处理节点。

具体地，在根据业务能力选择策略确定了终呼消息业务类型(能力)后，决定如何选择对应的目的业务处理节点。其中，节点分发策略包括轮询分发，按目的号码取模以及分发给源业务处理节点。这里节点分发策略也是按业务能力进行分类配置，不同类型的业务的节点分发策略可能也不一样。

例如图3所示，针对短信的节点分发策略包括按目的号码取模分发和分发给源业务处理节点；针对RCS的节点分发策略包括按目的号码取模分发和分发给源业务处理节点；而针对彩信的节点分发策略则包括轮询分发和分发给。

进一步的，该用于多业务融合平台的通信系统还包括统一终呼消息队列13。这里，统一终呼消息队列13用来统一缓存终呼消息。

具体地，当源业务处理节点确定终呼消息的业务类型后，将终呼消息缓存至统一终呼消息队列13中，并向目的业务处理节点转发呼叫请求；目的业务处理节点用于接收到所述呼叫请求后，从统一终呼消息队列13中获取终呼消息，并将终呼消息转发至目的用户。

可知，整个通信系统中只有一个统一终呼消息队列，通过对终呼消息进行统一缓存，便于实现不同业务间消息共享互通。

进一步的，该用于多业务融合平台的通信系统还包括接口机组件14；这里的接口机组件14包括各种信令接入，不同业务包含不同的信令。接口机组件作为用户消息起呼呼入的入口和消息终呼呼出的出口，负责系统内外部协议转换和消息路由。其中，可选的，每种业务类型对应一种接口机，由接口机进行相应业务类型消息的编解码，实现协议的转换。

这里，接口机组件14将接收的源用户的起呼消息和发送至目的用户的终呼消息进行协议转换和路由。

具体地，接口机组件14当接收到用户起呼消息呼入后，通过对起呼消息进行协议解码并路由至发送给内部的业务处理组件11进行分发处理；而当业务处理组件11分发决策处理完毕后，确定目的业务处理节点后，由目的处理节点从同一终呼消息队列中取出终呼消息，并由接口机组件14将终呼消息进行协议编码转换后路由并发送至目的用户。

下面结合具体实施例对本发明中通信系统的工作过程进行详细说明，具体地，如图3所示，包括如下步骤：

步骤301，接口机组件14接收到用户起呼消息呼入，协议解码后路由发送给内部业务处理组件11。

步骤302，源业务处理节点的业务进程接收到接口机分发的用户起呼消息，向分发控制进程发起终呼消息分发决策请求。

步骤303，分发控制进程向消息分发管理组件查询业务能力选择策略和节点分发策略，同时向用户状态管理组件查询用户开户信息以及用户状态信息等，根据查询结果进行综合决策，确定目的业务能力类型以及对应的具体业务处理节点，并向业务进程返回终呼消息业务类型以及目的业务处理节点。

步骤304，源业务处理节点的业务进程向统一终呼消息队列缓存终呼消息，同时向目的业务处理节点的业务进程转发终呼请求。

步骤305，目的业务处理节点的业务进程从统一终呼消息队列取出终呼消息，向接口机组件14下发终呼消息。

步骤306，接口机组件14对终呼消息编码并路由给目的用户。

基于上述可知，本发明的多业务融合平台的通信系统，通过接口机组件14、业务处理组件11、策略组件组件以及统一终呼消息队列组件13的相互配合，实现了多业务融合平台上业务间消息的互通，提供了一种新的业务运营模式，有效改善用户的体验。

进一步的，为了体现不同业务之间的消息交互，本发明以短信业务转RCS业务为例，说明了多业务融合平台上不同业务间消息互转交互流程。如图4所示，具体流程包括如下步骤：其中，步骤401～403为消息起呼流程，步骤404～414为消息终呼流程。

步骤401，短信信令接口机向短信业务处理进程提交收到的用户短消息起呼请求。

步骤402，短信业务处理进程进行基本的用户鉴权，业务鉴权等原有短信业务的基本业务控制起呼流程处理并且出起呼话单。

步骤403，短信业务处理进程向短信信令接口机回起呼响应，起呼流程结束。

步骤404，短信业务处理进程向分发控制进程发起终呼消息决策请求。

步骤405，分发控制进程向策略管理组件查询业务能力选择策略，节点分发策略配置，以及用户开户信息和/或用户状态信息等。

步骤406，策略管理组件向分发控制进程返回查询结果。

步骤407，分发控制进程根据策略管理组件查询结果进行综合决策，确定目的业务能力为短信(或RCS)以及对应的短信(或RCS)业务处理节点，并向起呼发起的短信业务处理进程返回决策结果；当决策结果为终呼业务类型仍然为短信，则继续短信业务原来的终呼流程，不存在业务间消息互转；如果决策结果终呼业务类型为RCS，则继续步骤408完成消息终呼。

步骤408，短信业务处理进程往统一终呼队列缓存终呼消息。

步骤409，短信业务处理进程向目的RCS业务处理进程转发终呼请求。

步骤410，RCS业务处理进程从统一终呼消息队列取出终呼消息。

步骤411，RCS业务处理进程向RCS信令接口机下发终呼消息。

步骤412，RCS信令接口机编码终呼消息并下发给目的用户，并将下发结果返回给RCS业务处理进程。

步骤413，RCS业务处理进程给短信业务处理进程回终呼响应。

步骤414，短信业务处理进程根据RCS业务处理进程返回的终呼响应结果决定是否需要重试；如果RCS返回失败则终呼消息重入统一终呼队列重新发起上述终呼流程；如果返回成功则直接出终呼话单，终呼流程结束。

基于上述可知，本发明实施例中所提供的用户多业务融合平台的通信系统，在用户发送消息时，根据预设的分发策略进行综合判断，最终决定消息是以何种业务形式进行终呼。因此，本发明有效解决多业务融合平台上不同业务间消息内部互通的问题，帮助电信运营商改善用户体验，增强用户黏性，同时降低系统整体通信开销。

方法实施例

本发明实施例还提供了一种用于多业务融合平台的通信方法，用于上述的通信系统，如图5所示，具体包括如下步骤：

步骤501，当接收到源用户的起呼消息后，通过源业务处理节点根据所述起呼消息查询终呼消息的分发策略，并基于查询结果确定终呼消息的业务类型；

步骤502，通过目的业务处理节点将所述业务类型的终呼消息发送至目的用户。

其中，在步骤401中，配置有终呼消息的分发策略，在进行通信时，直接查询分发策略即可。其中，这里的终呼消息的分发策略包括业务能力选择策略。这里，业务能力选择策略按照源业务(起呼消息类型)进行分类配置，每种源业务配置一套终呼业务能力选择策略。其中，在查询终呼消息的分发策略时，根据起呼消息的类型选择相应的业务能力选择策略。在选定相应的策略后，获取查询结果，并基于查询结合确定终呼消息的业务类型。

具体地，在基于查询结果确定终呼消息的业务类型，包括：

当查询的业务能力选择策略为强制从某一业务(源业务或者其他业务)终呼时，则将某一业务的业务类型作为终呼消息的业务类型；

当查询的业务能力选择策略为优先从某一业务(源业务或者其他业务)终呼时，则查询目的用户状态，并结合目的用户状态确定终呼消息的业务类型。

其中，用户状态可以通过查询相关信息获取并配置在分发策略中。而后需要查询该信息时，则直接获取即可。在结合目的用户状态确定终呼消息的业务类型时，判断优先的业务类型是否可以执行；当不能执行时，则选择其他业务的业务类型作为终呼消息的类型；否则，将优先业务的业务类型作为最终消息的类型。

这里的用户状态包括开户信息以及在线与否等状态信息。在基于用户状态确定终呼消息的业务类型，可选的，当用户在线时，可以通过RCS消息进行终呼；当用户不在线时，可以通过短信消息进行终呼；当用户未开户时，则终呼失败。

其中，可选的，终呼消息的分发策略还包括节点分发策略，在基于查询结果确定终呼消息的业务类型后，还包括：

根据节点分发策略的查询结果，从可处理业务类型的业务处理节点中选取目的业务处理节点。

由于系统为了满足大业务量要求，除了源业务处理节点和目的业务处理节点，还可能包含多个业务处理节点。这些业务处理节点可以为同种类型业务能力，还可以为不同类型的业务能力。因此，在确定终呼消息的业务类型后，需要从同种业务类型的节点中获取目的业务处理节点。其中，节点分发策略包括轮询分发，按目的号码取模以及分发给源业务处理节点。

进一步的，在基于查询结果确定终呼消息的业务类型后，方法还包括：将终呼消息缓存至统一终呼消息队列中，并向目的业务处理节点转发呼叫请求；通过目的业务处理节点将业务类型的终呼消息发送至目的用户，具体包括：通过目的业务处理节点接收到呼叫请求后，从统一终呼消息队列中获取终呼消息，并将终呼消息转发至目的用户。

进一步的，该方法还包括：

在接收到源用户的起呼消息之前以及在将终呼消息发送至目的用户之前，通过接口机将起呼消息和终呼消息进行协议转换和路由。

基于上述可知，本发明实施例中所提供的通信方法，能够实现不同业务之间的消息互通，充分体现了多业务融合平台的优势。需要说明的是，由于系统实施例中对系统的工作流程进行了详细说明，因此，方法实施例中仅做了简单的说明，但是应当理解的是，方法实施例中可包含系统实施例中的部分特征或者全部特征。

设备实施例

本发明实施例还提供了一种用于多业务融合平台的通信设备，用以实现上述的方法，如图6所示，该设备包括处理器62以及存储有处理器62可执行指令的存储器61；其中，存储器61中存储有计算机可执行的程序，处理器62用于执行存储器61中的程序时，以实现上述的用于多业务融合平台的通信方法中的部分步骤或者全部步骤。

其中，处理器62可以是通用处理器，例如中央处理器(central processingunit，CPU)，还可以是数字信号处理器(digital signal processor，DSP)、专用集成电路(application specific integrated circuit，ASIC)，或者是被配置成实施本发明实施例的一个或多个集成电路。

其中，存储器61，用于存储程序代码，并将该程序代码传输给CPU。存储器61可以包括易失性存储器(volatile memory)，例如随机存取存储器(random access memory，RAM)；存储器61也可以包括非易失性存储器(non-volatile memory)，例如只读存储器(read-only memory，ROM)、快闪存储器(flash memory)、硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)；存储器61还可以包括上述种类的存储器的组合。

存储介质实施例

本发明实施例还提供了一种计算机可读存储介质。这里的计算机可读存储介质存储有一个或者多个程序。其中，计算机可读存储介质可以包括易失性存储器，例如随机存取存储器；存储器也可以包括非易失性存储器，例如只读存储器、快闪存储器、硬盘或固态硬盘；存储器还可以包括上述种类的存储器的组合。当计算机可读存储介质中所述一个或者多个程序可被一个或者多个处理器执行，以实现上述的用于多业务融合平台的通信方法中的部分步骤或者全部步骤。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，程序可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。

虽然通过实施例描述了本申请，本领域的技术人员知道，本申请有许多变形和变化而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (12)

1.一种用于多业务融合平台的通信系统，其特征在于，包括：

业务处理组件，包含至少两个业务处理节点，用于当接收到源用户的起呼消息后，通过源业务处理节点根据所述起呼消息向策略管理组件查询终呼消息的分发策略，并基于查询结果确定终呼消息的业务类型，再通过目的业务处理节点将所述业务类型的终呼消息发送至目的用户；

所述策略管理组件，用于存储所述终呼消息的分发策略；

每个所述业务处理节点对应一种业务类型；所述系统还包括统一终呼消息队列，用于存储所述终呼消息；所述业务处理组件，还用于：

通过源业务处理节点将所述终呼消息缓存至统一终呼消息队列中，并向所述目的业务处理节点转发呼叫请求；

待所述目的业务处理节点接收到所述呼叫请求，从所述统一终呼消息队列中获取所述终呼消息，并将所述终呼消息转发至目的用户。

2.如权利要求1所述的系统，其特征在于，所述终呼消息的分发策略包括业务能力选择策略；所述业务处理组件具体用于：

当查询的业务能力选择策略为强制从某一业务终呼时，将该业务的业务类型作为所述终呼消息的业务类型；

当查询的业务能力选择策略为优先从某一业务终呼时，从所述策略管理组件查询目的用户状态，并结合所述目的用户状态确定所述终呼消息的业务类型。

3.如权利要求1所述的系统，其特征在于，所述终呼消息的分发策略还包括节点分发策略；所述业务处理组件具体用于：

当包含业务处理节点大于两个时，则根据所述节点分发策略从可处理所述业务类型的业务处理节点中选取所述目的业务处理节点。

4.如权利要求3所述的系统，其特征在于，所述节点分发策略包括轮询分发、按目的号码取模分发以及分发给所述源业务处理节点。

5.如权利要求1～4任一项所述的系统，其特征在于，所述系统还包括：

接口机组件，用于将接收的源用户的起呼消息和发送至目的用户的终呼消息进行协议转换和路由。

6.一种用于多业务融合平台的通信方法，其特征在于，包括：

当接收到源用户的起呼消息后，通过源业务处理节点根据所述起呼消息查询终呼消息的分发策略，并基于查询结果确定终呼消息的业务类型；

通过目的业务处理节点将所述业务类型的终呼消息发送至目的用户；

每个所述业务处理节点对应一种业务类型；所述基于查询结果确定终呼消息的业务类型后，所述方法还包括：将终呼消息缓存至统一终呼消息队列中，并向所述目的业务处理节点转发呼叫请求；

所述通过目的业务处理节点将所述业务类型的终呼消息发送至目的用户，具体包括：通过所述目的业务处理节点接收到所述呼叫请求后，从所述统一终呼消息队列中获取所述终呼消息，并将所述终呼消息转发至目的用户。

7.如权利要求6所述的方法，其特征在于，所述终呼消息的分发策略包括业务能力选择策略；所述基于查询结果确定终呼消息的业务类型，包括：

当查询的业务能力选择策略为强制从某一业务终呼时，则将该业务的业务类型作为所述终呼消息的业务类型；

当查询的业务能力选择策略为优先从某一业务终呼时，则查询目的用户状态，并结合所述目的用户状态确定所述终呼消息的业务类型。

8.如权利要求6所述的方法，其特征在于，所述终呼消息的分发策略还包括节点分发策略；所述基于查询结果确定终呼消息的业务类型后，所述方法还包括：

根据节点分发策略的查询结果，从可处理所述业务类型的业务处理节点中选取所述目的业务处理节点。

9.如权利要求8所述的方法，其特征在于，所述节点分发策略包括轮询分发、按目的号码取模分发以及分发给所述源业务处理节点。

10.如权利要求6～9任一项所述的方法，其特征在于，所述方法还包括：

在接收到源用户的起呼消息之前以及在将终呼消息发送至目的用户之前，通过接口机将所述起呼消息和所述终呼消息进行协议转换和路由。

11.一种用于多业务融合平台的通信设备，其特征在于，包括处理器和存储器；所述存储器上存储有可用在所述处理器上运行的计算机程序，当所述计算机程序被所述处理器执行时实现权利要求6～10任一项所述的方法中的步骤。

12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现权利要求6～10任一项所述的方法中的步骤。

Images