CN101132401A - 业务交互处理方法和系统 - Google Patents

Abstract

本发明公开了一种业务交互处理方法和系统，其核心是：第一业务处理节点根据当前业务执行情况，向第二业务处理节点发送业务触发信息；所述第二业务处理节点根据所述业务触发信息进行相应的业务处理控制。通过本发明，使业务交互问题能够在呼叫过程中被动态处理，也就是说，在呼叫过程中业务处理节点可以灵活控制业务的调用，并能对已经调用的业务做出调整。

Description

业务交互处理方法和系统

技术领域

本发明涉及通信领域，尤其涉及业务交互的处理技术。

背景技术

IP多媒体子系统(IMS，IP Multimedia System)是第三代移动通信标准化伙伴项目(3GPP)在版本5中引入的一个基于会话初始化协议(SIP，SessionInitiation Protocol)的体系，它的会话层和业务层是分离的。

3GPP技术标准(3GPP TS)23.218中定义的IMS系统的业务架构如图1所示，包括服务呼叫会话控制功能(S-CSCF，Call Session Control Function)实体、归属用户服务器(HSS，Home Subscriber Server)、SIP应用服务器、开放业务接入(OSA，Open Service Access)应用服务器、IMS业务交换功能(IM-SSF，IMS Service Switch Function)应用服务器以及业务能力交互管理器(SCIM，Service Capability Interaction Manager)。

其中S-CSCF实体为会话层实体，提供用户注册管理、会话控制、与业务平台交互等功能。

所述HSS是IMS网络中关键的数据存储实体，其上存储的数据包括用户身份、注册信息、业务档案以及鉴权接入数据等。

SIP应用服务器、OSA应用服务器和IM-SSF应用服务器属于业务层实体应用服务器(AS，Application Server)。其中SIP应用服务器用于实现基于SIP的增值应用；OSA应用服务器用于实现基于OSA应用程序接口(API)的第三方应用，OSA应用服务器需通过OSA业务能力服务器(SCS，ServiceCapability Server)与IMS核心网进行交互；IM-SSF应用服务器用于支持在IMS域内提供移动网络增强逻辑的客户化应用(CAMEL)业务能力。

所述SCIM是3GPP业务体系中存在的一类特殊SIP应用服务器，它用于管理多个应用服务器间的业务交互，但3GPP并没有对SCIM的应用进行详细的说明。

IMS体系下会话层和业务层是分离的，会话层实体不提供业务，但可以通过初始过滤规则(iFC，Initial Filter Criteria)调用业务层实体。另外，IMS系统提供OSA这类开放的接口，用于第三方进行业务开发。在未来的网络中用户可以使用的业务会越来越丰富，随着业务的不断丰富，业务交互问题也会越来越突出。

业务交互问题不仅仅限于业务冲突问题，广义上的业务交互问题包括会话层实体间的交互(如会话层实体间传递业务交互信息)、业务层实体间的交互(如两个业务间的冲突处理)，以及会话层实体与业务层实体间的交互(如会话层实体到业务层实体的触发处理)。

在3GPP中，目前使用的初始过滤规则是一种会话层实体和业务层实体间的交互规则，它是一种预置的静态触发规则，不能根据其在呼叫过程中动态处理如下的业务交互场景：

1、业务层实体在呼叫中下发后续消息的业务过滤规则；

2、根据业务层实体的状态/负荷等进行动态的消息分发处理；

3、对冲突的业务进行限制处理；

4、对冲突业务进行修正处理；

5、业务层实体间协同工作；

6、业务过滤规则相互关联，前一业务过滤规则的处理结果与后续业务过滤规则有关联关系；

7、业务层实体下发业务交互指示控制与其它业务的交互关系。

由上述可见，目前3GPP的业务交互处理机制还比较薄弱，因此，为了适应用户越来越丰富的业务，迫切需要在呼叫过程中动态处理业务交互问题的技术。

发明内容

本发明的目的是提供一种业务交互处理方法和系统，通过本发明，能够在呼叫过程中动态处理业务交互问题，也就是说，可以在呼叫过程中灵活控制业务的调用并能对已经调用的业务做出调整。

本发明是通过如下的技术方案实现的：

本发明提供一种业务交互处理方法，其包括：

A、第一业务处理节点根据当前业务执行情况，产生业务触发信息并将其发送给第二业务处理节点；

B、所述第二业务处理节点根据所述业务触发信息进行相应的业务处理控制。

其中，所述第一业务处理节点包括：业务控制点、业务触发点或用户终端；

所述第二业务处理节点包括：业务控制点或业务触发点。

其中，所述当前业务执行情况包括如下情况中的至少一种：业务控制点接受了用户更新的业务数据；业务控制点接收到通信消息；业务触发点上业务触发成功；业务控制点的当前状态发生迁移；用户终端接受了业务请求。

其中，所述将其发送给第二业务处理节点的过程，具体包括：

通过发送通信消息的消息体或头域或参数携带所述业务触发信息，并发送给所述第二业务处理节点。

其中，所述通信消息包括：

业务处理节点间存在的当前通信过程中传递的通信消息；或，

业务处理节点间存在的当前通信过程外传递的通信消息；或，

在业务处理节点间新建的通信过程传递的通信消息。

其中，当业务触发信息通过业务处理节点间存在的当前通信过程外传递的通信消息传递时，第一业务处理节点在传递所述业务触发信息之前包括：通过携带协议关联信息的通信消息指明后续发送业务触发信息的协议以及发送业务触发信息的协议过程，与当前通信的关联方式；第二业务处理节点接收所述协议关联信息后包括：识别第一业务处理节点的协议关联信息并根据此信息将通信过程外传递的业务触发信息与当前通信进行关联。

其中，传输业务触发信息的协议如下协议中的至少一种：会话初始化协议SIP、通用用户档案协议GUP、Diameter协议、超文本传输协议HTTP、移动应用部分协议MAP、智能网应用规程协议INAP、CAMEL应用部分协议或内部协议。

其中，所述业务触发信息包括如下信息中的至少一个：

业务调用信息；业务过滤规则；业务调用结果；业务交互指示；服务状况信息。

其中，所述业务调用信息包括：业务标识，并可选地包括运营商标识、主被叫标记、业务互联方式、业务当前状态和附加业务信息。

其中，当一次呼叫中调用多种业务的时候，一条传递业务触发信息的通信消息中携带有多个业务对应的多条业务调用信息。

其中，所述业务过滤规则包括如下信息中的至少一个：业务点触发器SPT、服务器地址、规则操作动作指示、解配置标志、失败缺省处理、过滤规则名、过滤规则关联指示、业务调用消息指示、业务标识和同一业务的多条过滤规则的关联指示。

其中，所述服务器地址包括下列类型的地址中的至少一种：

下发业务过滤规则的业务控制点自身地址、非下发业务过滤规则的业务控制点的地址、对应业务触发点上的一段程序或脚本的虚拟服务器地址。

其中，所述业务调用结果包括如下信息中的至少一个：

业务调用成功的指示；业务调用失败的指示；业务调用处理结果。

其中，当所述业务交互指示为显式指示时，所述业务交互指示包括作用方业务标识和允许/禁止标志，并可选地包括指定方业务标识、指定方用户属性/标记、指定方业务属性/标记、指定方业务能力、作用方业务的主被叫标记。

其中，当所述业务交互指示为隐式指示时，所述业务交互指示包括指定方业务标识、指定方用户属性/标记和指定方业务属性/标记、指定方业务能力中的一个或者多个，并可选地包括作用方业务标识和/或作用方业务的主被叫标记。

其中，所述服务状况信息包括：服务状态数据和/或业务负荷数据。

其中，步骤B中还包括：所述第二业务处理节点还根据业务规则进行相应的业务处理控制，所述业务规则来自业务规则数据库和/或本地和/或所述业务触发信息。

其中，所述业务规则包括如下规则中的至少一种：

业务冲突禁止规则；业务交互处理规则；业务过滤规则；业务信令修正规则；业务分发规则。

其中，所述业务冲突禁止规则包括如下元素中的至少一个：

指定业务的标识；指定业务的主被叫方标记；与指定业务有冲突的业务标识；与指定业务有冲突的业务的主被叫方标记。

其中，所述业务交互处理规则包括如下元素中的至少一个：指定方业务标识；指定方用户属性/标记；指定方业务属性/标记；指定方业务能力；作用方的业务标识；允许/禁止标志。

其中，所述业务过滤规则中包括：业务标识。

其中，所述业务信令修正规则包括如下信息中的至少一个：

指定方业务标识；冲突方业务标识；指定方业务的主被叫标记；冲突方业务的主被叫标记；修正方向标记；信令修正方式。

其中，所述信令修正方式包括如下信息中的至少一种：

消息类型的转换；消息的屏蔽；消息头域、消息头域中的参数和/或消息体内容的转换、删除、修改或添加。

其中，所述业务分发规则包括：按顺序分发或按百分比分发。

其中，步骤B中，所述业务处理控制包括：业务控制点调用控制和/或业务流程控制。

其中，步骤B中，所述业务控制点调用控制包括如下方式中的至少一种：继续调用业务控制点、对已调用的业务控制点的信令关系的修正、阻止后续业务控制点的调用、业务控制点的初始调用选择控制。

其中，步骤B中，所述业务流程控制包括如下方式中的至少一种：业务控制点间协同完成业务处理流程；对已调用业务控制点的信令消息流程的修正。

本发明还提供了一种业务交互处理系统，其包括：

第一业务处理节点和第二业务处理节点；所述第一业务处理节点，用于根据当前业务执行情况，产生业务触发信息并将其发送给第二业务处理节点；所述第二业务处理节点根据所述业务触发信息进行相应的业务处理控制。

其中，所述第一业务处理节点设置在业务控制点、业务触发点或用户终端中；所述第二业务处理节点设置在业务控制点或业务触发点中。

其中，所述当前业务执行情况包括如下情况中的至少一种：

业务控制点接受了用户更新的业务数据、业务控制点接收到通信消息、业务触发点上业务触发成功、业务控制点的当前状态发生迁移和用户终端接受了业务请求。

