一种检测用户状态事件的方法及装置与流程

文档序号:11157232阅读:204来源:国知局
一种检测用户状态事件的方法及装置与制造工艺

本发明涉及通信技术领域,特别涉及一种检测用户状态事件的方法及装置。



背景技术:

主动外呼指的是外呼系统先拨打客户电话,接通后把相应电话转接给座席代表进行交互。

在进行外呼时,经常需要获知被叫终端的用户状态事件,如拒绝呼叫、无人接听、占线、错误号码、关机、停机,等等,进而根据用户状态事件合理分配外呼资源,或结合用户状态事件为用户提供增值服务。

现有技术中,确定被叫终端的用户状态事件的方式包括:

其一,信令渠道。具体的,检测装置从被叫终端侧返回的信令中获取原因码,该原因码由被叫终端侧根据协议生成,能够表明被叫终端自身的状态。检测装置根据协议能够确定原因码对应的用户状态事件。但是,在原因码协议中,一个原因码可能对应多个用户状态事件,因此,根据信令渠道难以准确确定出真实的用户状态事件。

其二,语音渠道。具体的,检测装置接收终端侧返回的提示音,根据接收的提示音确定被叫终端的用户状态事件。但是,在通过语音渠道确定用户状态事件时,需要针对每一用户状态事件预存语音模板,并将语音模板加载到内存中,占用内存较大,且语音匹配的开销也较大。

因此,现有技术中缺乏准确且开销较小的确定用户状态事件的方法。



技术实现要素:

本发明实施例提供一种检测用户状态事件的方法及装置,用于解决现有技术中缺乏准确且开销较小的确定用户状态事件的方法的问题。

第一方面,本发明实施例提供一种检测用户状态事件的方法,包括:在进行外呼检测时,检测设备启动信令检测用户状态事件以及语音检测用户状态事件;检测设备接收包含被叫终端状态的第一原因码的信令,从信令中获取第一原因码,并根据原因码与用户状态事件的映射表判断所述第一原因码对应的用户状态事件是否唯一;如果所述第一原因码对应的用户状态事件唯一,则检测设备中止语音检测用户状态事件,释放用于语音检测用户状态事件的资源,并将所述第一原因码对应的用户状态事件发送至主叫装置。

其中,所述检测设备可以为由媒体网关以及媒体网关控制器构成的通用接入平台,也可以为将媒体网关以及媒体网关控制器的功能集成在一起的单一设备。上述主叫装置为发起外呼的设备,如计算机电话集成。所述被叫终端为通信终端设备,如移动终端、移动台等。原因码为用于表征被叫终端的用户状态事件的标识。

上述实现方式中,检测设备在确定通过信令可以唯一确定用户状态事件后,中止语音检测用户状态事件,释放语音检测所占用的资源,在保证能够主叫装置获得用户的真实状态的情况下,节约系统资源,减小了系统开销。

结合第一方面,在第一方面的第一种可能的实现方式中,如果检测设备判断出第一原因码对应的用户状态事件不唯一,则根据被叫终端侧返回的第一提示音确定所述被叫终端的用户状态事件;将确定出的用户状态事件发送至主叫装置。

上述可能的实现方式中,在第一原因码对应的用户状态事件不唯一时,通过被叫终端侧返回的提示音确定被叫终端的用户状态事件,使得主叫装置将接收到唯一的、确定的用户状态事件。避免了因主叫装置接收到信令渠道以及语音渠道返回的不一致的检测结果,导致主叫装置难以准确确定被叫终端的用户状态事件。

结合第一方面的第一种可能的实现方式,在第一方面的第二种可能的实现方式中,检测设备所述根据所述被叫终端侧返回的第一提示音确定所述被叫终端的用户状态事件,包括:接收所述被叫终端侧返回的所述第一提示音;将接收的所述第一提示音与存储的至少两个提示音模板进行匹配,确定与所述第一提示音对应的第一提示音模板;根据提示音模板与用户状态事件的映射表确定与所述第一提示音模板对应的用户状态事件,确定出的用户状态事件为所述被叫终端的用户状态事件。

