编者按：随着疫情防控全面放开，混合办公成为主流的协作方式，WebRTC 作为主流的 RTC 基础技术自然也受到影响。在 2023 年，WebRTC 代表的 RTC 技术会有怎样的剧本？本文来自 Tsahi Levent-Levi，LiveVideoStack 已获转载授权。

原文 /https://bloggeek.me/webrtc-predictions-2023/

文 / Tsahi Levent-Levi

译 / 核子可乐

技术审校 / 刘连响

 

在本文中，我们将共同了解 2023 年值得期待的 WebRTC 发展趋势与预测。正所谓细节决定成败，请务必关注其中的种种微小差别。

2023 年已经到来，我们也是时候回顾过去、展望未来，畅想 WebRTC 在这一新一年中将走向何方了。首先得承认，今年的情况格外复杂：

• WebRTC 已经成势，它将持续存在并维持稳定的使用需求；

• 我们正在、或者即将身陷全球经济衰退；

• 新冠疫情即将结束，刚刚摆脱阴云的中国政府决定全面放开；

• 作为刚刚问世的新秀，生成式 AI 带来的技术范式转变将影响每个人、每个行业。

另外，我（作者）的工作和生活也发生了很大变化。现在我在 Spearline 担任首席产品官，负责通信网络的测试和监控工作。人生还真是难以预料。

闲言少叙，咱们马上进入正题。

我们的 WebRTC 图景

在公布预测之前，我得先向大家表明立场。我们的整个发展趋势图景具体分为 3 层：

1. WebRTC 技术本身

2. WebRTC 中的开源

3. CPaaS 与 WebRTC

下面我们先从技术本体说起。

差异化时代

我们正身处一个差异化的时代：

这个时代的起点，是谷歌将 WebRTC 从浏览器中解绑出来，部分作为独立的未来 W3C 标准交付，同时开放了更多对于底层技术栈的访问。过去一年以来，已经有越来越多的用户在谷歌以外的实验和生产环境中使用这些功能。

2021 年，浏览器中的视频背景模糊和背景替换成为主流。

2022 年，我们看到专有编解码器和噪声抑制等功能，开始在 WebRTC 应用程序和技术方案中建立起坚实的基础。这方面的代表性商业用例就是 Dolby Voice 专有编解码器，以及 Twilio 与 Krisp 在噪声抑制方面的合作协议。

从这个角度来看，供应商无疑是希望进一步推动差异化，未来将有更多此类产品陆续涌现。只要整体经济不至于衰退得太厉害，相信这股积极潮流将得到延续。

WebRTC 的黄金时代或已过去

推动 WebRTC 快速普及的新冠疫情，如今即将全面退场。

无论后面还有没有新的爆发波次，中国都选择了全面开放。人们转向混合办公，而且逐渐适应了在疫情隔离之下通过视频会议交换工作信息。

在这场席卷全球的疫情中，Zoom 可谓顺势而起。将 Zoom 的股价跟 Chrome 中的 WebRTC 使用量曲线叠加起来，就得出了下面这张有趣的图表：

WebRTC 的使用量仍保持在疫情前的 3 到 4 倍。但可以看到，整个 2022 年内 WebRTC 用量开始持续减少，而且这种下降趋势很可能持续到 2023 年。

我的猜测是，最终 WebRTC 的使用量将稳定在 2020 年初的 3 倍左右。

libWebRTC 一骑绝尘

在 WebRTC 客户端实现方面，libWebRTC 仍然保持着遥遥领先。

没错，不是领先，而是遥遥领先。

libWebRTC 是谷歌的 WebRTC 实现，也是当前各类浏览器都在使用的 “正确答案”。

对于大多数项目，使用 libWebRTC 作为非浏览器实现的起点已经成为一种习惯。只有某些小众用例，才有可能稍微考虑一下其他解决方案。目前相对还有一点竞争力的对手，可能就是 Pion 了。

2022 年是 libWebRTC 经历优化和完善的一年，这相当于是延续了谷歌在 2021 年定下的工作重点。从目前看，2023 年的方向也将继续保持不变。

在针对 WebRTC Insights 客户的 libWebRTC 项目历史贡献者分析调查中，可以看到与 libWebRTC 有关的以下调查要点：

WebRTC 中，是否还有其他竞争方案能够取代 libWebRTC？

目前最流行的 WebRTC 实现就是 libWebRTC 了，而且它已经被广泛嵌入至全部现代浏览器当中。libWebRTC 得到了良好维护，而且一直保持着改进和优化。没有哪种其他 WebRTC 堆栈能在投入水平上与 liWebRTC 相比肩。

