CN112671723B - 呼叫控制系统、方法及计算机可读介质 - Google Patents

Abstract

本申请提供了一种呼叫控制方案，该方案采用的系统至少包括了会话边界控制单元、交换单元、呼叫服务单元和呼叫服务门户单元，用于为上层业务系统提供呼叫控制服务，所述交换单元和呼叫服务单元的数量为多个，且所述交换单元和呼叫服务单元一一对应。通过共享的消息队列和内存数据库以及合理的交互处理流程，可以方便地跟踪呼叫状态，并对各个呼叫进行全局的管理，以适应分布式场景下交换单元和呼叫服务单元按需进行水平扩展的需求，使得本申请的方案可以通过廉价的计算资源按需水平扩展，提升并发处理能力。

Description

呼叫控制系统、方法及计算机可读介质

技术领域

本申请涉及信息技术领域，尤其涉及一种呼叫控制系统、方法及计算机可读介质。

背景技术

现代通信系统里，呼叫控制与媒体处理是最核心的两大类功能。随着云计算平台的成熟和网络的普及，把传统的语音通信系统迁移到云端有非常多的好处，例如云资源可以按需付费，不需要昂贵的专用设备，节约设备成本以及运维成本。

现有互联网的语音通信平台大部分使用了开源的软交换系统，如FreeSWITCH(以下简称FS)，FS是一个独立的PBX(Private Branch Exchange，小型语音交换机)，单个处理节点的处理能力有限，往往只有300-500并发呼叫处理的能力。如果提升单个虚拟机的处理能力，就和传统单一节点的架构一样，无法发挥云计算的优势。因此，互联网的语音平台很多采用了分布式处理模式，但是目前并没有用于对分布式语音呼叫系统进行呼叫控制的成熟方案。

发明内容

本申请实施例提供了一种呼叫控制系统、方法及计算机可读介质，以解决目前缺少对分布式语音呼叫系统进行呼叫控制的成熟方案的问题。

本申请实施例提供了一种呼叫控制系统，该系统至少包括会话边界控制单元、交换单元、呼叫服务单元和呼叫服务门户单元，用于为上层业务系统提供呼叫控制服务，所述交换单元和呼叫服务单元的数量为多个，且所述交换单元和呼叫服务单元一一对应；

所述会话边界控制单元，用于根据终端发起的呼叫向一个交换单元发送第一呼叫请求；

所述交换单元，用于根据所述会话边界控制单元发送的第一呼叫请求创建相应的呼叫标识和呼叫事件，以及对第二呼叫请求进行处理，完成呼叫；

所述呼叫服务单元，用于将对应交换单元创建的呼叫事件发送至消息队列，以使所述上层业务系统从消息队列中获取订阅的呼叫事件进行相应处理；将呼叫标识保存至内存数据库；以及控制对应的交换单元对第二呼叫请求进行处理，完成呼叫；

所述呼叫服务门户单元，用于获取来自上层业务系统的第二呼叫请求，在所述第二呼叫请求是基于所述呼叫事件对应的第一呼叫请求进行后续操作的请求时，在内存数据库中查找对应的呼叫标识，并根据所述呼叫标识将第二呼叫请求发送给对应的呼叫服务单元；在所述第二呼叫请求是用于发起新呼叫的请求时，创建相应的呼叫标识保存，并将包括所述呼叫标识的第二呼叫请求发送给一个呼叫服务单元。

进一步地，所述内存数据库还存储有呼叫的上下文信息；

所述呼叫服务门户单元，还用于在交换单元发生故障时，根据负载情况确定用于替代的交换单元，并向用于替代的交换单元所对应的呼叫服务单元发送包括目标呼叫标识的恢复命令，其中，所述目标呼叫标识对应于故障的交换单元所管理的呼叫；

所述呼叫服务单元，还用于在其对应的交换单元确定为替代的交换单元时，基于目标呼叫标识从内存数据库中查找呼叫的上下文信息，并根据所述上下文信息控制对应的交换单元恢复目标呼叫标识对应的呼叫。

