如何基于WebRTC搭建一个视频会议

疫情期间，视频会议等远程办公产品备受青睐，众多互联网玩家切入视频会议市场，加剧市场竞争。但是，产品虽多，能够带来稳定可靠体验的产品却凤毛麟角，它的难点在哪里？视频会议的门槛到底有多高，又能够做到怎样的极致体验？在本文中网易智慧企业流媒体服务器天团将从 0 到 1 向大家介绍如何基于 WebRTC 来搭建一个视频会议。

一、入门篇

WebRTC 技术的本质是构建点对点的实时通信，目前主流的浏览器，包括 Chrome, Firefox, Edge 等，天然就支持 WebRTC 协议。对入门开发者来说，选用这几款浏览器，连开发客户端的时间都省了。最简单的 Web 视频会议，只需要架设一个 Web 服务器，服务器兼具信令交换的能力(信令服务也可以独立部署)，两个浏览器通过 Web Server 交换会话信息，就能建立 P2P 通道来传输媒体流，进行 1v1 的视频会议。如下图所示：

先请出我们今天的主角 WebRTC，它是由谷歌推广的实时音视频技术栈，是音视频领域搜索热度较高的技术。它有多重身份，既是 W3C 的标准，也是一个开源项目，还有一个对应的IETF工作组(RTCWEB)。在 WebRTC 出现之前，音视频通信是高不可攀的领域，需要大量的专业积累才能入门，而现在，越来越多的开发者通过 WebRTC 来深入了解 RTC 技术。

