一种查勘任务的处理方法、装置及计算机可读存储介质与流程

文档序号:17817604发布日期:2019-06-05 21:56
一种查勘任务的处理方法、装置及计算机可读存储介质与流程

本发明涉及网络通讯技术领域,尤其涉及一种查勘任务的处理方法、装置及计算机可读存储介质。



背景技术:

目前,对于现场查勘,一般由查勘员使用移动查勘系统完成查勘和核损;其中,移动查勘系统可以由移动终端、远端后台服务器、坐席个人计算机(PC,Personal Computer)构成,查勘过程通常包括:查勘员通过移动终端向远端后台服务器发起呼叫的查勘请求,远端后台服务器将所述呼叫的查勘请求转发给坐席PC机,坐席人员接受所述呼叫的查勘请求后,坐席人员和查勘员开始进行通话,移动查勘系统自动录音录像,查勘员在现场拍照取证,将拍摄的图片通过移动终端上传到远端后台服务器,远端后台服务器将拍摄的图片和录像推送到坐席PC机的操作界面,这样,坐席人员就可以查看拍摄的图片和录像进行核损处理。

但是,目前的移动查勘系统中,当前处于通话状态的坐席人员无法通过坐席PC机同时处理多个移动终端的呼叫请求,即:一个坐席人员只能与一个查勘员进行音视频通话,不能同时与多个查勘员进行音视频通话,也就不能并行处理多个查勘任务,如此,明显降低了坐席人员的工作效率。



技术实现要素:

有鉴于此,本发明实施例期望提供一种查勘任务的处理方法、装置及计算机可读存储介质,能够实现一个服务端并行处理多个查勘任务。

本发明实施例的技术方案是这样实现的:

本发明实施例提供一种查勘任务的处理方法,所述方法包括:

服务器根据各用户终端发起的呼叫请求分别获取空闲的通道,并确定获取到的各个空闲的通道对应的服务端;每个服务端对应一个以上通道,每个空闲的通道用于处理一个待处理事件;

基于获取到的各空闲的通道,分别建立各待处理事件对应的用户终端与所述服务端之间的音视频连接。

上述方案中,所述获取空闲的通道,包括:

判断所述呼叫请求中是否携带有用户终端的标识信息;

如果确定携带有用户终端的标识信息、且根据所述标识信息确定所述用户终端发起的待处理事件未处理,则从所有服务端对应的一个以上通道中获取空闲的通道;否则,从处理过所述待处理事件的服务端对应的一个以上通道中获取空闲的通道。

上述方案中,所述从所有服务端对应的一个以上通道中获取空闲的通道,包括:

从所有服务端对应的一个以上通道中获取任意一个空闲的通道;

或者,按照轮询方式,从所有服务端对应的一个以上通道中顺序获取空闲的通道;

或者,根据所述用户终端的标识信息,确定所述用户终端所属的区域,从所述区域下的服务端对应的一个以上通道中获取空闲的通道;

或者,根据所述用户终端的标识信息以及针对用户终端预设的优先级,确定所述用户终端对应的优先级,从与所述优先级对应的服务端对应的一个以上通道中获取空闲的通道。

上述方案中,建立音视频连接之后,所述方法还包括:

接收所述用户终端发送的图像数据;

根据所述图像数据,生成录像文件。

上述方案中,所述根据所述图像数据,生成录像文件,包括:

对所述图像数据进行编解码,生成录像文件;所述录像文件用于供所述服务端下载并完成查勘定损;或者,

基于获取到的各空闲的通道,向所述服务端发送所述图像数据;所述图像数据用于供所述服务端生成录像文件并完成查勘定损。

上述方案中,所述方法还包括:

未获取到空闲的通道时,判断对呼叫请求执行获取空闲的通道的获取次数是否大于预设的最大获取次数,如果确定大于,则将服务端忙的状态通知待处理事件对应的用户终端;否则,对呼叫请求再次获取空闲的通道。

本发明实施例还提供一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时实现上述方法的步骤。

本发明实施例还提供一种查勘任务的处理装置,包括:处理器和用于存储能够在处理器上运行的计算机程序的存储器,

其中,所述处理器用于运行所述计算机程序时,执行上述方法的步骤。

本发明实施例还提供一种查勘任务的处理方法,所述方法包括:

服务端获取自身空闲的通道;每个服务端对应一个以上预设通道,每个空闲的通道用于处理一个待处理事件;

基于获取到的空闲的通道,建立待处理事件对应的用户终端与自身之间的音视频连接。

上述方案中,建立音视频连接之后,所述方法还包括:

基于所述空闲的通道,接收服务器发送的图像数据;

对所述图像数据进行编解码,得到录像文件;所述录像文件用于供服务端用户下载并完成查勘定损。

上述方案中,所述方法还包括:

向服务器发送录像文件的下载请求;

接收所述服务器发送的录像文件;所述录像文件用于供服务端用户下载并完成查勘定损。

上述方案中,所述方法还包括:

检测是否接收到用户在显示界面触发的第一指令;所述第一指令表征增加通道的指令;

当确定接收到所述第一指令时,加载一个新通道;

将所述新通道的空闲状态通知给所述服务器。

上述方案中,所述方法还包括:

检测是否接收到用户在显示界面触发的第二指令;所述第二指令表征当前通道空闲的指令;

当确定接收到所述第二指令时,将当前通道的空闲状态通知给所述服务器。

本发明实施例还提供一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时实现上述方法的步骤。

本发明实施例还提供一种查勘任务的处理装置,包括:处理器和用于存储能够在处理器上运行的计算机程序的存储器,

其中,所述处理器用于运行所述计算机程序时,执行上述方法的步骤。

本发明实施例还提供一种查勘任务的处理装置,所述装置包括:

第一获取模块,用于根据各用户终端发起的呼叫请求分别获取空闲的通道,并确定获取到的各个空闲的通道对应的服务端;每个服务端对应一个以上通道,每个空闲的通道用于处理一个待处理事件;

第一音视频连接模块,用于基于获取到的各空闲的通道,分别建立各待处理事件对应的用户终端与所述服务端之间的音视频连接。

上述方案中,

所述第一获取模块,具体用于判断所述呼叫请求中是否携带有用户终端的标识信息;如果确定携带有用户终端的标识信息、且根据所述标识信息确定所述用户终端发起的待处理事件未处理,则从所有服务端对应的一个以上通道中获取空闲的通道;否则,从处理过所述待处理事件的服务端对应的一个以上通道中获取空闲的通道。

本发明实施例还提供一种查勘任务的处理装置,所述装置包括:

第二获取模块,用于获取自身空闲的通道;每个服务端对应一个以上预设通道,每个空闲的通道用于处理一个待处理事件;

第二音视频连接模块,用于基于获取到的空闲的通道,建立待处理事件对应的用户终端与自身之间的音视频连接。

上述方案中,所述装置还包括:

通道增加模块,用于检测是否接收到用户在显示界面触发的第一指令;所述第一指令表征增加通道的指令;当确定接收到所述第一指令时,加载一个新通道;将所述新通道的空闲状态通知给所述服务器。