进一步地，所述会话边界控制单元，用于在获取到外部终端发起的呼叫时，根据负载情况从多个交换单元中确定一个交换单元，并根据终端发起的呼叫向所述交换单元发送第一呼叫请求。

进一步地，所述呼叫服务门户单元，用于在所述第二呼叫请求是用于发起新呼叫的请求时，创建相应的呼叫标识，根据负载情况从多个交换单元中确定一个交换单元，并将包括所述呼叫标识的第二呼叫请求发送给所述交换单元对应的呼叫服务单元。

进一步地，所述呼叫服务门户单元的数量设有多个，通过负载均衡器获取来自上层业务系统的第二呼叫请求。

本申请实施例还提供了一种呼叫控制方法，所述方法应用于包括会话边界控制单元、交换单元、呼叫服务单元和呼叫服务门户单元的呼叫控制系统，用于为上层业务系统提供呼叫控制服务，所述交换单元和呼叫服务单元的数量为多个，且所述交换单元和呼叫服务单元一一对应，所述方法包括：

所述会话边界控制单元根据终端发起的呼叫向一个交换单元发送第一呼叫请求；

所述交换单元根据所述会话边界控制单元发送的第一呼叫请求创建相应的呼叫标识和呼叫事件；

所述呼叫服务单元将对应交换单元创建的呼叫事件发送至消息队列，以使所述上层业务系统从消息队列中获取订阅的呼叫事件进行相应处理，并将呼叫标识保存至内存数据库；

所述呼叫服务门户单元获取来自上层业务系统的第二呼叫请求，在所述第二呼叫请求是基于所述呼叫事件对应的第一呼叫请求进行后续操作的请求时，在内存数据库中查找对应的呼叫标识，并根据所述呼叫标识将第二呼叫请求发送给对应的呼叫服务单元；

所述呼叫服务单元获取第二呼叫请求，并控制对应的交换单元对第二呼叫请求进行处理，完成呼叫。

进一步地，所述方法还包括：

所述呼叫服务门户单元在所述第二呼叫请求是用于发起新呼叫的请求时，创建相应的呼叫标识，并将包括所述呼叫标识的第二呼叫请求发送给一个呼叫服务单元。

进一步地，所述内存数据库还存储有呼叫的上下文信息，所述方法还包括：

所述呼叫服务门户单元在交换单元发生故障时，根据负载情况确定用于替代的交换单元，并向用于替代的交换单元所对应的呼叫服务单元发送包括目标呼叫标识的恢复命令，其中，所述目标呼叫标识对应于故障的交换单元所管理的呼叫；

所述呼叫服务单元在其对应的交换单元确定为替代的交换单元时，基于目标呼叫标识从内存数据库中查找呼叫的上下文信息，并根据所述上下文信息控制对应的交换单元恢复目标呼叫标识对应的呼叫。

本申请实施例还提供了另一种呼叫控制系统，其中，该设备包括用于存储计算机程序指令的存储器和用于执行计算机程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述设备执行所述呼叫控制方法。

此外，本申请还提供了一种计算机可读介质，其上存储有计算机程序指令，所述计算机可读指令可被处理器执行以实现所述呼叫控制方法。

相较于现有技术，本申请实施例提供的呼叫控制系统至少包括了会话边界控制单元、交换单元、呼叫服务单元和呼叫服务门户单元，用于为上层业务系统提供呼叫控制服务，所述交换单元和呼叫服务单元的数量为多个，且所述交换单元和呼叫服务单元一一对应。通过共享的消息队列和内存数据库以及合理的交互处理流程，可以方便地跟踪呼叫状态，并对各个呼叫进行全局的管理，以适应分布式场景下交换单元和呼叫服务单元按需进行水平扩展的需求，使得本申请的方案可以通过廉价的计算资源按需水平扩展，提升并发处理能力。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1为本申请实施例提供的一种呼叫控制系统的结构示意图；

图2为本申请实施例提供的采用了多个呼叫服务门户单元的呼叫控制系统的结构示意图；

