CN106549901A - 一种业务触发方法和装置 - Google Patents

Abstract

本申请实施例提供了一种业务触发方法，包括：服务呼叫会话控制功能S-CSCF获取应用服务器AS的状态信息；当所述服务呼叫会话控制功能S-CSCF接收到业务请求时，所述服务呼叫会话控制功能S-CSCF采用所述应用服务器AS的状态信息判断所述应用服务器AS是否正常；若是，则所述服务呼叫会话控制功能S-CSCF采用预先获取的初始过滤规则iFC进行业务匹配；若所述业务匹配成功，则所述服务呼叫会话控制功能S-CSCF触发业务。本申请通过将获取的应用服务器AS的状态作为业务触发匹配的必要条件，减少了服务呼叫会话控制功能S-CSCF进行不必要的初始过滤规则iFC匹配和业务触发过程，降低了系统和网络负荷。

Description

一种业务触发方法和装置

技术领域

本申请涉及通信技术领域，特别是涉及一种业务触发方法和一种业务触发装置。

背景技术

根据3GPP TS 24.229中关于业务触发的机制，服务呼叫会话控制功能S-CSCF(Serving Call Session Control Function)在收到初始请求时，需根据用户签约的业务信息HSS中的初始过滤规则iFC(Initial Filter Criteria)触发点进行匹配，匹配成功后进行业务触发，将请求消息转发到相应的应用服务器AS(Application Server)。

当S-CSCF未收到一个请求相应的响应消息，或者从AS收到408 RequestTimeout响应消息，或者从AS收到504响应消息时，S-CSCF根据iFC中的默认处理方式决定是否继续进行业务触发。默认处理方式包括：SESSION_CONTINUED和SESSION_TERMINATED。

如果iFC的默认处理方式为“SESSION_CONTINUED”，或者没有默认处理方式时，S-CSCF继续匹配其他iFC。

如果iFC的默认处理方式为“SESSION_TERMINATED”方式时，需要将收到的响应消息继续转发给请求侧，并且不再进行后续未完成的业务触发。

在现有的这种iFC默认处理机制中，S-CSCF并不关心AS的状态，在AS发生故障、AS繁忙或者网络故障等情况时，S-CSCF仍然进行业务触发匹配和消息转发，做了过多无效的匹配和消息转发，带来事务、会话，甚至业务处理的延迟，增加了设备和网络负荷，同时，也带来了接通时间过长，用户感知较差的问题。

发明内容

鉴于上述问题，提出了本申请实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种业务触发方法和相应的一种业务触发装置。

为了解决上述问题，本申请实施例公开了一种业务触发方法，包括：

服务呼叫会话控制功能S-CSCF获取应用服务器AS的状态信息；

当所述服务呼叫会话控制功能S-CSCF接收到业务请求时，所述服务呼叫会话控制功能S-CSCF采用所述应用服务器AS的状态信息判断所述应用服务器AS是否正常；

若是，则所述服务呼叫会话控制功能S-CSCF采用预先获取的初始过滤规则iFC进行业务匹配；

若所述业务匹配成功，则所述服务呼叫会话控制功能S-CSCF触发业务。

优选的，所述服务呼叫会话控制功能S-CSCF，按预设的时间间隔获取所述应用服务器AS的状态信息。

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

所述服务呼叫会话控制功能S-CSCF在用户初始注册成功后，从用户签约数据中获取对应的应用服务器AS的连接信息；所述连接信息包括应用服务器的IP地址；

所述服务呼叫会话控制功能S-CSCF获取应用服务器AS的状态信息的步骤包括：

所述服务呼叫会话控制功能S-CSCF通过所述应用服务器的IP地址获取应用服务器AS的状态信息。

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

若所述服务呼叫会话控制功能S-CSCF采用所述应用服务器AS的状态信息判断所述应用服务器AS是否正常的结果为否，则所述服务呼叫会话控制功能S-CSCF按照初始过滤规则iFC的默认处理方式进行处理。

优选的，应用服务器AS异常包括：

所述服务呼叫会话控制功能S-CSCF未获取到所述应用服务器AS的状态信息；

或，所述服务呼叫会话控制功能S-CSCF接收到的所述状态信息为：非成功响应消息。

同时，本申请还公开了一种业务触发装置，包括：

位于所述服务呼叫会话控制功能S-CSCF的状态获取模块，用于获取应用服务器AS的状态信息；

位于所述服务呼叫会话控制功能S-CSCF的状态判断模块，用于当所述服务呼叫会话控制功能S-CSCF接收到业务请求时，采用所述应用服务器AS的状态信息判断所述应用服务器AS是否正常；

