只要你想，在WebRTC視頻通話中添加從一到一百萬的用戶都是可以的。

當被要求創(chuàng)建一個群組視頻通話時，顯然，針對該項目應該選擇WebRTC技術。這幾乎是唯一的選擇，而且肯定也是性價比最好的。這時有個很大的問題：單個群組WebRTC視頻通話中可以容納多少用戶？

每周至少有一次我會被問到：WebRTC是點對點的，能否用于大型群組通話，因為這種技術可能不適合這種用例。事實上，WebRTC技術十分適合大型群組通話。

您需要做的是，將WebRTC看作一組技術構建模塊，根據具體需求進行整合和匹配，同時，WebRTC在瀏覽器中的實現也只是其中一個構建模塊。

目前，WebRTC技術中支持群組視頻通話的最常用構件是SFU（選擇性轉發(fā)單元），這是一個媒體路由器，它接收所有來自會話的參與者的媒體流，并決定傳輸路徑。

在本文中，我想要討論的是，在創(chuàng)建支持使用WebRTC的大型視頻會話的應用程序時，需要考慮的幾個方面和決策。

分析復雜性

首先，來分析一下我們用例的復雜性。

對于WebRTC，以及實時視頻通信，我們將歸結為速度和流數:

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

2、流數——單個會話的媒體流數量。

讓我們從一個例子開始。

假設你為企業(yè)提供一個群組通話服務。它可以在全球范圍內運行。人們將一起參加工作會議。你計劃將小組會議限制在4人以內。我知道你想要更多參與者，但在這個例子中我只是想讓事情變得簡單明了。

上面的插圖顯示了4人參與會議的示意圖，4個人多對多的推流和拉流就形成了魔方矩陣方式的推拉流關系（布局）。

魔方矩陣方式：720p

如果你希望這個視頻會議是魔方矩陣式的布局，我們的討論如下:

你想要高質量的視頻。這就是每個人都想要的。因此，針對WQHD顯示器（即2560×1440），你計劃讓所有參與者發(fā)送分辨率為720p的視頻。它消耗了1.5Mbps(這里我很吝嗇，它可能需要更多)，所以:

會話中的每個參與者發(fā)送1.5Mbps，接收3個1.5Mbps的流

在4個參與者中，媒體服務器需要接收6Mbps并發(fā)送18Mbps的數據。

總結在一張簡單的表格中，我們得到：

魔方矩陣方式：VGA

如果您對分辨率不太感興趣，可以針對VGA分辨率，甚至將比特率限制600Kbps：

以VGA標準傳輸視頻時，需要避免的事情是在顯示器上提高分辨率 - 因為看起來會很難看，特別是在較大的4K顯示器上。

即使在餐巾紙上粗略地計算，可以得出，一個分辨率為720P的視頻會議消耗的帶寬大概相當于3個VGA會議。

Hangouts方式

但是如果我們的布局有點不同呢？像圖示有主要演講者和以較小窗口出現的其他參與者：

我稱之為Hangouts方式，因為Hangouts以這種布局而聞名，并且屬于第一批專門使用這種方式而不提供更多額外的布局。

這一次，我們將使用聯播的方式（simulcast），并計劃讓每個人都發(fā)送高質量的視頻，SFU決定使用哪個輸入流作為主要的發(fā)言人并為其選擇更高的分辨率，而其他參會者則選擇較低的分辨率。

經過幾次實驗后，發(fā)現將較低分辨率的視頻縮放到較大顯示器時看起來不太好，所以你決定選取720p。你最終得到如下結果：

.會話中的每個參與者發(fā)送2.2Mbps（對于720p的視頻流，這是1.5Mbps，對于其他聯播的參與者會有額外80Kbps）

.會話中的每個參與者從占主導地位的發(fā)言者接收到1.5Mbps的數據，同時還有來自于較小窗口的兩個~300Mbps的輸入數據流

.在4名參與者中，媒體服務器需要接收8.8Mbps并發(fā)送8.4Mbps的視頻流

這里我們可以學到：

不同的用例中，具有相同用戶數量的群組視頻，在媒體服務器上會轉換為不同的負載。

如果沒有特別提到，聯播（simulcast）的效果是最好的，它提高了群組呼叫的效率和質量（聯播是我們在Hangouts方式的視頻會議中使用的）。

在我們描述的用于4路視頻通話的3種場景中，我們得到了在SFU上3組的不同數據：

在WebRTC呼叫中有多少用戶處于活躍狀態(tài)？

這是個棘手的問題。

如果你使用的是MCU，在MCU可以處理的前提下，呼叫數量可以盡可能多。

如果您使用的是SFU，則取決于3個不同的參數：

1. 媒體服務器的復雜程度以及它的性能

2. 在客戶端設備上可用的資源

3. 構建基礎架構和實現級聯的方式

我們很快會回顧這些。

同樣的場景，不同的實現

在單次呼叫中，當用戶達到8-10個時，情況會變得復雜。這里我想分享一個公共服務（產品）的例子。