结合第一方面的第一或第二种可能的实现方式,在第一方面的第三种可能的实现方式中,如果检测设备判断出所述第一原因码对应的用户状态事件不唯一,且未能在超时时间内接收到被叫终端侧返回的提示音,则确定所述第一原因码对应的至少两个用户状态事件;根据所述至少两个用户状态事件确定对所述被叫终端进行外呼的策略;将所述策略发送至所述主叫装置。

上述可能的实现方式中,在无法根据信令渠道以及语音渠道确定用户状态事件时,通过已获得的非唯一用户状态事件来估算对被叫终端进行外呼的策略,以使主叫装置根据该策略来执行对该被叫终端的外呼,提高外呼效率。

结合第一方面的第三种可能的实现方式,在第一方面的第四种可能的实现方式中,检测设备根据非唯一用户状态事件估算对所述被叫终端进行外呼的策略,包括:根据所述至少两个用户状态事件确定是否需要对所述被叫终端进行再次外呼;或者根据所述至少两个用户状态事件确定对所述被叫终端进行再次外呼的时间。

第二方面,本发明实施例提供一种检测用户状态事件的装置,包括:

启动模块,用于在进行外呼检测时,启动信令检测用户状态事件以及语音检测用户状态事件;

信令接收模块,用于接收包含被叫终端状态的第一原因码的信令;

判断模块,从所述第一接收单元接收的所述信令中获取所述第一原因码,并根据原因码与用户状态事件的映射表判断所述第一原因码对应的用户状态 事件是否唯一;

资源释放模块,用于在所述第一原因码对应的用户状态事件唯一时,中止语音检测用户状态事件,释放用于语音检测用户状态事件的资源;

发送模块,用于将所述第一原因码对应的用户状态事件发送至主叫装置。

结合第二方面,在第二方面的第一种可能的实现方式中,检测用户状态事件的装置还包括:

语音确定模块,用于在所述第一原因码对应的用户状态事件不唯一时,根据所述被叫终端侧返回的第一提示音确定所述被叫终端的用户状态事件;

所述发送模块还用于:将所述语音确定模块确定出的用户状态事件发送至主叫装置。

结合第二方面的第一种可能的实现方式,在第二方面的第二种可能的实现方式中,所述语音确定模块具体用于:

接收所述被叫终端侧返回的所述第一提示音;

将接收的所述第一提示音与存储的至少两个提示音模板进行匹配,确定与所述第一提示音对应的第一提示音模板;

根据提示音模板与用户状态事件的映射表确定与所述第一提示音模板对应的用户状态事件,确定出的用户状态事件为所述被叫终端的用户状态事件。

结合第二方面的第一或第二种可能的实现方式,在第二方面的第三种可能的实现方式中,检测用户状态事件的装置还包括:

估算模块,用于在所述第一原因码对应的用户状态事件不唯一,且未能在超时时间内接收到所述第一提示音时,确定所述第一原因码对应的至少两个用户状态事件;根据所述至少两个用户状态事件确定对所述被叫终端进行外呼的策略;

所述发送模块还用于:将所述第二确定模块确定的所述策略发送至所述主叫装置。

结合第二方面的第三种可能的实现方式,在第二方面的第四种可能的实现 方式中,所述估算模块具体用于:根据所述至少两个用户状态事件确定是否需要对所述被叫终端进行再次外呼;或者,根据所述至少两个用户状态事件确定对所述被叫终端进行再次外呼的时间。

第三方面,本发明实施例提供一种检测用户状态事件的装置,包括:处理器、存储器;其中,所述存储器中存有计算机可读程序;所述处理器通过运行所述存储器中的程序,以用于完成第一方面所述的方法。

相较于现有技术,本发明提供的方案可以在准确确定用户状态事件和节约系统开销之间实现更好地平衡。

附图说明

为了更清楚地说明本发明实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简要介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域的普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。

图1为信令渠道检测以及语音渠道检测的示意图;

图2为本发明实施例中检测用户状态事件的方法的流程示意图;

图3为本发明实施例中检测用户状态事件方法的细化流程示意图;

图4为本发明实施例中检测用户状态事件方法的另一细化流程示意图;

图5为本发明实施例中检测用户状态事件流程的示意图;

图6为本发明实施例中检测用户状态事件流程的另一示意图;

图7为本发明实施例中检测用户状态事件流程的又一示意图;

图8为本发明实施例中检测用户状态事件的装置的结构示意框图;