而且这种优势在可预见的未来将一直存在。

谷歌为什么要投资 libWebRTC?

这其实跟 Google Meet 无关。谷歌的利润来源，主要是在浏览器 / 智能手机的搜索流程中投放广告。只要能让用户更多使用浏览器和 Web 资源，谷歌就能从更多的交互中间接获取收益。

之后是 Google Meet/Workspace，立足企业生产力层面与 Microsoft Office 正面竞争。

如果能够实现通信商品化，则代表谷歌找到了新的补充性技术管理方式。Ben Thomspon 曾经在最新的 AI 与五大科技巨头分析文章中提到：

开源也不可能脱离基本的经济法则。绝大多数参与者其实并不理解开源领域的运作规律：为什么很多肩负着股东收益最大化责任的大型上市企业，会不断投入大量资金来支持开源软件，甚至专门为其建立成规模的开发团队？事实上，这就是对补充性技术的基本管理原则。

经济原理告诉我们，当产品的补充性技术价格下降时，市场对于产品本身的需求将上升。一般来说，企业的战略思路就是尽可能降低补充性技术的价格，借此提振自家产品本体的销路。而理论上具备可持续性的最低价格，就是产品价格 + 补充性技术价格 = 产品价格，即免费提供补充性技术。只要能做到这一点，企业就将从胶着的市场竞争态势中撕开口子，找到一条差异化的取胜之道。所以：

聪明的企业一定会努力推动补充性技术走向商品化。

WebRTC 开源现状

跟一年前的 WebRTC 开源趋势相比，目前的整体形势并没有太大变化。

• Kurento 仍然没缓过来；

• Janus 表现不错，跟一年前一样；

• Jitsi 在组会议功能中仍扮演重要角色；

• mediasoup 是个不错的选项，其创始人和主要开发人员都曾在 Around 工作，随后通过收购一同加入了 Miro；

• Pion 的受众和实际使用量都在增长。

不出所料，Janus、Jitsi、mediasoup 和 Pion 都保持住了稳定的创始团队，这些团队和个人继续全身心倾注于这些项目，所以发展态势继续向好。

目前的问题是，除了 Janus 之外，这些项目都没能提供任何官方支持和定制开发选项。也就是说，企业客户需要依靠内部开发或外部承包商 / 自由职业者专门支持和调整这些技术。

这种状态已经持续了好几年，预计 2023 年也不会有太大的变化。

最大的变数，可能出现在那些由企业间接持有、但相关企业的业务重点又放在其他方向上的项目：

• Jitsi——Jitsi 先是被 Atlassian 收购，之后又被 8x8 收购。8x8 专注于 UCaaS、CCaS 和 CPaaS 等业务。Jitsi 即服务已经由 8x8 进行发布和推广，但 Jitsi 开源项目一直没有动静。新一年中，8x8 愿意为开源项目投入多少？这些都仍是未知数。

• mediasoup – mediasoup 的创始人习惯于 “按部就班”。这种不紧不慢的节奏让 mediasoup 在 Around 和 Miro、乃至未来的其他收购方之间不断易手。这会在 2023 年对 mediasoup 项目产生显著影响吗？可能不会，但整体经济衰退也许会影响项目的未来命运。

• Pion – Pion 是由 Sean DuBois 创建的，这股对于 Pion 和 WebRTC 技术易用性的热情始终没有改变。所以 Pion 应该会继续稳定前进。

• Janus – Janus 由 Meetecho 负责维护。Meetecho 是一家开源服务商，从目前的市场状况看，他们的业务重点和运营路径应该不会发生改变。

CPaaS 与 WebRTC

CPaaS 的整体格局正在变化，历史的指针开始指向 WebRTC。

这波转变在几年前就初见端倪，而且整个领域的变化似乎正在加速 —— 这跟 WebRTC 那波澜不惊的开源节奏形成了鲜明对比。

WebRTC CPaaS 中公认的领导者仍然是 Twilio、Vonage 和 Agora。我个人有种感觉，到 2023 年底，情况应该会有所改变。下面，我们回顾一下 CPaaS 中这几位 WebRTC “大佬”。

Twilio

任何一份没有 Twilio 的 CPaaS 都是不完整的。所以一切，当然要从 Twiolio 说起。

Twilio 继续延续着上一年的发展思路，力争让平台的客户体验更上一层楼。

