本文来自峰畅科技联合创始人&CTO 段先德在LiveVideoStack2021上海站的演讲内容，以峰畅科技采用OWT开源媒体服务器在金融行业的应用为实际案例，详细解析如何用平台化方法破解场景碎片化、定制化的难题，达到图形化编辑工作流的方式支持业务流程创新的目的。

文 / 段先德

整理 / LiveVideoStack

大家好，非常感谢LiveVideoStack的邀请。很高兴能在国内音视频领域的顶级技术社区分享我们在实时音视频通信领域的产品化所做的事情。我是来自峰畅科技的段先德。本次分享的主题是OWT在企业远程智能视频服务场景中的应用。标题的关键词是OWT和企业远程智能视频服务。OWT是英特尔主导的开源项目，全称是Open WebRTC Toolkit，它提供一套基于WebRTC通信平台和端上SDK，相当于工具集。开发者或企业可以基于此平台/工具集开发自己的垂直领域应用。企业远程智能视频服务是公司产品应用领域，本人有幸在2014年至2019年期间深度参与OWT项目架构、后端媒体服务器的框架设计、核心部件Coding。现如今，峰畅科技将OWT应用在目标客户的B2C实时交互场景中。

我将通过以下四个部分作分享：企业远程视频服务场景的RTC需求；OWT的设计原则与分寸；Zealcomm面对远程服务场景在OWT基础上的解决方案；OWT其他业务场景落地的关注方面。

01

—

企业远程视频服务场景的RTC需求

首先是企业远程服务对RTC的场景需求。企业与客户之间有线下面对面与远程服务，之前在没有实时交互场景下，通过数据交互ABP或其他H5浏览方式做常规交互，一些实时交互需求场景通过热线电话提供语音远程服务或通过外拨电话推销、调查、回访服务，也就是从B端触及到C端。

1.1 全渠道视频接入

随着技术平台演进和企业服务IT化需求和要求升级，传统电话实时交互服务渠道不够，且服务不够亲和，在金融行业中不满足存证/监管需要。金融行业是目前远程视频服务主要客户群体。现如今企业提供客户远程视频服务一般都会要求接入的渠道全渠道可触达，例如通过网页H5方式通过原生APP入口与企业服务端做交互。现如今微信是全民性渠道，所以企业上远程视频服务需要覆盖微信渠道，另外还要兼容传统PSTN电话、SIP硬终端与后端呼叫中心提供的远程视频服务。随着2020年5G铺开，有些客户用5G中视频VolTLE通道作为要求，比方说以前用电话打110报警，描述半天事件与位置不清楚导致公共服务提供不及时，现如今有相当的覆盖面可支持5G VolTLE后，企业或政务端视频能使受理端将语音呼叫变成视频呼叫，以直接用手机摄像头作警情报告。这是视频服务新动向。今年在种子客户中，已有商用上线。

远程视频服务全渠道接入需求，选择视频平台要求大概率要支持WebRTC方式、支持传统实时通信的系统。微信通道方面，做WebRTC平台，它从2020年IOS14.3推送后全平台微信环境内置浏览器可以打开WebRTC双向实时音视频通信。我们有客户在这一方面做了PUC验证。

1.2 服务智能化

企业另一个视频服务要求是服务智能化。视频服务与以前的电话服务不同，电话后话务员穿得懒散与否、工作场地、仪容仪表无要求；而视频后，对业务代表有非常高的要求。如果客户不满意外表，将影响企业提供的评价。视频服务交互流程例如银行、保险公司、运营商、政府部门柜面业务会有人作为企业或机构业务代表进行交互，实际上感兴趣的不是这个人，真正感兴趣的是服务流程。交互本质是在于企业或机构背后业务流程与数据。看到这层后，机器人提供人类信息可承载方式——音视频交互，是最接近企业原始服务质量与服务描述。

实际客户要求不会那么深，只会想人工业务代表需要成本做培训；培训质量效果参差不齐，需要降低人力成本，提高投入效果，视频服务传达到C端用户能够是标准化质量。另外客户希望服务过程中产生不符合规范现象，通过最新AI手段将其进行实时监测当场纠正。另外很多客户特别是业务方希望呈现给客户的是清新亮丽的企业形象、千人一面。以上就是促使我们思考如何将企业交互给用户远程视频服务智能化的原因。这需要RTC平台、音视频交互平台能够非常方便地与各种听觉、视觉、NLP等AI能力服务对接。

