CN101039199A - 呼叫处理方法、系统、应用服务器及交换设备 - Google Patents

Abstract

本发明应用于通信领域，提供一种呼叫处理方法以实现在应用资源不能提供业务时，可以选择放通呼叫或者释放呼叫。该呼叫处理方法包括：应用服务器接收交换设备触发的增值业务呼叫；以及在判断出当前的资源状态不能够提供所述增值业务时，根据预先设置的业务策略判断是否能够放通所述呼叫；在判断结果为能够放通所述呼叫时，向交换设备发送放通所述呼叫的通知；所述交换设备将所述增值业务呼叫按照未触发增值业务的呼叫处理。本发明还公开了一种呼叫处理系统、应用服务器及交换设备。

Description

呼叫处理方法、系统、应用服务器及交换设备

技术领域

本发明涉及通信技术领域，特别是涉及一种呼叫处理方法、系统、应用服务器及交换设备。

背景技术

基于IP的网络能够提供话音、数据、视频等多媒体综合业务，以NGN为例，下一代网络NGN(Next Generation Network)以软交换为核心，采用开放、标准体系结构，可以提供丰富的各类业务。人们习惯于把电话、电报之类通信网基本业务以外的业务称为增值业务，例如短信、彩信、彩铃等等。现在人们对增值业务的需求量和使用率与日俱增，提供增值业务的设备的支撑状况成为影响人们对增值业务满意度的重要问题。应用服务器AS(Application Server)是提供增值业务的设备之一，在现有技术中，AS在运行过程中出现资源不足或资源不可用的情况时，一般的处理是按比例丢弃呼叫或者全部丢弃呼叫。而实际上就呼叫来说，某些增值业务不一定是普通呼叫本身所必须的，例如彩铃，即个性化回铃音，用户开通这项业务后，对方在拨打该用户电话等候接通的时候，听到的就不再是“嘟......嘟......”的传统回铃音，而是该用户所设置的音乐或音效等，彩铃的出现丰富了沟通，但没有彩铃，也可以使用普通的回铃音接续呼叫，并不影响呼叫的正常进行。现有技术的处理，可以保护AS在异常情况下不受冲击，但呼叫无法接通毕竟给用户带来不便，对运营商来说降低了呼叫接通率，造成服务质量下降，也会带来不好的影响。并且在呼叫无法接通的情况下，用户一般会选择继续呼叫，连续的重呼会给通信系统造成更重的负荷，这种恶性循环也不利于系统快速恢复正常。

发明内容

本发明实施例提供呼叫处理方案，以实现在应用资源不能提供增值业务时，尽量不丢弃增值业务呼叫，而是将增值业务呼叫作为未触发增值业务的普通呼叫处理，以提高呼叫接通率。

本发明实施例中的一种呼叫处理方法，包括：

应用服务器接收交换设备触发的增值业务呼叫；以及

在判断出当前的资源状态不能够提供所述增值业务时，根据预先设置的业务策略判断是否能够放通所述呼叫；

在判断结果为能够放通所述呼叫时，向交换设备发送放通所述呼叫的通知；

所述交换设备将所述增值业务呼叫按照未触发增值业务的呼叫处理。

可选地，所述应用服务器在判断出当前自身的业务状态、业务提供资源状态、业务处理资源状态中的一项不能提供所述增值业务时，判定当前的资源状态不能够提供所述增值业务。

优选地，所述业务策略由下述原则中的至少一项构成：呼叫放通原则；增值业务优先级别原则。

当所述业务策略中包括增值业务优先级别原则时，应用服务器优先根据所述增值业务优先级别原则判断是否能够放通所述呼叫。所述应用服务器通过向交换设备发送携带有指示呼叫放通标识的通知消息实现向交换设备发送放通所述呼叫的通知。所述指示呼叫放通标识为消息ID或消息头中指定的原因值。

本发明实施例中的一种呼叫处理系统，包括交换设备和应用服务器，其中，