本发明实施例提供的查勘任务的处理方法、装置及计算机可读存储介质,引入通道的概念,使得一个服务端能对应一个以上通道,每个空闲的通道可以用于处理一个待处理事件;服务器根据各用户终端发起的呼叫请求分别获取空闲的通道,并确定获取到的各个空闲的通道对应的服务端;基于获取到的各空闲的通道,分别建立各待处理事件对应的用户终端与所述服务端之间的音视频连接。本发明实施例中,一个服务端可以同时使用多个空闲的通道分别处理多个待处理事件,进而能够针对不同的待处理事件,同时建立各待处理事件对应的用户终端与所述服务端之间的音视频连接,从而使一个服务端能并行处理多个查勘任务,大大提高了工作效率。

另外,本发明实施例中,用于建立音视频连接的请求既可以由用户终端发起,也可以由服务端发起,实现方式更灵活多样;当用户终端发起用于建立音视频连接的请求时,可由服务器根据用户终端发起的请求获取空闲的通道,并通过获取到的空闲的通道将用户终端发起的请求发送给服务端;当服务端发起用于建立音视频连接的请求时,服务端直接获取自身空闲的通道,并通过获取到的空闲的通道向服务器发送服务端主动向用户终端发起的请求,服务器将收到的服务端发起的用于建立音视频连接的请求转发给待处理事件对应的用户终端。显然,本发明实施例中服务端能主动发起用于建立音视频连接的请求,且能同时通过多个空闲的通道与多个用户终端交互,完成现场的查勘、核损,从而大大提高了工作效率。

附图说明

图1为本发明实施例查勘任务的处理方法的实现流程示意图一;

图2为本发明实施例查勘任务的处理方法的实现流程示意图二;

图3为本发明实施例移动查勘系统的网络拓扑示意图;

图4为本发明实施例移动查勘系统的整体架构示意图;

图5a为本发明实施例用户终端的功能模块框架示意图;

图5b为本发明实施例服务端的功能模块框架示意图;

图6为本发明实施例用户终端通过网络向移动查勘系统发起呼叫请求时查勘任务处理的具体实现流程示意图一;

图7为本发明实施例用户终端通过网络向移动查勘系统发起呼叫请求时查勘任务处理的具体实现流程示意图二;

图8为本发明实施例服务端通过网络向移动查勘系统发起呼叫请求时查勘任务处理的具体实现流程示意图一;

图9为本发明实施例服务端通过网络向移动查勘系统发起呼叫请求时查勘任务处理的具体实现流程示意图二;

图10为本发明实施例动态增加通道的流程示意图;

图11为本发明实施例查勘任务的处理装置的组成结构示意图一;

图12为本发明实施例查勘任务的处理装置的组成结构示意图二;

图13为本发明实施例查勘任务的处理装置的组成结构示意图三。

具体实施方式

为了能够更加详尽地了解本发明实施例的特点与技术内容,下面结合附图对本发明实施例的实现进行详细阐述,所附附图仅供参考说明之用,并非用来限定本发明。

如图1所示,本实施例以服务器侧为例详细说明查勘任务的处理方法,该查勘任务的处理方法应用于服务器侧,且用于建立实现查勘任务的音视频连接的请求由用户终端发起;图1所示的处理方法包括以下步骤:

步骤101:服务器根据各用户终端发起的呼叫请求分别获取空闲的通道,并确定获取到的各个空闲的通道对应的服务端。

其中,每个服务端对应一个以上通道,每个空闲的通道用于处理一个待处理事件。

实际应用时,本发明实施例中的服务器可以为移动查勘系统中的移动查勘服务器。所述服务器根据各用户终端发起的呼叫请求分别获取空闲的通道,具体包括:各用户终端将发起的呼叫请求发送给业务服务器,业务服务器根据接收的各用户终端发起的呼叫请求向移动查勘服务器发送至少一个空闲通道请求,移动查勘服务器接收到所述至少一个空闲通道请求后,对每个空闲通道请求分别获取空闲的通道。

在一实施例中,所述获取空闲的通道,包括:判断所述呼叫请求中是否携带有用户终端的标识信息;如果确定携带有用户终端的标识信息、且根据所述标识信息确定所述用户终端发起的待处理事件未处理,则从所有服务端对应的一个以上通道中获取空闲的通道;否则,从处理过所述待处理事件的服务端对应的一个以上通道中获取空闲的通道。

在一实施例中,所述从所有服务端对应的一个以上通道中获取空闲的通道,包括:从所有服务端对应的一个以上通道中获取任意一个空闲的通道;或者,按照轮询方式,从所有服务端对应的一个以上通道中顺序获取空闲的通道;或者,根据所述用户终端的标识信息,确定所述用户终端所属的区域,从所述区域下的服务端对应的一个以上通道中获取空闲的通道;或者,根据所述用户终端的标识信息以及针对用户终端预设的优先级,确定所述用户终端对应的优先级,从与所述优先级对应的服务端对应的一个以上通道中获取空闲的通道。

实际应用时,针对每个用户终端发起的呼叫请求分别获取空闲的通道时,包括两种情况:第一种、获取到空闲的通道;第二种、未获取到空闲的通道。

在一实施例中,当未获取到空闲的通道时,所述方法还包括:

判断对呼叫请求执行获取空闲的通道的获取次数是否大于预设的最大获取次数,如果确定大于,则将服务端忙的状态通知待处理事件对应的用户终端;否则,对呼叫请求再次获取空闲的通道。这里,预设的最大获取次数可以根据需要设置,比如:设置为三次或五次等。

实际应用时,当对呼叫请求未获取到空闲的通道时,服务器可以将对呼叫请求的排队情况和预计等待时长通知用户终端,所述预计等待时长用于用户终端确定等时长的待播放内容,比如:时长等于所述预计等待时长的一首歌曲。当预计等待时长的时间到达后,判断对呼叫请求执行获取空闲的通道的获取次数是否大于预设的最大获取次数,如果确定对呼叫请求执行获取空闲的通道的获取次数大于预设的最大获取次数,则将服务端忙的状态通知待处理事件对应的用户终端;否则,对呼叫请求再次进行排队,并再次获取空闲的通道。

当获取到空闲的通道时,执行步骤102。

步骤102:基于获取到的各空闲的通道,分别建立各待处理事件对应的用户终端与所述服务端之间的音视频连接。

这里,建立各待处理事件对应的用户终端与所述服务端之间的音视频连接,可以是服务器接收到用户终端发起的用于建立音视频连接的请求后,服务器获取空闲的通道,并通过获取到的空闲的通道将用户终端发起的请求转发给服务端;还可以是服务端发起用于建立音视频连接的请求,服务端直接获取自身的空闲的通道,并通过获取到的空闲的通道将向用户终端主动发起的请求发送服务器,服务器将服务端主动发起的请求转发给待处理事件对应的用户终端。

在一实施例中,建立音视频连接之后,所述方法还包括:接收所述用户终端发送的图像数据;根据所述图像数据,生成录像文件。

在一实施例中,所述根据所述图像数据,生成录像文件,包括:对所述图像数据进行编解码,生成录像文件;所述录像文件用于供所述服务端下载并完成查勘定损;或者,基于获取到的各空闲的通道,向所述服务端发送所述图像数据;所述图像数据用于供所述服务端生成录像文件并完成查勘定损。

这里,录像文件可以由服务器生成,还可以由服务端生成。由服务器直接生成录像文件,能够节省服务端的资源。

