一种语音交互的系统及方法
技术领域
本申请涉及语音交互技术领域,尤其涉及一种语音交互的系统及方法。
背景技术
现有的语音交互(IVR)系统都是单机或多机并行,呼叫控制、媒体控制与交互的流程控制集中在一个控制系统里,通过语音交换系统,把呼叫转移到一个IVR设备上进行处理。而现有的语音交互系统单个节点发生故障时,无法保证呼叫的连续性,即当一个实例异常宕机或下线,该实例上的呼叫会消失,不具备交互的连续性以及高可靠性;另外,现有的语音交互系统,当有新的需求时需要在系统中重新增加一个新的操作节点以此来支持新的功能,额外增加系统开发任务。
发明内容
本申请的一个目的是提供一种语音交互的系统及方法,解决现有技术中系统不具备交互的连续性以及高可靠性,以及当有新的需求时需要增加新的操作节点用来支持新的操作的问题。
根据本申请的一个方面,提供了一种语音交互的系统,该系统包括:
呼叫控制单元、解释器、内存数据库及消息队列单元,
其中,所述呼叫控制单元用于根据接收到的呼叫请求查询所述内存数据库,识别出所述呼叫请求中的被呼叫号码;
所述消息队列单元用于接收所述呼叫控制单元基于识别出的被呼叫号码发送的呼叫启动消息;
所述解释器用于基于所述呼叫启动消息加载并开始执行对话流程,并将所述对话流程的执行结果及对话流程变量更新至所述内存数据库中;
所述内存数据库对应呼叫唯一标识信息的对话流程执行上下文,其中,所述上下文包括流程变量、流程名字以及流程节点指针位置。
进一步地,所述呼叫请求包括主叫号码、被呼叫号码、转接逻辑号码以及呼叫唯一标识信息,其中,所述被呼叫号码通过映射到所述转接逻辑号码上,所述转接逻辑号码用于进入所述主叫号码呼叫所述被呼叫号码时创建的当前语音交互会话,所述呼叫唯一标识信息用于标识识别所述当前语音交互会话。
进一步地,所述解释器用于将所述对话流程中每一节点的执行结果更新至所述内存数据库中,其中,所述对话流程中每一节点为所述对话流程中独立的执行代码块,所述执行代码块包括呼叫控制、语音播放、录音、接收按键、语音识别、调用外部接口。
进一步地,所述系统包括媒体服务模块,所述解释器用于通过HTTP协议向所述媒体服务模块或所述呼叫控制单元发送交互控制请求,其中,所述交互控制请求包括控制语音的请求或控制呼叫的请求。
进一步地,当所述交互控制请求为所述控制语音的请求时,所述解释器通过HTTP协议将所述控制语音转接至所述媒体服务模块;当所述交互控制请求为所述控制呼叫的请求时,所述解释器通过HTTP协议将所述控制呼叫转接至所述呼叫控制单元。
进一步地,所述媒体服务模块或所述呼叫控制单元持续检测基于所述消息队列单元转接来的交互控制请求确定的呼叫状态变化,将所述呼叫状态变化通过所述消息队列单元发送至所述解释器。
进一步地,所述解释器、所述媒体服务模块及所述呼叫控制单元根据执行所述消息队列单元中的消息确定执行角色类型,其中,所述执行角色类型包括生产者和消费者。
根据本申请又一个方面,还提供了一种语音交互的方法,该方法包括:
根据接收到的呼叫请求查询内存数据库,识别出所述呼叫请求中的被呼叫号码;
基于识别出的被呼叫号码发送呼叫启动消息,加载并开始执行对话流程,并将所述对话流程的执行结果及对话流程变量更新至所述内存数据库中;
按照所述内存数据库中对应的呼叫唯一标识信息的对话流程执行上下文,其中,所述上下文包括流程变量、流程名字以及流程节点指针位置。
进一步地,将所述对话流程的执行结果及对话流程变量更新至所述内存数据库中,包括:
将所述对话流程中每一节点的执行结果及对话流程变量更新至所述内存数据库中,其中,所述对话流程中每一节点为所述对话流程中独立的执行代码块,所述执行代码块包括呼叫控制、语音播放、录音、接收按键、语音识别、调用外部接口,所述对话流程变量包括流程过程中所有计算使用的变量值和流程执行的当前位置变化。
根据本申请再一个方面,还提供了一种计算机可读介质,其上存储有计算机可读指令,所述计算机可读指令可被处理器执行以实现如前述所述的方法。
与现有技术相比,本申请所述系统包括:呼叫控制单元、解释器、内存数据库及消息队列单元,其中,所述呼叫控制单元用于根据接收到的呼叫请求查询所述内存数据库,识别出所述呼叫请求中的被呼叫号码;所述消息队列单元用于接收所述呼叫控制单元基于识别出的被呼叫号码发送的呼叫启动消息;所述解释器用于基于所述呼叫启动消息加载并开始执行对话流程,并将所述对话流程的执行结果及对话流程变量更新至所述内存数据库中;所述内存数据库对应呼叫唯一标识信息的对话流程执行上下文,其中,所述上下文包括流程变量、流程名字以及流程节点指针位置。通过消息队列来接收呼叫信息的,多个实例都可能接收到消息,并且呼叫相关的信息都存储在内存数据库中,当其中有一个发生异常,如宕机或下线时,此实例上的呼叫相关的消息会转发给其他实例,其他实例会继续处理流程后续的消息和执行呼叫流程,由于呼叫相关信息保存在内存数据库里,后续的实例可以读取,因此未发生异常的实例可以接管未完成的呼叫流程,从而实现了交互的连续性以及高可靠性。
附图说明
通过阅读参照以下附图所作的对非限制性实施例所作的详细描述,本申请的其它特征、目的和优点将会变得更明显:
图1示出根据本申请的一个方面提供的一种语音交互的系统的结构示意图;
图2示出本申请一实施例中语音交互系统的框架示意图;
图3示出根据本申请又一个方面提供的一种语音交互的方法的流程示意图。
附图中相同或相似的附图标记代表相同或相似的部件。
具体实施方式
下面结合附图对本申请作进一步详细描述。
在本申请一个典型的配置中,终端、服务网络的设备和可信方均包括一个或多个处理器 (例如中央处理器(Central Processing Unit,CPU))、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器 (RandomAccess Memory,RAM) 和/或非易失性内存等形式,如只读存储器 (Read Only Memory,ROM) 或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存 (Phase-Change RAM,PRAM)、静态随机存取存储器 (Static Random Access Memory,SRAM)、动态随机存取存储器 (DynamicRandom Access Memory,DRAM)、其他类型的随机存取存储器 (RAM)、只读存储器 (ROM)、电可擦除可编程只读存储器 (Electrically Erasable Programmable Read-Only Memory,EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器 (Compact Disc Read-OnlyMemory,CD-ROM)、数字多功能光盘 (Digital Versatile Disk,DVD) 或其他光学存储、 磁盒式磁带,磁带磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括非暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
图1示出根据本申请的一个方面提供的一种语音交互的系统的结构示意图,该系统包括:呼叫控制单元11、解释器12、内存数据库13及消息队列单元14,其中,所述呼叫控制单元11用于根据接收到的呼叫请求查询所述内存数据库13,识别出所述呼叫请求中的被呼叫号码;所述消息队列单元14用于接收所述呼叫控制单元11基于识别出的被呼叫号码发送的呼叫启动消息;所述解释器12用于基于所述呼叫启动消息加载并开始执行对话流程,并将所述对话流程的执行结果及对话流程变量更新至所述内存数据库13中;所述内存数据库13对应呼叫唯一标识信息的对话流程执行上下文,其中,所述上下文包括流程变量、流程名字以及流程节点指针位置。在此,呼叫由网络进入系统后,由呼叫控制单元11(CallControl Unit,CCU)处理,CCU根据呼叫请求查询内存数据库13,识别出呼叫请求中的被号码是一个需要自动语音交互系统(VoiceInteraction System,VIS)处理的呼叫,则向消息队列(MQ)单元14发送呼叫启动的消息,以此来通知解释器12(SE)需要启动一个对话流程,该解释器12为用户自定义的交互流程的流程执行单元,通过SE加载并开始执行对话流程,在执行过程中,将每个节点执行的结果和流程变量更新到13中;通过消息队列MQ的增强算法和平衡算法、流程解释器内部执行线程以及缓冲管理、内存数据库对应呼叫唯一标识信息的呼叫流程执行上下文之间的配合,从而可以完成流程在任意解释器无缝执行,其中,执行上下文部分包括但不限于流程变量、流程名字和流程节点指针位置。本申请所述的系统通过消息队列来接收呼叫信息,多个实例都可能接收到消息,并且呼叫相关的信息都存储在内存数据库中,当其中一个实例异常宕机或下线时,另一个实例会继续处理流程后续的消息,由于呼叫相关信息不是保存在某一个处理节点上,而是在内存数据库中,任何实例异常关闭后,其他正常工作的实例都可以读取,因此其他的实例可以继续进行未完成的呼叫流程,从而实现了交互的连续性以及高可靠性。
在本申请一实施例中,所述呼叫请求包括主叫号码、被呼叫号码、转接逻辑号码以及呼叫唯一标识信息,其中,所述被呼叫号码通过映射到所述转接逻辑号码上,所述转接逻辑号码用于进入所述主叫号码呼叫所述被呼叫号码时创建的当前语音交互会话,所述呼叫唯一标识信息用于标识识别所述当前语音交互会话。在此,呼叫请求包括呼叫的会话请求信息,该会话请求信息包括主叫号码、原始被叫号码、转接VIS流程对应的逻辑号码以及呼叫唯一标识ID,其中,逻辑号码为当前VIS流程的入口号码,原始被叫号码通过一定规则可以映射到这个VIS入口号码上。呼叫唯一标识ID(UCID)是用来标识一个呼叫的所有信息,一个呼叫从系统到挂断有一个完整的生命周期,而该生命周期使用呼叫唯一标识ID进行标识。主叫号码在不同时间可以有多次呼叫,每次呼叫的UCID都不同,而每一个UCID是唯一的。
在本申请一实施例中,所述解释器用于将所述对话流程中每一节点的执行结果更新至所述内存数据库中,其中,所述对话流程中每一节点为所述对话流程中独立的执行代码块,所述执行代码块包括呼叫控制、语音播放、录音、接收按键、语音识别、调用外部接口。在此,当对话流程开始执行时,即对话流程在SE中开始执行,每个节点执行的结果和流程变量都会更新到内存数据库中,其中,节点表示对话流程中一个独立的执行代码块,包括呼叫控制、语义播放、录音、接收按键、语音识别、调用外部接口等节点类型,不同语音系统的构造块可不同,即节点类型可不同。每个节点的执行结果包括呼叫的状态,包括呼叫ID、流程所有计算用的变量值、流程执行的当前位置,这些信息均保存在内存数据库中,当任意的SE单元发生异常宕机或下线,其他SE单元在收到客户消息后,可以从内存数据库读取上下文信息,继续执行当前的语音交互流程。其中,流程计算用的变量值示例性的如下:有个变量X从用户输入一个按键表示用户需要听取几天内的留言,每个用户可能想法不同,因此每次流程执行时,都会有这个变量X的拷贝,该值被用来作为查询后台留言的参数,通过该查询(即计算过程)获取总的留言数量。在本申请中使用的内存数据库相比于传统数据库,可以保存流程用到的复杂对象,而传统数据库只能支持普通表结构,无法高效处理通用的数据结构。
在本申请一实施例中,所述系统包括媒体服务模块,所述解释器用于通过HTTP协议向所述媒体服务模块或所述呼叫控制单元发送交互控制请求,其中,所述交互控制请求包括控制语音的请求或控制呼叫的请求。在此,对话流程执行中会用到流程中用户设定的变量或系统提供的变量,如存取UCID、原始主被叫号码的变量等等,流程中若接收到交互控制请求,则将通过HTTP协议发送交互控制请求的消息,其中,交互请求包括控制语音的请求或控制呼叫的请求。本申请实施例中所述的控制语音包括播放预先录制的语音、对交互一方录音、接收或发送双音多频(DTMF,Dual Tone Multi Frequency)信号、通过外置文本到语音(TTS,Text To Speech)服务器播放机器合成的语音、通过ASR引擎识别客户的语音等所有语音媒体相关的操作,所述的控制呼叫包括应答呼叫、转接呼叫、保持呼叫、加入第三方进入现有呼叫等控制功能;解释器在需要媒体服务功能或呼叫控制功能时,通过HTTP协议发送相关请求。需要说明的是,在本申请实施例中,采用容器化技术来运行解释器,进一步能做到随着业务变化带来计算资源使用伸缩的效果。
接上述实施例,当所述交互控制请求为所述控制语音的请求时,所述解释器通过HTTP协议将所述控制语音转接至所述媒体服务模块;当所述交互控制请求为所述控制呼叫的请求时,所述解释器通过HTTP协议将所述控制呼叫转接至所述呼叫控制单元。在此,SE在执行节点时,需要CCU和媒体服务模块(MSU)以及外置的媒体处理单元共同完成,其中,媒体处理单元如TTS服务和自动语音识别服务(ASR,Automatic speech recognition),若接收到的控制请求为控制语音类的(如录放音操作),则通过HTTP协议发送控制语音类的消息,MQ向MSU转发消息,若接收的为控制呼叫类的(如转接人工),则通过HTTP协议发送控制呼叫类的消息,MQ向CCU转发消息;MQ为消息的中转站,临时保存各种消息,按队列方式存储,保证先进先出。
在本申请一实施例中,所述媒体服务模块或所述呼叫控制单元持续检测基于所述消息队列单元转接来的交互控制请求确定的呼叫状态变化,将所述呼叫状态变化通过所述消息队列单元发送至所述解释器。在此,在对话流程处理过程中,CCU或MSU持续检测信令和媒体的状态和变化,即通过持续检测确定呼叫状态变化,及时将变化作为消息通过MQ发送给SE,SE持续不断处理这些消息,从而推动对话流程的执行。
在本申请一实施例中,所述解释器、所述媒体服务模块及所述呼叫控制单元根据执行所述消息队列单元中的消息确定执行角色类型,其中,所述执行角色类型包括生产者和消费者。在此,当CCU接收到呼叫请求A进行呼叫处理,向MQ发送呼叫启动消息,由MQ通知SE启动对话流程,SE为消息A的消费者,任何一个SE的执行单元都有可能处理到消息A,从而可以避免单一的或固定的SE执行单元失败导致的语音流程无法处理的情况,SE将流程执行的状态数据保存在内存数据库中。由SE主动发起的执行命令所产生的结果,也就是CCU和MSU发送到MQ由SE负责处理的消息,也可以由任意的SE单元来处理,在消息启动以及发起执行命令过程中的消息均定义了生产者ID、生产者类型以及消费者的类型,其中,生产者ID为特定执行单元实例的ID,生产者类型为特定执行单元的类别,如CCU或MSU或SE,消费者类型如CCU或MSU或SE。通过不同类型的确定以区分不同进程实例的执行角色,不同执行角色消费不同的消息队列,执行不同的任务。因所有处理单元都有自己的执行角色,如类型信息为CCU或MSU或SE,都可以消费本类型应该处理的消息,因此当任意的SE单元发生异常宕机或下线,任何其他SE都可以处理消息。
在本申请一具体实施例中,如图2所示的语音交互系统的框架示意图,该系统是由多个计算机运行的分布式系统,系统的规模在100到10万之间,该系统可为独立于软交换系统,也可以为软交换系统的一部分,整个系统包括呼叫控制单元(CCU)、媒体服务单元(MSU)、用户自定义的交互流程的流程执行单元(解释器,SE)、内存数据库(MDB)以及消息队列(MQ)几个单元,组成一个基于IP网络的分布式系统,消息队列工作于生产者消费者模式。该系统是通过消息队列来接收呼叫信息的,多个实例都可能接收到消息,并且呼叫相关的信息都存储在内存数据库中,当其中一个实例异常宕机或下线时,另一个实例会继续处理流程后续的消息, 由于呼叫相关信息不是保证在单个处理节点上,而是在内存数据库里,后续的实例可以读取,因此这个实例可以继续进行未完成的呼叫流程,从而实现了交互的连续性以及高可靠性。另外,该系统可支持js脚本语言,通过对于js脚本语言的支持,可以在一定程度上直接通过js脚本实现功能,无须再次对系统开发新的节点功能支持新的功能。
图3示出根据本申请又一个方面提供的一种语音交互的方法的流程示意图,该方法包括:步骤S11、步骤S12和步骤S13,
在步骤S11中,根据接收到的呼叫请求查询内存数据库,识别出所述呼叫请求中的被呼叫号码;呼叫由网络进入系统后,根据呼叫请求查询内存数据库,识别出呼叫请求中的被号码是否为一个需要自动语音交互系统(VIS)处理的呼叫,从而根据识别结果启动一个对话流程。需要说明的是,呼叫请求包括呼叫的会话请求信息,该会话请求信息包括主叫号码、原始被叫号码、转接VIS流程对应的逻辑号码以及呼叫唯一标识ID,其中,逻辑号码为当前VIS流程的入口号码,原始被叫号码通过一定规则可以映射到这个VIS入口号码上。呼叫唯一标识ID(UCID)是用来标识一个呼叫的所有信息,一个呼叫从系统到挂断有一个完整的生命周期,而该生命周期使用呼叫唯一标识ID进行标识。主叫号码在不同时间可以有多次呼叫,每次呼叫的UCID都不同,而每一个UCID是唯一的。
在步骤S12中,基于识别出的被呼叫号码发送呼叫启动消息,加载并开始执行对话流程,并将所述对话流程的执行结果及对话流程变量更新至所述内存数据库中。在此,通过识别出的被呼叫号码加载并开始执行对话流程,启动对话流程时首先当识别出的被呼叫号码为需要自动语音交互系统处理的呼叫时,向消息队列(MQ)发送呼叫启动的消息,通过MQ来通知解释器(SE)需要启动一个对话流程。在执行对话流程过程中,将每个节点执行的结果和流程变量更新到内存数据库中,数据库中保存了流程执行的上下文数据。随后,在步骤S13中,按照所述内存数据库中对应的呼叫唯一标识信息的对话流程执行上下文,其中,所述上下文包括流程变量、流程名字以及流程节点指针位置;在解释器的实例故障后,其他执行单元提出上下文数据,能够保持流程完整执行的效果,通过消息队列MQ的增强算法和平衡算法、流程解释器内部执行线程以及缓冲管理、内存数据库对应呼叫唯一标识信息的呼叫流程执行上下文之间的配合,从而可以完成流程在任意解释器无缝执行,其中,执行上下文部分包括但不限于流程变量、流程名字和流程节点指针位置。本申请通过消息队列来接收呼叫信息,多个实例都可能接收到消息,并且呼叫相关的信息都存储在内存数据库中,当其中一个实例异常宕机或下线时,另一个实例会继续处理流程后续的消息,由于呼叫相关信息不是保证在单个处理节点上,而是在内存数据库中,后续的实例可以读取,因此这个实例可以继续进行未完成的呼叫流程,从而实现了交互的连续性以及高可靠性。
具体地,在步骤S12中,将所述对话流程中每一节点的执行结果及对话流程变量更新至所述内存数据库中,其中,所述对话流程中每一节点为所述对话流程中独立的执行代码块,所述执行代码块包括呼叫控制、语音播放、录音、接收按键、语音识别、调用外部接口,所述对话流程变量包括流程过程中所有计算使用的变量值和流程执行的当前位置变化。在此,当对话流程开始执行时,即对话流程在SE中开始执行,每个节点执行的结果和流程变量都会更新到内存数据库中,其中,节点表示对话流程中一个独立的执行代码块,包括呼叫控制、语义播放、录音、接收按键、语音识别、调用外部接口等节点类型,不同语音系统的构造块可不同,即节点类型可不同。每个节点的执行结果包括呼叫的状态,包括呼叫ID、流程所有计算用的变量值、流程执行的当前位置,这些信息均保存在内存数据库中,当任意的SE单元发生异常宕机或下线,任何其他SE在收到客户消息后,可以从内存数据库读取上下文信息,继续执行当前的语音交互流程。
本申请所述的方法为确保大规模高并发语音交互系统连续性的方法,通过内存数据库保存流程执行的上下文数据,保证在单点失效情况下,语音流程可以持续交互执行。通过消息队列来处理语音交互系统中需要流程引擎执行命令的消息避免单点失败且把传统IVR的呼叫信息保存在内存数据库来保护一个完整的语音交互过程。
此外,本申请实施例还提供了一种计算机可读介质,其上存储有计算机可读指令,所述计算机可读指令可被处理器执行以实现前述一种语音交互的方法。
与上文所述的方法相对应的,本申请还提供一种终端,其包括能够执行上述图3或各个实施例所述的方法步骤的模块或单元,这些模块或单元可以通过硬件、软件或软硬结合的方式来实现,本申请并不限定。例如,在本申请一实施例中,还提供了一种语音交互的终端,所述终端包括:
一个或多个处理器;以及
存储有计算机可读指令的存储器,所述计算机可读指令在被执行时使所述处理器执行如前述所述方法的操作。
例如,计算机可读指令在被执行时使所述一个或多个处理器:
根据接收到的呼叫请求查询内存数据库,识别出所述呼叫请求中的被呼叫号码;
基于识别出的被呼叫号码发送呼叫启动消息,加载并开始执行对话流程,并将所述对话流程的执行结果及对话流程变量更新至所述内存数据库中。
显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。
需要注意的是,本申请可在软件和/或软件与硬件的组合体中被实施,例如,可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一个实施例中,本申请的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地,本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中,例如,RAM存储器,磁或光驱动器或软磁盘及类似设备。另外,本申请的一些步骤或功能可采用硬件来实现,例如,作为与处理器配合从而执行各个步骤或功能的电路。
另外,本申请的一部分可被应用为计算机程序产品,例如计算机程序指令,当其被计算机执行时,通过该计算机的操作,可以调用或提供根据本申请的方法和/或技术方案。而调用本申请的方法的程序指令,可能被存储在固定的或可移动的记录介质中,和/或通过广播或其他信号承载媒体中的数据流而被传输,和/或被存储在根据所述程序指令运行的计算机设备的工作存储器中。在此,根据本申请的一个实施例包括一个装置,该装置包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器,其中,当该计算机程序指令被该处理器执行时,触发该装置运行基于前述根据本申请的多个实施例的方法和/或技术方案。
对于本领域技术人员而言,显然本申请不限于上述示范性实施例的细节,而且在不背离本申请的精神或基本特征的情况下,能够以其他的具体形式实现本申请。因此,无论从哪一点来看,均应将实施例看作是示范性的,而且是非限制性的,本申请的范围由所附权利要求而不是上述说明限定,因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外,显然“包括”一词不排除其他单元或步骤,单数不排除复数。第一,第二等词语用来表示名称,而并不表示任何特定的顺序。