RTC技术（WebRTC）

Posted 2023-05-16

参考技术A RTC（Real time communication）实时通信，是实时音视频的一个简称，我们常说的RTC技术一般指的是WebRTC技术，已经被 W3C 和 IETF 发布为正式标准。由于几乎所有主流浏览器都支持 WebRTC 标准 API ，因此也让浏览器之间无插件化的音视频互通成为可能， 大大降低了音视频开发的门槛，开发者只需要调用 WebRTC API 即可快速构建出音视频应用。
更广义的RTC技术，不单单局限于音视频，包括IM、图片、白板、文件共享等富媒体在内的实时交互也属于RTC技术范畴。

直播中我们关心的几个点：延迟、质量、成本等。
传统rtmp直播痛点：TCP，延迟高、拥塞导致卡顿问题较多（质量问题）。
互联网网络复杂、延时敏感、实时音视频流畅度及清晰度较低以和运营成本较高等。
没有一项技术能兼顾并解决直播中的所有问题，RTC是时延、流畅、质量、成本等的平衡，成为技术选型落地的模型。
我们在做RTC应用的时候，不应该一味地追求一些点，不应该在某些单点上用力过猛（比如单纯的追求抗丢包能力），导致最终的效果会打很多折扣，不能只着眼于延迟低，画质高，应该把视角放在用户的整体体验上。

RTMP只是TCP上的一个标准协议，所以接入是一个标准体系，推流端可以是OBS这种直播软件工具，也可自开发rtmp推流工具，播放端可以是Flash播放器（Adobe 2020 12月份已经弃用）、服务端有技术成熟的CDN技术和设施进行分发、Native的播放器或者flv.js/hls.js这种开源播放器组件，遵循rtmp、flv、hls标准即可，接入成本比较低。而一个完善的RTC服务应用，需要从推流端、服务端、到拉流端，一整套完整的全链路闭环技术。

视频会议、在线教育小班课、大班课、1v1视频连麦、多人视频连麦互动、语音聊天室、在线面试、在线医疗、云游戏、智能家居、在线签约、在线K歌等，遍地开花。
比如Zoom、腾讯会议、钉钉会议、微信音视频聊天

互动连麦+服务端转推rtmp至CDN，CDN分发给观众。

声网、腾讯云音视频、即构、阿里云RTC、华为云RTC、微吼VRTC、网易云信RTC、保利威RTC、Ucloud RTC、融云RTC、拍乐云等。

5G时代RTC技术满足实时通信的同时，将赋能 AI、AR、VR、智能家居、云游戏、远程辅助驾驶等场景化落地。

2023年WebRTC趋势：黄金时代不在

 点击上方“LiveVideoStack”关注我们

▲扫描图中二维码或点击阅读原文▲

了解音视频技术大会更多信息

编者按：随着疫情防控全面放开，混合办公成为主流的协作方式，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年将注定成为不平凡的一年。

---

▼识别二维码或猛戳下图订阅课程▼

喜欢我们的内容就点个“在看”吧！