实际应用时,服务器接收到用户终端发送的“完成”消息时,服务器基于获取到的空闲的通道将“完成”消息转发给服务端,所述“完成”消息用于服务端停止录像并断开与待处理事件对应的用户终端之间的音视频连接。

实际应用时,服务器还可以接收服务端发送的状态消息,所述状态消息可以包括:“当前通道准备就绪”、“当前通道空闲”、“当前通道在通话”等等。

本发明实施例提供的方法,服务器根据各用户终端发起的呼叫请求分别获取空闲的通道,并确定获取到的各个空闲的通道对应的服务端;基于获取到的各空闲的通道,分别建立各待处理事件对应的用户终端与所述服务端之间的音视频连接。本发明实施例中,一个服务端可以同时使用多个空闲的通道分别处理多个待处理事件,进而能够针对不同的待处理事件,同时建立各待处理事件对应的用户终端与所述服务端之间的音视频连接,从而使一个服务端能并行处理多个查勘任务,大大提高了服务端用户的工作效率。

另外,本发明实施里中,音视频连接的建立既可以由用户终端发起,也可以由服务端发起,实现方式更灵活多样。当用户终端发起呼叫请求时,可由服务器根据各用户终端发起的请求分别获取空闲的通道并通过获取到的空闲的通道将用户终端发起的请求发送给服务端;当服务端发起呼叫请求时,服务端直接获取自身空闲的通道,并通过获取到的空闲的通道向服务器发送服务端主动向用户终端发起的请求,服务器将接收到的服务端主动发起的请求转发给待处理事件对应的用户终端。显然,本发明实施例中服务端能主动向用户终端发起呼叫请求,且能通过获取到的多个空闲的通道与多个用户终端交互,完成现场的查勘、核损,从而大大提高了服务端用户的工作效率。

如图2所示,本发明实施例以服务端侧详细说明本发明实施例查勘任务的处理方法,该查勘任务的处理方法应用与服务端侧,且用于建立实现查勘任务的音视频连接的请求由服务端主动发起;图2所示的处理方法包括以下步骤:

步骤201:服务端获取自身空闲的通道。

其中,每个服务端对应一个以上预设通道。每个空闲的通道用于处理一个待处理事件。

实际应用时,服务端获取到空闲的通道之后,可以将空闲的通道的状态消息发送服务器,所述状态消息可以为“当前通道空闲”、“当前通道准备就绪”、“当前通道在通话”等等。

在一实施例中,通道可以由会话发起协议(SIP)程序、或网页实时通话(webrtc)客户端、或具备独立信令处理和视频处理能力的装置中任意一种方式来实现。

步骤202:基于获取到的空闲的通道,建立待处理事件对应的用户终端与自身之间的音视频连接。

这里,建立待处理事件对应的用户终端与自身之间的音视频连接为:服务端主动向待处理事件对应的用户终端发起用于建立音视频连接的请求,服务端获取自身空闲的通道,并通过获取到的空闲的通道将主动发起的请求发送服务器,服务器将服务端向用户终端主动发起的请求转发给待处理事件对应的用户终端。

实际应用时,服务端用户可以从预设待处理事件列表中任意选择一个待处理事件,并向选定的待处理事件对应的用户终端发起呼叫请求。

在一实施例中,建立音视频连接之后,所述方法还包括:基于所述空闲的通道,接收服务器发送的图像数据;对所述图像数据进行编解码,得到录像文件;所述录像文件用于供服务端用户下载并完成查勘定损。

在一实施例中,建立音视频连接之后,所述方法还包括:向服务器发送录像文件的下载请求;接收所述服务器发送的录像文件;所述录像文件用于供服务端用户下载并完成查勘定损。

这里,录像文件可以由服务端生成,还可以由服务器生成。由服务器直接生成录像文件,能够节省服务端的资源。服务端生成录像文件后可以将录像文件上传到服务器。

实际应用时,服务端可以将通道的状态消息发送给服务器,所述状态消息可以为“新通道空闲”、“当前通道空闲”、“当前通道在通话”等等。

在一实施例中,所述方法还包括:检测是否接收到用户在显示界面触发的第一指令;所述第一指令表征增加通道的指令;当确定接收到所述第一指令时,加载一个新通道;将所述新通道的空闲状态通知给所述服务器。

在一实施例中,所述方法还包括:检测是否接收到用户在显示界面触发的第二指令;所述第二指令表征当前通道空闲的指令;当确定接收到所述第二指令时,将当前通道的空闲状态通知给所述服务器。

实际应用时,服务端可以在接收到服务器基于空闲的通道发送的“完成”消息后,停止录像并断开与待处理事件对应的用户终端之间的音视频连接。

这里,服务端可以根据业务需要,使用更多空闲的通道同时处理多个查勘任务。

下面详细介绍下本发明实施例在实际应用中采用的移动查勘系统的网络拓扑结构、以及基于该络拓扑结构实现查勘任务处理的过程及原理。

图3为本发明实施例移动查勘系统的网络拓扑示意图,如图3所示,移动查勘系统包括:用户终端、接入网关、业务服务器、移动查勘服务器、服务端、数据库;其中,

用户终端为具备音频视频采集和播放能力的移动设备,所述用户终端支持无线保真(WIFI,Wireless FIdelity)、全球微波互联接入(WIMAX,Worldwide Interoperability for Microwave Access)、蓝牙、数据线等多种方式连接到移动互联网络或者IP多媒体子系统(IMS,IP Multimedia Subsystem)网络。所述移动互联网包括但不限于3G、4G、5G,所述用户终端具体可以为Android手机、PAD,苹果手机、iPAD、移动笔记本等等。

接入网关用于用户终端通过网络注册到移动查勘系统,同时,所述接入网关是外网和移动查勘系统内网的边界网关,所述接入网关为用于跨网络的信令和媒体流穿越的设备。

业务服务器用于用户终端发起呼叫请求时,按照业务策略进行路由分发到移动查勘服务器;还用于向移动查勘服务器查询服务端的坐席状态和通道状态。

移动查勘服务器用于管理服务端的坐席的状态和通道的状态,还用于配合业务服务器查找出空闲的通道,并且转发用户终端向服务端的呼叫请求或者服务端向用户终端的呼叫请求;还用于接收用户终端上传的查勘图片,生成录像文件。

服务端为具备音频视频采集和播放能力的设备,所述服务端可以不具备视频采集能力,所述服务端可以为普通PC机、台式机、笔记本等等。

数据库用于存储服务端的坐席工号标识(ID,IDentification)和通道ID,记录坐席和通道的状态变化日志,记录每个通道的呼叫日志。

图4为本发明实施例移动查勘系统的整体架构示意图。如图4所示,移动查勘系统被划分为四个域,包括:用户域、接入域、业务域、坐席域;其中,

用户域包括:用户终端;接入域包括:接入网关;业务域包括:业务服务器、移动查勘服务器;坐席域包括服务端,服务端包括电脑和耳麦配套设备。

图5a为本发明实施例用户终端的功能模块框架示意图,图5b为本发明实施例服务端的功能模块框架示意图。

具体的,如图5a所示,用户终端的功能模块包括:业务处理模块、图片处理模块、图片上传模块、视频处理模块、指令处理模块、网络传输模块;其中,

