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