选择开源 WebRTC 媒体服务器架构的十二条建议

选择开源 WebRTC 媒体服务器架构的十二条建议

$太多的开源媒体服务器开源项目，到底哪一个适合您呢$

您有在 github 上搜索您需要的 WebRTC 相关资料的经历吗？之前的资料特别少，可是今天您再去搜一下，上面关于 WebRTC 的资料就和现在 WebRTC 在 LinkedIn 上面的简介一样多，下面这幅图是 WebRTC 这几年来在 github 上使用的走势图

从开源项目的一些仓库使用的案例来看，有的使用量确实非常之高，下面这幅图是我搜索 github 之后的一些例子

当您在 github 上搜索 WebRTC，并让它默认为您选择最佳匹配时，您会得到 PubNub 的列子，使用 PubNub 作为您使用 WebRTC 进行简单的一对一视频通话的信令。有趣的是，它已经不能再继续工作了。因为它使用了旧的 PubNub WebRTC SDK，这是一个不需要您花太多精力的领域(发送信令)。

假设您确实找到了一个您喜欢的 WebRTC 开源媒体服务器(当然是在 github 上)。您怎么知道它有什么好处? 这里有 10 种不同的建议，您可以用来参考一下做出好的选择。

您是否理解代码

如果您打算为 WebRTC 项目采用开源媒体服务器，那么需要每隔一段时间就深入研究一下该项目的 WebRTC 业务相关代码。

有几件事情您必须要做，第一让这个该死的媒体服务器运行起来，修复其中的 BUG、调整设置、修改其中的插件或者扩展以及为媒体服务器改名。

在我看到的许多情况下，当供应商依赖于一个开源的 WebRTC 媒体服务器框架时，他们最终不得不深入挖掘它的代码，有时甚至达到完全拥有它的程度，并完全改变项目的结构。

为了确保您做出了正确的决定 —— 首先检查一下您是否理解了自己要做的事情，并尝试先研究一下代码。

我自己的个人偏好是代码中包含注释，不能脱离代码按自己的想法理解。所以一定要检查那些不明显的部分(比如带宽估计，RTP 处理，STUN 或者 TURN 协议处理) 是否正确注释了。

代码是否持续维护

苹果也是最近几年才开始在浏览器中启用 WebRTC，SDK 中的 WKWebView 目前还在内测中，暂时不能使用，当然了我们还是非常高兴的。

但现在我们都需要将焦点转移到 H.264 上。包括您计划使用的 WebRTC 媒体服务器。
谷歌呢? 他们刚刚宣布将缓慢地从 PlanB 迁移到 UnifiedPlan。不要担心细节 —— 它只是改变了处理多个流的方式。

自从 WebRTC 的规范草案最终确定了正确的定义以来，getstats() API最近发生了很多次变化，这与它的 Chrome 实现不同。

实际问题呢？一两年前编写的代码在实际运行时存在严重的问题，甚至不谈论升级、更新、安全补丁等等。只是基本的一个能让它工作的东西。

当您检查您计划采用的 WebRTC 媒体服务器的 github 页面时，请确保查看它最后一次更新的时间。如果您检查更新是关于什么的以及更新发生的频率，就会得到额外的参考标准。

有人使用吗

没有什么比犯别人正在犯的同样的错误更好的了。(错误描述)

您想要的是一个流行的开源 WebRTC 媒体服务器。任何其他的东西都有它存在的理由，而这个理由不会是您发现了一颗未经雕琢的钻石。

使用流行的框架，一个是久经考验的，最好是名人使用，在生产环境中，在商业产品中，这些都是是参考标准

为什么？因为他给了您需要的两件事

1. 验证和有效性
2. 生态

它会让您确认这个东西是有价值的 —— 其他人已经用过它了。

它给您一个知识和经验的生态系统（因为有很多人使用，很多相关的示例和文档）。有时可以利用这一点来找到一些已经使用过它的自由职业者，或者从社区中更多的人那里获得帮助，我不会仅仅根据流行程度来选择一个平台，但我会将它作为一个强有力的参考标准。

该项目有文档吗

WebRTC 的媒体框架就像一个引擎，需要将其集成到您整个项目中。要实现这一点，您需要以某种方式与它集成 —— 或者通过它的 api，或者通过 REST api(或者GraphQL，等等)。

要做到这一点，您需要知道哪些 API 接口是适合您的，哪些不适合，比如那些写出来的东西或者文档。