图3为本申请实施例的方案实现呼叫控制方法时的一种交互流程示意图；

图4为本申请实施例的方案实现呼叫控制方法时的另一种交互流程示意图；

图5为本申请实施例的方案实现故障恢复时的示意图；

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在本申请一个典型的配置中，终端、服务网络的设备均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体，可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

本申请实施例提供的呼叫控制系统至少包括了会话边界控制单元、交换单元、呼叫服务单元和呼叫服务门户单元，用于为上层业务系统提供呼叫控制服务，所述交换单元和呼叫服务单元的数量为多个，且所述交换单元和呼叫服务单元一一对应。通过共享的消息队列和内存数据库以及合理的交互处理流程，可以方便地跟踪呼叫状态，并对各个呼叫进行全局的管理，以适应分布式场景下交换单元和呼叫服务单元按需进行水平扩展的需求，使得本申请的方案可以通过廉价的计算资源按需水平扩展，提升并发处理能力。

图1示出了本申请实施例提供的一种呼叫控制系统的结构，该系统至少包括了会话边界控制单元100、交换单元200、呼叫服务单元300和呼叫服务门户单元400，从而为上层业务系统500提供呼叫控制服务。

所述交换单元和呼叫服务单元的数量均设置有多个，且所述交换单元和呼叫服务单元一一对应，例如其中一个交换单元200-1与呼叫服务单元300-1对应。

所述会话边界控制单元100用于根据终端600发起的呼叫向一个交换单元发送第一呼叫请求。其中，所述终端600可以是外部的终端也可以是内部的终端，外部的终端通过运营商线路700作为中继与会话边界控制单元100进行交互，而内部的终端则无需通过运营商线路700直接与会话边界控制单元100进行交互。

所述交换单元200用于根据所述会话边界控制单元发送的第一呼叫请求创建相应的呼叫标识和呼叫事件，以及对第二呼叫请求进行处理，完成呼叫。

所述呼叫服务单元300用于将对应交换单元创建的呼叫事件发送至消息队列，以使所述上层业务系统从消息队列中获取订阅的呼叫事件进行相应处理；将呼叫标识保存至内存数据库；以及控制对应的交换单元对第二呼叫请求进行处理，完成呼叫。

所述呼叫服务门户单元400用于获取来自上层业务系统500的第二呼叫请求。在不同情况下，上层业务系统会向呼叫门户单元发送不同的第二呼叫请求。例如，在呼入场景中，呼入的呼叫由终端600发起，经由运营商线路700或者是直接发至边界控制单元100，然后由边界控制单元向一个交换单元200发起第一呼叫请求，并由该组交换单元/呼叫服务单元进行处理，使得上层业务系统可以获得订阅的呼叫事件，从而发出用于对该第一呼叫事件进行后续操作(如应答、挂断、保持等)的第二呼叫请求。而在呼出场景中，是由上层业务系统500主动对外(即向终端600)发起呼叫，此时的第二呼叫请求与第一呼叫请求无关，并非用于对第一呼叫请求进行后续操作，而是用于发起新呼叫。

由此，对于呼叫服务门户单元400而言，可以在不同情况下进行不同的处理。例如，在所述第二呼叫请求是基于所述呼叫事件对应的第一呼叫请求进行后续操作的请求时，可以在内存数据库中查找对应的呼叫标识，并根据所述呼叫标识将第二呼叫请求发送给对应的呼叫服务单元；而在所述第二呼叫请求是用于发起新呼叫的请求时，可以创建相应的呼叫标识保存，并将包括所述呼叫标识的第二呼叫请求发送给一个呼叫服务单元。

在实际场景中，所述会话边界控制单元100可以采用SBC(Session BorderController，会话边界控制器)，连接运营商线路，作为连接外部通信网络的通道，可以基于SIP(Session Initiation Protocol，会话初始协议)对外部呼叫请求的进行处理。此外，SBC也可以不通过运营商线路连接内部的终端，以实现对内部呼叫请求的处理。

