CN107580152A - 语音增值业务系统及其通信方法 - Google Patents

Abstract

本发明公开了一种语音增值业务系统及其通信方法，该语音增值业务系统的通信方法包括：语音增值业务平台服务器CTIS分别与各个上述语音增值业务服务器之间，以及脚本解析服务器IVRS与上述CTIS之间，均通过以下方式进行数据通信：确定填充好数据的数据包的包长度；按照发送端预先与接收端协商好的包结构体格式序列，对数据进行打包，其中，上述包结构体格式序列为：至少一个包类型字节、至少一个包长度字节、以及至少一个包体内容字节；将打包后的数据包通过网络传输至上述接收端。采用本发明的技术方案，减少了冗余的包数据，所以占用网络带宽就比JSON协议传输小。

Description

语音增值业务系统及其通信方法

技术领域

本发明涉及通信领域，具体而言，涉及一种语音增值业务系统及其通信方法。

背景技术

现有的语音增值业务需要在各地建立一套C++语言开发的系统平台，参见图1所示。该IVR业务系统平台主要完成各地电话语音增值业务的接入，各地业务流程需要针对各地单独开发，同时必须要懂得C++语言的专业人员才能开发。由于各地区业务不同，这样就使得研发维护人员工作量巨大。此外，每次更换IVR业务流程还需要将整个系统停机维护。

各地运营商，因为结算计费等问题，限制用户只能从其号码所属的运营商平台拨入系统，各平台的用户、资源都不能互联互通，使得平台用户单一，资源也不能共享。

此外，相关技术中的语音增值业务系统，通常采用HTTP协议和JSON协议传输数据。HTTP协议是基于网页传输定制协议。协议内容庞大，不适宜用于语音IVR业务；而JSON协议采用了发送端通过预先定义好KEY:VALUE方式通过字串方式组成一个由”{“和”}”包含的KEY:VALUE组合的一串字串作为内容通过字串序列化方式将文本字串发送到接收端，接收端将此字串通过解包器反向解析字串将对端发送信息解析出来，由于采用了网络传输都是字串方式传输，同时每一个包体传输变量都需要一个KEY描述,所以占用网络带宽大。

发明内容

本发明的主要目的在于公开了一种语音增值业务系统及其通信方法，以至少解决相关技术中各地运营商，限制用户只能从其号码所属的运营商平台拨入系统，各平台的用户、资源都不能互联互通，使得平台用户单一，资源也不能共享的问题。

根据本发明的一个方面，提供了一种语音增值业务系统。

根据本发明的语音增值业务系统包括：部署于各区域的多个语音增值业务服务器；设置于为上述语音增值业务服务器中一个或多个语音增值业务服务器的接入用户注册成虚拟用户并提交至脚本解析服务器IVRS，接收脚本解析服务器的控制指令并返回至上述一个或多个语音增值业务服务器的语音增值业务平台服务器CTIS，上述CTIS分别与各个上述语音增值业务服务器建立有数据通信连接；设置于接收到上述虚拟用户后读取预先配置的脚本文件并分析解码形成上述控制指令的上述IVRS，上述IVRS与上述CTIS建立有数据通信连接。

优选地，各个上述语音增值业务服务器均集成有与接入用户建立连接的至少一个语音板卡。

优选地，各个上述语音增值业务服务器分别通过公网与上述CTIS连接。

优选地，各个上述语音增值业务服务器分别基于TCP协议与上述CTIS传输数据。

优选地，上述系统还包括：与上述IVRS建立有数据通信连接的数据库接口服务器DBAS，上述DBAS存储有各区域接入用户的业务数据。

优选地，上述CTIS、上述IVRS、以及上述DBAS分开部署在不同的计算机上，上述多个语音增值业务服务器共用上述CTIS。

优选地，上述CTIS与上述IVRS通过局域网连接，上述IVRS与上述DBAS通过局域网连接。

优选地，上述CTIS与上述IVRS基于TCP协议传输数据，上述IVRS与上述DBAS基于TCP协议传输数据。

根据本发明的另一方面，提供了一种语音增值业务系统的通信方法。

根据本发明的语音增值业务系统的通信方法，CTIS分别与各个所述语音增值业务服务器之间，以及所述IVRS与所述CTIS之间，均通过以下方式进行数据通信：确定得到填充好数据的数据包的包长度；按照发送端预先与接收端协商好的包结构体格式序列，对数据进行打包，其中，所述包结构体格式序列为：至少一个包类型字节、至少一个包长度字节、以及至少一个包体内容字节；将打包后的数据包通过网络传输至所述接收端。

