CN101106565A

CN101106565A - 具有增强的业务过滤规则的分组网络及其实现方法

Info

Publication number: CN101106565A
Application number: CNA2006101594197A
Authority: CN
Inventors: 吴桑; 施有铸
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2006-07-14
Filing date: 2006-09-21
Publication date: 2008-01-16
Anticipated expiration: 2026-09-21
Also published as: CN101106565B

Abstract

本发明提供了一种具有增强的业务过滤规则的分组网络，包括：业务过滤规则库，用于保存或产生用户的业务过滤规则；业务控制点，用于为用户提供业务；以及业务触发点，从业务过滤规则库获取业务过滤规则，并根据业务过滤规则决定当前处理的SIP通信是否需要触发到业务控制点或是否要进行本地处理，其中，业务过滤规则至少包括以下之一：SIP消息会话描述外的消息体、会话状态、SIP初始请求消息外的消息事件、时间、用户呈现信息、用户状态、业务调用消息、其它规则关联信息、虚拟应用服务器地址、过滤规则有效性、业务调用结果处理、业务标识、业务控制点调用禁止规则。本发明还提供了一种业务触发方法，用于实现分组网络的业务触发。

Description

具有增强的业务过滤规则的分组网络及其实现方法

技术领域

本发明涉及通信领域，更具体而言，涉及一种具有增强的业务过滤规则的分组网络及其实现方法。

背景技术

IMS(IP Multimedia Subsystem，IP多媒体子系统)是一个基于SIP(Session Initiation Protocol，会话初始化协议)的体系，它的会话层和业务层是分离的，IMS为业务的调用提供必要的方法，IMS中业务的提供包含以下三个基本步骤：

1)定义可能的业务或业务集合；

2)当用户定购/修改业务订购关系时，以初始过滤规则的形式创建用户专有的业务数据；以及

3)将到达的初始请求传递给应用服务器。

当用户从运营商处得到一个IMS订购关系时，运营商需要给他分配一个用户配置。用户配置至少包含一个私有的用户身份和单个业务配置，它被永久地存放在HSS(Home Subscriber Server，归属用户服务器)上。可以通过两种用户数据处理操作SAA(Server-Assignment-Answer)或者PPR(Push-Profile-Request)，将用户配置从HSS传送到为该用户分配的S-CSCF(Serving-CallSession Control Function，服务呼叫会话控制功能)上。

为了实现IMS中业务提供所涉及的业务触发，现有技术3GPPTS 29.228(IP Multimedia(IM)Subsystem Cx and Dx Interfaces；Signaling flows and message contents)中以及MSF(MultiServiceForum，多业务论坛)的文稿msf.2006.004(Implementation Agreementfor the ISC interface)中，分别给出了相应的技术方案，下面将结合附图1至8对此予以详细描述。

图1至图4示出了3GPP TS 29.228中定义的用户配置的总体结构。

图1示出了其中用户档案(User Profile)的结构，图2示出了其中业务档案(Service Profile)的结构，图3示出了其中初始过滤规则的结构，以及图4示出了其中业务点触发器(Service PointTrigger)的结构。

Service Point Trigger设置的是业务触发判断条件，可以包括以下类型：

Request-URI(Uniform resource identifier，统一资源标识)：标识该请求所指向的资源；

SIP Method：表示该SIP请求的类型；

SIP Header：包含与该请求相关的信息，一个SPT(Service pointTrigger，业务点触发器)可以基于任何SIP头域是否出现，或者基于任何SIP头域的内容；

Session Case：有三个可能的值，即起始、终止或终止未注册，指明过滤器是否应该被处理起始、终止或者终止未注册的终端用户的S-CSCF所使用；以及

Session Description：针对SIP方法内的任何SDP(SessionDescription Protocol，会话描述协议)字段内容。

图5示出了MSF中提出的R3架构ISC(IP multimedia ServiceControl，IP多媒体业务控制)接口。

如图5所示，在MSF的文稿msf.2006.004中提出了如下的业务架构：

S-CSC(Serving Call Session Controller，服务呼叫会话控制器)可以直接触发到业务层，业务层实体可以是开放业务接入网关、AS(Application Server，应用服务器)、以及与传统业务网络对接的业务逻辑网关。S-CSC也可以通过SB/SCIM(Service Broker，业务代理/Service Capability Interaction Manager，业务能力交互管理)将呼叫触发到业务层，SB/SCIM与S-CSC以及业务层实体间使用ISC接口，SB/SCIM与HSS间使用Sh接口来获取SCIM业务档案。

MSF SB/SCIM业务档案采用了类似3GPP(3rd GenerationPartnership Project，第三代移动通信标准化伙伴项目)业务档案的描述方式，图6至图8示出了MSF SB/SCIM业务档案的总体结构，其中，图6示出了SCIM业务档案的结构，图7示出了SCIM过滤规则的结构，以及图8示出了SCIM业务点触发器的结构。

从图6、7、8中可以看到MSF SB/SCIM中新增了两种SPT，它可以根据基本呼叫状态触发或者是根据日程触发，呼叫状态可以取值试呼、忙、无应答、挂机，日程根据RFC 2445可以取值FREE、BUSY、BUSY-UNAVAILABLE、BUSY-TENTATIVE，还可以取值UNOBTAINABLE。

目前业务触发点的触发主要依赖于它收到的SIP消息，而RFC3261 SIP:Session Initiation Protocol中定义的SIP消息格式为：

generic-message＝start-line

*message-header

CRLF

[message-body]

start-line＝Request-Line/Status-Line

Request-Line＝Method SP Request-URI SP SIP-Version CRLF

Status-Line＝SIP-Version SP Status-Code SP Reason-Phrase CRLF

然而，根据上述定义，在应用3GPP iFC(Initial Filter Criteria，初始过滤规则)过滤规则以及MSF SCIM过滤规则进行业务触发时，发现存在以下问题：

1、现有技术无法根据SIP消息体中除SDP信息(会话描述信息)以外的其它部分来触发业务；

2、现有技术可以根据SIP初始请求消息触发业务，SIP初始请求消息为RFC 3261中定义的起始行为SIP请求行的SIP消息且SIP初始请求消息是能创建信令路径的消息，例如INVITE、SUBSCRIBE等消息，iFC(初始过滤规则)指的就是对这些SIP初始请求消息(即SIP初始消息)的过滤规则，但现有技术无法根据SIP初始请求消息以外的SIP消息触发业务，如根据SIP后续请求消息(指SIP信令路径创建后的后续请求消息，例如BYE、ACK、CANCEL、PRACK、UPDATE消息等)、SIP响应消息触发业务，包括根据SIP后续请求方法、SIP后续请求消息中的消息头域、SIP后续请求消息中的消息体触发、状态码触发、SIP响应中的消息头域触发以及SIP响应中的消息体触发等。

因此现有标准中根据SIP消息的触发能力是不完备的，且上述问题也是有实际需求的，例如移动网络增强逻辑的客户化应用(CAMEL(Customised Applications for Mobile network EnhancedLogic，移动网络增强逻辑的客户化应用))用户通过IMS域发短消息，消息体中承载了短消息信令的SIP消息需要触发到业务控制点上以进行计费控制或者对虚拟专用网(VPN)被叫短号进行变换一类的处理。

3、MSF对于3GPP的过滤规则进行了扩展，引入了根据基本呼叫状态触发以及根据日程触发，但MSF定义的根据基本呼叫状态仅支持试呼、忙、无应答、挂机四种；

4、现有技术的触发机制不支持根据当前时间信息触发业务，而根据时间信息触发业务是一种比较重要的业务触发要求；

5、MSF的根据日程触发可以根据用户的状态触发，但它仅仅取了RFC 2445中定义的闲/忙时间类型(Free/Busy Time Type)，不能提供更加丰富的信息，且RFC 2445发布时间为1998年，时间已经比较久远了，显然它不能满足用户需要的更强和更个性化的业务触发能力要求；

6、现有技术的过滤规则对用户状态的支持不够，这里的用户状态是指与呼叫无关的状态，如注册状态(是否注册)、漫游状态(是否漫游)等，iFC中只支持“终止未注册(Terminating_Unregistered)”的用户状态，即只对被叫用户提供基于用户注册状态的过滤规则，不能支持对主叫用户提供基于用户注册状态的过滤规则，此外也不能根据用户漫游状态触发，而根据用户漫游状态触发业务是一种比较重要的业务触发要求；

7、不能指定业务调用消息，现有技术中，S-CSCF/MSF SB/SCIM等收到一个SIP请求消息，该SIP请求消息匹配一个业务过滤规则，只能将该SIP请求消息发向指定的应用服务器，即对指定应用服务器的业务调用消息就是该业务过滤规则的触发消息，而在实际应用中，业务过滤规则的触发消息和对指定应用服务器的调用消息可以不是同一种SIP消息，此外，如前所述，MSF SB/SCIM可以通过业务逻辑网关与传统业务网络对接，实际上，如果业务逻辑网关位于MSF SB/SCIM中，则MSF SB/SCIM和传统业务网络之间的交互接口将是传统业务网络支持的协议接口，如智能协议接口，即业务调用消息可以不是SIP协议，现有技术中，业务过滤规则不能支持对SIP协议以外的业务调用消息；

