单个群组WebRTC视频通话中可以容纳多少用户

只要你想，在WebRTC视频通话中添加从一到一百万的用户都是可以的。

当被要求创建一个群组视频通话时，显然，针对该项目应该选择WebRTC技术。这几乎是唯一的选择，而且肯定也是性价比最好的。这时有个很大的问题：单个群组WebRTC视频通话中可以容纳多少用户？

每周至少有一次我会被问到：WebRTC是点对点的，能否用于大型群组通话，因为这种技术可能不适合这种用例。事实上，WebRTC技术十分适合大型群组通话。

您需要做的是，将WebRTC看作一组技术构建模块，根据具体需求进行整合和匹配，同时，WebRTC在浏览器中的实现也只是其中一个构建模块。

目前，WebRTC技术中支持群组视频通话的最常用构件是SFU（选择性转发单元），这是一个媒体路由器，它接收所有来自会话的参与者的媒体流，并决定传输路径。

在本文中，我想要讨论的是，在创建支持使用WebRTC的大型视频会话的应用程序时，需要考虑的几个方面和决策。

分析复杂性

首先，来分析一下我们用例的复杂性。

对于WebRTC，以及实时视频通信，我们将归结为速度和流数:

1、速度——在服务器中我们所期待的分辨率和比特率。

2、流数——单个会话的媒体流数量。

让我们从一个例子开始。

假设你为企业提供一个群组通话服务。它可以在全球范围内运行。人们将一起参加工作会议。你计划将小组会议限制在4人以内。我知道你想要更多参与者，但在这个例子中我只是想让事情变得简单明了。

上面的插图显示了4人参与会议的示意图，4个人多对多的推流和拉流就形成了魔方矩阵方式的推拉流关系（布局）。

魔方矩阵方式：720p

如果你希望这个视频会议是魔方矩阵式的布局，我们的讨论如下:

你想要高质量的视频。这就是每个人都想要的。因此，针对WQHD显示器（即2560×1440），你计划让所有参与者发送分辨率为720p的视频。它消耗了1.5Mbps(这里我很吝啬，它可能需要更多)，所以:

会话中的每个参与者发送1.5Mbps，接收3个1.5Mbps的流

在4个参与者中，媒体服务器需要接收6Mbps并发送18Mbps的数据。

总结在一张简单的表格中，我们得到：

魔方矩阵方式：VGA

如果您对分辨率不太感兴趣，可以针对VGA分辨率，甚至将比特率限制600Kbps：

以VGA标准传输视频时，需要避免的事情是在显示器上提高分辨率 - 因为看起来会很难看，特别是在较大的4K显示器上。

即使在餐巾纸上粗略地计算，可以得出，一个分辨率为720P的视频会议消耗的带宽大概相当于3个VGA会议。

Hangouts方式

但是如果我们的布局有点不同呢？像图示有主要演讲者和以较小窗口出现的其他参与者：

我称之为Hangouts方式，因为Hangouts以这种布局而闻名，并且属于第一批专门使用这种方式而不提供更多额外的布局。

这一次，我们将使用联播的方式（simulcast），并计划让每个人都发送高质量的视频，SFU决定使用哪个输入流作为主要的发言人并为其选择更高的分辨率，而其他参会者则选择较低的分辨率。

经过几次实验后，发现将较低分辨率的视频缩放到较大显示器时看起来不太好，所以你决定选取720p。你最终得到如下结果：

.会话中的每个参与者发送2.2Mbps（对于720p的视频流，这是1.5Mbps，对于其他联播的参与者会有额外80Kbps）

.会话中的每个参与者从占主导地位的发言者接收到1.5Mbps的数据，同时还有来自于较小窗口的两个~300Mbps的输入数据流

.在4名参与者中，媒体服务器需要接收8.8Mbps并发送8.4Mbps的视频流

这里我们可以学到：

不同的用例中，具有相同用户数量的群组视频，在媒体服务器上会转换为不同的负载。

如果没有特别提到，联播（simulcast）的效果是最好的，它提高了群组呼叫的效率和质量（联播是我们在Hangouts方式的视频会议中使用的）。

在我们描述的用于4路视频通话的3种场景中，我们得到了在SFU上3组的不同数据：

在WebRTC呼叫中有多少用户处于活跃状态？

这是个棘手的问题。

如果你使用的是MCU，在MCU可以处理的前提下，呼叫数量可以尽可能多。

如果您使用的是SFU，则取决于3个不同的参数：

1. 媒体服务器的复杂程度以及它的性能

2. 在客户端设备上可用的资源

3. 构建基础架构和实现级联的方式

我们很快会回顾这些。

同样的场景，不同的实现

在单次呼叫中，当用户达到8-10个时，情况会变得复杂。这里我想分享一个公共服务（产品）的例子。