交换单元200可以采用PBX(Private Branch Exchange，小型语音交换机)，用于将呼叫请求转接至特定的话机；呼叫服务单元300可以采用CS(Call Server，呼叫服务器)，用于控制PBX，一个CS控制一个PBX单元，CS是控制PBX的代理，同时CS还负责收集PBX的事件，把事件发送到消息队列。

呼叫服务门户单元400可以采用CSP(Call Server Portal，呼叫服务器门户)，并且可以集成CS-SDK(Call Server-Software Development Kit，呼叫服务器软件开发工具包)来识别收到的呼叫请求是新呼叫请求还是后续呼叫请求，并分别进行相应的处理，例如为新呼叫请求做负载均衡后发给CS，由CS控制PBX发起新呼叫，或者是对后续呼叫请求进行相应的转发、控制等。

在本申请的一些实施例中，呼叫服务门户单元的数量也可以是设有多个，多个呼叫服务门户单元可以采用负载均衡器进行负载均衡。例如，CSP在获取来自上层业务系统的第二呼叫请求时，可以通过负载均衡器获取来自上层业务系统的第二呼叫请求。图2示出了采用了多个CSP的呼叫控制系统的结构示意图，其中，负载均衡器800可以采用通用的HTTP负载均衡器，如F5、haproxy等，来确保CSP的高可用性。

图3示出了上述呼叫控制系统实现呼叫控制方法时的一种交互流程，该交互流程实现的是呼入的处理过程，包括以下步骤：

步骤S301，会话边界控制单元100根据终端600发起的呼叫向一个交换单元发送第一呼叫请求。例如，当终端600是外部终端时可以是普通的用户通过手机拨打客服电话，此时手机会通过运营商线路向会话边界控制单元100发起一个呼叫，会话边界控制单元100根据终端600发起的呼叫向其中一个交换单元200发送第一呼叫请求。

由于系统中呼叫单元200的数量有多个，因此会话边界控制单元100在发送第一呼叫请求时进行负载均衡的处理。由此，会话边界控制单元可以在获取到外部终端发起的呼叫时，根据负载情况从多个交换单元中确定一个交换单元，并根据终端发起的呼叫向所述交换单元发送第一呼叫请求。例如，若呼叫控制系统中有10个PBX，SBC可以选择其中负载最低的一个PBX作为目标来分配第一呼叫请求。

步骤S302，交换单元200根据所述会话边界控制单元发送的第一呼叫请求创建相应的呼叫标识和呼叫事件。对于呼入的呼叫，呼叫标识Call-ID由交换单元200创建，此时的呼叫状态为振铃，因此会创建振铃的呼叫事件。

步骤S303，呼叫服务单元300将对应交换单元200创建的呼叫事件发送至消息队列MQ，并将呼叫标识保存至内存数据库DB。

步骤S304，所述上层业务系统500若订阅了相应的呼叫事件，可以从消息队列MQ中获取订阅的呼叫事件进行相应处理。例如，若上层业务系统为客服电话常用ACD(AutomaticCall Distribution，自动呼叫分配)系统，该ACD系统订阅了振铃的呼叫事件，此时可以从消息队列中有新的振铃事件加入后，ACD系统可以将该次呼入分配至相应的坐席进行接听。此时，ACD系统作为上层业务系统可以向呼叫门户单元发送将来自终端的呼叫转接至某一个坐席的第二呼叫请求。

步骤S305，所述呼叫服务门户单元400获取来自上层业务系统500的第二呼叫请求。

步骤S306，在呼入场景中，所述第二呼叫请求是基于所述呼叫事件对应的第一呼叫请求进行后续操作的请求。例如对于ACD系统，所述后续操作即为转接至某一个坐席的操作。此时，所述呼叫服务门户单元400可以在内存数据库BD中查找对应的呼叫标识Call-ID，并根据所述呼叫标识Call-ID将第二呼叫请求发送给对应的呼叫服务单元。

