---

作者：Tsahi Levent-Levi、Philipp Hancke

翻译、编辑：Alex

技术审校：李忠

影音探索 #018#

WebRTC的开源环境混乱不堪。它需要成熟起来并成为重要的业务，或者获得重要的支持。

本篇文章由我和Philipp Hancke[1]共同创作。我们一起合作了很多事，包括WebRTC课程[2]（新课马上要来了）和WebRTC洞察[3]等等。

WebRTC是免费的。今天，每个现代浏览器都包含了WebRTC。在这些浏览器中运行的基础代码不仅开源且使用宽松的BSD许可证。在某种程度上，免费和开源被融合在一个不那么愉快的组合中，而开发者以为WebRTC中的一切都应该免费。

结果呢？在WebRTC推出11年之后，我们发现它的处境悲惨。在今天这篇文章中，我们会详述WebRTC开源生态的现状，以及我们为什么需要做出必要的改变以确保WebRTC在未来几年能够健康发展。

你的开源辅导笔记

我们将从你所需要了解的最重要的事情开始：

开源 !=免费

在深入研究之前，先让我们快速了解一下开源。

到底什么是开源？

开源项目是指在开源许可协议的规定下，一段被大众公开使用的源代码。来自同一家公司或者不同公司的某个人或者某个团队“联合起来”开发了一个发挥某种作用的软件。他们将该软件的源代码公开，并贴上许可证，这就成了一个开源项目。

开源并不等于免费。开源同样要在法律约束下进行，但这并不是本文的重点。实际上，使用开源并不是说你无需向任何人支付任何费用，它意味着不需要任何附加条件，你就可以获得代码。

为什么大家最终都愿意为开源项目无偿贡献代码？这就要从开源项目的商业模式说起。

开源商业模式

目前存在多种形式的开源许可证[4]。每种开源许可证都有自身的规则，其中一些相对更宽松，对商业更加友好。有时许可证类型本身也会被用作商业模式，它通过双重许可模式实现：一个免费但有限制条款的开源许可协议，同时提供一个商业许可协议。

在其他情况中，开源项目的商业模式围绕提供项目支持、维护和定制项目。你可以免费获得代码，但如果你需要帮助，你可以通过付费获得支持。

有时，商业模式还围绕着附加组件（比如，社区版和企业版在项目网页作为选项弹出）。用于扩展系统的脚本、监测模块或者其他操作和模块组件等作为商业产品受到保护。项目的开源部分使各家公司能够使用它，并提升了项目的知名度，而商业部分是开放开源部分的原因。开发者以此为生甚至发家致富。

近些年，我们看到一些围绕着托管服务的商业模式，其中的代码库开源且免费，但如果你让这些公司帮你托管并支付费用，那么他们将为你解决所有维护和扩展问题。

有些人认为开源是真正免费的。Troy Hunt最近写了一篇很棒的文章，你可以在这里阅读：https://www.troyhunt.com/if-youre-not-paying-for-the-product-you-are-possibly-just-consuming-goodwill-for-free/

“有一个建议是：我们这些开发软件和服务的人必须以某种方式获得收入。”

对此我想说的是：没错！

归根结底，研究开源终为利。

为什么这么说？

• 如果你创建了一个广受欢迎的开源项目，那么你总是想搞清楚如何通过它获得收入。通过开源项目，你能直接（参见上文例子）或间接地增加获得高薪工作或者加入更加有趣项目的机会。

• 有时，研究开源是因为你对某一项技术十分感兴趣。但最终结果是一样的：或许你有时间搞开源，是因为你在其他公司可以获得收入，只是把开源当作兴趣；或许你任职的公司很高兴你去研究开源（意味着你所做的事情能够给公司带来内在价值）。

• 也许你搞开源是为了磨练技术。但话说回来，你这么做的原因还是为了成为一名更优秀的程序员……并最终被公司聘用。

如果你正在开发的项目对另外两个人或者一家公司有意义，那么就能获得金钱上的收益。我们敢说，如果你没有从这些收益中获得任何好处（即使很少），那么开源项目就没有真正的未来，它也到了生死关头。