8、不能描述其它过滤规则，而一个业务过滤规则中引用另一个过滤规则也是一种比较重要的业务触发要求；

9、现有技术只能根据过滤规则转发消息到应用服务器而不能在触发条件匹配后指定特定的处理。例如现有技术不能主动获取业务触发数据；也无法实现带有流程性的触发判断，如触发被叫侧业务前先判断主叫用户是否在被叫用户的黑名单中；此外，如上如述，MSF SB/SCIM和传统业务网络之间直接交互时，无法实现发送非触发业务的消息到业务控制点，例如发送INAP的InitialDp消息到SCP；还无法实现根据过滤规则进行业务触发点和业务控制点的信令关系或信令消息修正的处理，修正信令关系例如发送消息结束与指定业务控制点的通信，修改信令消息例如屏蔽某些信令参数等；

10、现有技术中iFC和MSF的过滤规则总是有效，S-CSCF/MSFSB/SCIM得到过滤规则后，将总是执行，但实际上过滤规则可以只是“临时有效”，如当应用服务器在当前业务执行过程中，产生一个过滤规则，它可以只在当前呼叫处理过程中有效，呼叫释放，该过滤规则也将失效，现有技术不能支持过滤规则的有效性；

11、现有技术中对业务调用结果的处理仅支持继续处理或者终止会话，不支持更丰富的处理类型，如S-CSCF/MSF SB/SCIM依据过滤规则将SIP初始消息发送至应用服务器，如果由于某种原因(如网络临时故障)该应用服务器在规定时间内没有向S-CSCF/MSFSB/SCIM返回一个SIP消息，此时，可以重新调用一次该业务控制点；

12、现有iFC和MSF的业务过滤规则中均无法识别该业务过滤规则对应的业务，这样会导致一些问题如应用服务器收到触发业务的消息还要再次判断要调用的业务类型、会话中难以得知调用的业务从而对业务交互处理造成困难等；另外现有业务过滤规则中也无法将已经调用的业务种类做为规则匹配条件，而在业务交互处理中这也是一种重要的业务触发控制要求。

13、现有iFC和MSF的业务过滤规则中不支持对应用服务器调用的禁止规则，如当S-CSCF/MSF SB/SCIM根据一个SIP初始消息调用了一系列的应用服务器，该SIP初始消息的后续响应消息按现有技术也将按顺序全部经过所有已调用的应用服务器，但实际上，有些应用服务器对特定的响应消息，可能并不能被调用，现有技术无法满足这一要求。

因此现有技术的缺点可以总结如下：

1、不支持根据SIP消息消息体中除了SDP信息外的其它部分触发业务；

2、基本呼叫状态非常有限，仅有试呼、忙、无应答、挂机四种，状态划分不够细，例如无法区分通话后挂机还是通话前挂机；

3、不支持根据SIP初始请求消息外的SIP消息事件触发；

4、不能按时间触发；

5、MSF根据日程触发仅提供有限的根据用户信息触发能力，无法提供如根据用户所处场所触发等更多的触发方式；

6、不能根据用户状态触发；

7、不能指定业务调用消息；

8、不能引用其它过滤规则；

9、不能在触发条件匹配后指定特定的处理；

10、不支持业务过滤规则的有效性；

11、不支持对业务调用结果更丰富的处理方式；

12、不能识别业务过滤规则对应的业务且无法将业务种类做为规则匹配条件。

13、不支持对应用服务器调用的禁止规则。

因此，人们需要一种用于分组网络的业务触发解决方案，能够解决上述相关技术中的问题。

发明内容

本发明旨在提供本发明提供了一种具有增强的业务过滤规则的分组网络及其实现方法，业务触发点能够根据SIP消息会话描述外的消息体、SIP请求消息外的SIP消息事件、会话状态、时间段、用户呈现信息、用户状态、业务调用消息、其它规则关联信息、虚拟应用服务器地址、过滤规则有效性、业务调用结果处理、业务标识、业务控制点调用禁止规则中的一种或者多种将当前处理的SIP通信触发到业务控制点或进行本地处理。

根据本发明的一个方面，提供了一种具有增强的业务过滤规则的分组网络，包括：业务过滤规则库，用于保存或产生用户的业务过滤规则；业务控制点，用于为用户提供业务；以及业务触发点，从业务过滤规则库获取业务过滤规则，并根据业务过滤规则决定当前处理的通信是否需要触发到业务控制点或是否要进行本地处理，其中，业务过滤规则至少包括以下之一：SIP消息会话描述外的消息体、会话状态、SIP初始请求消息外的消息事件、时间、用户呈现信息、用户状态、业务调用消息、其它规则关联信息、虚拟应用服务器地址、过滤规则有效性、业务调用结果处理、业务标识、业务控制点调用禁止规则。

根据本发明的另一方面，提供了一种业务触发方法，其包括以下步骤：业务触发点根据业务过滤规则决定当前处理的通信是否需要触发到业务控制点或是否要进行本地处理，其中，业务过滤规则至少包括以下之一：SIP消息会话描述外的消息体、会话状态、SIP初始请求消息外的消息事件、时间、用户呈现信息、用户状态、业务调用消息、其它规则关联信息、虚拟应用服务器地址、过滤规则有效性、业务调用结果处理、业务标识、业务控制点调用禁止规则。

需要说明的是，现有技术中SIP Method业务点触发器表面上可以根据所有的SIP方法触发业务，但S-CSCF在会话信令路径建立后SIP路由集就固定下来了，这样如果有业务需要在会话信令路径建立以后触发，例如根据BYE消息触发，应用层服务器因为无法加入到已经建立的SIP路由集从而导致实际上S-CSCF不能支持任意SIP请求消息的触发，实际上它只能支持对INVITE、MESSAGE、SUBSCRIBE等作为会话发起请求、用于请求建立会话信令路径的SIP方法的触发。本发明中对业务触发点有特殊的要求，业务触发点可以修改会话信令路径，可以支持所有类型的SIP消息包括SIP请求消息、SIP响应消息以及本发明中所述的所有会话状态触发，即SIP Method业务点触发器在本发明中可以根据所有的SIP方法(Method)触发业务。

通过上述技术方案，本发明实现了如下技术效果：

本发明提供了一种增强的业务触发机制，业务触发点可以根据SIP消息会话描述外的消息体、SIP初始请求消息外的SIP消息事件、会话状态、时间、用户呈现信息、用户状态、业务调用消息、其它规则关联信息、虚拟应用服务器地址、过滤规则有效性、业务调用结果处理、业务标识、业务控制点调用禁止规则将当前处理的SIP通信触发到业务控制点或进行本地处理，从而提高了触发的有效性，减轻了业务控制点的负荷。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1示出了3GPP TS 29.228中定义的用户配置的用户档案的结构；

图2示出了3GPP TS 29.228中定义的用户配置的业务档案的结构；

图3示出了3GPP TS 29.228中定义的用户配置的初始过滤规则的结构；

图4示出了3GPP TS 29.228中定义的用户配置的业务点触发器的结构；

图5示出了MSF中提出的R3架构ISC接口；

图6示出了SCIM业务档案的结构；

图7示出了SCIM过滤规则的结构；

图8示出了SCIM业务点触发器的结构；

图9示出了根据本发明的一种典型分组网络的网络逻辑结构图；

图10示出了根据本发明的一种典型的业务触发流程的流程图；以及

图11示出了根据本发明的业务触发流程的流程图。

具体实施方式

下面将参考附图并结合实施例，来详细说明本发明。

图9示出了根据本发明的一种典型分组网络的网络逻辑结构图。

本发明提出，在业务触发机制中，如图9所示，分组网络900的网络逻辑包括业务过滤规则库902、业务控制点904、和业务触发点906。

其中：

1、业务过滤规则库902保存或产生用户的业务过滤规则，可以存在一个或一个以上的业务过滤规则库，它可以是一个独立的用户签约数据库，如HSS，业务过滤规则作为用户签约数据存放其中，业务过滤规则库也可以位于业务控制点中，如业务控制点在业务处理过程中产生业务过滤规则，业务过滤规则库也可以位于业务触发点中，如业务过滤规则作为一段程序或配置数据存在于业务触发点中；

2、业务触发点906提供与业务控制点904交互的能力，它根据业务过滤规则决定当前处理的通信是否需要触发到业务控制点或是否要进行本地处理，业务触发点与业务控制点之间存在E3接口，该接口协议可以采用但不限于SIP协议、智能网应用规程协议(INAP，Intelligent Network Application Protocol)、CAMEL(Customized Applications for Mobile network Enhanced Logic，移动网增强逻辑的用户应用)应用部分协议、移动应用部分协议(MAP，Mobile Application Part)、开放业务接入应用程序接口协议(OSAAPI，Open Service Access Application Program Interface)、以及内部接口协议等；

3、业务触发点与业务过滤规则库之间存在E2接口，该接口可以采用但不限于Diameter协议(如业务过滤规则库位于HSS时)、SIP协议(如业务过滤规则库位于业务控制点时)、通用用户档案协议(GUP，Generic User Profile)、MAP协议、以及内部接口协议等，业务触发点可以通过E2接口从业务过滤规则库获得用户业务过滤规则，业务触发点可以是S-CSCF或Service Broker(业务代理)或SCIM AS或软交换等；

