CN101132560A

CN101132560A - 业务交互处理方法和***

Info

Publication number: CN101132560A
Application number: CNA2007100003387A
Authority: CN
Inventors: 吴桑; 施有铸
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2006-08-25
Filing date: 2007-01-12
Publication date: 2008-02-27

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、第二业务处理节点获取所述业务触发信息，并根据所述业务触发信息进行相应的业务处理控制。

本发明的实施例还提供了一种业务交互处理***，其包括：

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

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

附图说明

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

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

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

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

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

图6为本发明提供的第一实施例中实现业务触发点根据业务调用信息以及业务信令修正规则对业务触发点和业务控制点间的信令关系进行修正的流程图；

图7为本发明提供的第一实施例中实现业务触发点根据业务调用信息以及业务信令修正规则对业务触发点和业务控制点间的信令消息进行修正的流程图；

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

图9为本发明提供的第一实施例中实现业务触发点根据业务调用结果以及业务过滤规则进行后续的业务控制点调用的流程图；

图10为本发明提供的第一实施例中实现业务控制点根据接收的其它业务控制点发送的业务交互指示进行后续的业务控制点调用的流程图；

图11为本发明提供的第一实施例中实现业务触发点发送业务交互指示，业务控制点根据该指示进行后续的业务控制点调用的流程图；

图12为本发明提供的第一实施例中实现业务触发点根据业务调用信息以及业务过滤规则，调用后续业务控制点的流程图；

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

具体实施方式

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

一、业务规则数据库

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

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

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

2、业务冲突禁止规则。

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

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

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

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

<Service>callForwardingUnconditional</Service>

<TargetService>doNotDisturb</TargetService>

<TargetService>callWaiting</TargetService>

</ConflictServiceDescription>

</ServiceInteractionDescription>

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

3、业务信令修正规则。

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

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

指定方业务标识、指定方业务的主被叫标记、指定消息/事件描述、修正方向描述和信令修正方式。

其中指定方业务标识、指定方业务的主被叫标记，用于描述信令修正作用的前提是调用了所指定的业务。

其中指定消息/事件描述，用于描述触发信令修正处理的事件或者消息，包括消息的来源，和/或，对消息/事件的具体描述。其中，消息的来源用于说明业务触发点收到的消息来自哪里，例如，增加一个FromServiceId描述发送消息的业务标识，来表示触发信令修正的消息为所对应的业务发送的。当然消息的来源还可以使用其它方式描述，例如，通过业务控制点的地址来描述。对消息/事件的具体描述包括如下信息中的至少一种：对消息类型的描述、对消息内容的描述、对会话状态的描述。对消息/事件的具体描述还可以包括其它附加的限定描述，例如用户的漫游状态、当前时间等。如果只有消息的来源的描述而没有对消息/事件的具体描述，则表示该来源发送的所有消息都会引起信令修正。

其中修正方向描述，用于控制修正规则是作用于业务触发点接收的消息或事件，还是作用于业务触发点发给冲突方业务控制点的消息。对于后者，修正方向描述还可以包括发送消息的目的地，例如可以通过接收消息的业务标识的形式表示将修正后的消息发送给哪个业务接收。

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

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

所述业务信令修正规则中的指定方业务标识、指定方业务的主被叫标记、指定消息/事件描述为信令修正的条件，修正方向描述、信令修正方式为具体的信令修正实施方法。上述业务信令修正规则中的条件可以不同时出现，例如信令修正规则中可以只出现指定方业务标识、修正方向描述以及信令修正方式，其中修正方向描述用于指示修正业务触发点接收到的指定方业务控制点发送的消息。

所述业务信令修正规则可以采用XML方式描述，例如：

<SessionState>Originating_Answer</SessionState>

</Condition>

<MessageType>ReleaseCall</MessageTypee>

</Condition>

</Condition>

</Condition>

</ChangingTrigger>

<Direction>Receive</Direction>

<Mode>Change</Mode>

<ProtocolType>Internal</ProtocolType>

</ChangingDes>

</SigChanging>

上述采用XML方式描述的业务信令规则分为：修正条件描述(对应ChangingTrigger中的描述)以及修正实施描述(对应ChangingDes中的说明)。其中，修正条件描述中SeviceId属性对应指定业务标识，表示实施信令修正的条件是该业务标识所代表的业务被调用；FromSeviceId属性对应消息的来源，它表示引起信令修正的消息为该业务标识所对应的业务发送。而SessionState、ProtocolType、MessageType均为对引起信令修正的消息的具体描述，分别表示触发信令修正时的会话状态、消息的协议类型、消息类型。修正实施描述中的Direction属性描述了信令修正方向，上例中取值Receive表示修正业务触发点收到的消息，而Mode属性描述了信令修正方式，上例中取值为Change表示进行消息类型的转换，而其后的ProtocolType以及MessageType描述了转换的具体消息。

4、业务交互处理规则。

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

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

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

5、业务分发规则。

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

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

二、业务控制点

业务控制点用于提供和执行业务逻辑。一个业务控制点可以提供和执行一个或者多个业务逻辑。业务控制点可以是SIP AS、OSA SCS、IM-SSF、业务控制功能(SCF，Service Control Function)实体、OSA应用服务器、软交换机等。业务控制点中也可以内置SCIM功能。除了发送和/或接收业务触发信息外，本发明中业务控制点可以具备如下功能：

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

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

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

三、业务触发点

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

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

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

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

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

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

6、根据业务调用信息以及业务过滤规则，进行后续的业务控制点调用。

四、业务数据存储点

所述业务数据存储点用于存储用户的业务数据，所存储的业务数据至少包括本发明实施例中的业务触发信息数据。

所述业务数据存储点可以位于HSS中，也可以位于其它用于存储用户业务数据的实体中，例如其它的数据库服务器。用户业务数据可以集中存储在一个实体上，也可以根据业务数据类型存储于不同实体上。

上述业务触发点与所述业务规则数据库之间存在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接口可以是直接接口也可以是间接接口。

所述业务控制点与所述业务数据存储点间存在E4接口，该接口可以采用但不限于如下协议：SIP协议、Diameter协议、GUP协议、HTTP协议、MAP协议、内部接口协议等。

所述业务控制点可以通过所述E4接口，向所述业务数据存储点发送业务触发信息数据，或者，从所述业务数据存储点中获取业务触发信息数据。

所述业务触发点与所述业务数据存储点间存在E5接口，该接口可以采用但不限于如下协议：SIP协议、Diameter协议、GUP协议、HTTP协议、MAP协议、内部接口协议等。

所述业务触发点可以通过所述E5接口，向所述业务数据存储点发送业务触发信息数据，或者，从所述业务数据存储点中获取业务触发信息数据。

所述业务控制点和/或业务触发点从所述业务数据存储点获取业务触发信息数据的方式可以是主动查询，也可以是通过订阅等方式要求所述业务数据存储点主动发送。

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

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

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

所述第二业务处理节点获取所述第一业务处理节点产生的业务触发信息的方式包括如下方式中至少一种：

所述第一业务处理节点将所述业务触发信息发送给所述第二业务处理节点；或者，所述第一业务处理节点先将所述业务触发信息，发送至所述业务数据存储点，然后所述第二业务处理节点从所述业务数据存储点获取所述业务触发信息。

其中，第一业务处理节点将所述业务触发信息发送给第二业务处理节点的处理可以通过如下实例实现：例如，用户发起通信，Service Broker 1通过SIP消息调用AS1(此时AS1为第一业务处理节点)，由于AS1发送的后续消息可经过Service Broker 1，因此业务触发信息可采用直接发送的方式传递至第二业务处理节点的Service Broker 1。

其中，第一业务处理节点将所述业务触发信息发送至所述业务数据存储点，第二业务处理节点从所述业务数据存储点获取所述业务触发信息的处理可以通过如下实例实现：例如，用户使用基于实时流协议(RTSP)的流媒体业务，此时终端直接连接至流媒体服务器，所述流媒体服务器根据用户的公共用户身份查找业务数据存储点，如HSS，并通过3GPP定义的标准的Sh接口写入业务触发信息数据，例如写入业务调用信息数据；此时由于第二业务处理节点，如Service Broker之前通过Sh接口订阅了HSS中的业务触发信息数据，因此Service Broker可从HSS中获取到变化后的业务触发信息数据，例如此例子中的用户使用流媒体业务的业务调用信息数据。在这个例子中第一业务处理节点为流媒体服务器，第二业务处理节点为Service Broker，业务数据存储点为HSS。

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

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

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

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

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

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