在实际场景中，由于呼入的Call-ID由交换单元200创建，因此呼叫服务单元将交换单元创建的Call-ID保存至内存数据库时，可以与呼叫服务单元的标识CS-ID一起保存。此外，由于交换单元与呼叫服务单元一一对应，交换单元的标识PBX-ID与呼叫服务单元的标识CS-ID也一一对应，因此，可以建立这些标识之间的映射关系，由此呼叫服务门户单元400可以根据所述呼叫标识Call-ID将第二呼叫请求发送给对应的呼叫服务单元，并由相应的交换单元完成处理。

步骤S307，所述呼叫服务单元300获取第二呼叫请求，并控制对应的交换单元200对第二呼叫请求进行处理，完成呼叫。以本实施例中用户拨打客服电话为例，PBX作为交换单元第二呼叫请求进行处理为将呼叫请求转发至对应的坐席，完成呼叫的转接，使得用户可以与对应的坐席通话。

上述呼叫控制系统在对呼出进行控制时，上层业务系统向呼叫控制系统发送的第二呼叫请求是用于发起新呼叫的请求，此时交互处理流程如图4所示，包括以下步骤：

步骤S401，上层业务系统500向呼叫服务门户单元400发送第二呼叫请求。在该场景中，该第二呼叫请求是用于发起新呼叫的请求，而非是基于呼叫事件对应的第一呼叫请求进行后续操作的请求，用户向外部的终端发起呼叫。例如，在客服向用户的手机拨打营销电话的场景，即为客服系统的一个坐席通过系统的软电话客户端发起一个外呼请求，将MakeCall的请求发送呼叫服务门户单元CSP中。

与呼入场景中类似，在呼出场景中，呼叫服务门户单元的数量也可以是设有多个，多个呼叫服务门户单元可以采用负载均衡器进行负载均衡。例如，CSP在获取来自上层业务系统的第二呼叫请求时，可以通过负载均衡器获取来自上层业务系统的第二呼叫请求。

步骤S402，呼叫服务门户单元400创建相应的呼叫标识，并将包括所述呼叫标识的第二呼叫请求发送给一个呼叫服务单元。以前述场景为例，呼叫服务门户单元CSP在收到MakeCall的请求后，就会生成响应的呼叫标识Call-ID。

由于设置有多组交换单元/呼叫服务单元，在发送第二呼叫请求时，为了提高系统的可用性也可以采用负载均衡机制。由此，所述呼叫服务门户单元在所述第二呼叫请求是用于发起新呼叫的请求时，创建相应的呼叫标识保存至内存数据库，根据负载情况从多个交换单元中确定一个交换单元，例如，可以选择负载最低或者是负载相对较低的某一个，然后将第二呼叫请求发送给所述交换单元对应的呼叫服务单元。

步骤S403，所述呼叫服务单元获取第二呼叫请求，将第二呼叫请求的呼叫标识保存至内存数据库中，并控制对应的交换单元对第二呼叫请求进行处理，完成呼叫。此外，在本申请实施例中，所述第二呼叫请求是指由上层业务系统发出的、用户实现呼叫的请求。在具体场景中，根据呼叫机制的不同，所述第二呼叫请求可以表示一个具体的请求，也可以是一组相关的请求。例如，在外呼(即呼出)场景中，客服系统的一个坐席通过系统的软电话客户端发起一个外呼请求，将MakeCall的请求发送给CSP后，CSP可以拦截该MakeCall的请求，生成Call-ID后，重新发起一个包含Call-ID的新请求给PBX/CS进行处理，完成外呼。在该场景中，所述第二呼叫请求即为在实现外呼时的一些列相关请求。

在本申请的另一些实施中，所述内存数据库还存储有呼叫的上下文信息，所述上下文信息可以一个呼叫能够顺利建立的必要信息，例如与会话边界控制单元的所有信令、媒体对接的地址信息和路由信息等，在实际场景中，可以由相应的处理单元在获取或生成这些信息后上传至共享的内存数据库中，以用于在某个交换单元发生故障时，切换至其它交换单元实现故障的恢复。