4、业务控制点是提供业务的功能实体，一个业务控制点可以提供一个或者多个业务。业务控制点和业务过滤规则库之间存在E1接口，该接口可以采用但不限于Diameter协议(如业务过滤规则库位于HSS时)等，业务控制点通过该接口可以更新业务过滤规则库上的业务过滤规则。业务控制点可以是IMS中的SIP AS、OSA SCS(Open Service Access-Service Capability Server，开放业务接入-业务能力服务器)、IM-S SF(IP Multimedia Service Switching Function，IP多媒体业务交换功能)、智能网SCF(Service Control Function，业务控制功能)等。

简言之，分组网络900包括：

业务过滤规则库902，用于保存或产生用户的业务过滤规则；

业务控制点904，用于为用户提供业务；以及

业务触发点906，从业务过滤规则库获取业务过滤规则，并根据该业务过滤规则决定当前处理的通信是否需要触发到业务控制点或是否要进行本地处理，其中，过滤规则至少包括以下之一：SIP消息会话描述外的消息体、会话状态、SIP初始请求消息外的SIP消息事件、时间、用户呈现信息、用户状态、业务调用消息、其它规则关联信息、虚拟应用服务器地址、业务过滤规则有效性、业务调用结果处理、业务标识、业务控制点调用禁止规则。

根据图9所示的本发明的典型分组网络逻辑结构，本发明中提出了一种典型的业务触发流程。

图10示出了根据本发明的一种典型的业务触发流程的流程图，其包括以下步骤：

上述流程解释如下：

步骤S1002：业务触发点收到终端的注册请求；

步骤S1004-S1006：业务触发点向发送注册消息的用户所在的业务过滤规则库请求下载用户业务过滤规则，业务过滤规则库响应并发送用户的业务过滤规则，所述业务过滤规则为本发明中增强的业务过滤规则。该流程对应的例子如当业务触发点是ServiceBroker，业务过滤规则库是HSS，两者间的通讯接口采用3GPP Sh接口的时候：所述的下载请求为Diameter协议用户数据请求(User-Data-Request)消息，其中携带用户标识属性-值对(User-Identity AVP)以及数据参考属性-值对(Data-Reference AVP)以及业务指示属性-值对(Service-Indication AVP)，其中使用User-Identity AVP用于定位某一个用户的数据，Data-Reference AVP取值透明数据(RepositoryData)表示所请求的数据位于HSS的用户透明数据区，Service-Indication AVP取值为业务过滤规则对应的特定的透明数据标识；所述的下载响应为Diameter协议用户数据响应(User-Data-Answer)消息，其中携带用户数据属性-值对(User-Data AVP)，其中的数据为业务触发点请求的该用户的增强的业务过滤规则。具体来说，增强的业务过滤规则包括：根据SIP消息会话描述外的消息体、SIP初始请求消息外的SIP消息事件、会话状态、时间、用户呈现信息、用户状态、业务调用消息、其它规则关联信息、虚拟应用服务器地址、业务过滤规则有效性、业务调用结果处理、业务标识、业务控制点调用禁止规则等触发，稍后本文将针对所述增强的业务过滤规则一一描述；

步骤S1008-S1010：业务触发点保存收到的用户业务过滤规则并向终端发送响应；

步骤S1012：终端发送SIP邀请(SIP INVITE)消息；以及

步骤S1014-S1016：业务触发点根据该用户的增强的业务过滤规则进行触发的判断，所述的增强的业务过滤规则包括根据SIP消息会话描述外的消息体、SIP初始请求消息外的SIP消息事件、会话状态、时间、用户呈现信息、用户状态、业务调用消息、其它规则关联信息、虚拟应用服务器地址、业务过滤规则有效性、业务调用结果处理、业务标识、业务控制点调用禁止规则触发，当触发条件满足的时候如果所述的业务过滤规则描述的服务器地址为业务控制点的地址，业务触发点向业务过滤规则中指定的业务控制点发送INVITE消息以请求调用业务；如果所述的业务过滤规则描述的服务器地址为虚拟服务器地址，业务触发点调用虚拟服务器地址对应的本地处理。

上述过程简言之，如图11所示，包括以下步骤：

步骤S1102，业务触发点从业务过滤规则库获取业务过滤规则；以及

步骤S1104，业务触发点根据该业务过滤规则决定当前处理的通信是否需要触发到业务控制点或是否要进行本地处理，其中，过滤规则至少包括以下之一：SIP消息会话描述外的消息体、会话状态、SIP初始请求消息外的SIP消息事件、时间、用户呈现信息、用户状态、业务调用消息、其它规则关联指示、虚拟应用服务器地址、业务过滤规则有效性、业务调用结果处理、业务标识、业务控制点调用禁止规则。

此外，在业务处理过程中，业务控制点也可以直接向业务触发点发送业务过滤规则，或者通过用户签约数据库间接向业务触发点发送业务过滤规则，业务触发点可以据此进行后续的相应处理，业务触发点可以在收到该业务过滤规则后立即匹配处理，也可以先保存并在收到后续的SIP消息再匹配处理。一般的，和来自用户签约数据库获取的业务过滤规则不同，来自业务控制点的业务过滤规则只在当前通信中有效，当前通信结束后，业务触发点可以删除此前记录的来自业务控制点的业务过滤规则，即这是一种“临时”业务过滤规则。显然，在一次通信处理过程中，业务触发点可以获得来自不同场所如HSS、业务控制点的业务过滤规则。

如前所述，本发明要提供的是一种增强的业务触发实现方法，其中，提出了一种增强的业务过滤规则，该增强的业务过滤规则可以解决现有技术中的问题。

1、根据SIP消息会话描述外的消息体触发业务

如上所述，现有技术存在问题1，不支持根据SIP消息消息体中除了SDP信息外的其它部分触发业务。即，根据SIP消息会话描述外的消息体触发是3GPP以及MSF现有标准中不支持的。为了解决这个问题，本发明在业务过滤规则中引入SIP消息会话描述外的消息体元素，其值包括消息体类型和/或消息体内容，其中消息体内容可以是文本编码格式或二进制编码格式，具体的，本发明定义了新的SIP消息体业务点触发器(SIP Body SPT)类型：

定义该SPT包含消息体类型(Message Body Type)以及消息体内容(Message Body Content)元素，其中Message Body Type对应SIP消息中内容类型(Content-Type)的取值，按照RFC 3261中的定义它表示指定消息体的媒体类型；Message Body Content表示Content-Type指示的消息体的内容，一般的，消息体类型采用MIME(Multipurpose Internet Mail Extensions，多用途网络邮件扩展)媒体类型(media type)，对应的，消息体内容即为MIME体(MIMEbody)。

Message Body Content中又包括实体标签(Body Tag)以及实体内容(Body Content)两类元素。其中Body Tag表示上述消息体内容中包含的单元数据的标签名或标签值，消息体内容采用文本编码方式下它可以对应某个元素的标签名，例如消息体内容采用可扩展标记语言(XML)编码方式下的它对应XML元素的标签名；消息体内容采用二进制编码方式下它可以对应消息体内容中包含的数据单元的标签值，例如封装ISUP(Integrated Services DigitalNetwork User Par，综合业务数字网用户部分)的SIP(SIP-I)消息中的消息类型编码(Message Type Code)值或者参数名编码(Parameter Name Code)值。Body Content对应所述Body Tag标记的标签对应的数据单元内容，例如SIP-I方式下Body Content可以对应Body Tag标记的参数名编码对应的参数内容(ParameterContent)。SIP Body SPT中Message Body Type是必备的，用于识别不同的内容类型，SIP Body SPT中可以带0到多个Message BodyContent。以上元素均可采用但不限于使用正则表达式的形式指示进行部分匹配或者精确匹配。

上述SIP Body SPT定义采用表格形式描述为：

表1

Data type	Tag	Compound of
		Compound of			Tag	Type	Cardinality
		tSIPBody	SIPBody	MessageBodyType	Tag	Type	Cardinality	tString	1
MessageBodyContent	tMessageBodyContent			MessageBodyType	(0 ton)			tString	1
MessageBodyContent	tMessageBodyContent			tMessageBodyContent	(0 ton)	MessageBodyContent	BodyTag	tString	1
BodyContent	tString	1					BodyTag	tString	1

以上仅为了说明业务触发点可以根据SIP消息message-body内容触发，实际的SPT定义方式可以是不限于上述方式，本发明中其它的SPT也是类似的，后面不再一一说明。

下面针对message-body采用文本编码以及二进制编码两种方式，具体对根据SIP消息会话描述外的消息体触发的SPT描述进行说明。

实施例1：主叫用户为IMS预付费用户，该用户发送的短消息采用XML方式封装到SIP MESSAGE消息的消息体中，业务触发点收到该用户的SIP MESSAGE消息发现消息体中携带的短消息消息类型指示为请求递交的时候将当前会话触发到业务控制点。

短消息采用XML封装到SIP MESSAGE消息的消息体中的方式如下：

MESSAGE sip:receiver@example.com，SIP/2.0

Content-Type:multipart/related；type＝″application/message+xml″；

start＝″<nXYxAE@pres.vancouver.example.com>″；

boundary＝″＝_005A0428C1257165_＝″

--＝_005A0428C1257165_＝

Content-Type:application/message+xml