位于所述服务呼叫会话控制功能S-CSCF的初始过滤规则匹配模块，用于若判断所述应用服务器AS是否正常的结果为是，则采用预先获取的初始过滤规则iFC进行业务匹配；

位于所述服务呼叫会话控制功能S-CSCF的业务触发模块，用于若所述业务匹配成功，则所述服务呼叫会话控制功能S-CSCF触发业务。

优选的，所述服务呼叫会话控制功能S-CSCF，按预设的时间间隔获取所述应用服务器AS的状态信息。

优选的，所述装置还包括：

位于所述服务呼叫会话控制功能S-CSCF的连接信息获取模块，用于在用户初始注册成功后，从用户签约数据中获取对应的应用服务器AS的连接信息；所述连接信息包括应用服务器的IP地址；

所述状态获取模块进一步包括：

第一状态获取子模块，用于通过所述IP地址获取应用服务器AS的状态信息。

优选的，所述装置还包括：

位于所述服务呼叫会话控制功能S-CSCF的默认处理模块，用于若所述服务呼叫会话控制功能S-CSCF采用所述应用服务器AS的状态信息判断所述应用服务器AS是否正常的结果为否，则所述服务呼叫会话控制功能S-CSCF按照初始过滤规则iFC的默认处理方式进行处理。

优选的，应用服务器AS异常包括：

所述服务呼叫会话控制功能S-CSCF未获取到所述应用服务器AS的状态信息；

或，所述服务呼叫会话控制功能S-CSCF接收到的所述状态信息为：非成功响应消息。

本申请实施例包括以下优点：

本申请通过将获取的应用服务器AS的状态作为业务触发匹配的必要条件，减少了服务呼叫会话控制功能S-CSCF进行不必要的初始过滤规则iFC匹配和业务触发过程，降低了系统和网络负荷。

当应用服务器AS的状态异常时，不再进行后续初始过滤规则iFC匹配，缩短了业务处理的时长，提升了用户感知。

附图说明

图1是现有的业务触发中应用服务器AS状态故障返回非200OK最终响应处理流程图；

图2是现有的业务触发中应用服务器AS状态故障未回复任何响应消息处理流程图；

图3是本申请的一种业务触发方法实施例的步骤流程图；

图4是本申请实施例中应用服务器AS状态正常的心跳流程；

图5是本申请实施例中应用服务器AS状态异常的心跳流程。

图6是本申请实施例中业务触发流程图；

图7是本申请的一种业务触发装置实施例的结构框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

参照图1，是现有的业务触发中应用服务器AS状态故障返回非200OK最终响应处理流程图。

在10～20，S-CSCF收到INVITE请求后，根据业务触发处理机制，将消息触发到相应的AS_1。

在30，AS_1由于某种原因处于故障状态，向S-CSCF返回408/5xx等非200OK最终响应消息。

响应消息包括：100试呼叫(Trying)、180振铃(Ringing)、181呼叫正在前转(Call is Being Forwarded)、200成功响应(OK)、302临时迁移(MovedTemporarily)、400错误请求(Bad Request)、401未授权(Unauthorized)、403禁止(Forbidden)、404用户不存在(Not Found)、408请求超时(RequestTimeout)、480暂时无人接听(Temporarily Unavailable)、486线路忙(BusyHere)、504服务器超时(Server Time-out)、600全忙(Busy Everywhere)。

在40，S-CSCF收到业务触发请求由AS回复的408/5xx等非200OK最终响应消息，并且业务触发的默认处理方式为“SESSION_CONTINUED”,还有其他低优先级iFC需要业务触发，则继续匹配下一个iFC，并触发业务到AS_2。

50～60AS_2向S-CSCF返回INVITE请求，S-CSCF收到INVITE请求后，判断用户已经无其他iFC需要触发。因此，将INVITE转发到被叫终端侧。

在AS发生故障、AS繁忙或者网络故障等情况时，S-CSCF仍然进行业务触发匹配和消息转发，做了过多无效的匹配和消息转发，带来事务、会话，甚至业务处理的延迟，增加了设备和网络负荷，同时，也带来了接通时间过长，用户感知较差的问题。

参照图2所示是现有的业务触发中应用服务器AS状态故障未回复任何响应消息处理流程图。

在10～20，S-CSCF收到INVITE请求后，根据业务触发处理机制，将消息触发到相应的AS_1。

在30，S-CSCF对AS_1业务触发完成后，未收到任何响应消息，直到事务定时器超时。S-CSCF获取业务触发的默认处理方式为“SESSION_CONTINUED”，并且还有其他低优先级iFC需要业务触发。S-CSCF继续进行下一个iFC匹配，并将消息触发到AS_2。