其中，所述业务触发信息包括如下信息中的至少一个：

业务调用信息、业务过滤规则、业务调用结果、业务交互指示和服务状况信息。

其中，所述第一业务处理节点包括：业务触发信息产生单元、消息构造单元和业务触发信息传输单元；

所述业务触发信息产生单元，用于根据当前业务执行情况，产生业务触发信息；

所述消息构造单元，用于将产生的业务触发信息封装到通信消息的消息体或头域或参数中；

所述业务触发信息传输单元，用于通过所述通信消息将所述业务触发信息发送给所述第二业务处理节点。

其中，所述通信消息包括：

业务处理节点间存在的当前通信过程中传递的通信消息；或，

业务处理节点间存在的当前通信过程外传递的通信消息；或，

在业务处理节点间新建的通信过程传递的通信消息。

其中，当业务触发信息通过业务处理节点间存在的当前通信过程外传递的通信消息传递时，所述第一业务处理节点还包括：

关联方式指示单元，用于在传递所述业务触发信息之前，通过携带协议关联信息的通信消息指明后续发送业务触发信息的协议以及发送业务触发信息的协议过程，与当前通信的关联方式。

其中，所述第二业务处理节点包括：业务触发信息接收单元和业务处理控制单元；

所述业务触发信息接收单元，用于接收第一业务处理节点发送的业务触发信息；

所述业务处理控制单元，用于根据所述业务触发信息进行相应的业务处理控制。

其中，所述第二业务处理节点还包括：

业务规则获取单元，用于在接收通信消息时获取业务规则，所述业务规则来自业务规则数据库和/或本地和/或所述业务触发信息。

其中，所述业务规则包括如下规则中的至少一种：

业务冲突禁止规则；业务交互处理规则；业务过滤规则；业务信令修正规则；业务分发规则。

其中，所述业务处理控制单元还用于根据所述业务触发信息以及所获取的业务规则进行相应的业务处理控制。

其中，所述业务处理控制单元的业务处理控制包括：业务控制点调用控制和/或业务流程控制。

其中，所述业务控制点调用控制包括如下方式中的至少一种：继续调用业务控制点；对已调用的业务控制点的信令关系的修正；阻止后续业务控制点的调用；业务控制点的初始调用选择控制。

其中，所述业务流程控制包括如下方式中的至少一种：业务控制点间协同完成业务处理流程；对已调用业务控制点的信令消息流程的修正。

其中，当业务触发信息通过业务处理节点间存在的当前通信过程外传递的通信消息传递时，所述第二业务处理节点还包括：

关联单元，用于当接收到第一业务处理节点传送的通信消息后，根据其中携带的所述关联方式指示单元指明的所述关联方式识别第一业务处理节点的协议关联信息并根据此信息将通信过程外传递的业务触发信息与当前通信进行关联。

由上述本发明提供的技术方案可以看出，其通过第一处理节点发送业务触发消息给第二业务处理节点；所述第二业务处理节点根据所述业务触发消息进行相应的业务处理控制的技术，使业务交互问题能够在呼叫过程中被动态处理，也就是说，可以在呼叫过程中业务处理节点可以灵活控制业务的调用，并能对已经调用的业务做出调整。

附图说明

图1为背景技术中提供的IMS系统的业务架构图；

图2为本发明适用的分组网络的逻辑结构图；

图3为本发明提供的第一实施例的流程图；

图4为本发明提供的第一实施例中实现业务触发点根据业务调用信息以及预置的业务冲突禁止规则控制业务调用的流程图；

图5为本发明提供的第一实施例中实现业务控制点间使用业务调用信息进行互联，以协同完成流程处理的流程图；

图6为本发明提供的第一实施例中实现根据呼叫过程中获取的业务过滤规则进行后续的业务控制点调用的流程图；

图7为本发明提供的第二实施例的结构原理图。

具体实施方式

本发明适用的分组网络的逻辑结构图如图2所示，包括业务规则数据库、业务控制点和业务触发点。下面分别描述其功能。

一、业务规则数据库

所述业务规则数据库可以位于HSS中，也可以位于HSS的数据服务器中，用于保存用户的业务规则。

对于业务交互协调功能，业务规则数据库保存的业务规则包括至少一种如下数据：

1、业务过滤规则。描述设定的规则和业务控制点之间的关系，例如用户的iFC数据。

2、业务冲突禁止规则。

所述业务冲突禁止规则用于指明特定的业务间存在冲突，以便在业务冲突时禁止冲突的业务的调用。其包括至少一个如下信息：

指定业务的业务标识、指定业务的主被叫标记、与指定业务有冲突的业务标识和与指定业务有冲突的业务主被叫标记。

业务冲突禁止规则可以是被包含在业务过滤规则中，例如在业务过滤规则中描述与该过滤规则对应的业务有冲突的其它业务。

所述业务冲突禁止规则可以采用XML方式描述，例如：

<ServiceInteractionDescription>

    <Service>callForwardingUnconditional</Service>

    <Side>term</Side>

    <ConflictServiceDescription>

        <Side>term</Side>

        <TargetService>doNotDisturb</TargetService>

        <TargetService>callWaiting</TargetService>

    </ConflictServiceDescription>

</ServiceInteractionDescription>

上述采用XML方式描述的业务冲突规则表示被叫侧(term)的无条件呼叫前转业务(callForwardingUnconditional)与同样是被叫侧的免打扰业务(doNotDisturb)和呼叫等待业务(callWaiting)有冲突。

3、业务信令修正规则。

所述业务信令修正规则用于在业务触发点在收到引发业务处理冲突的特定的事件时根据所述业务信令修改规则对业务触发点和业务控制点间的信令关系和/或信令消息进行调整/修正。例如对业务控制点下发的引发业务处理冲突的参数进行删除处理等。

所述业务信令修正规则包括至少一个如下信息：

指定方业务标识、冲突方业务的标识、指定方业务的主被叫标记、冲突方业务的主被叫标记、修正方向标记和信令修正方式。

其中修正方向标记用于控制修正规则作用于业务触发点接收的指定方业务控制点发送的消息还是业务触发点发给冲突方业务控制点的消息。

其中所述信令修正方式包括如下方式中的至少一个：消息类型的转换；消息的屏蔽；消息头域、参数和/或消息体内容的转换、删除、修改或添加。

所述的信令修正方式主要用于对业务控制点发往业务触发点的消息进行修正，和/或，对业务触发点将发往业务控制点的消息进行修正。

所述业务信令修正规则中的指定方业务标识、冲突方业务的标识、指定方业务的主被叫标记、冲突方业务的主被叫标记为信令修正的条件，修正方向标记、信令修正方式为具体的信令修正实施方法。上述业务信令修正规则中的条件可以不同时出现，例如信令修正规则中可以只出现指定方业务标识、修正方向标记以及信令修正方式，其中修正方向标记用于指示修正业务触发点接收到的指定方业务控制点发送的消息，此时对所述业务控制点发送的消息均进行修正而不管是否有其它的业务应用；当信令修正规则中同时出现指定方业务标识和冲突方业务的标识时，则表示当同时使用了这两种业务标识对应的业务后才进行信令的修正，例如智能业务MAS单独使用的时候不需要进行信令修正，但当201业务和MAS业务被同时调用时，则需要修正MAS业务下发的RELEASECALL(呼叫释放)指令，以向201业务上报智能DP(检测点)事件，如DP9b，这种情况下就可以设置指定方业务标识为MAS的业务标识，冲突方业务标识为201的业务标识，以表示在同时应用了这两种业务的情况下才需要进行信令修正。

4、业务交互处理规则。

所述业务交互处理规则用于指明在特殊的呼叫中特定的业务是否允许调用，所述特殊的呼叫包括调用了特定的业务、呼叫中用户属性/标记是特殊的、呼叫中的业务属性/标记是特殊的、呼叫中的业务能力是特殊的。与业务冲突禁止规则不同，在应用业务交互处理规则前，当前通信可以没有调用其它的业务，例如话务员用户呼叫可以突破被叫的免打扰业务；另外业务冲突禁止规则只用于禁止业务触发，业务交互处理规则也可用于允许特定业务的触发。概括来说业务交互处理规则可应用于特殊的情况，它的优先级比业务冲突禁止规则要高。

所述业务交互处理规则包括至少一个如下信息：

指定方业务标识、指定方用户属性/标记、指定方业务属性/标记、指定方业务能力、作用方业务标识和允许/禁止标志。

5、业务分发规则。

所述业务分发规则用于对同质业务控制点(能提供相同业务的业务控制点)的调用消息的分发方式进行描述，包括至少一个如下分发规则：按顺序分发和按百分比分发。

上述不同的业务规则可以位于一个网元中，也可以位于不同的网元，即可以有多个业务规则数据库存在。此外，所有不同的业务规则可以统一在一种业务规则(如业务过滤规则)中，也可以是其中的若干种统一在一种业务规则中，或者每种业务规则是单独的业务规则。

二、业务控制点

业务控制点用于提供业务。一个业务控制点可以提供一个或者多个业务。业务控制点可以是SIP AS、OSA SCS、IM-SSF、业务控制功能(SCF，ServiceControl Function)实体、OSA应用服务器、软交换机等。业务控制点中也可以内置SCIM功能。本发明中业务控制点可以具备如下功能：

1、根据业务调用信息以及预置的业务冲突禁止规则判断后续业务是否允许被调用；

2、业务控制点间可以根据业务调用信息互联，以协同完成业务处理流程；

3、根据业务交互指示消息中的显式业务禁止/允许的指示，进行后续的业务调用控制，或者，当所述业务交互指示中携带的信息为隐式时，依据所述业务交互指示以及预置的业务交互处理规则，进行后续的业务调用控制。

三、业务触发点

所述业务触发点用于提供与业务控制点交互的能力，根据业务过滤规则，决定当前处理的通信是否需要触发到特定的业务控制点。其可以是S-CSCF，也可以是业务代理(Service Broker)。业务触发点中可以内置SCIM功能。本发明中业务触发点还具备如下功能中的至少一种：