由此，在本实施例中，所述呼叫服务门户单元400还用于在交换单元发生故障时，根据负载情况确定用于替代的交换单元，并向用于替代的交换单元所对应的呼叫服务单元发送包括目标呼叫标识的恢复命令，其中，所述目标呼叫标识对应于故障的交换单元所管理的呼叫。而呼叫服务单元300还用于在其对应的交换单元确定为替代的交换单元时，基于目标呼叫标识从内存数据库中查找呼叫的上下文信息，并根据所述上下文信息控制对应的交换单元恢复目标呼叫标识对应的呼叫。

例如，以图5所示的场景为例，当交换单元200-1故障时，呼叫服务门户单元400根据负载情况确定用于替代的交换单元是交换单元200-2，此时其对应的呼叫服务单元是300-2，该呼叫服务单元300-2会基于目标呼叫标识Call-ID从内存数据库中查找呼叫的上下文信息，并根据所述上下文信息控制对应的交换单元200-2恢复目标呼叫标识对应的呼叫。

由于所述交换单元和呼叫服务单元是一一对应的，因此可以通过云计算平台采用分布式的构架在对交换单元和呼叫服务单元进行水平扩展，使得本申请实施例提供的呼叫控制系统能够通过廉价的计算资源按需水平扩展，提升并发处理能力。同时，通过将上下文信息保存至内存数据库中，可以在某一交换单元发生故障时，进行快速切换实现故障恢复，提升了系统的可靠性。

此外，本申请实施例的方案中还可以提供IVR(互动式语音应答)服务。由此，在呼入场景中，交换单元可以识别呼入类型，如果被叫号码是IVR类型,由当前交换单元处理,激活对应的IVR流程；如果是上层业务系统的呼入类型，如ACD系统，则发送路由请求事件给ACD服务，由ACD系统通过呼叫服务门户单元发送路由处理请求，完成呼叫的转接。其中，IVR服务的系统可以直接利用云计算平台中的计算资源来部署，与交换单元共享云计算平台计算资源，无需单独部署专用的IVR服务器，节约了专用的IVR系统，使得方案实现更加简单。

此外，本申请实施例还提供了另一种呼叫控制系统，该系统包括用于存储计算机程序指令的存储器和用于执行计算机程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述设备执行前述的呼叫控制方法。

特别地，本申请实施例中的方法和/或实施例可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在该计算机程序被处理单元执行时，执行本申请的方法中限定的上述功能。

需要说明的是，本申请所述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言或其组合来编写用于执行本申请的操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

附图中的流程图或框图示出了按照本申请各种实施例的设备、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的针对硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个计算机可读指令，所述计算机可读指令可被处理器执行以实现前述本申请的多个实施例的方法和/或技术方案。

需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一些实施例中，本申请的软件程序可以通过处理器执行以实现上文步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

Claims (10)

1.一种呼叫控制系统，其中，该系统至少包括会话边界控制单元、交换单元、呼叫服务单元和呼叫服务门户单元，用于为上层业务系统提供呼叫控制服务，所述交换单元和呼叫服务单元的数量为多个，且所述交换单元和呼叫服务单元一一对应；

所述会话边界控制单元，用于根据终端发起的呼叫向一个交换单元发送第一呼叫请求；

所述交换单元，用于根据所述会话边界控制单元发送的第一呼叫请求创建相应的呼叫标识和呼叫事件，以及对第二呼叫请求进行处理，完成呼叫；

所述呼叫服务单元，用于将对应交换单元创建的呼叫事件发送至消息队列，以使所述上层业务系统从消息队列中获取订阅的呼叫事件进行相应处理；将呼叫标识保存至内存数据库；以及控制对应的交换单元对第二呼叫请求进行处理，完成呼叫；

所述呼叫服务门户单元，用于获取来自上层业务系统的第二呼叫请求，在所述第二呼叫请求是基于所述呼叫事件对应的第一呼叫请求进行后续操作的请求时，在内存数据库中查找对应的呼叫标识，并根据所述呼叫标识将第二呼叫请求发送给对应的呼叫服务单元；在所述第二呼叫请求是用于发起新呼叫的请求时，创建相应的呼叫标识保存，并将包括所述呼叫标识的第二呼叫请求发送给一个呼叫服务单元。