业务处理模块,用于查询和显示保单、案件信息;图片处理模块,用于采集用户终端的摄像头拍摄的图像信息、对图像进行加密水印处理、压缩存储成符合查勘业务要求的图片文件;图片上传模块,用于将图片上传到移动查勘服务器;视频处理模块,用于用户终端音视频通话的编码、解码;指令处理模块,用于用户终端和服务端坐席之间发送消息指令,比如连线请求,连线结束消息,发送图片上传的路径信息等;网络传输模块,用于用户终端采集的音频、视频码流、以及查勘图片的底层网络传输。

如图5b所示,服务端的功能模块包括:业务处理模块、多通道总控模块、单通道指令处理模块、单通道视频处理模块、图片下载模块、录像上传模块、网络传输模块;其中,

业务处理模块,用于显示当前正在处理的案件信息;多通道总控模块,用于控制和协调多个单通道协同工作以及收集各个通道的状态;单通道指令处理模块,用于处理某个通道的示忙、示闲、接听、挂断等操作指令控制,和用户终端建立的呼叫;单通道视频处理模块,用于对各通道的音频视频编码、解码,每个单通道指令处理模块对应一个单通道视频处理模块;图片下载模块,用于从移动查勘服务器上下载查勘员上传的图像信息;录像上传模块,用于将通话过程中产生的录音录像文件上传到移动查勘服务器;网络传输模块,用于坐席端采集的音频、视频码流、以及查勘图片的底层网络传输。

图6为本发明实施例用户终端通过网络向移动查勘系统发起呼叫请求时,查勘任务处理的具体实现流程示意图,本实施例中,用户终端为查勘员使用的终端,服务器为移动查勘服务器,服务端为查勘业务坐席使用的PC机,待处理事件为上报的查勘案件;本实施例中,应用于移动查勘服务器侧,用于建立实现查勘任务的音视频连接的请求由用户终端发起,且由PC机对与用户终端在音视频通话中产生的图像数据进行录像;具体实现过程,包括如下步骤:

步骤601:用户终端通过网络注册到接入网关。

查勘员在用户终端上打开网络连接,输入账户信息,通过网络注册到接入网关,准备开始发起呼叫请求。同时,PC机的业务坐席输入工号和密码,通过网络注册到接入网关,通过多通道总控模块初始化两个单通道指令处理模块和两个视频处理模块,并通过多通道总控模块向移动查勘服务器上报两个空闲通道已经准备就绪。

步骤602:用户终端向接入网关发起查勘案件1的呼叫请求。

查勘员在用户终端的显示界面上选择一个查勘案件1,点击呼叫请求,用户终端向接入网关发起呼叫请求。

步骤603:接入网关收到呼叫请求后,将所述呼叫请求转发给后台的业务服务器。

步骤604:业务服务器在数据库中查找查勘案件1的受理信息。

步骤605:业务服务器根据查询的结果判断查勘案件1是否为新查勘案件。

步骤606:若查勘案件1是新查勘案件,则向移动查勘服务器发送空闲通道请求,移动查勘服务器查找空闲的通道时,查询所有业务坐席对应的空闲的通道,然后执行步骤608。

查询所有业务坐席对应的空闲的通道,也就是不限定业务坐席工号范围。

步骤607:若查勘案件1不是新查勘案件,则向移动查勘服务器发送空闲通道请求,移动查勘服务器查找之前受理过查勘案件1的业务坐席工号对应的空闲的通道。

步骤608:移动查勘服务器接收到至少一个空闲通道请求后,在数据库或者内存中查找空闲的通道。

移动查勘服务器可以对所述至少一个空闲通道请求进行排队处理。

步骤609:若移动查勘服务器没有查询到空闲的通道,向业务服务器返回当前排队人数和预计等待时长,然后执行步骤613。

同时,用户终端通过业务处理模块在显示界面提示查勘员“当前有xx个人在排队,预计等待xx分钟”,还可以向查勘员播放排队等待音乐,排队等待时长默认30秒。

步骤610:当预计等待时长的时间到达时,移动查勘服务器判断本次排队是否超过最大排队次数。

可以设置最大排队次数为默认值如3次。

步骤611:若超过最大排队次数,向业务服务器返回排队失败的消息。

同时,用户终端通过业务处理模块在显示界面提示“对不起,业务坐席全忙,请稍候再试”的消息给查勘员。

步骤612:若没有超过最大排队次数,移动查勘服务器再次对空闲通道请求进行排队,再次执行步骤608。

同时,在用户终端上播放提示音“请稍后正在转后台业务坐席服务”给查勘员。

步骤613:若找到空闲的通道1,移动查勘服务器将当前的呼叫请求分配给通道1,用户终端向通道1发起呼叫请求。

步骤614:PC机通道1的指令处理模块收到呼叫请求后,通过业务处理模块在PC机界面上提示“通道1查勘案件1请求呼叫”。

若业务坐席在PC机界面上点击“拒绝连线”,或者在规定的时间内没有点击“接受连线”,都执行步骤622。若,业务坐席在规定的时间内在PC机界面上点击“接受连线”,执行步骤615。所述规定的时间可以为默认值如30秒。

步骤615:PC机通道1的单通道指令处理模块建立通道1和用户终端的音视频通话,通道1的视频处理模块开始编解码,PC机界面上将看到用户终端现场的影像信息,PC机通道1自动开始在PC机本地进行录音录像。

同时,PC机的多通道总控模块向移动查勘服务器上报状态如“当前业务坐席的通道1处于通话中”。

步骤616:业务坐席和查勘员开始音视频通话,业务坐席告知查勘员工作规范要求,注意事项,查勘员开始现场取证工作。

步骤617:业务坐席在PC机界面上点击“有空”按钮,多通道总控模块向移动查勘服务器上报状态“当前业务坐席工号的状态处于通话中,但是通道2处于空闲状态”。

步骤618:移动查勘服务器将查勘案件2的呼叫请求分配给空闲的通道2。执行步骤613之后的步骤。

这样,业务坐席使用通道1和通道2并行处理两个来自不同用户终端的呼叫请求。

步骤619:查勘员使用用户终端开始在现场进行查勘、拍照取证、上传图片到移动查勘服务器。

步骤620:完成现场作业后,查勘员在用户终端界面上点击“完成”动作,结束与PC机业务坐席的音视频通话。

在查勘的过程中,查勘员随时可以和业务坐席通过消息、音视频互动交流。

步骤621:移动查勘服务器将“完成”消息转发给PC机端通道1的指令处理模块,PC机通道1停止录像采集工作,并通过录像上传模块将录像文件上传到移动查勘服务器。

同时,通道1通过业务处理模块,在PC机界面上提示“通道1,查勘案件1已经完成作业,请进行核损”。业务坐席通过PC机的图片下载模块,从移动查勘服务器上查看查勘员的取证图像。业务坐席打开核心理赔系统,完成定损作业。

步骤622:业务坐席使用通道1完成查勘和核损工作全部结束。

查勘定损任务完成后,业务坐席在PC机界面上点击“有空”按钮,多通道总控模块向移动查勘服务器上报状态即“当前业务坐席的通道1处于空闲状态”。

移动查勘服务器将下一个用户终端的呼叫请求分配给空闲的通道1。然后执行步骤613之后的步骤。

