发明内容
基于此,有必要针对上述技术问题,提供一种能够提高审批效率的基于内网代理的视频面签系统和方法。
一种基于内网代理的视频面签系统,所述系统包括用户终端、代理服务器和坐席终端,其中:
所述用户终端,用于响应于触发操作生成视频面签指令,并通过所连接的外网将所述视频面签指令传输到代理服务器,所述视频面签指令包括指令接收地址;
所述代理服务器,用于在接收到视频面签指令时,通过所处的内网将所述视频面签指令发送至所述指令接收地址所指向的坐席终端;
所述坐席终端,用于在接收到视频面签指令时,创建所述坐席终端与所述用户终端之间的视频面签进程,以及与所述视频面签进程相适应的面签参数;所述面签参数包括加入到所述视频面签进程的接入地址;
所述坐席终端,还用于通过所连接的内网将所述面签参数发送至所述代理服务器,以使所述代理服务器通过对应的外网将所述面签参数转发至所述用户终端;
所述用户终端,还用于在接收到所述面签参数时,基于所述面签参数中的接入地址加入到所述视频面签进程中,以实现与所述坐席终端之间的视频面签操作。
在其中一个实施例中,所述坐席终端,还用于在视频面签操作的过程中,生成屏幕共享指令,并将所述屏幕共享指令通过所述代理服务器转发至用户终端;
所述用户终端,还用于在接收到所述屏幕共享指令时,检测响应操作,并当检测到表征同意共享的响应操作时,采集所述用户终端当前的显示屏幕画面,并将采集的显示屏幕画面通过所述代理服务器转发至坐席终端。
在其中一个实施例中,所述系统还包括存储服务器,其中:
所述代理服务器,还用于录制从视频面签操作开始至视频面签操作结束的过程中对应生成的视频流数据;
所述存储服务器,用于从所述代理服务器处获取录制的所述视频流数据,并对获取的视频流数据进存储。
在其中一个实施例中,所述代理服务器与所述坐席终端通过多个TCP端口进行内网通信,其中:
所述坐席终端,还用于向所述代理服务器中部署的各个TCP端口分别发起通信连接请求,并根据各个TCP端口反馈的连接请求结果,进行TCP端口连通性的验证。
在其中一个实施例中,所述用户终端与所述坐席终端在进行视频面签操作的过程中,通过所述代理服务器上部署的多个UDP端口进行视频流数据的转发,其中:
所述代理服务器,还用于对预设的各个UDP端口进行监听;
所述坐席终端,还用于分别向各个UDP端口发送报文数据;
所述代理服务器,还用于在对各个UDP端口进行监听的过程中,基于各个UDP端口接收到报文数据,进行UDP端口连通性的验证。
在其中一个实施例中,所述代理服务器中部署有反向代理服务和穿透服务,其中:
所述代理服务器基于部署的反向代理服务,对接收到的视频面签指令和面签参数进行代理转发;
所述代理服务器基于部署的穿透服务,对视频面签操作的过程中所需传输到用户终端的第一视频流数据、所需传输到坐席终端的第二视频流数据,以及所需传输到坐席终端的显示屏幕画面进行代理转发。
在其中一个实施例中,所述穿透服务中还部署有中继子服务和会话穿透子服务,其中:
当内网与外网之间设有防火墙时,基于部署的会话穿透子服务,根据固定的公网地址和固定的通信端口,搭建所述用户终端与所述坐席终端之间的通信通道;
在基于所述会话穿透子服务完成对所述通信通道的搭建之后,基于部署的中继子服务,通过所述通信通道进行所述第一视频流数据、第二视频流数据和显示屏幕画面的中继转发。
一种基于内网代理的视频面签方法,所述方法包括:
用户终端响应于触发操作生成视频面签指令,并通过所连接的外网将所述视频面签指令传输到代理服务器,所述视频面签指令包括指令接收地址;
所述代理服务器在接收到视频面签指令时,通过所处的内网将所述视频面签指令发送至所述指令接收地址所指向的坐席终端;
所述坐席终端在接收到视频面签指令时,创建所述坐席终端与所述用户终端之间的视频面签进程,以及与所述视频面签进程相适应的面签参数;所述面签参数包括加入到所述视频面签进程的接入地址;
所述坐席终端通过所连接的内网将所述面签参数发送至所述代理服务器,以使所述代理服务器通过对应的外网将所述面签参数转发至所述用户终端;
所述用户终端在接收到所述面签参数时,基于所述面签参数中的接入地址加入到所述视频面签进程中,以实现与所述坐席终端之间的视频面签操作。
在其中一个实施例中,所述方法还包括:
当所述代理服务器与所述坐席终端通过多个TCP端口进行内网通信时,所述坐席终端向所述代理服务器中部署的各个TCP端口分别发起通信连接请求,并根据各个TCP端口反馈的连接请求结果,进行TCP端口连通性的验证;
当通过所述代理服务器上部署的多个UDP端口进行视频流数据的转发时,所述坐席终端分别向各个UDP端口发送报文数据,并由所述代理服务器对预设的各个UDP端口进行监听,且,在对各个UDP端口进行监听的过程中,基于各个UDP端口接收到报文数据,进行UDP端口连通性的验证。
在其中一个实施例中,所述方法还包括:
由所述代理服务器中部署的反向代理服务,对接收到的视频面签指令和面签参数进行代理转发;
当内网与外网之间设有防火墙时,基于所述代理服务器中部署的会话穿透子服务,根据固定的公网地址和固定的通信端口,搭建所述用户终端与所述坐席终端之间的通信通道;
在基于所述会话穿透子服务完成对所述通信通道的搭建之后,基于所述代理服务器中部署的中继子服务,对视频面签操作的过程中所需传输到用户终端的第一视频流数据、所需传输到坐席终端的第二视频流数据,以及所需传输到坐席终端的显示屏幕画面进行中继转发。
上述基于内网代理的视频面签系统和方法,在内网隔离的网络环境下,基于部署的代理服务器进行视频面签指令、面签参数的转发,避免客户信息等敏感数据暴露于公网中,提升了风险管控水平。并且,用户终端还能够根据接收到面签参数,基于面签参数中的接入地址加入到先前由坐席终端创建的视频面签进程中,实现与坐席终端之间的视频面签操作,上述的操作方式使得坐席终端即便是处于内网环境中,也能够顺利地执行视频面签业务,保证了坐席人员与外网指定用户之间的实时音视频通话,提高了业务执行效率。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本申请进行进一步详细说明。应当理解,此处描述的具体实施例仅仅用以解释本申请,并不用于限定本申请。
本申请提供的基于内网代理的视频面签方法,可以应用于如图1所示的应用环境中。其中,用户终端102通过外网与代理服务器104进行通信,坐席终端106通过内网与代理服务器104进行通信。在实现用户终端102与坐席终端106之间的视频面签操作时,由用户终端102响应于触发操作生成视频面签指令,并通过所连接的外网将视频面签指令传输到代理服务器104,视频面签指令包括指令接收地址。代理服务器104在接收到视频面签指令时,通过所处的内网将视频面签指令发送至指令接收地址所指向的坐席终端106。坐席终端106在接收到视频面签指令时,创建坐席终端106与用户终端102之间的视频面签进程,以及与视频面签进程相适应的面签参数;面签参数包括加入到视频面签进程的接入地址。坐席终端106通过所连接的内网将面签参数发送至代理服务器104,以使代理服务器104通过对应的外网将面签参数转发至用户终端102。当用户终端102在接收到面签参数时,基于面签参数中的接入地址加入到视频面签进程中,以实现与坐席终端之间的视频面签操作。
其中,用户终端102和坐席终端106可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备,代理服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现。
在一个实施例中,如图2所示,提供了一种基于内网代理的视频面签方法,以该方法应用于图1中的应用场景为例进行说明,具体包括以下步骤:
步骤S202,用户终端响应于触发操作生成视频面签指令,并通过所连接的外网将视频面签指令传输到代理服务器,视频面签指令包括指令接收地址。
其中,视频面签指令指代是由用户终端向坐席终端发送的呼叫信息,其即可以理解为“视频邀请”指令,也可以理解为“等待呼叫”指令等,本申请实施例对此不作限定。
具体的,当用户终端和坐席终端中均设有音视频服务时(该音视频服务提供了登录子服务、验证子服务、监听子服务和视频通话子服务),在用户终端的前端界面中显示由登录子服务提供的登录页面。其中,该登录页面中设有至少一个信息输入框。需要说明的是,该信息输入框即可以为用户名输入框,也可以为密码信息输入框等等,本申请实施例对此不作限定。当位于用户终端侧的指定用户将相应的登录信息(例如用户名、登录密码等)输入到上述的信息输入框时,由用户终端调用验证子服务进行登录信息的获取,并进行用户身份的验证。当用户身份验证成功时,将由用户终端调用视频通话子服务,并从登录页面切换到由视频通话子服务提供的呼叫页面(这里,呼叫页面的示意图具体可以参考图3)。最终,在由用户终端向坐席终端发起视频通话连接之前,由用户终端进行视频面签指令的生成,并通过所连接的外网将视频面签指令传输到代理服务器。
在其中一个实施例中,前述的音视频服务可以集成于一个应用程序中,在指定用户基于用户终端成功登录该应用程序之后,由用户终端生成视频面签指令,并通过用户终端所连接的外网,将生成的视频面签指令传输到代理服务器,由代理服务器做进一步的转发处理。另外,在执行前述的步骤之前,本实施例中还可以通过用户终端进行后端接口的调用,并同步生成用于初始化应用程序的加签参数。在由用户终端或运行音视频服务的服务器完成对该应用程序的初始化处理之后,由用户终端基于音视频服务中部署的监听子服务,创建一个即时通讯的通讯线程。需要说明的是,当前创建的通讯线程可以用于对生成的视频面签指令进行监听并反馈。
当前实施例中,通过音视频服务中设置的各项子服务进行用户身份的验证、以及视频面签指令的监听等,保障了应用程序的稳定运行,提高了视频面签效率。
步骤S204,代理服务器在接收到视频面签指令时,通过所处的内网将视频面签指令发送至指令接收地址所指向的坐席终端。
具体的,请参考图4,其为整体网络访问规划示意图。当前,代理服务器中部署有Nginx-反向代理服务,且代理服务器与坐席终端之间基于部署的Nginx服务,通过多个TCP端口进行内网通信。当代理服务器接收到视频面签指令时,由代理服务器通过具备良好连通性的TCP端口,进行视频面签指令的转发。
在其中一个实施例中,在进行视频面签指令转发之前,由坐席终端向代理服务器中部署的各个TCP端口分别发起通信连接请求,并根据各个TCP端口反馈的连接请求结果,进行各个TCP端口连通性的验证。具体在应用的时候,可以考虑由坐席终端进行telnet指令的调用以及执行,并在坐席终端成功执行telnet指令时,由坐席终端向代理服务器的各个TCP端口发起通信连接请求,并对各个TCP端口反馈的连接请求结果进行汇总。其中,反馈的连接请求结果可以为“连接成功”、“连接失败”等,示例性的,当任一TCP端口反馈的连接请求结果为“连接成功”时,即可以判断对应的TCP端口具备良好的连通性,反之亦然,本申请对比不作过多说明。
当前实施例中,基于部署的反向代理服务进行视频面签指令的转发,且在转发之前由坐席终端向代理服务器中部署的各个TCP端口分别发起通信连接请求,并根据各个TCP端口反馈的连接请求结果,进行各个TCP端口连通性的验证,避免了无效TCP端口的投入使用,提高了视频面签指令的转发效率。
步骤S206,坐席终端在接收到视频面签指令时,创建坐席终端与用户终端之间的视频面签进程,以及与视频面签进程相适应的面签参数;面签参数包括加入到视频面签进程的接入地址。
具体的,在坐席终端的前端显示界面中,显示由视频通话子服务提供的呼叫等待页面和通话页面。当坐席终端接收到视频面签指令,并确定需要与指定用户建立视频通话时,通过在呼叫等待页面中显示指引信息和/或指引弹窗,指引坐席人员进入由音视频服务提供的指定音视频房间中,示例性的,“指引坐席人员进入由音视频服务提供的指定音视频房间中”这一步骤可以理解为创建视频面签进程,由呼叫等待页面切换到通话页面。
在其中一个实施例中,当坐席终端接收到视频面签指令时,将调用预设的弹窗指令,在呼叫等待页面中弹出至少一个会话显示窗口,其中,在前端界面中显示的会话显示窗口,也可以间接起到提示坐席人员的作用。示例性的,提示的内容包括“当前已有指定用户发起了视频邀请”、“指定用户处于等待连接状态中”等,本申请实施例对比不作限定。在另一个实施例中,在坐席终端的前端界面中显示的会话显示窗口中可以设有“接受”按钮,当坐席人员点击该“接受”按钮时,将由呼叫等待页面切换到通话页面。其中,通话页面的示意图具体可参考图5,由图5可知,当前位于用户终端侧的指定用户,并没有进入到指定音视频房间中;另外,应用程序中也提供了个人影像、工作影像等截图功能,供位于坐席终端侧的坐席人员进行自由调配。当用户终端获取到指定音视频房间的相关参数时,即可根据相关参数所确定的接入地址,加入到指定音视频房间中,与坐席人员进行视频通话。
当前实施例中,将开启指定音视频房间的控制权交由坐席人员,禁止客户自行开启音视频房间,避免了音视频资源的浪费。
步骤S208,坐席终端通过所连接的内网将面签参数发送至代理服务器,以使通过对应的外网将面签参数转发至用户终端。
需要说明的是,在进行面签参数转发的时候,由代理服务器通过具备良好连通性的TCP端口,将面签参数转发至用户终端。示例性的,本实施中采用的TCP端口包括443端口和8687端口中的至少一种,本申请实施例对此不做限定。
步骤S210,用户终端在接收到面签参数时,基于面签参数中的接入地址加入到视频面签进程中,以实现与坐席终端之间的视频面签操作。
具体的,当用户终端接收到面签参数时,基于面签参数中的接入地址(即音视频房间参数)加入到坐席终端所处的指定音视频房间中,与位于坐席终端处的坐席人员进行视频通话。需要说明的是,在视频面签操作的过程中:
一方面,由坐席终端生成屏幕共享指令,并由坐席终端将屏幕共享指令通过代理服务器转发至用户终端。在用户终端接收到屏幕共享指令时,将由用户终端检测响应操作,并当检测到表征同意共享的响应操作时,采集用户终端当前的显示屏幕画面,并由用户终端将采集到的显示屏幕画面通过代理服务器转发至坐席终端。
另一方面,在需要对视频面签过程中生成的视频流数据进行存储时,将先由代理服务器录制从视频面签操作开始至视频面签操作结束的过程中对应生成的视频流数据;再由视频面签系统中设置的存储服务器获取代理服务器录制的视频流数据,并对获取的视频流数据进行存储。
在其中一个实施例中,由坐席终端生成屏幕共享指令,示例性的,该屏幕共享指令可为“打开屏幕共享”的消息指令或“请求屏幕共享”的消息指令等,本申请实施例对此不作限定。需要说明的是,在由代理服务器进行视频流数据的录制时,可以基于坐席终端中预先设置的云端录制功能,自动进行视频流的录制;并在结束视频通话时,将录制得到的视频流数据传输到存储服务器,或者,由存储服务器自行进行视频流数据的获取。
基于当前实施例,一方面为了便于进行后续的存档备份和容灾备份,将由代理服务器定时向存储服务器请求获取(即下载)所需备份的视频流数据,并在请求成功时(即下载成功时),调用一个异地的数据系统进行视频流数据的容灾备份;另外,在进行存档备份时,可以通过多个外置硬盘或计算机设备上的其他硬盘(当然也可以采用其他的备份设备,例如数据存储管理软件等,本申请实施例对比不作限定),进行视频流数据的存档备份。
基于当前实施例,另一方面需要说明的是,生成的屏幕共享指令,将由代理服务器转发至用户终端,经指定用户授权同意后,由用户终端调用屏幕共享功能,将采集到的显示屏幕画面通过代理服务器转发至坐席终端,此时坐席人员即可通过前端界面查看到用户终端的屏幕共享画面。当然,本实施例中采用的应用程序也可以提供截图、备注和人脸比对等功能项,本申请实施例对此不作限定。上述的各项功能项,具体可参考以下实施方式:
(1)基于提供的截图功能项,进行屏幕共享画面的整体或部分图像截取,而截取到的屏幕共享画面可以通过代理服务器转发到用户终端,或者上传到数据库或本地存储文件夹中,做进一步的存储处理。
(2)在坐席人员与指定用户进行视频通话的过程中,基于提供的备注功能项,使得坐席人员能够及时补充审批资料。
(3)在坐席人员与指定用户进行视频通话的过程中,基于提供的人脸比对功能项,使得坐席人员能够调用坐席终端中预先存储的人脸图像,进行指定用户的身份核实。
当前实施例中,基于坐席终端侧提供的各种功能项,方便坐席人员进行指定用户的身份核实和及时补充审批资料,有效的提高了面签审批效率。
上述基于内网代理的视频面签方法,在内网隔离的网络环境下,基于部署的代理服务器进行视频面签指令、面签参数的转发,避免客户信息等敏感数据暴露于公网中,提升了风险管控水平。并且,用户终端还能够根据接收到面签参数,基于面签参数中的接入地址加入到先前由坐席终端创建的视频面签进程中,实现与坐席终端之间的视频面签操作,上述的操作方式使得坐席终端即便是处于内网环境中,也能够顺利地执行视频面签业务,保证了坐席人员与外网指定用户之间的实时音视频通话,提高了业务执行效率。
请参考图6,其为在内网中设置防火墙之后,结合部署在代理服务器上的TURN-穿透服务器所对应的应用环境图,结合图4可知,代理服务器中还部署有Nginx-反向代理服务和TURN-穿透服务。在一个实施例中,如图7所示,本申请提供的一种基于内网代理的视频面签方法,还包括以下步骤:
步骤S702,由代理服务器基于部署的Nginx服务,对接收到的视频面签指令和面签参数进行代理转发。
具体的,由代理服务器基于部署的Nginx服务,并通过代理服务器上部署的多个TCP端口,对视频面签操作的过程中所需传输到坐席终端的视频面签指令,以及所需传输到用户终端的面签参数进行代理转发。
在其中一个实施例中,当代理服务器与坐席终端通过多个TCP端口进行内网通信时,先由坐席终端向代理服务器中部署的各个TCP端口分别发起通信连接请求,再由坐席终端根据各个TCP端口反馈的连接请求结果,进行TCP端口连通性的验证。
当前实施例中,在基于Nginx服务进行视频面签指令和面签参数转发之前,通过预先对代理服务器中部署的各个TCP端口的连通性进行验证,避免了无效端口的利用,提高了视频面签效率。
步骤S704,由代理服务器基于部署的TURN服务,对视频面签操作的过程中所需传输到用户终端的第一视频流数据、所需传输到坐席终端的第二视频流数据,以及所需传输到坐席终端的显示屏幕画面进行代理转发。
其中,由代理服务器基于部署的TURN服务,并通过代理服务器上部署的多个UDP端口,对视频面签操作的过程中所需传输的第一视频流数据、第二视频流数据以及显示屏幕画面进行代理转发。
具体的,当通过代理服务器上部署的多个UDP端口进行视频流数据的转发时,由坐席终端分别向各个UDP端口发送报文数据,并由代理服务器对预设的各个UDP端口进行监听,且,在对各个UDP端口进行监听的过程中,基于各个UDP端口接收到报文数据,进行UDP端口连通性的验证。
在其中一个实施例中,请参考图8,对UDP端口连通性的验证具体包括以下实施过程:首先,由坐席终端创建UDP Socket Cilent-报文发送进程,基于该进程向指定的UDP端口发送UDP报文。其次,由代理服务器创建UDP Socket Server-报文监听进程,基于该进程对各个绑定到的UDP端口的活动状态进行监听。其次,在任一UDP端口接收到坐席终端传输的报文数据时,由代理服务器进行应答报文的生成,并将生成的应答报文传输到坐席终端,其中,应答报文生成之后,将由代理服务器进行UDP Socket Server进程的关闭。最后,在坐席终端接收到应答报文时,将由坐席终端进行UDP Socket Cilent进程的关闭。
当前实施例中,基于TURN服务进行视频流数据以及显示屏幕画面的转发,提高了媒体流数据的传输效率。且通过预先对代理服务器中部署的各个UDP端口的连通性进行验证,避免了无效端口的利用,提高了视频面签效率。
需要说明的是,由于坐席人员的办公网络环境一般都会设置防火墙与外网隔离开来,当内网与外网之间设有防火墙时,防火墙通常会进行严格的IP地址限制和端口限制,所以在设有防火墙的情况下,坐席终端与用户终端之间的点对点传输是无法顺利实施的。为了解决上述问题,本实施例考虑在TURN服务中部署Relay-中继子服务和STUN-会话穿透子服务,从而实现对视频流数据以及显示屏幕画面的转发。请参考图9,基于TURN服务中部署Relay子服务和STUN子服务进行视频流数据以及显示屏幕画面的转发,具体包括以下步骤:
步骤S902,基于部署的STUN子服务,根据固定的公网地址和固定的通信端口,搭建用户终端与坐席终端之间的通信通道。
需要说明的是,针对固定的公网地址和固定的通信端口,只需在防火墙上开通其白名单,就可以搭建用户终端与坐席终端之间的通信通道。
步骤S904,当基于STUN子服务完成对通信通道的搭建时,基于部署的Relay子服务,即可通过通信通道进行第一视频流数据、第二视频流数据和显示屏幕画面的中继转发。
其中,Relay子服务作为中继服务器,其允许坐席终端使用同一个中继地址与多个处于不同公网的用户终端进行通信。由代理服务器进行音视频数据的代理转发,实际指的是:基于搭建好的通信信道,由代理服务器基于部署的中继子服务对产生的音视频报文进行中继转发。示例性的,中继转发可进一步理解为:由坐席终端将产生的音视频报文先发送到中继服务器,再通过中继服务器将接收到的音视频报文转发给用户终端,反之同理。
请参考图10,其为将视频面签系统应用与生产环境和公网时所对应的网络访问规划示意图;从图10中可知,用户终端侧部署了信令服务器、消息服务器和媒体服务器,代理服务器侧部署了Nginx服务器和TURN服务器、。其中,Nginx服务器分别连接到信令服务器和消息服务器,TURN服务器连接到媒体服务器。需要说明的是,部署的Nginx服务器主要负责消息和信令的转发,部署的TURN服务器主要负责音视频流数据的转发。另外,TURN服务器针对内网和外网,还分别开放了不同的UDP端口,其中:
(1)TURN服务器针对内网开放的UDP端口包括3478端口、5349端口和59900~60000端口中的至少一种。其中,3478端口和5349端口都是用于监听会话的端口,其区别在于5349端口用于连接安全的UDP会话。59900~60000端口均为用于交换媒体数据的端口。需要说明的是,本实施例中采用UDP协议进行音视频流数据的转发,虽然能够减少延迟,保证数据的实时传输。但由于UDP协议不面向连接且该协议并不能保证通信数据的安全性,考虑到上述问题,当前实施例中,在TURN服务器中引入了DTLS协议-数据包传输层安全性协议,用以保证数据的安全加密和可靠传输。
(2)TURN服务器针对外网开放的UDP端口包括8000端口、8800端口、843端口和443端口中的至少一种。另外,本实施例中也配置了多个备用端口,进一步使得在TURN服务器运转异常时,也能够调用备用端口进行音视频流数据的实时转发。
应该理解的是,虽然图2、图7和图9的流程图中的各个步骤按照箭头的指示依次显示,但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明,这些步骤的执行并没有严格的顺序限制,这些步骤可以以其它的顺序执行。而且,图2、图7和图9中的至少一部分步骤可以包括多个步骤或者多个阶段,这些步骤或者阶段并不必然是在同一时刻执行完成,而是可以在不同的时刻执行,这些步骤或者阶段的执行顺序也不必然是依次进行,而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。
请参考图11,本申请提供的一种基于内网代理的视频面签系统1100,该系统1100包括用户终端1101、代理服务器1102和坐席终端1103,其中:
用户终端1101,用于响应于触发操作生成视频面签指令,并通过所连接的外网将视频面签指令传输到代理服务器,视频面签指令包括指令接收地址。
代理服务器1102,用于在接收到视频面签指令时,通过所处的内网将视频面签指令发送至指令接收地址所指向的坐席终端。
坐席终端1103,用于在接收到视频面签指令时,创建坐席终端与用户终端之间的视频面签进程,以及与视频面签进程相适应的面签参数;面签参数包括加入到视频面签进程的接入地址。
坐席终端1103,还用于通过所连接的内网将面签参数发送至代理服务器,以使代理服务器通过对应的外网将面签参数转发至用户终端。
用户终端1101,还用于在接收到面签参数时,基于面签参数中的接入地址加入到视频面签进程中,以实现与坐席终端之间的视频面签操作。
在其中一个实施例中,坐席终端1103还用于在视频面签操作的过程中,生成屏幕共享指令,并将屏幕共享指令通过代理服务器转发至用户终端;用户终端1101还用于在接收到屏幕共享指令时,检测响应操作,并当检测到表征同意共享的响应操作时,采集用户终端当前的显示屏幕画面,并将采集的显示屏幕画面通过代理服务器转发至坐席终端。
在其中一个实施例中,请参考图11,该视频面签系统1100还包括存储服务器1104,其中:代理服务器1103还用于录制从视频面签操作开始至视频面签操作结束的过程中对应生成的视频流数据;存储服务器1104用于从代理服务器处获取录制的视频流数据,并对获取的视频流数据进存储。
在其中一个实施例中,代理服务器1102与坐席终端1103通过多个TCP端口进行内网通信,其中:坐席终端1103还用于向代理服务器中部署的各个TCP端口分别发起通信连接请求,并根据各个TCP端口反馈的连接请求结果,进行TCP端口连通性的验证。
在其中一个实施例中,用户终端1101与坐席终端1103在进行视频面签操作的过程中,通过代理服务器1102上部署的多个UDP端口进行视频流数据的转发,其中:代理服务器1102还用于对预设的各个UDP端口进行监听;坐席终端1103还用于分别向各个UDP端口发送报文数据;代理服务器1102还用于在对各个UDP端口进行监听的过程中,基于各个UDP端口接收到报文数据,进行UDP端口连通性的验证。
在其中一个实施例中,代理服务器1102中部署有反向代理服务和穿透服务,其中:代理服务器1102基于部署的反向代理服务,对接收到的视频面签指令和面签参数进行代理转发;代理服务器1102基于部署的穿透服务,对视频面签操作的过程中所需传输到用户终端的第一视频流数据、所需传输到坐席终端的第二视频流数据,以及所需传输到坐席终端的显示屏幕画面进行代理转发。
在其中一个实施例中,穿透服务中还部署有中继子服务和会话穿透子服务,其中:当内网与外网之间设有防火墙时,基于部署的会话穿透子服务,根据固定的公网地址和固定的通信端口,搭建用户终端与坐席终端之间的通信通道;在基于会话穿透子服务完成对通信通道的搭建之后,基于部署的中继子服务,通过通信通道进行第一视频流数据、第二视频流数据和显示屏幕画面的中继转发。
关于基于内网代理的视频面签系统的具体限定可以参见下文中对于基于内网代理的视频面签方法的限定,在此不再赘述。上述基于内网代理的视频面签系统中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中,也可以以软件形式存储于计算机设备中的存储器中,以便于处理器调用执行以上各个模块对应的操作。
上述基于内网代理的视频面签系统,在内网隔离的网络环境下,基于部署的代理服务器进行视频面签指令、面签参数的转发,避免客户信息等敏感数据暴露于公网中,提升了风险管控水平。并且,用户终端还能够根据接收到面签参数,基于面签参数中的接入地址加入到先前由坐席终端创建的视频面签进程中,实现与坐席终端之间的视频面签操作,上述的操作方式使得坐席终端即便是处于内网环境中,也能够顺利地执行视频面签业务,保证了坐席人员与外网指定用户之间的实时音视频通话,提高了业务执行效率。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,的计算机程序可存储于一非易失性计算机可读取存储介质中,该计算机程序在执行时,可包括如上述各方法的实施例的流程。其中,本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用,均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-OnlyMemory,ROM)、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器(Random Access Memory,RAM)或外部高速缓冲存储器。作为说明而非局限,RAM可以是多种形式,比如静态随机存取存储器(Static Random Access Memory,SRAM)或动态随机存取存储器(Dynamic Random Access Memory,DRAM)等。
以上实施例的各技术特征可以进行任意的组合,为使描述简洁,未对上述实施例中的各个技术特征所有可能的组合都进行描述,然而,只要这些技术特征的组合不存在矛盾,都应当认为是本说明书记载的范围。
以上实施例仅表达了本申请的几种实施方式,其描述较为具体和详细,但并不能因此而理解为对发明专利范围的限制。应当指出的是,对于本领域的普通技术人员来说,在不脱离本申请构思的前提下,还可以做出若干变形和改进,这些都属于本申请的保护范围。因此,本申请专利的保护范围应以所附权利要求为准。