优选地，所述CTIS和数据库接口服务器DBAS之间，通过以下方式进行数据通信：确定得到填充好数据的数据包的包长度；按照发送端预先与接收端协商好的包结构体格式序列，对数据进行打包，其中，所述包结构体格式序列为：至少一个包类型字节、至少一个包长度字节、以及至少一个包体内容字节；将打包后的数据包通过网络传输至接收端。

优选地，在将打包后的数据包通过网络传输至接收端之后，还包括：接收来自于发送端的数据包；按照预先与所述发送端协商好的包结构体格式的序列，对数据包进行解析，其中，所述包结构体格式序列为：至少一个包类型字节、至少一个包长度字节、以及至少一个包体内容字节；将解析后的数据包的包体内容放置于指定变量中，传输至应用层处理。

优选地，所述至少一个包体内容字节包括：至少一个变量字串长度字节、至少一个变量字串内容字节、至少一个数据内容字节。

与现有技术相比，本发明实施例至少具有以下优点：将各地的语音增值业务统一到一个平台，各地通过网络链接到中心服务器(语音增值业务平台服务器CTIS)，从中心服务器通过图1的系统架构完成各地的语音增值业务开展，并且只用维护一套脚本语言就可以完成各地的语音增值业务的开发，简单易维护，能够实现各区域用户、资源的互联互通，使得各区平台用户共享资源。

附图说明

图1是根据相关技术的语音增值业务系统的架构示意图；

图2是根据本发明实施例的语音增值业务系统的架构示意图；

图3是根据本发明优选实施例的语音增值业务系统的架构示意图；

图4是根据本发明实施例的语音增值业务系统的通信方法的流程图；

图5是根据本发明优选实施例的语音增值业务系统的通信方法的流程图。

具体实施方式

下面结合说明书附图对本发明的具体实现方式做一详细描述。

图2是根据本发明实施例的语音互动式语音应答业务系统的架构示意图。如图2所示，该语音互动式语音应答业务系统包括：部署于各区域的多个语音增值业务服务器11、12…1N；设置于为上述语音增值业务服务器中一个或多个语音增值业务服务器的接入用户注册成虚拟用户并提交至脚本解析服务器IVRS 21，接收脚本解析服务器的控制指令并返回至上述一个或多个语音增值业务服务器的语音增值业务平台服务器CTIS 22，上述CTIS22分别与各个上述语音增值业务服务器11、12…1N建立有数据通信连接；设置于接收到上述虚拟用户后读取预先配置的脚本文件并分析解码形成上述控制指令的上述IVRS 21，上述IVRS21与上述CTIS 22建立有数据通信连接。

本发明将各地的语音增值业务统一到一个平台，各地通过网络链接到中心服务器(语音增值业务平台服务器CTIS)，从中心服务器通过图1的系统架构完成各地的语音增值业务开展，并且只用维护一套脚本语言就可以完成各地的语音增值业务的开发，简单易维护，能够实现各区域用户、资源的互联互通，使得各区平台用户共享资源。

优选地，各个上述语音增值业务服务器均集成有与接入用户建立连接的至少一个语音板卡。

在优选实施过程中，某区域电话语音增值业务用户先经过当前区域语音增值业务服务器的语音板卡进入本地电话语音增值业务系统(例如，电话对对碰业务系统)，然后经由本地电话语音增值业务系统接入到语音增值业务平台服务器CTIS。后续语音增值业务交由脚本解析服务器IVRS完成。

具体地，各地语音增值业务接续到CTIS，CTIS将各地的接入用户注册成为虚拟用户，将虚拟用户提交给IVRS服务器，IVRS服务器接入用户后，读取磁盘上开发人员预先编写好的语音增值业务脚本语言文件，通过脚本语言实现用户的IVR语音业务交互，IVRS主要完成语音业务的逻辑实现。具体实现内容在S语言脚本里面。如果有语音播放业务交给CTIS实现，再由CTIS交回区域语音增值业务服务器的语音板卡实现。

优选地，如图3所示，上述系统还可以包括：与上述IVRS建立有数据通信连接的数据库接口服务器DBAS，上述DBAS存储有各区域接入用户的业务数据。

