CN103354547B - 控制语音接续的系统及方法 - Google Patents

Abstract

本发明公开一种控制语音接续的系统及方法，以解决现有的VoIP客户端不便于维护且不能进行跨平台移植的问题。本发明实施例公开的控制语音接续的系统，在底层之上依次设有接续层、代理层及应用层，其中：应用层，用于控制界面响铃和显示以及发出操作命令；代理层，用于转换应用层和接续层间的接口；接续层，用于纯逻辑控制呼叫状态转移及应用层回调。

Description

控制语音接续的系统及方法

技术领域

本发明涉及通信技术领域，尤其涉及一种可广泛应用于VoIP(VoiceoverInternetProtocol)的控制语音接续的系统及方法。

背景技术

近年来，随着移动互联网应用的快速发展，VoIP等网络通信方式日益改变着用户的交往方式。

VoIP系统至少包括VoIP客户端和VoIP服务器，VoIP客户端是基于手机或计算机固有的操作系统进行开发设计的，大多设有不同版本以可运行于安卓、IOS等手机操作系统上或PC机上。

其中，语音接续是VoIP系统稳定运行的关键一环。所谓语音接续即指VoIP客户端和VoIP服务器之间对语音的呼叫、挂断、响铃等接续动作所进行的处理，既包括信令层面的接续处理也包括数据流层面的接续处理。

本发明主要关注VoIP客户端对语音接续的控制处理。

VoIP客户端的语音接续，主要包括处理用户请求，向服务器发送请求、回复和心跳包，以及对所收到的VoIP服务器发送给应用层的与语音处理相关包的处理逻辑；由于语音接续包的传递通常是在互联网上进行，由于网络连接质量和终端网络连接可靠性等方面的问题，VoIP客户端、服务器之间在包传送过程中可能出现延迟到达或者丢包的问题。VoIP客户端收到包后，需要根据逻辑判断对收到的包该如何处理，以及经过处理后反映到应用层以响应何种操作(也就是iOS，Android等界面或声音操作)。

现有的VoIP客户端在开发过程中，对语音的接续处理，大多不使用接口分层，严重存在问题定位和维护困难等不便。而且由于不同的手机或PC操作系统之间的差异，往往需要针对不同的手机或PC操作系统进行单独的开发，导致所开发的VoIP客户端不能进行跨平台移植，开发效率低，资源浪费严重。

发明内容

本发明的主要目的在于公开一种控制语音接续的系统和方法，以解决现有的VoIP客户端不便于维护且不能进行跨平台移植的问题。

为达上述目的，本发明实施例公开一种控制语音接续的系统，在底层之上依次设有接续层、代理层及应用层，其中：

应用层，用于控制界面响铃和显示以及发出操作命令；

代理层，用于转换应用层和接续层间的接口；

接续层，用于纯逻辑控制呼叫状态转移及应用层回调。

为达上述目的，本发明实施例还公开一种控制语音接续的方法，包括：

将串行的语音接续按阶段划分，并将实现纯逻辑控制呼叫状态转移及应用层回调的接续层与实现操作界面响铃和显示以及发出操作命令的应用层解耦；以及

通过代理层实现应用层和接续层间接口的转换。

与现有技术相比，本发明公开的控制语音接续的系统和方法至少具有以下优点：

通过将语音接续拆分成应用层、代理层和接续层，且应用层和接续层解耦，系统及逻辑清晰，可控性强，为语音接续过程中的故障定位和维护提供了极大的便利而且扩展方便，同时系统上的优化使得语音接续的相关功能模块可以跨平台使用，提高了资源的利用率。其中代理层接口可使用JSON(JavaScriptObjectNotation，一种轻量级的数据交换格式)等接口，使得即使在没有应用层的情况下也通过脚本输入进行测试，既缩短了编译时间，又降低编程复杂度，提高了开发的准确率的工作效率；而且可以直接通过脚本产生测试数据测试接续层和应用层，使两个层次能够独立进行维护。

附图说明