2、业务控制点接收到一个通信消息，如SIP消息，该消息触发了业务流程；

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

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

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

6、业务触发点准备触发业务控制点，即业务触发点准备向业务控制点发送业务触发消息。

所述第一业务处理节点和第二业务处理节点可以直接连接，也可以是通过中间的安全网关连接，第一业务处理节点和第二业务处理节点可以与安全网关间使用安全协议建立安全连接。

所述第一业务处理节点和第二业务处理节点之间可以是互相信任的，例如它们位于同一个运营商网络中；也可以是不信任的，例如它们位于不同的运营商网络中且两个运营商网络不具备信任关系。进一步的，第二业务处理节点还可以转发所述业务触发信息至其它业务处理节点，不妨称其为第三业务处理节点，同样，第一业务处理节点和第三业务处理节点间可以是互相信任的，也可以是不信任的。

第二业务处理节点可以通过本地策略识别，来控制是否接收第一业务处理节点传递的业务触发信息，例如通过对第一业务处理节点的地址配置是否允许接收等方式进行控制，当第一业务处理节点和第二业务处理节点不在同一信任域中的时候，第二业务处理节点可以丢弃第一业务处理节点的业务触发信息。

由于第二业务处理节点还可能向第三业务处理节点转发第一业务处理节点传递的业务触发信息，第一业务处理节点可以在发送所述业务触发信息的同时，指示该信息的私密性信息，例如增加一个PrivacyServiceInfo头域来指示该业务触发信息是否允许发送给其它所有或者特定的业务处理节点。第二业务处理节点对业务触发信息的转发控制也可以是依据本地策略进行的，例如根据第一业务处理节点地址和/或第三业务处理节点的地址，来配置是否允许转发第一业务处理节点发送的业务触发信息。

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

基于SIP协议传输的SIP消息包括如下类型中的至少一种：邀请消息SIPINVITE、确认消息SIP ACK、订阅消息SIP SUBSCRIBE、通知消息SIP NOTIFY、参考消息SIP REFER、信息消息SIP INFO、即时消息SIP MESSAGE、发布消息SIP PUBLISH、SIP响应消息。

所述业务触发信息包括如下几种业务触发信息中的至少一个：业务调用信息；业务过滤规则；业务调用结果；业务交互指示；服务状况信息。下面分别对其进行详细说明：

1、业务调用信息。

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

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

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

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

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

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

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

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

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

<Content>waiting</Content>

</SIPHeader>

</Condition>

<ServiceIdentifier>callWaiting</ServiceIdentifier>

</ServiceInfo>

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

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

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

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

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

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

所述业务互联方式可用于不同业务控制点之间的互联，也可用于业务触发点与业务控制点间的互联。对于后者可用于非配置方式的业务触发处理，即业务控制点的地址是动态传递的，而不是静态配置的，例如用户使用非IMS的流媒体业务时，所述流媒体业务应用不经过业务触发点，业务触发点不知道提供所述流媒体业务的业务控制点地址，而所述业务控制点可以通过向业务触发点传递携带业务互联方式的业务调用信息，例如通过业务数据存储点传递该消息，指示业务控制点的地址以及访问方式；所述业务触发点可以根据所述地址以及访问方式，在需要的时候动态地访问发送所述业务调用信息的业务控制点。例如，在用户使用流媒体业务的时候，来电话要在媒体内容中显式主叫号码，则业务触发点可以通过记录的流媒体业务中的业务调用信息中的业务互联方式向所述流媒体业务控制点发送业务调用消息。

业务控制点支持的互联协议类型可以采用但不限于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是可选信息，由业务控制点填充。

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

所述附加业务信息用于携带该业务相关的附加描述信息，例如***呼叫中的第三方付费标志、付费的第三方用户标识、已经激活的业务特征、业务版本信息、业务提供商信息等。所述业务版本信息用于标识一个业务的版本，该版本信息可用于业务交互控制处理，例如会议业务V1.0不支持多方的预付费预算从而不能与预付费业务同时调用，会议业务V2.0支持与预付费业务的同时调用，此时对于会议业务和预付费业务的交互处理对于版本V1.0和V2.0是不同的。所述业务提供商信息用于标识提供业务的厂家信息，同样业务提供商信息也可用于业务交互控制处理。上述的业务版本信息以及业务提供商信息均属于业务属性的刻画。

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

所述业务调用信息通过SIP消息传递的方法至少包括如下方式之一：通过Via头域传递；通过Record-Route头域传递；通过History-Info头域传递；通过业务调用信息头域传递；通过业务调用信息消息体传递；通过业务信息头域传递；通过业务信息消息体传递。下面分别对这几种传递方式进行说明：

①、通过Via头域传递：

不扩展Via头域携带业务标识的例子如：

Via:SIP/2.0/USP 800.AS1.home.net；branch＝z9hG4bK7ef4c23976

或

Via:SIP/2.0/USP [email protected]；branch＝z9hG4bK7ef4c23976

上面两个例子中800.AS1.home.net以及[email protected]表示已经调用了AS1上的业务800。

扩展Via头域携带业务调用信息的例子如：

Via: SIP/2.0/USP

AS1.home.net；service＝conf；operator＝CMCC；branch＝z9hG4bK7ef4c23976

上面的例子中Via头域携带了两个业务调用信息的参数service以及operator，其中service携带调用的业务标识为conf表示调用了会议业务，operator携带运营商标识CMCC。

②、通过Record-Route头域传递：

不扩展Record-Route头域携带业务标识的例子如：

Record-Route:<sip:200.AS1.home.net；lr>

上面的例子中200.AS1.home.net表示已经调用了AS1上的业务200。

扩展Record-Route头域携带业务标识的例子如：

Record-Route:<sip:AS1.home.net；service＝200；operator＝CNC；lr>

上面的例子中Record-Route头域中的URI参数进行了扩展，携带了两个业务调用信息的参数service以及operator，其中service携带调用的业务标识为200表示调用了200业务，operator携带运营商标识CNC。

③、通过History-Info头域传递：

例1：

History-Info:<sip:[email protected]>；index＝1

上面的例子中[email protected]表示已经调用了AS1上的业务200。

例2：

History-Info: <sip:[email protected]>； index＝1；

service-id＝200；operator＝CNC

上面的例子中History-Info头域引入了两个扩展参数service-id以及operator，其中service-id携带调用的业务标识为200表示调用了200业务，operator携带运营商标识CNC。

④、通过业务调用信息头域传递：

这种传递方式在SIP消息中新增一个业务调用信息头域，例如单独增加一个P-Service-History头域，对应的例子如：

P-Service-History: service-id＝800；operator＝op1；version＝1.0；vender＝v1；

call-side＝orig；service-addr＝[email protected]；service-instance＝4151D0FCE11；

service-state＝state12

上面的例子中使用了P-Service-History头域，其中service-id参数取值800表示已经调用了800业务，operator取值op1表示运营商为op1，version取值1.0表示业务版本号为1.0，vender取值为v1表示业务开发商为v1；call-side取值为orig表示该业务为主叫侧业务，service-addr取值[email protected]表示业务控制点的地址，service-instance取值4151D0FCE11表示业务控制点当前的业务处理逻辑实例为4151D0FCE11，service-state取值state12表示业务控制点当前状态为state12。

⑤、通过业务调用信息消息体传递：

这种传递方式在SIP消息中新增一个业务调用信息消息体，例如定义一个业务调用信息多用途网络邮件扩展(MIME，Multipurpose Internet MailExtensions)内容类型(Content-Type)，取值为application/servicehistory，前面采用业务调用信息头域传递的例子中的信息采用此种方式表示如下：

Content-Type:application/servicehistory

service-id＝800

operator＝op1

version＝1.0

vender＝v1

call-side＝orig

service-addr＝[email protected]

service-instance＝4151D0FCE11

service-state＝state12

上面的例子中业务调用信息消息体采用了文本方式编码，这里仅为示例，它也可以采用其它编码格式，例如采用XML方式编码或者二进制编码等。

⑥、通过业务信息头域传递：

这种方式下本发明中的业务触发信息中的内容采用统一的业务信息头域来传递，传递不同的业务触发信息的区别是使用了不同的业务信息头域参数，例如在SIP消息中新增一个P-Service-Info头域，前面采用业务调用信息头域传递的例子中的信息采用此种方式表示如下：

P-Service-Info: service-id＝800；operator＝op1；version＝1.0；vender＝v1；