图7为本发明实施例用户终端通过网络向移动查勘系统发起呼叫请求时,查勘任务处理的具体实现流程示意图,本实施例中,用户终端为查勘员使用的终端,服务器为移动查勘服务器,服务端为查勘业务坐席使用的PC机,待处理事件为上报的查勘案件;本实施例中,应用于移动查勘服务器侧,用于建立实现查勘任务的音视频连接的请求由用户终端发起,且由移动查勘服务器对用户终端发送的查勘图像数据进行录像;具体实现过程,包括如下步骤:

步骤701:用户终端通过网络注册到接入网关。

查勘员在用户终端上打开网络连接,输入账户信息,通过网络注册到接入网关,准备开始发起呼叫请求。同时,PC机的业务坐席输入工号和密码,通过网络注册到接入网关,通过多通道总控模块初始化两个单通道指令处理模块和两个视频处理模块,并通过多通道总控模块向移动查勘服务器上报两个空闲通道已经准备就绪。

步骤702:用户终端向接入网关发起查勘案件1的呼叫请求。

查勘员在用户终端的显示界面上选择一个查勘案件1,点击呼叫请求,用户终端向接入网关发起呼叫请求。

步骤703:接入网关收到呼叫请求后,将所述呼叫请求转发给后台的业务服务器。

步骤704:业务服务器在数据库中查找查勘案件1的受理信息。

步骤705:业务服务器根据查询的结果判断查勘案件1是否为新查勘案件。

步骤706:若查勘案件1是新查勘案件,则向移动查勘服务器发送空闲通道请求,移动查勘服务器查找空闲的通道时,查询所有业务坐席对应的空闲的通道,然后执行步骤708。

查询所有业务坐席对应的空闲的通道,也就是不限定业务坐席工号范围。

步骤707:若查勘案件1不是新查勘案件,则向移动查勘服务器发送空闲通道请求,移动查勘服务器查找之前受理过查勘案件1的业务坐席工号对应的空闲的通道。

步骤708:移动查勘服务器接收到至少一个空闲通道请求后,在数据库或者内存中查找空闲的通道。

移动查勘服务器可以对所述至少一个空闲通道请求进行排队处理。

步骤709:若移动查勘服务器没有查询到空闲的通道,向业务服务器返回当前排队人数和预计等待时长,然后执行步骤713。

同时,用户终端通过业务处理模块在显示界面提示查勘员“当前有xx个人在排队,预计等待xx分钟”,还可以向查勘员播放排队等待音乐,排队等待时长默认30秒。

步骤710:当预计等待时长的时间到达时,移动查勘服务器判断本次排队是否超过最大排队次数。

可以设置最大排队次数为默认值如3次。

步骤711:若超过最大排队次数,向业务服务器返回排队失败的消息。

同时,用户终端通过业务处理模块在显示界面提示“对不起,业务坐席全忙,请稍候再试”的消息给查勘员。

步骤712:若没有超过最大排队次数,移动查勘服务器再次对空闲通道请求进行排队,再次执行步骤708。

同时,在用户终端上播放提示音“请稍后正在转后台业务坐席服务”给查勘员。

步骤713:若找到空闲的通道1,移动查勘服务器将当前的呼叫请求分配给通道1,用户终端向通道1发起呼叫请求。

步骤714:PC机通道1的指令处理模块收到呼叫请求后,通过业务处理模块在PC机界面上提示“通道1查勘案件1请求呼叫”。

若业务坐席在PC机界面上点击“拒绝连线”,或者在规定的时间内没有点击“接受连线”,都执行步骤722。若,业务坐席在规定的时间内在PC机界面上点击“接受连线”,执行步骤715。所述规定的时间可以为默认值如30秒。

步骤715:PC机通道1的单通道指令处理模块建立通道1和用户终端的音视频通话,通道1的视频处理模块开始编解码,PC机界面上将看到用户终端现场的影像信息,移动查勘服务器自动开始进行录音录像。

同时,PC机的多通道总控模块向移动查勘服务器上报状态如“当前业务坐席的通道1处于通话中”。

步骤716:业务坐席和查勘员开始音视频通话,业务坐席告知查勘员工作规范要求,注意事项,查勘员开始现场取证工作。

步骤717:业务坐席在PC机界面上点击“有空”按钮,多通道总控模块向移动查勘服务器上报状态“当前业务坐席工号的状态处于通话中,但是通道2处于空闲状态”。

步骤718:移动查勘服务器将查勘案件2的呼叫请求分配给空闲的通道2。执行步骤713之后的步骤。

这样,业务坐席使用通道1和通道2并行处理两个来自不同用户终端的呼叫请求。

步骤719:查勘员使用用户终端开始在现场进行查勘、拍照取证、上传图片到移动查勘服务器。

步骤720:完成现场作业后,查勘员在用户终端界面上点击“完成”动作,结束与PC机业务坐席的音视频通话。

在查勘的过程中,查勘员随时可以和业务坐席通过消息、音视频互动交流。

步骤721:移动查勘服务器停止通道1的录像采集工作,同时将“完成”消息转发给服务端通道1的指令处理模块。

同时,通道1通过业务处理模块,在PC机界面上提示“通道1,查勘案件1已经完成作业,请进行核损”。业务坐席通过PC机的图片下载模块,从移动查勘服务器上查看查勘员的取证图像。业务坐席打开核心理赔系统,完成定损作业。

步骤722:业务坐席使用通道1完成查勘和核损工作全部结束。

查勘定损任务完成后,业务坐席在PC机界面上点击“有空”按钮,多通道总控模块向移动查勘服务器上报状态即“当前业务坐席的通道1处于空闲状态”。

移动查勘服务器将下一个用户终端的呼叫请求分配给空闲的通道1。然后执行步骤713之后的步骤。

图8为本发明实施例服务端通过网络向移动查勘系统发起呼叫请求时,查勘任务处理的具体实现流程示意图,本实施例中,用户终端为查勘员使用的终端,服务器为移动查勘服务器,服务端为查勘业务坐席使用的PC机,待处理事件为上报的查勘案件;本实施例中,应用于PC机侧,用于建立实现查勘任务的音视频连接的请求由PC机主动发起,且由PC机对与用户终端在音视频通话中产生的图像数据进行录像;具体实现过程,包括如下步骤:

步骤801:用户终端通过网络注册到接入网关。

查勘员在用户终端上打开网络连接,输入账户信息,通过网络注册到接入网关,准备开始发起呼叫请求。同时,PC机的业务坐席输入工号和密码,通过网络注册到接入网关,通过多通道总控模块初始化两个单通道指令处理模块和两个视频处理模块,并通过多通道总控模块向移动查勘服务器上报两个空闲通道已经准备就绪。

步骤802:PC机通过业务处理模块在显示界面上列出了当前查勘案件列表,业务坐席在PC机显示界面上选择查勘案件1,点击呼叫请求,使用空闲的通道1向移动查勘服务器发起外呼请求。

步骤803:移动查勘服务器接收到连线请求后,向接入网关转发送通道1查勘案件1的呼叫请求。

步骤804:接入网关向用户终端发起呼叫请求。

步骤805:用户终端在接收呼叫请求后,通过业务处理模块显示“xx话务员正在发起查勘案件1的连线”,提示“接受连线”或者“拒绝连线”消息给查勘员,查勘员在用户终端界面上点击“接受连线”。