优选地，如图3所示，上述CTIS、上述IVRS、以及上述DBAS分开部署在不同的计算机上，上述多个语音增值业务服务器共用上述CTIS。

优选地，如图3所示，各个上述语音增值业务服务器分别通过公网与上述CTIS连接，各个上述语音增值业务服务器分别基于TCP协议与上述CTIS传输数据。上述CTIS与上述IVRS通过局域网连接，上述IVRS与上述DBAS通过局域网连接。上述CTIS与上述IVRS可以基于TCP协议传输数据，上述IVRS与上述DBAS也可以基于TCP协议传输数据。

在优选实施过程中，本发明实施例在现有语音增值业务系统的基础上，新增加了一套系统(以下简称S系统)，并基于S系统的编程模型开发电话语音增值业务。S系统包括但不限于：三个服务器，分别是：用于数据库交互的数据库接口服务器DBAS，用于解析各地增值业务脚本文件的脚本解析服务器IVRS，用于接续各地电话增值业务(例如，电话对对碰)控制信令的语音增值业务平台服务器CTIS。

例如，一个电话对对碰用户通过电信局的电信专网连接到某地语音增值业务服务器，某地电话语音增值业务服务器通过TCP协议连接到本发明的CTIS。CTIS预先分配一个虚拟用户注册到CTIS服务器，再通过TCP协议连接进入IVRS形成虚拟的用户数据。IVRS接续进入CTIS注册的用户后，读取预置的脚本文件，分析解码形成控制命令通过TCP协议连接返回给CTIS。再通过CTIS的TCP协议连接返回到用户进入的语音增值业务服务器的语音板卡。语音板卡执行具体控制命令后形成语音信号通过用户的电话机播放语音文件。如果在IVRS分析解码形成控制命令之前，如需要读取用户的业务数据，则交由DBAS执行，DBAS将操作结果返回至IVRS。

图4是根据本发明实施例的语音增值业务系统的通信方法的流程图。在图2所示的语音增值业务系统中，语音增值业务平台服务器CTIS分别与各个所述语音增值业务服务器之间，以及脚本解析服务器IVRS与所述CTIS之间，均通过以下方式进行数据通信：

步骤S401：确定填充好数据的数据包的包长度。

步骤S403：按照发送端预先与接收端协商好的包结构体格式序列，对数据进行打包，其中，所述包结构体格式序列为：至少一个包类型字节、至少一个包长度字节、以及至少一个包体内容字节。

步骤S405：将打包后的数据包通过网络传输至所述接收端。

相关技术中的语音增值业务系统，通常采用HTTP协议和JSON协议传输数据。HTTP协议是基于网页传输定制协议。协议内容庞大，不适宜用于语音IVR业务；而JSON协议采用了发送端通过预先定义好KEY:VALUE方式通过字串方式组成一个由”{“和”}”包含的KEY:VALUE组合的一串字串作为内容通过字串序列化方式将文本字串发送到接收端，接收端将此字串通过解包器反向解析字串将对端发送信息解析出来，由于采用了网络传输都是字串方式传输，同时每一个包体传输变量都需要一个KEY描述,所以占用网络带宽大。

例如，一个标准的JSON格式：

需要传输的每一个数据都需要有一个KEY作为标识，以方便远端识别出来。比如‘result’这个变量字段。将这段JSON字串格式化为网络传输字串后如下：

{result:0,msg:0000,data:{tts:语音TTS数据}}所有的内容都要序列化到需要发送的缓冲区里面准备传输。

采用图4所示的方法，发送端和接收端预定义好需要发送好的包结构体。发送端按照双方协商好的打包方式将包结构体序列化通过网络传输到接收端，打包后网络传输的数据包为一个二进制的序列化数据流，其没有冗余数据，比如JSON中的KEY描述，包序列化的的具体位置代表包体内容的描述。这样就减少了冗余的报数据，所以占用网络带宽就比JSON协议传输小。此外，数据包中有至少一个字节标识当前要传输的数据包的长度，是固定的，因此能够预先估计带宽。而JSON协议中，每次要传输的数据都需要有KEY，且KEY长度不固定，还不能预先估计带宽。

优选地，所述CTIS和数据库接口服务器DBAS之间，也可以通过上述方式进行数据通信，即：确定得到填充好数据的数据包的包长度；按照发送端预先与接收端协商好的包结构体格式序列，对数据进行打包，其中，所述包结构体格式序列为：至少一个包类型字节、至少一个包长度字节、以及至少一个包体内容字节；将打包后的数据包通过网络传输至接收端。