場景如下：

.在魔方矩陣方式布局中單次會議有9名參與者

.使用testRTC進入會話，實現全自動化

.因為是demo，在運行一分鐘之后進程會自動結束

.考慮到屏幕上有9個人，所以將所有人的分辨率降低到VGA，并分配1.3Mbps

.導致瀏覽器將接收10Mbps的數據進行處理

在這里媒體服務器會決定如何限制和測量流量。

這里是另一個demo，進行的是完全相同場景：

現在每個瀏覽器的平均傳入速率僅為2.7Mbps，幾乎是其他服務的四分之一。

同樣的場景，不同的實現。

對于主流應用產品又如何？

基于SFU模型的視頻會議，市面上的一些主流應用產品又如何？他們的應用程序中關于參會者規(guī)模有什么樣的限制？

以下是我從網上搜集到的內容：

.Google Hangouts - 一次會議中最多有25位參與者，過去是最多容納10個人。當我第一次也是唯一一次使用它進行WebRTC培訓時，參會者人數一超過10人就卡死了，導致了我只能選擇使用其他視頻會議服務。

.Hangouts Meet - 在單個會話中將其參與者人數限制在50人以內

.Houseparty - 8名參與者

.Skype - 25名參與者

.appear.in - 使用專業(yè)帳戶登錄，單個房間內最多支持12個參與者

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

.Atlassian Stride and Meet Jitsi - 50位參與者

這是否意味著不能超過50個參與者？

我認為隨著會議規(guī)模的增加，難度越來越大：

CPaas對尺寸的限制

當您查看CPaaS平臺時，那些支持視頻和群組呼叫的服務通常會限制其會議規(guī)模。在大多數情況下，他們會給出一個他們測試過的或適合的參會者人數。正如我們所看到的那樣，這個參會者人數適用于一個非常具體的場景，但很可能不是你要滿足的場景需求。

在CPaaS中，在單個會話中，這些數字在從10位到100位參與者不等。通常情況下，如果超過給定的參會者人數，則超過指定數目的參與者只能觀看而不能發(fā)言。

要記住的關鍵點

需要記住的幾件事：

.群組規(guī)模越大，實施和優(yōu)化的復雜性就越高

.瀏覽器需要運行多個解碼器，這本身就是一種負擔

.在這種情況下，移動設備，特別是舊設備，可能很快就會癱倒。在確定要支持的會議人數規(guī)模之前，測試你計劃支持中的最老式，最小型的設備

.您可以構建SFU，使其不會將所有傳入的媒體流路由到每個人，而是選擇部分數據發(fā)送出去。例如，音頻通道上只傳送一個發(fā)言人的音頻數據，或者4個最重要的發(fā)言人的音頻數據

調整您的媒體服務器

調整大小和媒體服務器是我最近在testRTC上做的事情。過去我們曾經和Kurento合作過一段時間，并正在計劃修補其他媒體服務器。我參與的每個項目中都會遇到這個問題：

在單個媒體服務器中，我們最多可以添加多少會話/用戶/流？

根據我們上面看到的關于速度和流數的內容，最穩(wěn)妥的回答應該是：這很大程度上取決于你在實現什么業(yè)務。

如果你需要的是每個人都處于活躍狀態(tài)的群組呼叫，你應該選取在一臺服務器上容納100-500名參與者的方案。這些數字會根據你為媒體服務器選擇的計算機以及每個數據流平均計劃的比特率而有所不同。

如果你需要的是一個單主播對多觀眾的聯播，使用WebRTC是為了維持低延遲，200-1,000是較理想的估計規(guī)模，甚至可能更多。

大型機器還是小型機器？

你需要解決的另一件事是，要選擇哪臺計算機來托管你的媒體服務器。是選擇性能較差的大機器，還是體驗良好的小機器呢？

使用大型機器意味著你可以在一個服務器中添加更多的觀眾，這樣服務的復雜性就會降低。但是如果發(fā)生崩潰（媒體服務器崩潰），就會有更多的用戶受到影響。當你需要升級你的媒體服務器（很顯然你會），這個過程會讓你付出更多的代價，或者變得更加復雜。

機器越大，它的內核就越多。這導致需要在多線程模式下運行媒體服務器。這意味著它們構建、調試和修復變得更加復雜。也增加更多不確定的部分。

選擇小型機器意味著你會更早地遇到規(guī)模問題，他們將需要更精細的算法和啟發(fā)式算法。在負載平衡服務時，會出現更多的極端情況。

基于流，帶寬還是CPU來確定規(guī)模？

如何確定你的媒體服務器達到了滿負載？如何決定下一個會話是否需要一臺新機器，還是放置在當前使用的媒體服務器上？如果選擇當前使用的媒體服務器，當新的參與者想要加入在此媒體服務器上正在運行的會話時，那么他們是否有足夠的空間？

這些問題不容易回答。

通常有3種不同的度量標準，用于決定何時從單個媒體服務器擴展到其他服務器。具體如下：