多说几句开源项目

在开始WebRTC开源王国之旅之前，让我们先来了解一些事：

• 大部分开源项目只是一个将你的应用开发所需的某种性能抽象出来的API。在WebRTC中，我们会关注实现特定网络实体的此类抽象。我们稍后会详细介绍。

• 当使用开源时，你通常对应用程序拥有更多控制权。这是因为你可以修改开源组件的源代码，而不是在使用预编译的库时向厂商寻求帮助。

• 很多开源项目的文档都很糟糕。当它们缺乏可靠的商业模式时，更印证了这一事实：开发爱好者更喜欢写代码，而不是解释如何使用这些代码。

• 文档是开源项目商用很重要的一个方面。提供使其更易使用的清晰API外观和示例代码的能力也很重要。

WebRTC开源一览

新手的一个常见错误是：WebRTC是一种不需要编码的解决方案。既然浏览器已经实现了它，就没有其他事要做了。这与真相相去甚远。WebRTC协议需要一组移动组件、客户端和服务器；它们一起实现了我们所看到的这一丰富的通信解决方案。

上图（来自高级WebRTC架构课程[5]）显示了典型WebRTC应用中的各种必需组件。

• 客户端： 基于Web或者其他

• Web浏览器客户端作为浏览器的一部分“免费”获得

• 其他则需要你自己探索

• 应用服务器： 本文我们并不会介绍应用服务器，因为任何类型的应用都具备这一通用组件，并非WebRTC专属。

• 信令服务器： 负责设置和协商WebRTC会话。

• STUN/TURN 服务器： 处理NAT穿越。几乎所有部署都需要它。

• 媒体服务器： 用于媒体处理任务繁重的工作。无论是群组通话、录制，还是视频渲染等，你都可以使用媒体服务器。

对于每个组件，你都可以找到一个或者多个开源项目来实现它。其中一些更好用，但许多开源项目已被遗忘并逐渐弃用，而只有少数设计精妙，令人赞不绝口。

让我们深入了解这些组件，并看看其中可使用的组件以及其所对应的开源社区正处于什么样的状态。

WebRTC开源客户端库

首先是WebRTC开源客户端库，它们是WebRTC协议在用户/设备/客户端层面的实现，可以将其视为WebRTC的底层API。

WebRTC曾经只有一个库：libwebrtc。但渐渐地，更多的库被推出并在生态中占据了一席之地。

我们先从libwebrtc开始。

• libwebrtc

WebRTC中最主要的开源项目就是libwebrtc。为什么？

1. 它是第一个推出的开源项目。

2. Chrome将它用于其WebRTC实现。

3. Safari、Edge和Firefox也是如此：它们不同程度地集成和使用了libwebrtc。

4. 许多native移动应用内部使用libwebrtc。

实际上，libwebrtc在WebRTC中无处不在。

这里有几个你需要知道的关于libwebrtc的知识点。

• libwebrtc由谷歌唯一控制和维护。每个更改都需要谷歌同意。

• Chromium和Chrome都兼容了libwebrtc，意味着它可以触达几十亿部设备。

• 谷歌非常保护libwebrtc，所以向libwebrtc贡献代码并非易事。

• 虽然一直有人向libwebrtc贡献代码，但外部贡献者少之又少。

• 记住，谷歌团队之所以维护libwebrtc并不是出于公益目的，他们也是为了满足自身需求，尤其体现在这些年的Google Meet。Google Meet的用例、使用场景、API和代码流程都很可能比libwebrtc的代码库更安全、更稳定并做了深度优化。

• 值得一提的是，libwebrtc的全部构建系统是为了将其编译进Chromium而非其他项目（比如你正在构建的那一个）。想了解更多，请观看Philipp的Fosdem talk[6]。

• 它的一些接口（比如设备获取）测试比较少是因为Chrome覆盖了这些接口，所以谷歌的重点是Chrome接口，而不是libwebrtc中实现的接口。

在过去的代码贡献中，谷歌占据了其中的90%。