图9为本发明实施例中另一检测用户状态事件的装置的结构示意框图。

具体实施方式

图1为现有技术中通过信令渠道以及语音渠道确定被叫终端的用户状态事件的示意图。其中,涉及的网元或系统或网络包括:语音信箱系统(Voice Message System;简称:VMS)、基站子系统(Base Station Subsystem;简称:BSS)、通用电信无线接入网(Universal Telecommunication Radio Access Network;简称:UTRAN)、归属位置寄存器(Home Location Register;简称:HLP)、业务控制点(Service Control Point;简称:SCP)、移动交换中心(Mobile Switching Center;简称:MSC)、媒体网关(Media Gateway;简称:MGW)、媒体网关控制器(Media Gateway Controller;简称:MGC)、通用接入平台(Universal Access Platform;简称:UAP)、计算机电话集成(Computer Telephony Integration;简称:CTI)。其中,上述UAP由上述MGC以及上述MGW构成。上述网元或系统或网络的实施方式请参照现有技术,在此不予详述。

另外,图1中的实线箭头对应信令渠道检测途径,虚线箭头对应语音渠道检测途径。需要说明的是,被叫终端侧的MGW与MSC的连线表明二者存在交互,通常MGW受到MSC的控制。再者,语音渠道检测途径中的网元或系统间传输的并不一定都是语音,例如,呼叫中心侧的MGW与MGC之间可以进行信令传输。

为了解决现有技术中缺乏准确且开销较小的确定用户状态事件的方法的问题,本发明实施例针对现有技术中的UAP进行改进,提供一种检测用户状态事件的方法及装置,下面通过附图以及具体实施例对本发明技术方案做详细的说明。

图2为本发明实施例提供的一种检测用户状态事件的方法的流程示意图,该方法包括如下步骤:

步骤101:在进行外呼检测时,启动信令检测用户状态事件以及语音检测用户状态事件;

步骤102:接收包含被叫终端状态的第一原因码的信令;

步骤103:从信令中获取第一原因码,并根据原因码与用户状态事件的映 射表判断第一原因码对应的用户状态事件是否唯一;如果第一原因码对应的用户状态事件唯一,则转向步骤104;

步骤104:中止语音检测用户状态事件,释放用于语音检测用户状态事件的资源;

步骤105:将第一原因码对应的用户状态事件发送至主叫装置。

具体的,上述步骤101至步骤105可以通过图1中的UAP执行,也可以将UAP中的MGC和MGW集成在一个检测设备上,上述步骤101至步骤105均由该集成的检测设备执行。在采用不同于图1所示的呼叫中心架构时,上述步骤101至步骤105也可以采用与UAP功能相同或相似的其他网元执行。

在步骤101中,在进行外呼检测时,执行上述步骤101至步骤105的检测设备首先会获得用于信令渠道检测的资源,启动信令检测用户状态事件;以及获得用于语音渠道检测的资源,启动语音检测用户状态事件。

其中,获得信令检测资源或者语音检测资源的方式包括:其一,从系统已经为检测设备分配的资源中划拨出用于信令检测或用于语音检测的资源;其二,检测设备主动向系统中负责资源分配的网元发出资源请求,请求网元为其分配用于信令检测或用于语音检测的资源;其三,主叫装置的外呼触发分配资源的网元主动为检测设备分配资源,检测设备接收为其分配的资源进行检测。

步骤102中,由于信令相较于语音的数据量较小,传输时间较短,检测设备将首先接收到被叫终端侧返回的信令。

步骤103中,检测设备从接收的信令中获取用于表明被叫终端状态的第一原因码。然后,根据存储的原因码与用户状态事件的映射表判断第一原因码对应的用户状态事件是否唯一。

其中,上述映射表可以存储在检测设备本地,也可以存储在通信系统的其它网元之中,检测设备可以从该网元处获取映射表,或者将第一原因码发送至该网元,由该网元判断第一原因码对应的用户状态事件是否唯一,并将判断结果返回给检测设备。

如果执行步骤103后的判断结果表明第一原因码对应的用户状态事件唯一,则可通过信令检测唯一、准确确定用户状态事件,转向执行步骤104,中止语音检测用户状态事件,释放用于语音检测用户状态事件的资源。