步骤806:PC机通道1的单通道指令处理模块建立通道1和用户终端的音视频通话,通道1的视频处理模块开始编解码,PC机界面上将看到现场的影像信息,PC机的通道1自动开始在PC机本地进行录音录像。

同时,PC机的多通道总控模块向移动查勘服务器上报状态即“当前业务坐席的通道1处于通话中”。

步骤807:业务坐席和查勘员开始音视频通话,业务坐席告知查勘员工作规范要求、注意事项,查勘员开始现场取证工作。

步骤808:业务坐席在PC机界面上点击“有空”按钮,多通道总控模块向移动查勘服务器上报状态“当前业务坐席工号的状态处于通话中,但是通道2处于空闲状态”。

步骤809:PC机的业务坐席可以使用通道2处理查勘案件2的音视频连接,然后执行步骤802之后的步骤。

这样,业务坐席使用通道1和通道2并行处理两个不同用户终端的呼叫请求。

步骤810:查勘员使用用户终端开始在现场进行查勘、拍照取证、上传图片到移动查勘服务器。

步骤811:完成现场作业后,查勘员在用户终端界面上点击“完成”动作,结束与PC机业务坐席的音视频通话。

在查勘的过程中,查勘员随时可以和业务坐席通过消息、音视频互动交流。

步骤812:移动查勘服务器将“完成”消息转发给PC机端通道1的指令处理模块,通道1停止录像采集工作,并通过录像上传模块将录像文件上传到移动查勘服务器。

同时,通道1通过业务处理模块,在PC机界面上提示“通道1,查勘案件1已经完成作业,请进行核损”。业务坐席通过PC机的图片下载模块,从移动查勘服务器上查看查勘员的取证图像。业务坐席打开核心理赔系统,完成定损作业。

步骤813:业务坐席使用通道1完成移动查勘和定损工作全部结束。

查勘定损结束后,业务坐席在PC机界面上点击“有空”按钮,多通道总控模块向移动查勘服务器上报状态即“当前业务坐席的通道1处于空闲状态”。

PC机的业务坐席使用通道1处理下一个查勘案件的音视频连线请求,然后执行步骤802之后的步骤。

图9为本发明实施例服务端通过网络向移动查勘系统发起呼叫请求时,查勘任务处理的具体实现流程示意图,本实施例中,用户终端为查勘员使用的终端,服务器为移动查勘服务器,服务端为查勘业务坐席使用的PC机,待处理事件为上报的查勘案件;本实施例中,应用于PC机侧,用于建立实现查勘任务的音视频连接的请求由PC机主动发起,且由移动查勘服务器对用户终端发送的查勘图像数据进行录像;具体实现过程,包括如下步骤:

步骤901:用户终端通过网络注册到接入网关。

查勘员在用户终端上打开网络连接,输入账户信息,通过网络注册到接入网关,准备开始发起呼叫请求。同时,PC机的业务坐席输入工号和密码,通过网络注册到接入网关,通过多通道总控模块初始化两个单通道指令处理模块和两个视频处理模块,并通过多通道总控模块向移动查勘服务器上报两个空闲通道已经准备就绪。

步骤902:PC机界面上通过业务处理模块列出了当前查勘案件列表,业务坐席在显示界面上选择查勘案件1,点击呼叫请求,使用空闲的通道1向移动查勘服务器发起外呼请求。

步骤903:移动查勘服务器接收到PC机主动发起的请求后,向接入网关转发通道1查勘案件1的呼叫请求。

步骤904:接入网关向用户终端发起呼叫请求。

步骤905:用户终端在接收呼叫请求后,通过业务处理模块显示“xx话务员正在发起查勘案件1的连线”,提示“接受连线”或者“拒绝连线”消息给查勘员,查勘员在用户终端界面上点击“接受连线”。

步骤906:PC机通道1的单通道指令处理模块建立通道1和用户终端的音视频通话,通道1的视频处理模块开始编解码,PC机界面上将看到现场的影像信息,移动查勘服务器自动开始进行录音录像。

同时,PC机的多通道总控模块向移动查勘服务器上报状态即“当前业务坐席的通道1处于通话中”。

步骤907:业务坐席和查勘员音视频通话,人工语音告知查勘员工作规范要求、注意事项,查勘员开始现场取证工作。

步骤908:业务坐席在PC机的PC机界面上点击“有空”按钮,多通道总控模块向移动查勘服务器上报状态“当前业务坐席工号的状态处于通话中,但是通道2处于空闲状态”。

步骤909:PC机的业务坐席可以使用通道2处理查勘案件2的音视频连接,然后执行步骤902之后的步骤。

这样,业务坐席使用通道1和通道2并行处理两个不同用户终端的呼叫请求。

步骤910:查勘员使用用户终端开始在现场进行查勘、拍照取证、上传图片到移动查勘服务器。

步骤911:完成现场作业后,查勘员在用户终端界面上点击“完成”动作,结束与PC机业务坐席的音视频通话。

在查勘的过程中,查勘员随时可以和业务坐席通过消息、音视频互动交流。

步骤912:移动查勘服务器将“完成”消息转发给PC机端通道1的指令处理模块,移动查勘服务器停止录像采集工作。

同时,通道1通过业务处理模块,在PC机界面上提示“通道1,查勘案件1已经完成作业,请进行核损”。业务坐席通过PC机的图片下载模块,从移动查勘服务器上查看查勘员的取证图像。业务坐席打开核心理赔系统,完成定损作业。

步骤913:业务坐席的通道1的移动查勘和定损工作全部结束。

查勘定损结束后,业务坐席在PC机界面上点击“有空”按钮,多通道总控模块向移动查勘服务器上报状态即“当前业务坐席的通道1处于空闲状态”。

PC机的业务坐席使用通道1处理下一个查勘案件的音视频连线请求,然后执行步骤902之后的步骤。

图10为本发明实施例动态增加通道的流程示意图,本实施例中,用户终端为查勘员使用的终端,服务器为移动查勘服务器,服务端为查勘业务坐席使用的PC机,待处理事件为上报的查勘案件;本实施例中,应用于移动查勘服务器侧,用于建立实现查勘任务的音视频连接的请求由用户终端发起,且由PC机对与用户终端在音视频通话中产生的图像数据进行录像;具体实现过程,包括以下步骤:

步骤1001:用户终端通过网络注册到接入网关,发起呼叫请求。

查勘员在用户终端上打开网络连接,输入账户信息,通过网络注册到接入网关,准备开始发起呼叫请求。同时,PC机的业务坐席输入工号和密码,通过网络注册到接入网关,通过多通道总控模块初始化两个单通道指令处理模块和两个视频处理模块,并通过多通道总控模块向移动查勘服务器上报两个空闲通道已经准备就绪。

步骤1002:PC机的业务坐席使用通道1的单通道指令处理模块建立通道1和用户终端的音视频通话,通道1的视频处理模块开始编解码,PC机界面上将看到现场的影像信息。PC机通道1开始录音录像。

PC机的多通道总控模块向移动查勘服务器上报状态即“当前业务坐席的通道1处于通话中”。

步骤1003:业务坐席和查勘员开始音视频通话,业务坐席告知查勘员工作规范要求、注意事项,查勘员开始现场取证工作。