图1是本发明实施例公开的控制语音接续的系统框图；

图2是图1中接续层的内部功能模块框图；

图3是本发明实施例公开的控制语音接续的方法流程图。

具体实施方式

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

实施例一

本实施例公开一种VoIP客户端控制语音接续的系统。如图1所示，该系统是在底层1之上依次设立的接续层2、代理层3及应用层4。其中，底层用于处理网络间消息，例如：对TCP/UDP数据包进行序列化传输和反序列化等。

本实施例公开的系统将VoIP客户端的语音接续拆分成三层。应用层用于控制界面响铃和显示以及发出操作命令，代理层用于转换应用层和接续层间的接口，接续层用于纯逻辑控制呼叫状态转移及应用层回调。即应用层主要用于实现和用户之间的界面显示和捕捉相关的操作命令，而业务的逻辑控制则由接续层进行控制，并通过底层的消息接口与VoIP服务器进行通讯。

依托图1所示的系统，应用层与接续层解耦，因此应用层和接续层可以采用两套数据流，并通过代理层来实现应用层和接续层间的接口的转换，因此各层的开发人员可以灵活择取最佳的编程语言以提高开发效率。较佳的，代理层可以使用JSON等接口，使得即使在没有应用层的情况下也通过脚本输入进行测试，进一步提高开发的准确率的工作效率；而且可以直接通过脚本产生测试数据测试接续层和应用层，使两个层次能够独立进行维护。

语音接续可以看做是一个串行的过程，因为从应用层来说，客户端界面命令的下达具有一定的时间间隔；从接续层来说，接续层对底层的消息的处理逻辑简单，并且有一定的先后顺序，只有满足顺序条件的消息才会被处理。从而为本发明实施例采用的分层系统提供了基础。然而，采用分层的系统之后，也导致分层后的逻辑是异步的。为此，在程序逻辑设计的时候，只要明确了整个通话流程会经历哪些阶段，需要哪些消息来控制，然后将每个阶段的处理独立起来，再通过任务指定的下一任务来判断当前任务是否应该加入到任务队列，轮到任务执行时再根据当前会话的状态判断任务是否该继续执行。通过这样的处理，就能有序地将接续任务组织起来，我们称呼这种接续任务管理方式为接续状态机。

为此，如图2所示，上述接续层的内部功能模块进一步包括：

任务产生模块21，用于根据应用层和底层的调用，产生任务，并将任务加入任务管理模块中进行统一管理；

任务管理模块22，用于在单独的线程中运行，根据任务添加的顺序执行任务，且一个任务执行完成后才取出下一任务继续执行。例如：客户点击呼叫按钮产生呼出任务。当呼出流程还没执行完成时，客户又立刻点击挂断产生挂断任务。如果不使用任务队列来处理就需要使用大量的逻辑进行控制，而使用任务队列后，每个任务执行完成后再执行下一任务。这样每个任务可单独运行，并且不用担心别的任务的打扰。

本发明实施例中，任务产生模块在需要的情况下还会指定下一任务，与之对应的，则上述“任务管理模块在一个任务执行完成后才取出下一任务继续执行”中的“下一个任务”既可以是一个新的任务也可以是上一任务指定的关联任务；为此，在执行具体的任务时，往往还需要进一步判断该任务是否是被“上一任务”指定的关联任务。

值得说明的是，所谓线程，有时被称为轻量级进程(LightweightProcess，LWP)，是程序执行流的最小单元。一个标准的线程由线程ID，当前指令指针(PC)，寄存器集合和堆栈组成。另外，线程是进程中的一个实体，是被系统独立调度和分派的基本单位，线程自己不拥有系统资源，只拥有一点在运行中必不可少的资源，但它可与同属一个进程的其它线程共享进程所拥有的全部资源。一个线程可以创建和撤消另一个线程，同一进程中的多个线程之间可以并发执行。由于线程之间的相互制约，致使线程在运行中呈现出间断性。线程也有就绪、阻塞和运行三种基本状态。每一个程序都至少有一个线程，若程序只有一个线程，那就是程序本身。