场景如下：

.在魔方矩阵方式布局中单次会议有9名参与者

.使用testRTC进入会话，实现全自动化

.因为是demo，在运行一分钟之后进程会自动结束

.考虑到屏幕上有9个人，所以将所有人的分辨率降低到VGA，并分配1.3Mbps

.导致浏览器将接收10Mbps的数据进行处理

在这里媒体服务器会决定如何限制和测量流量。

这里是另一个demo，进行的是完全相同场景：

现在每个浏览器的平均传入速率仅为2.7Mbps，几乎是其他服务的四分之一。

同样的场景，不同的实现。

对于主流应用产品又如何？

基于SFU模型的视频会议，市面上的一些主流应用产品又如何？他们的应用程序中关于参会者规模有什么样的限制？

以下是我从网上搜集到的内容：

.Google Hangouts - 一次会议中最多有25位参与者，过去是最多容纳10个人。当我第一次也是唯一一次使用它进行WebRTC培训时，参会者人数一超过10人就卡死了，导致了我只能选择使用其他视频会议服务。

.Hangouts Meet - 在单个会话中将其参与者人数限制在50人以内

.Houseparty - 8名参与者

.Skype - 25名参与者

.appear.in - 使用专业帐户登录，单个房间内最多支持12个参与者

.Amazon Chime - 桌面版16位参与者，iOS上最多8位参与者（尚未支持安卓）

.Atlassian Stride and Meet Jitsi - 50位参与者

这是否意味着不能超过50个参与者？

我认为随着会议规模的增加，难度越来越大：

CPaas对尺寸的限制

当您查看CPaaS平台时，那些支持视频和群组呼叫的服务通常会限制其会议规模。在大多数情况下，他们会给出一个他们测试过的或适合的参会者人数。正如我们所看到的那样，这个参会者人数适用于一个非常具体的场景，但很可能不是你要满足的场景需求。

在CPaaS中，在单个会话中，这些数字在从10位到100位参与者不等。通常情况下，如果超过给定的参会者人数，则超过指定数目的参与者只能观看而不能发言。

要记住的关键点

需要记住的几件事：

.群组规模越大，实施和优化的复杂性就越高

.浏览器需要运行多个解码器，这本身就是一种负担

.在这种情况下，移动设备，特别是旧设备，可能很快就会瘫倒。在确定要支持的会议人数规模之前，测试你计划支持中的最老式，最小型的设备

.您可以构建SFU，使其不会将所有传入的媒体流路由到每个人，而是选择部分数据发送出去。例如，音频通道上只传送一个发言人的音频数据，或者4个最重要的发言人的音频数据

调整您的媒体服务器

调整大小和媒体服务器是我最近在testRTC上做的事情。过去我们曾经和Kurento合作过一段时间，并正在计划修补其他媒体服务器。我参与的每个项目中都会遇到这个问题：

在单个媒体服务器中，我们最多可以添加多少会话/用户/流？

根据我们上面看到的关于速度和流数的内容，最稳妥的回答应该是：这很大程度上取决于你在实现什么业务。

如果你需要的是每个人都处于活跃状态的群组呼叫，你应该选取在一台服务器上容纳100-500名参与者的方案。这些数字会根据你为媒体服务器选择的计算机以及每个数据流平均计划的比特率而有所不同。

如果你需要的是一个单主播对多观众的联播，使用WebRTC是为了维持低延迟，200-1,000是较理想的估计规模，甚至可能更多。

大型机器还是小型机器？

你需要解决的另一件事是，要选择哪台计算机来托管你的媒体服务器。是选择性能较差的大机器，还是体验良好的小机器呢？

使用大型机器意味着你可以在一个服务器中添加更多的观众，这样服务的复杂性就会降低。但是如果发生崩溃（媒体服务器崩溃），就会有更多的用户受到影响。当你需要升级你的媒体服务器（很显然你会），这个过程会让你付出更多的代价，或者变得更加复杂。

机器越大，它的内核就越多。这导致需要在多线程模式下运行媒体服务器。这意味着它们构建、调试和修复变得更加复杂。也增加更多不确定的部分。

选择小型机器意味着你会更早地遇到规模问题，他们将需要更精细的算法和启发式算法。在负载平衡服务时，会出现更多的极端情况。

基于流，带宽还是CPU来确定规模？

如何确定你的媒体服务器达到了满负载？如何决定下一个会话是否需要一台新机器，还是放置在当前使用的媒体服务器上？如果选择当前使用的媒体服务器，当新的参与者想要加入在此媒体服务器上正在运行的会话时，那么他们是否有足够的空间？

这些问题不容易回答。

通常有3种不同的度量标准，用于决定何时从单个媒体服务器扩展到其他服务器。具体如下：