Content-ID:<nXYxAE@pres.vancouver.example.com>

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

<message-type-indicator> message submit request

</message-type-indicator>

<message-class>personal</message-class>

<delivery-report>Yes</delivery-report>

<read-reply>Yes</read-reply>

<content>This is a test message！</content>

</message>

这种情况下对应的根据SIP消息会话描述外的消息体触发SPT描述为：

<SPT>

<MessageBodyType>application/message+xml</MessageBodyType

>

<BodyTag>message-type-indicator</BodyTag>

<BodyContent>message submit

request</BodyContent>

</MessageBodyContent>

</SIPBody>

</SPT>

其中MessageBodyType取值application/message+xml表示用户的短消息采用的是XML封装的方式，业务触发点匹配的字段是SIP消息中的Content-Type中包含application/message+xml的情况；BodyTag取值message-type-indicator，BodyContent取值messagesubmit request表示业务触发点需要匹配application/message+xml方式封装的SIP消息体中的XML标签为message-type-indicator取值为message submit request的内容。

实施例2：当一个IMS VPN用户发短信，该短信消息采用短消息业务转发层(SMS TL)封装的方式放到SIP消息的message-body中，业务触发点将该SIP通信触发到业务控制点，业务控制点对短信进行进一步的处理，例如当短信中的被叫号码为一个VPN短号的时候翻译该号码。

SMS TL层封装的方式可以参见欧洲电信标准协会(ETSI(European Telecommunications Standards Institute，欧洲电信标准协会))发布的标准文档DES/AT-030036，例如：

MESSAGE sip:1234567890@domain SIP/2.0

From:

<sip:098765432 1@domain>；tag＝c0a80103-13c4-7e84-1ee41f1-223

9

To:<sip:1234567890@domain>

Call-ID:

247fc650-c0a80103-13c4-7e84-1ee41f1-4883@192.168.1.3

CSeq:1 MESSAGE

Via:SIP/2.0/UDP

192.168.1.3:5060；branch＝z9hG4bK-7e84-1ee41f1-207e

Content-Encoding:base64

Max-Forwards:70

Content-Type:application/vnd.3gpp.sms-tl

Content-Length:32

EQMKgWBmhABAAACnDNTynA5ql+fz8LkM

上诉例子中封装了一条TL递交短消息(SMS-SUBMIT)消息，消息中携带文本″Test message″。

<SPT>

<MessageBodyType>application/vnd.3gpp.sms-tl</MessageBodyType>

<BodyTag>TL-SMS-SUBMIT</BodyTag>

</MessageBodyContent>

</SIPBody>

</SPT>

上述SPT表示业务触发点匹配条件为采用DES/AT-030036中application/vnd.3gpp.sms-tl封装方式且SIP消息内容部分的短消息转发层(SM-TL)的协议数据单元(PDU(Protocol Data Unit，协议数据单元))类型为SMS-SUBMIT。

这类二进制封装方式下的SPT描述对业务触发点有要求，需要它理解实体标签(Body Tag)的含义，并据此查找解析的二进制内容中对应的数据单元。

这里的SPT描述仅为了说明业务触发点可以根据二进制方式封装的SIP消息体内容来触发，实际的SPT描述方式可以不限于此。

2、根据业务触发点的会话状态触发业务

如上所述，现有技术存在问题2，基本呼叫状态非常有限。即，MSF目前支持试呼、忙、无应答、挂机4种基本会话状态，对于实际的应用这4种状态是不够的。为此考虑对MSF定义的基本呼叫状态进行扩展，3GPP TS 23.278中定义了一套IM-SSF使用的检测点(DP)状态模型。本发明提出了，业务触发点的状态模型可以借鉴3GPP TS 23.278中的定义以支持更完整的会话状态触发能力。

为此定义会话状态业务点触发器(Session State SPT)，业务触发点Session State SPT支持的会话状态包括：

收集信息、分析信息、路由选择失败、发端_忙、发端_无应答、发端_应答、发端_拆线、发端_放弃、终端试呼鉴权、终端_忙、终端_无应答、终端_应答、终端_拆线、终端_放弃

当然，也可以根据需要将其中的某些会话状态进行合并定义，或者根据需要再扩展新的会话状态定义。

其中，上述的“终端_忙”即可以是会话到达用户终端，用户终端返回的“忙”状态，也可以是会话未到达用户终端，网络判断出的“忙”状态(NDUB，Network Determined User Busy，网络决定用户忙)，NDUB进一步还包括网络决定用户接近忙(ApproachingNetwork Determined User Busy)，因此，即可以定义一个“终端忙”来表示上述的用户终端返回忙和NDUB，也可以分别定义两个会话状态“终端_忙_用户终端返回”和“终端_忙_网络决定”来分别表示上述两种情况，而“终端_忙_网络决定”还可以进一步的细分定义一个“终端_接近忙_网络决定”的会话状态。类似的，“发端_忙”同样可以相应的细化定义，如“发端_接近_忙”。

上述DP点完全照搬3GPP TS 23.278，具体每个DP点的定义参照3GPP TS 23.278。

上述Session State SPT定义采用表格形式描述为：

表2

Data type	Tag	Base type	Comments
Data type	Tag	Base type	Comments	tSessionState	SessionState	enumerated	Possible values:2(collectedInfo)3(analyzedInformation)4(routeSelectFailure)5(oCalledPartyBusy)6(oNoAnswer)7(oAnswer)9(oDisconnect)10(oAbandon)12(termAttemptAuthorized)13(tBusy)14(tNoAnswer)15(tAnswer)17(tDisconnect)18(tAbandon)

由于IM-SSF根据DP点触发已经是一种标准，所以下面不一一对上述会话状态举例证明其有效性，业务触发点根据会话状态触发的实施例如下：

实施例3：主叫用户有自动重复试呼业务，当到被叫的会话路由失败的时候业务触发点将会话触发到业务控制点上

对应的会话状态SPT为：

<SPT>

</SPT>

上述SessionState标签表示要求业务触发点匹配会话状态，SessionState标签后的取值4表示匹配的条件为业务触发点上的会话状态为路由选择失败。

3、根据SIP初始请求消息外的SIP消息事件触发业务

如上所述，现有技术存在问题3，不支持根据SIP初始请求消息外的SIP消息事件触发业务，包括不能根据SIP后续请求消息触发、不能根据SIP响应消息触发。

现有技术中SIP Method业务点触发器表面上可以根据所有的SIP方法触发业务，但S-CSCF在会话信令路径建立后SIP路由集就固定下来了，这样如果有业务需要在会话信令路径建立以后触发，例如根据BYE、ACK、CANCEL、PRACK、UPDATE等消息触发，应用层服务器因为无法加入到已经建立的SIP路由集从而导致实际上S-CSCF不能支持任意SIP请求消息的触发，实际上它只能支持对INVITE、MES SAGE、SUBSCRIBE等作为会话发起请求、用于请求建立会话信令路径的SIP方法的触发。本发明中扩展了业务触发点的功能，使其可以修改会话信令路径，即SIP初始请求消息之后的响应消息和后续SIP请求消息的信令路径可以不同于SIP初始请求消息建立的信令路径，可以支持所有类型的SIP消息包括SIP请求消息、SIP响应消息以及本发明中所述的所有会话状态触发，即SIP Method业务点触发器在本发明中可以根据所有的SIP方法(Method)触发业务。

由于SIP Method业务点触发器现有技术中已经使用，下面以SIP响应消息为例描述本发明对SIP请求消息外的SIP消息事件触发业务的支持。

SIP响应消息的格式为：

Response-message＝Status-Line

*message-header

CRLF

[message-body]

Status-Line＝SIP-Version SP Status-Code SP Reason-Phrase CRLF

由于3GPP iFC机制目前已经支持根据消息头和SDP触发，而本发明前面也已经支持了根据除SDP外的其它形式的SIP消息内容触发，且初始过滤规则(iFC)描述本身已经支持多种SPT的组合，所以下面只需要考虑支持根据SIP消息Status-Code(状态码)触发，原因(Reason-Phrase)中是对Status-Code的简单文本描述，而且具体实现时SIP实体可以在Reason-Phrase中填充RFC 3261规定外的文本描述，可选地，支持Reason-Phrase。

可以为Status-Code定义一种SIP响应业务点触发器(SIPResponse SPT)，里面只包含SIPResponse一个元素，SIPResponse取值类型为string，SIPResponse可以取满足SIP协议的任意响应码的值，SIPResponse可以支持通配和/或多值描述，以满足某些情况下业务控制点需要对一类响应码进行处理的情况，通配和多值描述的表示方法可以采用正则表达式或者为了描述简单起见也可以采用如4XX，5XX的形式表示，其中4XX表示通配，只要SIP响应码为4系列的就认为SPT发生匹配，而用逗号连接4XX，5XX表示这是一个多值描述，只要逗号分隔的多个值之一发生了匹配就认为SPT发生了匹配。以上仅为了说明SIP Response SPT可以支持通配和/或多值描述，SPT的描述形式可以不限于上述形式。

上述SIP Response SPT定义采用表格形式描述为：

表3

Data type	Tag	Base type	Comments
Data type	Tag	Base type	Comments	tSIPResponse	SIPResponse	tString

业务触发点根据Status-Code触发举例如下：