其中,用于语音检测用户状态事件的资源包括:用于传输被叫终端侧返回的提示音的传输资源、用于缓存返回提示音的存储资源、用于识别第一提示音的运算资源等资源中的至少一项。

步骤105中,检测设备将根据信令检测确定的用户状态事件发送至主叫终端,以使主叫装置获知被叫终端的真实状态,并据此为该被叫终端分配外呼资源,或结合用户状态事件为用户提供增值服务。

需要说明的是,上述步骤104与步骤105可以同时进行,即,步骤103中判断出第一原因码对应的用户状态事件唯一后,同时触发步骤104以及步骤105的执行。步骤105也可以在步骤104执行结束后执行,或者,步骤104在步骤105执行结束后执行。

另外,被叫终端侧可以通过图1中的MSC返回信令,在采用与图1不同的网络架构时,被叫终端侧也可以通过与MSC起相似作用的其他网元返回信令。

再者,上述主叫装置可以为图1中的CTI,在采用其他架构的呼叫中心时,主叫装置也可以为与图1中的CTI起相似作用的其他设备。

本发明实施例提供的上述检测用户状态事件的方法中,检测设备在确定通过信令可以唯一确定用户状态事件后,中止语音检测用户状态事件,释放语音检测所占用的资源,在保证能够主叫装置获得用户的真实状态的情况下,节约系统资源,减小了系统开销。

可选的,本发明实施例中,在步骤103中的判断结果表明第一原因码对应的用户状态事件不唯一之后,转向执行步骤106。

步骤106:根据被叫终端侧返回的第一提示音确定被叫终端的用户状态事件;

步骤107:将确定出的用户状态事件发送至主叫装置。

具体的,如果第一原因码对应的用户状态事件不唯一,则表明通过信令渠道难以确定出被叫终端的真实状态,检测设备接收被叫终端侧返回的第一提示音,根据第一提示音确定出用户状态事件,并将用户状态事件发送至主叫装置。

例如,被叫终端侧返回的信令中包含的第一原因码为“用户缺席”原因码时,确定出两个用户状态事件,分别为“用户不在服务区事件”和“用户关机事件”,然后,通过被叫终端侧返回的提示音“您所呼叫的用户已关机”,并据此确定被叫终端的真实状态为“用户关机事件”。

需要说明的是,被叫终端侧可以通过图1中的MGW返回第一提示音,在采用与图1不同的网络架构时,被叫终端侧也可以通过与MGW起相似作用的其他网元返回第一提示音。

上述技术方案中,通过被叫终端侧上报的信令包含的第一原因码确定被叫终端的用户状态事件,并在第一原因码对应的用户状态事件不唯一时,通过被叫终端侧返回的提示音确定被叫终端的用户状态事件,主叫装置将接收到唯一的、确定的用户状态事件。避免了因主叫装置接收到信令渠道以及语音渠道返回的不一致的检测结果,导致主叫装置难以准确确定被叫终端的用户状态事件。

可选的,本发明实施例中,步骤106:根据被叫终端侧返回的第一提示音确定被叫终端的用户状态事件,具体实施时,参照图3,包括如下步骤:

步骤1061:接收被叫终端侧返回的第一提示音;

步骤1062:将接收的第一提示音与存储的至少两个提示音模板进行匹配,确定与第一提示音对应的第一提示音模板;

步骤1063:根据提示音模板与用户状态事件的映射表确定与第一提示音模板对应的用户状态事件,确定出的用户状态事件为被叫终端的用户状态事件。

具体的,步骤1061中,检测设备利用分配的传输资源接收被叫终端侧返回的第一提示音。

继续执行步骤1062,将第一提示音存储在本地存储器(如,内存)中,并将第一提示音与预存的提示音模板进行匹配,确定第一提示音模板所匹配的提示音模板,并进一步执行步骤1063,确定第一提示音模板对应的用户状态事件为被叫终端的用户状态事件。

其中,检测设备本地预存有多个提示音模板,每个提示音模板可以对应一个用户状态事件,提示音模板与用户状态事件的对应关系可以存储在一个映射表中,也可以在每个提示音模板的属性信息中存储其对应的用户状态事件的信息。