service-state＝state12

⑦、通过业务信息消息体传递：

这种方式下本发明中的业务触发信息中的内容采用统一的业务信息消息体来传递，传递不同的业务触发信息的区别是使用了不同的业务信息消息体单元，例如在SIP消息中新增一个业务信息消息体，如定义一个业务信息MIMEContent-Type，取值为application/serviceinfo+xml，前面采用业务调用信息头域传递的例子中的信息采用此种方式表示如下：

Content-Type:application/serviceinfo+xml

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

<service-id>800</service-id>

<call-side>orig</call-side>

<service-addr>[email protected]</service-addr>

<service-instance>4151D0FCE11</service-instance>

<service-state>0</service-state>

</servicehistory>

</serviceinfo>

上面的例子中业务信息消息体采用了XML方式编码，这里仅为示例，它也可以采用其它编码格式，例如采用文本方式编码或者二进制编码等。

除了SIP消息外，业务调用信息也可以采用其它类型的消息传递，例如业务触发点和/或业务控制点可以通过Sh接口的Diameter协议消息访问HSS，并通过HSS保存以及传递业务调用信息。

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描述中，此时它可以表示相关过滤规则的执行结果为业务触发条件。

所述业务调用消息，用来指示业务过滤规则条件匹配后，对特定服务器地址的调用消息。所述业务调用消息至少包括如下指示之一：消息的协议类型、消息类型、消息的关键参数。

所述业务标识可以位于对业务控制点的描述部分，用于表示业务过滤规则要触发的业务。业务控制点下发的业务过滤规则中如果一条业务过滤规则携带了业务标识而其它业务过滤规则没有携带业务标识，可以默认为所下发的业务过滤规则使用同样的业务标识。业务标识也可以位于业务过滤规则的业务点触发器描述中，即将已经调用的业务种类作为一种匹配条件，在这种情况下对业务标识的描述还可以包括业务标识的来源，即表示从哪里调用了对应的业务，例如增加一个Origination单元，当该属性取值DifferentCommunication时，表示非当前通信调用的业务，取值SameCommunication时，表示当前通信调用的业务。

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

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

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

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

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

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

所述业务过滤规则通过消息传递的方法至少包括如下方式之一：通过SIP消息业务过滤规则消息体传递；通过业务信息消息体传递。下面分别对其进行说明：

①、通过SIP消息业务过滤规则消息体传递：

这种传递方式在SIP消息中新增一个业务过滤规则消息体，例如定义一个业务过滤规则MIME Content-Type，取值为application/servicefiltercriteria+xml，对应的使用此消息体传递业务过滤规则的例子如：

Content-Type:application/servicefiltercriteria+xml

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

<SPT>

</SPT>

</TriggerPoint>

<ServerName>sip:[email protected]</ServerName>

</ApplicationServer>

</FilterCriteria>

</servicefiltercriteria>

上面的例子中业务过滤规则消息体采用了XML格式编码，它也可以采用其它的编码格式，例如文本编码、二进制编码等。

上面的例子中包含了两条过滤规则，第一条过滤规则的过滤规则名对应FilterName属性的取值name1；TriggerPoint类为触发条件的描述；其中DisarmFlag为解配置标志，该属性取值为1表示该过滤规则上报后就会失效；过滤规则中的SPT类表示该规则规则的触发器，其中SIPResponse取值183表示过滤规则在收到携带SIP响应码为183的SIP响应消息时触发；ApplicationServer类为业务控制点描述部分，其中ServerName属性取值sip:[email protected]表示该过滤规则匹配以后触发至该地址对应的业务控制点；SucceedFC为该过滤规则触发成功以后的过滤规则关联指示，该属性取值为name20表示该过滤规则触发成功以后执行过滤规则名为name20的过滤规则；DefaultSucceedFC为该过滤规则触发失败以后的过滤规则关联指示，该属性取值为name100表示该过滤规则触发成功以后执行过滤规则名为name100的过滤规则。

②、通过业务信息消息体传递：

这种方式下本发明中的业务触发信息中的内容采用统一的业务信息消息体来传递，传递不同的业务触发信息的区别是使用了不同的业务信息消息体单元，例如在SIP消息中新增一个业务信息消息体，如定义一个业务信息MIMEContent-Type，取值为application/serviceinfo+xml，对于上面的通过SIP消息业务过滤规则消息体传递的例子采用此种方式表示如下：

Content-Type:application/serviceinfo+xml

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

<SPT>

</SPT>

</TriggerPoint>

<ServerName>sip:[email protected]</ServerName>

</ApplicationServer>

</FilterCriteria>

</servicefiltercriteria>

</serviceinfo>

除了SIP消息外，业务过滤规则也可以采用其它类型的消息传递，例如业务触发点和业务控制点之间可以通过Diameter协议发送业务过滤规则。例如业务触发点在当前通信过程中通过SIP消息，调用了业务控制点，业务控制点使用Diameter消息下发业务过滤规则，在发送前，业务控制点可以先在发往业务触发点的SIP消息中，指示下发业务触发信息的协议类型为Diameter协议，以及下发业务触发信息的Diameter消息中的会话ID(Session-Id)。然后，业务控制点使用Diameter协议以及上述消息中的Session-Id，下发业务触发信息，业务触发点根据所述Session-Id，将接收的Diameter消息与当前通信关联，即接收的Diameter消息可作用于当前通信，同时根据Diameter消息类型或其中的参数，识别出业务控制点下发的Diameter消息中携带了业务过滤规则。

3、业务调用结果。

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

所述业务调用结果通过SIP消息传递的方法至少包括如下方式之一：通过Via头域传递；通过Record-Route头域传递；通过History-Info头域传递；通过SIP消息业务调用结果头域传递；通过SIP消息业务调用结果消息体传递；通过业务信息头域传递；通过业务信息消息体传递。下面分别对其进行说明：

①、通过Via头域传递：

例如：Via:SIP/2.0/USP AS1.home.net；service-id＝s1；invoke-result＝succeed

上面的例子中Via头域携带了service-id以及invoke-result参数，表示业务s1调用成功。

②、通过Record-Route头域传递：

例如：Record-Route: <sip:AS1.home.net；service-id＝s1；invoke-result＝succeed；lr>

上面的例子中Record-Route头域携带了service-id以及invoke-result参数，表示业务s1调用成功。

③、通过History-Info头域传递：

例如：

History-Info: <sip:[email protected]>； index＝1； service-id＝s1；

invoke-result＝succeed；process-result＝user free

上面的例子在History-Info头域增加了几个参数invoke-result表示业务调用的成功失败指示，process-result表示业务处理的结果，这个例子表示业务s1调用成功，业务处理结果返回字符串user free。

④、通过SIP消息业务调用结果头域传递：

这种传递方式在SIP消息中新增一个业务调用结果头域，例如单独增加一个P-Service-Result头域，对于上面的例子，采用此种方式表示的例子如：

P-Service-Result:service-id＝s1；invoke-result＝succeed；process-result＝userfree

⑤、通过SIP消息业务调用结果消息体传递：

这种传递方式在SIP消息中新增一个业务调用结果消息体，例如定义一个业务调用结果MIME Content-Type，取值为application/serviceresult，对于上面的例子，采用此种方式表示如下：

Content-Type:application/serviceresult

service-id＝s1

invoke-result＝succeed

process-result＝user free

⑥、通过业务信息头域传递：

这种方式下本发明实施例中的业务触发信息中的内容，采用统一的业务信息头域来传递，传递不同的业务触发信息的区别是使用了不同的业务信息头域参数，例如在SIP消息中新增一个P-Service-Info头域，对于上面的例子，采用业务信息头域传递业务调用结果的示例如下：

P-Service-Info:service-id＝s1；invoke-result＝succeed；process-result＝user free

⑦、通过业务信息消息体传递：

这种方式下本发明实施例中的业务触发信息中的内容，采用统一的业务信息消息体来传递，传递不同的业务触发信息的区别是使用了不同的业务信息消息体单元，例如在SIP消息中新增一个业务信息消息体，如定义一个业务信息MIME Content-Type，取值为application/serviceinfo+xml，对于上面的例子，采用业务信息消息体传递业务调用结果的示例如下：

Content-Type:application/serviceinfo+xml

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

<service-id>s1</service-id>

</servicehistory>

<invoke-result>succeed</invoke-result>

<process-result>user free</process-result>

</serviceresult>

</serviceinfo>