可以看到，在2016年初达到顶峰之后，代码修改量之后逐年减少。在疫情期间，甚至降到了低于平均每月200个commit的低点。但即使代码量不断减少，libwebrtc依然是WebRTC生态中最大以及最频繁更新的项目。

libwebrtc的外部代码贡献量相当低，不到总贡献的10%， 对于WebRTC这一行业标准库来说并不是一个好兆头。如果谷歌可以打开大门，放入一些改进WebRTC或使WebRTC更易使用的贡献代码，那么情况将会改善。

接下来我们将了解：libwebrtc的商业模式。

谈钱时刻

如果有人决定使用libwebrtc并将它直接集成到自己的应用上怎么办？

• 没有付费支持选项。

• 没有真正的替代方案为定制化开发付费。

• 维护自己的fork分支，然后和开源upstream 版本保持同步是一件成本非常高的事情。

• 因此在大部分情况中，libwebrtc是最佳选择。这是因为它准确支持你在Web浏览器中所遇到的各类实现，是最新的开源项目。

• 值得一提的是，libwebrtc是用C++实现的。有什么关系吗？我们接下来要介绍的Pion会解释这一切。

• Pion

Pion[7]是WebRTC API的Go实现。Sean DuBois[8]是Pion项目背后的核心人物，他对Pion的热情颇有感染力。

Tsahi认为，用Go来写Pion是它成功的主要原因。这只是因为相对于C++，很多开发者更愿意使用Go（现代、新颖且时髦）。不论什么原因，Pion从一开始就发展良好，现在已经成为一个流行的WebRTC开源项目。它常用于嵌入式设备、基于云的视频渲染和最近的SFU以及其他媒体服务器实现。

谈钱时刻

如果有人决定使用Pion并将它直接集成到自己的应用怎么办？

• 没有付费支持选项。

• 没有官方替代方案为定制化开发付费。

• Pion有很多代码贡献者，他们把这种贡献当作正式工作。

• Python、Rust等

WebRTC还有其他语言的实现，其中比较有名的包括：

• aiortc[9]：WebRTC的Python实现。

• WebRTC.rs[10]：WebRTC的Rust实现，作为Pion的重写（rewrite）被开发出来。

也许还有其他实现，但没有那么有名。

这里我们就不介绍谈钱时刻了。这些项目的规模太小，我们还没有看到有很多服务在生产中大规模使用它们。

• GStreamer

GStreamer[11]是一个比WebRTC还老的开源媒体框架。它应用于使用WebRTC的应用和服务中，甚至没有使用它的WebRTC能力（主要因为这些能力后面已经添加到了GStreamer中）。

我们看到，当厂商们需要进行实时的视频内容转码时，就会使用GStreamer。比如：

• 获取机器渲染（3D、投屏等）并将它们通过WebRTC传递给浏览器。

• 混合输入数据，将它们合并为单个录制文件或者单个直播流。

• 在嵌入式平台上收集媒体输入数据，并将它们准备用于WebRTC会话。

由于WebRTC是GStreamer中所添加的另一个输出类型，开发者可以直接将它作为广播实体（broadcasting entity）使用，这是一个不消耗数据只生成数据的实体。

GStreamer是社区努力的成果，并使用C编写。虽然许多应用都使用GStreamer，但它却缺乏强健的商业模式。这意味着什么？

谈钱时刻

如果有人决定使用GStreamer并将它直接集成到自己的应用怎么办？

• 具备付费支持官方选项（by Centricular）。

• 你也可以直接向Centricular支付定制化的开发费用。

• 整个生态环境的规模已经足够大，你可以很容易找到具备GStreamer知识的人。

开源TURN服务器

使用TURN连接WebRTC来转发消息

接下来是TURN服务器。这里就变得“简单”了，因为我们主要讨论的是coturn[12]。虽然还有其他几个选择，但是coturn是目前最流行的TURN服务器（开源或者其他）。

在很多方面，我们只需coturn即可，因为TURN很简单，并可用于代码实现（Cloudflare正在或曾经想要通过他们的管理服务改变这一点[13]）。