实施例4：主叫用户有一种业务，在收到所有类型的会话失败时会话将触发至业务控制点进行进一步的处理，例如根据不同的响应码播放不同的语音通知

相应的SIP Response SPT表示方式为：

<SPT>

</SPT>

上述SPT中4XX，5XX，6XX表示只要业务触发点收到的SIP响应只要为4系列或者5系列或者6系列之一就匹配了本SPT。

根据上述方法，还可以对其它的SIP初始请求消息外的任何SIP消息进行匹配触发，这里不再赘述。

4、根据时间触发业务

如上所述，现有技术存在问题4，不能按时间触发业务。

实际的应用场景如用户有按时间免打扰业务，在00:00到06:00之间的休息时间不希望被打扰，在这段时间呼入的呼叫被接入到语音邮箱。

本发明提出，定义一种时间业务点触发器(Time SPT)：

表4

Data type	Tag	Base type	Comments
Data type	Tag	Base type	Comments	tTime	Time	tString

其中tTime可以采用字符串描述，时间的描述方式可以参照但不限于采用国际标准化组织(ISO)8601中的格式，时间信息可以包括年、月、日、时、分、秒中的一种或者多种，时间段中的起止时间可以采用但不限于用字符“/”进行分隔，例如20:00/24:00。

业务触发点根据时间触发举例如下：

实施例5：用户有按时间免打扰业务，在00:00到06:00之间的休息时间不希望被打扰，在这段时间呼入的呼叫被接入到语音邮箱

相应的Period SPT表示方式为：

<SPT>

</SPT>

上述SPT表示只要业务触发点当前时间落在00:00到06:00区间范围内就发生了Time SPT匹配。

5、根据用户呈现信息触发业务

如上所述，现有技术存在问题5，MSF根据日程触发仅提供有限的根据用户信息触发能力。相对而言，现在流行的PRESENCE规范能够提供更多用户相关的信息，例如可以提供用户所在的场所、用户当前进行的活动。本发明提出，根据用户的Presence信息触发业务能够提供更加强劲和更加个性化的业务触发能力。

根据用户呈现信息触发的应用场景如用户希望上班的时候可以接受任意的呼叫，但是到家以后激活来话筛选业务。所述用户呈现信息以及格式在因特网工程任务组(IETF)有定义，相关的主要标准有RFC 3863、因特网草案“RPID:Rich Presence Extensions tothe Presence Information Data Format”、因特网草案“CIPID:ContactInformation in Presence Information Data Format”、因特网草案“Timed Presence Extensions to the Presence Information Data Format(PIDF)to Indicate Status Information for Past and Future TimeIntervals”、因特网草案“Session Initiation Protocol(SIP)User AgentCapability Extension to Presence Information Data Format(PIDF)”，用户呈现信息还包括用户的位置信息，相关的主要标准有RFC 4119、因特网草案“GEOPRIV PIDF-LO Usage Clarification，Considerationsand Recommendations”、因特网草案“A Document Format forFiltering and Reporting Location Noticatiohs in the PresenceInformation Document Format Location Object(PIDF-LO)”、因特网草案“Revised Civic Location Format for PIDF-LO”。目前标准中多采用通过SIP消息的消息体部分携带XML方式描述的呈现信息，为了适应呈现信息数据的灵活性和扩展性，业务触发点的呈现业务点触发器(Presence SPT)借鉴SIP Body SPT的定义方式。

上述Presence SPT定义采用表格形式描述为：

表5

Data type	Tag	Compound of
		Compound of			Tag	Type	Cardinality
		tPresence	Presence	PresenceType	Tag	Type	Cardinality	tString	1
PresenceContent	tPresenceContent			PresenceType	(1 to n)			tString	1
PresenceContent	tPresenceContent			tPresenceContent	(1 to n)	PresenceContent	ElementTag	tString	1
ElementContent	tString	1					ElementTag	tString	1

其中呈现类型(PresenceType)对应可能的不同的SIP内容类型(SIP ContentType)。Presence SPT的描述形式可以不限于采用上述方式。

用户呈现信息的内容比较丰富，例如RFC 3863定义了设备状态(basic)；因特网草案“RPID:Rich Presence Extensions to thePresence Information Data Format”中定义了比较丰富的状态呈现信息类型，如用户活动(activities)、用户情绪(mood)、场所类型(place-type)、场所属性(place-is)、私密程度(privacy)、用户的当前状态和角色(sphere)；因特网草案“Session Initiation Protocol(SIP)User Agent Capability Extension to Presence Information DataFormat(PIDF)”中定义了设备的通信能力(偏好设置)。

下面针对业务触发点收到的呈现信息采用上述呈现信息数据格式的丰富呈现扩展(RPID)格式携带举例如下：

实施例6：用户希望在家的时候才激活来话筛选业务

业务触发点收到的携带用户呈现信息的SIP消息示例为：

NOTIFY sip:[5555::aaa:bbb:ccc:ddd]:1357；comp＝sigcomp SIP/2.0

Via:SIP/2.0/UDP ps.home2.net；branch＝z9hG4bK348923.1

......

Event:presence

Content-Type:application/pidf+xml

......

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

<presence xmlns＝″urn:ietf:params:xml:ns:pidf″

xmlns:xsi＝″http://www.w3.org/2001/XMLSchema-instance″

xmlns:dm＝″urn:ietf:params:xml:ns:pidf:data-model″

xmlns:rpid＝″urn:ietf:params:xml:ns:pidf:rpid″

xsi:schemaLocation＝″urn:ietf:params:xml:ns:pidfpidf.xsd

urn:ietf:params:xml:ns:pidf:data-model data-model.xsd

urn:ietf:params:xml:ns :pidf:rpid rpid.xsd″

entity＝″pres:someone@example.com″>

......

<rpid:place-type>

<rpid:residence/>

</rpid:place-type>

......

</presence>

其中<rpid:residence/>表示用户在住地，该住地可以是用户自己的居住场所也可以是其它人的家里。

相应的Presence SPT表示方式为:

<SPT>

<PresenceType>application/pidf+xml</PresenceType>

<ElementTag>rpid:residence/</ElementTag>

</PresenceContent>

</Presence>

</SPT>

上面的Presence SPT中成分标签(ElementTag)为rpid:residence/表示当业务触发点得到的呈现信息中包含XML标签rpid:residence/的时候就发生了Presence SPT的匹配。

上面的实施例中举的例子是根据用户当前场所触发，PresenceSPT还可以根据上述用户活动、用户情绪、场所属性、私密程度、用户的当前状态和角色、设备状态、设备通信能力触发，描述方式是类似的，这里不再一一列举了。

另外上面的实施例中呈现信息用IETF RPID的格式携带，呈现信息也可以不采用RPID的格式携带，如采用其它形式的文本格式或者二进制格式携带，此时可通过PresenceType来区分不同的呈现信息表示类型，呈现信息中不同的呈现类型通过ElementTag来区分。例如

业务触发点收到的携带用户呈现信息的SIP消息为：

NOTIFY sip:[5555::aaa:bbb:ccc:ddd]:1357；comp＝sigcomp SIP/2.0

Via:SIP/2.0/UDP ps.home2.net；branch＝z9hG4bK348923.1

......

Event:presence

Content-Type:application/presence+text

......

place-type:residence

相应的Presence SPT表示方式为：

<SPT>

<PresenceType>application/presence+text</PresenceType>

<ElementTag>place-type</ElementTag>

<ElementContent>residence</ElementContent>

</PresenceContent>

</Presence>

</SPT>

以上举例仅为了说明呈现信息可以使用非RPID格式描述，实际的描述格式可以不限于上述方式。

用户的呈现信息还包括用户的位置信息，下面再针对业务触发点根据用户的位置信息触发举例说明：

实施例7：用户为纽约百老汇某剧院的贵宾客户，当用户到剧院附近的时候可以享受呼叫费用的优惠，以吸引用户经常到剧院去

业务触发点收到的携带用户位置信息的SIP消息示例为：

NOTIFY sip:[5555::aaa:bbb:ccc:ddd]:1357；comp＝sigcomp SIP/2.0

Via:SIP/2.0/UDP ps.home2.net；branch＝z9hG4bK348923.1

......

Content-Type:application/pidf+xml

......

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

<presence xmlns＝″urn:ietf:params:xml:ns:pidf″

xmlns:gp＝″urn:ietf:params:xml:ns:pidf:geopriv10″

xmlns:cl＝″urn:ietf:params:xml:ns:pidf:geopriv 10:civicLoc″

entity＝″pres:geotarget@example.com″>

<gp:geopriv>

<gp:location-info>

<cl:civicAddress>

<cl:country>US</cl:country>

<cl:A1>New York</cl:A1>

<cl:A3>New York</cl:A3>

<cl:A6>Broadway</cl:A6>

<cl:HNO>123</cl:HNO>

<cl:LOC>Suite 75</cl:LOC>

<cl:PC>10027-0401</cl:PC>

</cl:civicAddress>

</gp:location-info>

</gp:geopriv>

</status>

</presence>

具体的Presence SPT描述实例为：

<SPT>

<PresenceType>application/pidf+xml</PresenceType>

<ElementContent>Broadway</ElementContent>

</PresenceContent>

</Presence>

</SPT>

