从入门到进阶｜如何基于WebRTC搭建一个视频会议

导读：疫情期间，视频会议等远程办公产品备受青睐，众多互联网玩家切入视频会议市场，加重市场竞争。可是，产品虽多，可以带来稳定可靠体验的产品却百里挑一，他的难点在哪里？视频会议的门槛倒地有多高，又能作到怎样的极致体验？网易智慧企业流媒体服务器天团将会从0到1，和你们分享如何基于WebRTC来搭建一个视频会议。

文｜网易智慧企业流媒体服务器天团

入门篇

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

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

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

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

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

1. P2P在两个客户端之间创建，不可避免的涉及到NAT穿透的问题，打洞的成功率直接影响P2P的可用性，在会议场景是不能接受的。
2. 在多人场景下，本地的媒体流以拷贝的形式发送给每一个对端，对网络带宽是个极大的浪费，上行网络的带宽瓶颈决定了会议的方数上限，影响体验，也不利于扩展。

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

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

• 媒体服务器架设在公网，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

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

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