但是，凡事都有一个但是：coturn也需要不断更新和改进。这是最近在coturn的github repo上发布的一个问题[14]：这个项目死了吗？

可以在注释中的链接里阅读相关信息，其中的回答很有趣。

coturn的维护者已经精疲力竭，又或者只是没有时间来维护它（他们都有自己的日常工作）。对于这样一个广受欢迎的开源项目，最终结果就是一两个志愿者边忙碌于自己的日常工作，边贡献代码。

接下来又到了：

谈钱时刻

如果有人决定使用coturn并将它直接集成到自己的应用中怎么办？

• 没有官方付费支持选项。

• 没有官方替代方案支付定制化的开发费用。

• 整个生态环境的规模已经足够大，你可以很容易找到具备coturn知识的人。

WebRTC的开源信令服务器

信令服务器是一个很不同的开源项目。WebRTC没有准确定义它们，但是需要它们在参与者之间传递SDP信息和其他信号。对于WebRTC的开源信令解决方案，这里有几种替代方案。

值得注意的是，WebRTC中许多信令服务器替代方案仅提供对等通信性能，而无法与媒体服务器交互。有些信令服务器也将处理音频和视频流。它们对媒体或信令的注重程度决定了我们是将它们视为媒体服务器还是信令服务器。这一切都取决于它们的关注点以及最终所提供的功能。

信令需要两个组件，分别是信令服务器和客户端库（通常是轻量级的，但并不总是这样）。

我们将从标准库SIP和XMPP开始。

• SIP和XMPP

SIP和XMPP比WebRTC早出现了10年左右，拥有自己的开源项目生态、厂商和开发者。它们可用作成熟且可扩展的服务器，有时通过扩展支持特定WebRTC应用场景，如为TURN创建验证token[15]。

我们不会花时间一一解释这些替代方案。

这里值得一提的是MQTT。众所周知，Facebook曾在Facebook Messenger中使用它发送信号（至少过去曾使用过，目前不确定是否还在使用）。

• PeerJS

PeerJS[16]的存在时间几乎和WebRTC一样长。在相当长的一段时间里，其代码库一直没有得到维护或更新以适应所支持的浏览器。这种状态似乎延续到了今天。

这个项目似乎专注于庞杂的单服务器开发，而没有考虑水平的分布式扩展。但对于大部分人来说，应该足够了。

多年以来，PeerJS几经易手并更换维护者，今年年初还在招募维护者[17]。

事不宜迟，让我们开始谈钱时刻吧！

谈钱时刻

如果有人决定使用PeerJS并将它直接集成到自己的应用怎么办？

• 没有官方付费支持选项。

• 没有官方替代方案支付定制化的开发费用。

• 代码库规模很小，所以如果你了解WebRTC，那么这些挑战就不是什么大问题。

• simple-peer

Simple-Peer早期由Feross推动，它是另一个仅专注于P2P的“纯WebRTC”库。如果Simple-Peer适用于你的应用场景，非常好，它目前已经成熟并完善。大部分情况下，你的应用场景会随着时间不断发展。

2022年，它只收到了少量维护commit[18]，2021年收到的commit也不多。在使用PeerJS时需要注意的问题同样适用于Simple-Peer。如果你要在二者之中选择一个，选择Simple-Peer吧，因为它的代码是更地道的JavaScript。

谈钱时刻

可以阅读PeerJS的谈钱时刻，因为它们所遵循的规则是一样的。

• Matrix

Matrix[19]是一个“用于安全、去中心化通信的开放网络”。它具有开放标准，同时背后也有商业厂商支持（Element[20]）

新颖时髦的Matrix试图弥补SIP和XMPP的缺陷，但是它最主要的设计为客户端和服务端的架构，且它的实现类似于把网络和UI包含在内的Slack。Matrix具有分散的架构和实现，从而更易扩展。

这里产生了一些分歧。Tsahi认为Matrix是一个很棒的选择，而Philipp却没那么激动。Matrix从full mesh迁移到Jitsi[21]，最近又迁移到原生SFU[22]。所以对于有些人来说，它的WebRTC历程有些曲折。