基于CPU?- 當CPU達到一定的百分比時，意味著機器是“滿”的。當你使用較小的機器時，它的效果最好，因為CPU是你消耗的第一個資源。

基于帶寬?- SFU消耗了大量網絡資源。如果你使用的是更大的機器，你可能不會達到CPU的極限，但是最終會消耗太多的帶寬。所以最終將通過帶寬監(jiān)控來決定可用的容量。

基于數據流?- 有時基于CPU和帶寬的挑戰(zhàn)在于，根據動態(tài)條件，可支持的會話和數據流的數量可能會有所不同。通過策略調整可能也無法應對這種情況，所以可能需要更多的計算。這將導致無論是基于CPU還是帶寬來調整計算機的大小，都需要根據服務器可支持的數據流數量制定規(guī)則。

這里面臨的挑戰(zhàn)是，無論你選擇哪種方案，確定規(guī)模都是需要獨自完成的。我看到，在需要解決這個問題時，很多人會選擇使用testRTC。

級聯單個會話

級聯是將一個媒體服務器連接到另一個媒體服務器的過程。如圖所示：

我們有一個4路組視頻電話，分布在3個不同的媒體服務器上。服務器根據需要在它們之間建立連接。為什么要做這個？

＃1 - 地理分布

當將SFU作為其中一部分并在全球范圍中提供服務時，立即引發(fā)的問題是在進行新的會話時，您將為其分配哪個SFU？在哪些數據中心？由于我們希望讓媒體服務器盡可能靠近用戶，因此我們要么提前知道有關會話的信息并根據這決定將其分配到哪里，要么通過合理的方式來決定，比如地理定位 - 我們選擇在離用戶最近的數據中心創(chuàng)建會議。

假設4人正在通話。其中3人來自紐約，而第4個人來自法國。但是如果是這個法國人最先加入到這個通話中，那么會發(fā)生什么？

結果是該服務器將會在法國托管。4人中有3人將遠離媒體服務器。顯然這不是最好的方法...

一種解決方案是，通過距離參與者最近的服務器之間進行傳播的方式來進行會議：

我們使用更多的服務器資源來獲取此會話，但我們對媒體路由有更多的控制權，所以我們可以更好地優(yōu)化它們。這提高了會議的媒體質量。

＃2 - 碎片分配

假設我們可以在單個媒體服務器上連接多達100個參與者。此外，每次會議最多可容納10人。理想情況下，我們不希望為每個媒體服務器分配超過10次會議。

但是如果我告訴你會議的平均規(guī)模是2人呢？那么我們將得到這樣的分配:

這會導致服務器資源的大量浪費。我們該如何解決這個問題？

1. 通過預設人數達到最大會議規(guī)模。但這不是真正需要做的事情

2. 冒一個風險，假設你分配了50%的服務器容量，那么剩余的容量則是留給現有的會議以應對參會人數的增長。雖然仍然是在浪費資源，但程度較低。由于服務器資源的限制，我們可能無法應對會議中可能出現的邊緣情況

3. 通過跨媒體服務器遷移會話對服務器進行“碎片整理”。這聽起來不太有友好，而且可能會擾亂用戶。

4. 級聯會話。允許跨機器的規(guī)模增長

最后一個級聯中，您可以通過預留部分媒體服務器的資源，來實現將現有會話級聯到其他媒體服務器的目的。

＃3 - 更大的會議

假設您想創(chuàng)建比單個媒體服務器能夠處理的更大型會議，那么唯一的選擇就是級聯。

如果您的媒體服務器可以容納100名參與者，但是您希望參加規(guī)模為5000名的會議，那么您需要通過級聯以支持他們。但這并不容易，這就解釋了為什么沒有很多這樣的解決方案可以用，但這是可能實現的。

請注意，在這樣的大型會議上，媒體流不會是雙向的。在會議中，發(fā)送媒體流的參與者比較少，絕大部分的參與者都只是接收媒體流。關于純粹的聯播場景，在Red5 Pro博客上我寫了一篇關于的縮放挑戰(zhàn)的文章。

概括

本文中我們觸及了很多領域。在嘗試確定在WebRTC視頻通話中能夠有多少用戶時，應該做的是：

1. 無論會議是什么規(guī)模，都能使用WebRTC支持實現

1.1. 這是一個成本問題，并與商業(yè)模式保持一致，這將決定或打破這一模式。

1.2. 會議規(guī)模越大，實現的方式就會越復雜，同時需要更多的限制和假設

2. 分析你需要支持的復雜性

2.1. 統(tǒng)計每個設備和媒體服務器的傳入和傳出流

2.2. 決定每個流的視頻質量（分辨率和比特率）

3. 定義將使用的媒體服務器

3.1. 選擇一種機器類型以運行媒體服務器

3.2. 在擴展之前計算出所需的規(guī)模

3.3. 檢查服務器資源上的增長是否是線性的

3.4. 決定是否基于帶寬，CPU，流數或其他進行擴展

4. 圖示的級聯該如何實現

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