1.3 业务平台化

接下来是企业远程视频服务典型需求，痛点是在以前系统建设思路时，出一套业务场景，供应商出一套系统，过了几十年后，会发现IT系统乱糟糟，到处都是各自独立的烟囱。我们希望通过平台化方式，可变更服务流程方式做业务流程的定制，把以前的系统固化业务流程变成可编辑的业务流程。需要使系统具体远程视频服务的流程和内容方便直接地由业务人员编排。

02

—

OWT的分寸

面对企业视频服务的需求，在现如今开源的圈子中，需要支持WebRTC，且后端是非常开放结构，与现有后端AI服务对接、提供可编排业务流程，实际上可选框架不多。OWT是目前来说可以提供较好Base Line，我们在其作为基础做一些事。

2.1 OWT的设计原则

接下来分享一下OWT的设计原则，这一部分在LVS2019时分享过。功能性部分可以直接看得到，做得东西可以描述出来，一个系统的生命力更多是在非功能性部分，系统做成的样子是从软件架构对于系统的期望，而不是功能部门和业务部门能够提出要求的。OWT的设计原则主要有以下几个方面：模块化的运行体系；强隔离；层次化的媒体栈。

原则一：

关于模块化的运行时体系，Modularization不是新鲜事物，是软件开发工程化的较基础的最佳实践，越简单朴素的原则，在平时工作中越容易置若罔闻。OWT非常坚持在画框图时、系统时是独立部件。典型会将信令部件、媒体相关部件、呼叫控制部件等基础平台部件分得较清楚，特别是媒体接入部件非常分明得划分出。

原则二：

关于强隔离，与第一原则一脉相承，在框图上画出独立框，在运行是独立实体，即其存在与其他实体之间没有内存共享，也就是说它的运行位置是没有关系的，即两个交互实体在同一个CPU上或是两个CPU上交互手段一样。将操作系统进程作为系统的细胞，所有逻辑上单元部件运行时是独立的。OWT中有音视频的转码混音混流器，服务于一个混音器是个独立进程，针对Input Stream的一个转码器是独立进程，也就是说每一个橙端运行时的部件都是独立操作系统进程存在。另外系统设计了一套错误检测、错误隔离、错误恢复的机制，例如系统中视频转码部件出现故障，回话控制器会检测到并重新调度资源，将转码服务恢复，将Pipe Line重新搭建，终端用户不感知系统服务实体迁移、出错恢复。

原则三：

关于层次化的媒体栈OWT是实时音视频的框架，非常关键的操控对象就是音视频媒体，在OWT中分成三个层次的组织，从下往上依次是BO交互层，帧交互层，内容控制层。所有媒体相关部件都会跨到帧交互层，媒体接入部件会跨到BO交互层，图像增强、转码混音会到内容交互层。这样做的原因是使得所有流媒体在系统中有共同音视频帧分装格式。

2.2 OWT的UMSM

基于统一的音视频帧分装格式，OWT中定义了一套统一媒体扩散模型Unified Medias Broad Model。上图是示意图，蓝色部分是音视频平台的部件，黄色是外围的端、媒体生成、消费部件。各种格式流媒体进入系统后被接入部件统一化，规整成统一音频视频帧格式定义，在系统中流转媒体格式统一音频帧。

03

—

Zealcomm的解决方案

针对上述企业远程视频服务的需求，OWT是什么样的系统，Zealcomm峰畅科技基于这个系统是怎样完成远程视频服务的需求呢？

3.1 充分融合AI能力服务

首先看待平台角度向前走一步。以前人工智能能力发展到可用之前，众所周知，AI能力在过去3到4年急速发展，在2019年、2020年有能力服务，例如NLP，实时视频生成技术。随着算力成长，可以走到工业界使用，体验可以接受。以前也有厂商借助互联网音视频实时通信平台，将平台作为工具辅助企业远程视频服务。根据前文描述可以看出把音视频平台作为工具辅助交互，服务流程数据是企业编程至业务员大脑中。现如今有些AI能力可以直接与客户进行音视频媒介交互时，可以用视频方式驱动场景体验。

3.2 “视频原生”远程服务工作流平台