此外，上述业务调用结果中的业务调用成功的指示和业务调用失败的指示可以只表示有业务被调用成功或失败，而不指明具体的业务，如通过Record-Route头域传递，在业务控制点被调用后，在返回给业务触发点的消息中携带的指示，如如下示例：

Record-Route:<sip:AS1.home.net；invoke-result＝succeed；lr>

上面的例子中，Record-Route头域携带了invoke-result参数，表示有业务被调用成功，但不指明业务类型；或者，在业务控制点被调用后，在返回给业务触发点的消息中携带的指示，如如下示例：

Record-Route:<sip:AS1.home.net；invoke-result＝failure；lr>

表明业务控制点被调用后，没有成功调用一个业务，即业务调用失败。

4、业务交互指示。

业务交互指示用于指示相关业务调用是否允许或禁止。

所述业务交互指示包括至少一个如下信息：

指定方业务标识、指定方用户属性/标记、指定方业务属性/标记、指定方业务能力、允许调用业务的描述、禁止调用业务的描述。

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

所述指定方用户属性/标记用于标识用户的属性或者身份，例如紧急呼叫的紧急用户标记[email protected]，或者话务员呼叫的话务员用户属性都是一种指定方用户属性/标记，该用户属性/标记可以用于指示与其它业务的交互关系，例如话务员发起的呼叫或紧急用户接收的紧急呼叫可以突破被叫的免打扰业务。

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

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

所述允许调用业务的描述至少包括如下之一：允许调用的业务标识、允许调用的业务的主被叫标记、后续业务允许调用标记。

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

所述后续业务允许调用标记用于指示所有后续的业务都允许调用，如，一个业务控制点被触发后，返回的消息中携带了所述后续业务允许调用标记，表明该业务控制点已经调用的业务，不影响当前通信中该业务控制点之后的业务调用。目前3GPP标准中S-CSCF的被叫触发处理流程中，当S-CSCF触发至AS，AS返回消息中Request-URI被修改后S-CSCF不再处理后续的业务过滤规则，而采用本发明的方案业务控制点可以在发送的消息中传递所述后续业务允许调用标记，此时业务触发点可以不受现有技术中Request-URI被修改后不能触发后续业务的限制，即业务触发点可以继续触发后续的业务控制点。

所述禁止调用业务的描述至少包括如下之一：禁止调用的业务标识、禁止调用的业务的主被叫标记、后续业务禁止调用标记。具体的解释与上面允许调用业务的描述包括的内容的解释类似。

其中，所述后续业务禁止调用标记用于指示所有后续的业务都禁止调用，进一步的，所述后续业务禁止调用标记又可以分为如下两种情况：本方后续业务禁止调用标记、或所有后续业务禁止调用标记。所述本方后续业务禁止调用标记用于指示本方(主叫方或被叫方)的后续业务被禁止调用，如主叫侧的一个业务控制点被触发后，返回的消息中携带了所述本方后续业务禁止调用标记，则表明主叫侧的后续业务调用都被禁止；所述所有后续业务禁止调用标记用于指示当前通信中所有的后续业务被禁止调用，如主叫侧的一个业务控制点被触发后，返回的消息中携带了所述所有后续业务禁止调用标记，则表明主叫侧的后续业务和被叫侧的业务调用都被禁止。使用后续业务禁止调用标记的例子如：用户拨打200接入主叫***业务，由于200业务用户跟话机没有必然的绑定关系，则***业务AS发送的消息中可指示本方后续业务禁止调用标记，此时业务触发点不再处理该用户后续的业务过滤规则，即禁止调用本方后续的业务。

所述允许或者禁止调用业务的描述形式可以是集中描述的，例如通过allow-service或者forbid-service头域集中描述所有允许或者禁止调用的业务；也可以是分别描述的，例如通过ServiceInd头域中的allow或者forbid参数描述指定业务的允许/禁止调用属性从而对各个指定业务分别描述。所述业务交互指示可以不明确说明描述的业务是允许调用或者禁止调用，此时可以使用默认值，例如默认指示的业务允许被调用。所述允许调用的业务标识以及后续业务允许调用标记可以是分别描述的，也可以是集中描述的，例如采用allow-service头域集中描述的形式下，该头域取值all可以表示后续业务允许调用标记；采用分别描述的方式下，所述后续业务允许调用标记可以单独描述，例如使用一个allow-all头域指示后续业务都允许被调用。同样禁止调用的业务标识以及后续业务禁止调用标记可以是分别描述的，也可以是集中描述的。

所述业务交互指示可以是由业务控制点发送的，例如业务控制点上特定业务被调用后，业务控制点主动指示该业务调用后其它业务是否允许调用。

所述业务交互指示也可以是由业务触发点发送的，此时业务触发点可以通过业务过滤规则数据和/或业务冲突禁止规则数据，发送业务交互指示。例如用户同时签约了遇忙前转以及呼叫等待业务，但它们是分时间段被调用的，如上班的时间段调用遇忙前转业务，下班后的时间段调用呼叫等待业务，对用户上班的时间段对应的业务进行描述的业务过滤规则数据中的服务器地址配置如下：

<ServerName>sip:AS1.home1.net；forbid-service＝CW</ServerName>

此时业务触发点将上述服务器地址描述放置于至业务控制点AS1的SIP消息的Route头域部分，此时该头域即携带了业务交互指示，业务控制点收到消息后，将调用遇忙前转业务，并根据上述的业务交互指示禁止呼叫等待业务的调用。

又例如，用户接收无线一键通(PoC，Push to talk over Cellular)业务服务器发送的来话，而所述用户又签约了恶意呼叫追查以及无应答前转业务，这两个业务在同一个业务控制点AS1上提供，对应的业务过滤规则中的服务器地址描述如下：

<ServerName>sip:AS1.home1.net；service＝MCID，sip:TAS.home1.net；service＝CFNR</ServerName>

由于PoC业务对于终端有特殊的要求，因此不期望无应答前转业务被调用，以避免前转后的用户终端不具备PoC支持能力，此时业务冲突禁止规则中，存在PoC业务和无应答前转业务冲突的描述，由此业务触发点在发送至业务控制点AS1的业务调用消息时，删除无应答前转业务的SIP URL，即它发送的Route头域为：

Route:<sip:AS1.home1.net；service＝MCID；lr>

此时该Route头域包含业务交互指示，其中指示允许调用恶意呼叫追查业务。

所述业务交互指示通过SIP消息传递时，可以如下方式实现：通过Via头域传递；通过Record-Route头域传递；通过SIP消息Route头域传递；通过SIP消息History-Info头域传递；通过SIP消息业务交互指示头域传递；通过SIP消息业务交互指示消息体传递；通过业务信息头域传递；通过业务信息消息体传递。下面分别对其进行说明：

①、通过Via头域传递：

例如Via:SIP/2.0/USP

[email protected]；branch＝z9hG4bK7ef4c23976；allow-service＝s1，s3，s5；forbid-service＝s4

上面的例子中Via头域携带了业务交互指示，通过allow-service参数以及forbid-service参数分别指示后续允许调用的业务和禁止调用的业务。

②、通过Record-Route头域传递：

例如Record-Route：

<sip:AS1.home.net；service＝s1；allow-service＝s1，s3，s5；forbid-service＝s4；lr>

上面的例子中Record-Route头域中的URI参数进行了扩展，携带了两个业务交互指示参数allow-service以及forbid-service分别指示后续允许调用的业务和禁止调用的业务。

③、通过SIP消息Route头域传递：

不扩展Route头域携带业务交互指示的例子如：

Route:<sip:[email protected]；lr>

上面通过两个Route头域携带业务交互指示，分别表示接收消息的实体允许调用业务s1以及s3。

扩展Route头域携带业务交互指示的例子如：

Route:<sip:AS1.home1.net；allow-service＝s1，s3，s5；lr>

又例如：

Route:<sip:AS1.home1.net；forbid-service＝s4；lr>

前一个例子中Route头域中增加了一个allow-service参数，其中的取值表示接收消息的实体允许调用业务s1、s3、s5；后一个例子中Route头域中增加了一个forbid-service参数，其中的取值表示接收消息的实体禁止调用业务s4。

④、通过SIP消息History-Info头域传递：

例如：

History-Info:<sip:AS1.home.net>；index＝1；ind-service＝s1；allow-service:s2，s3；forbid-service＝s6

上面的例子History-Info头域中增加了ind-service参数，其中的取值表示该业务交互指示为业务s1的交互指示；allow-service参数，其中的取值表示接收消息的实体允许调用业务s2、s3；forbid-service参数，其中的取值表示接收消息的实体允许调用业务s6。