例如,提示音模板可以包括“你所呼叫的用户已停机”的语音,该语音模板所对应的用户状态事件为“停机事件”。检测设备将第一提示音与存储的多个提示音模板进行匹配后,如果确定第一提示音与“你所呼叫的用户已停机”的语音模板相匹配,则可确定该语音模板对应的“停机事件”即为被叫终端的用户状态事件。关于将第一提示音与至少两个提示模板进行匹配的实现方式请参照现有技术,在此不予详述。

需要说明的是,除了上述通过模板匹配的方式确定第一提示音所对应的用户状态事件,还可以采用语音主动识别技术来确定第一提示音的内容,进而根据第一提示音的内容确定被叫终端的用户状态事件。

另外,实际情况中,检测设备也可以在步骤103中判断出第一原因码所对应的用户状态事件不唯一之后分配语音渠道检测所需的资源,执行步骤106,本发明实施例意图保护这一变形方案。

可选的,本发明实施例中,对应的用户状态事件不唯一的原因码的集合为第一原因码集合,第一原因码集合包含的原因码对应的用户状态事件的集合为第一用户状态事件集合,上述至少两个提示音模板包括第一用户状态事件集合中每个用户状态事件对应的提示音模板。

具体的,用户状态事件包括两类,第一类用户状态事件能够通过原因码唯一确定,即第一类用户状态事件所对应的原因码只对应有一个用户状态事件; 第二类用户状态事件不能通过原因码唯一确定,即第二类用户状态事件所对应的原因码对应有至少两个用户状态事件,第二类用户状态事件的集合即第一用户状态事件集合。

由于第一类用户状态事件能够通过信令渠道唯一地确定出来,所以,实际情况中不需要通过语音渠道来确定第一类用户状态事件,因此,检测设备可以不存储第一类用户状态事件对应的语音模板,而是存储不能通过信令渠道来确定的第一用户状态事件集合包含的第二类用户状态事件对应的提示音模板,通过语音渠道来确定第一用户状态事件集合中的用户状态事件。

上述技术方案中,通过存储不能通过信令渠道确定的用户状态事件对应的提示音模板,而不存储能够通过信令渠道确定的用户状态事件对应的提示音模板,能够减少语音渠道确定用户状态事件所需占用的存储资源。

可选的,本发明实施例中,在步骤103:根据原因码与用户状态事件的映射表判断第一原因码对应的用户状态事件是否唯一之后,参照图4,还包括如下步骤:

步骤108:如果第一原因码对应的用户状态事件不唯一,且未能在超时时间内接收到被叫终端侧返回的第一提示音,则确定第一原因码对应的至少两个用户状态事件;

步骤109:根据至少两个用户状态事件确定对被叫终端进行外呼的策略;

步骤110:将确定出的策略发送至主叫装置。

具体的,实际情况中,可能出现如下情况:由于语音传输耗时过长,或者语音传输链路阻塞、故障,又或者被叫终端故障无法返回提示音。

在上述情况中,检测设备可能未能在超时时长内接收到被叫终端侧返回的提示音,无法根据语音检测渠道获得用户状态事件,而由于第一原因码对应的用户状态事件不唯一,因此,通过信令渠道也无法获得被叫终端的唯一用户状态事件。

在这种情况下,检测设备可以通过当前已有的关于被叫终端的信息,即第 一原因码对应的非唯一的用户状态事件,来估算被叫终端的真实状态,进而根据估算的被叫终端的状态生成对被叫终端的接下来的外呼策略。

实际情况中,在确定第一原因码对应的用户状态事件非唯一之后,检测设备可以将第一原因码对应的非唯一用户状态事件存储起来待用,如果能够根据语音检测渠道确定唯一用户状态事件,则舍弃存储的非唯一用户状态事件。如果通过语音渠道无法确定非唯一用户状态事件,则检测设备读取之前存储的非唯一用户状态事件,通过步骤109确定接下来的外呼策略。其中,非唯一用户状态事件可以存储在内存中,或者专用寄存器中,或者存储在从硬盘上。

上述技术方案中,在无法根据信令渠道以及语音渠道确定用户状态事件时,通过已获得的信息(即,第一原因码对应的至少两个用户状态事件)来确定对被叫终端进行外呼的策略,以使主叫装置根据该策略来执行对该被叫终端的外呼,提高外呼效率。

可选的,本发明实施例中,步骤109:根据至少两个用户状态事件确定对被叫终端进行外呼的策略,具体实施时,包括:

根据至少两个用户状态事件确定是否需要对被叫终端进行再次外呼;或者

根据至少两个用户状态事件确定对被叫终端进行再次外呼的时间。

具体的,根据第一原因码确定出的至少两个用户状态事件,虽然不能唯一地确定被叫终端的状态,但是也能反映被叫终端的状态,或者可以用于估计被叫终端的状态,根据第一原因码确定出的至少两个用户状态事件可以确定是否需要对被叫终端进行再次外呼;或者在要对被叫终端进行再次外呼时,根据至少两个用户状态事件确定再次外呼的时间。

例如,在第一原因码为“用户缺席”原因码时,确定出两个用户状态事件,分别为“用户不在服务区事件”和“用户关机事件”,可以估计被叫终端只是暂时缺席,可以生成指示主叫装置对被叫终端进行再次外呼的策略。另外,用户缺席的情况不会在短时间内改变,所以可以进一步在策略中指示主叫装置延迟对被叫终端的外呼,以避免外呼资源的浪费,提高资源的利用率。

实际情况中,在执行步骤109时,还可以结合被叫用户的其他信息来生成外呼策略。例如,在根据第一原因码确定出被叫终端的可能用户状态事件为“用户不在服务区事件”和“用户停机事件”时,可以结合被叫终端的历史话单,如果该用户之前未曾停机,则可以估计用户只是暂时不再服务器,可以等待一较短时间再次进行外呼。如果历史话单表明该用户之前经常停机,则可以估计该用户出现停机事件,可以等待一较长时间再次进行外呼。

上述技术方案中,在无法根据信令渠道以及语音渠道确定用户状态事件时,通过第一原因码对应的至少两个用户状态事件来确定是否对被叫终端进行再次外呼,以及具体在什么时间进行下一次外呼,避免外呼资源浪费,提高外呼效率。

为了更好的理解本发明实施例提供的技术方案,下面以利用由MGC以及MGW组成的UAP来执行本发明实施例提供的检测用户状态事件的方法,予以举例说明。

其中,MGC包括:检测控制模块、事件存储模块、唯一事件过滤模块、信令检测模块,上述模块可以是由芯片实现的硬件模块,也可以是由处理器执行程序实现的功能模块。

图5为检测用户状态事件的流程示意图,包括如下步骤:

步骤201:在进行外呼检测时,检测控制模块启动信令渠道检测以及语音渠道检测;

步骤202:信令检测模块根据检测到的信令包含的原因码确定用户状态事件,并将用户状态事件上报唯一事件过滤模块;

步骤203:唯一事件过滤模块判断信令检测模块上报的用户状态事件是否唯一;

步骤204:在信令检测模块上报的用户状态事件唯一时,唯一事件过滤模块将唯一用户状态事件上报检测控制模块;

步骤205:检测控制模块向MGW发送中止语音检测用户状态事件的指令; 并执行步骤207;

步骤206:MGW响应指令,释放用于语音检测用户状态事件的资源。

步骤207:检测控制模块将唯一用户状态事件发送至主叫装置。

通过上述流程,在通过信令渠道能够获得唯一用户状态事件的情况下,释放语音检测所占用的资源,节约系统资源,减小了系统开销。

图6为检测用户状态事件的另一流程示意图,包括如下步骤:

步骤301:在进行外呼检测时,检测控制模块启动信令渠道检测以及语音渠道检测;

步骤302:信令检测模块根据检测到的信令包含的原因码确定用户状态事件,并将用户状态事件上报唯一事件过滤模块;

步骤303:唯一事件过滤模块判断信令检测模块上报的用户状态事件是否唯一;

步骤304:在信令检测模块上报的用户状态事件不唯一时,将非唯一用户状态事件存储在事件存储模块中;

步骤305:MGW根据检测的提示音确定出用户状态事件,并将用户状态事件发送至唯一事件过滤模块;

步骤306:唯一事件过滤模块确定MGW上报的用户状态事件唯一,将唯一用户状态事件发送至检测控制模块;

步骤307:检测控制模块将唯一用户状态事件发送至主叫装置。

