作者 | Tsahi Levent-Levi
翻译 | Alex
技术审校 | 刘连响
WebRTC 年终盘点 #004
本篇为WebRTC技术专家Tsahi Levent-Levi发布在BlogGeek.me上的文章，我们翻译了其中部分内容发布在LiveVideoStack的公众号上。感谢Tsahi的授权。
我对WebRTC的主要担心是：一场大战蓄势待发。一方面，谷歌虽然一直引领WebRTC的发展，但作为一家大公司，它很可能没有从WebRTC中看到足够的价值。另一方面，行业中的其他人对于WebRTC的主要库libwebrtc（归谷歌所有，由其控制和维护）正在发生的事感到沮丧不已。这就导致了不同分支的产生——人们不断讨论和尝试为WebRTC这一规模宏大的项目找到更好的结构解决方案。
WebRTC差异化时代
两年以前，我们改变了主题：将“WebRTC增长时代”改为“WebRTC差异化时代”。
这一切都源于谷歌拆分了WebRTC开发工作，其中包括它在libwebrtc的内部结构，WebRTC 的开源实现以及WebRTC之外的实现方面做出的决策。结论是，任何机器学习算法都将在WebRTC之外。
其他大型供应商纷纷效仿，也在情理之中。
WebRTC巅峰时刻
我们已经到达WebRTC的顶峰了吗？
我通过Philipp了解到_Chrome Platform Status_网站，这里可以找到很多统计信息。该网站可以跟踪页面加载数据（包括某些 API 调用），其中许多都与 WebRTC 相关。上图是我选择的GetUserMediaPromise图表，它显示了Chrome 中加载的网页请求访问摄像头或麦克风权限的频率——通常为发起 WebRTC 会话。
在整个新冠疫情期间，我们看到 WebRTC 的使用量大幅增加，随后半年逐渐趋于稳定，但仍是疫情前的4倍。WebRTC是否能够保持这种状态还是一个疑问。Clubhouse自其强势亮相以来似乎已经停滞不前，就是一个很好的例子。
无人能预测未来一年还将发生什么：如果奥密克戎或者其他新冠变体病毒迫使人们待在家里隔离，又或者结束疫情指日可待，世界会变成什么样子？WebRTC呢？
谷歌和libwebrtc
谷歌全面控制了WebRTC，这样做有利有弊。所有浏览器通过libwebrtc支持WebRTC，libwebrtc是谷歌的WebRTC实现：
- 谷歌旗下的Chrome使用libwebrtc
- 具有Chromium（=Chrome）内核的Microsoft Edge也使用了libwebrtc
- Apple Safari采用了libwebrtc并在WebKit中得以实现
- Mozilla Firefox已经将libwebrtc嵌入到Firefox并需要不时更新（最近刚进行了一次重大更新）
对于WebRTC，谷歌似乎已经转向了维护模式。它改变了思维方式，聚焦于libwebrtc会给自身带来哪些好处。对于谷歌来说，这都说得通。
在为整个行业“遮风挡雨”十余年后，谷歌已开始初显倦态，尤其是内部创新不足的情况下，这种转变在所难免。
谷歌通过WebRTC为自身带来好处
这意味着，如果你的用例刚好是谷歌涉及领域或者其所需，那么祝贺你，它们将保持良好状态。如果你的用例不为谷歌所需，那就要祝你好运了。
同时，围绕WebRTC的行业中有很多心怀好意的人们，他们希望看到WebRTC不断成长，继续繁荣。他们想要为WebRTC的发展贡献出自己的力量，但这并不容易：
- 作为谷歌外部人士，向libwebrtc添加修改、更新和新的特性十分困难。
- libwebrtc置于10~20亿台设备中，谷歌不会盲目地接受贡献。
- 还有需要承担的责任。Google全权负责添加进Chrome和libwebrtc中的任何特性或修改等。他们甚至会为其他人找到的安全漏洞付费。
- 还需要有人来做测试，这将消耗很多资源，所以谷歌需要评估这么做是否合理。
- 从贡献者的角度来看，根本不能做到一劳永逸：你不可能只是提交几行代码然后寄希望于这些代码会集成到libwebrtc和Chrome中。
- 你需要为此付出努力：解释WebRTC为什么需要这些代码、为什么由你来提交以及这些贡献如何能帮助到每个人。
- 让我们面对现实：我们热爱写代码而不是评论、解释或者向他人推销自己。
- 那么公司呢？它们想要参与其中但却不想投入人力和资金。
结果就是陷入僵局。
WebRTC开源技术突破
有很多围绕WebRTC创建的开源项目，由于新冠疫情，在最近两年发展迅速。
在过去10年中，我们看到一些开源项目脱颖而出。我知道以下列出的项目并非全部，但可以假设这些就是我在市场中最常看到的开源项目（我刻意忽略了诸如FreeSwitch和Asterisk的VoIP/SIP开源项目）。
上图显示了我对于这些顶级开源WebRTC技术的当下思考：
- Kurento一直呈下降趋势。一切都始于5年前它被Twilio收购的那一刻。Twilio夺走了Kurento的知识，给它留下了一个空壳。从那时起，这个项目就回天无力了。维护该项目的团队后来开发了OpenVidu并开始了从Kurento到mediasoup的迁移。
- 多年来Janus一直表现强劲，但今天在新的项目中却越来越少看到它。它的发展缓慢也许是因为其他开源项目的兴起，又或许是因为meetecho团队的重点转向了NDI和OBS（WebRTC生态系统中的一个细分领域）。
- Jitsi的表现很棒。8x8从Atlassian手中收购Jitsi以后，向前一步，对此开源项目进一步投资（感谢Emil Ivov，做出这个决策并不容易）。Jitsi功能丰富，而且非常适用于视频会议。视频会议之外的其他场景可能更适合其他项目。
- mediasoup也是一个很棒的选择。最近几年，使用mediasoup的用户数量增长可观。我听到的大部分反馈都很正面。
- Pion很有趣。它作为WebRTC的Go实现出现，现在通过多种构建在其上的开源项目，可以完成从客户端解决方案到 SFU 的所有工作。对于某些任务而说，Pion是最佳解决方案。
对于WebRTC来说，Electron是一把双刃剑
还有Electron，这是一个构建于Chromium浏览器引擎之上的PC应用框架，它在WebRTC应用程序中也很受欢迎。
但使用Electron也意味着要向它选择的Chromium+libwebrtc发布节奏妥协，或者不断深入挖掘新技术，并同时拥有这项技术。
CPaaS中WebRTC的复杂状况
使用WebRTC CPaaS解决方案从来都不是一件容易的事。在即将到来的2022年会变得更加复杂，为什么会这样？因为形势并不明朗。
Twilio
Twilio正在向CEP（Customer Engagement Platform，客户参与平台）迁移。我支持它这么做，虽然这与WebRTC无关。
但涉及到WebRTC，Twilio对市场变化的反应较慢。对Twilio而言，WebRTC更像是事后的补救方法。
Agora（声网）
虽然声网的表现和流量都很强劲，但也存在市场不确定性，比如WebRTC已到巅峰，由Clubhouse带来的巨大增长以及政府的监管等。我在这里特别提到声网，是因为它是唯一一家专注于RTC的CPaaS供应商，并且是一家上市公司。
Daily
从好的方面来说，我们已经看到对Daily的投资（B轮已达到4000万美金）。这家公司正在成长中，致力于为开发者实现WebRTC。
Vonage
Vonange刚刚被爱立信收购。当我们分析它的WebRTC CPaaS性能时，我们就要看下这家公司迄今为止的收购链：
TokBox → Telefonica→ Vonage → Nexmo → Ericsson
- Telefonica收购了TokBox
- 然后Vonage从Telefonica手中收购了TokBox
- 将TokBox纳入Nexmo CPaaS平台
- 然后更名为Vonage API和Vonage Video API
- 现在Vonage已被爱立信收购
对于Vonage API平台的发展，我们拭目以待。
新的加入者
不断有新的参与者（规模不一）进入这个市场：微软和亚马逊纷纷加入CPaaS，尤其是使用WebRTC的CPaaS。Zoom最近也在涉足CPaaS。
像100ms这样更加年轻的公司（成立于2020年）也参与进来。它的API很有意思：可以使开发者提供用例的提示，或者在后台为开发者做更多事（与传统供应商解决方案相比）。
小部件、嵌入式和预生成
CPaaS市场还在不断增长和成熟。我们开始看到更高级别的、提供UI/UX的API。它们虽然大小、形态不一，名称不尽相同，但开发者都能轻松使用。
应该使用哪一家的产品？
明年你会选择哪家供应商？
这家公司会转移业务方向，从而抛弃你吗？
它所提供的API和各种性能真的好用吗？
问题种种，但都很难回答。
更多拓展内容：
https://bloggeek.me/webrtc-un...
https://bloggeek.me/webrtc-ne...
https://chromestatus.com/metr...
https://bloggeek.me/chrome-on...
https://bloggeek.me/twilio-ac...
https://bloggeek.me/8x8-acqui...
https://bloggeek.me/twilio-si...
https://www.daily.co/blog/ann...
致谢
本文已获得作者Tsahi Levent-Levi授权翻译和发布，特此感谢。
原文链接：https://bloggeek.me/webrtc-tr...
更多年终技术盘点：
扫描图中二维码了解大会更多信息