⑤、通过SIP消息业务交互指示头域传递：

这种传递方式在SIP消息中新增一个业务交互指示头域，例如单独增加一个P-Service-Ind头域，对应的例子如：

P-Service-Ind:ind-service＝s1；allow-service＝all；

该例子表示该业务s1发送的交互指示允许所有后续业务的调用。

⑥、通过SIP消息业务交互指示消息体传递：

这种传递方式在SIP消息中新增一个业务交互指示消息体，例如定义一个业务调用信息MIME Content-Type，取值为application/serviceind，对应的例子如：

Content-Type:application/serviceind

ind-service＝s1

allow-service＝s2，s3

forbid-service＝s6

上面的例子中业务信息消息体采用了文本方式编码，这里仅为示例，它也可以采用其它编码格式，例如采用XML方式编码或者二进制编码等。

⑦、通过业务信息头域传递：

这种方式下本发明中的业务触发信息中的内容采用统一的业务信息头域来传递，传递不同的业务触发信息的区别是使用了不同的业务信息头域参数，例如在SIP消息中新增一个P-Service-Info头域，对应的例子如：

P-Service-Info:ind-service＝s1；allow-service＝s2，s3；forbid-service＝s6

⑧、通过业务信息消息体传递：

这种方式下本发明中的业务触发信息中的内容采用统一的业务信息消息体来传递，传递不同的业务触发信息的区别是使用了不同的业务信息消息体单元，例如在SIP消息中新增一个业务信息消息体，如定义一个业务信息MIMEContent-Type，取值为application/serviceinfo+xml，对应的例子如：

Content-Type:application/serviceinfo+xml

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

<IndService>callingCard</IndService>

<Ind>forbidden</Ind>

<Service>conference</Service>

</IndDescription>

</serviceind>

</serviceinfo>

上面的例子表示主叫***业务禁止调用主叫侧的会议业务，本例中业务信息消息体采用了XML方式编码，这里仅为示例，它也可以采用其它编码格式，例如采用文本方式编码或者二进制编码等。

除了SIP消息外，业务交互指示也可以采用其它类型的消息传递，例如业务触发点和/或业务控制点可以通过Sh接口的Diameter协议消息访问HSS，并通过HSS保存以及传递业务交互指示信息。

此外，在消息中传递的所述后续业务禁止调用标记和所述后续业务允许调用标记可以是同一个标记字段，通过不同的赋值来区分后续业务是禁止调用还是允许调用，而所述后续业务禁止调用标记还可以通过不同的赋值来区分被禁止调用的是本方后续业务还是所有后续业务，当然也可以不区分，即在消息中传递的所述后续业务禁止调用标记固定只表示本方后续业务禁止调用或所有后续业务禁止调用。

当业务触发点收到所述后续业务禁止/允许调用标记时，可以据此处理后续的业务调用，比如，业务触发点从收到的消息中解析出后续业务禁止/允许调用标记后，据此不执行或执行后续的业务过滤规则(如iFC)。

业务触发点也可以不解析处理消息中的后续业务禁止/允许调用标记，此时，后续业务禁止/允许调用标记若要发挥作用可以有如下两种方式：后续的业务过滤规则中体现消息中的这部分内容、或后续业务控制点根据所述标记自行决定业务调用的允许或禁止。比如采用前一种方式，后续的业务过滤规则中设置的一个业务触发条件是消息中存在后续业务允许调用标记，这样当消息中携带的是后续业务禁止调用标记时，该业务过滤规则对应的业务控制点将不被调用。

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，根据所述业务触发信息进行相应的业务处理控制，或者，根据所述业务触发信息以及业务规则进行相应的业务处理控制。所述业务处理控制包括业务控制点调用控制和/或业务流程控制等。其中，业务控制点调用控制包括继续调用业务控制点(包括已经调用的业务控制点、未调用的业务控制点、允许调用业务控制点上特定业务，或，禁止调用业务控制点上特定业务但允许调用其它业务)、对已调用的业务控制点的信令关系的修正(如中止信令连接)、阻止后续业务控制点的调用、业务控制点的初始调用选择控制等。业务流程控制包括业务控制点间协同完成业务处理流程、对已调用业务控制点的信令消息流程的修正等。

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

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

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

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

这种情况对应的实施例如下：

用户A通过网页点击呼叫用户B，所述点击呼叫业务通过OSA GW/AS实现，用户A同时签约了语音呼叫连续性(VCC，Voice Call Continuity)业务以及来话限制业务，其中语音呼叫连续性业务在VCC AS上提供，来话限制业务在TAS上提供。

具体的实施过程如图4所示，其中业务触发点以及业务规则数据库均为Service Broker，业务控制点为OSA GW/AS、VCC AS、TAS，详细的步骤说明如下：

步骤1，用户A调用点击呼叫业务，此时OSA GW/AS向Service Broker发送INVITE消息，其中携带点击呼叫的业务调用信息，该消息具体为：

INVITE sip:[email protected] SIP/2.0

……

P-Service-Info:service-id＝CTD；version＝1.0；vender＝v1；call-side＝orig

上述消息中通过P-Service-Info头域携带了点击呼叫的业务调用信息，Service Broker收到该业务调用信息后记录下来。

在此过程中OSA GW/AS为第一业务处理节点。

步骤2，Service Broker根据业务调用信息以及业务冲突禁止规则进行检查，此时业务冲突禁止规则中存在如下描述：

<TargetService>incomingCallBarring</TargetService>

</ConflictDescription>

</ServiceConflictDescription>

用户的业务过滤规则数据中存在如下两条过滤规则描述：

<FilterName>incomingCallBarring<FilterName>

<SPT>

<Method>INVITE</Method>

</SPT>

<SPT>

</SPT>

</TriggerPoint>

<ServerName>sip:[email protected]</ServerName>

<ServiceId>incomingCallBarring</ServiceId>

</ApplicationServer>

</FilterCriteria>

<SPT>

<Method>INVITE</Method>

</SPT>

</TriggerPoint>

<ServerName>sip:[email protected]</ServerName>

</ApplicationServer>

</FilterCriteria>

上面两条业务过滤规则分别对应来话限制以及VCC业务的过滤规则描述。

因为Service Broker已经记录了点击呼叫的业务调用信息，而且业务冲突禁止规则中描述了禁止触发来话限制业务，因此当Service Broker进行业务触发的时候通过检查业务过滤规则中的业务标识，即上面示例描述中的ServiceId属性，发现来话限制业务的业务标识落在点击呼叫业务的冲突业务描述中，因此Service Broker禁止来话呼叫业务的调用，即不调用业务控制点TAS。

在此过程中Service Broker为第二业务处理节点。

步骤3，因为VCC业务不在点击呼叫业务的冲突业务描述中，所以ServiceBroker可以触发该业务，根据上面VCC业务的过滤规则触发到VCC AS，此时Service Broker向VCC发送INVITE消息，携带点击呼叫的业务调用信息。

步骤4，VCC AS进行业务处理后向Service Broker发送INVITE消息，其中增加了VCC业务的业务调用信息，该消息具体为：

INVITE sip:[email protected] SIP/2.0

……

P-Service-Info:service-id＝VCC；

在这个步骤中Service Broker改为充当第一业务处理节点。

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

本实施例中的说明用例的处理对应业务控制点调用控制中的阻止后续业务控制点的调用的处理。

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

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

步骤1，S-CSCF收到一个INVITE消息，该INVITE消息可以来自用户终端。

步骤2，S-CSCF根据业务过滤规则触发业务A到AS1。

步骤3，AS1调用业务s1成功，AS1通过INVITE消息将业务调用信息传递给S-CSCF，其中携带有业务s1支持的业务互联方式，包括AS1的地址与本次通信对应的业务逻辑实例ID以及支持的互联协议类型为SIP。例如所述INVITE消息为：

INVITE sip:[email protected] SIP/2.0

……

P-Service-Info: service-id＝s1；serv-contact-addr＝sip:[email protected]；

serv-contact-prot＝sip；serv-instance-id＝ffea1379

上述SIP消息中的P-Service-Info中的serv-contact-addr、serv-contact-prot、serv-instance-id分别对应业务互联地址、业务互联协议以及业务逻辑实例ID。

步骤4，S-CSCF根据业务过滤规则触发AS2上的业务s2。

步骤5，AS2调用业务s2，根据业务调用信息中的业务标识以及业务s2的流程需要，AS2判断需要与业务控制点s1互联，例如需要获取s1的业务数据。