在40～50，AS_2向S-CSCF返回INVITE请求，S-CSCF收到INVITE请求后，判断用户已经无其他iFC需要触发。因此，将INVITE转发到被叫终端侧。

按照3GPP TS 24.229协议中的处理机制，当AS_1故障未返回任何响应消息时，S-CSCF需等待事务定时器超时，再根据iFC的默认处理方式决定是否继续业务触发和业务。一般事务定时器时间较长，常用的事务定时器在30秒，对于用户打电话等业务而言，这样的时间显然过长，大部分用户没有这样的耐心等待如此长的时间，会认为运营商网络存在问题，电话打不通，用户感知差，从而引起用户投诉。由此，可认为协议考虑了理论上信令的处理逻辑，但在实际应用中对用户感知方面欠缺考虑。

本申请实施例的核心构思之一在于，服务呼叫会话控制功能通过获取应用服务器AS的状态信息作为业务触发匹配条件，根据应用服务器AS的状态信息触发业务。

参照图3，示出了本申请的一种业务触发方法实施例的步骤流程图，具体可以包括如下步骤：

步骤301，服务呼叫会话控制功能S-CSCF获取应用服务器AS的状态信息；

步骤302，当所述服务呼叫会话控制功能S-CSCF接收到业务请求时，所述服务呼叫会话控制功能S-CSCF采用所述应用服务器AS的状态信息判断所述应用服务器AS是否正常；

步骤303，若是，则所述服务呼叫会话控制功能S-CSCF采用预先获取的初始过滤规则iFC进行业务匹配；

步骤304，若所述业务匹配成功，则所述服务呼叫会话控制功能S-CSCF触发业务。

在本申请实施例中，当S-CSCF接收到业务请求时S-CSCF根据AS的状态信息触发业务。当AS的状态为故障时，将不触发该AS业务，从而减少不必要的业务匹配。当应用服务器AS状态正常时，服务呼叫会话控制功能S-CSCF根据初始过滤规则iFC进行业务匹配，若业务匹配成功，则服务呼叫会话控制功能S-CSCF触发业务。