1、根据业务调用信息以及预置的业务冲突禁止规则，判断后续业务是否允许被调用；

2、根据业务调用信息以及预置的业务信令修正规则，对业务触发点和业务控制点间的信令消息做出修正；

3、根据当前业务调用结果以及业务过滤规则，进行后续的业务控制点调用；

4、根据业务交互指示消息中的作用方业务标识和业务禁止/允许指示或者依据业务交互处理规则和业务交互指示中的指示方信息(如用户属性/标识等)，进行后续的业务调用控制；

5、根据服务状况信息以及预置业务分发规则，进行后续的业务控制点调用。

上述业务触发点与所述业务规则数据库之间存在E1接口，该接口可以采用但不限于SIP协议、Diameter协议、通用用户档案(GUP，Generic User Profile)协议、超文本传输协议(HTTP，Hyper Text Transport Protocol)以及移动应用部分(MAP，Mobile Application Part)协议、内部接口协议等。所述业务触发点可以通过E1接口从业务规则数据库获得业务规则。

业务触发点和业务规则数据库间可以存在其它中间网元，例如通用用户档案服务器(GUP Server)，即E1接口可以是直接接口也可以是间接接口。

业务触发点与业务控制点存在E2接口，该接口协议可以采用但不限于SIP、智能网应用规程(INAP，Intelligent Network Application Protocol)、CAMEL应用部分(CAP，CAMEL Application Part)协议、MAP协议、Diameter协议、HTTP协议等，业务触发点和业务控制点间也可以是内部接口，例如当业务触发点同时具备业务提供功能时。

业务触发点除了可以从业务规则数据库获得业务规则，也可以从业务控制点获得业务规则，业务控制点可以根据当前业务执行情况，例如收到了一条业务触发点发来的消息，通过所述E2接口向业务触发点下发业务规则。

业务控制点与业务规则数据库之间存在E3接口，该接口可以采用但不限于如下协议：

SIP协议、Diameter协议、GUP协议、HTTP协议、MAP协议、内部接口协议等。

所述业务控制点可以从业务规则数据库获取业务规则；当其本地设置有业务规则也可以在本地获取(即业务规则数据库位于业务控制点中)；业务控制点还可以在业务执行过程中生成业务规则。在业务控制点生成业务规则时，例如接受了用户更新的业务数据从而更新了业务过滤规则，通过E3接口向业务规则数据库同步更新所述业务规则。

业务控制点和业务规则数据库间可以存在其它中间网元，例如通用用户档案服务器(GUP Server)，即E3接口可以是直接接口也可以是间接接口。

基于上述分组网络的逻辑结构，本发明提供了第一实施例，其是一种业务交互处理方法，其核心是：第一业务处理节点根据当前业务执行情况，向第二业务处理节点发送业务触发信息；接收到业务触发信息的第二业务处理节点根据所述业务触发信息进行相应的业务调用控制和/或业务流程控制等。其具体实施过程如图3所示，包括如下步骤：

步骤S101，第一业务处理节点根据当前业务执行情况，产生业务触发信息并将其发送给第二业务处理节点；以及，第二业务处理节点获取业务规则。

所述第一业务处理节点可以是分组网络中的如下实体类型之一：业务触发点、业务控制点、用户终端。所述第二业务处理节点可以是分组网络中的如下实体类型之一：业务触发点、业务控制点。第一业务处理节点也可以和第二业务处理节点是同一个实体，例如均为业务触发点。

下面先针对步骤S101中第二业务处理节点获取业务规则的过程进行描述，具体如下：

当第二业务处理节点是业务触发点时，所述业务触发点在接收通信消息时，可以从业务规则数据库获得业务规则；当其本地设置有业务规则也可以在本地获取；也可以从业务控制点处获得业务规则，如从业务控制点下发给业务触发点的业务触发信息中获取。

当第二业务处理节点是业务控制点时，所述业务控制点在接收通信消息时，可以从业务规则数据库获取业务规则；当其本地设置有业务规则也可以在本地获取。

接下来针对步骤S101中第一业务处理节点根据当前业务执行情况，产生业务触发信息并将其发送给第二业务处理节点的过程进行描述，具体如下：

所述当前业务执行情况包括如下几种情况中的至少一种：

1、业务控制点接受了用户更新的业务数据；

2、业务控制点接收到一个通信消息，如SIP消息；

3、业务触发点上业务触发成功；

4、业务控制点当前状态发生迁移，所述状态是业务控制点自身状态或所处理业务的状态。

5、用户终端接受了一个业务请求，所述业务请求包括用户或网络的业务调用请求和/或业务控制请求，如用户调用终端上的业务。

所述业务触发信息包括如下几种业务触发信息中的至少一个：

1、业务调用信息。

所述业务调用信息是指已经被调用业务的相关信息，包括至少一种如下信息：

业务标识、运营商标识、主被叫标记、业务互联方式、业务当前状态、附加业务信息。

当一次呼叫中调用多种业务的时候，一条传递业务触发信息的消息中可以携带有多个业务对应的多条业务调用信息。

所述业务标识是业务调用信息中的必选信息，它用于标识被调用的业务。

所述业务标识在运营商网络内是唯一分配的，它可以标识运营商网络内的业务，且业务标识在同一个运营商网络内不会冲突。

所述业务标识可以是一个字符串也可以是一个数值，例如免费电话业务标识可以是freePhone，也可以是800。业务标识也可以采用公共服务身份(PSI，Public Service Identity)表示。业务标识也可以是3GPP TR 23.816中定义的IMS通信业务标识(IMS communication service identifier)。

当业务标识通过显式方式携带时，所述业务标识可以通过业务触发点填充，也可以通过业务控制点填充，也可以通过用户终端填充。当业务标识通过业务控制点填充时，业务控制点可以通过内置SCIM功能填充业务调用历史信息中的数据，如业务标识等。当业务标识通过用户终端填充时，业务标识可以通过Request-URI(请求统一资源标识)携带。

当业务标识通过隐式方式携带时，在消息中不明确指示出业务标识，但通过消息中的头域、参数、消息体等，接收到消息的实体可以根据业务标识识别规则将所述业务标识识别出来。例如被叫侧应用呼叫等待业务，被叫侧在SIP消息180Ring中携带P-Service-Indication：waiting，接收到所述SIP消息的实体通过此头域取值查找对应的业务识别规则，可识别出被叫侧应用了呼叫等待业务。具体识别方式如采用基于消息匹配规则的业务识别方式，对上面的例子，业务标识识别规则可采用如下形式描述：

        <Condition>

                <SIPHeader>

                    <Header>P-Service-Indication</Header>

                    <Content>waiting</Content>

            </SIPHeader>

        </Condition>

        <ServiceInfo>

            <ServiceIdentifier>callWaiting</ServiceIdentifier>

        </ServiceInfo>

上述描述的业务标识识别规则给出了用于识别业务标识的信息，根据所述信息，识别实体可以识别出对应的业务标识，然后使用所述业务标识来统一进行业务交互处理。

所述运营商标识用于标识运营商网络，不同的运营商网络对应的运营商标识是不同的，它是一个全局唯一的标识，运营商标识的表示形式可以采用，但不限于如homel.net一类的形式。运营商标识可以通过业务触发点填充，也可以通过业务控制点填充，也可以通过用户终端填充。

业务触发点可以通过但不限于采用比较域名的方式判断一次消息是否出本运营商网络，当呼叫出本运营商网络的时候，业务触发点添加运营商标识。当消息在同一个运营商网络内的业务触发点、业务控制点间传递时，不需要携带运营商标识。

所述主被叫标记用于区分所标识的业务是在主叫侧还是在被叫侧被调用。使用主被叫标记是因为某些业务可以是主叫侧业务也可以是被叫侧业务，这类业务在主叫侧被调用与在被叫侧被调用时相比，表现的业务特征不同，例如号码携带业务。

主被叫标记可以通过业务控制点添加，也可以通过业务触发点添加，也可以通过用户终端添加。对于业务控制点主动发起的呼叫可以使用主叫侧的标记。当接收的消息中没有主被叫标记时，业务触发点可以根据业务触发的用户方在触发业务的呼叫中是主叫还是被叫的信息，添加所述标记；当然业务触发点也可以不做添加的处理，即不需要区分调用的业务是主叫侧业务还是被叫侧业务。

所述业务互联方式用于描述业务控制点所支持的业务互联方式，它可以描述业务控制点支持的所有类型的业务互联方式，每一种业务互联方式描述包含如下元素中的至少一个：互联协议类型、互联协议版本号、业务地址、业务逻辑实例ID。其可以以列表的形式存在。

业务控制点间互联的协议类型可以采用但不限于HTTP、Diameter、SIP、MAP、TCAP、INAP、CAP等。

所述互联协议版本号用于指示互联协议的协议版本信息。

所述业务地址用于标识提供业务的业务控制点的地址信息。所述业务地址可以是统一资源定位符(URL，Universal Resource Locator)，也可以是IP地址和端口号，也可以是全局码(GT，Global Title)地址，也可以是目的点码(DPC，Destination Point Code)。所述业务地址也可以是DPC和子系统号(SSN，Sub-System Number)，也可以是GT和SSN。所述业务地址是可选信息，可以由业务控制点填充，也可以由业务触发点填充。

所述业务逻辑实例ID用于标识提供业务的业务控制点的特定业务逻辑实例的内部索引ID，例如业务逻辑实例ID可以是业务控制点上该业务通信的状态机编号，它可用于在业务控制点互联交互的时候使用所述业务逻辑实例ID定位业务控制点上该业务通信对应的处理逻辑实例。业务逻辑实例ID是可选信息，由业务控制点填充。

所述业务当前状态用于标识业务当前处理状态，业务当前状态是可选信息，由业务控制点填充。

所述附加业务信息用于携带该业务相关的附加描述信息，例如信用卡呼叫中的第三方付费标志、付费的第三方用户标识、已经激活的业务特征等。

