Introduction

可以将WebRTC系统体系结构大致分为两种类型：

不中断加密访问的媒体

• p2p架构
• 使用TURN服务器
• [未来支持PERC]

其他

• MCU
• SFU

像往常一样，选择最好的解决方案在很大程度上取决于应用场景，没有一个架构被认为是最好的。

主要的媒体服务器（按字母顺序）

汇总表

大部分内容遵循的是这个表中总结的。 请务必阅读右侧的评论。

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个音频+视频通量。 另外，（这是我自己的意见）如果沟通不是双向的，或者如果你没有渲染所有的视频流，你可以处理更多的媒体。