2022 年内的一大重要变化，就是 Twilio 宣布将专注于四大支柱，将原本分散的改进力量集中起来。Jeff Lawson 在关于裁员 11% 的公开信中公布了这四大支柱：

1. “投资于我们平台的可靠性和信任度”，涉及规模、安全和优化……

2. 提高消息收发业务的盈利能力，指的是短信与社交消息业务；

3. 加速细分业务采用，指的是 CDP（客户数据平台）；

4. 扩展 Flex 客户端群体，即 CCaS（联络中心）业务。

这里对 WebRTC 只字未提，也没把视频业务纳入支柱范畴。

恰恰相反，公布于 2021 年的 Twilio Live 视频业务将被关闭：

有趣的是，Twilio 在迁移指南中推荐了 Mux—— 一家刚刚推出 WebRTC 视频产品的供应商。这不禁让人好奇，正在使用 Programmable Video 的 Twilio 客户要不要也逐步朝着 Mux 迁移？

Vonage

Vonage 正忙于跟爱立信就收购协议进行谈判。

除了视频背景模糊和背景替换之外，Vonage 的平台并没有产生太大变化。

随着 Vonage 和爱立信间蜜月期的结束，再考虑到全球经济衰退的到来，Vonage Video API 的未来命运无疑值得关注。其投资水平将保持高位，还是说会因整体衰退而一路缩减？

Agora

Agora 的股价自峰值之后可谓一路暴跌：

而且由于 Agora 是在 2020 年才进行 IPO 的，所以可供分析的数据也远不及 Zoom 那么丰富。

无论如何，Agora 正围绕着平台体验和质量跟 Zoom 展开激烈的市场对抗。

Zoom

Zoom 选择的是非绑定方式，仅使用少量 WebRTC。在视频方面，Zoom 专注于构建自己的多媒体技术栈，希望更多取代 WebRTC 的作用。从短期来看，这种全靠自己的办法效率不高；但如果把眼光放长远些，结论就完全不同了。

而 Zoom、API 还有 CPaaS 的故事恰恰需要用长远的眼光来解读。目前的 Zoom 还不够完善，与浏览器的整合也不够紧密。为了保证知己知彼，Zoom 委托开展一项性能调查，希望了解 Zoom Video SDK 跟 Vonage Video API、Agora、Twilio Programmable Video 以及 Amazon Chime SDK 之间的优劣关系。

相关的帖子指出：

• Zoom 希望在宣传中强调自己视频 CPaaS 供应商的身份。目前，他们在这一领域的市场渗透率还比不上那些大型视频 CPaaS 供应商，所以希望通过这份业绩报告向潜在客户们证明自己在市场上具有竞争力。

• 亚马逊一路堪称势如破竹。因此 Zoom 决定加入其中，借此在市场上保持竞争力和一定份额。目前，Amazon Chime SDK 已经成为开发人员甚至是其竞争对手（包括 Zoom）不可忽视的一股力量。

微软

2020 年，IaaS 服务商开始全面进军视频 CPaaS 市场。就在这一年，微软 Azure 和亚马逊 AWS 都推出了自己的视频 API。

微软的方案似乎更有说服力：Azure Communication Services 使用的是与 Microsoft Teams 相同的基础设施，从长远看应该能直接接入 Microsoft Teams 呼叫。

从网络效应和基础设施设计的角度看，情况应该是对微软有利的。但实际情况并非如此，在与 WebRTC 应用程序开发者的交流中，他们普遍反映微软还没能充分发挥这部分潜力。

亚马逊

如今，Amazon Chime SDK 的曝光率可以说越来越高了。而且似乎跟 Amazon Connect 一样，在推出了 3 年之后，Chime SDK 也来到了决定其能否跻身 “江湖名人堂” 的关键时刻。

相信无数双眼睛正在紧盯这个历史性的时刻，特别是那些视频 API 供应商们……

Cloudflare (市场新秀)

又一家 IaaS 供应商加入了视频 API 的行业 ——Cloudflare。Cloudflare 于 2012 年起开始提供托管 TURN 服务，但当时还仅处于 beta 内测阶段。

但 2022 年 9 月，他们突然公布并推出了两项附加服务：

1. Cloudflare Stream—— 基于 WebRTC 的直播服务；

2. Cloudflare Calls——WebRTC 视频群组通话服务。

这两款 API 产品的基本定位，也正好是当下 Video API 或 WebRTC CPaaS 领域的热点所在。

希望两位新秀的普及速度，能比不温不火的托管 TURN 服务更快一些。

Mux (市场新秀)

