基於webrtc多人音視訊的研究

眾所周知，WebRTC非常適合點對點（即一對一）的音視訊會話。然而，當我們的客戶要求超越一對一，即一對多、多對一設定多對多的解決方案或者服務，那麼問題就來了：“我們應該採用什麼樣的架構？” 。簡單的呢有人會考慮copy多個p2p就完成了多人之間的會話，可並沒有考慮到到來的問題：cpu、記憶體、尤其是流量問題；傳統的解決方案是MCU伺服器，利用伺服器硬體的能力去mix音視訊，然後傳給各個參與者，這能到達預想的，這個亦能到達我們的需求；使用基於網狀拓撲結構的結構可能是前兩者的折中之選。

儘管能實現WebRTC多人音視訊的方案，該技術的最流行的用途不侷限於多方視訊會議場景。不要以為只是傳統的音視訊會議室，更多的情況包括：智慧硬體、ipcamera、線上課堂，實時直播等。在每一種情況下，伺服器的能力是能夠從多個源的媒體流分發到多個客戶端。所以...如果你是一個服務供應商如何才能在實現支援WebRTC的多方拓撲結構？

有幾種不同的架構根據您的要求，可能是合適的。這些架構基本上他們圍繞二點：

§ 集中VS對等網路（P2P）

§ 混合VS路由。

我將在這裡介紹最流行的解決方案。如果你需要去深入到協議的影響和實施細則的架構，你可以找到所有的相關資訊，RTP拓撲IETF文件。

Mesh解決方案

Mesh方法是最簡單的解決方案。因為它不需要假設任何伺服器，而且直接使用成熟的WebRTC傳輸方案。該體系結構基於從每一個傳送者建立多個一對一的資料流到每一個接收端。

Mesh解決方案

即使它看起來像一個低效的解決方案，在實踐中是非常有效的，並且延遲最低，每個接收端都會根據實際情況產生不同的位元率。

唯一的問題是，這種解決方案需要大量的上行頻寬將媒體流同時傳送至所有目的地，現有的裝置實現所需的CPU功率會顯著上升。

Mixer解決方案

Mixer的做法是多人視訊會議的傳統解決方案，並且使用多年取得了巨大成功。這一成功可以歸功於它需要客戶端更少消耗這一事實。該架構基於具有中心點保持與每個參與者一對一的流的特性。中心元件接收並混合每個傳入的音訊流和視訊流，以合成一個單一的流出到每一個參加者。在視訊會議行業對於這些集中元件的一個常見術語是多點控制單元（MCU）。在實踐中，使用一個MCU的通常是指一個混合器容器。

Mixer解決方案

混頻器是供傳統裝置操作間很好的解決方案。它們還允許全位速率適配，因為混頻器可以產生不同的輸出流，所以每個接收器有不同的品質。混合器解決方案的另一個優點是它可以利用硬體裝置編解碼。

主要缺點是在MCU的基礎設施成本高。此外，由於混合需要解碼和再編碼，這引入額外的延遲和質量的損失。最後，轉碼和組合物可在理論上導致對應用程式的使用者介面的彈性較小（儘管有此問題的解決方法）。

Router解決方案

Router（或中繼）的辦法使得H.264 SVC基礎設施普及，這也正是廣泛應用的。該架構基於具有中心點從每個傳送器接收一個流併發送出一個流到每一個參與者。這個中心點只做資料包檢測和轉發，而不是昂貴的編碼和實際的媒體的解碼。常見術語是SFU。

Router解決方案

Router提供一個便宜的可擴充套件的多方傳輸，具有較好的延遲性、與傳統的mixer解決方案相比沒有質量劣化。

這種方案非常適合大併發的事實會議和直播。目前較成熟的服務提供商就是聲網

來一張各個解決方案的流量圖？

我應該使用哪種架構？

這個就需要根據自己的專案的需要了。其實，商業解決方案，包括上述所有方案，往往需要根據客戶的實際應用場景選擇對於的方法。不過，也有經驗，你可以使用一些通用規則。

1、如果您僅是提供P2P音視訊傳輸的服務，Mesh架構可能是最適合你的。另外，如果基礎設施的成本不是問題，並且參與者具有異構連線，這可以是一個很好的解決方案。

2、假設你提供企業級服務，且有較好的寬頻和高效的硬體（即一個企業內部服務），參加人數是有限的，那麼你非常適合Mixer方案。

3、一般來說，如果你提供大規模服務的，應優先考慮到Router的方法。Router傳輸接近把情報在網路的邊界，構建終端使用者應用程式時，以達到更好的可擴充套件性和靈活性的網路的範例。