应用服务器，用于接收交换设备触发的增值业务呼叫，并在判断出当前的资源状态不能够提供所述增值业务时，根据预先设置的业务策略判断是否能够放通所述呼叫，以及在判断得出能够放通所述呼叫时，向交换设备发送放通所述呼叫的通知；

交换设备，用于在收到应用服务器发送的放通所述呼叫的通知时，将所述增值业务呼叫按照未触发增值业务的呼叫处理。

优选地，所述应用服务器通过向交换设备发送携带有指示呼叫放通标识的通知消息实现向交换设备发送放通所述呼叫的通知。

本发明实施例中的一种应用服务器，包括接收模块、资源监控模块、裁决模块及通知模块，其中：

接收模块，用于接收交换设备触发的增值业务呼叫；

资源监控模块，用于监控并记录呼叫资源状态；根据接收模块接收到的呼叫，判断当前的资源状态是否能够提供所述增值业务；

裁决模块，用于在资源监控模块判断得出当前的资源状态不能提供所述增值业务时，调用预先设置的业务策略，判断是否能够放通所述呼叫；

通知模块，用于在裁决模块判断得出能够放通所述呼叫时，向交换设备发送放通所述呼叫的通知。

本发明实施例中的一种交换设备，包括：

接收单元，用于接收业务呼叫；

判断单元，用于判断接收单元接收到的业务呼叫是否为增值业务呼叫；

触发单元，用于将判断单元判断得出的增值业务呼叫触发到应用服务器；

呼叫处理单元，用于根据应用服务器发来的放通所述呼叫的通知消息将该呼叫按照未触发增值业务的呼叫进行处理。

综上所述，本发明提供的实施例解决了在应用资源不能提供增值业务时，呼叫无法接通的问题，实现了在此情况下可以根据预先设置的业务策略选择是否放通增值业务呼叫，让增值业务丰富人们生活的同时，尽量减少可能会带来的负面问题，提高用户满意度。也避免因应用资源不能提供某些增值业务时，通信系统丢弃呼叫而可能带来的用户连续重呼，从而提高呼叫接通率，以及减轻通信系统的负荷，有利于通信系统快速恢复正常。

附图说明

为使本发明解决的技术问题、采用的技术方案及优点更加清楚明白，以下参照附图并举实施例，对本发明做进一步的详细阐述，各附图中：

图1为现有技术中NGN组网架构图；

图2为本发明一实施例中呼叫处理的信令图；

图3为本发明一实施例中呼叫处理的装置图；

图4为本发明一实施例中呼叫处理的系统图；

图5为本发明一实施例中交换设备的结构图。

具体实施方式

某些增值业务不一定是普通呼叫必须的，没有增值业务的附着，可以不影响正常呼叫的进行。例如彩铃，对于这样的业务，对用户来讲，希望在此类增值业务不可用或资源不足时，可以不影响正常的呼叫进行，以满足最普通的交流需求。

应用服务器可以根据不同的业务特征和用户的使用方式，在资源异常情况下实现对某些呼叫放通，放通指系统在特定情况下，使用与触发业务不同的简化或替代流程来处理和接续呼叫，如使用普通的未触发增值业务的接续方式，以不影响呼叫的接通。

例如：主叫(可以为用户或者终端)发送消息给交换设备，交换设备在不同的网络中名称不同，本实施例中以NGN网络中的软交换为例，软交换在收到该消息后，对随后的呼叫处理按照普通呼叫进行，而不触发那些资源异常的业务，例如不触发呼叫过程中的彩铃业务，以保证呼叫的正常接续，为用户提供更加周全的服务。

本发明一实施例可以基于IP的电信网络实现，此处以NGN网络架构为例给以描述，但并不构成对本发明的限制，NGN系统组网架构如附图1所示：

软交换100，用于业务触发、路由、呼叫接续，与应用服务器之间通过会话初始协议(SIP，Session Initiation Protocol)信令进行交互；软交换100判断呼叫属性，如果是增值业务，则触发相应的增值业务，将呼叫转发给应用服务器进行后续增值业务控制。