优选地，在将打包后的数据包通过网络传输至接收端之后，在接收端，还可以包括以下处理：接收来自于发送端的数据包；按照预先与所述发送端协商好的包结构体格式的序列，对数据包进行解析，其中，所述包结构体格式序列为：至少一个包类型字节、至少一个包长度字节、以及至少一个包体内容字节；将解析后的数据包的包体内容放置于指定变量中，传输至应用层处理。

在优选实施过程中，发送端和接收端(其中，发送端可以是语音增值业务服务器，则接收端可以是CTIS；发送端可以是CTIS，则接收端可以是语音增值业务服务器；发送端可以是CTIS，则接收端可以是IVRS；发送端可以是IVRS，则接收端可以是CTIS；发送端可以是IVRS，则接收端可以是DBAS；发送端可以是DBAS，则接收端可以是IVRS)。同时共用一套预定义好的包结构，打包序列化双方都用同一套。发送端和接收端预先都知道包结构体格式序列，发送端将包结构体填充好后，交给双方协商预置好的打包模块将包结构体序列化后通过网络传输到接收端，接收端使用发送端打包方式对应的同一套解包方式将序列化包解包出来使用。收发双方预先设置包结构体中具体位置所存放的内容，需要发送端将包结构体中具体位置填充内容即可。即：收发双方预先为规定好的包体内容里面需要传输的内容预先开辟好空间，发送端只需要将需要传输的数据放到包结构体中具体位置里面，然后通过打包器将包打成一个序列化包后通过网络传输，发送端的打包模块将包结构体打包后，通过网络发送至接收端。到达接收端后，客户端将接收到包结构体，重新按照包结构体格式的序列解析并组装，将解析后的数据包的包体内容放置于指定变量中，传输至应用层处理。

其中，所述至少一个包体内容字节可以进一步包括：至少一个变量字串长度字节、至少一个变量字串内容字节、至少一个数据内容字节。

下面以游戏播放背景音乐包为例进行说明。

上面代码是根据本发明实例的一个标准的包结构体，发送端和接收端使用同一个上述包结构体，在发送端，上述包结构体的打包过程如下：

步骤1：预先计算确定填充好数据的数据包的包长度。

步骤2：按照发送端预先与接收端协商好的包结构体格式序列，对数据进行打包。

步骤3：序列化网络数据后将包通过网络传输到客户端。

上述数据字串打包过程，在包体内容的mszBackgroundMusic字节中前两个字节是变量字串长度字节，后面才是变量字串的内容字节。

上述包结构体格式序列如表1所示：

两个字节的包类型+两个字节的包长度+两个字节的变量字串长度mszBackgroundMusic+若干个字节的变量字串内容mszBackgroundMusic+若干个字节的数据内容miIsRound

表1

接收端解包过程是采用打包方式对应的解包方式，将序列化包按照STRU_GAME_PLAY_BACKGROUND_MUSIC_RQ格式解包反序列化数据到一个定义好的STRU_GAME_PLAY_BACKGROUND_MUSIC_RQ包结构变量中，客户端解包成功后就可以直接读取包结构变量直接使用。

以下结合图5进一步描述上述优选实施方式。

图5是根据本发明优选实施例的语音增值业务系统的通信方法的流程图。如图5所示，该语音增值业务系统的通信方法包括：

步骤S501：在发送端，预先计算确定填充好数据的数据包的包长度。

步骤S503：按照发送端预先与接收端协商好的包结构体格式序列，对数据进行打包，其中，所述包结构体格式序列为：至少一个包类型字节、至少一个包长度字节、以及至少一个变量字串长度字节、至少一个变量字串内容字节、至少一个数据内容字节。

步骤S505：序列化网络数据后将包通过网络传输至接收端。

步骤S507：在接收端，接收来自于发送端的数据包。

步骤S509：按照预先与所述发送端协商好的包结构体格式的序列，对数据包进行解析，其中，所述包结构体格式序列为：至少一个包类型字节、至少一个包长度字节、以及至少一个变量字串长度字节、至少一个变量字串内容字节、至少一个数据内容字节。

步骤S511：将解析后的数据包的包体内容放置于指定变量中，传输至应用层处理。