当涉及到开放源码框架时，文档并不能保证具有特定的质量 —— 它会因项目的不同而有很大的差异，只要确保您所使用的文档达到了可以理解的程度就可以了。

如果可能，请检查文件是否包括:

1. 一些介绍性材料的组成和架构的项目说明
2. 一些 API 参考示例
3. 一些演示如何使用这个东西的例子
4. 一些关于安装，配置，维护，可扩展文档，…

文档越多，一年之后您的情况就越好。

它是否是 Debuggable 的

WebRTC是实时的，实时很难调试。

如果您需要关注的不是信号部分(或者音视频信令部分)，而是媒体部分，那就更难了。

我知道您只是喜欢在 c++ 代码中添加您自己的 printf 和 cout 语句，并尝试复现那个烦人的 bug。更有圣者，收集 PCAP （TCP Dump）文件，然后……呃……阅读它们（估计您会疯的）。

如果能够提供一些日志记录、调试等功能，而不必总是将这些语句添加到代码中，那就太好了。甚至可能有一个具有不同日志级别的机制，并在日志中写入合理的信息，这样就可以减少查找 bug 所需的时间。

另外，要确保将监控系统集成到您将要使用的媒体服务器中是非常方便的。如果在生产中没有简单的方法来测试这个东西的健康状况，那么它要么没有在生产中使用，要么需要进行一些修改才能实现。我想您应该不想陷入那种困境。

同时 —— 确保代码本身有良好的文档记录。没有什么比自我解释的代码概念更令人沮丧(也更愚蠢)了。人 —— 代码不能解释它自己 —— 自己做自己的事情。我知道那个写媒体服务器的人是上帝的化身，但我们其他人不是。您们的程序员很优秀，但是相信我 —— 不是那么好。选择一些易于维护 —— 这是不言自明的，因为有人花时间在代码的棘手部分写了一些非常好的注释，我知道这也是摸索代码的一部分，但它很重要 —— 检查两次。

对我来说，更快地调试、排除故障和发现问题的能力通常对我自己的业务至关重要。

是否易于服务横向扩展

媒体服务器占用了大量的资源，比如内存、CPU、带宽（甚至是 GPU）

这意味着，如果您的业务以任何方式获得成功，您将需要更多的媒体服务器来规模化运行。

您可以从在亚马逊 AWS 上搜索一下从 m4.large 到 m4.16xlarge（这是机器名称哦）看看您就知道了那是多么昂贵了。最终，媒体服务器的横向扩展归结为增加更多的机器，这很好理解，直到您开始使用群组音视频通话时您就明白了

下面是一个列子

1. 假设一台机器可以处理 100 个参与者，可以分成任何类型的测试小组(这里只是一个简化)
2. 每一个音视频电话平均有 10 个参与者
3. 每组呼叫可以有2个参与者，最多 50 个参与者

现在我们考虑一下如何横向扩展我们的音视频服务能力呢?

我们需要投入多少台机器? 我们什么时候决定不向正在运行的机器增加新的音视频呼叫进入? 这些机器人员都满了，我们要把它们级联起来吗? 丢掉该音视频的呼入并尝试将它们转移到其他机器上?

我不知道，但您应该知道。至少您是认真对待您的产品的。

您可能无法在开源 WebRTC 媒体服务器的文档中找到这个问题的答案，但至少应该确保您有一些关于如何大规模运用和部署它的合理文档，而不是作为一次性实例。

该媒体服务器使用什么语言开发的

他们是用 Kotlin 写的哦。因为这是有史以来最伟大的语言，谷歌甚至将其成立为 Android 的官方版本。

如果我们使用 Kotlin 开发媒体服务器有问题吗？我在使用的语言中寻找两件事:

1. 音视频媒体服务最终的结果都是支持高性能的音视频接入，记住，我们在这里要处理的是一个资源浪费的问题，所有我们要考虑得长远一点，一个词：优化
2. 我必须知道如何使用它，并且我的开发人员也要必须精通此事

其中有一些媒体服务器是基于 Node.js 的，而另一些是用 Java 编写的。您的开发人员更喜欢哪一个? 哪一个更适合您公司未来 5 年的技术计划?

如果您需要在两个媒体服务器之间做出选择，而它们之间的主要区别在于语言，那么选择对您的组织更有效的语言。

它是否符合您的信令模式

您的 WebRTC 产品需要三样东西:

1. 信令服务
2. STUN/TURN 服务
3. 媒体服务器

