首发于WebRTC
WebRTC媒体服务器

WebRTC媒体服务器

本文介绍了WebRTC解决方案中使用MCU和SFU模式的媒体服务器(截至2016年9月)。 我希望它能够成为那些想更多地了解概念并快速开始项目的用户参考文章。 这里每个产品的详细信息都没有提供,但它们的链接都在这儿。如果您愿意的话,您可以进一步阅读。 而且,我几乎只提到独立的媒体服务器,并没有触及WebRTC CPaas 或 PaaS。

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 在他们的产品中使用它,但是像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:terena.org/activities/t

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

发布于 2018-02-05

文章被以下专栏收录