2.根据权利要求1所述的系统，其中，所述内存数据库还存储有呼叫的上下文信息；

所述呼叫服务门户单元，还用于在交换单元发生故障时，根据负载情况确定用于替代的交换单元，并向用于替代的交换单元所对应的呼叫服务单元发送包括目标呼叫标识的恢复命令，其中，所述目标呼叫标识对应于故障的交换单元所管理的呼叫；

所述呼叫服务单元，还用于在其对应的交换单元确定为替代的交换单元时，基于目标呼叫标识从内存数据库中查找呼叫的上下文信息，并根据所述上下文信息控制对应的交换单元恢复目标呼叫标识对应的呼叫。

3.根据权利要求1所述的系统，其中，所述会话边界控制单元，用于在获取到外部终端发起的呼叫时，根据负载情况从多个交换单元中确定一个交换单元，并根据终端发起的呼叫向所述交换单元发送第一呼叫请求。

4.根据权利要求1所述的系统，其中，所述呼叫服务门户单元，用于在所述第二呼叫请求是用于发起新呼叫的请求时，创建相应的呼叫标识，根据负载情况从多个交换单元中确定一个交换单元，并将包括所述呼叫标识的第二呼叫请求发送给所述交换单元对应的呼叫服务单元。

5.根据权利要求1所述的系统，其中，所述呼叫服务门户单元的数量设有多个，通过负载均衡器获取来自上层业务系统的第二呼叫请求。

6.一种呼叫控制方法，其中，所述方法应用于包括会话边界控制单元、交换单元、呼叫服务单元和呼叫服务门户单元的呼叫控制系统，用于为上层业务系统提供呼叫控制服务，所述交换单元和呼叫服务单元的数量为多个，且所述交换单元和呼叫服务单元一一对应，所述方法包括：

所述会话边界控制单元根据终端发起的呼叫向一个交换单元发送第一呼叫请求；

所述交换单元根据所述会话边界控制单元发送的第一呼叫请求创建相应的呼叫标识和呼叫事件；

所述呼叫服务单元将对应交换单元创建的呼叫事件发送至消息队列，以使所述上层业务系统从消息队列中获取订阅的呼叫事件进行相应处理，并将呼叫标识保存至内存数据库；

所述呼叫服务门户单元获取来自上层业务系统的第二呼叫请求，在所述第二呼叫请求是基于所述呼叫事件对应的第一呼叫请求进行后续操作的请求时，在内存数据库中查找对应的呼叫标识，并根据所述呼叫标识将第二呼叫请求发送给对应的呼叫服务单元；

所述呼叫服务单元获取第二呼叫请求，并控制对应的交换单元对第二呼叫请求进行处理，完成呼叫。

7.根据权利要求6所述的方法，其中，所述方法还包括：

所述呼叫服务门户单元在所述第二呼叫请求是用于发起新呼叫的请求时，创建相应的呼叫标识，并将包括所述呼叫标识的第二呼叫请求发送给一个呼叫服务单元。

8.根据权利要求6所述的方法，其中，所述内存数据库还存储有呼叫的上下文信息，所述方法还包括：

所述呼叫服务门户单元在交换单元发生故障时，根据负载情况确定用于替代的交换单元，并向用于替代的交换单元所对应的呼叫服务单元发送包括目标呼叫标识的恢复命令，其中，所述目标呼叫标识对应于故障的交换单元所管理的呼叫；

所述呼叫服务单元在其对应的交换单元确定为替代的交换单元时，基于目标呼叫标识从内存数据库中查找呼叫的上下文信息，并根据所述上下文信息控制对应的交换单元恢复目标呼叫标识对应的呼叫。

9.一种呼叫控制系统，其中，该系统包括用于存储计算机程序指令的存储器和用于执行计算机程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述系统执行权利要求6至8中任一项所述的方法。

10.一种计算机可读介质，其上存储有计算机程序指令，所述计算机程序指令可被处理器执行以实现如权利要求6至8中任一项所述的方法。

Images