专注 API 视频传输业务的供应商 Mux 也加入了 WebRTC 市场，同时拿出了自家 Video API——Mux Real-Time Video。考虑到 Mux 的目标受众与 CPaaS 的最终用户（软件开发商）略有不同，所以这招差异化打得确实漂亮。Mux 相当于是给同一个问题带来了全新的视角和解释 —— 类似于 IaaS 服务商和 Zoom 之间的区别。

之前也提到，Twilio 决定向自己的 Twilio Live 客户推荐 Mux。如果我是 Mux，那我肯定会认真标记好每家来自 Twilio Live 的客户，确保向他们提供最佳体验和支持，这样半年之后就可以 “引导” 他们从 Twilio Programmable Video 迁移到 Mux 这边来了。

SaaS 服务商进军 CPaaS，可嵌入和预构建成为主流

接下来要说的，是低代码 / 无代码趋势及其在 CPaaS 中的表现。过去两年来，可以看到越来越多的 CPaaS 服务商开始在其视频 API 上提供低代码与无代码解决方案。

另外，各 SaaS 服务商也开始进军这部分解决方案 / 业务市场。出于某种考虑吧，反正现在人人都觉得 CPaaS 是块不容忽视的蛋糕。

其中最值得关注的当数 Whereby。这套会议平台最初只提供 Whereby Embedded 和 Digital Samba 等网络研讨功能，但最近上线的 Digital Samba Embedded 明显更加全面且成熟。

随着 CPaaS 服务商及其他厂商不断提供更高的抽象层，这部分市场也将继续保持发展。

回顾我的 2022 年 WebRTC 发展趋势预测

对过去一年的市场动态做完了总结，下面咱们来看看我当初的预测到底靠不靠谱。

但请大家别太当真，毕竟任何预测都是娱乐为主、辅以一点逻辑演绎。

说对的部分

我提出的三种趋势得到了证实。

#1 – 规模与性能

我当时认为，WebRTC 的规模和性能都将不断提升。2022 年无疑验证了我的观点。

在 2022 年 11 月的 Kranky Geek 活动中，谷歌公布了 WebRTC 年度更新，而其中排在首位的就是性能优化：

后面我们还会多次看到这张幻灯片。

#2 – 新技术

下面是新的技术趋势与细分类别：

• WebAssembly – 随着背景模糊 / 替换和噪声抑制的普及，WebAssembly 现已成为大部分主流 WebRTC 应用程序的重要组成部分。

• WebTransport, WebCodecs – 目前相关演示很多，但大多还处于试验阶段。实际生产层面的进展还非常有限（除了 Zoom 之外）。

• AV1 – 仍在持续推进当中，但似乎是距离实现越来越近了。

#4 – 流媒体直播

流媒体直播在 2022 年继续保持发展：

• Cloudflare 亲自下场，开始与为自己提供解决方案的供应商正面竞争；

• 流媒体直播观众的日增长量达 15000 人；

• WHIP 与 WHEP 的标准化让 WebRTC 全面融入流媒体直播，生态系统仍在不断变化。

说错的部分

下面来看哪些预测惨遭打脸。

#3 – WebRTC 基础设施、超大规模与 SD-WAN

当时，我很认真地分析了 Anycast 和 SD-WAN 对于 WebRTC 的重要意义。

但之后 Subspace 公司就关闭了，已经付出的全部努力也付之东流。真的很遗憾，我到现在也认为这是一种可行的延迟控制与流媒体清晰度增强方案。此次挫折，恐怕会将类似的尝试往后推迟好几年。

#5 – 从二维到元宇宙

我想得倒是挺多，但从 2022 年的现实来看，前所未见的新选择和新思路其实并没多少。

云媒体处理

这应该算是新思路之一，虽然还没有真正形成趋势，但绝对值得关注。

在 WebRTC 中使用选择性转发单元（SFU）的核心意义，就是为了降低计算带来的基础设施成本。

然而……

几年之前，谷歌开始在云端对 Google Meet 进行噪声抑制。也就是说，在 SFU 架构中引入云端音频编解码。

如今，谷歌正以同样的方式让低端设备也能实现背景替换。

这可能只是谷歌自己的尝试，但也有可能会吸引到其他厂商的争相效仿。

2023 年 WebRTC 发展趋势预测

说完了对 2022 年 WebRTC 市场趋势的总结，又回顾了上一轮预测中的是是非非，下面该向大家公布我对 2023 年的展望和判断了。

#1 – 关于 libWebRTC (和 WebRTC 的未来)