业务触发点接收业务控制点发送的业务调用信息后，可以将其传递给其它业务控制点，具体的传递方式可以是：转发、存储后再转发。转发的方式例如业务触发点接收用户初始通信请求，触发到一个业务控制点上，业务控制点发送的消息经过业务触发点，业务触发点将其路由到其它业务控制点；转发方式的另外一种情况是业务控制点更新业务调用信息，例如更新业务调用信息中的业务状态，业务触发点将其转发到其它业务控制点，具体的转发处理可以采用如根据业务过滤规则等方式进行。存储后再转发的方式例如业务触发点收到业务控制点发送的业务调用信息后将其存储下来，后续在初次触发其它业务控制点时，在触发消息中携带保存下来的已调用业务的业务调用信息。

2、业务过滤规则。

所述业务过滤规则包括对业务控制点自身的调用规则和/或对其它业务控制点的调用规则。

业务过滤规则中包括如下信息中的至少一个：SPT、服务器地址、规则操作动作指示、解配置标志、失败缺省处理、过滤规则名、过滤规则关联方式、业务调用消息、业务标识、同一业务的多条过滤规则的关联指示。

业务过滤规则中一般携带SPT和服务器地址中的至少一个。业务过滤规则中可以没有任何SPT描述，此时业务控制点在业务过滤规则中可以只携带服务器地址以表示无条件触发到业务控制点。业务过滤规则中也可以不携带SPT或者服务器地址信息，例如业务控制点进行业务过滤规则的管理维护操作，此时可以只携带过滤规则名、解配置标志或者规则操作动作指示。

所述SPT包括至少一个如下类型的SPT：SIP消息中请求统一资源标识、SIP消息名称、SIP消息头、会话情形、SIP消息消息体、会话状态、用户状态、时间、用户呈现信息、业务标识、过滤规则关联指示。与iFC类似，业务过滤规则可以支持SPT的逻辑运算，可以支持SPT的组合，可以支持结合范式以及非结合范式表述。

所述服务器地址，包括接收消息的业务控制点的SIP地址和/或业务触发点的本地虚拟服务器地址。所述的本地虚拟服务器地址可以对应业务触发点上的一段程序或者脚本，即所述服务器地址包括业务控制点自身的服务器地址和/或其它业务控制点的服务器地址和/或业务触发点上的虚拟服务器地址。

业务控制点在业务过滤规则中可以不指明服务器地址，也可以明确指示服务器地址。当业务控制点在业务过滤规则中不指明服务器地址时，业务触发点默认服务器地址为下发该业务过滤规则的业务控制点的地址。当业务控制点在业务过滤规则中明确指示接收消息的服务器地址时，所述服务器地址还可以是其它业务控制点的地址和/或业务触发点上的虚拟服务器地址。例如门户业务服务器下发业务过滤规则，其中在下发的业务过滤规则中指示过滤规则被满足时业务触发点将消息发往提供子业务的服务器，而不是发往门户业务服务器。

对于业务控制点指示的业务过滤规则中服务器地址是其它业务控制点的地址情况，如果业务触发点在当前通信中没有创建与所述其它业务控制点的对话，则在收到第一个引发到所述其它业务控制点的消息时，业务触发点可以通过发往该业务控制点的消息创建对话，例如业务触发点向该业务控制点发送INVITE消息。

所述规则操作动作指示用来指明在第二业务处理节点上，如业务触发点上的规则操作动作指示，以便用来管理业务过滤规则。其包括至少一个如下的指示：

更新一条规则、添加一条规则、删除一条规则、覆盖所有规则。

在业务过滤规则的描述中，通过添加规则操作动作指示的方式指明在业务触发点上的规则操作动作指示，例如增加一种ActionInd单元值，当所述单元值取值为0时，表示覆盖该业务中所有到本业务控制点的规则；当所述单元值取值为1时，表示添加一条规则；当所述单元值取值为2时，表示更新一条规则；当所述单元值取值为3时，表示删除一条规则。

所述规则操作动作指示可以通过第一业务处理节点，如业务控制点下发给第二业务处理节点，如业务触发点；也可以不通过第一业务处理节点下发，而是通过第二业务处理节点提供默认规则操作动作指示，例如收到不带规则操作动作指示的业务过滤规则时默认为覆盖所有以前保存的业务过滤规则。

所述解配置标志用来指明一条过滤规则是被执行一次后失效还是一直有效或者无效，或者通信结束后失效，以便用来管理业务过滤规则。例如通过在业务过滤规则中的描述中增加一种DisarmFlag单元来实现，如当其取值为0时表示所对应的规则匹配被执行一次后失效；当其取值为1时表示所对应的业务过滤规则一直有效，直到业务控制点主动将该规则失效或者使用管理手段将其失效，例如管理员失效或者删除该规则；当其取值为2时表示所对应的规则失效，业务控制点可以在当前通信中失效一条业务过滤规则，也可以在当前通信外失效一条业务过滤规则，例如当用户通过3GPP定义的Ut接口去激活无条件通信前转(CFU，Communication Forwarding Unconditional)业务时，业务控制点将一条业务过滤规则失效；当其取值为3时表示所对应的规则在当前通信中有效，直到业务控制点在当前通信中主动将该条规则失效或当前通信释放。

所述解配置标志可以通过第一业务处理节点，如业务控制点下发给第二业务处理节点，如业务触发点；也可以不通过第一业务处理节点下发，而是通过第二业务处理节点提供默认的解配置处理，例如收到不携带解配置标志的业务过滤规则时，默认为所述不携带解配置标志的业务过滤规则是一直有效。

上述业务过滤规则的管理操作可以通过解配置标志失效一条业务过滤规则，或者通过规则操作动作指示删除一条业务过滤规则，可以根据业务过滤规则名来定位业务触发点或者业务规则数据库中要管理的一条业务过滤规则。

所述失败缺省处理用来指明业务触发点调用业务控制点失败情况的失败缺省处理情况。它可以取值继续处理其它业务过滤规则、通信释放、重新调用业务控制点、调用同质业务控制点、停止执行业务过滤规则。其中，“继续处理其它业务过滤规则”表示忽略当前调用失败，如果有其它的业务过滤规则，则接着执行其它的业务过滤规则；“通信释放”表示释放当前通信；“重新调用业务控制点”表示对当前调用失败的业务控制点重新调用一次；“调用同质业务控制点”表示调用能提供和当前调用失败的业务控制点相同服务的业务控制点(即同质业务控制点)，如AS1调用失败，AS2能提供和AS1相同服务，则业务触发点调用AS2，AS2的地址可以和AS1的一起配置在业务过滤规则中；“停止执行业务过滤规则”表示忽略当前调用失败，如果有后续的业务过滤规则，则停止执行后续所有的业务过滤规则。

所述过滤规则名用来标识一条过滤规则。同一个业务控制点下发的多个业务过滤规则可以共用同一个过滤规则名，也可以每条业务过滤规则单独使用一条过滤规则名。过滤规则名可以由业务控制点分配，并填充到下发的业务过滤规则中；也可以由业务触发点分配，并在接收业务控制点下发的业务过滤规则后在响应消息中携带过滤规则名，业务控制点接收该响应消息后可以在后续下发的业务过滤规则中携带业务触发点分配的过滤规则名。

所述过滤规则关联指示用来通过过滤规则名在过滤规则间建立关联关系。所述关联关系包括指定的过滤规则执行成功后的关联关系以及执行失败后的关联关系。当指定的过滤规则执行成功或者失败后，可以通过所述关联关系获取到所指定的过滤规则关联的过滤规则，并执行。如前所述的过滤规则关联指示也可以位于SPT描述中，此时它可以表示相关过滤规则的执行结果为业务触发条件。

所述业务调用消息指示业务过滤规则条件匹配后对特定服务器地址的调用消息。

所述业务标识用于表示业务过滤规则对应的业务。业务控制点下发的业务过滤规则中如果一条业务过滤规则携带了业务标识而其它业务过滤规则没有携带业务标识，可以默认为所下发的业务过滤规则使用同样的业务标识。

所述同一业务的多条过滤规则关联指示用于关联同一个业务对应的多条业务过滤规则，以在触发多个业务过滤规则时将消息在同一个业务对话中发给业务控制点。同一业务的多条过滤规则的关联指示至少包括：业务过滤规则名、业务标识、过滤规则的业务索引和业务控制点的服务器地址。当业务控制点只提供一个业务的时候，同一业务的多条过滤规则的关联指示也可以只包括业务控制点的服务器地址。

上述关联指示中过滤规则的业务索引在运营商网络内可以不是唯一分配的，但同一个服务器地址对应的业务控制点提供的不同业务对应的过滤规则的业务索引必须唯一，同一个业务对应的业务过滤规则的业务索引必须相同。当使用业务过滤规则名或者业务标识来关联同一个业务的多个业务过滤规则时，同一业务的多条过滤规则的关联指示元素与过滤规则中的其它元素是统一的。

上述同一业务的多条过滤规则的关联指示的使用方式由多种，例如：

通过业务过滤规则名进行关联时，至同一业务控制点的多条业务过滤规则具有相同的业务过滤规则名，所述多条业务过滤规则既可以组合为一个整体的业务过滤规则，并共用同一个业务过滤规则名；也可以是多条业务过滤规则分散存储，每条业务过滤规则都独立使用业务过滤规则名，但同一业务的多条过滤规则的业务过滤规则名取值相同。业务触发点可以在本地控制块中保存业务过滤规则名和对话的关联关系，以保证同样的业务过滤规则名可以关联到同一个对话中；

通过业务过滤规则中的业务标识进行关联时，至同一业务控制点的多条业务过滤规则的业务过滤规则名可以不相同，但业务标识是相同的，业务触发点可以在本地控制块中保存业务标识和对话的关联关系，以保证同样的业务过滤规则名可以关联到同一个对话中；

通过业务过滤规则中过滤规则的业务索引或者进一步根据业务过滤规则中的服务器地址进行关联时，业务触发点可以在本地控制块中保存过滤规则的业务索引或者保存过滤规则的业务索引和服务器地址和对话的关联关系，以保证同样的业务过滤规则名可以关联到同一个对话中。

3、业务调用结果。