进一步的，本发明实施例还可以采用任务队列加定时器的框架，以依托该框架，实现通过任务划分精确地控制任务的执行顺序。如图2所示，接续层还设置有定时器23及其连接的定时器管理模块24；其中定时器管理模块与任务产生模块及任务管理模块连接，用于在单独的线程中运行并管理定时器，当定时器的使用者产生一个定时器并指定定时器超时处理函数后，加入该定时器，以及当定时器超时，调用该定时器指定的超时处理函数进行处理。本发明实施例中，定时器的使用者可以是任务产生模块，也可以是任务管理模块。藉此，整个接续层的逻辑变得简单，并具有清晰的层次；而且，为了使在复杂的接续过程不出错，接续层和应用层必然需要相互制约，而该系统正好可通过灵活组合，实现不同的控制效果。举例如下：

例如：主叫快速重复操作呼出挂断，由于应用层和接续层是异步的，会产生应用层已将界面关闭，但接续层的挂断操作还没完成的问题。这样下一次的呼出任务已经加入任务队列了，主叫才开始做数据清除处理，这样就会将下一次呼出的数据清除，造成在执行下一次呼出任务时程序崩溃。

面对这种状况，依托本发明实施例的系统，可以将清除数据的任务独立出来，做成界面销毁后应用层到接续层的接口，并且在创建挂断任务时指定下一任务为清除数据，此时就算有其他的任务产生也不会加入到任务队列进行处理。

由上例可见通过接口的扩展可实现接续层和应用层的交互，并通过任务划分实现逻辑精确控制，足见本发明框架具有很好的可扩展性和封闭性，而且逻辑层次很清晰。

本实施例中，依托接续层的任务产生模块、任务管理模块和定时器管理模块，三个模块至少具有如下三种组合工作模式：

模式一、任务产生模块产生任务加入任务管理模块，任务管理模块取出任务并执行。

模式二、任务产生模块产生延时任务，即将任务延时执行。

实现时，在任务的执行流程中加入定时器，任务从任务管理模块中取出后，还需等待定时器超时，才能执行定时器指定的超时处理函数。

应用举例：当用户点了呼出按钮，接续层将呼出任务分为两个阶段，第一阶段对呼出数据和通话状态进行维护，第二阶段延时两秒才将呼出请求发出。

模式三、任务产生模块产生循环任务，即将任务根据一定的时间间隔循环执行。

实现流程：如果定时器为循环定时器，定时器会循环计时，一旦定时器超时就会触发任务加入任务管理模块队列，这样就实现了任务根据一定的时间间隔循环执行。

依托本实施例公开的上述系统，任务管理模块维护的是一个任务队列。接续任务被一个个加入队列，每一次调用添加都会通知任务管理线程将任务取出并执行，任务执行完成再等待下一通知取出任务并执行。其中，有的任务会指定下一个要执行的任务，添加任务时，会将任务和当前执行任务所指定的下一任务进行比较，如果任务相同才会将该任务加入队列。而有的任务完成需要进行等待，就会产生一个定时器加入到定时管理模块，定时管理线程检测到定时器超时后才会继续后续处理。从而使得本发明实施例公开的系统具有很好的适应性和可扩展性；而且可以直接通过脚本产生测试数据测试接续层和应用层，使两个层次能够独立进行维护。

综上，本实施例通过将语音接续拆分成应用层、代理层和接续层，且应用层和接续层解耦，系统清晰，可控性强，该系统为语音接续过程中的故障定位和维护提供了极大的便利而且扩展方便，同时系统上的优化使得语音接续的相关功能模块可以跨平台使用，提高了资源的利用率。而且代理层接口可使用JSON等接口，使得即使在没有应用层的情况下也通过脚本输入进行测试，既缩短了编译时间，又降低编程复杂度，提高了开发的准确率的工作效率。

实施例二

与上述控制语音接续的结构相对应的，本实施例公开一种控制语音接续的方法。