基于CPU - 当CPU达到一定的百分比时，意味着机器是“满”的。当你使用较小的机器时，它的效果最好，因为CPU是你消耗的第一个资源。

基于带宽 - SFU消耗了大量网络资源。如果你使用的是更大的机器，你可能不会达到CPU的极限，但是最终会消耗太多的带宽。所以最终将通过带宽监控来决定可用的容量。

基于数据流 - 有时基于CPU和带宽的挑战在于，根据动态条件，可支持的会话和数据流的数量可能会有所不同。通过策略调整可能也无法应对这种情况，所以可能需要更多的计算。这将导致无论是基于CPU还是带宽来调整计算机的大小，都需要根据服务器可支持的数据流数量制定规则。

这里面临的挑战是，无论你选择哪种方案，确定规模都是需要独自完成的。我看到，在需要解决这个问题时，很多人会选择使用testRTC。

级联单个会话

级联是将一个媒体服务器连接到另一个媒体服务器的过程。如图所示：

我们有一个4路组视频电话，分布在3个不同的媒体服务器上。服务器根据需要在它们之间建立连接。为什么要做这个？

＃1 - 地理分布

当将SFU作为其中一部分并在全球范围中提供服务时，立即引发的问题是在进行新的会话时，您将为其分配哪个SFU？在哪些数据中心？由于我们希望让媒体服务器尽可能靠近用户，因此我们要么提前知道有关会话的信息并根据这决定将其分配到哪里，要么通过合理的方式来决定，比如地理定位 - 我们选择在离用户最近的数据中心创建会议。

假设4人正在通话。其中3人来自纽约，而第4个人来自法国。但是如果是这个法国人最先加入到这个通话中，那么会发生什么？

结果是该服务器将会在法国托管。4人中有3人将远离媒体服务器。显然这不是最好的方法...

一种解决方案是，通过距离参与者最近的服务器之间进行传播的方式来进行会议：

我们使用更多的服务器资源来获取此会话，但我们对媒体路由有更多的控制权，所以我们可以更好地优化它们。这提高了会议的媒体质量。

＃2 - 碎片分配

假设我们可以在单个媒体服务器上连接多达100个参与者。此外，每次会议最多可容纳10人。理想情况下，我们不希望为每个媒体服务器分配超过10次会议。

但是如果我告诉你会议的平均规模是2人呢？那么我们将得到这样的分配:

这会导致服务器资源的大量浪费。我们该如何解决这个问题？

1. 通过预设人数达到最大会议规模。但这不是真正需要做的事情

2. 冒一个风险，假设你分配了50%的服务器容量，那么剩余的容量则是留给现有的会议以应对参会人数的增长。虽然仍然是在浪费资源，但程度较低。由于服务器资源的限制，我们可能无法应对会议中可能出现的边缘情况

3. 通过跨媒体服务器迁移会话对服务器进行“碎片整理”。这听起来不太有友好，而且可能会扰乱用户。

4. 级联会话。允许跨机器的规模增长

最后一个级联中，您可以通过预留部分媒体服务器的资源，来实现将现有会话级联到其他媒体服务器的目的。

＃3 - 更大的会议

假设您想创建比单个媒体服务器能够处理的更大型会议，那么唯一的选择就是级联。

如果您的媒体服务器可以容纳100名参与者，但是您希望参加规模为5000名的会议，那么您需要通过级联以支持他们。但这并不容易，这就解释了为什么没有很多这样的解决方案可以用，但这是可能实现的。

请注意，在这样的大型会议上，媒体流不会是双向的。在会议中，发送媒体流的参与者比较少，绝大部分的参与者都只是接收媒体流。关于纯粹的联播场景，在Red5 Pro博客上我写了一篇关于的缩放挑战的文章。

概括

本文中我们触及了很多领域。在尝试确定在WebRTC视频通话中能够有多少用户时，应该做的是：

1. 无论会议是什么规模，都能使用WebRTC支持实现

1.1. 这是一个成本问题，并与商业模式保持一致，这将决定或打破这一模式。

1.2. 会议规模越大，实现的方式就会越复杂，同时需要更多的限制和假设

2. 分析你需要支持的复杂性

2.1. 统计每个设备和媒体服务器的传入和传出流

2.2. 决定每个流的视频质量（分辨率和比特率）

3. 定义将使用的媒体服务器

3.1. 选择一种机器类型以运行媒体服务器

3.2. 在扩展之前计算出所需的规模

3.3. 检查服务器资源上的增长是否是线性的

3.4. 决定是否基于带宽，CPU，流数或其他进行扩展

4. 图示的级联该如何实现

<p style="border:0px;color:rgb(25,25,25);font-family:'PingFang