步骤1004:业务坐席在PC机的显示界面上点击“新增通道”按钮,通过多通道总控模块加载一个新的单通道指令处理模块和一个视频处理模块,

假设新的通道为通道2,多通道总控模块向移动查勘服务器上报状态,所述状态为“当前业务坐席的通道2准备就绪”。

步骤1005:业务坐席在PC机的显示界面上点击“有空”按钮,多通道总控模块向移动查勘服务器上报状态“当前业务坐席工号的状态处于通话中,但是通道2处于空闲状态”。

步骤1006:PC机的业务坐席可以使用通道2处理查勘案件2的音视频连接,然后执行步骤1002之后的步骤。

这样,业务坐席使用通道1和通道2并行处理两个不同用户终端的呼叫请求。

步骤1007:查勘员使用用户终端开始在现场进行查勘、拍照取证、上传图片到移动查勘服务器。

步骤1008:完成现场作业后,查勘员在用户终端界面上点击“完成”动作,结束与PC机业务坐席的音视频通话。

在查勘的过程中,查勘员随时可以和业务坐席通过消息、音视频互动交流。

步骤1009:移动查勘服务器将“完成”消息转发给PC机端通道1的指令处理模块,通道1停止录像采集工作,并通过录像上传模块将录像文件上传到移动查勘服务器。

同时,通道1通过业务处理模块,在PC机界面上提示“通道1,查勘案件1已经完成作业,请进行核损”。业务坐席通过PC机的图片下载模块,从移动查勘服务器上查看查勘员的取证图像。业务坐席打开核心理赔系统,完成定损作业。

步骤1010:业务坐席使用通道1完成移动查勘和定损工作全部结束。

查勘定损结束后,业务坐席在PC机界面上点击“有空”按钮,多通道总控模块向移动查勘服务器上报状态即“当前业务坐席的通道1处于空闲状态”。

PC机的业务坐席使用通道1处理下一个查勘案件的音视频连线请求,然后执行步骤1002之后的步骤。

基于本申请各实施例提供的查勘任务的处理方法,本申请还提供一种查勘任务的处理装置,可以设置在服务器上,且用于建立实现查勘任务的音视频连接的请求由用户终端发起;如图11所示,所示装置包括:第一获取模块111、第一音视频连接模块112;其中;

第一获取模块111,用于根据各用户终端发起的呼叫请求分别获取空闲的通道,并确定获取到的各个空闲的通道对应的服务端。

第一音视频连接模块112,用于基于获取到的各空闲的通道,分别建立各待处理事件对应的用户终端与所述服务端之间的音视频连接。

其中,每个服务端对应一个以上通道,每个空闲的通道用于处理一个待处理事件。

在一实施例中,所述第一获取模块111,具体用于判断所述呼叫请求中是否携带有用户终端的标识信息;如果确定携带有用户终端的标识信息、且根据所述标识信息确定所述用户终端发起的待处理事件未处理,则从所有服务端对应的一个以上通道中获取空闲的通道;否则,从处理过所述待处理事件的服务端对应的一个以上通道中获取空闲的通道。

在一实施例中,所述第一获取模块111,具体用于从所有服务端对应的一个以上通道中获取任意一个空闲的通道;或者,按照轮询方式,从所有服务端对应的一个以上通道中顺序获取空闲的通道;或者,根据所述用户终端的标识信息,确定所述用户终端所属的区域,从所述区域下的服务端对应的一个以上通道中获取空闲的通道;或者,根据所述用户终端的标识信息以及针对用户终端预设的优先级,确定所述用户终端对应的优先级,从与所述优先级对应的服务端对应的一个以上通道中获取空闲的通道。

实际应用时,针对每个用户终端发起的呼叫请求分别获取空闲的通道时,包括两种情况:第一种、获取到空闲的通道;第二种、未获取到空闲的通道。

所述第一音视频连接模块112,具体用于接收到用户终端发起的用于建立音视频连接的请求后,获取空闲的通道,并通过获取到的空闲的通道将用户终端发起的请求转发给服务端。

在一实施例中,所述装置还包括:判断模块;其中,

判断模块,用于未获取到空闲的通道时,判断对呼叫请求执行获取空闲的通道的获取次数是否大于预设的最大获取次数,如果确定大于,则将服务端忙的状态通知待处理事件对应的用户终端;否则,对呼叫请求再次获取空闲的通道。

这里,预设的最大获取次数可以根据需要设置,比如:设置为三次或五次等。

实际应用时,当对呼叫请求未获取到空闲的通道时,服务器可以将对呼叫请求的排队情况和预计等待时长通知用户终端,所述预计等待时长用于用户终端确定等时长的待播放内容,比如:时长等于所述预计等待时长的一首歌曲。当预计等待时长的时间到达后,判断对呼叫请求执行获取空闲的通道的获取次数是否大于预设的最大获取次数,如果确定对呼叫请求执行获取空闲的通道的获取次数大于预设的最大获取次数,则将服务端忙的状态通知待处理事件对应的用户终端;否则,对呼叫请求再次进行排队,并再次获取空闲的通道。

在一实施例中,所述装置还包括:第一录像生成模块;其中,

第一录像生成模块,用于接收所述用户终端发送的图像数据;根据所述图像数据,生成录像文件。

在一实施例中,所述第一录像生成模块,具体用于对所述图像数据进行编解码,生成录像文件;所述录像文件用于供所述服务端下载并完成查勘定损;或者,基于获取到的各空闲的通道,向所述服务端发送所述图像数据;所述图像数据用于供所述服务端生成录像文件并完成查勘定损。

这里,录像文件可以由服务器生成,还可以由服务端生成。由服务器直接生成录像文件,能够节省服务端的资源。

实际应用时,所述装置还包括第一发送模块、第一接收模块;其中,

第一发送模块,用于基于获取到的空闲的通道将“完成”消息转发给服务端。所述“完成”消息用于服务端停止录像并断开与待处理事件对应的用户终端之间的音视频连接。

第一接收模块,用于接收服务端发送的状态消息。所述状态消息可以包括:“当前通道准备就绪”、“当前通道空闲”、“当前通道在通话”等等。

需要说明的是:上述实施例提供的查勘任务的处理装置在进行处理时,仅以上述各程序模块的划分进行举例说明,实际应用中,可以根据需要而将上述处理分配由不同的程序模块完成,即将装置的内部结构划分成不同的程序模块,以完成以上描述的全部或者部分处理。另外,上述实施例提供的推荐装置与推荐方法实施例属于同一构思,其具体实现过程详见方法实施例,这里不再赘述。

在实际应用中,第一获取模块111、第一发送模块、第一接收模块由位于查勘任务的处理装置上的网络接口实现;第一音视频连接模块112、判断模块、第一录像生成模块可由位于查勘任务的处理装置上的中央处理器(CPU,Central Processing Unit)、微处理器(MPU,Micro Processor Unit)、数字信号处理器(DSP,Digital Signal Processor)、或现场可编程门阵列(FPGA,Field Programmable Gate Array)等实现。

基于本申请各实施例提供的查勘任务的处理方法,本申请还提供一种查勘任务的处理装置,可以设置在服务端上,且用于建立实现查勘任务的音视频连接的请求由服务端主动发起;如图12所示,所述装置包括:第二获取模块121、第二音视频连接模块122;其中,