上述Presence SPT中用户位置信息采用城市地址位置描述，其中cl:A3表示该位置对应的城市，cl:A6表示该位置对应的街区，cl:HNO表示该位置对应的门牌号。

上面的实施例中采用的是的城市地址方式描述的行政地理位置信息，Presence SPT也可以根据采用但不限于用经纬度方式描述的自然地理位置信息触发，也可以根据采用但不限于用终端接入网络的地理位置如接入设备编号、接入网络编号一类方式描述的网络地理位置信息触发，这里不再举例说明。

同实施例6类似，用户位置信息描述格式可以不限于RFC 4119中定义的方式，这里不再一一举例说明。

需要说明的是，地理位置信息是用户呈现信息中较特殊且重要的一种信息，因此也可以采用一个独立的位置业务点触发器Location SPT来描述地理位置信息。

6、根据用户状态触发业务

如上所述，现有技术存在问题6，不能根据用户漫游状态、起始未注册状态触发业务。根据用户漫游状态触发的例子，如用户在漫游的时候限制其它用户的呼入而不限制该用户的呼出，用户漫游状态的获得方式依赖于业务触发点的具体实现，实现方式可以采用但不限于如业务触发点根据SIP消息中的P-Visited-Network-ID头域中的拜访网络标识判断用户是否漫游。

为此定义一种漫游状态业务点触发器(Roaming State SPT):

表6

Data type	Tag	Base type	Comments
Data type	Tag	Base type	Comments	tRoamingState	RoamingState	enumurated	0(roamingState)1(non-roamingState)

实施例8：用户在漫游的时候限制其它用户的呼入

相应的Roaming State SPT表示方式为：

<SPT>

</SPT>

上述SPT表示只要业务触发点发现用户处于漫游状态就发生了Roaming State SPT的匹配，使用该SPT配合Session Case SPT(如取值INVITE)和SIP Method SPT(如取值TERMINATING_REGISTERED)就可以实现被叫用户在漫游的时候将来话触发到业务控制点上的功能。

iFC在会话情形(SessionCase)已经支持终止未注册，取值为“2”，本发明支持对主叫用户提供在未注册状态下的业务触发，如仍在业务过滤规则SPT中使用会话情形元素，扩展一个会话情形的取值“3”，表示起始未注册(Origingating_Unregistered)，即可以支持对主叫用户提供基于用户注册状态的过滤规则。如用户未在IMS中注册，但在电路域中注册，用户发起呼叫，从电路域进入IMS，在未注册状态下，作为主叫用户，业务触发点调用相应的业务控制点。

7、业务过滤规则中可以指定业务调用消息

如上所述，现有技术存在问题7，只能将业务过滤规则的触发消息，作为该规则被匹配后对特定业务控制点的调用消息。为解决该问题，可以在业务过滤规则中指定对业务控制点的调用消息。

实施例9：业务触发点收到一个SIP响应消息，如200响应码，该SIP响应消息匹配一个业务过滤规则，需要调用一个特定的业务控制点，业务控制点名为“sip:as@ims.example.com”，从业务触发点发向该业务控制点的调用消息为SIP BYE(再见)消息，如下所示：

<SPT>

</SPT>

..................

<ServerName>sip:as@ims.example.com</ServerName>

</ApplicationServer>

在对ApplicationServer的描述中，增加了相应的InvokingMessage标签的设置，其取值可以是任一SIP消息。

实施例10：在业务过滤规则中指定对业务控制点的调用消息还有一个重要的应用，业务点触发器SPT中可能无法描述触发消息，如当采用前述的会话状态业务点触发器时，可以看到，一些会话状态并不是由业务触发点收到的一个SIP消息引发的，如会话状态为“终端无应答”，显然，此时将必须在业务过滤规则中指定从业务触发点发向特定业务控制点的调用消息，示例如下：

<SPT>

</SPT>

..................

<ServerName>sip:as@ims.example.com</ServerName>

<InvokingMessage>INVITE</InvokingMessage>

</ApplicationServer>

在上述的业务调用消息元素中，描述了消息的名称，可以是任一SIP消息。当业务控制点是不同类型时，如即可以是IMS应用服务器，也可以是智能网SCP等时，业务调用消息元素还可以指定消息所属协议类型，即E3接口类型，如取值“IN”表示调用消息是智能业务协议，还可以具体指明智能业务协议的种类，如取值“INAP”等，此外如果没有指明消息所属协议类型，可以缺省认为是“SIP”协议。业务调用消息元素还可以指定消息中的关键参数，例如智能业务的业务键参数、SCP的信令地址、协议版本号等。

8、业务过滤规则中可以描述其它规则关联信息

如上所述，现有技术存在问题8，不能使一个以上的业务过滤规则相互关联起来，要解决该问题，首先要能标识出一个业务过滤规则，即给业务过滤规则命名编号；其次要定义一个业务过滤规则被匹配的业务控制点的业务执行结果，如“1”表示“成功”，“0”表示“失败”等。

实施例11：对其它业务过滤规则的关联指示的描述可以出现在上一条业务过滤规则中，示例如下：

<ServerName>sip:as@ims.example.com</ServerName>

</Relation>

</ApplicationServer>

对其它业务过滤规则的关联指示的描述可以出现在对业务控制点的设置中，例如在特定的业务控制点名称之后，给出该业务控制点的执行结果对其它业务过滤规则的关联(标签为Relation)，当执行结果Result为0(失败)时，调用关联的业务过滤规则，标签RelatingFilterCriteria给出了关联规则的名称FC00abc。即在本业务过滤规则中给出特定业务控制点对应的其它关联规则，根据该业务

控制点的执行结果引用其它关联规则。

当然，对其它业务过滤规则的关联指示的描述也可以出现在下一条业务过滤规则中，即在本业务过滤规则的业务点触发器SPT中引用其它关联规则的执行结果，作为一种匹配条件，如下所示：

<SPT>

</Relation>

</SPT>

在业务点触发器SPT中，要求检查名称为FC11xyz的业务过滤规则的执行结果。此外，如前所述，业务控制点可以向业务触发点返回业务过滤规则，业务触发点可以立即匹配处理该业务过滤规则，此时，业务过滤规则可以不出现RelatingFilterCriteria的名称，而认为Result的取值就是来自该业务控制点的执行结果，即RelatingFilterCriteria可以显式取值、也可以是缺省取值。

除了可以根据本规则的执行结果引用其它关联规则、或将其它关联规则的执行结果作为本规则的匹配条件，还可以在一个业务过滤规则中预置其它的过滤规则，预置规则可能会被执行，也可能不会被执行，取决于业务触发点后续是否能获得相应的触发条件。

可以看到，业务过滤规则中描述的其它规则关联信息至少包括业务执行结果、或其它过滤规则。

9、业务过滤规则中可以描述虚拟应用服务器地址

如上所述，现有技术存在问题9，不能在触发条件匹配后指定特定的处理。为解决该问题在业务过滤规则中引入虚拟应用服务器地址。

虚拟服务器地址对应业务触发点上的一段程序或一段脚本，虚拟服务器地址不用SIP URL表述，但可以采用类似的方式描述，例如虚拟服务器地址的域描述部分对应业务触发点的本机地址，用户部分对应业务触发点上的一段程序或者一段脚本。虚拟的服务器地址可以带参数以做为相应的程序段或者脚本的输入，它携带的参数可以不是SIP协议中的参数。

虚拟服务器地址的描述可以位于业务过滤规则中对业务控制点

的描述中，例如可以放在过滤规则数据中服务器地址描述部分。

实施例12：业务触发点地址为triggerPoint1.home.net，它上面有脚本localScript3用于向一个呈现服务器发送消息，localScript3这个脚本有一个呈现服务器地址的输入参数用于表示要向哪个呈现服务器发送消息。它得到的一条过滤规则数据中服务器地址描述为：

<ServerName>localScript3@triggerPoint1.home.net；

presenceServer＝presenceServer10.home.net</ServerName>

上面的例子中localScript3@triggerPoint1.home.net表示triggerPoint1.home.net上对应的脚本或程序为localScript3，其后的presenceServer＝presenceServer10.home.net为脚本localScript3的输入，表示这个脚本可以向presenceServer10.home.net这个地址请求用户的呈现数据。即当这条过滤规则的触发条件满足后业务触发点triggerPoint1.home.net调用其上的脚本localScript3，调用的脚本根据虚拟服务器地址中的presenceServer参数向presenceServer10.home.net这个地址请求用户的呈现数据。

10、业务过滤规则中可以描述过滤规则有效性

如上所述，现有技术存在问题9，业务触发点获得业务过滤规则后，将总是执行，但实际上过滤规则可以只是“临时有效”。如前所述，在当前通信处理过程中，来自业务控制点的业务过滤规则可以只在当前通信处理过程中有效。本发明提供两种方式来描述业务过滤规则的有效性，一种方式是在业务过滤规则中增加一个有效性元素，取值至少为以下一种：无效、有效、当前通信有效、一次有效，其中，“无效”表示业务过滤规则已经失效，业务触发点可以不用执行；“有效”表示业务过滤规则一直有效(直到指定它无效或者删除该业务过滤规则)，业务触发点需要执行；“当前通信有效”表示业务过滤规则只在当前通信处理过程中有效，通信释放，业务触发点可以删除该业务过滤规则或将有效性元素取值改为“无效”；“一次有效”表示业务过滤规则被执行一次后就失效，业务触发点可以删除该业务过滤规则或将有效性元素取值改为“无效”。