步骤6，AS2根据业务调用信息向AS1发送INVITE消息，例如发送的消息为：

INVITE sip:AS1.home.net SIP/2.0

Route:<sip:[email protected]；serv-instance-id＝ffea1379；service-id＝s1>

AS2根据业务调用信息中的业务互联协议向AS1发送SIP INVITE消息，并且上述消息中的Route头域中的地址填充为AS1发送的业务互联信息中的业务互联地址，并在Route头域中携带业务互联信息中的业务逻辑实例ID以及业务标识，根据这些信息AS1可定位该通信的控制逻辑。

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

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

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

假设业务控制点为OSA GW/AS或TAS，业务触发点为Service Broker。所述来话筛选业务在OSA GW/AS上提供，无应答转语音邮箱业务在TAS上提供。具体实施过程说明如下：

步骤1，Service Broker收到至被叫用户的INVITE消息，此时根据业务过滤规则，Service Broker调用业务控制点OSA GW/AS。

步骤2，Service Broker采用背靠背用户代理(B2BUA，Back to Back UserAgent)的模式向OSA GW/AS发送INVITE消息，请求调用所述来话筛选业务。

步骤3，OSA GW/AS调用来话筛选业务成功，向Service Broker发送200 OK响应消息，并在其中携带来话筛选业务的业务调用信息，Service Broker记录下所述业务调用信息。

步骤4，Service Broker向被叫用户发送INVITE消息。

步骤5，Service Broker上被叫无应答定时器超时，Service Broker检查获得的信令修正规则(该信令修正规则为Service Broker之前已经获取的，例如在用户注册的时候通过Sh接口从HSS获得)，其中存在如下描述：

<SessionState>Terminating_NoAnswer</SessionState>

</Condition>

</Condition>

</ChangingTrigger>

<Mode>Create</Mode>

</ChangingDes>

</SigChanging>

上述信令修正规则表示修正条件为当前会话状态为终端_无应答(对应SessionState属性取值)且已经调用了来话筛选业务(对应SeviceId的取值)，修正方向描述为修正方向为本地发送的消息(对应Direction属性的取值)，接收修正后的消息的目的地为当前提供ICS业务的业务控制点(对应DestinationSeviceId属性的取值)，信令修正方式为产生新的消息，具体的产生的消息为BYE消息(对应MessageType属性的取值)。

由于上述信令修正规则中的修正条件均满足，Service Broker根据其中的修正描述产生至OSA GW/AS的BYE消息。

步骤6，Service Broker向OSA GW/AS发送BYE消息，释放通信。

步骤7，由于Service Broker上被叫无应答定时器超时，且Service Broker没有收到被叫的应答消息，因此Service Broker向被叫发送CANCEL消息取消通信建立请求。

步骤8，Service Broker检查会话状态终端_无应答下的业务过滤规则，由于无应答转语音邮箱业务配置在此会话状态下触发，因此Service Broker向提供无应答转语音邮箱业务的TAS发送INVITE消息。

此例子即对应业务控制点调用控制中的对已调用的业务控制点的信令关系的修正的处理。

在上述例子中，第一业务处理节点为OSA GW/AS，第二业务处理节点为Service Broker。

信令修正处理也可以修正业务触发点和业务控制点间的信令消息，信令消息修正方式包括：消息类型的转换；消息的屏蔽；消息头域、参数和/或消息体内容的转换、删除、修改或添加；产生新的消息。例如用户拨打201智能***业务，在201业务的语音提示下，用户输入大众呼叫(MAS)智能业务的接入码，因此继续触发MAS业务，用户在MAS业务语音提示下进行足球比赛竞猜选择，其后MAS业务处理完毕，下发智能业务协议消息ReleaseCall释放呼叫，但由于201***业务具备连续呼叫的特性，因此直接执行ReleaseCall消息指令将导致201***业务无法连续呼叫。对于这个例子可以应用信令修正处理，如业务触发点可以根据已经调用的201业务以及MAS业务的业务信息以及信令修正规则，将ReleaseCall消息转换为挂机的DP事件消息上报给201业务，从而实现201业务的连续呼叫特性。

具体的关键实施过程如图7所示，其中业务触发点为Service Broker，所述201业务在201智能业务控制点(SCP，Service Control Point)上提供，MAS业务在MAS SCP上提供，即业务控制点为201 SCP、MAS SCP，Service Broker与上述两个SCP通过INAP协议对接，图7详细的步骤说明如下：

步骤1，Service Broker收到主叫用户发送的INVITE消息，其中携带201业务的PSI，此时根据业务过滤规则，Service Broker调用业务控制点201SCP。

步骤2，Service Broker向201SCP发送InitialDp消息，根据业务过滤规则中的业务标识Service Broker将该消息中的业务键设置为201业务的业务键值以指示201SCP调用201业务。此时Service Broker记录下201业务的业务调用信息。

步骤3，用户和201 SCP进行语音提示播放以及收号的交互过程略去，用户输入MAS业务的接入码以后201SCP向Service Broker发送RequestReportBCSMEvent消息，请求Service Broker监视DP事件，该消息中监视的事件类型包括监视被叫用户的挂机事件。

步骤4，201SCP根据收号结果向Service Broker发送Connect消息，其中携带MAS业务的接入码。

步骤5，根据业务过滤规则，Service Broker调用业务控制点MAS SCP，向MAS SCP发送InitialDp消息，根据业务过滤规则中的业务标识ServiceBroker将该消息中的业务键设置为MAS业务的业务键。此时Service Broker记录下MAS业务的业务调用信息。

步骤6，用户与MAS业务的交互过程略去，当业务处理完毕以后MAS业务下发ReleaseCall消息释放呼叫。

步骤7，Service Broker收到该消息检查信令修正规则，其中存在如下信令修正规则描述：

<SessionState>Originating_Answer</SessionState>

</Condition>

<MessageType>ReleaseCall</MessageTypee>

</Condition>

</Condition>

</Condition>

<Direction>Receive</Direction>

<Mode>Change</Mode>

<ProtocolType>Internal</ProtocolType>

</ChangingDes>

</SigChanging>

上述信令修正规则表示修正条件为当前会话状态为发端_应答(对应SessionState属性取值)，即主叫侧已经收到了应答信号；收到的消息协议类型为INAP(对应ProtocolType属性的取值)，消息类型为ReleaseCall(对应MessageType属性的取值)，消息来源为MAS业务发送的消息(对应FromServiceId属性的取值)；且当前已经调用了201业务(对应SeviceId属性的取值)。

修正方向描述为修正方向为本地接收的消息(对应Direction属性的取值)，信令修正方式为转换消息类型(对应Mode属性的取值)，转换后的消息协议类型为Internal表示转换为内部消息(对应ProtocolType属性的取值)，转换后的消息类型为DP9B，即对应被叫用户挂机的DP事件(对应MessageType属性的取值)。

由于上述条件满足，Service Broker将MAS业务发送的ReleaseCall消息转换为内部消息DP9B。

步骤8，由于201业务已经通过RequestReportBCSMEvent消息请求ServiceBroker监视被叫用户的挂机事件，因此Service Broker将内部消息DP9B转换为智能消息EventReportBCSM上报给Service Broker，该消息中携带的DP事件指示被叫挂机，即其中的参数EventTypeBCSM取值为9，legID取值为2。

此例子即对应业务流程控制中的对已调用业务控制点的信令消息流程的修正的处理。

在上面的例子中Service Broker根据业务过滤规则，本地记录业务调用信息，此时第一业务处理节点和第二业务处理节点均为Service Broker。

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

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

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

图中业务触发点为Service Broker，业务控制点为AS1、AS2。具体实施过程包括如下步骤：

步骤1，Service Broker收到一个INVITE消息，该INVITE消息来自用户终端。

步骤2，Service Broker根据静态配置的用户业务过滤规则触发到业务控制点AS1。

步骤3，AS1回送200 OK响应，确认INVITE消息处理成功。

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

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

<SPT>

</SPT>

</TriggerPoint>

<ServerName>sip:[email protected]</ServerName>

</ApplicationServer>

</FilterCriteria>

<SPT>

</SPT>

</TriggerPoint>

<ServerName>sip:[email protected]</ServerName>

</ApplicationServer>

</FilterCriteria>

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

这里采用SUBSCRIBE消息携带业务过滤规则，并通过XML方式描述所述业务过滤规则仅为了说明流程，实际可以不限于此，例如也可以采用INFO等消息、也可以采用文本等格式描述动态下发的业务过滤规则。

