应用服务器旁路方法及服务型呼叫会话控制功能设备

摘要

本发明涉及一种应用服务器旁路方法，包括：服务型呼叫会话控制功能设备在接收到呼叫请求后，检测与应用服务器列表中的应用服务器之间的通信信令，判断所述应用服务器的业务是否中断；如果判断所述应用服务器的业务中断，则确定所述应用服务器为故障应用服务器，并根据初始过滤规则继续完成所述应用服务器列表中除所述故障应用服务器之外的应用服务器的业务触发和后续呼叫处理。本发明还涉及一种服务型呼叫会话控制功能设备。本发明通过旁路AS的方式，可以确保用户呼叫不会因为某个AS故障而导致中断。而对于S-CSCF与PES/PSS AS之间的中断情况，通过旁路操作可以最大程度保障用户的通信安全，大大降低IMS业务大面积中断的可能性。

说明书

技术领域

本发明涉及IP多媒体子系统(IP Multimedia Subsystem，简称IMS)网络技术，尤其涉及一种在IMS网络中实现应用服务器(Application Server，简称AS)旁路(Bypass)的方法及服务型呼叫会话控制功能(Serving Call Session Control Function，简称S-CSCF)设备。

背景技术

随着IMS技术的的优势和逐步完善，现已被运营商普遍认可，并被广泛应用于运营商业务融合和转型战略的下一代网络架构中。AS是架构在IMS网络之上的功能实体，充分利用IMS网络提供的各种功能，为用户提供补充业务与增值多媒体服务。

IMS用户作为主叫或者被叫时，用户注册的S-CSCF需要根据用户初始过滤规则(Initial Filter Criteria，简称IFC)触发业务到相应的AS。现有技术下，IMS业务触发机制为按预定次序的串行方式，在用户签约多个AS业务时，S-CSCF将呼叫送一个AS触发完第一个业务后再送下一个AS触发下一个业务，依此类推，那么，当S-CSCF与其中任何一个AS之间业务中断，S-CSCF因无法触发该AS业务流程而导致用户呼叫被释放。

如图1所示，为现有技术中主叫用户注册的S-CSCF与AS之间信令连接异常时的呼叫流程示意图。在本示例中，主要涉及步骤包括：

1、用户发起会话请求；

2、主叫用户注册的S-CSCF与AS之间信令连接异常，则

S-CSCF触发业务失败；

3、主叫用户注册的S-CSCF结束呼叫，本次呼叫失败。

如图2所示，为现有技术中被叫用户注册的S-CSCF与AS之间信令连接异常时的呼叫流程示意图。在本示例中，主要涉及步骤包括：

1、用户发起会话请求；

2、S-CSCF触发业务；

3、S-CSCF通过DNS得到被叫所在IMS域的查询呼叫会话控制功能(Interrogating Call Session Control Function，简称I-CSCF)；

4、I-CSCF通过归属用户服务器(Home Subscriber Server，简称HSS)查询得到被叫用户注册的S-CSCF；

5、I-CSCF将会话请求送往被叫用户注册S-CSCF；

6、被叫用户注册的S-CSCF与AS之间信令连接异常，S-CSCF触发业务失败；

7、被叫用户注册的S-CSCF结束呼叫，呼叫失败。

从上面两个示例中可以看出，一旦S-CSCF与AS之间信令连接异常，均会导致业务失败，进而结束呼叫，这必然会给用户带来不良体验。另外，在IMS体系中，所有用户作为主被叫基本通话都必须送补充业务应用平台(PES/PSS AS)触发补充业务，若S-CSCF与PES/PSS AS之间中断，甚至会导致本域所有用户都无法呼入呼出，造成大面积通信安全事件，严重影响通信安全。

发明内容

本发明的目的是提出一种AS旁路方法及S-CSCF设备，能够在用户注册的S-CSCF与其中任何一个需要触发业务的AS信令连接异常时，仍能保证后续AS的业务触发与呼叫接续，最大程度保障用户的通信安全，大大降低IMS业务大面积中断的可能性。

为实现上述目的，本发明提供了一种应用服务器旁路方法，包括：

服务型呼叫会话控制功能设备在接收到呼叫请求后，检测与应用服务器列表中的应用服务器之间的通信信令，判断所述应用服务器的业务是否中断；