关于 libWebRTC，我的看法基本不变，只是结论略有调整。

谷歌的这套 WebRTC 库已经非常成熟，包含所有预期功能。我认为谷歌后续会从下面几个角度对 libWebRTC 做进一步完善：

1. 精简调整。清理掉那些不用的代码（最近已经有这方面迹象），推动其实现规范化兼容。现在的 libWebRTC 有了难得的空闲时间，可以好好把基础再打牢些了。

2. 进一步优化性能。继续优化 CPU 和内存资源的使用，改进带宽估算和回声消除等算法。

3. 完善协作。2022 年，谷歌就已经在这方面做出努力，相信 2023 年也是如此。谷歌会引入更多 API 和配置，让 WebRTC 中的协作体验更加轻松完备。在完善之后，无论是在 Google Meet 中共享谷歌文档，还是在文档中共享 Google Meet，也许都将变得顺畅自然。

libWebRTC 将继续成为 WebRTC 堆栈中的首选客户端开发方案，谷歌也将用努力和投入证明其先进性。

#2 – 机器学习与媒体处理

就 WebRTC 而言，WebAssembly 将在 2023 年继续扮演核心驱动角色。

Wasm 不仅会被用于媒体处理，同时也将在背景替换、噪声抑制和专有编解码器实现等场景下发挥作用。

我认为，Wasm 将被用于开发在 WebRTC 数据通道或 WebTransport 上运行的媒体引擎，帮助供应商更多将对等连接实现保留在 WebRTC 之内。

#3 – 先语音后视频（Lyra 先上，AV1 随后）

这个思路可能有点过激，但我还是想多说几句。

Lyra 是谷歌基于机器学习的语音编解码器，它会在 AV1 之前进入 WebRTC。这里指的不是可用性，而是真正的采用和普及。

理由很简单，AV1 占用的 CPU 容量和内存太大了，因此只能在高端设备或者较新的硬件上才能运行。在 AV1 成为现实之前，我们还有很长的路要走 —— 大概要再过一、两年。

而 Lyra 已经实现了，性能和质量都在不断提高。微软 Satin 也在朝着谷歌步步逼近，所以我觉得 2023 年内双方肯定会有一番较量。

我觉得 Lyra 技术可能已经就绪，而市场也已准备到位。

#4 – 可观察性

在我看来，WebRTC 应用程序的可观察性一直是个大问题。由于种种原因（包括加密需求），WebRTC 的特性导致其很难使用传统工具和方法实现监控。

2023 年，可观察性应该会得到更广泛的关注。目前市场上已经有众多使用 WebRTC 的产品，联络中心也开始全面迁往云端。各大主要供应商都在将当前部署的重点从 SIP 转向 WebRTC，这就要求用更好的工具来监控并分析 WebRTC 会话在预生产 / 正式生产环境中的行为。

#5 – 兼并与倒闭

2023 年，必然掀起一波兼并与倒闭浪潮。

经济衰退已经成为现实，而且很可能要持续一整年。无论最终能不能恢复，目前可以确定的是：

企业在 2023 年内都在削减开支、缩小规模并专注于核心业务。

WebRTC 也避不开历史的洪流，而且作为一种比较年轻的技术，其受到的伤害可能更大。但好消息是，新冠疫情塑造的混合办公习惯也让 WebRTC 有了更大的施展空间，所以两种因素可能会相互抵消。

所以总的来看，新一年内的兼并可以看作行业自身的吐故纳新行为：

• 一部分供应商难以维持运营，撑不过 2023 年。他们的技术也许稳定可靠，只是未能与市场需求完美契合、或者缺少能够实现业务目标的商业计划。

• 其他一些供应商可能会接受收购。2022 年就曝出了不少收购案，相信 2023 年会更多。

这样的前景，无疑让选择 CPaaS 供应商变成了令人头痛的难题。一旦选错，意外被兼并甚至破产的供应商只会留下一副烂摊子（想想 Twilio Live），令已经投入时间和资源的客户蒙受损失。为了避免这种情况，客户往往会选择体量更大、知名度更高的供应商，由此引发的恶性循环无疑将让小型供应商失去市场吸引力、加速走向灭亡。

做好准备，迎接艰难的一年

这一年，日子不会太好过。

相信大家对即将到来的挑战已经心中有数。

一方面，各个领域都面临着相似的难题；另一方面，市场状态造成的种种不确定性又会给业务造成独特的冲击。

再加上生成式 AI 对于 WebRTC 乃至整个通信市场造成的深远影响，2023 年将注定成为不平凡的一年。