所述业务调用结果包括业务调用成功的指示、业务调用失败的指示、业务调用处理结果等。所述业务调用成功的指示、业务调用失败的指示用于在一个业务控制点被调用后返回的业务调用结果中表明业务调用的成功或失败。所述业务调用处理结果为业务控制点对业务调用进行处理并通过消息返回的结果，例如业务触发点向业务控制点发送INVITE消息请求用户的当前日程安排状态，业务控制点在返回的200OK消息中携带用户日程安排为空闲的指示。

4、业务交互指示。

业务交互指示用于指示相关业务调用是否允许或禁止。它分为显式业务交互指示与隐式业务交互指示，前者在消息中明确指示指定的业务是否允许或者禁止调用，后者则不在消息中明确指示指定的业务是否允许或者禁止调用。业务交互指示包括至少一个如下信息：

指定方业务标识、指定方用户属性/标记、指定方业务属性/标记、指定方业务能力、作用方业务标识、作用方业务的主被叫标记、允许/禁止标志。

其中，所述指定方业务标识用于标识发送业务交互指示的业务，在一条业务交互指示中只有一个指定方业务标识。业务交互指示也可以不携带指定方业务标识，例如紧急呼叫的业务交互指示可以只携带指定方用户属性/标记。

所述指定方用户属性/标记用于标识用户的属性或者身份，例如紧急呼叫的紧急用户标记user@emergency.chinatele.com，或者话务员呼叫的话务员用户属性都是一种指定方用户属性/标记，它们可以用于隐式指示与其它业务的交互关系，例如话务员发起的呼叫或紧急用户接收的紧急呼叫可以隐式指示突破被叫的免打扰业务。

所述指定方业务属性/标记用于标识业务的属性，例如紧急呼叫标记，指定方业务属性/标记中可以包括业务地址。

所述指定方业务能力用于指示用户具备或者不具备的业务应用能力(例如因为激活免打扰业务导致的不具备受话的能力)，它可以指示发送消息时因已经调用了特定业务所具备或不具备的业务能力，也可以指示发送消息时因没有被调用但已经签约或者激活的业务所具备或者不具备的业务能力。例如用户有免打扰或者缺席业务，在所述用户发起通信请求的时候可以在消息中携带业务能力指示，指示用户不能受话，如果被叫用户有回叫类业务，此时可以根据此业务能力指示禁止被叫侧回叫业务的调用。

所述作用方业务标识用于标识当前指示要作用的业务，一条业务交互指示中可以有多个作用方业务标识。当使用隐式业务交互指示时，业务交互指示中可以不携带作用方业务标识。

所述作用方业务的主被叫标记用于标识与指定方业务标识代表的业务有交互关系的业务是应用于主叫侧还是被叫侧，一条业务交互指示中可以有多个作用方业务的主被叫标记。作用方主被叫标记不是必须的，当没有此标记时，业务触发点和/或业务控制点默认为所标识的业务与本实体在当前呼叫中的位置在同一侧。

所述允许/禁止标志表示是否允许指示的作用方业务被调用。当使用隐式业务交互指示时，可以不携带该标志。

5、服务状况信息。

服务状况信息用于描述第一业务处理节点当前的状态信息，包括服务状态数据、业务负荷数据等服务状况信息，所述服务状态如业务控制点的激活状态、业务的激活状态等，所述业务负荷数据如业务控制点的调用次数、CPU占用率等。

上述业务触发信息可以是通过第一业务处理节点直接发送给第二业务处理节点，也可以是通过第一业务处理节点间接发送给第二业务处理节点，也就是说，通过中间节点转发所述业务触发信息给所述第二业务处理节点，如业务控制点向业务规则数据库发送业务过滤规则，业务规则数据库再向业务触发点发送该过滤规则。

传递业务触发信息的协议可以采用SIP协议、INAP协议、CAP协议、MAP协议、Diameter协议、GUP协议、HTTP协议或内部接口协议，但不限于上述协议。

业务触发信息可以放在上述协议消息的消息体中携带，也可以扩展一个单独的头域，并使用所述头域中的不同参数携带；也可以使用上述协议消息原有的头域中的参数携带；也可以扩展上述协议消息中新的参数携带；对于内部接口协议也可以采用内部数据结构或消息携带。

业务触发信息可以在不同业务处理节点间存在的当前通信中传递，也可以在当前通信外传递，或者是，当不同业务处理节点间本不存在通信时通过一个新建的通信传递。

当业务触发信息在不同业务处理节点间存在的当前通信外传递时，其中第一业务处理节点可以在发送业务触发信息前通过携带协议关联信息的消息，如SIP消息，指明后续发送业务触发信息的协议以及发送业务触发信息的协议过程，与当前SIP通信的关联方式。相应的，第二业务处理节点收到上述SIP消息时，识别出SIP消息中携带的协议指示与关联信息，并当其收到第一业务处理节点携带业务触发信息的消息时，根据所识别出的协议指示与关联信息将所收到的业务触发信息的消息和当前第一业务处理节点的通信进行关联。

其中，所述携带有协议指示与关联信息的SIP消息可以采用Info消息、Publish消息等，但不限于上述消息。例如当业务控制点采用Diameter协议直接向业务触发点下发业务触发信息时，业务控制点可以先在发往业务触发点的SIP消息中指示下发业务触发信息的协议类型为Diameter协议，以及下发业务触发信息的Diameter消息中的会话ID(Session-Id)。此后业务控制点使用Diameter协议以及上述消息中的Session-Id下发业务触发信息。

步骤S102，根据所述业务触发信息进行相应的业务处理控制，或者，根据所述业务触发信息以及业务规则进行相应的业务处理控制。所述业务处理控制包括业务控制点调用控制和/或业务流程控制等。其中，业务控制点调用控制包括继续调用业务控制点(包括已经调用的业务控制点和/或未调用的业务控制点)、对已调用的业务控制点的信令关系的修正(如中止信令连接)、阻止后续业务控制点的调用、业务控制点的初始调用选择控制等。业务流程控制包括业务控制点间协同完成业务处理流程、对已调用业务控制点的信令消息流程的修正等。

具体实现过程分如下几种情况进行举例说明：

第一种情况：业务触发信息为业务调用信息时，业务触发点和/或业务控制点可以根据业务调用信息以及业务冲突禁止规则判断即将调用的后续业务是否允许被调用，如当判断出业务调用信息中指示的已调用的业务和即将调用的业务存在冲突时禁止调用所述后续业务。

这种情况以业务触发点收到Invite消息后触发业务，业务控制点向业务触发点发送业务调用信息，业务触发点根据业务调用信息以及预置的业务冲突禁止规则控制业务调用为例进行说明，具体实施过程如图4所示，包括如下步骤：

步骤1，业务触发点收到一个Invite消息，该Invite消息可以来自用户终端。

步骤2，业务触发点根据业务过滤规则触发业务A到业务控制点1。

步骤3，业务调用成功，业务控制点1通过200 OK确认消息将业务调用信息传递给业务触发点。

业务调用信息可以通过扩展新的参数携带，也可以采用协议扩展头域或者消息体的方式携带。例如，当业务调用信息采用SIP协议扩展头域的方式携带时，实施过程如下：

INVITE sip:bob@home.net SIP/2.0

P-Service-History:service-id＝prepaid；operator＝home1.net；call-side＝orig；

service-addr＝prepaid@home1.net；service-instance＝234151D0FCE11；

service-state＝state12

P-Service-History:service-id＝outgoingCallScreen；operator＝home1.net；

call-side＝orig；

 ......

上述语言表示主叫侧(orig)已经调用了两个业务，一个是预付费(prepaid)业务，另外一个是去话筛选(outgoingCallScreen)业务，所述两个业务都是运营商网络home1.net内的业务。其中，所述预付费业务的业务控制点地址为prepaid@home1.net，业务控制点的处理逻辑实例为234151D0FCE11，业务控制点的当前处理状态为state12。

步骤4，业务触发点根据所述业务调用信息和预置的业务冲突禁止规则，判断后续业务过滤规则对业务控制点2的业务B的调用是否与业务A冲突。

业务触发点根据呼叫中传递的业务调用信息和/或本地得到的业务调用信息(如业务过滤规则中包含业务标识)以及获取的业务冲突禁止规则，判断已经调用的业务和即将调用的业务是否存在冲突。具体实施方式如下：

判断业务调用信息中指示的已经调用的业务对应的业务标识和/或主被叫标记，以及业务触发点获得的即将调用的业务对应的业务标识和/或主被叫标记是否同时落于业务冲突禁止规则中指示的禁止此业务的调用的信息内，若同时落于，则认为两个业务冲突，则禁止调用新的业务；否则，认为两个业务不冲突。

步骤5，如果两个业务不冲突，则业务触发点向业务控制点发送Invite消息。当业务A和业务B冲突的时候业务触发点不会调用步骤5。

上述仅仅以业务触发点收到Invite消息后触发业务，业务控制点向业务触发点发送业务调用信息，业务触发点根据业务调用信息以及预置的业务冲突禁止规则控制业务调用为例进行说明，实际应用可以不限于此，例如，两个业务触发点间，或两个业务控制点间也可以传递业务调用信息，并根据所述业务调度信息以及预置的业务冲突禁止规则进行业务处理控制等。本实施例中的说明用例的处理对应业务控制点调用控制中的阻止后续业务控制点的调用的处理。

第二种情况：业务触发信息为业务调用信息时，业务控制点可以根据业务调用信息协同完成自身的业务处理流程。

比如，前面已经提到业务调用信息中包括业务地址和业务逻辑实例ID，其中所述业务逻辑实例ID用于标识提供业务的业务控制点的对应该呼叫的内部处理ID。业务控制点间可以使用这些信息进行互联，并协同完成流程处理。具体实施过程以如图5所示的例子进行说明，包括如下步骤：

步骤1，业务触发点收到一个Invite消息，该Invite消息可以来自用户终端。

步骤2，业务触发点根据业务过滤规则触发业务A到业务控制点1。