应用服务器(AS)300，用于装载和运行业务逻辑的服务器，为NGN网络提供丰富的业务；增值业务装载于AS中，对软交换触发来的呼叫根据业务逻辑进行控制。

媒体资源服务器(MRS，Media Resource Server)500，是IP网络中提供媒体增值服务的资源组件，在软交换设备、应用服务器等控制设备的控制下，为下一代网络提供媒体数据处理服务，如放音、收号、语音合成、语音识别、录音、传真以及视频会议等。

本发明的一种呼叫处理方法的实施例描述如下：

应用服务器接收交换设备触发的增值业务呼叫，判断当前的资源状态是否能够提供该增值业务，如果当前的资源不能提供该增值业务，例如当前的资源状态相对于触发的增值业务而言不足或不可用，则根据预先设置的业务策略判断是否能够放通该呼叫，在判断结果为能够放通该呼叫时，则向交换设备发送放通该呼叫的通知。交换设备在收到应用服务器的放通通知后，将该增值业务呼叫按照未触发增值业务的普通呼叫处理。当然根据预置的业务策略不同，应用服务器也可以向交换设备发送释放该呼叫的通知，实现根据预先设置的业务策略选择放通呼叫或者释放呼叫，交换设备收到释放呼叫的通知后，则丢弃该增值业务呼叫。这样的方案实现了在增值业务丰富人们生活的同时，尽量减少可能会带来的负面问题，从而提高用户满意度。

下面进一步举例来描述上述实施例中的具体方案：其中的交换设备可以是软交换；其中触发的呼叫可以描述为：软交换检查所接收呼叫的呼叫属性，如果该呼叫为增值业务呼叫，则将该呼叫触发至应用服务器。

其中判断当前的资源状态是指，主要是判断当前处理呼叫必需的资源状态；当前处理呼叫必需的资源状态通常包括但不限于：应用服务器自身的业务状态、业务提供资源状态、业务处理资源状态等等；其中，业务提供资源状态可以包括媒体资源服务器是否可用、内存是否足够、数据库是否正常、外置磁盘阵列是否正常等等；业务处理资源状态可以包括线程池是否满、有无空闲呼叫实例、消息队列是否满等等；当前的资源状态不能提供该增值业务是指当前的要满足该增值业务所需要的资源中存在不足或者不可用的情况，即当前处理呼叫必需的资源状态中有至少一项不足或者不可用，则无法提供该增值业务。

其中预先设置的业务策略可以包括呼叫放通原则、增值业务优先级别原则，也可以包括增值业务配合原则等其中之一或者多个，增值业务配合原则可以指，设置如何配合的原则，哪个原则被优先判定等信息，可能涉及多个原则的相互判定顺序等。如果某一增值业务的业务策略中包括有增值业务优先级别原则的设置内容，较佳的方案是AS优先根据增值业务优先级别原则判断是否放通该增值业务呼叫。例如对于某一项增值业务，可以将业务策略设置为：当处理呼叫所需要的资源不足或不可用时，应用服务器直接向交换设备发送指示放通该呼叫的通知消息。

预先设置的业务策略具体举例说明如下：

业务特性	是否可放通	优先级
			彩铃	是	2
预付费	否	1
			漏话通知	是	3

此例子中，一个呼叫触发的业务包含彩铃、预付费、漏话通知三个增值业务特性，根据业务处理策略，在超过一个增值业务特性时，该呼叫的放通属性取决于该呼叫的增值业务优先级特性。因为这里高优先级的增值业务特性为“预付费”，其对应的“是否可放通”属性为“否”，则表示该呼叫在提供增值业务的应用资源不足或不可用时不能被放通，只能释放。而如果只包括彩铃一个增值业务特性时，则根据业务策略的设置，该呼叫在提供增值业务的资源不足或不可用时可以被放通，因为其对应的“是否可放通”属性为“是”。