上述方式是一种显式的有效性表示方式，另一种方式是隐式的有效性表示方式，即不扩展一个有效性元素，由业务触发点根据通信处理状况，自行决定业务过滤规则的有效性，比如，业务触发点缺省认为在当前通信处理过程中，来自业务控制点的业务过滤规则“一次有效”，来自用户签约数据库的业务过滤规则“有效”。

11、业务过滤规则中可以描述业务调用结果处理

业务调用结果的第一种情况可以是：业务触发点向业务控制点发送调用消息失败，在规定时间内没有收到来自业务控制点的返回消息，即超时无响应，比如网络出现了故障，导致调用消息或其返回发送失败，此时，在业务过滤规则中增加一个业务调用结果处理元素，其值至少为以下一种：重新调用业务控制点、调用同质业务控制点、执行下一条业务过滤规则、停止执行业务过滤规则、通信释放，其中，“重新调用业务控制点”表示对当前调用失败的业务控制点重新调用一次；“调用同质业务控制点”表示调用能提供和当前调用失败的业务控制点相同服务的业务控制点(即同质业务控制点)，如AS1调用失败，AS2能提供和AS1相同服务，则业务触发点调用AS2，AS2的地址可以和AS1的一起配置在业务过滤规则中；“执行下一条业务过滤规则”表示忽略当前调用失败，执行下一条业务过滤规则(如果有的话)，“停止执行业务过滤规则”表示忽略当前调用失败，并停止执行后续所有的业务过滤规则(如果有的话)，“通信释放”表示释放当前通信。

业务调用结果的第二种情况还可以是：业务控制点收到一个调用消息后，因为某种原因如系统故障，而导致本应被调用的业务逻辑没被调用，业务控制点在返回的响应中指示业务逻辑调用失败(注意不是业务逻辑调用执行后当前通信失败，如呼叫限呼)，业务触发点据此进行相应的业务调用结果处理，如上所示。

业务调用结果还有一种特殊的第三种情况：业务控制点收到一个调用消息后，进行相应处理后，返回的是和调用消息不一样的消息，如业务控制点收到一个SIP INVITE邀请消息，返回给业务触发点一个SIP响应消息，在现有技术中，后续其它的业务过滤规则将不再执行，而在本发明中，通过设置“业务调用结果处理”，可以选择执行“下一条业务过滤规则”，当然也可以选择“停止执行业务过滤规则”。

在第三种情况下，当业务触发点执行“下一条业务过滤规则”，还存在一个问题：是用业务触发点收到的原始触发消息，还是用上一个业务控制点返回的响应消息，来匹配下一条业务过滤规则，比如，业务触发点收到一个INVITE消息，执行第一条业务过滤规则，调用第一个业务控制点，收到一个415响应码消息，此时，业务触发点是仍用INVITE消息还是用415消息来执行下一条业务过滤规则，为解决这个问题，本发明针对“下一条业务过滤规则”，扩展一个“匹配条件”元素，其值可以是：业务触发点的原始触发条件、上一个业务控制点的调用消息、上一个业务控制点返回消息、甚至是其它的指定消息。其中，“业务触发点的原始触发条件”可以是业务触发点收到的原始触发消息、或原始触发的会话状态。

和上述的过滤规则有效性类似的，上述方式是一种显式的业务调用结果处理表示方式，另一种方式是隐式的业务调用结果处理表示方式，即不扩展业务调用结果处理元素，由业务触发点根据通信处理状况，自行决定业务调用结果处理方式，比如，对上述第一种情况，业务触发点缺省认为进行“调用同质业务控制点”的处理等。

此外，“匹配条件”元素可以位于业务调用结果处理元素中，即位于上一条业务过滤规则中，也可以独立的位于下一条业务过滤规则中，作为匹配当前业务过滤规则的指示条件。

实施例13：业务触发点收到一个INVITE消息，调用了一个主叫姓名收集AS，该AS用于在被叫应答时向被叫播放主叫姓名，呼叫被发向被叫终端，被叫振铃无应答，业务触发点根据会话状态是“终端无应答”的业务过滤规则1，调用了一个语音邮箱AS，向其发送指定的调用消息INVITE，语音邮箱AS应答，返回200响应码消息，业务触发点根据业务过滤规则1中设定的“下一条业务过滤规则”及对应的“业务触发点的原始触发条件”，使用会话状态是“终端无应答”来执行下一条业务过滤规则2，执行结果是向主叫姓名收集AS发送指定的调用消息BYE，清除主叫姓名收集AS，以避免其向语音邮箱AS播放主叫姓名。

12、业务过滤规则中可以描述业务标识

如上所述，现有技术存在问题12，不能识别业务过滤规则对应的业务且无法将业务种类做为规则匹配条件，为解决该问题，在业务过滤规则中引入业务标识。一个业务对应的业务标识在一个运营商网络内是唯一的。

对业务标识的描述可以出现在对业务控制点的设置中，以表示该业务过滤规则要触发的业务，这种情况下一个业务过滤规则对应一种业务。

例如：

<ServerName>sip:as@ims.example.com</ServerName>

<ServiceIndentifier>InComingCallScreening</ServiceIndentifier>

</ApplicationServer>

上面的例子中业务过滤规则的应用服务器描述中增加了一个ServiceIndentifier标签描述该业务过滤规则要触发的业务为来话筛选，其业务标识为InComingCallScreening。

业务标识也可以位于服务器名部分，例如：

<ServerName>sip:

InComingCallScreening@ims.example.com</ServerName>

</ApplicationServer>

或者

<ServerName>sip:as@ims.example.com；service＝

InComingCallScreening</ServerName>

</ApplicationServer>

当然，对业务标识的描述也可以出现在业务过滤规则的业务点触发器描述中，即将已经调用的业务种类作为一种匹配条件，如下所示：

<SPT>

.........................

<ServiceIndentifier>InComingCallScreening</ServiceIndentifier>

</SPT>

上面的例子中业务过滤规则的SPT部分增加了一个ServiceIndentifier标签描述该业务过滤规则匹配的条件之一为已经触发来话筛选业务，其业务标识为InComingCallScreening。

13、业务过滤规则中可以描述业务控制点的调用禁止规则

如前所述，现有技术不支持对业务控制点调用的禁止规则，一个业务控制点已经被调用后，当业务触发点收到一个后续的业务触发消息时，在特殊情况下该业务控制点有可能并不能接收该触发消息，这样通过将该业务控制点排除在该触发消息对应的业务过滤规则中是无法实现这一要求的，本发明提供了业务过滤规则中可以描述业务控制点的调用禁止规则来实现这一要求。

实施例14：业务触发点收到一个SIP INVITE消息，根据业务过滤规则依次调用了AS1、AS2、AS3，此后，业务触发点收到了一个来自语音邮箱的200应答响应消息，而AS2并不希望收到该200响应消息，否则会导致业务应用出错(AS2只处理来自用户终端的200应答响应消息)。此时，如果在200响应消息的业务过滤规则中排除对AS2的调用而只调用AS1和AS3，是很难满足这一要求，这是因为对200之类的响应消息来说，已经调用了哪些AS是很难预见的，一般来说，响应消息的业务过滤规则中描述的业务控制点或者是新增的(即在对应的SIP初始请求消息处理时没有调用)、或者是已调用业务控制点需要特殊处理的，如前述的指定新的调用消息、及描述业务控制点是否可以被调用等，对于后一种处理与此相关的业务过滤规则部分如下所示：

<SPT>

</SPT>

................

<ServerName>sip:as2@ims.example.com</ServerName>

</ApplicationServer>

在对ApplicationServer的描述中，增加了相应的BAN标签的设置，取值为TRUE表示该200应答响应消息禁止发往AS2。

最后，需要说明的是，从前述多个示例可以看到，业务触发点在一次通信处理过程中，可以使用多份分别来自不同场所的业务过滤规则，如HSS、业务控制点、甚至是业务触发点自身。显然，这些来自不同场所的业务过滤规则可以有不同的表现形式，如类似iFC的XML描述形式、或一段程序、或一份表格数据等，即可以有不同表现形式的业务过滤规则存在，当然来自不同场所的业务过滤规则也可以统一为一种表现形式；此外，这些来自不同场所的业务过滤规则也可以有不同的规则元素，如来自业务触发点的业务过滤规则可以只有业务调用结果处理和/或业务过滤规则有效性等规则元素，当然来自不同场所的业务过滤规则也可以统一有相同的规则元素；此外，与iFC类似，本发明中的业务过滤规则中的SPT支持逻辑运算，例如非运算、或运算、与运算等，即SPT可以将触发禁止条件排除在外，也可以对SPT进行组合。从以上的描述中，可以看出，本发明实现了如下技术效果：

本发明提供了一种增强的业务触发机制，业务触发点可以根据SIP消息会话描述外的消息体、SIP初始请求消息外的SIP消息事件、会话状态、时间、用户呈现信息、用户状态、业务调用消息、其它规则关联信息、虚拟应用服务器地址、业务过滤规则有效性、业务调用结果处理、业务标识、业务控制点调用禁止规则将当前处理的通信触发到业务控制点或进行本地处理，从而提高了触发的有效性和灵活性，避免了业务冲突，减轻了业务控制点的负荷。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。应该明白，这些具体实施中的变化对于本领域的技术人员来说是显而易见的，不脱离本发明的精神保护范围。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims

1.一种具有增强的业务过滤规则的分组网络，其特征在于，包括：

业务过滤规则库，用于保存或产生用户的业务过滤规则；

业务控制点，用于为所述用户提供业务；以及

业务触发点，从所述业务过滤规则库获取所述业务过滤规则，并根据所述业务过滤规则决定当前处理的通信是否需要触发到所述业务控制点或是否要进行本地处理，其中，所述业务过滤规则至少包括以下之一：SIP消息会话描述外的消息体、会话状态、SIP初始请求消息外的消息事件、时间、用户呈现信息、用户状态、业务调用消息、其它规则关联信息、虚拟应用服务器地址、过滤规则有效性、业务调用结果处理、业务标识、业务控制点调用禁止规则。

2.根据权利要求1所述的具有增强的业务过滤规则的分组网络，其特征在于，所述业务过滤规则包括SIP消息会话描述外的消息体元素其值包括消息体类型和/或消息体内容。

3.根据权利要求2所述的具有增强的业务过滤规则的分组网络，其特征在于，所述消息体类型为多用途网络邮件扩展MIME媒体类型，所述消息体内容为多用途网络邮件扩展MIME体。

4.根据权利要求1所述的具有增强的业务过滤规则的分组网络，其特征在于，所述会话状态至少包括以下之一：收集信息、分析信息、路由选择失败、发端_忙、发端_无应答、发端_应答、发端_拆线、发端_放弃、终端试呼鉴权、终端_忙、终端_无应答、终端_应答、终端_拆线、终端_放弃。

5.根据权利要求1所述的具有增强的业务过滤规则的分组网络，其特征在于，所述SIP初始请求消息外的消息事件至少包括以下一种：SIP响应消息、SIP后续请求消息。

6.根据权利要求5所述的具有增强的业务过滤规则的分组网络，其特征在于，所述业务过滤规则包括所述SIP响应消息元素，其值支持通配和/或多值描述。

7.根据权利要求1所述的具有增强的业务过滤规则的分组网络，其特征在于，所述用户呈现信息至少包括以下之一：用户活动、用户情绪、场所类型、场所属性、私密程度、用户的当前状态和角色、设备状态、设备通信能力、用户位置信息。

8.根据权利要求7所述的具有增强的业务过滤规则的分组网络，其特征在于，所述的用户位置信息至少包括自然地理位置信息、行政地理位置信息、网络地理位置信息中的一种。

9.根据权利要求1所述的具有增强的业务过滤规则的分组网络，其特征在于，所述用户状态至少包括以下一种状态：注册状态、漫游状态。

10.根据权利要求1所述的具有增强的业务过滤规则的分组网络，其特征在于，所述其它规则关联信息至少包括以下之一：业务执行结果、或其它过滤规则。

11.根据权利要求10所述的具有增强的业务过滤规则的分组网络，其特征在于，所述其它规则关联信息位于业务点触发器描述中和/或位于对业务控制点的描述中。

12.根据权利要求1所述的具有增强的业务过滤规则的分组网络，其特征在于，所述业务调用消息指定业务触发点向业务控制点发送的消息。

13.根据权利要求12述的具有增强的业务过滤规则的分组网络，其特征在于，所述业务过滤规则包括所述业务调用消息元素，其值包括以下至少一种信息：消息所属协议类型、消息名称、消息中的关键参数。

14.根据权利要求1所述的具有增强的业务过滤规则的分组网络，其特征在于，所述虚拟应用服务器地址指定业务触发点上的一段程序或脚本。

15.根据权利要求1所述的具有增强的业务过滤规则的分组网络，其特征在于，所述过滤规则有效性至少包括以下一种：无效、有效、当前通信有效、或一次有效。

16.根据权利要求1所述的具有增强的业务过滤规则的分组网络，其特征在于，所述业务调用结果处理至少包括以下一种：重新调用业务控制点、调用同质业务控制点、执行下一条业务过滤规则、停止执行业务过滤规则、通信释放。

17.根据权利要求1或16所述的具有增强的业务过滤规则的分组网络，其特征在于，所述业务过滤规则还包括匹配条件，其值至少包括以下一种：业务触发点的原始触发条件、上一个业务控制点的调用消息、上一个业务控制点返回消息、其它指定消息。

18.根据权利要求1所述的具有增强的业务过滤规则的分组网络，其特征在于，所述的业务标识位于业务点触发器描述中和/或位于对业务控制点的描述中。

19.一种业务触发方法，其特征在于，包括以下步骤：

业务触发点根据业务过滤规则决定当前处理的通信是否需要触发到业务控制点或是否要进行本地处理，其中，所述业务过滤规则至少包括以下之一：SIP消息会话描述外的消息体、会话状态、SIP初始请求消息外的消息事件、时间、用户呈现信息、用户状态、业务调用消息、其它规则关联信息、虚拟应用服务器地址、过滤规则有效性、业务调用结果处理、业务标识、业务控制点调用禁止规则。

20.根据权利要求19所述的业务触发方法，其特征在于，所述业务过滤规则包括SIP消息会话描述外的消息体元素其值包括消息体类型和/或消息体内容。

21.根据权利要求20所述的业务触发方法，其特征在于，所述消息体类型为多用途网络邮件扩展MIME媒体类型，所述消息体内容为多用途网络邮件扩展MIME体。

22.根据权利要求19所述的业务触发方法，其特征在于，所述会话状态至少包括以下之一：收集信息、分析信息、路由选择失败、发端_忙、发端_无应答、发端_应答、发端_拆线、发端_放弃、终端试呼鉴权、终端_忙、终端_无应答、终端_应答、终端_拆线、终端_放弃。

23.根据权利要求22所述的业务触发方法，其特征在于，所述发端_忙和/或终端_忙至少包括以下一种情况：用户终端返回忙、网络决定忙、网络决定接近忙。

24.根据权利要求19所述的业务触发方法，其特征在于，所述SIP初始请求消息外的消息事件至少包括以下一种：SIP响应消息、SIP后续请求消息。

25.根据权利要求24所述的业务触发方法，其特征在于，所述业务过滤规则包括所述SIP响应消息元素，其值支持通配和/或多值描述。

26.根据权利要求19所述的业务触发方法，其特征在于，所述用户呈现信息至少包括以下之一：用户活动、用户情绪、场所类型、场所属性、私密程度、用户的当前状态和角色、设备状态、设备通信能力、用户位置信息。

27.根据权利要求26所述的业务触发方法，其特征在于，所述的用户位置信息至少包括以下之一：自然地理位置信息、行政地理位置信息、网络地理位置信息中的一种。

28.根据权利要求19所述的业务触发方法，其特征在于，所述用户状态至少包括以下一种状态：注册状态、漫游状态。

29.根据权利要求19所述的业务触发方法，其特征在于，所述其它规则关联信息至少包括以下之一：业务执行结果、或其它过滤规则。

30.根据权利要求29所述的业务触发方法，其特征在于，所述其它规则关联信息位于业务点触发器描述中、或位于对业务控制点的描述中。

31.根据权利要求19所述的业务触发方法，其特征在于，所述业务调用消息指定业务触发点向业务控制点发送的消息。

32.根据权利要求31所述的具有增强的业务过滤规则的分组网络，其特征在于，所述业务过滤规则包括所述业务调用消息元素，其值包括以下至少一种信息：消息所属协议类型、消息名称、消息中的关键参数。

33.根据权利要求19所述的业务触发方法，其特征在于，所述虚拟应用服务器地址指定业务触发点上的一段程序或脚本。

34.根据权利要求19所述的业务触发方法，其特征在于，所述过滤规则有效性至少包括以下一种：无效、有效、当前通信有效、或一次有效。

35.根据权利要求19所述的业务触发方法，其特征在于，所述业务调用结果处理至少包括以下一种：重新调用业务控制点、调用同质业务控制点、执行下一条业务过滤规则、停止执行业务过滤规则、通信释放。

36.根据权利要求19或35所述的业务触发方法，其特征在于，所述业务过滤规则中还包括匹配条件，其值至少包括以下一种：业务触发点的原始触发条件、上一个业务控制点的调用消息、上一个业务控制点返回消息、其它指定消息。

37.根据权利要求35所述的业务触发方法，其特征在于，所述业务调用结果处理的发生情况至少是以下一种：业务触发点向业务控制点发送调用消息失败、业务控制点调用业务逻辑失败、业务控制点返回和对其调用消息不一样的消息。

38.根据权利要求19所述的业务触发方法，其特征在于，所述的业务标识位于业务点触发器描述中和/或位于对业务控制点的描述中。

39.根据权利要求19至38任一项所述的业务触发方法，其特征在于，所述业务触发点从业务过滤规则库获取所述业务过滤规则，所述业务过滤规则库至少位于以下一处：用户签约数据库、业务控制点、业务触发点。

40.根据权利要求39所述的业务触发方法，其特征在于，所述业务过滤规则直接或间接来自业务控制点时，业务触发点可以立即执行所述业务过滤规则、或在收到后续通信消息时再执行所述业务过滤规则。