通过上述流程,在信令检测渠道确定的用户状态事件不唯一时,通过与U因检测渠道确定被叫终端的唯一用户状态事件,使得主叫装置将接收到唯一的、确定的用户状态事件。避免了因主叫装置接收到信令渠道以及语音渠道返回的不一致的检测结果,导致主叫装置难以准确确定被叫终端的用户状态事件。

图7为检测用户状态事件的又一流程示意图,包括如下步骤:

步骤401:在进行外呼检测时,检测控制模块启动信令渠道检测以及语音 渠道检测;

步骤402:信令检测模块根据检测到的信令包含的原因码确定用户状态事件,并将用户状态事件上报唯一事件过滤模块;

步骤403:唯一事件过滤模块判断信令检测模块上报的用户状态事件是否唯一;

步骤404:在信令检测模块上报的用户状态事件不唯一时,将非唯一用户状态事件存储在事件存储模块中;

步骤405:检测控制模块确定等待唯一用户状态事件超时;

步骤406:检测控制模块从事件存储模块读取非唯一用户状态事件;

步骤407:检测控制模块根据读取的非唯一用户状态事件预估外呼策略,并将预估的外呼策略发送至主叫装置。

通过上述流程,在无法根据信令渠道以及语音渠道确定用户状态事件时,通过已获得的非唯一用户状态事件来估算对被叫终端进行外呼的策略,以使主叫装置根据该策略来执行对该被叫终端的外呼,提高外呼效率。

需要说明的是,上述技术方案仅仅是本发明实施例提供的检测用户状态事件的方法的一种可能的实现方式,不能以此限定本发明实施例的保护范围。

基于相同的技术构思,本发明实施例还提供了一种检测用户状态事件的装置500,图8为装置500的结构示意框图,包括:

启动模块501,用于在进行外呼检测时,启动信令检测用户状态事件以及语音检测用户状态事件;

信令接收模块502,用于接收包含被叫终端状态的第一原因码的信令;

判断模块503,从第一接收单元接收的信令中获取第一原因码,并根据原因码与用户状态事件的映射表判断第一原因码对应的用户状态事件是否唯一;

资源释放模块504,用于在第一原因码对应的用户状态事件唯一时,中止语音检测用户状态事件,释放用于语音检测用户状态事件的资源;

发送模块505,用于将第一原因码对应的用户状态事件发送至主叫装置。

可选的,本发明实施例中,装置500还包括:

语音确定模块506,用于在第一原因码对应的用户状态事件不唯一时,根据被叫终端侧返回的第一提示音确定被叫终端的用户状态事件;

发送模块505还用于:将语音确定模块确定出的用户状态事件发送至主叫装置。

可选的,本发明实施例中,语音确定模块506具体用于:

接收被叫终端侧返回的第一提示音;

将接收的第一提示音与存储的至少两个提示音模板进行匹配,确定与第一提示音对应的第一提示音模板;

根据提示音模板与用户状态事件的映射表确定与第一提示音模板对应的用户状态事件,确定出的用户状态事件为被叫终端的用户状态事件。

可选的,本发明实施例中,继续参照图6,装置500还包括:

估算模块507,用于在第一原因码对应的用户状态事件不唯一,且未能在超时时间内接收到第一提示音时,确定第一原因码对应的至少两个用户状态事件;根据至少两个用户状态事件确定对被叫终端进行外呼的策略;

发送模块505还用于:将估算模块507确定的策略发送至主叫装置。

可选的,本发明实施例中,估算模块507具体用于:根据至少两个用户状态事件确定是否需要对被叫终端进行再次外呼;或者,根据至少两个用户状态事件确定对被叫终端进行再次外呼的时间。

需要说明的是,以上装置500中的判断模块503可以为单独设立的处理器,也可以集成在UAP设备的某一个处理器中实现,此外也可以以程序代码的形式存储于UAP设备的存储器中,由UAP设备的某一个处理器调用并执行判断模块503的功能,这里的处理器可以是一个中央处理器(Central Processing Unit;简称:CPU)或者是特定集成电路(Application Specific Intergrated Circuit;简称:ASIC)或者是被配置成实施本发明实施例的一个或多个集成电路。资源释放模块504、语音确定模块506的实现与判断模块503类似,且可以与判断模 块503集成在一起,也可以单独实现。信令接收模块502可以为UAP设备的接收机,发送模块505可以为UAP设备的发射机,用于实现与被叫终端侧之间的通信。