应用服务器可以在向交换设备发送的消息中携带指示呼叫放通或释放的标识来实现向交换设备发送放通呼叫或释放呼叫的通知，该标识可以是消息ID或消息头中指定原因值。

交换设备收到该通知消息后，对该呼叫按通知消息的请求进行后续放通该呼叫或者释放该呼叫的处理。

对于这样的业务处理，在此类业务的应用资源不可用或不足时，可以不影响普通呼叫的进行，对用户来讲，可以满足通常的交流需求。

参照附图2，呼叫处理的又一实施例流程描述如下：

1、主叫(通常是用户或者终端)发起呼叫至软交换。

2、软交换检查呼叫属性，判断该呼叫是否为增值业务呼叫；

3、如果是增值业务，软交换将该呼叫触发至应用服务器。

4、应用服务器判断实现该增值业务所需要的当前的资源状态和业务放通策略，当发现当前资源相对于该增值业务呼叫不足或不可用时，确定发送通知给软交换进行呼叫放通或呼叫释放；这里处理增值业务所需要的资源通常指处理呼叫必不可少的资源，如果其中一个资源不可用或者不足以提供该增值业务，则无法提供该增值业务。资源不可用或者不足的判定，可以依据网络的配置或者用户要求的内容来设定标准，可以是一门限值，如当资源使用率超过某个百分比可以设定为不可用；超过某个百分比为资源不足；或者依不同的业务需求可能占用的资源量不同来判定。

4.1若呼叫放通，则应用服务器发送呼叫放通请求给软交换，发送放通请求可以通过在向交换设备发送的消息中携带指示呼叫放通的标识来实现，该标识可以是消息ID或消息中指定的原因值。消息ID可以指消息名称，标识发送是什么消息，如发送一个响应消息，可以用消息ID来指出这是一个响应消息。消息中携带指定的原因值，可以为：如在SIP协议中的4XX/5XX消息reason头域中携带指示呼叫放通的原因值。之后的处理流程进入流程5。

4.2若呼叫释放，则应用服务器发送呼叫释放请求给软交换，发送释放请求可以通过在向交换设备发送的消息中携带指示呼叫释放的标识来实现，该标识可以是消息ID或消息头中指定的原因值。例如在SIP协议中的4XX/5XX消息reason头域中携带指示业务不可用、呼叫释放的原因值来实现。之后的处理流程进入流程8。

5、软交换收到携带呼叫放通的指示消息后，对该增值业务呼叫按未触发增值业务、以普通呼叫进行处理，路由到被叫，该呼叫的后续处理由软交换接管。

6、被叫应答；

7、被叫应答后，软交换通知主叫，完成主被叫间的媒体协商，建立话路，主被叫可以开始进行通话。

8、软交换收到携带呼叫释放的指示消息后，释放该增值业务呼叫。

本发明的一种呼叫处理系统的实施例参照附图3，描述如下：

一种呼叫处理系统，包括交换设备100和应用服务器300，交换设备在NGN网络中可以为软交换。其中：应用服务器300用于接收交换设备100触发的增值业务呼叫，并在判断出当前的资源状态不能够提供该增值业务时，即资源存在不足或不可用的情况时，根据预先设置的业务策略判断是否能够放通该呼叫，若判断得出能够放通该呼叫时，向交换设备100发送放通呼叫的通知消息；或判断得出不能够放通该呼叫时，向交换设备100发送释放呼叫的通知消息。

交换设备100用于检查用户提起的呼叫属性，判断该呼叫为增值业务呼叫时，将该呼叫触发至应用服务器300；以及在收到应用服务器300发送的放通该呼叫的请求消息时，将该呼叫按照未触发增值业务的普通呼叫来处理。

其中应用服务器300具体包括，参照附图4：接收模块301、资源监控模块302和裁决模块303，其中：

接收模块301，用于接收交换设备触发的增值业务呼叫；

资源监控模块302，用于监控并记录呼叫资源状态；根据接收模块301接收到的呼叫，判断当前的资源状态是否能够提供该增值业务；

