WebRTC 不会改善你的通话质量，可观测性才会

作者：Tsahi Levent-Levi
原文：https://bloggeek.me/webrtc-fix-quality-observability/

有一个秘密：WebRTC 的通话质量与其他 VoIP 协议是一样的。

WebRTC 的优势在于它嵌入在 Web 浏览器中以及围绕它蓬勃发展的生态系统。但我们今天不聊这个。我最近与一位客户进行了一次初步沟通，他们想搞清楚的问题之一就是 VoIP 协议的使用。

他们没有使用 WebRTC，认为切换到 WebRTC 可能会提升通话质量。但他们真正的问题不在于协议，而是缺乏 WebRTC 可观测性：他们根本看不到通话实际发生了什么。

本文核心要点

• WebRTC 的通话质量与其他 VoIP 协议相当，但真正的问题往往在于 WebRTC 可观测性，而非协议本身。
• 纠结于”是否切换到 WebRTC 还是其他协议”会分散注意力，让你无法找到通话质量问题的根本原因。
• 客户端可观测性，尤其是通过 getStats()，能提供服务器端指标无法给出的用户体验洞察。
• 在做架构变更之前，先收集数据并进行分析，理解真正的问题，而不是追逐潮流。
• 可观测性让你能够快速定位问题，实现高效排障和更优质的服务。

问错了问题

你问错问题了。这个错误的问题有各种各样的形式：

• 我们该用 WebRTC 还是切换到 X？
• 我们该继续用 X 还是切换到 WebRTC？
• 是不是该换掉我们的 SFU？
• 是不是该加一个 SFU？也许……去掉它？
• 我们在用的视频 API 供应商有质量问题，该换谁？

不是说这些问题不好。它们都是好问题。

但它们问错了方向。它们把真正的问题藏在下面，那个最初引发这场对话的原因。

如果存在质量问题，难道不应该先搞清楚根本原因是什么吗？

如果通话连接不够频繁，也许我们应该查一查为什么有那么多通话失败？

在不理解要解决的问题的情况下就切换技术、改配置、改架构，意味着我们用错了方法。

最近一个客户开会时，我”逮到”了一个让人感觉”不对劲”的修复。直觉告诉我它就是不对。

于是我建议暂停一下，回退这个修复，去检查问题本身。

试着搞清楚它最初为什么会发生。

因为它可能隐藏着更深层的事实，日后还会引发更大的麻烦。

结果确实如此。那个修复只是把问题藏得更深了。

从某种意义上说，这就是可观测性的意义所在。找到根本原因并解决它们，而不是粉饰太平、掩盖问题，让谁都不知道底下埋着什么。

两种技术栈都能达到同样的质量

用 SIP？很好。

用 WebRTC？也很好。

你猜怎么着？它们都用 RTP 传输媒体。

在 2026 年及以后，两者很可能都在 SRTP 之上运行。安全性比以前更普及也更重要了……

带宽问题？对两者都有影响。抖动也一样。基础设施和 TURN 服务器的部署位置也一样。

两者都能使用相同的编解码器。

这意味着什么？

从质量角度来看，选 SIP 还是 WebRTC 其实并不重要。

重要的是你的实现有多好。

是的，如今我会倾向于 WebRTC。不仅仅是因为我多年来一直是它的倡导者，而是因为过去十年里，所有的精力和创新都转向了 WebRTC，在某种程度上也是远离了 SIP。

更现代的架构和实现都在 WebRTC 阵营。

这是否意味着 WebRTC 服务的媒体质量比 SIP 服务好？不是。

它只是意味着你手上有更多的工具和选项。但两者都能达到同样高的媒体质量水平。

你默认是盲目的

拿 SIP 还是 WebRTC 来讨论媒体质量问题，是错误的问题。

真正应该指引你的核心问题是：我当前的媒体质量如何，如何改进和优化它？要回答这个问题，你需要更多信息——可观测性。

WebRTC 给了我们 getStats()，一个出色的 API，几乎能收集到我们所需的一切，打包在一次调用中，供我们收集和分析。

而 SIP……我们基本上只能靠自己。原因很简单，SIP 是一个协议规范，而 WebRTC 同时也是一套 API 规范。

这里的关键区别在于视角不同。

用 SIP 时，如今大部分可观测性都在服务器端完成。用 WebRTC 时，最佳实践是通过 getStats() 从客户端收集。如果你问我，最好的方式是使用 rtcstats.com（你可以说我有偏见）。

为什么？

服务器端指标只是在猜测用户的感受。它们只掌握了一半的故事，基于服务器看到的内容以及客户端可能给也可能不给的反馈。如果说有用的话，它们主要用来判断”是不是出了问题”，而不是”为什么出了问题”。所以用这些数据来理解什么可以优化和改进，几乎是不可能的。

客户端指标收集，在 WebRTC 应用中正确实施时，能让你坐到用户旁边的头等舱，理解他经历了什么：以其他任何方法都无法实现的方式理解他的连接和媒体体验。

如果你在做真正的可观测性、根本原因分析、排障或优化工作，这个客户端视角至关重要。否则，你看到的只不过是真正发生过的事情的幽灵残影。

可观测性所能带来的，是更快的传输管道无法取代的

可观测性意味着：

• 从客户端收集指标和遥测数据
• 能够在监控服务器中进行大规模分析和聚合
• 能够下钻到根本原因的深入排查能力

当你把这些做到位之后，在一个服务部署中发现问题和趋势变化的时间，从数天缩短到数分钟。它依赖于监控，而不是用户投诉。问题可以被追溯到根本原因，而不需要找用户进行漫长的调试会议。你在用户流失之前就能捕获到回归问题。你可以带着信心（和数据）去与你的 CPaaS 或视频 API 或基础设施供应商据理力争。

这才是你的服务应该达到的状态。尤其是在用户如今期望即时响应的时代。

先看清楚，再重构

有问题需要解决？

客户抱怨。质量差。连接有限。

在你着手修复之前，先去给客户端代码埋点。在 WebRTC 中，这意味着在整个通话过程中以及所有通话中收集 getStats()。这些信息必须被收集和保存下来，这样你才能做出基于数据而非感觉的决策。

没有这些数据，不要从 P2P 切换到 SFU，也不要反过来。

不要因为 AV1 视频质量更好就去采用它，在理解 VP8 为什么不够用之前（对很多场景来说它够用了）。

不要急着换 CPaaS 供应商。从 LiveKit 跳到 Janus，跳到 Jitsi，跳到 mediasoup，再到自建，再到其他什么——在理解问题出在哪之前，先别动。

不要追逐最新的时髦技术（叫它 MOQ？），如果你对 WebRTC 的理解还不够深，还不清楚它能做什么和不能做什么。

你首先需要做的？确保你能”看见”问题。在迈向新的架构决策之前，先让脚下有坚实的地面。