直接将场景体验放置交互中是系统设计目标，提出了“视频原生”，由视频的原始信息承载方式提供人与机器的交互。企业远程视频服务场景是怎么样的技术栈呢？如上图根据视频人和人聊天，可见的是交互对象问答。例如合同签署时，机器人推合同过来进行手写签字，电子签名叠加进系统，与柜面真人业务员办理体验相同。在支持体验背后是具体业务场景服务流程，例如是贷款面审流程，有以下几个步骤：提交身份证照片、人证比对，条款确认、社会关系背景核实等，具体场景建立在工作流平台上，可提供一系列业务流程所需交互环节作为模板存在，在模板上拼装业务流程。此平台是通用平台，可在上面拼凑出无穷多的不同的业务流程。最底下是视频信息流，它在平台上有音视频流控制层次。

3.3 架构

上图是系统架构。针对企业远程视频服务场景有访客端，座席端（支持人工坐席，重点推机器人坐席），中间蓝色部分是系统平台主体，下面部分是以OWT为基础打造的开放媒体平台，下面对接的是第三方AI媒体服务。上面的是与客户业务流程系统的对接。

3.4 对OWT的扩展

为了达到上述架构，要对OWT做扩充，特别是对用户已经建设一部分基于传统CT技术视频通信平台，需要对OWT内置SIP网关进行增强，要扩展头携带能力和非标的业务流程信令支持，Recording Agent增强，在录制后马上提供调令。另外增加一些部件，OWT提供统一媒体扩散模型，在模型基础上上只要符合媒体流转的音视频帧格式定义，可以扩展任意媒体。还有进行人脸识别、服务过程中实时截图部件。另外很重要的点是参加bizbot会话控制的增强。

3.5 demo

上面播放的是前不久给客户POC提供系统的演示。真实复杂的业务流程没在其中，用户终端是微信内置浏览器，前半段与之视频问答是数字人，小窗是参与测试的同事，力求通过开放的媒体平台将企业端流程数据对接到用户的眼睛与耳朵。

04

—

OWT之于其他场景

最后介绍OWT在其他应用场景落地时需要补足的点。

4.1 做私有部署的视频会议类应用

一是基于OWT做私有部署的视频会议类应用。所谓的视频会议类是人与人之间交互为主，多方跨地域的形式。有些上市公司直接基于OWT做了产品化，之前提供过咨询与帮助。这方面需要补齐的是在跨数据中心部署时对于扩散模型需要中继节点，增加relay部件。针对多方通信，多端能力，视频流消费需求有自适应订阅切换。如果场景是大规模会话（一个会议中有10万或100万人）会话控制模块需要做增强，它是conference agent，运营状态从处理逻辑剥离做分布式。会话模型要转换成以stream为中心，其逻辑针对性明显，针对传统视频会议场景。另外需要产品化就要会管逻辑、白板标注、文件传递辅助性功能。

4.2 强实时类应用

二是听到有些团队基于OWT做强实时类应用，譬如多人在线游戏（云游戏）、远程遥控等场景对于端到端的延时极其苛刻，一般来说需要大几十毫秒确定的延时，基于Cron不合适，Cron中音视频播放端和采集端都保守通用，需要基于OWT Native SDK做更好的buffer优化。另外要低延时必须要路由干预，与终端直接交互的节点推到离用户终端越近，要在接入节点和其他节点做传输保障。在集群内部，需要扩展统一媒体扩散模型，支持rtp级扩散。

4.3 在线教育/远程课堂类应用

三是基于OWT做在线教育/远程课堂类应用，以前提供过客户支持，此场景下，如果是场景固定，可以直接在SDK对应，如果场景有变化，就需要将场景基本逻辑分出，特别对于教师终端SDK要做优化，传统教师端设备不支持WebRTC的外摄。此外还有自动导播，服务端的学生标签分析、点名计算机视觉能力集成。

4.4 互动直播/跨平台直播类应用

四是是前不久硅谷StreamYard被Hopin收购，它的场景非常简单，基于OWT的完成度有70-80%。需要做的扩展是打磨推流媒体格式支持，OWT支持HLS但做得少，如果推流的话是会议加直播的形式，StreamYard多方场景下是pano，将pano场景推送出去直播，将多方通信mix，适用于所有端，保持一致。另外在直播场景有消息交互的增强，需要与各个直播平台做推流打通。

以上就是我的全部分享，谢谢。