裁决模块303，用于在资源监控模块判断得出当前的资源状态不能提供该增值业务时，调用预先设置的业务策略，判断是否向交换设备发送放通该呼叫的通知；

通知模块304，用于根据裁决模块的判断结果向交换设备100发送通知消息，如在裁决模块303判断得出能够放通所述呼叫时，向交换设备100发送放通该呼叫的通知消息；或者在裁决模块303判断得出能能够放通所述呼叫时，向交换设备100发送释放该呼叫的通知消息。

交换设备100收到来自应用服务器300的放通该呼叫的通知消息后，将该呼叫按照基本呼叫(也称普通呼叫，即不含增值业务的呼叫)进行处理，保证呼叫的正常接续，并生成话单。

本发明的一种应用服务器的实施例描述如下：

一种应用服务器，包括接收模块、资源监控模块、裁决模块及通知模块，其中：

接收模块，用于接收交换设备触发的增值业务呼叫；

资源监控模块，用于监控并记录呼叫资源状态；根据接收模块接收到的呼叫，判断当前的资源状态是否能够提供该增值业务，若否，则将当前资源状态不能提供该增值业务的情况提交给裁决模块；

裁决模块，用于在资源监控模块判断得出当前的资源状态不能提供该增值业务时，调用预先设置的业务策略，判断是否能够放通该呼叫；

通知模块，用于根据裁决模块的判断结果向交换设备发送通知消息，如在裁决模块判断得出能够放通所述呼叫时，向交换设备发送放通该呼叫的通知消息；或者在裁决模块判断得出能能够放通所述呼叫时，向交换设备发送释放该呼叫的通知消息。

参照附图4，一种应用服务器的又一实施例描述如下：

接收模块301，用于接收软交换触发来的增值业务呼叫；

资源监控模块302，用于监控呼叫资源，记录资源状态，如资源状态不足或不可用，如业务状态异常、线程池满、无空闲呼叫实例、媒体资源服务器不可用、内存不足、消息队列满等等影响提供该增值业务的资源状态。判断当前的资源状态是否能够提供该增值业务，若否，则将当前资源状态不能提供该增值业务的情况提交给裁决模块。这里的资源状态资源通常指处理该增值业务呼叫所必不可少的资源，这类资源一般会有多个，如内存、数据库等等，其中任何一个资源不可用，都可能无法继续处理该呼叫。

裁决模块303，根据接收模块301接收到的增值业务呼叫，及资源监控模块302所提交的呼叫资源情况，调用预先设置的业务策略，判断向软交换发送放通该呼叫的通知消息还是丢弃该呼叫的通知消息。预先设置的业务策略可以根据不同的增值业务特征，可以设置不同的业务策略，如对于某些增值业务或业务特性，当资源不足或不可用时，基本的呼叫信息无法获取，因此只能释放呼叫；而对于某些增值业务或业务特性，当资源不足或不可用时，基本的呼叫信息不受影响，可以进行基本的呼叫，因此可以放通此类呼叫。此类业务策略可以预置在AS中。

通知模块304，根据裁决模块303的判断结果向软交换发送通知消息。

本发明的一种交换设备的实施例参照附图5所示，交换设备100，包括接收单元101，判断单元102、触发单元103及呼叫处理单元104，其中：

接收单元101，用于接收业务呼叫；

判断单元102，用于判断接收单元接收到的业务呼叫是否为增值业务呼叫；

触发单元103，用于将判断单元判断是出的增值业务呼叫触发到应用服务器300；

呼叫处理单元104，用于根据应用服务器300发来的放通该呼叫的通知要求将该增值业务呼叫按照未触发增值业务的呼叫进行处理。

综上所述，本发明各实施例可以实现当应用服务器在资源异常时，按业务策略处理，依据增值业务的要求不同，对增值业务呼叫的处理也不同；在去掉不影响正常呼叫的增值业务特征后，正常接续呼叫，从而保证用户的通信需求，同时提高了呼叫的接通率。通过对呼叫放通的处理，避免用户连续重呼可能导致的系统负荷更重的情况，有利于系统尽快恢复正常。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims (12)