本实施例中的检测用户状态事件的装置500与前述检测用户状态事件的方法是基于同一发明构思下的两个方面,在前面已经对方法的实施过程作了详细的描述,所以本领域技术人员可根据前述描述清楚地了解本实施例中的装置500的结构及实施过程,为了说明书的简洁,在此就不再赘述了。

基于相同的发明构思,本发明实施例还提供一种检测用户状态事件的装置600,参照图9,装置600包括:处理器601、存储器602;其中,存储器602中存有计算机可读程序;处理器601通过运行存储器中的程序,以用于完成前述检测用户状态事件的方法。

可选的,本发明实施例中,检测用户状态事件的装置600还包括收发机603,用于与网络中的其他网元传输信息。

可选的,本发明实施例中,处理器601在运行存储器602中的程序时,执行如下步骤:

在进行外呼检测时,启动信令检测用户状态事件以及语音检测用户状态事件;

通过收发机603接收包含被叫终端状态的第一原因码的信令;

从信令中获取第一原因码,并根据原因码与用户状态事件的映射表判断第一原因码对应的用户状态事件是否唯一;

如果第一原因码对应的用户状态事件唯一,则中止语音检测用户状态事件,释放用于语音检测用户状态事件的资源;

通过收发机603将第一原因码对应的用户状态事件发送至主叫装置。

可选的,本发明实施例中,处理器601在用于:根据原因码与用户状态事件的映射表判断第一原因码对应的用户状态事件是否唯一之后,还用于:

在第一原因码对应的用户状态事件不唯一时,根据被叫终端侧返回的第一 提示音确定被叫终端的用户状态事件;

通过收发机603将确定出的用户状态事件发送至主叫装置。

可选的,本发明实施例中,处理器601在用于:根据被叫终端侧返回的第一提示音确定被叫终端的用户状态事件,包括:

通过收发机603接收被叫终端侧返回的第一提示音;

将接收的第一提示音与存储的至少两个提示音模板进行匹配,确定与第一提示音对应的第一提示音模板;

根据提示音模板与用户状态事件的映射表确定与第一提示音模板对应的用户状态事件,确定出的用户状态事件为被叫终端的用户状态事件。

可选的,本发明实施例中,处理器601在用于:根据原因码与用户状态事件的映射表判断第一原因码对应的用户状态事件是否唯一之后,还用于:

如果第一原因码对应的用户状态事件不唯一,且未能在超时时间内接收到第一提示音,则确定第一原因码对应的至少两个用户状态事件;

根据至少两个用户状态事件确定对被叫终端进行外呼的策略;

通过收发机603将策略发送至主叫装置。

可选的,本发明实施例中,处理器601用于:根据至少两个用户状态事件确定对被叫终端进行外呼的策略,包括:

根据至少两个用户状态事件确定是否需要对被叫终端进行再次外呼;或者

根据至少两个用户状态事件确定对被叫终端进行再次外呼的时间。

上述处理器601可以为单独设立的处理单元,也可以是多个处理元件的统称。例如,处理器601可以是中央处理器(Central Processing Unit;简称:CPU),也可以是特定集成电路(Application Specific Intergrated Circuit;简称:ASIC),或者是被配置成实施本发明实施例的一个或多个集成电路,例如:一个或多个微处理器(digital singnal processor;简称:DSP),或,一个或者多个现场可编程门阵列(Field Programmable Gate Array;简称:FPGA)。

本实施例中的检测用户状态事件的装置600与前述检测用户状态事件的方 法是基于同一发明构思下的两个方面,在前面已经对方法的实施过程作了详细的描述,所以本领域技术人员可根据前述描述清楚地了解本实施例中的装置600的结构及实施过程,为了说明书的简洁,在此就不再赘述了。

本发明实施例中提供的一个或多个技术方案,至少具有如下技术效果或优点:

本发明实施例,通过信令包含的第一原因码确定被叫终端的用户状态事件,并在第一原因码对应的用户状态事件不唯一时,通过提示音确定被叫终端的用户状态事件,主叫装置将接收到唯一的、确定的用户状态事件,解决了通过信令渠道确定的用户状态事件与通过语音渠道确定的用户状态事件不一致,影响主叫装置准确确定被叫终端真实状态的问题。

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

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

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

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

显然,本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样,倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1