如果判断所述应用服务器的业务中断，则确定所述应用服务器为故障应用服务器，并根据初始过滤规则继续完成所述应用服务器列表中除所述故障应用服务器之外的应用服务器的业务触发和后续呼叫处理。

进一步的，在用户注册时，还包括：

所述服务型呼叫会话控制功能设备从归属用户服务器下载所述初始过滤规则；

所述服务型呼叫会话控制功能设备根据所述初始过滤规则和呼叫流程确定需要触发的所述应用服务器列表。

进一步的，所述服务型呼叫会话控制功能设备检测与应用服务器之间的通信信令，判断所述应用服务器的业务是否中断的操作具体包括：

所述服务型呼叫会话控制功能设备创建到所述应用服务器列表中的各个应用服务器的会话初始协议(Session Initiated Protocol，简称SIP)链路，并向所述各个应用服务器发送选项(OPTION)消息，然后根据是否在配置的重发次数内获得响应来判断所述服务型呼叫会话控制功能设备与每个应用服务器之间的连接是否中断，进而根据判断结果确定所述应用服务器的业务是否中断。

进一步的，在所述服务型呼叫会话控制功能设备中还预设有各个应用服务器的旁路策略，所述旁路策略为手工方式或自动方式，其中手动方式的开关配置包括允许和不允许的选项，当服务型呼叫会话控制功能设备接收到呼叫请求时，对所述应用服务器列表中的各个应用服务器的旁路策略进行判断，对于所述旁路策略为手动方式的允许选项的情况，则直接对采用该旁路策略的应用服务器执行旁路操作；对于所述旁路策略为手动方式的不允许选项的情况，则不对采用该旁路策略的应用服务器执行旁路操作；对于所述旁路策略为自动方式的情况，则继续检测与该应用服务器之间的通信信令，以判断该应用服务器的业务是否中断，再根据中断情况执行相应的旁路操作。

进一步的，在完成应用服务器列表中除所述故障应用服务器之外的应用服务器的业务触发和后续呼叫处理之后，还包括：

在形成的话单中对未进行业务触发的应用服务器进行标识；

根据所述话单进行计费处理。

为实现上述目的，本发明提供了一种服务型呼叫会话控制功能设备，包括：

业务检测模块，用于在接收到呼叫请求后，检测与应用服务器列表中的应用服务器之间的通信信令，判断所述应用服务器的业务是否中断；

故障确认模块，用于在判断所述应用服务器的业务中断时，确定所述应用服务器为故障应用服务器；

旁路处理模块，用于根据初始过滤规则继续完成所述应用服务器列表中除所述故障应用服务器之外的应用服务器的业务触发和后续呼叫处理。

进一步的，还包括：

规则获取模块，用于从归属用户服务器下载所述初始过滤规则；

列表确定模块，用于根据所述初始过滤规则和呼叫流程确定需要触发的所述应用服务器列表。

进一步的，所述业务检测模块具体包括：

链路创建单元，用于创建到所述应用服务器列表中的各个应用服务器的会话初始协议链路；

消息发送模块，用于向所述各个应用服务器发送选项消息；

响应接收模块，用于接收所述各个应用服务器对所述选项消息返回的响应消息；

所述故障确认模块还用于根据是否在配置的重发次数内获得响应来判断所述服务型呼叫会话控制功能设备与每个应用服务器之间的连接是否中断，进而根据判断结果确定所述应用服务器的业务是否中断。

进一步的，还包括：

话单标识模块，用于在完成应用服务器列表中除所述故障应用服务器之外的应用服务器的业务触发和后续呼叫处理之后，在形成的话单中对未进行业务触发的应用服务器进行标识。

进一步的，还包括：

旁路策略模块，用于保存为各个应用服务器预先设定的旁路策略，所述旁路策略为手工方式或自动方式，其中手动方式的开关配置包括允许和不允许的选项；

策略判断模块，用于当接收到呼叫请求时，对所述应用服务器列表中的各个应用服务器的旁路策略进行判断，对于所述旁路策略为手动方式的允许选项的情况，则直接对采用该旁路策略的应用服务器执行旁路操作；对于所述旁路策略为手动方式的不允许选项的情况，则不对采用该旁路策略的应用服务器执行旁路操作；对于所述旁路策略为自动方式的情况，则继续检测与该应用服务器之间的通信信令，以判断该应用服务器的业务是否中断，再根据中断情况执行相应的旁路操作。

