来源：第五届农村中小金融机构科技创新优秀案例评选
一、项目背景及目标
背景一：
目前我社部分高频非现金业务不支持线上渠道自助办理。其中，短信通、手机银行管理等柜面业务年交易笔数合计达万笔，占柜面非现金交易的近20%。应采取更严格的风险防控手段，实现这部分业务的线上自助办理，以节省柜面资源、降低客户排队等待时长。
背景二：
我社社会保障卡发卡量已超过万张，长期不在省内的客户占一定比例。但我社为地方性金融机构，在省外无营业网点，要满足更多省外客户的金融业务需求，必须丰富线上渠道的服务范围。
背景三：
年2月中国人民银行发布《关于进一步强化金融机构防控新型冠状病毒感染肺炎疫情的通知》，强调“金融机构要加强全国范围特别是疫情严重地区的线上服务，引导企业和居民通过互联网、手机APP等线上方式办理金融业务”。
背景四：
人脸识别、电子签名等技术的成熟应用，以及风险预警模型与交易实时阻断系统的不断完善，使得银行金融风险识别与处置的准确性进一步提高。
本项目拟通过客户线上申请、人工后台通过视频审核的方式，使部分当前仅能在柜面办理的非现金业务，实现电子渠道自助办理。并通过事前、事后多流程监督，降低业务风险。
项目基本要求如下：
（1）支持手机银行客户端业务申请：客户在手机银行客户端选择需要办理的业务，输入身份信息和相关业务要素。
（2）事前监督：连接人行联网核查系统，对客户进行人脸识别。连接运营商系统，将本地的证件和手机号，与运营商系统留存的证件和手机号进行比对。
（3）支持客户端和行内坐席视频通话：通过视频通话连接客户和后台人工坐席，坐席进行风险提示、判断业务办理是否客户本人意愿，确认后业务办理成功。
（4）支持对审核流程的图片和影像内容进行存储和查询。
（5）后台管理系统：支持交易记录按条件查询、交易统计报表、坐席管理等。
（6）事后监督：每日将客户空中柜台办理业务的记录传输至现有的电子银行风险系统（含风险预警和交易阻断系统）。风险系统对通过本系统办理业务的客户进行更严格的监督，对符合交易阻断条件的客户，进行交易阻断。
空中柜台系统以文字、语音、视频等方式，与客户实现远程“面对面”交流，运用远程视频、生物特征识别、OCR等金融科技技术，结合各种风控策略，创新探索出远程银行运营的新模式，加速了海南农信数字化、智能化和创新性的转型发展。该系统紧扣疫情常态化新形势下加强线上服务的宗旨，契合让数据多跑路让客户少跑腿的服务要求，在疫情防控的新形势下，减少了客户到网点的频度，提高了我社服务效率，降低了临柜业务人工服务成本。
二、项目方案
2.1系统逻辑架构
系统分为应用表现层、接入层、业务应用层、平台层、服务层和数据层。
应用表现层
应用表现层包括app应用，座席端应用以及后台管理应用，展现给用户的界面，即用户在使用一个系统的时候他的所见所得。
接入层
接入层则包括Android、ios、H5、PC、作为表现层的载体，并连接业务应用层应用。
业务应用层
本层包含多种业务应用，提供业务应用的配置，提供最上层的服务功能，依赖平台层提供接口和功能支持。
平台层
本层将按照插件方式调用多个业务应用，提供应用的控制管理，提供身份认证、系统配置、系统状态和自动升级等功能。
服务层
服务层包括后台数据服务、系统后台管理平台，主要为平台层提供数据服务，系统管理。
数据层
数据层包括平台的数据、应用的数据和各种业务应用模块，提供数据的管理和业务应用程序集的管理。
架构模式
整个系统可能包括多个业务模块，系统对每个业务模块进行管理，统一系统数据库。
设计机制
1.数据管理，通过后台管理和维护相关数据。
2.异常分析，通过日志查看。
2.2系统物理架构
本系统物理架构H5段和APP有所不同。
H5实时双向视频物理架构如下：
信令服务
接收HTML5端的信令请求，经由WebRTC代理服务，到达纯TChat的中心服务器。信令服务还负责WebRTC代理服务的负载均衡。
Turn服务
接收HTML5端的媒体数据，经由WebRTC代理服务，到达纯TChat的媒体服务器。当WebRTC代理服务部署在公网时，也可以跳过Turn服务，由HTML5端直连WebRTC代理服务。
WebRTC代理
连接HTML5与纯TChat，它是HTML5与纯TChat互联互通的桥梁。
APP实时双向视频物理架构如下：
系统核心部分主要由中心服务器、媒体转发服务器、录像服务器、业务服务器组成。
中心服务器
负责房间管理，并将房间信息同步至媒体转发服务器。同时，还负责与业务层服务器进行交互，将用户相关请求传递给业务服务器进行处理，并将处理结果反馈给对应的终端用户，起中间桥梁作用。
媒体转发服务器
负责为终端用户转发流媒体数据。
录像服务器
录像服务器支持两种录像方式：
1、合成流录制，录像来源为客户端的合成流。
2、服务端录制，录像来源为媒体转发服务器的媒体流。
业务服务器
负责业务流程的管理，包括终端用户身份鉴权认证以及业务流的控制等，起到与第三方系统互联互通的桥梁作用。
单向视频是指不需要连接视频服务器和座席参与，用户自主录制视频，并上传至双录系统，以备双录质检。
单向视频APP基于系统原生的视频录制API实现，视频文件支持本地预览、存储及上传管理。
双向视频是指客户与座席人员通过视频流媒体服务器建立实时视频通话，由座席人员发起视频录制，保存并上传视频文件至双录系统，以备双录质检。
实时双向视频支持一对一、一对多、多对多的视频通话模式。支持客户端录制、合成流录制、服务器端录制三种模式，另外支持视频集群和负载均衡。
采用ffmpeg和CxImage开源库。ffmpeg用于音视频的合成录制；CxImage针对采集到的视频帧，添加水印和时间戳的图像处理。从而保证了视频文件的时效性和指定唯一用途。
采用线程池技术实现视频文件批量上传，文件上传失败支持自动重传，以及断点续传，并支持全局限速处理，可设置任务计划。
排队系统基于redis数据缓存实现，据官方数据SET操作每秒可达次，GET操作每秒可达次。redis缓存服务器高性能的数据读写和数据共享，从而排队系统性能强大，支持高并发视频请求，同时方便系统水平扩展。
视频前提示
视频前程序自动检测网络类型，当处于弱网环境时（2G、3G），提示用户当前的网络可能不稳定。
视频中调整
视频中使用多种策略去保证视频通信质量。
前向纠错编码
前向纠错编码的实现原理是：m个数据包在发送端经过冗余编码后生成n个数据包，将n个数据包发给接收端；接收端收到至少任意k个数据包就可以通过译码使原始数据还原。n-k为冗余校验信息的数量。前向纠错编码在网络波动较小时，抗丢包能力比较强。
抖动缓冲区
抖动缓冲区的实现原理是：在收到网络上的RTP报文后，不直接进行解码，待缓存一定个数的RTP报文后，按照时间戳或者包序号进行重排，消除报文的乱序和抖动问题。抖动缓冲区利用延迟来换取视频的流畅播放，相比视频的卡顿来说，稍大一点的延迟但流畅的效果，其主观体验更好。
关键帧请求
关键帧简称IDR帧。对视频来说，IDR帧的解码无需参考之前的帧，因此，在丢包严重时可以通过发送关键帧请求进行画面的恢复。
动态码率控制
动态码率控制的实现原理是：根据接收端的丢包率或延时情况维护一个状态机。以根据丢包率为例，在判断为超过阈值时，根据系数减少当前发送端的码率值，当判断为在阈值内时又根据系数来增加发送端的码率值；然后将这个值通过rtcp包发送给发送端，发送端根据该值来动态的调整码率。
动态帧率控制
视频发送端根据对端发送的接收端的丢包率或延时情况调整出一组比较合适的码率值，当网络条件好的时候，码率值会比较大，当网络条件比较差的时候，码率值会比较低。但是若是发送端仅调整码率，不调整帧率，当网络条件比较好的时候，仅仅提升了视频质量，没有充分利用网络条件，提升实时性。当网络条件比较差的时候，码率降的比较低，若不降低帧率，视频质量会大幅度下降。所以需要增加一种机制，根据发送端的码率值，动态调整发送端的帧率值。
2.3系统应用架构
空中柜台平台建设以服务器集群为支撑，采用分布式架构、模块化建设思想，具备良好的稳定性、高可靠性、兼容性、可扩展性和先进性。软件的设计和开发基于先进的技术规范，采用多层次、松耦合、构件化的软件设计思想，保证系统的可扩展性和灵活性。空中柜台平台支持iOS/Android/PCWeb/手机H5/