Matrix背后有一家公司支持，但这家公司有自己的倾向（与Slack竞争的私心）。

谈钱时刻

如果有人决定使用Matrix并将它直接集成到自己的应用怎么办？

• 没有官方付费支持选项。

• 没有官方替代方案支付定制化的开发费用。

• 尽管如此，Matrix上有一个Jobs Room[23]，你可以在上面搜索付费帮助。

• GitHub“丛林”中的其他项目

在创作这篇文章的时候，有26121个repository提到了WebRTC[24]。你在阅读这篇文章时，这一数目还在增加。

在这些混乱的repository中，特别突出的并不是很多，所以很难弄清哪些项目更适合你，尤其当你的需求会持续下去的时候。如果你正在寻找获得足够支持并具备繁荣社区的项目，那更是难上加难。

WebRTC的SFU和媒体服务器

媒体服务器和SFU[25]是另一组重要的开源WebRTC项目。

信令服务器处理设置实际会话的对等通信，而媒体服务器聚焦在信道——我们想要发送的实际数据——音频和视频流，提供实时视频流和处理。每当你需要群组会话、广播或录制（假设你希望在应用程序中加入视频通话或视频会议）时，你最后都会使用媒体服务器。

下面是商业方面：

• Janus、Jitsi、mediasoup和Pion

我曾在《2022 WebRTC发展趋势分析》中详细介绍过这些项目，相关内容可以参见下图。

Janus、Jitsi、mediasoup和Pion在商业解决方案中非常有用且流行。让我们使用分析其他WebRTC开源项目的方法来分析它们。

• Janus

• 来自meetecho的官方付费支持。

• 你可以向meetecho支付咨询和（付费）开发费用。从经验来看，他们大部分人都很忙，这也意味着他们对最终合作的人选非常挑剔。

• Janus生态规模足够大，并且还有其他人为其提供开发服务。

• Jitsi

可以将Jitsi看作其自己的平台：

• Jitsi 的核心是Jitsi Videobridge，与周围的其他组件共同组成了Jitsi Meet视频聊天应用程序。

• 它还包括一个托管的CPaaS服务产品：8×8 JaaS[26]。

谈钱时刻

• 几年以前8×8收购了Jitsi，这也说明它没有官方付费选项。

• ‍‍‍‍‍‍‍‍同样，也无法进行付费的定制化开发。

• Jitsi生态规模足够大，并且还有其他人为其提供开发服务。

• 和Matrix（Element 提供付费托管）一样，8×8 JaaS 为Jitsi（CPaaS）提供付费托管。还有Jitsi Meet，它本质上是建立在Jitsi之上的免费托管服务。‍‍‍‍‍‍‍‍

• mediasoup

• mediasoup由在Around[27]工作的两名开发人员维护，这也说明它没有付费支持官方选项。

• 同样，也无法使用定制化开发。

• mediasoup的生态意味着你也可以找到它的开发人群。

• Pion

• 我们在上文介绍WebRTC客户端时已经讨论了Pion。

• 假设媒体服务器也是如此。

• 你唯一头疼的是选择使用哪个基于Pion编写的媒体服务器。

需要明确的是，在上述的所有情况中，如果让厂商帮助你解决那些无人维护的特定媒体服务器代码库问题，那就意味着实现质量方面的结果将非常不确定。也就是说，你很难搞清楚是在和谁合作。

• Kurento的失败

Kurento媒体服务器已经死了，连它背后的那群开发者都去开发OpenVidu（下文会介绍）了，并让OpenVidu在mediasoup之上运行。

千万别碰它。

Kurento已经沉寂多年，但有人依然想使用它。先去搞清楚它的状况吧。

• 抽象概念的更高层次

更高层的概念开源项目努力成为某种平台。在 WebRTC 生态系统中，它们最关注的是在开源媒体服务器之上提供一层工具。OpenVidu和LiveKit很可能是其中最值得关注的两个项目。