两个浏览器向 Web 服务器请求页面，并进行 SDP 交换，然后在浏览器之间直接建立P2P Transport，进行媒体流传输。这是最简单的 WebRTC 应用形式。这种简单的媒体流直联的方式，线上有很多教程，也可以参考 WebRTC 的 demo (https://webrtc.github.io/samples/ )，这里不展开。

如果拓展到多方的视频会议，架构是这样的：

可以看到，这种”简单”的视频会议，有两个风险点：

P2P 在两个客户端之间建立，不可避免的涉及到 NAT 穿透的问题，打洞的成功率直接影响 P2P 的可用性，在会议场景是不能接受的。

在多人场景下，本地的媒体流以拷贝的形式发送给每个对端，对网络带宽是个极大的浪费，上行网络的带宽瓶颈决定了会议的方数上限，影响体验，也不利于扩展。

要解决这两个问题，就要引入媒体服务器。看下面的架构图：

加入媒体服务器后，每个浏览器只和服务器建立媒体传输通道。

媒体服务器架设在公网，P2P 的可用性有保障。

每个浏览器只向服务器发送一路本地媒体流，由服务器负责转发给远端，避免了带宽浪费。

对于视频会议来说，这是更优的架构选择。

常用的媒体服务器主要分为 SFU(Selected Forward Unit)和MCU(Multipoint Control Unit)，SFU 只负责媒体流转发，不做太多复杂的媒体处理，并发能力会强一些。MCU除了媒体流的接收/发送，还会进行转码和混流，对服务器的性能要求比较高，在实时传输系统中，转码会带来额外的延时，在选型时也必须考虑。多人视频会议场景下的 SFU/MCU 架构示意如图：

SFU 对接入的媒体流进行一些平台转发，MCU 对接收到的媒体流做转码后，只转发一路合成后的媒体流。它们的优势和劣势总结如下表：

WebRTC 的生态中，有许多优异的开源媒体服务器，下面列出部分关注度高的项目：

大家可以根据自己的需求，选择合适的项目来搭建媒体服务器。对于实时性和高并发有强要求的会议场景，笔者还是推荐采用 SFU 架构，下面的进阶篇中也会基于 SFU 展开介绍。

另外，如果不满足于浏览器入会，有扩展客户端覆盖的需求，上述的开源项目中，也有相应的 native 的客户端库，比如 mediaSoup，有提供一个 libmediasoupclient 的 C++ library，这个库本身是基于 libwebrtc 的，大家可以基于这个库来搭建 iOS/Andriod/PC 的客户端，需要一定的时间摸索编译环境，但不会太复杂。

这还不是 WebRTC 生态的全部，在客户端扩展方面，WebRTC 是一直走在路上的，各种前沿的混合开发框架项目中，都能看到它的身影，比如 RN/Flutter/Cordova 等等，在 Github 上都有 WebRTC 开发库，愿意实践的开发者可以尝试，不过，要用这些开发框架做到产品化，还是需要一定积累的，需要踩一些坑。

到这里，我们完成了基础的视频会议搭建，或许在通话时会面对这样那样的质量问题，但至少实现了听得见、看得到，浅尝辄止的目标已达成。下面的进阶篇，就留给打算深入学习 RTC 的小伙伴(需要一些音视频基础)。

二、进阶篇

视频会议的基础是实时音视频通信(RTC)技术，在上一篇解决了听得见、看得到的问题之后，在接下来的进阶篇中，我们重点关注下如何能让音视频通信稳定、流畅、可靠，也就是关乎视频会议的质量体验问题。

大家可能都会有这样的体会，视频会议总是很难保持稳定，偶尔会视频卡住，或者声音断续，或是今天可以正常完会，改天就不好。其实实时音视频通信的原理就是信号的采集，处理和传输，而其中传输部分是最难把控的，为了做到实时性，我们要摒弃长时延、可靠的 TCP，选择不可靠，但有可能做到实时的 UDP。在公共互联网上用 UDP 搭建传输网络，它的不可靠的因子会被放大，比如时延，抖动，丢包等，都有可能影响视频会议的体验。

下面的章节中，我们重点介绍实时音视频通信中的 Quality of Service (QoS)。QoS 可以狭义地理解为链路分组数据传输的质量指标，相对的另一个指标是 Quality of Experience(QoE)，它是用户对设备，网络和系统总体的端到端主观体验。

（一）QoS 那些事

WebRTC 中已经具备了一些保障 QoS 的策略，比如 ARQ，FEC，Jitter Buffer，Congestion Control 等，让我们结合前面的 SFU 架构来展开探讨。

QoS 策略的主要任务是对抗影响数据传输的网络变量，比如时延，抖动，丢包，带宽等。我们简单介绍下 QoS 的常规武器。

• ARQ：自动重传请求，是数据链路层的错误纠正协议之一，WebRTC 中用到是协议中的 NACK 机制，即接收端监测到数据包 SeqN 丢失后，发送对该数据包的重传请求，由发送端执行重传。
• FEC：前向纠错，是增加数据通讯可靠度的方法，利用原始数据编码进行冗余信息的传输，当传输中出现丢包，允许接收端根据冗余信息重建。WebRTC 利用 UlpFEC 进行数据保护，冗余系数由链路上的丢包率决定。
• Jitter Buffer：抖动缓冲，通过在接收端维护一个数据缓冲区，可以对抗一定程度的网络抖动，丢包和乱序，需要考虑的是接收延时和卡顿之间的平衡。
• Congestion Control：拥塞控制，WebRTC 利用 GCC 算法来控制传输，通过兼顾丢包和时延的算法来估计网络可用带宽，并以此估算值来控制源端发送码率，避免网络拥堵。

在典型的 SFU 传输链路中，媒体流(RTP 数据包)由 Sender 发送到 Receiver，媒体控制流(RTCP 包)由 Receiver 反馈给 Sender。控制流中包括了 NACK, PLI, REMB, Receiver Report 等反馈信息。这些反馈信息是配合 QoS 策略的辅助手段。

有了这些 QoS 策略的加持，WebRTC 的视频通话能够对抗一定程度的网络状况，正常情况下的通话质量可以保障。但是，这种默认的策略也存在明显的改进空间，比如：

• QoS 的策略是在端到端之间生效的，接收端发现丢包后，才会向发送端发送 NACK请求重传，全链路的路径(rtt)过长，影响数据重传和恢复的效率。
• 接收端在发现无法恢复视频帧后，才会发送 PLI(Picture Lost Indicator)向源端请求关键帧，直到下一个关键帧到达前，所有链路上的视频帧都无法正常解码，影响接收端的视频帧率，较大概率造成卡顿。
• 针对这两个典型的问题，我们可以分别尝试改进。

如上图所示，在改进的 SFU 传输架构中，重传请求不再是全链路反馈，而是在客户端和服务器之间进行。一方面，服务器具备了 NACK 请求的能力，及时发现上行链路的丢包，及时向发送到请求重传。另一方面，服务器能够及时响应接收端的 NACK 请求。丢包重传的效率提升，有助于减少端到端延时，改善音视频体验。

对于弱网下视频帧率较低的问题，除了优化传输过程中的 FEC+NACK 策略之外，还可以从源端编码器入手调整。

常规的 RTC 系统中的编码 GOP 是 IPPP…P，每一个 P 帧都作为参考帧，一旦某一帧有数据包缺失，其后的所有 P 帧都无法正常解码，抗误码扰动的能力比较差。

一种改进的思路是，改变编码器的参考帧选择，采用长参考帧 Long-Term Reference (LTR) frames 机制，比如：

可以看到，引入 LTR 后，P 帧不再是单一的前向参考，而是会有选择性的参考一些固定的帧，只要这部分固定的参考帧能够完整被接收，就能确保其他的完整帧能够正常解码，提高接收端的视频帧率，保障流畅。这种编码方式是比较适合于 RTC 系统的，能够对抗更大的网络抖动。

应用在视频会议中，需要接收端实时反馈的配合。接收端借助于 RTCP，实时反馈能够正常解码的帧信息，发送端可以利用收集到的这些信息，选择合适的参考帧序列(需要兼顾编码效率)，这样端到端的配合，能够最大程度的提升实时传输系统的体验。

这种反馈与编码协同的机制，同样适用于多人的会议场景。只不过，在多人场景中，我们要面对更加棘手的多端拥塞控制问题。

前面介绍过 WebRTC 自带的端到端拥塞控制，在会议场景下，拥塞控制需要综合考虑各个客户端的情况，如下图所示：

在多人会议情况下，各个接收端的带宽能力是不相同的，每条链路的带宽估计值都会反馈到发送端，由发送端来统一决策，控制编码和发送码率。这会带来两个潜在的问题：

• 多条链路的带宽反馈导致发送端的决策困难，编码/发送码率容易抖动。
• 某一个接收端的网络带宽不足(如图中的 300k 下行)，发送端就会降低码率以适配当前带宽，导致每个接收端的体验都会下降，这显然是不合理的。

解决这些问题，我们就要来改进拥塞控制模型。大致的思路是，在 SFU 上实现带宽估计反馈，以及下行的拥塞控制。将端到端的拥塞策略，演进为分段的拥塞控制策略。

理想情况下，发送端会根据上行的带宽估计值控制源端编码和发送码率，SFU 则会利用下行的带宽估计值，来控制下发给各接收端的较高码率。

然而，现实问题是，当 SFU 只有一路视频可以转发时，如何根据各链路的带宽情况进行下发控制，有点巧妇难为无米之炊的感觉。

这里要借助于两种源端编码策略：Simulcast 和 SVC。

Simulcast：同步广播，指的是同时编码/发送多路视频流，比如常规发送一路 720p，外加一路 180p 的流，这样在 SFU 下发给接收端的时候，可以根据下行带宽的限制，选择下发不同分辨率的流，照顾到每个端的体验。应用 Simulcast 的系统示意：

SVC：可伸缩编码，使用基于层次的方法，提供时间或空间可伸缩编码组合。在 RTC 的应用中，通常会选用时域 SVC，通过改变帧率来实现伸缩性。SFU 可以根据下行的实际带宽，从同一路 SVC 视频流中解析出不同的时域分层，分别传输给各个接收端，同 样可以实现差异化的视频流转发。

Simulcast 和 SVC 在实际应用中各有优劣，Simulcast 多路流的分辨率跨度大，主观体验不佳；SVC 的时域分层会影响帧率，容易出现卡顿。

（二）实时传输网络

前一节重点介绍了 WebRTC QoS 的基本配置，以及进阶的实践方向。有了这些武器，可以在上下行网络质量有波动时，还能保障较好的音视频体验。

在视频会议的搭建过程中，QoS 策略的保障是一方面，传输链路的选择也同样重要。

到目前为止，我们介绍的视频会议架构还是中心服务器转发，摆在我们面前有几个显而易见的问题：

用户远距离接入，尤其是跨国、跨地区时，传输链路质量没有保障。

国内的跨运营商之间接入，网络抖动大，影响会议质量。

单点服务器的容量和负载受限制。

如果希望我们的视频会议是稳定、可靠的，解决上面的所有问题，必须构建一个具备智 能调度的实时传输网络。

整体网络传输的调度见上图，几点简要的说明：

分区域/分运营商部署 SFU 服务器，用户通过接入服务实现就近接入，保障了最后一公里的质量。

灵活/按需部署路由节点，通过路由分配服务，能够根据实时网络质量选择优异的传输路径。

分布式的 SFU 更有利于会议方数的扩展和服务扩容

需要保障传输 s 网络内部的数据传输质量，可以尝试 QUIC。

结合上述两点，有了可靠的传输网络，加上 QoS 保障的上下行质量，才能实现让人放心的视频会议体验。

（三）其它

除了网络传输和 QoS 之外，视频会议的质量体验也和客户端的表现相关，一些端侧的疑难杂症，比如设备可用性，回声消除，双讲抑制等等，一定程度上决定了会议产品的成败。这一部分的技术细节，将会在今后的公号文章中分享。

三、To Be Continued

自建一个视频会议产品绝非一朝一夕之事。视频会议系统庞大，文中介绍的也只是一小部分。未来我们会针对技术细节，结合网易实践，进行持续的分享，甚至推出免费的系列课程。

另外，如果你对本篇文章有任何疑问，或想针对某一细节继续探讨，欢迎大家关注公众号，留下你的问题，对话网易智慧企业流媒体服务器天团。我们也会定期汇总大家的问题，整理成专题文章发布，希望给大家带来更多收获。

关于网易云信

网易云信：网易智企旗下融合通信云服务专家、通信与视频 PaaS 平台。集网易 24 年 IM 以及音视频技术打造的融合通信云服务专家，稳定易用的通信与视频 PaaS 平台。提供融合通信与视频的核心能力与组件，包含 IM 即时通讯、5G 消息平台、一键登录、信令、短信与号码隐私保护等通信服务，音视频通话、直播、点播、互动直播与互动白板等音视频服务，视频会议等组件服务，并联合网易易盾推出一站式安全通信方案「安全通」。目前，网易云信已经成功发送 1.6 万亿条消息，覆盖智能终端 SDK 数累计超过 186 亿，我们期待每个智能终端都有云信的融合通信能力。