编者按：最近几年视频会议产品得到了极大的关注和快速的发展。产品的用户体验，功能和质量决定了产品能否在竞争中脱颖而出。而如何选择一个好的架构和解决方案是最为关键的因素。
本次分享将分为几大部分：第一部分介绍视频会议产品的历史以现状，以及主要的功能要素。第二部分将介绍基于WebRTC的解决方案以及优缺点，以及主要的挑战。第三部分介绍RingCentral的视频会议系统的解决方案，以及主要技术优势。希望通过分享，大家对于如何打造一款优秀的视频会议产品在架构选择和技术选型上能有一定的收获。
大家好，我今天演讲的主题是关于视频会议，WebRTC以及RingCentral的解决之道。
本次演讲大概分为六部分。首先，介绍下个人及公司，再聊下视频会议产品发展及趋势，之后会讲一些主流的网络视频会议解决方案，紧接着说下基于WebRTC的解决方案及挑战，最后详细谈下RingCentral是如何解决这些问题以及它的架构。
我在RingCentral担任视频与媒体研发高级总监，同时我也是杭州研发中心负责人，负责公司视频产品的研发。加入RingCentral以前，我在Webex任职18年，担任系统架构师和客户端负责人职位，见证了Webex从一个非常小的产品发展壮大到成为leader，进入全盛时期的过程。我本人比较关注RTC领域、人工智能在这个领域的应用等等。
国内认识RingCentral的人可能不多，实际上我们是一家全球领先的企业云通信供应商，联络中心解决方案的提供者。RingCentral1999年成立于美国硅谷，2013年于纽交所上市。RingCentral目前在国内有三家office，分别位于杭州、厦门和香港。统一通信领域中存在很多巨头，像思科、微软等等，RingCentral公司已经连续七年获得荣膺Gartner全球UCaaS魔力象限领导者，可以说是非常不简单了。
可能很多人是从疫情开始接触到视频会议，但网络视频会议本身具有非常悠久的发展历史。早在1970年以前，应该说是20世纪初这个idea就出现了。在20世纪30年代，贝尔实验室制造了第一个可视电话原型。后来，AT&T投入了大量资金研发出了第一款产品，那时的产品是基于特定网络和硬件的，很可惜，AT&T产品完全失败了，但他们的想法和技术在实验阶段逐渐被证实。80年以后被称为商业化阶段，数字电视的普及加速了发展，第一款商业化产品也是在80年代后期到90年期间推出的。这时，AT&T的第一款PictureTel产品也推出了第一个编码器，当时所有的设备和产品都是基于专用的拨号网络和专用硬件，特定用户人群才能使用。90年以后迎来了高速发展的阶段，因为随着互联网和PC的普及，基于PC的商业化产品90年后开始出现，同时也出现了第一款商业化摄像头，解决方法都是互联网和非专用设备，得到了极大的普及和加速发展。2000年以后，视频会议进入了成熟的标准化阶段，编解码器、H264都出现了。WebRTC也在2017年开源了，出现了开源的框架。随着SaaS和云计算的普及，视频会议也云端化，也出现了移动化及多终端化的支持。2020年以后，疫情出现导致远程办公爆发增长，大量公司进入这个领域，也产出了大量创新，视频会议迎来了爆发的阶段。在此之前，很多人可能也没想过虚拟背景替换等，但随着居家办公的出现，虚拟背景替换等创新都慢慢开发出来了，产品变得智能化并且能与不同行业不同技术进行融合。
以我个人见解来看它的趋势，从发展来看，首先是融合化。在疫情之前，网络视频就是一个满足人类基本沟通需求的工具，随着疫情爆发之后，我们发现它和不同的技术比如AI、VR和元宇宙结合，所以它的趋势上来说，越来越多的含义和技术进行融合，呈现出更多的产品和创新。第二点是智能化，已经有很多产品号称含有智能因素，无论是虚拟背景还是智能降噪或是实时语音翻译等。我认为这还远远不够，将来随着技术发展，会出现更多智能化元素提供更丰富的功能来提高效率，使生活更便捷。第三点是生态化，今天的视频会议不再是简单的工具而是一个平台，成为了一个生态。在生态上有硬件产生，有平台供应商，也有提供平台进行二次开发的，能创造出更多附加价值。这个趋势普及范围会越来越广。
如今的视频会议行业有非常多的玩家，或多或少无论你是否认识，有很多视频厂商存在于这个行业。我认为主流网络视频会议决解方案有很多共同点。
首先讲的是对终端的支持。所有的主流厂商基本都会支持这些可见的终端，第一个是移动客户端，随着远程办公和移动办公的普及，没有这个终端是很难让客户买单的，特别是移动，也许你在路上要加个会、假装已经到公司了，这些都是非常便利的方式。第二个是桌面客户端，不用我多说，大部分的应用产品都在桌面端，所以这块必须支持。那会议室终端的话，会议室是一个非常特殊的场景，如果很多人一起用电脑加入会议，无论是语音还是视频都是无法满足这个应用场景的，那就需要一个大屏的电视机加一个强大的外设，所以这一点也是需要cover的。说到H5终端，有些应用场景必须用浏览器来支持加会，自然而然随着浏览器支持WebRTC，这是一个非常重要的卖点。那还有电话终端，随着网络会议的发展，不仅是与对方的电脑，不是每个人随时随地都可以在电脑旁或手机旁，有时需要用PSTN进行沟通，所以这也是一个必要的支持。除此之外还有SIP终端，随着越来越多的厂商出现，你也不能要求所有客户都用同一个产品，之间的互操作性也是一个重要点。
在这些主流厂商中，这些关键功能和技术要点也是要cover的。像音视频和PSTN互通，它需要在很多场景或是会中call一个电话，像视频及虚拟背景支持、桌面共享及远程控制等，这些功能在日常协作或是分享中都是很必要的。比如电子白板在远程办公中可以写字或是画图来相互分享想法。另外，还有弱网优化，我们客户会遇到很多网络状态，你如果不做优化，质量一定是无法保证的。还有标准化及互操作性，刚提到的SIP，随着客户与其他客户开会时，可能会有不同厂商的产品进行相互之间的协作和交流。
在这里，很多关键协议和标准是所有厂商要去遵守的，比如信令方面，我想很多厂商可能会想WebSocket因为它能兼容浏览器，像HTTP也好，那也许很多可能是TCP。在媒体传输方面，我想很简单，无论是WebRTC还是自营的产品，RTP+RTCP必然是首选。在视频编码上，像SVC/AVC+Simulcast/VP8+Simulcast是比较主流的选择。那音频也一样，我相信绝大多数是Opus支持，那比较古老的可能SILK或G.7xx更多的协议。像直播方面，支持的HLS或者DASH等等等等。对第三方交互，大厂商基本都会支持SIP的接入，像SIP+媒体传输来支撑互操作性。
那么，音视频框架，现在主流产品分为两大类。一个是自研框架，很多老牌厂商像Zoom等在很久以前就开始研发，它们都会有自研方案，它的特点是灵活和高性能因为所有都在你的掌控之内。它的缺点是研发周期长，有可能需要几年的投入，很多技术难点一个个去摸索也是非常耗时耗力。另外，最近的厂商像微软/谷歌/飞书等都会选择WebRTC作为起点，WebRTC的特点也非常明显，它有成熟的开源框架，能快速推出源型，资料非常丰富，招人也很方便，因为市场中有大量的人才。相比自研框架它也有很多缺点，它非常庞大，因为有很多标准需要支持，这造成了协商和交互的繁琐，遇到问题调试也是非常麻烦的。另外，性能上来说和自研比也是有差距的，坦白来说有些标准和流程还是存在一定的局限性。
下面我们重点讲基于WebRTC的解决方案及挑战，因为这是目前的先进厂商的主流选择。
我们有两种WebRTC研发模式，一种是基于前端开发模式，主要的研发前端用Javascript或Typescript，一般主流选择用Electron+WebRTC，无论是微软还是国内的飞书都选这种模式，它的特点是跨平台，一份代码能cover Electron本身和浏览器，这个好处是显而易见的。另一种是原生开发模式，即不是用前端语言来开发，还是用C++或者是native语言比如iOS等来开发，它的好处是可扩展和定制化，如果发现哪里性能不行可以很方便地改造它。从性能上来说比前端会好一些，起码调优还是有办法去调，不像前端基本上是不受控的。
那么，基于WebRTC还是有不少优势的。首先它免费，研发这样一套框架如果自己去做起码一两年以上，需要大量投入，比如招人等也是一个漫长的过程，所以这一点是一个巨大的优势，特别是针对于想快速进入市场的公司来说这是一个很不错的选择。第二点是资料丰富，基本上你遇到的坑别人都踩过了，网上都能找到，可以快速解决你的问题。第三点是人才，现在市场上有很多熟悉这块的人才，所以这点对快速迭代或是研发来说是非常重要的因素。那么，它的代码是非常成熟的，全世界有成千上万的人每天日日夜夜在维护和使用，所以我认为很多bug和问题都有非常多的经验可以借鉴。然后，很多主流浏览器都已经支持，这也是非常大的优势，因为刚说的H5终端它需要支持。
WebRTC虽然免费，但它作为一个一流产品还是需要付出很大代价的。它需要强大的服务器端支持，WebRTC本身是P2P模式，服务器端需要自己研发，因为它整套框架非常复杂，需要支持众多协议，标准等，相应的服务器需要自己去识别这些协议也是巨大的挑战工作。因为框架是基于浏览器，有时候你的解决方案可能是为了照顾浏览器，很多方案必须在服务器端实现。由于浏览器不受控制，它提供的接口或者说是能控制的地方不多，所以像回音消除等功能可能选择服务器端去完成，这会带来一些额外的问题，有些局限性比如查问题会比较困难，信令网络断了等会经常发生。另外，服务性能挑战也是一个问题，一方面是因为协议的复杂性，另一方面是因为P2P模式服务器可能存在大量的工作，所以在性能上比较受限。
第二个挑战是它对弱网支持非常有限。WebRTC的设计初期不是为了优化弱网，他们当初做这个框架的时候认为网络不能差到哪里去，太差的网络不应该做音视频会议，它默认只能抗15%左右的丢包。另外，它对默认QoS算法比较敏感，对于一些网络的变化是没法及时调整和适配的。所以有时明明带宽还可以，但检测出来反而只有最基本的语音通信几十K。所以，这是它对于弱网支持来说一个非常大的问题。
对于平台和设备也一样，WebRTC在一些平台上的实现不是很完美，它的音频采集就是默认16K的采集，诸如此类。它也无法使用平台本身的一些能力来提早用户体验，那在一些设备上比如新的苹果手机，它有时会有明显的回声消除问题，所以这也是一个需要关注的问题。
另外，它虽然提供了一个音视频框架，但很多功能还是需要自主去研发的，作为一个主流产品完全靠它肯定是不够的。包括直播它就完全没有提供任何支持，需要自己去实现，比如E2EE（端对端加密），它本身就是P2P，那对于WebRTC来说，天然就不支持这个功能，还有像SIP会议、字幕功能等等。
那对于这些问题，我们重点讲下RingCentral的解决之道以及构架。
首先，RingCentral产品名称是MVP，分别是Message、Video和Phone，它是统一一个client，一个client能让你日常协作在同一个场景里发生，我们的目标是提供任意时间、任意地点、任意设备、任意方式的沟通和通讯。
这是一个非常简单的系统架构图，简化再简化，这只是一个概念上的东西。首先，我们会支持非常多的终端。我们的data center会有级联操作，对于终端来说，它会选择最接近的边缘节点，通过信令和媒体进行交互。数据中心通过级联进行数据传输，这能提高用户体验，用户可以选择离他最近，体验最好的一个服务器来接入。同时，我们会支持非常多的终端支持，比如电话终端我们通过电话网关接入以后进行后台mix，通过PSTN到数据中心等等。对于第三方客户端支持我们通过SIP的网关来接入，能够通过SIP和媒体的交互来支持目前来说所有主流的产品无论是微软的Teams还是Zoom等等。对于第三方直播系统我们也通过RTMP协议，通过信令网络进行分发，对超大型会议进行足够支持，包括将来Facebook、YouTube，能直播到第三方系统中去。
这是RingCentral视频客户端架构。整个客户端分为四层，最底下一层是网络协议层，我们提供众多的协议接入包括HTTP、WebSocket这种信令级别的协议，对于媒体传输或控制有RTP，第三方用SIP，还有其他众多协议等。在协议之上，我们会提供非常多的组件，每个组件可能带着某一项特定的功能，比如视频可能有众多的功能供上层使用，会有音频、桌面共享等等。在组件层之上，我们有SDK层，SDK提供完整的产品功能的实现，例如会议SDK能让用户开发出完整的会议系统，还有直播SDK对大型会议或大型直播能用这个SDK进行直播客户端的开发和实现。刚提到的会议室大屏会议系统，我们用SDK能覆盖到这些应用场景，除此之外还有SIP等等。SDK层之上，APP层提供了完整的客户端的实现，客户端的桌面端也好、移动端也好甚至能通过SDK向第三方开放，使他们能实现自己的第三方客户端。
RingCentral产品提供了高质量的音视频体验，技术上和很多友商是一样的，分为很多模块，在采集阶段利用硬件的能力，在渲染和播放方面进行优化，我们会有AI预处理进行一些AI feature的集成比如降噪、虚拟背景、编解码器、弱网对抗等，我们能够从各方面进行优化例如性能等，通过智能路由能够选择最近的边缘节点，在网络层提供更好的用户体验。这是我们音视频体验方面的架构。
说到对大型会议的支持，对于一家公司有时需要召开员工大会，特别是上万人的公司，这时普通的会议场景是无法支撑的。我们的解决方案是基于亚马逊服务加直播功能，主持人和小组成员在SFU之间交换数据，但SFU通过MCU，再通过RTMP推流到第三方服务，之后，观众端通过CDN网络能支撑超大量的用户。我们目前能支撑到100K级别的用户，同时，我们媒体内容也受DRM保护，是无法通过截取URL或嗅探方式观察到数据内容。
我们对第三方的会议支持，刚提到的是SIP网关的接入。我们有一个SIP会议网关，通过在RC自己的终端之间，相互之间通过内部的SFU或者信令服务器进行媒体的信令交互。但我们会有专门的SIP网关来对接第三方如微软和Zoom，它通过SIP信令的交互来进行协商，同时通过BFCP来对桌面共享等进行传输和支持。所以，我们目前对主流SIP终端支持的非常好，所以它的体验对于弱网优化等会比一般的SIP终端更好。
我们同时也提供端到端的加密，数据安全是非常重要的一点，很多会议内容本身就是保密的，他们不想让RingCentral知道具体内容，默认情况下数据经过服务器，服务器必然知道其中交流的音频和视频。端对端加密就是用来解决技术服务器也不一定能截获数据。我们这是业界标准的做法，通过一个密钥的协商服务器，只提供密钥的交换功能，服务器本身不知道非对称密钥交换。同时，我们通过消息层安全协议来交换密钥，还用SFrame的加密方式对视频帧和音频帧的每一帧进行加密。对于接收端来说，因为发送端是用公钥来进行加密，接收端是用私钥进行接收。对服务器来说，由于它没有获取私钥，是无法获得其中的内容。以上是我们端对端加密方案。
对于整个系统来说，我们有很多AI feature，比如实时语音翻译，对于听力不太好的用户有很大的帮助，它可以实时将语音转化为文字。再说Presentation Mode，类似于天气预报模式，桌面共享时用户头像能显示在左下角，使体验更好，大家既能看到你的人又能看到你共享的东西，看到你的肢体语言等等。还有会议总结，我们能自动对会议生成摘要并总结，会后能自动生成省去做笔记的麻烦。同时，我们也支持语音命令，通过命令来控制终端，避免频繁操作。另外还有自动跟随，比如我在来回走动，摄像头会自动跟随，通过软件来实现AI的状况。当然还有很多这里就不一一列举了。
我们还是有非常多的挑战比如性能问题，我们知道Electron它本身作为一种框架性能是有缺陷的，内存管理有时会达到2个G，这是框架本身带来的，即使是微软Teams也会遇到类似问题，国内的飞书也一样。同时，我们是Web技术也会带来性能损耗，特别是大量计算，如果用前端语言的话会非常耗CPU。还有媒体处理和AI，这些都是非常耗性能的比如虚拟背景，可能计算量非常巨大，打开这种功能明显能看到CPU在飙升。对于这种问题，我们的解决方案一方面是我们深度定制Electron本身，特别是对内存管理等做了很多优化，降低损耗，另一方面涉及到高耗能计算功能的任务我们都移到C++或native语言去，以NodeJS模块的方式提供前端访问，提高性能。如果对于某一些无法移到native语言的，我们会用别的方式解决性能问题。
第二个挑战是媒体质量和体验。WebRTC在弱网情况下，媒体质量不佳，在网络好的情况下大家都感觉不到，当丢包或者抖动比较严重的时候，视频卡顿是非常明显，有时可能视频或桌面共享加载是非常缓慢的，存在呼吸效应时而清晰时而不清晰等。我们一方面深度定制WebRTC本身，特别是对桌面共享，我们加了一个全新的模块，它默认的性能是非常糟糕的，像QoS就完全重写，不同场景、不同业务需求下有不同的策略来对应，而不是统一的算法去cover所有场景。还有就是引入更好的Codec和算法，提供最佳的用户体验，比如引入RS-FEC来支撑抗丢包策略，这是性能方面的一种解决方案。
另外，还有对于平台和设备的适配，WebRTC默认在有些平台上做的不是很到位，有些终端支持的不是很好，特别是一些安卓的设备性能本身就非常糟糕，WebRTC默认实现非常耗时，对于这种设备我们一方面是改变平台的支持比如增加对Windows上的48K音频采集的支持，同时对不同终端引入云端配置，如果发现新的设备回音消除非常差，需要加入回音消除算法，可以通过远程配置动态调整算法来支持不同设备的硬件能力。还有，在用户体验设计上，如果设备性能真的特别差到不能用，比如很便宜的安卓设备，当一些指标差到一定程度时，会实现“功能降级”，比如视频最多显示九个，以获得更好的音频体验等。
喜欢我们的内容就点个“在看”吧！
