WebRTC媒體伺服器

05-09

本文介紹了WebRTC解決方案中使用MCU和SFU模式的媒體伺服器（截至2016年9月）。我希望它能夠成為那些想更多地了解概念並快速開始項目的用戶參考文章。這裡每個產品的詳細信息都沒有提供，但它們的鏈接都在這兒。如果您願意的話，您可以進一步閱讀。而且，我幾乎只提到獨立的媒體伺服器，並沒有觸及WebRTC CPaas 或 PaaS。

Introduction

可以將WebRTC系統體系結構大致分為兩種類型：

不中斷加密訪問的媒體

p2p架構
使用TURN伺服器
[未來支持PERC]

其他

像往常一樣，選擇最好的解決方案在很大程度上取決於應用場景，沒有一個架構被認為是最好的。

主要的媒體伺服器（按字母順序）

匯總表

大部分內容遵循的是這個表中總結的。請務必閱讀右側的評論。

Intel Collaboration Suite for WebRTC

包括客戶端SDK（JS/Android/iOS / Windows），伺服器SDK（SFU/MCU/SIP網關）。它提供了幾乎所有你想要的東西。 MCU/SFU不是從頭開始開發，而是基於Licode的。

順便說一句，最近它被提及作為intel和韓國電信運營商巨頭SK電訊合作的核心技術。

Janus

Janus核心是WebRTC的「gateway」，它是用C語言實現並且是在libsrtp和libnice之上開發的（實現SRTP和ICE協議也被Google和mozilla使用）。通過添加各種插件，可以實現不同的功能或用例，例如SFU。正如我在前一篇文章中所寫的，它已經在Slack中使用了。許可證最初是AGPL，但是在Alex和Oleg（CoTurn的創建者）討論後，更改為GPLv3。

Jitsi VideoBridge

被Atlassian收購，它是一個用Java編寫的SFU。 Atlassian允許該項目保持開放源代碼（即使他們更改了許可證），並且開發仍在繼續。從一開始，Jitsi一直使用XMPP（與客戶端）進行信號傳輸，並使用自己的XMPP擴展：Colibri與信令伺服器進行交換。它還提供了一個REST API。

整個團隊非常接近IETF標準和瀏覽器。這是實現同步聯播最快（也許是目前唯一的）。 Jitsi的前任首席執行官兼創始人兼視頻橋技術負責人Emil也是Trickle ICE的作者。

雖然 Atlassian 在他們的產品中使用它，但是像http://talky.io/這樣的其他公司已經將它用於不同的場景。

Kurento

最初設計為MCU，Kurento本身是用C++實現的。有JS / Node /和Java的SDK。開發人員可以使用SDK操作Kurento。有使用Node.js（Kurento + WebRTC + Node.js）管理Kurento媒體伺服器非常詳細的文檔和代碼。目前，它也可以作為SFU模式。

[Alex Note]：2016年9月20日由twilio收購。

還有一個基於Kurento的被稱為NUBOMEDIA的託管服務，那些不想在自己的伺服器上運行的人可以使用那個或者彈性的RTC。

Licode

雖然它只是最初的MCU，但它現在也可以使用SFU模式工作。 Licode本身是用C++實現的。如上所述，INTEL已將其用作其媒體伺服器邏輯的基礎。

參考：https：//www.terena.org/activities/tf-webrtc/meeting1/slides/Lynckia.pdf

Meedooze

該項目比其他項目稍舊，沒有github存儲庫，但只有源代碼庫。

MediaSoup

據我所知，這是最新的webRTC SFU項目。核心是用C語言（使用例如libuv）實現的。其餘的代碼是使用最多的JavaScript（ECMAScript 6）。有很多未實現的webrtc功能，根據Twitter的帖子，媒體運行良好。有趣的是，它可以使用JavaScript處理RTP包。

PowerMedia XMS

Dialogic開發，它是一個商業媒體伺服器。固定的布局是痛苦的，但是從RFC5707來的是一個歷史問題。如果你已經實現了對RFC5707的支持，你可以控制它。值得注意的是，在日本，軟銀公司正在使用它作大規模的安裝。

SORA

與其他SFU不同的是，除了作為視頻路由器之外，還實現了資源優化功能（通過快照）以及許多其他獨特功能。請參閱Shiguredo WebRTC SFU Sora開發日誌以獲取其他高級功能。

結論

雖然這篇文章是關於媒體伺服器的，但是我認為WebRTC通過媒體伺服器來實現通信是很好的，當然也有不通過媒體伺服器（P2P / TURN）的通信形式。

P2P（又名：full mesh）的問題在於，它在客戶端不能很好地擴展，即給定對話中的人數是有限的。按照Philipp Hancke先生的說法，如果你巧妙地實現了這個功能，你應該能夠在普通的PC上處理大約8個音頻+視頻通量。另外，（這是我自己的意見）如果溝通不是雙向的，或者如果你沒有渲染所有的視頻流，你可以處理更多的媒體。