第二获取模块121,用于获取自身空闲的通道。

第二音视频连接模块122,用于基于获取到的空闲的通道,建立待处理事件对应的用户终端与自身之间的音视频连接。

其中,每个服务端对应一个以上预设通道。每个空闲的通道用于处理一个待处理事件。所述通道可以由SIP程序、或webrtc客户端、或具备独立信令处理和视频处理能力的装置中任意一种方式来实现。

这里,第二音视频连接模块122,具体用于获取自身空闲的通道,并通过获取到的空闲的通道将主动发起的呼叫请求发送服务器;服务器将服务端向用户终端主动发起的呼叫请求转发给待处理事件对应的用户终端。

实际应用时,服务端用户可以从预设待处理事件列表中任意选择一个待处理事件,并向选定的待处理事件对应的用户终端主动发起呼叫请求。

在一实施例中,所述装置还包括:第二录像生成模块;其中,

第二录像生成模块,用于基于获取到的空闲的通道接收服务器发送的图像数据;对所述图像数据进行编解码,得到录像文件。所述录像文件用于供服务端用户下载并完成查勘定损。

在一实施例中,所述装置还包括:第二接收模块、第二发送模块;其中,

第二发送模块,用于向服务器发送录像文件的下载请求。

第二接收模块,用于接收所述服务器发送的录像文件;所述录像文件用于供服务端用户下载并完成查勘定损。

这里,录像文件可以由服务端生成,还可以由服务器生成。由服务器直接生成录像文件,能够节省服务端的资源。服务端生成录像文件后可以将录像文件上传到服务器。

实际应用时,第二获取模块121获取到空闲的通道之后,可以利用第二发送模块将空闲的通道的状态消息发送服务器。所述状态消息可以为“当前通道空闲”、“当前通道准备就绪”、“当前通道在通话”等等。

在一实施例中,所述装置还包括:检测模块、通道增加模块;

所述通道增加模块,用于检测是否接收到用户在显示界面触发的第一指令;所述第一指令表征增加通道的指令;当确定接收到所述第一指令时,加载一个新通道;将所述新通道的空闲状态通知给所述服务器。

所述检测模块,用于检测是否接收到用户在显示界面触发的第二指令;所述第二指令表征当前通道空闲的指令;当确定接收到所述第二指令时,利用第二发送模块将当前通道的空闲状态通知给所述服务器。

实际应用时,服务端可以利用第二接收模块接收到服务器基于空闲的通道发送的“完成”消息后,第二音视频连接模块122停止录像并断开与待处理事件对应的用户终端之间的音视频连接。

这里,服务端可以根据业务需要,使用更多空闲的通道同时处理多个查勘任务。

需要说明的是:上述实施例提供的查勘任务的处理装置在进行处理时,仅以上述各程序模块的划分进行举例说明,实际应用中,可以根据需要而将上述处理分配由不同的程序模块完成,即将装置的内部结构划分成不同的程序模块,以完成以上描述的全部或者部分处理。另外,上述实施例提供的推荐装置与推荐方法实施例属于同一构思,其具体实现过程详见方法实施例,这里不再赘述。

在实际应用中,第二获取模块121、第二发送模块、第二接收模块由位于查勘任务的处理装置上的网络接口实现;第二音视频连接模块122、第二录像生成模块、检测模块、通道增加模块可由位于查勘任务的处理装置上的CPU、MPU、DSP、或FPGA等实现。

图13是本发明查勘任务的处理装置的结构示意图,图13所示的查勘任务的处理装置1300包括:至少一个处理器1301、存储器1302、用户接口1303、至少一个网络接口1304。查勘任务的处理装置1300中的各个组件通过总线系统1305耦合在一起。可理解,总线系统1305用于实现这些组件之间的连接通信。总线系统1305除包括数据总线之外,还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见,在图13中将各种总线都标为总线系统1305。

其中,用户接口1303可以包括显示器、键盘、鼠标、轨迹球、点击轮、按键、按钮、触感板或者触摸屏等。

可以理解,存储器1302可以是易失性存储器或非易失性存储器,也可包括易失性和非易失性存储器两者。其中,非易失性存储器可以是只读存储器(ROM,Read Only Memory)、可编程只读存储器(PROM,Programmable Read-Only Memory)、可擦除可编程只读存储器(EPROM,Erasable Programmable Read-Only Memory)、电可擦除可编程只读存储器(EEPROM,Electrically Erasable Programmable Read-Only Memory)、磁性随机存取存储器(FRAM,ferromagnetic random access memory)、快闪存储器(Flash Memory)、磁表面存储器、光盘、或只读光盘(CD-ROM,Compact Disc Read-Only Memory);磁表面存储器可以是磁盘存储器或磁带存储器。易失性存储器可以是随机存取存储器(RAM,Random Access Memory),其用作外部高速缓存。通过示例性但不是限制性说明,许多形式的RAM可用,例如静态随机存取存储器(SRAM,Static Random Access Memory)、同步静态随机存取存储器(SSRAM,Synchronous Static Random Access Memory)、动态随机存取存储器(DRAM,Dynamic Random Access Memory)、同步动态随机存取存储器(SDRAM,Synchronous Dynamic Random Access Memory)、双倍数据速率同步动态随机存取存储器(DDRSDRAM,Double Data Rate Synchronous Dynamic Random Access Memory)、增强型同步动态随机存取存储器(ESDRAM,Enhanced Synchronous Dynamic Random Access Memory)、同步连接动态随机存取存储器(SLDRAM,SyncLink Dynamic Random Access Memory)、直接内存总线随机存取存储器(DRRAM,Direct Rambus Random Access Memory)。本发明实施例描述的存储器1302旨在包括但不限于这些和任意其它适合类型的存储器。

本发明实施例中的存储器1302用于存储各种类型的数据以支持查勘任务的处理装置1300的操作。这些数据的示例包括:用于在查勘任务的处理装置1300上操作的任何计算机程序,如操作系统13021和应用程序13022;其中,操作系统13021包含各种系统程序,例如框架层、核心库层、驱动层等,用于实现各种基础业务以及处理基于硬件的任务。应用程序13022可以包含各种应用程序,用于实现各种应用业务。实现本发明实施例方法的程序可以包含在应用程序13022中。

上述本发明实施例揭示的方法可以应用于处理器1301中,或者由处理器1301实现。处理器1301可能是一种集成电路芯片,具有信号的处理能力。在实现过程中,上述方法的各步骤可以通过处理器1301中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器1301可以是通用处理器、数字信号处理器,或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。处理器1301可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本发明实施例所公开的方法的步骤,可以直接体现为硬件译码处理器执行完成,或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于存储介质中,该存储介质位于存储器1302,处理器1301读取存储器1302中的信息,结合其硬件完成前述推荐方法的步骤。

基于本申请各实施例提供的查勘任务的处理方法,本申请还提供一种计算机可读存储介质,参照图13所示,所述计算机可读存储介质可以包括:用于存储计算机程序的存储器1302,上述计算机程序可由查勘任务的处理装置1300的处理器1301执行,以完成前述查勘任务的处理方法所述步骤。计算机可读存储介质可以是FRAM、ROM、PROM、EPROM、EEPROM、Flash Memory、磁表面存储器、光盘、或CD-ROM等存储器。

以上所述,仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围。

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