如图3所示，该方法包括：

步骤S1、将串行的语音接续按阶段划分，并将实现纯逻辑控制呼叫状态转移及应用层回调的接续层与实现操作界面响铃和显示以及发出操作命令的应用层解耦。

步骤S2、通过代理层实现应用层和接续层间接口的转换。

该步骤中，较佳的，通过代理层具体实现应用层和接续层间接口的转换过程如下步骤s21和步骤s22。

步骤s21、应用层给接续层设置代理，将代理实例传入，并给代理层设置接口的具体实现实例。

本实施例中，接续层设计专门的接口类提供回调接口，接口类会将每个接口的函数名和参数转换为JSON，并通过代理实例访问统一接口将JSON传入代理层；应用层和代理层约定了唯一关键字来表示每个接口，在设计时，代理层通过获取JSON中的关键字找到具体的实现函数；代理层设计一个map来实现该关键字到接口的映射，map的索引是回调接口的关键字，索引对应的存储内容为代理指定实现接口。

步骤s22、代理层收到JSON后，解析JSON找到函数名对应的关键字，再在map中通过关键字对应的接口并执行，完成接续层到应用层的回调过程。

本实施例通过JSON来实现回调的好处在于，新增一个接口时，只需修改接口定义文件，再将接口关键字和代理指定的实现接口在map中注册即可。将接口转换为JSON传入代理层，解析并执行的过程都是统一、通用的。这样就使得接口设计具有很好的可扩展性和封闭性，易于维护。

可选的，本实施例中依托上述实施例一中的分层系统，控制语音接续的方法进一步包括：

步骤S3、接续层根据应用层和底层的调用，产生任务，并将任务加入任务管理模块中进行统一管理；其中任务管理模块在单独的线程中运行，根据任务添加的顺序执行任务，且一个任务执行完成后才取出下一任务继续执行。

该步骤中，在需要的情况下，产生任务的同时还会指定下一任务，与之对应的，则上述“一个任务执行完成后才取出下一任务继续执行”中的“下一个任务”既可以是一个新的任务也可以是上一任务指定的关联任务；为此，在执行具体的任务时，往往还需要进一步判断该任务是否是被“上一任务”指定的关联任务。

进一步的，控制语音接续的方法还包括：

步骤S4、接续层设置与任务管理模块连接的定时器管理模块，以在单独的线程中运行并管理定时器，使得当定时器的使用者产生一个定时器并指定定时器超时处理函数后，加入该定时器，以及当该定时器超时，调用该定时器指定的超时处理函数进行处理。

为使在复杂的接续过程不出错，接续层和应用层必然需要相互制约。例如：主叫快速重复操作呼出挂断，由于应用层和接续层是异步的，会产生应用层已将界面关闭，但接续层的挂断操作还没完成的问题。这样下一次的呼出任务已经加入任务队列了，主叫才开始做数据清除处理，这样就会将下一次呼出的数据清除，造成在执行下一次呼出任务时程序崩溃。为此，本实施例控制语音接续的方法在面对这种状况时，还包括：将清除数据的任务独立出来，做成界面销毁后应用层到接续层的接口，并且在创建挂断任务时指定下一任务为清除数据，此时就算有其他的任务产生也不会加入到任务队列进行处理。

综上，本实施例通过将语音接续拆分成应用层、代理层和接续层，且应用层和接续层解耦，逻辑清晰，可控性强，为语音接续过程中的故障定位和维护提供了极大的便利而且扩展方便，而且代理层接口可使用JSON等接口，使得即使在没有应用层的情况下也通过脚本输入进行测试，既缩短了编译时间，又降低编程复杂度，提高了开发的准确率的工作效率；而且可以直接通过脚本产生测试数据测试接续层和应用层，使两个层次能够独立进行维护。该方法可以广泛应用于各种VoIP客户端的开发设计或升级维护中。

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

Claims (9)

1.一种控制语音接续的系统，其特征在于，在底层之上依次设有接续层、代理层及应用层，其中：