步骤3，业务调用成功，业务控制点1通过200OK确认消息将业务调用信息1传递给业务触发点，其中携带有业务控制点1支持的业务互联方式，包括业务控制点1的地址与本次通信对应的业务逻辑实例ID以及支持的互联协议类型为SIP。

步骤4，业务触发点根据业务过滤规则触发业务B到业务控制点2。

步骤5，业务调用成功，业务控制点2通过200OK确认消息将业务调用信息2传递给业务触发点。

步骤6，业务控制点2根据业务调用信息中的业务互联方式得知业务A的存在，且业务B和业务A需要协同工作，例如业务B需要取业务A中的业务数据，此时业务控制点2发送Invite消息到业务控制点1，并将业务逻辑实例ID通过Invite消息带给业务控制点1，以让业务控制点1找到正确的处理逻辑实例。

本实施例中的说明用例的处理对应业务流程控制中的业务控制点间协同完成业务处理流程的处理。

第三种情况：当业务触发信息为业务调用信息时，业务触发点可以根据业务调用信息以及业务信令修正规则对业务触发点和业务控制点间的信令关系和/或信令消息做出调整/修正，包括对业务控制点发往业务触发点的消息和/或对业务触发点将发往业务控制点的消息进行修正。

信令修正处理的过程可以在业务触发点接收消息或者发送消息或者收到内部事件(例如业务触发点上无应答定时器超时)的时候被激活。例如，被叫先触发了一种可以播放主叫身份信息的来话筛选业务，该业务在收到应答信号后可以向被叫播放主叫身份信息；在收到来话后，如果被叫用户没有应答，其后触发无应答时转语音邮箱业务，这个时候如果业务触发点不进行特殊处理，来话筛选业务认为应答的是真实的被叫，从而播放主叫身份信息的语音提示，语音邮箱中录下的是来话筛选业务播放的主叫身份信息的语音提示而没有录下主叫留言。此时可采用信令消息修正技术，业务触发点收到无应答事件，根据已经调用的来话筛选业务信息以及信令修正规则，向来话筛选业务发送结束对话的消息，即修正业务触发点和提供来话筛选业务的业务控制点之间的信令关系。此例子即对应业务控制点调用控制中的对已调用的业务控制点的信令关系的修正的处理。

信令修正处理也可以修正业务触发点和业务控制点间的信令消息，信令消息修正方式包括：消息类型的转换；消息的屏蔽；消息头域、参数和/或消息体内容的转换、删除、修改或添加。例如用户能够使用通用个人通信(UPT)业务，其中UPT业务在该用户做被叫且当被叫无应答时可以逐个呼叫不同的被叫用户终端，如所述UPT业务最多可以呼叫三个不同的被叫终端，每个终端最多振铃20秒，即主叫最多听60秒回铃音。同时该用户使用的这多个用户终端中有一个申请了彩铃业务。UPT业务和彩铃业务都是智能业务且在呼叫中都会配置上报的事件检测点(EDP)，并在EDP配置请求消息中设置无应答时长，但UPT业务配置的无应答时长为20秒，而彩铃业务配置的无应答时长为55秒，呼叫中同时触发这两种业务的话，由于彩铃业务后触发，它的EDP配置将覆盖UPT业务的EDP配置，如果不做任何处理的话，主叫用户听回铃音的时长将超过60秒，从而影响了UPT业务的业务特性的实现。对于这个例子可以应用信令修正处理，如业务触发点可以根据已经调用的UPT业务和彩铃业务的业务信息以及信令修正规则，删除掉彩铃业务下发的EDP配置请求消息中的无应答时长参数。此例子即对应业务流程控制中的对已调用业务控制点的信令消息流程的修正的处理。

第四种情况：业务触发信息为业务过滤规则时，业务触发点可以根据接收到的业务过滤规则进行后续的业务控制点调用。

业务控制点根据当前业务的执行情况，向业务触发点发送业务过滤规则。当前业务执行情况可以是业务控制点接受了用户更新的业务数据的情况，例如用户激活了CFU业务；当前业务执行情况也可以是业务控制点接收到一个SIP消息后的业务流程处理，例如收到了业务触发点发送的INVITE消息。业务触发点接收到所述业务过滤规则后，根据所述业务过滤规则进行后续的业务控制点调用。特别的，当业务触发后业务控制点在通信中向业务触发点下发业务过滤规则的情况下，业务触发点可以工作于背靠背用户代理(B2BUA)方式，此时后续消息的触发不使用SIP路由的方式，所以不存在控制上报后续消息与SIP路由规则的冲突问题。

下面以如图6所示的流程为例详细说明第四种情况的具体实施过程。

图中假设当前业务执行情况是业务控制点接收到一个SIP消息后的业务流程处理；业务控制点1地址为sip:AS1@homedomain.com，业务控制点2地址为sitp:AS2@homedomain.com。具体实施过程包括如下步骤：

步骤1，业务触发点收到一个Invite消息，该Invite消息来自用户终端。

步骤2，业务触发点根据业务过滤规则触发业务A到业务控制点1。

步骤3，业务控制点1回送200OK响应。

步骤4，业务控制点1通过Subscribe消息在通信中携带业务过滤规则，其中配置业务触发点遇到183消息要上报给业务控制点1，遇到486消息要上报给业务控制点2。

所述业务过滤规则采用XML方式描述，举例如下：

<FilterCriteria>

    <FilterName>name1<FilterName>

    <TriggerPoint>

        <ConditionTypeCNF>0</ConditionTypeCNF>

        <ActionInd>1</ActionInd>

        <DisarmFlag>1</DisarmFlag>

        <SPT>

           <ConditionNegated>0</ConditionNegated>

           <Group>0</Group>

       <SIPResponse>183</SIPResponse>

     </SPT>

   </TriggerPoint>

   <ApplicationServer>

      <ServerName>sip:AS1@homedomain.com</ServerName>

      <DefaultHandling>0</DefaultHandling>

    <SucceedFC>name20</SucceedFC>

    <DefaultSucceedFC>name100</DefaultSucceedFC>

  </ApplicationServer>

</FilterCriteria>

<FilterCriteria>

        <FilterName>name2<FilterName>

<TriggerPoint>

    <ConditionTypeCNF>0</ConditionTypeCNF>

    <ActionInd>1</ActionInd>

  <DisarmFlag>1</DisarmFlag>

<SPT>

    <ConditionNegated>0</ConditionNegated>

    <Group>0</Group>

              <SIPResponse>486</SIPResponse>

        </SPT>

  </TriggerPoint>

        <ApplicationServer>

           <ServerName>sip:AS2@homedomain.com</ServerName>

           <DefaultHandling>1</DefaultHandling>

   </ApplicationServer>

</FilterCriteria>

上面描述中说明了业务控制点下发了两条业务过滤规则，其均为新添加的上报后失效的业务过滤规则。第一条业务过滤规则(对应规则名name1)在收到SIP响应183时触发，对应的处理服务器地址为sip:AS1@homedomain.com，如果此业务过滤规则触发成功后，后续的关联业务过滤规则名为name20(SucceedFC)，如果此业务过滤规则触发失败，后续的关联业务过滤规则名为name100(DefaultSucceedFC)；第二条业务过滤规则(对应规则名name2)在收到SIP响应486时触发，对应的处理服务器地址为sip:AS2@homedomain.com。

这里采用Subscribe消息携带业务过滤规则，并通过XML方式描述所述业务过滤规则仅为了说明流程，实际可以不限于此。

步骤5，业务触发点回送200OK响应。

步骤6，业务触发点收到183消息。

步骤7，业务触发点根据前面步骤4中下发的业务过滤规则，触发到业务控制点1。

步骤7使用Notify消息携带183消息的内容仅为了说明流程，实际可以不限于此。

步骤8，业务控制点1回送200OK响应。

步骤9，业务触发点收到486消息。

步骤10，业务触发点根据前面步骤4中下发的业务过滤规则，触发到业务控制点2。

步骤10使用Notify消息携带486消息的内容仅为了说明流程，实际可以不限于此。

步骤11，业务控制点2回送200OK响应。

此例子对应业务控制点调用控制中的继续调用业务控制点的处理。

第五种情况：业务触发信息为业务调用结果时，业务触发点可以根据所述当前的业务调用结果以及业务过滤规则，进行后续的业务控制点调用。

下面举例说明第五种情况下的具体实施过程，如下：

业务控制点根据当前业务执行情况，向业务触发点下发业务触发信息，其中包括业务调用结果，并在所述业务调用结果指明业务触发成功、业务触发失败的指示、业务调用的处理结果等。

所述业务触发点接收到所述业务触发信息后，根据业务调用结果执行后续处理。例如调用结果指示失败时，根据业务过滤规则中的缺省处理和/或关联指示，调用相关的关联规则；当调用结果指示成功时，继续其它业务过滤规则的调用或者根据业务过滤规则中的关联指示调用相关的关联规则；当业务控制点返回业务调用处理结果时，根据业务控制点返回的消息进行业务过滤规则的匹配处理，例如根据业务控制点返回的业务调用处理结果触发其它的业务控制点。

此例子对应业务控制点调用控制中的继续调用业务控制点的处理。

第六种情况：业务触发信息为业务交互指示时，业务触发点和/或业务控制点可以根据接收到的业务触发信息中的业务交互指示和/或业务交互处理规则，进行后续的业务调用控制和/或业务流程控制。

具体实施过程如下：

第一业务处理节点根据当前业务的执行情况，向第二业务处理节点发送业务触发信息，其中包括业务交互指示。

假设提供主叫卡号业务的业务控制点向业务触发点发送业务触发信息时，通过SIP消息体携带方式携带，举例如下：

INVITE sip:bob@home.net SIP/2.0

Content-Type:application/servind+xml

<？xml version＝″1.0″encoding＝″UTF-8″？>

<servind xmlns＝″urn:ietf:params:xml:ns:servind″>

<IndService>callingCard</IndService>

    <IndDescription>

        <Ind>forbidden</Ind>

        <Side>orig</Side>

            <Service>conference</Service>

    </IndDescription>

</servind>

上述消息表示主叫卡号(callingCard)业务，禁止主叫侧的会议(conference)业务被调用。