1、一种呼叫处理方法，其特征在于，包括：

应用服务器接收交换设备触发的增值业务呼叫；以及

在判断出当前的资源状态不能够提供所述增值业务时，根据预先设置的业务策略判断是否能够放通所述呼叫；

在判断结果为能够放通所述呼叫时，向交换设备发送放通所述呼叫的通知；

所述交换设备将所述增值业务呼叫按照未触发增值业务的呼叫处理。

2、如权利要求1所述的方法，其特征在于，所述应用服务器在判断出当前自身的业务状态、业务提供资源状态、业务处理资源状态中的一项不能提供所述增值业务时，判定当前的资源状态不能够提供所述增值业务。

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

所述业务策略由下述原则中的至少一项构成：

呼叫放通原则；

增值业务优先级别原则。

4、如权利要求3所述的方法，其特征在于，所述业务策略还可以包括增值业务配合原则。

5、如权利要求4所述的方法，其特征在于，

当所述业务策略中包括增值业务优先级别原则时，应用服务器优先根据所述增值业务优先级别原则判断是否能够放通所述呼叫。

6、如权利要求1或2所述的方法，其特征在于，所述应用服务器通过向交换设备发送携带有指示呼叫放通标识的通知消息实现向交换设备发送放通所述呼叫的通知。

7、如权利要求6所述的方法，其特征在于，所述指示呼叫放通标识为消息ID或消息中指定的原因值。

8、一种呼叫处理系统，其特征在于，包括交换设备和应用服务器，其中，

应用服务器，用于接收交换设备触发的增值业务呼叫，并在判断出当前的资源状态不能够提供所述增值业务时，根据预先设置的业务策略判断是否能够放通所述呼叫，以及在判断得出能够放通所述呼叫时，向交换设备发送放通所述呼叫的通知；

交换设备，用于在收到应用服务器发送的放通所述呼叫的通知时，将所述增值业务呼叫按照未触发增值业务的呼叫处理。

9、如权利要求8所述的系统，其特征在于，所述应用服务器具体包括接收模块、资源监控模块和裁决模块，其中：

接收模块，用于接收交换设备触发的增值业务呼叫；

资源监控模块，用于监控并记录呼叫资源状态；根据接收模块接收到的呼叫，判断当前的资源状态是否能够提供所述增值业务；

裁决模块，用于在资源监控模块判断得出当前的资源状态不能提供所述增值业务时，调用预先设置的业务策略，判断是否能够放通所述呼叫；

通知模块，用于在裁决模块判断得出能够放通所述呼叫时，向交换设备发送放通所述呼叫的通知。

10、如权利要求8或9所述的系统，其特征在于，所述应用服务器通过向交换设备发送携带有指示呼叫放通标识的通知消息实现向交换设备发送放通所述呼叫的通知。

11、一种应用服务器，其特征在于，包括接收模块、资源监控模块、裁决模块及通知模块，其中：

接收模块，用于接收交换设备触发的增值业务呼叫；

资源监控模块，用于监控并记录呼叫资源状态；根据接收模块接收到的呼叫，判断当前的资源状态是否能够提供所述增值业务；

裁决模块，用于在资源监控模块判断得出当前的资源状态不能提供所述增值业务时，调用预先设置的业务策略，判断是否能够放通所述呼叫；

通知模块，用于在裁决模块判断得出能够放通所述呼叫时，向交换设备发送放通所述呼叫的通知。

12、一种交换设备，其特征在于，包括：

接收单元，用于接收业务呼叫；

判断单元，用于判断接收单元接收到的业务呼叫是否为增值业务呼叫；

触发单元，用于将判断单元判断得出的增值业务呼叫触发到应用服务器；

呼叫处理单元，用于根据应用服务器发来的放通所述呼叫的通知消息将该呼叫按照未触发增值业务的呼叫进行处理。

Images