基于上述技术方案，本发明通过S-CSCF与AS之间的通信信令检测机制检测各个AS业务是否中断，并根据IFC旁路故障的AS，对除故障AS之外的其他AS进行触发以及后续的呼叫处理。通过这种旁路处理的方式，可以确保用户呼叫不会因为某个AS故障而导致中断。而对于S-CSCF与PES/PSS AS之间的中断情况，通过旁路操作可以最大程度保障用户的通信安全，大大降低IMS业务大面积中断的可能性。

附图说明

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

图1为现有技术中主叫用户注册的S-CSCF与AS之间信令连接异常时的呼叫流程示意图。

图2为现有技术中被叫用户注册的S-CSCF与AS之间信令连接异常时的呼叫流程示意图。

图3为本发明AS旁路方法的一实施例的流程示意图。

图4为本发明AS旁路方法的另一实施例的流程示意图。

图5为本发明AS旁路方法的又一实施例的流程示意图。

图6为本发明S-CSCF设备的一实施例的结构示意图。

图7为本发明S-CSCF设备的另一实施例的结构示意图。

图8为本发明S-CSCF设备的又一实施例的结构示意图。

具体实施方式

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

如图3所示，为本发明AS旁路方法的一实施例的流程示意图。在本实施例中，AS旁路流程包括：

步骤101、S-CSCF设备在接收到呼叫请求；

步骤102、检测与AS列表中的AS之间的通信信令，判断所述AS的业务是否中断；

步骤103、如果判断所述AS的业务中断，则确定所述AS为故障AS，并根据IFC继续完成所述AS列表中除所述故障AS之外的AS的业务触发和后续呼叫处理。

在本实施例中，S-CSCF设备在触发与用户相关的AS的业务之前，判断该AS的业务是否中断，从而有针对性地不将呼叫请求发送到故障AS，而是将呼叫请求发送到其他AS进行业务触发，从而可以确保用户呼叫不会因为某个AS故障而导致中断，从而避免了降低用户体验的可能。如果S-CSCF设备检测AS列表中的所有AS均通信正常，则完成正常的业务触发与后续呼叫处理。

如图4所示，为本发明AS旁路方法的另一实施例的流程示意图。与上一实施例相比，本实施例在步骤101之前还包括：

步骤101a、在用户注册时，S-CSCF设备从HSS下载用户注册时设定的IFC；

步骤101b、S-CSCF设备根据IFC和呼叫流程确定需要触发的AS列表。

在步骤101b中，在确定AS列表时，如果存在各个AS之间的优先级，还可以确定AS列表中的各个AS对应的优先级。

在本实施例中的步骤102中S-CSCF设备所建立的检测机制可以具体为：S-CSCF设备创建到AS列表中的各个AS的SIP链路，并向各个AS发送OPTION消息，然后根据是否在配置的重发次数内获得响应来判断S-CSCF设备与每个AS之间的连接是否中断，进而根据判断结果确定AS的业务是否中断。

在S-CSCF设备中还预设有各个AS的旁路策略，旁路策略为手工方式或自动方式，其中手动方式的开关配置包括允许和不允许的选项，当S-CSCF设备接收到呼叫请求时，对AS列表中的各个AS的旁路策略进行判断，对于旁路策略为手动方式的允许选项的情况，则直接对采用该旁路策略的AS执行旁路操作；对于旁路策略为手动方式的不允许选项的情况，则不对采用该旁路策略的AS执行旁路操作；对于旁路策略为自动方式的情况，则继续检测与该AS之间的通信信令，以判断该AS的业务是否中断，再根据中断情况执行相应的旁路操作。

如图5所示，为本发明AS旁路方法的又一实施例的流程示意图。与前一实施例相比，本实施例在步骤103完成AS列表中除故障AS之外的AS的业务触发和后续呼叫处理之后，还包括以下步骤：

步骤104、在形成的话单中对未进行业务触发的AS进行标识；

步骤105、根据该话单进行计费处理。