之后，第二业务处理节点，如业务触发点和/或业务控制点可以根据指定方业务标识、作用方业务标识以及所述业务交互指示消息中的显式业务禁止/允许指示，或者，当业务交互指示中携带的信息为隐式时，依据所述业务交互指示以及预置的程序或业务交互处理规则，进行后续的业务调用控制。

如对应上述例子，用户在触发主叫卡号业务后发送消息希望触发会议业务，此时业务触发点根据保存的业务交互指示中作用方业务标识得知会议业务是被禁止的，此时业务触发点不再触发会议业务。此例子对应业务控制点调用控制中的阻止后续业务控制点的调用的处理。当业务交互指示为允许时对应业务控制点调用控制中的继续调用业务控制点的处理。

当业务触发点和/或业务控制点在通信中同时得到业务冲突禁止规则、业务过滤规则、业务交互指示时，则业务触发点和/或业务控制点以业务交互指示中指定的处理规则为准。

实际上业务冲突禁止规则是一类特殊的业务交互规则，它们也可以合并为一种业务规则。

业务交互指示的处理流程与图3中的流程比较相似，这里不再详细说明。

第七种情况：业务触发信息为服务状况信息时，业务触发点可以根据所述服务状况信息以及业务分发规则，进行后续的业务控制点调用。

可以认为，第七种情况下，业务触发点根据业务控制点的服务状态、业务负荷以及业务分发规则进行后续的业务控制点调用是一种业务触发点到业务控制点的动态负载均衡控制技术。

业务触发点可以维持业务控制点的负荷数据、状态数据。其中业务控制点的负荷数据可以采用但不限于记录业务(包括业务触发点触发的业务以及业务控制点主动发起的业务。)触发次数、CPU占用率等形式描述，状态数据可以采用但不限于业务触发点与业务控制点通过握手信号获得。

业务触发点可以维持业务标识(业务标识用于在运营商网络内唯一的对应一个业务，业务触发点从业务规则数据库和业务控制点获得的业务过滤规则中可以携带业务标识。)与提供业务标识对应的业务的业务控制点的地址间的对应关系。

业务触发点根据所述维持的状态数据和/或负荷数据，以及业务标识与所述业务控制点的地址间的对应关系，按照预置的业务分发规则，在支持业务标识所对应业务的业务控制点间进行业务分发控制：

当用户终端与一个具体的业务控制点有绑定关系时，业务触发点不进行到所述具体的业务控制点的动态分发处理。所述绑定关系包括但不限于业务过滤规则中指明了一个业务的业务控制点的地址时，根据所述业务控制点的地址将用户终端注册到一个特定业务控制点以提供特定的业务，后续该用户使用所述特定业务时触发到所述特定业务控制点。其它情况下，业务触发点可以根据业务控制点的状态数据和/或负荷数据，以及业务标识与所述业务控制点的地址间的对应关系，按照预置的业务分发规则，在支持业务标识所对应业务的业务控制点间进行业务分发控制。

此例子即对应业务控制点调用控制中的业务控制点的初始调用选择控制的处理。

需要说明的是，上述七种情况下业务控制点和/或业务触发点根据业务触发信息或根据业务触发信息以及业务规则进行的相应业务处理控制仅为示例，并不表示不同的业务触发信息和不同的业务规则间存在上述的对应绑定关系。

本发明通过的第二实施例是一种业务交互处理系统，其结构如图7所示，包括：第一业务处理节点和第二业务处理节点。其中所述第一业务处理节点包括业务触发信息产生单元、消息构造单元和业务触发信息传输单元；所述第二业务处理节点包括业务触发信息接收单元、业务规则获取单元和业务处理控制单元。

所述第一业务处理节点可以设置在业务控制点、业务触发点或用户终端中；所述第二业务处理节点可以设置在业务控制点或业务触发点中。

所述第一业务处理节点通过业务触发信息产生单元根据当前业务执行情况，产生业务触发信息。其中，所述当前业务执行情况包括如下情况中的至少一种：

业务控制点接受了用户更新的业务数据；业务控制点接收到通信消息；业务触发点上业务触发成功；业务控制点的当前状态发生迁移；用户终端接受了业务请求。

其中，所述业务触发信息包括如下信息中的至少一个：

业务调用信息；业务过滤规则；业务调用结果；业务交互指示和服务状况信息。其中各种信息的具体内容雷同于方法实施例中的相关描述，这里不再详细描述。

然后通过消息构造单元将产生的业务触发信息封装到所述通信消息的消息体或头域中；随后通过所述业务触发信息传输单元通过所述通信消息将所述业务触发信息发送给所述第二业务处理节点。

其中，所述通信消息包括：

业务处理节点间存在的当前通信过程中传递的通信消息；或，业务处理节点间存在的当前通信过程外传递的通信消息；或，在业务处理节点间新建的通信过程传递的通信消息。

所述第二业务处理节点通过所述业务规则获取单元获取业务规则。具体可以在接收通信消息时，从业务规则数据库获取预置的业务规则；或，当其本地设置有预置的业务规则，在本地获取所述预置的业务规则；或通过第一业务处理节点发送的业务触发信息获取相应的业务规则。

其中所述业务规则包括如下规则中的至少一种：

业务冲突禁止规则；业务交互处理规则；业务过滤规则；业务信令修正规则；业务分发规则。其中各种规则的具体内容雷同于方法实施例中的相关描述，这里不再详细描述。

当第一业务处理节点发送的业务触发信息到达第二业务处理节点后，所述第二业务处理节点通过业务处理控制单元根据所述业务触发信息以及获取的业务规则进行相应的业务处理控制，或者仅仅根据所述业务触发信息进行相应的业务处理控制。具体业务处理控制单元的业务处理控制包括：业务控制点调用控制和/或业务流程控制。所述业务控制点调用控制包括如下方式中的至少一种：继续调用业务控制点；对已调用的业务控制点的信令关系的修正；阻止后续业务控制点的调用；业务控制点的初始调用选择控制。所述业务流程控制包括如下方式中的至少一种：业务控制点间协同完成业务处理流程；对已调用业务控制点的信令消息流程的修正。下面描述第二业务处理节点的具体处理过程，如下：

所述第二业务处理节点通过业务处理控制单元根据所述业务触发信息，或根据业务触发信息以及所获取的业务规则阻止后续业务控制点的调用。例如当所述业务触发信息为业务调用信息时，根据其中的业务调用信息以及获取的业务冲突禁止规则，判断即将调用的后续业务是否允许被调用，并当判断出业务调用信息中指示的已调用的业务和即将调用的业务存在冲突时禁止调用所述后续业务。

所述第二业务处理节点通过业务处理控制单元根据所述业务触发信息在业务控制点间协同完成业务处理流程，例如根据所述业务调用信息进行业务控制点之间的互联以及协同完成业务处理流程。

所述第二业务处理节点通过业务处理控制单元对已调用的业务控制点的信令关系的修正或所述业务流程控制中对已调用业务控制点的信令消息流程的修正。例如根据所述业务调用信息以及预置的业务信令修正规则对业务触发点和业务控制点间的信令消息做出修正。

所述第二业务处理节点通过业务处理控制单元继续调用业务控制点。例如当业务触发信息为业务过滤规则时，根据接收到的业务触发信息中的业务过滤规则进行业务控制点的匹配，并调用所匹配到的业务控制点；或者，当业务触发信息为业务调用结果时，根据接收到的业务触发信息中的业务调用结果以及业务过滤规则，进行后续的业务控制点调用。

所述第二业务处理节点通过业务处理控制单元继续调用业务控制点或阻止后续业务控制点的调用。例如当业务触发信息为业务交互指示时，所述第二业务处理节点通过第四业务处理控制单元根据业务触发信息中的业务交互指示中指定方业务标识、作用方业务标识以及业务交互指示中的显式业务禁止/允许指示进行后续的业务调用控制；或，当业务交互指示中的信息为隐式时，根据接收到的业务触发信息中的业务交互指示和业务交互处理规则，进行后续的业务调用控制。

所述第二业务处理节点通过业务处理控制单元进行业务控制点的初始调用选择控制。例如当业务触发信息为服务状况信息时，所述第二业务处理节点通过第五业务处理控制单元，根据接收到的业务触发信息中的服务状况信息维持业务控制点的负荷数据和/或状态数据；以及，维持业务标识与提供业务标识对应的业务的业务控制点的地址间的对应关系；然后，根据所述维持的状态数据和/或负荷数据，按照预置的业务分发规则，在支持业务标识所对应业务的业务控制点间进行业务分发控制，所述业务控制点的地址通过所述业务标识与业务控制点地址对应关系得到。

另外，当业务触发信息通过业务处理节点间存在的当前通信过程外传递的通信消息传递时，在本发明提供的第二实施例中，所述第一业务处理节点还包括：关联方式指示单元，用于在传递所述业务触发信息之前，通过携带协议关联信息的通信消息指明后续发送业务触发信息的协议以及发送业务触发信息的协议过程，与当前通信的关联方式。所述第二业务处理节点还包括：关联单元，用于当接收到第一业务处理节点传送的通信消息后，根据其中携带的所述关联方式指示单元指明的所述关联方式识别第一业务处理节点的协议关联信息并根据此信息将通信过程外传递的业务触发信息与当前通信进行关联。

由上述本发明提供的技术方案可以看出，其通过第一处理节点发送业务触发消息给第二业务处理节点；所述第二业务处理节点根据所述业务触发消息进行相应的业务处理控制的技术，使业务交互问题能够在呼叫过程中被动态处理，也就是说，可以在呼叫过程中业务处理节点可以灵活控制业务的调用，并能对已经调用的业务做出调整。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (42)

1.一种业务交互处理方法，其特征在于，包括：

A、第一业务处理节点根据当前业务执行情况，产生业务触发信息并将其发送给第二业务处理节点；

B、所述第二业务处理节点根据所述业务触发信息进行相应的业务处理控制。

2.如权利要求1所述的方法，其特征在于，

所述第一业务处理节点包括：业务控制点、业务触发点或用户终端；

