WebRTC多人视频会议服务端架构

WebRTC 除了一对一通信外，最常见的使用场景便是多人视频会议。不要只考虑传统的会议室场景，有很多场景都超出了会议室的范畴，比如网上学习、客服支持、或者实时广播。在每个场景中，最重要的能力便是如何分发多路音视频流。所以假设你是服务供应商，你该如何将多人会议场景适配到 WebRTC 客户端上呢？

其实根据不同的需求，存在几种架构；这些架构基本都围绕两个维度展开，即中心化 vs 点对点连接（P2P）；混流 vs 路由中继。我会在这里介绍几种最流行的架构。

Mesh

Mesh 是最简单的架构。它在新的 WebRTC 服务供应商中很受欢迎，因为它（基本）不需要任何基础设施。该架构对于每个发送者和它所有可能的接收者而言，都会创建连接。

尽管这种架构看起来很低效，但实践证明它非常有效；并且由于每个接收者都具备开箱即用的带宽自适应功能，可以将延迟降至最低。

唯一的问题在于，这种架构需要大量的上行链路带宽才能同时推流给所有接收者，并且目前的浏览器实现需要消耗大量的 CPU 资源才能对视频并行编码。

混流

传统的多人会议架构采用的是混流模式，并且这种架构已经使用了很多年了。这是因为它需要的客户端能力最少。这种架构使用中心节点与每个参与者保持一对一连接；中心节点接收每个发送方的视频流并将它们混合成单个视频流，然后发送给每个参与者。在视频会议领域，这些中心节点被称为 MCU（Multipoint Control Unit，多端控制器）。

混流架构的兼容性最好，可以兼容很多老旧设备；它也支持带宽自适应模式，因为混流单元可以为每个接收者分别生成不同质量的视频流。混流架构的另一个优点是它能利用硬件解码，许多 WebRTC 客户端的芯片都具有解码单个视频流的能力。

混流架构的主要问题是 MCU 的架构成本。此外，混流既需要解码还需重新编码，因此会增加延迟以及降低画质。同时混流也降低了客户端 UI 的灵活性（尽管存在一些解决方案）。

路由中继

路由中继架构是 H.264 SVC 普及后流行起来的，并且已经被广泛应用于新的没有历史包袱的 WebRTC 平台。该架构使用中心节点接收每个发送方的视频流，并将其转发给其他参与者。中心节点对数据包仅仅进行检查和转发，而不进行解码和再编码。

路由中继提供了一种廉价的且可扩展的多人会议架构；与混流架构相比，它具有较低的延迟，并且没有画质损失。

但另一方面，大部分从业者往往缺乏搭建这种架构的经验，并且对于不同的接收方适配起来较为棘手。这需要发送方支持生成一个流的多个版本（比如 Simulcast 或者 VP8），路由器会根据接收方的客户端能力选择性地转发对应的流。

我该使用哪种架构？

不幸的是，这并不是一个简单的问题。一些服务供应商为了满足不同客户的需求，提供了上述所有架构的支持。不过这里还是有一些通用的选择方式以供参考。

如果你提供的是纯音频服务，或者需要兼容老旧设备，那么混流架构是不错的选择。此外，假如你的成本开销并不是问题；并且参与者们各自的连接性非常不同，也可以使用混流。

如果你的服务的使用者们有着非常好的网络，他们的设备配置也很给力（比如公司内部服务），并且参与者数量有限，那么 Mesh 架构是不错的选择。

如果你要部署大规模服务，那么就选择路由中继架构。总的来说，路由中继架构既能较好地利用客户端算力，同时还能保持良好的扩展性和灵活性。

WebRTC 缺少了什么？

尽管存在各种免费或者付费的 WebRTC 多人会议解决方案，但是仍然存在一些可以提升用户体验的技术设施建设，包括但不限于如下几点：

提升音频处理和编码的效率，尤其是提升回声消除和噪声抑制算法。
更高级、更灵活的拥塞控制，可以即时修改流的参数，例如比特率、视频质量或分辨率。
支持 Simulcast 和 Layered Video Coding，以使原始视频流能分别适配每个接收方的客户端能力。对于 Simulcast 而言，存在一些解决方案；但对于 VP8 的 Layered Video Coding，恐怕我们就得去修改 WebRTC 的代码了

总而言之，基于 WebRTC 开发多人会议服务是一个好的开始。随着 W3C 标准的发展、更多的 API，以及各大浏览器厂商的跟进，基于 Web 的视频会议将拥有光明的未来！