应用层，用于控制界面响铃和显示以及发出操作命令；

代理层，用于转换应用层和接续层间的接口；

接续层，用于纯逻辑控制呼叫状态转移及应用层回调；

所述转换应用层和接续层间的接口，包括：应用层给接续层设置代理，将代理实例传入，并给代理层设置接口的具体实现实例；其中接续层设计专门的接口类提供回调接口，接口类会将每个接口的函数名和参数转换为JSON，并通过代理实例访问统一接口将JSON传入代理层；应用层和代理层约定了唯一关键字来表示每个接口，在设计时，代理层通过获取JSON中的关键字找到具体的实现函数；代理层设计一个map来实现该关键字到接口的映射，map的索引是回调接口的关键字，索引对应的存储内容为代理指定实现接口；

代理层收到JSON后，解析JSON找到函数名对应的关键字，再在map中通过关键字对应的接口并执行，完成接续层到应用层的回调过程。

2.根据权利要求1所述的控制语音接续的系统，其特征在于，所述接续层包括：

任务产生模块，用于根据应用层和底层的调用，产生任务，并将任务加入任务管理模块中进行统一管理；

任务管理模块，用于在单独的线程中运行，根据任务添加的顺序执行任务，且一个任务执行完成后才取出下一任务继续执行。

3.根据权利要求2所述的控制语音接续的系统，其特征在于，所述接续层还包括定时器及其连接的定时器管理模块；

所述定时器管理模块，与所述任务产生模块及任务管理模块连接，用于在单独的线程中运行并管理定时器，当定时器的使用者产生一个定时器并指定定时器超时处理函数后，加入该定时器；当定时器超时，调用该定时器指定的超时处理函数进行处理；

其中所述定时器的使用者为所述任务产生模块或所述任务管理模块。

4.根据权利要求1至3任一所述的控制语音接续的系统，其特征在于，所述应用层和接续层数据解耦。

5.根据权利要求4所述的控制语音接续的系统，其特征在于，所述代理层的转换通过JSON实现。

6.一种控制语音接续的方法，其特征在于，包括：

将串行的语音接续按阶段划分，并将实现纯逻辑控制呼叫状态转移及应用层回调的接续层与实现操作界面响铃和显示以及发出操作命令的应用层解耦；以及

通过代理层实现应用层和接续层间接口的转换；

所述通过代理层实现应用层和接续层间接口的转换包括：

应用层给接续层设置代理，将代理实例传入，并给代理层设置接口的具体实现实例；其中接续层设计专门的接口类提供回调接口，接口类会将每个接口的函数名和参数转换为JSON，并通过代理实例访问统一接口将JSON传入代理层；应用层和代理层约定了唯一关键字来表示每个接口，在设计时，代理层通过获取JSON中的关键字找到具体的实现函数；代理层设计一个map来实现该关键字到接口的映射，map的索引是回调接口的关键字，索引对应的存储内容为代理指定实现接口；

代理层收到JSON后，解析JSON找到函数名对应的关键字，再在map中通过关键字对应的接口并执行，完成接续层到应用层的回调过程。

7.根据权利要求6所述的控制语音接续的方法，其特征在于，包括：

所述接续层根据应用层和底层的调用，产生任务，并将任务加入任务管理模块中进行统一管理；其中所述任务管理模块在单独的线程中运行，根据任务添加的顺序执行任务，且一个任务执行完成后才取出下一任务继续执行。

8.根据权利要求7所述的控制语音接续的方法，其特征在于，包括：

将主叫的清除数据任务独立做成应用层到接续层的接口，并且在创建挂断任务时指定下一任务为清除数据。

9.根据权利要求7所述的控制语音接续的方法，其特征在于，包括：

所述接续层设置与所述任务管理模块连接的定时器管理模块，以在单独的线程中运行并管理定时器，使得当定时器的使用者产生一个定时器并指定定时器超时处理函数后，加入该定时器，以及当该定时器超时，调用该定时器指定的超时处理函数进行处理。