Service Broker收到上述动态下发的业务过滤规则后将其保存在本地。

步骤5，Service Broker回送200 OK响应，确认成功处理了该携带业务过滤规则的SUBSCRIBE消息。

步骤6，Service Broker收到183消息。

步骤7，Service Broker根据前面步骤4中保存的动态下发业务过滤规则，触发到AS1，并根据业务过滤规则中DisarmFlag属性的指示，将183响应消息对应的动态下发的业务过滤规则失效。

步骤7使用NOTIFY消息携带183消息的内容仅为了说明流程，实际可以不限于此，例如也可以采用INFO等消息发送。

步骤8，AS1回送200 OK响应，确认收到了该NOTIFY消息。

步骤9，Service Broker收到486消息。

步骤10，Service Broker根据前面步骤4中保存的动态下发的业务过滤规则，触发到AS2，并根据业务过滤规则中DisarmFlag属性的指示，将486响应消息对应的动态下发的业务过滤规则失效。

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

步骤11，AS2回送200OK响应。

此例子对应业务控制点调用控制中的继续调用业务控制点的处理。其中第一业务处理节点为AS1，第二业务处理节点为Service Broker。

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

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

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

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

其中业务触发点为S-CSCF，业务控制点为AS1、AS2，其中AS1提供用户日程设置查询业务并返回结果，AS2提供前转语音邮箱业务，被叫用户签约了一种用户日程忙触发前转语音邮箱的业务。图9的详细说明如下：

步骤1，S-CSCF收到至被叫用户A的INVITE消息。

步骤2，用户A的业务过滤规则中指示收到INVITE消息且会话情形(Session Case)为被叫受话时触发至AS1，因此S-CSCF向AS1发送INVITE消息，以调用用户日程设置查询业务。

步骤3，AS1调用用户日程设置查询业务，并在发送回S-CSCF的INVITE消息中返回用户A的日程查询，例如：

INVITE sip:[email protected] SIP/2.0

……

P-Service-Info:service-id＝s1；invoke-result＝succeed；process-result＝user busy

上述消息中通过P-Service-Info的process-result携带了用户日程设置为userbusy的业务调用处理结果。

步骤4，S-CSCF上存在如下业务过滤规则描述：

<SPT>

<Method>INVITE</Method>

</SPT>

<SPT>

</SPT>

<SPT>

<Header>P-Service-Info</Header>

</SIPHeader>

</SPT>

</TriggerPoint>

<ServerName>sip:[email protected]</ServerName>

</ApplicationServer>

</InitialFilterCriteria>

上述过滤规则表示注册的被叫用户收到INVITE消息，且P-Service-Info头域中携带的业务调用结果包含字符user busy，则触发至AS2。

S-CSCF收到AS1下发的INVITE消息后，进行业务过滤规则的匹配处理，因为上述规则被匹配上，所以S-CSCF根据该业务过滤规则触发AS2。

步骤5，S-CSCF向AS2发送INVITE消息，以调用前转语音邮箱业务。

此例子对应业务控制点调用控制中的继续调用业务控制点的处理。其中第一业务处理节点即为AS1，第二业务处理节点即为S-CSCF。

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

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

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

INVITE sip:[email protected] SIP/2.0

Content-Type:application/servind+xml

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

<IndService>callingCard</IndService>

<Ind>forbidden</Ind>

<Service>conference</Service>

</IndDescription>

</servind>

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

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

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

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

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

上面的例子中由业务触发点处理业务交互指示，也可以是由业务控制点来处理业务交互指示，如图10所示，其中业务触发点为S-CSCF，业务控制点为OSA GW/AS、TAS，其中OSA GW/AS提供主叫***业务，TAS提供会议业务。图10的详细解释如下：

步骤1，S-CSCF收到用户发送的INVITE消息，该消息中携带主叫***业务的PSI，此时根据业务过滤规则，S-CSCF调用业务控制点OSA GW/AS。

步骤2，S-CSCF向OSA GW/AS转发该INVITE消息，以请求调用主叫***业务。

步骤3，OSA GW/AS调用主叫***业务，进行收号交互后，向S-CSCF发送INVITE消息，其中携带业务交互指示，具体形式如上面采用application/servind+xml的SIP消息体携带的方式。

步骤4，用户通过主叫***业务拨打了会议PSI，因此S-CSCF将INVITE消息转发至提供会议业务的业务控制点TAS上。

步骤5，TAS根据业务交互指示得知会议业务被禁止，因此不调用会议业务。

此例子对应业务控制点调用控制中的继续调用业务控制点的处理，在上面的例子中第一业务处理节点为OSA GW/AS，第二业务处理节点为TAS，由TAS根据业务交互指示来决定是否调用会议业务。

图11中说明了另外一个关于业务交互指示的例子，其中业务触发点为Service Broker，业务控制点为TAS，其中用户A签约了彩铃业务以及呼叫等待业务，TAS为该用户A提供所述业务。图11的详细解释如下：

步骤1，Service Broker收到会议服务器发送至用户A的INVITE消息，该消息中Contact头域携带isfocus指示，表示该呼叫为会议呼叫。

步骤2，Service Broker根据业务识别规则或本地程序识别出会议业务被调用，即此时Service Broker得到会议业务的业务调用信息。Service Broker检查业务冲突禁止规则，发现存在如下描述：

<Service>Conference</Service>

<TargetService>CallWaiting</TargetService>

</ConflictDescription>

</ServiceConflictDescription>

此时Service Broker本地还有业务过滤规则描述如下：

<SPT>

<Method>INVITE</Method>

</SPT>

<SPT>

</SPT>

</TriggerPoint>

<ServerName>sip:TAS.home1.net；service＝CRBT，sip:TAS.home1.net；service＝

CW</ServerName>

</ApplicationServer>

</FilterCriteria>

上述过滤规则的匹配条件为被叫用户收到INVITE消息，而其中的服务器地址描述部分的ServerName属性取值为sip:TAS.home1.net；service＝CRBT，sip:TAS.home1.net；service＝CW，其中包括两条服务器地址描述，而其中的service参数表示指示TAS调用的业务分别为彩铃业务以及呼叫等待业务。

根据前面所述的业务冲突禁止规则，Service Broker发现将调用的业务控制点TAS上的呼叫等待业务与会议呼叫冲突，因此禁止呼叫等待业务的调用，具体表现为删除呼叫等待业务对应的SIP URI。

步骤3，Service Broker向业务控制点TAS发送INVITE消息，其中携带修改后的业务交互指示，具体为：

INVITE sip:[email protected] SIP/2.0

Route:<sip:TAS.home1.net；service＝CRBT>

即上面的Route头域仅保留了CRBT业务对应的SIP URI，且通过其中的service参数，Service Broker指示TAS调用彩铃业务，即业务交互指示通过该SIP URI体现出来。

步骤4，业务控制点TAS根据上述的业务交互指示仅调用彩铃业务，而不调用呼叫等待业务。

此例子对应业务控制点调用控制中的继续调用业务控制点的处理，上面的例子中的步骤3、4中第一业务处理节点为Service Broker，第二业务处理节点为TAS，是否调用呼叫等待业务由Service Broker决定。

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

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

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

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

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

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

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

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

业务控制点调用业务以后向业务触发点传递业务调用信息，所述传递方式可以是直接传递也可以是通过中间节点传递，业务触发点根据所述业务调用信息以及业务过滤规则进行后续的业务控制点的调用。对应的实施例如下：

用户A先使用了因特网电视(IPTV)业务，其后用户B呼叫用户A请求通话，此时业务触发点触发IPTV主叫号码显示业务，在IPTV媒体流中***主叫号码的文本或者图形显示给用户终端。

具体的实施过程如图12所示，在此例中业务控制点为IPTV AS，它是第一业务处理节点，业务触发点为Service Broker，它是第二业务处理节点，用户业务数据存储点以及业务规则数据库均为HSS，此实施例中根据IPTV业务初始的调用方式分为两类进行说明，具体的步骤如下：

用户通过SIP消息调用IPTV业务：

这种情况下用户A通过Service Broker调用IMS-based IPTV业务，IPTV AS直接向Service Broker发送业务调用信息，详细的过程为：

步骤1a，为用户A服务的Service Broker收到所述用户发送的INVITE消息，其中包含IPTV节目URI。