初始过滤规则iFC是存储在归属签约用户服务器HSS((Home SubscriberServer)的用户签约数据中的一部分，在用户注册时下载到为用户分配的S-CSCF中，iFC按照不同优先级定义了业务触发的条件和目的AS，S-CSCF在处理用户业务请求时进行iFC匹配检测，符合触发条件则向指定的AS触发，使得AS可以对该次业务按照AS内既定的业务逻辑进行控制。如果AS运行状态正常，再进行iFC的业务匹配。否则，不需要进行iFC的匹配。

作为本申请实施例的一种优选示例，所述方法还包括：

所述服务呼叫会话控制功能S-CSCF在用户初始注册成功后，从用户签约数据中获取对应的应用服务器AS的连接信息；所述连接信息包括应用服务器的IP地址；

所述服务呼叫会话控制功能S-CSCF获取应用服务器AS的状态信息的步骤包括：

所述服务呼叫会话控制功能S-CSCF通过所述应用服务器的IP地址获取应用服务器AS的状态信息。

服务呼叫会话控制功能S-CSCF是多媒体子系统IMS(IP MultimediaSubsystem)的业务控制层，为用户提供回话控制和注册业务。在本申请实施例中，在用户初始注册成功后，S-CSCF从用户签约数据中获取相关AS的信息，包括AS的服务器IP地址、域名、端口、业务标识等相关信息，将该信息与本地存储的AS信息进行比对，如果本地不存在该AS的信息，将作为新的AS存储到本地，并根据该AS的地址信息获取运行状态。对于新的AS，在用户注册完成之后就可以获取AS的状态信息。

作为本申请实施例的一种优选示例，所述服务呼叫会话控制功能S-CSCF，按预设的时间间隔获取所述应用服务器AS的状态信息。

S-CSCF可以采用类似心跳等方法按预设的间隔周期性地获取AS的状态信息，在网络不同层次进行心跳检测，以及采用不同信令进行心跳检测。

在网络层，S-CSCF可以采用用户数据报协议UDP(User DatagramProtocol)消息进行心跳检测。

在应用层，S-CSCF可以采用会话初始协议SIP(Session InitiationProtocol)消息进行心跳检测，包括Subscribe、Option等消息。

参照图4，示出了本申请实施例中应用服务器AS状态正常的心跳流程。

在10，S-CSCF向AS发送Option状态请求消息；

在20，AS收到Option状态请求消息后，并且AS运行状态正常，向S-CSCF回复200OK响应消息；S-CSCF收到200OK响应消息后，将AS状态存储到本地。

在本申请实施例中，S-CSCF采用SIP消息中的选择Option消息进行心跳检测。对于AS的状态，一方面，可通过是否获得响应消息，响应消息的响应消息来判断；另一方面，可在通知Notify或响应消息中做扩展，包括扩展头域，或在消息体中采用XML等方式携带AS状态。可根据是否对设备的要求来选择获取AS状态的方法。

参照图5，示出了本申请实施例中应用服务器AS状态异常的心跳流程。在10，S-CSCF向AS发送Option状态请求消息。由于某种原因，AS运行状态为故障态，AS并未向S-CSCF回复任何消息。S-CSCF等待响应消息超时，S-CSCF认为该时间段AS运行状态为故障态，并将状态存储在本地。

作为本申请实施例的一种优选示例，所述方法还包括：

若所述服务呼叫会话控制功能S-CSCF采用所述应用服务器AS的状态信息判断所述应用服务器AS是否正常的结果为否，则所述服务呼叫会话控制功能S-CSCF按照初始过滤规则iFC的默认处理方式进行处理。

若S-CSCF判断到AS的状态为异常，S-CSCF按照iFC的默认处理方式判断是否继续业务处理，iFC的默认处理方式包括：继续处理SESSION_CONTINUED，结束处理SESSION_TERMINATED，或者没有默认处理方式。

当默认处理方式为：SESSION_CONTINUED，或者没有默认处理方式时，S-CSCF继续匹配其他低优先级的iFC。

当默认处理方式为SESSION_TERMINATED方式时，需要将收到的响应消息继续转发给请求侧，并且不再进行后续未完成的业务触发。

在本申请实施例中，应用服务器AS异常包括：

所述服务呼叫会话控制功能S-CSCF未获取到所述应用服务器AS的状态信息；

或，所述服务呼叫会话控制功能S-CSCF接收到的所述状态信息为：非成功响应消息。

引起应用服务器AS异常的情况包括：链路异常导致信令发送失败、丢包、延迟等，AS无响应消息返回；AS故障，S-CSCF发送到AS的信令无法处理，AS无响应消息返回；这两种情况都使得S-CSCF无法获得AS的状态信息。还有就是由于AS业务繁忙、重定向等原因，回复3xx/5xx/6xx等非成功响应消息。

参照图6是本申请实施例中业务触发流程图。

在10～20，S-CSCF收到INVITE请求后，根据用户签约数据得到当前iFC所对应的AS_1，S-CSCF根据获取的AS_1的状态信息得知AS_1处于故障状态，由于S-CSCF本地存储的AS_1状态为故障状态，该iFC的默认处理方式为“SESSION_CONTINUED”，并且该用户还有未触发的低优先级的iFC。S-CSCF不再对当前iFC进行匹配，也不对AS_1进行业务触发的处理，而是直接行下一个iFC的业务触发处理。下一个iFC匹配成功后，将消息转发给相应的AS_2。

在30～40，AS_2向S-CSCF返回INVITE请求，S-CSCF收到INVITE请求后，判断用户已经无其他iFC需要触发。因此，将INVITE转发到被叫终端侧。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。

参照图7，示出了本申请的一种业务触发装置实施例的结构框图，具体可以包括如下模块：

位于所述服务呼叫会话控制功能S-CSCF的状态获取模块701，用于获取应用服务器AS的状态信息；

位于所述服务呼叫会话控制功能S-CSCF的状态判断模块702，用于当所述服务呼叫会话控制功能S-CSCF接收到业务请求时，采用所述应用服务器AS的状态信息判断所述应用服务器AS是否正常；

位于所述服务呼叫会话控制功能S-CSCF的初始过滤规则匹配模块703，用于若判断所述应用服务器AS是否正常的结果为是，则采用预先获取的初始过滤规则iFC进行业务匹配；

位于所述服务呼叫会话控制功能S-CSCF的业务触发模块704，用于若所述业务匹配成功，则所述服务呼叫会话控制功能S-CSCF触发业务。

在本申请实施例中，所述服务呼叫会话控制功能S-CSCF，按预设的时间间隔获取所述应用服务器AS的状态信息。

作为本申请实施例的一种优选示例，所述装置还包括：

位于所述服务呼叫会话控制功能S-CSCF的连接信息获取模块，用于在用户初始注册成功后，从用户签约数据中获取对应的应用服务器AS的连接信息；所述连接信息包括应用服务器的IP地址；

所述状态获取模块进一步包括：

第一状态获取子模块，用于通过所述IP地址获取应用服务器AS的状态信息。

作为本申请实施例的一种优选示例，所述装置还包括：

位于所述服务呼叫会话控制功能S-CSCF的默认处理模块，用于若所述服务呼叫会话控制功能S-CSCF采用所述应用服务器AS的状态信息判断所述应用服务器AS是否正常的结果为否，则所述服务呼叫会话控制功能S-CSCF按照初始过滤规则iFC的默认处理方式进行处理。

在本申请实施例中，应用服务器AS异常包括：

所述服务呼叫会话控制功能S-CSCF未获取到所述应用服务器AS的状态信息；

或，所述服务呼叫会话控制功能S-CSCF接收到的所述状态信息为：非成功响应消息。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

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

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

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

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

尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的一种业务触发方法和一种业务触发装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种业务触发方法，其特征在于，包括：

服务呼叫会话控制功能S-CSCF获取应用服务器AS的状态信息；

当所述服务呼叫会话控制功能S-CSCF接收到业务请求时，所述服务呼叫会话控制功能S-CSCF采用所述应用服务器AS的状态信息判断所述应用服务器AS是否正常；

若是，则所述服务呼叫会话控制功能S-CSCF采用预先获取的初始过滤规则iFC进行业务匹配；

若所述业务匹配成功，则所述服务呼叫会话控制功能S-CSCF触发业务。

2.根据权利要求1所述的方法，其特征在于，所述服务呼叫会话控制功能S-CSCF，按预设的时间间隔获取所述应用服务器AS的状态信息。

3.根据权利要求1或2所述的方法，其特征在于，所述方法还包括：

所述服务呼叫会话控制功能S-CSCF在用户初始注册成功后，从用户签约数据中获取对应的应用服务器AS的连接信息；所述连接信息包括应用服务器的IP地址；

所述服务呼叫会话控制功能S-CSCF获取应用服务器AS的状态信息的步骤包括：

所述服务呼叫会话控制功能S-CSCF通过所述应用服务器的IP地址获取应用服务器AS的状态信息。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

若所述服务呼叫会话控制功能S-CSCF采用所述应用服务器AS的状态信息判断所述应用服务器AS是否正常的结果为否，则所述服务呼叫会话控制功能S-CSCF按照初始过滤规则iFC的默认处理方式进行处理。

5.根据权利要求3所述的方法，其特征在于，应用服务器AS异常包括：

所述服务呼叫会话控制功能S-CSCF未获取到所述应用服务器AS的状态信息；

或，所述服务呼叫会话控制功能S-CSCF接收到的所述状态信息为：非成功响应消息。

6.一种业务触发装置，其特征在于，包括：

位于所述服务呼叫会话控制功能S-CSCF的状态获取模块，用于获取应用服务器AS的状态信息；

位于所述服务呼叫会话控制功能S-CSCF的状态判断模块，用于当所述服务呼叫会话控制功能S-CSCF接收到业务请求时，采用所述应用服务器AS的状态信息判断所述应用服务器AS是否正常；

位于所述服务呼叫会话控制功能S-CSCF的初始过滤规则匹配模块，用于若判断所述应用服务器AS是否正常的结果为是，则采用预先获取的初始过滤规则iFC进行业务匹配；

位于所述服务呼叫会话控制功能S-CSCF的业务触发模块，用于若所述业务匹配成功，则所述服务呼叫会话控制功能S-CSCF触发业务。

7.根据权利要求6所述的装置，其特征在于，所述服务呼叫会话控制功能S-CSCF，按预设的时间间隔获取所述应用服务器AS的状态信息。

8.根据权利要求6或7所述的装置，其特征在于，所述装置还包括：

位于所述服务呼叫会话控制功能S-CSCF的连接信息获取模块，用于在用户初始注册成功后，从用户签约数据中获取对应的应用服务器AS的连接信息；所述连接信息包括应用服务器的IP地址；

所述状态获取模块进一步包括：

第一状态获取子模块，用于通过所述IP地址获取应用服务器AS的状态信息。

9.根据权利要求8所述的装置，其特征在于，所述装置还包括：

位于所述服务呼叫会话控制功能S-CSCF的默认处理模块，用于若所述服务呼叫会话控制功能S-CSCF采用所述应用服务器AS的状态信息判断所述应用服务器AS是否正常的结果为否，则所述服务呼叫会话控制功能S-CSCF按照初始过滤规则iFC的默认处理方式进行处理。

10.根据权利要求8所述的装置，其特征在于，应用服务器AS异常包括：

所述服务呼叫会话控制功能S-CSCF未获取到所述应用服务器AS的状态信息；

或，所述服务呼叫会话控制功能S-CSCF接收到的所述状态信息为：非成功响应消息。