考虑到检测出的故障AS未接收到S-CSCF设备发送的呼叫请求，也没有提供相应的业务，因此在计费方面需要考虑到这些情况，因此在本次业务触发和呼叫处理之后，生成话单时可以对话单中的未进行业务触发的AS进行标识，以便计费系统在处理话单时可以根据该标识进行相应的计费处理。

对于PES/PSS AS这种特殊的AS，由于全网所有用户都需要触发该PES/PSS AS，如果由于S-CSCF设备与PES/PSS AS之间发生中断，则会导致所有用户的呼叫被释放，导致大面积通信安全事件，而本发明各实施例通过旁路操作可以由S-CSCF设备将用户呼叫触发到其他未发生故障的AS，进而有效地避免了这种所有用户均无法呼入呼出的严重影响通信安全的大面积通信安全事件的发生。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

如图6所示，为本发明S-CSCF设备的一实施例的结构示意图。在本实施例中，S-CSCF设备包括：业务检测模块1、故障确认模块2和旁路处理模块3。其中，业务检测模块1负责在接收到呼叫请求后，检测与AS列表中的AS之间的通信信令，判断AS的业务是否中断。故障确认模块2负责在判断AS的业务中断时，确定AS为故障AS。旁路处理模块3负责根据IFC继续完成AS列表中除故障AS之外的AS的业务触发和后续呼叫处理。

如图7所示，为本发明S-CSCF设备的另一实施例的结构示意图。与上一实施例相比，本实施例还包括：规则获取模块4和列表确定模块5。规则获取模块4负责从HSS下载IFC。列表确定模块5，用于根据IFC和呼叫流程确定需要触发的AS列表。

在本实施例中，业务检测模块1可以具体包括：链路创建单元，用于创建到AS列表中的各个AS的会话初始协议链路；消息发送模块，用于向各个AS发送选项消息；响应接收模块，用于接收各个AS对选项消息返回的响应消息；故障确认模块还用于根据是否在配置的重发次数内获得响应来判断S-CSCF设备与每个AS之间的连接是否中断，进而根据判断结果确定AS的业务是否中断。

在S-CSCF设备中还可以针对每个AS设置特定的旁路策略，该旁路策略主要包括旁路方式是手工方式还是自动方式，该AS是否允许旁路操作等。

在S-CSCF设备的另一实施例中，还可以包括旁路策略模块和策略判断模块，其中旁路策略模块用于保存为各个应用服务器预先设定的旁路策略，所述旁路策略为手工方式或自动方式，其中手动方式的开关配置包括允许和不允许的选项。策略判断模块用于当接收到呼叫请求时，对所述应用服务器列表中的各个应用服务器的旁路策略进行判断，对于所述旁路策略为手动方式的允许选项的情况，则直接对采用该旁路策略的应用服务器执行旁路操作；对于所述旁路策略为手动方式的不允许选项的情况，则不对采用该旁路策略的应用服务器执行旁路操作；对于所述旁路策略为自动方式的情况，则继续检测与该应用服务器之间的通信信令，以判断该应用服务器的业务是否中断，再根据中断情况执行相应的旁路操作。

如图8所示，为本发明S-CSCF设备的又一实施例的结构示意图。与上一实施例相比，本实施例还包括话单标识模块6，该模块用于在完成AS列表中除故障AS之外的AS的业务触发和后续呼叫处理之后，在形成的话单中对未进行业务触发的AS进行标识，以便计费系统在处理话单时可以根据该标识进行相应的计费处理。

本发明S-CSCF设备实施例通过与AS之间的通信信令检测机制检测各个AS业务是否中断，并根据IFC旁路故障的AS，对除故障AS之外的其他AS进行触发以及后续的呼叫处理。通过这种旁路处理的方式，可以确保用户呼叫不会因为某个AS故障而导致中断。而对于S-CSCF与PES/PSS AS之间的中断情况，通过旁路操作可以最大程度保障用户的通信安全，大大降低IMS业务大面积中断的可能性。

最后应当说明的是：以上实施例仅用以说明本发明的技术方案而非对其限制；尽管参照较佳实施例对本发明进行了详细的说明，所属领域的普通技术人员应当理解：依然可以对本发明的具体实施方式进行修改或者对部分技术特征进行等同替换；而不脱离本发明技术方案的精神，其均应涵盖在本发明请求保护的技术方案范围当中。