步骤2a，Service Broker根据业务过滤规则将该INVITE消息触发至IPTVAS，这里的业务过滤规则为Service Broker在此之前通过HSS的Sh接口获取的业务过滤规则。

步骤3a，IPTV AS调用IPTV业务后，在回送给Service Broker的200 OK响应消息中携带业务调用信息，例如

SIP/2.0 200 OK

……

P-Service-History:service-id＝IPTV

其后的IPTV业务交互流程略去。

步骤4a，Service Broker记录下用户A使用IPTV业务的业务调用信息。

步骤5a，Service Broker收到用户B发送到用户A的INVITE消息，该消息请求与用户A建立通话。

步骤6a，Service Broker根据业务调用信息以及用户的业务过滤规则进行检查，此时用户的业务过滤规则中有如下数据：

<FilterName>IPTVCALLERID<FilterName>

<SPT>

<Method>INVITE</Method>

</SPT>

<SPT>

<Origination>DifferentCommunication</Origination>

</SPT>

</TriggerPoint>

<ServerName>sip:[email protected]</ServerName>

</ApplicationServer>

</FilterCriteria>

上面的过滤规则中触发条件部分存在两个SPT描述，两个描述同属一个组，表示其中的触发条件为与的关系，第一个SPT描述中的触发条件为收到SIP INVITE消息(对应Method属性取值INVITE)；第二个SPT描述中使用了ServiceId属性，其取值为IPTV，另外还使用了Origination属性，取值为DifferentCommunication，表示该SPT条件为用户在跟当前通信不同的通信中调用了业务标识为IPTV的业务。

因Service Broker已经记录下用户A使用IPTV业务的业务调用信息，并且Service Broker当前收到了INVITE消息，所以该过滤规则的条件满足，Service Broker将当前通信触发至过滤规则中描述的IPTV AS的地址。

步骤7a，Service Broker向IPTV AS发送INVITE消息，以调用IPTV主叫号码显示业务。

用户通过实时流协议(RTSP，Real-Time Streaming Protocol)消息调用IPTV业务：

这种情况下用户A直接通过RTSP协议调用非IMS-based IPTV业务，IPTVAS向HSS发送业务调用信息，Service Broker之前通过Sh接口向HSS订阅了业务调用信息数据，HSS由此向Service Broker推送该业务调用信息，详细的过程为：

步骤1b，用户A直接向IPTV AS发送RTSP DESCRIBE消息，请求IPTV节目的媒体编解码描述信息。

步骤2b，IPTV向用户回送200 OK，携带IPTV节目的媒体编解码描述信息。

步骤3b，IPTV AS通过Sh接口的配置更新请求(PUR，Profile-Update-Request)消息向HSS传递用户A的业务调用信息。

步骤4b，HSS向IPTV AS回应配置更新响应(PUA，Profile-Update-Answer)消息。

步骤5b，因为Service Broker已经向HSS订阅了业务调用信息，因此HSS向Service Broker发送推送通知请求(PNR，Push-Notification-Request)消息，传递用户A的业务调用信息。

步骤6b，Service Broker记录下HSS发送的PNR消息中的业务调用信息，即记录下用户A已经调用了IPTV的业务调用信息。

步骤7b，Service Broker向HSS回送发送推送通知确认消息(PNA，Push-Notifcation-Answer)消息。

步骤8b，Service Broker收到用户B发送到用户A的INVITE消息，该消息请求与用户A建立通话。

步骤9b，Service Broker根据业务调用信息以及用户的业务过滤规则进行检查，此时用户的业务过滤规则中存在如前面所述的用户通过SIP消息调用IPTV业务中的例子的描述。

步骤10b，Service Broker向IPTV AS发送INVITE消息，以调用IPTV主叫号码显示业务。

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

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

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

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

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

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

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

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

然后通过消息构造单元将产生的业务触发信息封装到所述通信消息的消息体或头域中；随后通过所述业务触发信息传输单元通过所述通信消息将所述业务触发信息发送出去。所述业务触发信息可以是直接发送至第二业务处理节点的，也可以是通过中间节点传输的，例如第一业务处理节点先将其发送至业务数据存储点，业务数据存储点向第二业务处理节点发送业务触发信息或者第二业务处理节点主动从所述业务数据存储点中获取所述业务触发信息。

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

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

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

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

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

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

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

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

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

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

所述第二业务处理节点通过业务处理控制单元根据所述业务触发信息，继续调用业务控制点或阻止后续业务控制点的调用。例如当业务触发信息为业务交互指示时，所述第二业务处理节点根据业务触发信息中的业务交互指示或进一步根据业务交互处理规则判断特定业务是否允许调用，进行后续的业务调用控制。

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

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

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

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

Claims

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

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

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

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

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

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

第一业务处理节点通过通信消息携带所述业务触发信息，并将所述通信消息发送给所述第二业务处理节点；或，

第一业务处理节点将所述业务触发信息传递至业务数据存储点，第二业务处理节点从所述业务数据存储点获取所述业务触发信息。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

13.如权利要求7所述的方法，其特征在于，所述业务交互指示包括如下信息中至少一种：指定方业务标识、指定方用户属性/标记、指定方业务属性/标记、指定方业务能力、允许调用业务的描述、禁止调用业务的描述。

14.如权利要求13所述的方法，其特征在于，所述允许调用业务的描述包括如下信息中至少一种：允许调用的业务标识、允许调用的业务的主被叫标记、后续业务允许调用标记。

15.如权利要求13所述的方法，其特征在于，所述禁止调用业务的描述包括如下信息中至少一种：禁止调用的业务标识、禁止调用的业务的主被叫标记、后续业务禁止调用标记。

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

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

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

18.如权利要求17所述的方法，其特征在于，当所述业务调用信息基于SIP协议传递时，包括如下传递方式中的至少一种：通过Via头域传递；通过Record-Route头域传递；通过History-Info头域传递；通过业务调用信息头域传递；通过业务调用信息消息体传递；通过业务信息头域传递；通过业务信息消息体传递。

19.如权利要求17所述的方法，其特征在于，当所述业务过滤规则基于SIP协议传递时，包括如下传递方式中的至少一种：通过业务过滤规则消息体传递；通过业务信息消息体传递。

20.如权利要求17所述的方法，其特征在于，当所述业务调用结果基于SIP协议传递时，包括如下传递方式中的至少一种：通过Via头域传递；通过Record-Route头域传递；通过History-Info头域传递；通过SIP消息业务调用结果头域传递；通过SIP消息业务调用结果消息体传递；通过业务信息头域传递；通过业务信息消息体传递。

21.如权利要求17所述的方法，其特征在于，当所述业务交互指示通过SIP协议传递时，包括如下传递方式中的至少一种：通过Via头域传递；通过Record-Route头域传递；通过SIP消息Route头域传递；通过SIP消息History-Info头域传递；通过SIP消息业务交互指示头域传递；通过SIP消息业务交互指示消息体传递；通过业务信息头域传递；通过业务信息消息体传递。

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

23.如权利要求22所述的方法，其特征在于，所述业务规则包括如下规则中的至少一个：业务冲突禁止规则；业务交互处理规则；业务过滤规则；业务信令修正规则；业务分发规则。

24.如权利要求23所述的方法，其特征在于，所述业务冲突禁止规则包括如下元素中的至少一个：指定业务的标识；指定业务的主被叫方标记；与指定业务有冲突的业务标识；与指定业务有冲突的业务的主被叫方标记。

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

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

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

指定方业务标识；指定方业务的主被叫标记；指定消息/事件描述；修正方向描述；信令修正方式。

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

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

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

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

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

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

33.一种业务交互处理***，其特征在于，包括：

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

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

所述第二业务处理节点获取所述第一业务处理节点产生的业务触发信息，并根据所述业务触发信息进行相应的业务处理控制。

34.如权利要求33所述的***，其特征在于，

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

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

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

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

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

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

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

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

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

所述业务触发信息传输单元，用于通过所述通信消息将所述业务触发信息发送出去。

38.如权利要求37所述的***，其特征在于，所述通信消息包括：

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

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

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

40.如权利要求33所述的***，其特征在于，所述第二业务处理节点包括：业务触发信息获取单元和业务处理控制单元；

所述业务触发信息获取单元，用于获取所述第一业务处理节点产生的业务触发信息；

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

41.如权利要求40所述的***，其特征在于，所述第二业务处理节点还包括：

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

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

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

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

44.如权利要求40或43所述的***，其特征在于，所述业务处理控制单元的业务处理控制包括：业务控制点调用控制和/或业务流程控制。

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

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

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

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