所述第二业务处理节点包括：业务控制点或业务触发点。

3.如权利要求1所述的方法，其特征在于，所述当前业务执行情况包括如下情况中的至少一种：

业务控制点接受了用户更新的业务数据；业务控制点接收到通信消息；业务触发点上业务触发成功；业务控制点的当前状态发生迁移；用户终端接受了业务请求。

4.如权利要求1所述的方法，其特征在于，所述将其发送给第二业务处理节点的过程，具体包括：

通过发送通信消息的消息体或头域或参数携带所述业务触发信息，并发送给所述第二业务处理节点。

5.如权利要求4所述的方法，其特征在于，所述通信消息包括：

业务处理节点间存在的当前通信过程中传递的通信消息；或，

业务处理节点间存在的当前通信过程外传递的通信消息；或，

在业务处理节点间新建的通信过程传递的通信消息。

6.如权利要求5所述的方法，其特征在于，当业务触发信息通过业务处理节点间存在的当前通信过程外传递的通信消息传递时，

第一业务处理节点在传递所述业务触发信息之前包括：通过携带协议关联信息的通信消息指明后续发送业务触发信息的协议以及发送业务触发信息的协议过程，与当前通信的关联方式；

第二业务处理节点接收所述协议关联信息后包括：识别第一业务处理节点的协议关联信息并根据此信息将通信过程外传递的业务触发信息与当前通信进行关联。

7.如权利要求1所述的方法，其特征在于，传输业务触发信息的协议包括如下协议中的至少一种：会话初始化协议SIP、通用用户档案协议GUP、Diameter协议、超文本传输协议HTTP、移动应用部分协议MAP、智能网应用规程协议INAP、CAMEL应用部分协议或内部协议。

8.如权利要求1所述的方法，其特征在于，所述业务触发信息包括如下信息中的至少一个：

业务调用信息；业务过滤规则；业务调用结果；业务交互指示；服务状况信息。

9.如权利要求8所述的方法，其特征在于，所述业务调用信息包括：业务标识，并可选地包括运营商标识、主被叫标记、业务互联方式、业务当前状态和附加业务信息。

10.如权利要求9所述的方法，其特征在于，当一次呼叫中调用多种业务的时候，一条传递业务触发信息的通信消息中携带有多个业务对应的多条业务调用信息。

11.如权利要求8所述的方法，其特征在于，所述业务过滤规则包括如下信息中的至少一个：业务点触发器SPT、服务器地址、规则操作动作指示、解配置标志、失败缺省处理、过滤规则名、过滤规则关联指示、业务调用消息指示、业务标识和同一业务的多条过滤规则的关联指示。

12.如权利要求11所述的方法，其特征在于，所述服务器地址包括下列类型的地址中的至少一种：

下发业务过滤规则的业务控制点自身地址、非下发业务过滤规则的业务控制点的地址、对应业务触发点上的一段程序或脚本的虚拟服务器地址。

13.如权利要求8所述的方法，其特征在于，所述业务调用结果包括如下信息中的至少一个：

业务调用成功的指示；业务调用失败的指示；业务调用处理结果。

14.如权利要求8所述的方法，其特征在于，当所述业务交互指示为显式指示时，所述业务交互指示包括作用方业务标识和允许/禁止标志，并可选地包括指定方业务标识、指定方用户属性/标记、指定方业务属性/标记、指定方业务能力、作用方业务的主被叫标记。

15.如权利要求8所述的方法，其特征在于，当所述业务交互指示为隐式指示时，所述业务交互指示包括指定方业务标识、指定方用户属性/标记和指定方业务属性/标记、指定方业务能力中的一个或者多个，并可选地包括作用方业务标识和/或作用方业务的主被叫标记。

16.如权利要求8所述的方法，其特征在于，所述服务状况信息包括：

服务状态数据和/或业务负荷数据。

17.如权利要求1或8所述的方法，其特征在于，步骤B中还包括：所述第二业务处理节点还根据业务规则进行相应的业务处理控制，所述业务规则来自业务规则数据库和/或本地和/或所述业务触发信息。

18.如权利要求17所述的方法，其特征在于，所述业务规则包括如下规则中的至少一个：

业务冲突禁止规则；业务交互处理规则；业务过滤规则；业务信令修正规则；业务分发规则。

19.如权利要求18所述的方法，其特征在于，所述业务冲突禁止规则包括如下元素中的至少一个：

指定业务的标识；指定业务的主被叫方标记；与指定业务有冲突的业务标识；与指定业务有冲突的业务的主被叫方标记。

20.如权利要求18所述的方法，其特征在于，所述业务交互处理规则包括如下元素中的至少一个：指定方业务标识；指定方用户属性/标记；指定方业务属性/标记；指定方业务能力；作用方的业务标识；允许/禁止标志。

21.如权利要求18所述的方法，其特征在于，所述业务过滤规则中包括：业务标识。

22.如权利要求18所述的方法，其特征在于，所述业务信令修正规则包括如下信息中的至少一个：

指定方业务标识；冲突方业务标识；指定方业务的主被叫标记；冲突方业务的主被叫标记；修正方向标记；信令修正方式。

23.如权利要求21所述的方法，其特征在于，所述信令修正方式包括如下信息中的至少一个：

消息类型的转换；消息的屏蔽；消息头域、消息头域中的参数和/或消息体内容的转换、删除、修改或添加。

24.如权利要求18所述的方法，其特征在于，所述业务分发规则包括：按顺序分发或按百分比分发。

25.如权利要求1所述的方法，其特征在于，步骤B中，所述业务处理控制包括：业务控制点调用控制和/或业务流程控制。

26.如权利要求25所述的方法，其特征在于，步骤B中，所述业务控制点调用控制包括如下方式中的至少一种：继续调用业务控制点、对已调用的业务控制点的信令关系的修正、阻止后续业务控制点的调用、业务控制点的初始调用选择控制。

27.如权利要求25所述的方法，其特征在于，步骤B中，所述业务流程控制包括如下方式中的至少一种：业务控制点间协同完成业务处理流程；对已调用业务控制点的信令消息流程的修正。

28.一种业务交互处理系统，其特征在于，包括：

第一业务处理节点和第二业务处理节点；

所述第一业务处理节点，用于根据当前业务执行情况，产生业务触发信息并将其发送给第二业务处理节点；

所述第二业务处理节点根据所述业务触发信息进行相应的业务处理控制。

29.如权利要求28所述的系统，其特征在于，

所述第一业务处理节点设置在业务控制点、业务触发点或用户终端中；

所述第二业务处理节点设置在业务控制点或业务触发点中。

30.如权利要求28所述的系统，其特征在于，所述当前业务执行情况包括如下情况中的至少一种：

业务控制点接受了用户更新的业务数据、业务控制点接收到通信消息、业务触发点上业务触发成功、业务控制点的当前状态发生迁移和用户终端接受了业务请求。

31.如权利要求28所述的系统，其特征在于，所述业务触发信息包括如下信息中的至少一个：

业务调用信息、业务过滤规则、业务调用结果、业务交互指示和服务状况信息。

32.如权利要求31所述的系统，其特征在于，所述第一业务处理节点包括：业务触发信息产生单元、消息构造单元和业务触发信息传输单元；

所述业务触发信息产生单元，用于根据当前业务执行情况，产生业务触发信息；

所述消息构造单元，用于将产生的业务触发信息封装到通信消息的消息体或头域或参数中；

所述业务触发信息传输单元，用于通过所述通信消息将所述业务触发信息发送给所述第二业务处理节点。

33.如权利要求32所述的系统，其特征在于，所述通信消息包括：

业务处理节点间存在的当前通信过程中传递的通信消息；或，

业务处理节点间存在的当前通信过程外传递的通信消息；或，

在业务处理节点间新建的通信过程传递的通信消息。

34.如权利要求33所述的系统，其特征在于，当业务触发信息通过业务处理节点间存在的当前通信过程外传递的通信消息传递时，所述第一业务处理节点还包括：

关联方式指示单元，用于在传递所述业务触发信息之前，通过携带协议关联信息的通信消息指明后续发送业务触发信息的协议以及发送业务触发信息的协议过程，与当前通信的关联方式。

35.如权利要求30所述的系统，其特征在于，所述第二业务处理节点包括：业务触发信息接收单元和业务处理控制单元；

所述业务触发信息接收单元，用于接收第一业务处理节点发送的业务触发信息；

所述业务处理控制单元，用于根据所述业务触发信息进行相应的业务处理控制。

36.如权利要求35所述的系统，其特征在于，所述第二业务处理节点还包括：

业务规则获取单元，用于在接收通信消息时获取业务规则，所述业务规则来自业务规则数据库和/或本地和/或所述业务触发信息。

37.如权利要求36所述的系统，其特征在于，所述业务规则包括如下规则中的至少一个：

业务冲突禁止规则；业务交互处理规则；业务过滤规则；业务信令修正规则；业务分发规则。

38.如权利要求35所述的系统，其特征在于，所述业务处理控制单元还用于根据所述业务触发信息以及所获取的业务规则进行相应的业务处理控制。

39.如权利要求35或38所述的系统，其特征在于，所述业务处理控制单元的业务处理控制包括：业务控制点调用控制和/或业务流程控制。

40.如权利要求39所述的系统，其特征在于，所述业务控制点调用控制包括如下方式中的至少一种：继续调用业务控制点；对已调用的业务控制点的信令关系的修正；阻止后续业务控制点的调用；业务控制点的初始调用选择控制。

41.如权利要求39所述的系统，其特征在于，所述业务流程控制包括如下方式中的至少一种：业务控制点间协同完成业务处理流程；对已调用业务控制点的信令消息流程的修正。

42.如权利要求34所述的系统，其特征在于，当业务触发信息通过业务处理节点间存在的当前通信过程外传递的通信消息传递时，所述第二业务处理节点还包括：

关联单元，用于当接收到第一业务处理节点传送的通信消息后，根据其中携带的所述关联方式指示单元指明的所述关联方式识别第一业务处理节点的协议关联信息并根据此信息将通信过程外传递的业务触发信息与当前通信进行关联。

Images