第三条不是强制性的，但如果您正在读这篇文章，它是强制性的。该媒体服务器需要与信令服务器和 STUN/TURN 服务器交互。

当然，您可以使用媒体服务器的信令功能，但它们并不是真正的信令功能，我的建议是不要将媒体服务器公开用于任何事情 —— 在您的服务中对其进行内部控制。

因此，您需要让它与您的信令服务器进行交互。检查它们是否共享相似的范例和概念，否则，这本身就是一件很头疼和混乱的事情，否则调试测试时您会疯掉的。

检查一下您要选择的媒体服务器架构是否有很容易集成的 STUN/TURN 开源服务器供您选择

开源许可证对您合适吗

BSD? MIT? APL? GPL? AGPL?

这个开源的 WebRTC 媒体服务器框架到底附带什么许可证?

有趣的是，有些项目在这个过程中会转换它们的许可证。Jitsi 是在被 Atlassian 收购之后这么做的 —— 从 LGPL 转移到一个更宽松的 APL。

您的业务模式的方式，以及您计划部署服务的方式将会影响您想要的开源许可的类型，并将能够在您的服务中采用。

$当涉及到开源许可时，有不同类型的免费。$

您挑选和使用的每段代码都需要遵守这些许可证内部要求和约束，这也包括媒体服务器本身。既然媒体服务器不像一个用过的电池那样可以随时更换，我的建议是选择一个带有开放源码许可的东西 —— 或者选择一个商业产品(它会让您付出代价，但会解决这个烦人的问题)。

我以前写过关于开放源码许可的文章——也可以去看看。

有人为此提供付费支持吗

我知道，您使用开源来避免支付任何费用。然而，如果您查看许多成功且维护良好的开源项目 —— 特别是中小型项目，您将看到它们背后的业务模式。为那些在 IT 上投入时间的人提供了一种谋生的方式。在许多情况下，业务模型是支持和定制开发的。

选择付费支持意味着两件事:

1. 有些人愿意承担责任并改进这件事，他把它当作日常工作来做，而不是当作业余爱好
2. 如果您需要帮助尽快 —— 您可以随时支付得到它

如果没有人提供任何付费支持，那么谁来维护这些代码，目的是什么? 怎样才能鼓励他们继续投入时间开发呢? 他们会在下个月决定停止投入开发吗? 上个月吗? 明年吗?

现在流行开源媒体服务器预览

Jitsi Platform
Jitsi不仅是WebRTC媒体服务器，而且还有一个完整的平台。 Jitsi系列产品包括Jitsi Videobridge（媒体中继，SFU），Jitsi Meet（会议网络客户端），Jicofo（Jitsi Conference Focus），Jigasi（Jitsi Gateway to SIP）和Jitsi SIP Phone。借助Jitsi我们能在几个小时之内迅速搭建一个完整可用的通信平台。 它还使用Jingle（XMPP）和功能齐全的Web界面实现自己的信令控制。 然而，令人遗憾的是，它对于媒体录制没有提供稳定易用的解决方案。

Kurento Media Server
这是最通用的解决方案之一。 它不仅是一个媒体服务器，而且是一个开发工具包。Kurento的主要优势在于其多功能性，引入了媒体工作流的概念，允许在代码中定义媒体流的方式和位置。 这允许WebRTC开发者组合和集成非常有趣的特征，例如增强现实，AR计算机视觉（例如识别QR码，面部检测），实时媒体修改和与RTP（VoIP）服务互操作。Kurento可以配置为SFU或MCU，或两者兼备。

Janus WebRTC Gateway
虽然它的描述在任何地方都没有提到“媒体服务器”，但Janus可以很容易地设置为SFU。 其最显着的特征之一是其插件架构，可以增强服务的核心功能。有一些有趣的Janus用例，例如SIP Gateway，屏幕共享等。

mediasoup
这是一个相对较新而且有趣的媒体服务器，它与其他媒体服务器的不同之处在于它被设计成一个用于Node的开发库，这允许它可以被容易的集成到更大的应用程序中。

licode
底层基于 c++ 进行开发，内部使用 WebRTC 部分 P2P 源码，健壮性比较强，信令和业务控制通过 nodejs 做桥接方便调用，使用方便，结构设计合理

做出决定

考虑需求和约束，理解总是存在未知和部分信息。然后从中提炼出一个决定，决定性的选择。

在 Gustavo Garcia 编写的这个伟大的汇编中，您可以找到更多关于媒体服务器的技术信息。