场景描述
概述
虚拟营业厅适应金融服务线上化、智能化的未来发展趋势，将实时音视频技术与 AI 等技术进行高度融合应用， 实现金融机构线下网点业务的线上化，为客户提供 7x24 小时非接触式金融服务。
虚拟营业厅可全面覆盖金融机构客户信息维护、对公开户、理财双录、视频面签等丰富的业务类型，实时在线业务办理，包括人脸识别、身份验证、视频见证、保密问题、交易触发等环节，提升用户体验的同时降低运营成本。
优缺点 | 传统营业厅的缺点 | 虚拟营业厅优点 |
营业半径 | 传统银行的营业厅服务半径有限，只能覆盖较少的人群，不同营业厅忙闲不均。 | 统一入口，流量分发。 |
客户体验 | 客户需要到营业厅现场进行业务办理，客户经理也需要拜访客户，费时费力。 | 线上解决，足不出户。 |
运营成本 | 营业厅建设、运营需要消耗大量空间、人力、物力等各方面成本。 | 仅需要服务器和开发人员。 |
实现方案
虚拟营业厅业务流程图：
虚拟营业厅功能模块：
这里需要注意的是，客服端通常使用桌面软件或者 Web 浏览器，原因是桌面端具有更丰富的服务功能，而且还可以满足内网隔离、高清摄像头、客服行为监控等涉及底层设备的需求。用户端则使用 iOS 和 Android（移动端），是考虑到目前大量中老年用户群体并不会使用电脑，而且台式电脑还需要安装摄像头、麦克风才可以正常互动。在终端的选型中没有选择使用小程序，是因为在虚拟营业厅的场景中有录屏推流的需求，小程序目前不支持录屏推流，所以在选型时应避开。
会话管理
在虚拟营业厅中，每个实时音视频房间实际是一个会话，通常情况下，一个会话只有一个客服和一个用户，当房间满足该条件时，房间入口将关闭，无法加入新的用户和客服，其次对于业务的实际情况而言，不允许一个客服同时接待两个用户，也不允许一个用户同时处理两个业务，这需要在业务层做出限制。
1. 会话状态管理
TRTC 的房间本身没有做进房的限制，
privateMapKey参数是对全局的房间进入做出限制并不适合目前的场景。主流的做法还是通过自建的业务层在进入房间前进行判断，则需要进行会话的状态管理。用户本身对于 TRTC 房间无感知，进入房间的行为也无感知，在应用中发起相关服务时，由系统根据当坐席和会话情况自动分配进对应的会话，这样降低了用户入口的深度，让操作更为简便，也不用关心多个用户或多个客服进入到同一个房间的情况。
2. 坐席转接
考虑到用户并不一定清楚自己需要办理什么业务，或者仅仅只是提问。常见的客服系统都会分为一线、二线等，越深层级的客服针对性越强，反之通用性越强。相当于是一线的客服帮助用户答疑咨询然后转接给对应负责的客服，这就需要坐席转接机制。
通常来讲，一线的客服如果仅仅只是咨询和答疑，不需要与用户进行业务上的操作，诸如合同签订等。那么可以接入 AI，人工接入 IM 即可，如果需要和用户对话，可以接入 TRTC 的语音房。
当用户需要去到另一个会话时，可直接通过
enterRoom去到另一个 TRTC 房间，房间号分配由系统去实现，进入新的会话成功后再退出旧的会话。为了避免多个用户被系统同时被分配到一个房间，这里需要做业务锁，当一个会话需要转接时，当前会话以及目标会话都应被锁住，被锁住的会话不会被纳入分配的对象，直到用户进入新的会话并成功退出原有会话时（收到
enteRoom，exitRoom回调），该锁才解除。如果恰好两个用户被系统都转接同一个坐席，后来的转接请求将会转接失败并发起重试寻找新的坐席。队列管理
排队问题是所有营业厅都会遇到的，如果把一个客服对应的会话房间当作一个柜台，那么一次就只能处理一个用户的业务（咨询类客服不算此类），需要合理的分配每个柜台的人员流量，这里提供几种常用的策略。
1. 通用策略
在比较大的网上营业厅，可以选择进入哪个营业厅，在一般情况下默认应该为自动分配模式，该模式下坐席只为所属营业厅的用户提供服务，可以实现坐席与用户之间的快速、精准配对。
如果出现该营业厅全局的高峰期，需要其他的营业厅进行支持，则可以定义一个全局分配模式 ，该全局模式下，会优先服务所属营业厅的用户，在一定条件下也可以为其他营业厅的用户提供服务。
此外，队列、坐席、用户都具备优先级属性，系统会给优先级高的队列（例如 VIP 客户的队列）优先分配坐席，给优先级高的坐席优先匹配用户，给优先级高的用户优先匹配坐席。
2. 权重策略
场景1：用户溢出
针对用户数量溢出的队列需要调度，一般用户可以接受排队，但时间有限，因此需要尽可能平衡每个队列的等待人数。
同类溢出策略：办同一个业务，溢出到同级或更高级别的队列组。当队列的代办人数量过多时，可查询其他营业厅或其他同类型队列是否有空闲队列，予以调配。
定向溢出策略：当队列的代办人数量过多时，可指定将某队列的等待人移动到另一个队列。
场景2：新老用户
数据库中应记录用户的办理次数以及先前服务的坐席，来判断其是否为老用户，对老用户可以斟酌提供一点权重，并且为他优先分配曾经服务过的坐席。
场景3：用户数较少
在用户溢出的情况，基本上是服务完一个就紧接着下一个。反之，用户少这种情况，则需要根据客服今日的服务情况进行调整，避免出现一个客服服务了大量用户，但其他客服较少的情况。一般而言，根据一天的接单时长排优先级，接单时长最短的优先；根据一天的接单次数来排，接单次数最少的优先。
3. 用户调度策略
场景1：插队策略
程序设计的再严密也会出现某用户等待时间过长的情况，面对这样的用户，系统需要主动将其排队位置往前调整避免等待时间过长导致用户流失。当有多个超时用户时，可根据等待时长、用户等级、是否为重点用户等维度为其添加权重。
场景2：空闲时间转接策略
坐席的优先级等其他条件相同的情况下，会将用户优先分配给上次占线时间最长的坐席接听。
场景3：先到先服务策略
相同优先级的队列，用户优先级相同时，等待时间最长的用户优先服务。
文件管理
在虚拟营业厅的场景中，有大量的文件需要交互。例如：各式合同原件、带有用户签名的合同、全程录制文件、BGM、语音文件。
1. 安全性
1.1 文件保护和加密
首先对于合同原件、用户签名、录制文件本身都需要进行加密，这里的加密一般有以下几种加密。
URL 地址本身需要加密，可以通过某些特定的哈希算法，将 URL 转换为特定的字符串，只有知道解密方式的人才可以将无规则字符串转为文件地址，数据库中存储的也是无规则字符串。
通过地址访问文件本身需要权限管理，以腾讯云的访问管理为例，默认的 COS 云存储桶为私有读写，即便拿到了 URL 的真实地址如果没有使用对应的账号下的 API 密钥去请求，也是会被拒绝访问的。同时操作本身也应该分开权限，读权限可以开放给需要的人，但对于一些高危操作（如删除数据）的权限，也可独立出来进行授权，仅允许用户在控制台进行操作，同时通过 开启 MFA 校验来进行二次认证。开启 MFA 校验后，用户在执行此类高危操作时会触发短信校验码进行校验。
对于一些核心敏感数据，如金融交易数据、医疗影像数据等，可通过 对象锁定 功能来防止文件在上传之后被删除或者篡改。配置对象锁定功能后，在配置的有效期内，存储桶内的所有数据将处于只读状态，不可覆盖写或者删除；此项操作对包括主账号在内所有 CAM 用户及匿名用户生效。
如果希望子账号对某些桶也禁止访问，例如一些非常机密的文件，存在某一个桶里，只允许超级管理员进行读，其他人均不可读，那么可以单独对这个桶进行加密。加密后的桶，即便是拥有了对应的 API 密钥，也必须有对应的桶密钥并在 请求的 header 中加入，才可以访问该桶。
视频加密，为了保障视频内容安全，防止视频被非法下载和传播，可以使用 COS 的 HLS 视频加密 功能，拥有相比于私有读文件更高的安全级别。加密后的视频，无法分发给无访问权限的用户观看。即使视频被下载到本地，视频本身也是被加密的，无法恶意二次分发，从而保障您的视频版权不受非法侵犯。
1.2 备份容灾
版本控制：保障用户的文件不会被覆盖写或者删除，所有同名文件的写操作都会视同新增不同版本的同名文件，删除操作等同于新增一项删除标记；可通过指定版本号访问过去任意版本的数据，可实现数据的回滚操作，解决数据误删和覆盖的风险。
数据备份：可将所有增量文件通过专线复制到其他城市的数据中心，实现异地容灾的作用。当主存储桶中的数据被删除时，可从备份存储桶中通过批量拷贝的方式恢复数据。
多云灾备：对于一些数据主要存储在其他云厂商，且对数据持久性要求苛刻的情况，COS 也提供基于云函数的多云灾备方案，数据存储在其他云厂商上，可通过云函数触发数据同步或者存储桶复制实现异地容灾，保障数据持久性。
1.3 监控回溯
事中监控：对于高危操作，无论是谁在每一次发起操作时，都应该回调给指定人（2位以上），确保可以及时发现高危行为，并采取手段中止。
操作回溯：删除文件、覆盖写文件、修改文件权限等操作，需要进行监控写入日志，删除操作等高危行为可追溯可查证。
2. 可用性
考虑到有的情况下用户侧的网络状态不佳，当在直接传一整个文件时，如果中间传输超时失败会重新传输。这里可以使用弱网分片传输，将一整个文件分为多个大小相同的分块。如果中间时网络断开了，后续再次下载或上传时可以继续上一次的部分，可以参考 COS 的 断点续传 功能。
录制管理
1. 风险揭示
在虚拟营业厅的场景中，有非常多需要播放提前录制好视频的情况，例如语音播报环节、风险揭示环节。将不同的产品绑定预先录制好的风险揭示内容，根据用户选购的产品类型同步下载相应风险揭示文件并进行播报，风险揭示过程同步录制。播放相关视频、语音的操作可以参考 关键业务逻辑 - BGM 和语音播放。
该操作的目的是为了证明用户观看过风险相关的条款并进行留底，避免后续用户在这方面进行追究。一般来说有以下几种文件可用来展示风险：
语音风险播报
视频风险播报
PPT 展示
白板风险展示
2. 全景录制
为便于留底和事后回溯，虚拟营业厅的录制包含的内容比较多。除了客服和用户的单独的两路需要录制，其合成的混流也需要录制，用户的手写的签名笔迹也需要单独录制，确保有效性防止抵赖。
其次录制的视频需要保证高清、且人脸完整，方便后续对视频内人物进行人脸识别、活体检测等。
此外，对于手写签名，对于常用的方案是使用类似 canvas 的模块，那么对于这种方式的签名，有两种方案：
作为录屏中的一部分保存下来，并对该段时间的录像留底或者打上时间戳。
自己处理业务逻辑，将笔迹作为 GIF 保存，同时整个 canvas 画图最后会生成图片数据 dataUrl 的形式上传服务器。
3. 录像加工
对于营业厅的录像有几种主流的加工方式，可以降低运营方的复盘压力和提高安全性。
水印与时间戳：录像过程中实时叠加文字/图片和时间戳等水印信息，通过标准化的水印服务确保录像文件合法、有效，防止用户抵赖，有效保障录像文件完整有效、非技术合成。
AI 标记：用 AI 和自动化程序对用户的每一轮的问答、提问以及签名环节、查看风险揭示等重要环节自动打上时间节点，方便后续复盘跳转直接查看某一个部分。同时也方便质检人员，智能识别坐席语音片段和用户语音片段，针对每次问答进行打标定位并标记风险问题点，协助质检人员快速、精准定位问题，提升质检效率。
4. 本地录制
部分用户有本地录制的需求，在服务开始前可通过提示音提示用户打开手机的录屏功能。
Android 端
若需要在 App 内增加录屏的按钮，在 Android 5.0 之前，我们是无法通过常规的方式来录制屏幕或者截图的，不过在 Android 5.0 后，Android 开放了
MediaProjectionManage、VirtualDisplay等 API，使得普通应用录屏成为了可能。iOS端：
iOS 9：Apple 在 iOS 9 推出了 ReplayKit 框架，提供了录屏功能，限制是只能录制本 App 内的屏幕。录制完成后会生成一个视频文件，只能通过
RPPreviewViewController来预览，编译生成的文件。iOS 10：iOS 10 Apple 推出了 Broadcast Upload Extention 和 Broadcast Setup UI Extention，来解决录屏的问题。
iOS 11：iOS 11 的发布正式直播兴盛的年代，为了迎合市场需求，Apple 提供了跨 App 录屏的功能，可以实现录取整个屏幕的功能。 虽然 ReplayKit2 已经可以满足开发者的多数需求，但是对于用户来说，这个版本在实现屏幕直播时，需要用户提前在手机设置中配置出屏幕录制的访问控制权限，使屏幕录制按钮显示在系统的上拉管理菜单中，并且在录制时，上拉底部菜单调出快捷管理菜单，并且长按屏幕录制圆形按钮才能开始录制和直播。复杂的操作流程，让用户使用的门槛增高。所以在 iOS 11 上屏幕共享功能也显得很单薄。
iOS12：iOS 12 在 iOS11 的基础上进行了优化，并提供了
RPSystemBroadcastPickerView，解决了录制屏幕，用户无需在控制中心手动启动。流管理
虚拟营业厅推流拉流的逻辑并不复杂，主要在业务的流处理上。
1. 推拉流
对于用户而言，语音需要全程推送，视频需要推送摄像头流或录屏流，取决于业务进行到哪一个环节，当业务进行到需要远程协助或指导操作的环节时，需要将摄像头推流切换为录屏推流，具体实现细节参考 关键业务逻辑 - 屏幕分享和视频切换。
2. AI 分析
这里列举几种营业厅场景中，常见的利用 AI 对视频流进行分析处理的方案，具体选择什么请读者根据自己的业务需求进行选择。以下功能均可以通过使用腾讯云 AI SDK 进行实现，参考 腾讯云人工智能 AI 矩阵。
2.1 人体检测
静默活体检测：对摄像头视频流做不定时的截图拍照，进行相关检测，通过摄像头拍摄的照片进行检测，判断是否是真实的⼈脸或攻击性的假脸（⼈脸翻拍的图⽚、⼈脸翻拍的屏幕、打印的人脸照片等）。应用于人脸识别过程中对于欺诈行为的拦截。
动态活体检测：需要获取摄像头和视频流，通过眨眼、张嘴、左右摇头、上下点头等动作指令，配合完成动作，随机抓取多图来判断是否活体，支持业务侧自定义检测动作顺序。
人脸识别：检测是否为正确的投保人、甲方代表等。
2.2 位置检测
实时离框警告：实时获取视频流检测人脸是否在框，检测在框画面是否符合预期情况，对违规行为进行风险提示，规范用户业务办理行为。
多人在框检测：结合人脸检测，人脸比对等能力，通过业务场景匹配算法对多个人脸同时进行人脸检测及人脸比对，提高了检测的效率，减少业务流程复杂度。
2.3 行为检测
签字动作识别：对视频和图像中的人物进行签字动作的识别，确认是否有签字，并返回签字的时间及签字的坐标定位。
文档出示识别：支持对视频和图像中的人体进行文档出示识别检测，返回是否有出示文档的动作及出示动作是否合规。
穿衣识别：支持对人体穿衣进行识别，自动识别脖子以下是否有人体皮肤存在，达到一定面积时，即通过动态捕捉、目标跟随等功能对视频录制过程中的人体皮肤进行马赛克处理。
2.4 语音检测
敏感词检测：实时质检内容内是否有敏感词，回答是否合规，并给出提醒。
用户意愿检测：实时识别用户语音回答的内容，通过AI能力将采集到的数据进行实时转换，确认用户意愿。
3. 质量监控
对于服务行业来说，通话质量是保证服务体验的重要一环，通话中需要实时监控双方的网络状态，当检测到系统数据异常，实时告警，应及时反馈，帮助运营与支持人员实现及时发现问题、解决问题的闭环管理。
TRTC 实时音视频 还提供了仪表盘作为增值服务，仪表盘可对全局资源统一监控管理，项目状态、用户行为、故障情况一目了然。通过类型丰富的仪表盘展示音视频质量状态，多维度统计分析，清晰直观。仪表盘中每一个数据点都可支持多维度下钻。以房间为维度显示丢包、接入总量和异常占比等多种数据明细，且可支持数据下钻；以单个用户为维度显示用户通话的卡顿、丢包、延时等多种明细数据。多维度分析用户业务行为，聚焦用户体验分析。
关键业务逻辑
本章节将会对核心功能层的业务逻辑进行讲解，提供流程图、调用时序图以及相关 API 的关键参数。
对于虚拟营业厅场景，座席端一般使用 Web 桌面浏览器端，用户端一般为 Android/iOS 端，用户端一般需要到屏幕分享，音视频通话，语音和 BGM 播放等功能。
屏幕分享和视频切换
用户一般需要将摄像头流和视频流都推送，移动端只能推送主路流，所以只能在需要的时候将主路的视频流更换进行切换。
实现流程
注意：
1. 移动端只能推送主路流，因此在切换前务必保证摄像头关闭且不再推流。
2. 从 Android 7.0 系统开始，对于没有做过任何保活措施的后台应用，Android 系统会很快将其杀掉以减少系统能耗。 但当您的 App 处于屏幕分享状态时，不可避免地要被切到系统后台运行，此时如果能弹出悬浮窗可以避免被系统强杀掉。 同时，在手机屏幕上显示悬浮窗，也有利于告知用户当前正在做屏幕分享，以便提醒用户避免泄露个人隐私。
3. 由于移动端的录屏推流目前无法只监控某个应用内画面，会监控到键盘输入，也会不可控的会切换到其他应用或看到手机内弹出的通知，请在录屏推流前告知用户，不要进行敏感信息的操作，也建议开启手机勿扰模式以免看到不应该看到的信息。
时序图
BGM 和语音播放
在业务办理过程中，用户端会有一些语音提示指引和条款语音播放。使用第三方播放器播放的话，如果用户带耳机，则座席端听不到用户端播放的语音；如果是外放，座席端可能能听到但很小声；如果声音是从听筒出来的，则座席端是听不到的。建议用 TRTC 自带的 BGM 播放接口来播放，这样双方都能非常清晰地听到用户端播放的提示音。接口支持本地音频文件和 URL 链接的音频文件。对于操作提示音，不需要对方听到的，可以用第三方播放器播放即可。
实现流程
简短的、重复性很高的提示音，可以提前下载到本地，这样播放的时候可以节省一些网络请求。较长的、重复性低的，可以使用 URL 的方式传参。
注意：
如果要多次播放同一首背景音乐，不要每次播放都分配一个新的 ID，推荐使用相同的 ID。
若希望同时播放多首不同的音乐，为不同的音乐分配不同的 ID 进行播放。
如果使用同一个 ID 播放不同音乐，SDK 会先停止播放旧的音乐，再播放新的音乐。
时序图
startPlayMusic播放背景音乐，可以指定 BGMid 跟对应的 URL 音频文件绑定。后续对该 BGM 暂停、停止，音量调整操作可以通过该 ID 进行操作。坐席端内网代理和穿透
金融保险行业，对于网络安全要求比较高，内网和外网有防火墙隔离。用户端在外网、坐席端在内网、TRTC 服务端在厂商云端，三方要能视频通话，则需要打通座席端内网到 TRTC 服务端的链路。
方案1：给每个座席端电脑都加入 TRTC 服务端白名单，允许座席端连接 TRTC 后台。这种方式，当座席人员变动、电脑环境改变等，则需要给新的电脑和人员配置防火墙规则。
方案2：部署 TRTC 内网代理服务器，座席端都通过代理服务器与 TRTC 后台连接。这种方式，不需要改变座席端的网络环境，只需要给代理服务器设置白名单规则即可。
通常会使用方案2，特别是内网防护墙有多层的、有硬件防火墙和软件防火墙的，如果单个坐席端遇到问题排查会变得很复杂。使用方案2可以大大提高业务可维护性，遇到问题也可以缩小问题排查范围。
实现流程
WebRTC 的服务端通常由 STUN 和 TURN 构成，STUN 通俗来讲是用来打洞的，当双方需要 P2P 直连时用到，TRTC 的音视频直接通过后台中转，这里不需要搭建 STUN 服务。
TURN 在 WebRTC 通信里面的作用是，当 STUN 打洞失败，则通过 TURN 服务与对方建立连接，音视频媒体数据通过 TURN 来转发。TURN 服务可以使用开源工具 TURNServer 来搭建。
除了 WebRTC 本身的协议需要代理，TRTC 的信令通道也需要代理。TRTC Web 端的信令通道使用 Websocket 协议，Websocket 代理直接用 Nginx 搭建即可。
代理服务器防火墙配置规则：
规则 | 端口 | 说明 |
入方向 | TCP：443 UDP：3478、5349、59900-60000 | TCP 端口：座席端连接 Nginx 配置的 Websocket 服务。 UDP 端口：座席端连接 Turnserver，Turnserver 默认侦听的是3478端口。 |
出方向 | TCP：8687 UDP：8000、8800、843、443、8080、16285 | TCP 端口：代理服务器 Nginx 的 Websocket 服务连接腾讯云服务器。 UDP 端口：代理服务器 Turnserver 连接腾讯云服务器。 |
注意：
入方向的 IP 地址，可以限定坐席端的那几台电脑，也可以不限定。建议不限定，如果人员电脑变动则需要更新。
出方向的 IP 地址，建议使用 AnyIP，因为腾讯云 TRTC 后台的节点很多，而且会动态调整节点数量，所以 IP 地址没办法提供固定的列表。
时序图
如果有多台代理服务器，则可以在自己的业务后台维护一个服务负载情况的列表。Web 端在 setProxyServer 之前，向自己的业务后台获取负载较低的代理服务器地址。如果开发周期紧急，也可以把服务器列表给 Web 端，Web 端按随机/轮询的方式选择代理服务器列表。
注意：
自 v4.8.5 开始，支持设置多个 Turnserver 地址，如果企业内部坐席端人员比较多，一台代理服务器不够用，则可以部署多台。
setTurnServer接口接口传入数组参数即可。方案配套产品
系统层级 | 产品名称 | 场景用途 |
接入层 | 提供低延时、高品质的多人音视频实时互动直播解决方案。在此场景下，用户之间可以低延时地视频互动。 | |
接入层 | 提供基于群组功能的房间管理、消息的收发，以及自定义信令等通信需要。在此场景下，可以用 IM 的文本消息聊天，用自定义消息封装教室状态、控制状态。 | |
云端服务 | 提供人脸检测与分析、比对、搜索、验证、五官定位、活体检测等多种功能，为开发者和企业提供高性能高可用的人脸识别服务。在此场景下，可用于敏感业务的人脸识别、身法验证。 | |
云端服务 | 提供实时音视频的旁路转推，以及加速媒体流的分发服务，此外还具备录制、鉴黄等附加能力。在此场景下，可以做后台监控、视频录制、旁路拉流做 AI 表情专注度分析等功能。 | |
云端服务 | 面向音视频、图片等媒体，提供制作上传、存储、转码、媒体处理、媒体 AI、加速分发播放、版权保护等一体化的高品质媒体服务。在此场景下，可以做视频录制文件的二次转码和加工。 | |
数据存储 | 提供音视频录制文件、音视频切片文件的存储服务。在此场景下，可以把录制文件转移到 COS 作为长期存储。 |