综上所述，采用本发明提供的语音增值业务系统及其通信方法，实现了各区域语音增值业务的联网，开发语言采用S系统脚本语言，不需要专业C++开发人员来开发。系统维护简单，不需重启系统就可以替换业务流程。业务脚本只需要维护一套，不像原有系统需要各地单独维护。不同平台的用户，可以通过各平台指定的通道，进入一个统一的业务平台，在该平台实现用户之间的资源共享与互联互通。此外，基于S系统构建了新的数据包传输协议，协议简单易实现，解决了S系统服务器之间的信令传输问题，针对S系统各个服务器之间传输信令提供了基础保证。避免了使用JSON协议占用带宽大，传输效率低下的问题。并且，数据包中有至少一个字节标识当前要传输的数据包的长度，是固定的，因此能够预先估计带宽。

以上公开的仅为本发明的几个具体实施例，但是，本发明并非局限于此，任何本领域的技术人员能思之的变化都应落入本发明的保护范围。

Claims (10)

1.一种语音增值业务系统，其特征在于，包括：

部署于各区域的多个语音增值业务服务器；

设置于为所述语音增值业务服务器中一个或多个语音增值业务服务器的接入用户注册成虚拟用户并提交至脚本解析服务器IVRS，接收脚本解析服务器的控制指令并返回至所述一个或多个语音增值业务服务器的语音增值业务平台服务器CTIS，所述CTIS分别与各个所述语音增值业务服务器建立有数据通信连接；

设置于接收到所述虚拟用户后读取预先配置的脚本文件并分析解码形成所述控制指令的所述IVRS，所述IVRS与所述CTIS建立有数据通信连接。

2.根据权利要求1所述的系统，其特征在于，各个所述语音增值业务服务器均集成有与接入用户建立连接的至少一个语音板卡。

3.根据权利要求1所述的系统，其特征在于，各个所述语音增值业务服务器分别通过公网与所述CTIS连接，各个所述语音增值业务服务器分别基于TCP协议与所述CTIS传输数据。

4.根据权利要求1至3中任一项所述的系统，其特征在于，还包括：与所述IVRS建立有数据通信连接的数据库接口服务器DBAS，所述DBAS存储有各区域接入用户的业务数据。

5.根据权利要求4所述的系统，其特征在于，所述CTIS、所述IVRS、以及所述DBAS分开部署在不同的计算机上，所述多个语音增值业务服务器共用所述CTIS。

6.根据权利要求4所述的系统，其特征在于，

所述CTIS与所述IVRS通过局域网连接，所述IVRS与所述DBAS通过局域网连接；

所述CTIS与所述IVRS基于TCP协议传输数据，所述IVRS与所述DBAS基于TCP协议传输数据。

7.一种权利要求1所述的语音增值业务系统的通信方法，其特征在于，语音增值业务平台服务器CTIS分别与各个所述语音增值业务服务器之间，以及脚本解析服务器IVRS与所述CTIS之间，均通过以下方式进行数据通信：

确定填充好数据的数据包的包长度；

按照发送端预先与接收端协商好的包结构体格式序列，对数据进行打包，其中，所述包结构体格式序列为：至少一个包类型字节、至少一个包长度字节、以及至少一个包体内容字节；

将打包后的数据包通过网络传输至所述接收端。

8.根据权利要求7所述的方法，其特征在于，所述CTIS和数据库接口服务器DBAS之间，通过以下方式进行数据通信：

确定得到填充好数据的数据包的包长度；

按照发送端预先与接收端协商好的包结构体格式序列，对数据进行打包，其中，所述包结构体格式序列为：至少一个包类型字节、至少一个包长度字节、以及至少一个包体内容字节；

将打包后的数据包通过网络传输至接收端。

9.根据权利要求7所述的方法，其特征在于，在将打包后的数据包通过网络传输至接收端之后，还包括：

接收来自于发送端的数据包；

按照预先与所述发送端协商好的包结构体格式的序列，对数据包进行解析，其中，所述包结构体格式序列为：至少一个包类型字节、至少一个包长度字节、以及至少一个包体内容字节；

将解析后的数据包的包体内容放置于指定变量中，传输至应用层处理。

10.根据权利要求7至9中任一项所述的方法，其特征在于，所述至少一个包体内容字节包括：至少一个变量字串长度字节、至少一个变量字串内容字节、至少一个数据内容字节。