• OpenVidu

OpenVidu[28]是一种包括UI、实现了房间服务的抽象层。

Kurento被收购后，团队剩下的人创建了OpenVidu。他们甚至逐渐采用mediasoup作为使用的媒体服务器[29]，而将Kurento置于一边。

谈钱时刻

和我们之前所看到的很多开源解决方案都不同，OpenVidu看似有其自己的商业模式：

• 具备官方商业支持。

• 提供托管商业计划以及咨询和开发工作。

• LiveKit

LiveKit[30]提供“开源WebRTC基础设施”，即Pion SFU之上的管理层。

我一直不太理解LiveKit的商业模式。他们并不只是一个开源项目，还是一家公司。因此，他们需要收入维持下去。

也许他们从采用LiveKit的企业那里获取支持和开发收入，但很难从他们的网站看出来。

其他一些不太流行的WebRTC开源选择

其他公司也提供商业解决方案（本质上为专用），有些人将它们作为本地替代方案：这些公司提供软件和支持，但你需要部署和维护。

这种解决方案，或者非常合适，或者会带来灾难，尤其是当这样的厂商决定转移或者离开市场时。所以遇到这类解决方案一定要谨慎。

WebRTC开源是时候发展起来了吗？

本文是一篇很长的WebRTC开源现状概览文章，我想我们可以达成一致的是：WebRTC开源目前的状况不太妙。

• WebRTC已经存在超过10年。

• WebRTC开源项目不断发展。

• 技术爱好者和专业技术人员都在使用这些项目。

• 这些开源项目存在于为数百万用户的商业应用中。

• 但它们却很少提供付费帮助支持。

• 不知何故，其市场并没有在商业方面获得发展。

我们认为WebRTC开源并没有真正成长起来。我们希望看到更加成熟的市场，这样才能为企业和企业家提供更多更好的商业解决方案。

参考文献：

[1] https://twitter.com/hcornflower

[2] https://webrtccourse.com/

[3] https://bloggeek.me/webrtc-insights/

[4] https://bloggeek.me/using-open-source-license/

[5] https://webrtccourse.com/developers/

[6] https://archive.fosdem.org/2021/schedule/event/webrtc_shipping/

[7] https://pion.ly/

[8] https://www.linkedin.com/in/sean-dubois/

[9] https://github.com/aiortc/aiortc

[10] https://github.com/webrtc-rs/webrtc

[11] https://gstreamer.freedesktop.org/

[12] https://github.com/coturn/coturn

[13] https://bloggeek.me/managed-webrtc-turn-speed/

[14] https://github.com/coturn/coturn/issues/915

[15] https://xmpp.org/extensions/xep-0215.html

[16] https://peerjs.com/

[17] https://github.com/peers/peerjs/issues/938

[18] https://github.com/feross/simple-peer/commits/master

[19] https://matrix.org/

[20] https://element.io/

[21] https://www.youtube.com/watch?v=tVh0vYnBM4k

[22] https://matrix.org/blog/2022/08/05/this-week-in-matrix-2022-08-05

[23] https://matrix.org/docs/guides/matrix-jobs-room

[24] https://github.com/search?q=webrtc

[25] https://bloggeek.me/webrtcglossary/sfu/

[26] https://jaas.8x8.vc/

[27] https://www.around.co/

[28] https://openvidu.io/

[29] https://openvidu.medium.com/a-new-era-for-openvidu-better-perfomance-and-media-quality-with-mediasoup-24d46a9eb10d

[30] https://livekit.io/

作者简介：

Tsahi Levent-Levi：WebRTC专家，曾为testRTC的联合创始人和CEO，现为Spearline公司testRTC的产品负责人。Tsahi拥有多年WebRTC技术培训经验，并拥有自己的技术博客BlogGeek.Me，你可以到这里（https://webrtccourse.com/）了解和学习他的课程。

致谢：

本文已获得作者Tsahi Levent-Levi授权翻译和发布，特此感谢。

原文链接：

https://bloggeek.me/state-of-webrtc-open-source-projects/

---