WebRTC 不会改善你的通话质量，可观测性才会
内容提要
WebRTC通话质量与其他VoIP协议相当，问题常在于可观测性而非协议本身。应通过getStats()收集客户端指标，深入分析根本原因，而非盲目切换技术或架构。先收集数据，再基于数据决策，避免追逐潮流。可观测性可快速定位问题，提升服务质量。
延伸解读
协议之争是伪命题
文章指出，WebRTC与SIP等VoIP协议在媒体传输上都基于RTP/SRTP，使用相同的编解码器，因此从质量角度看并无本质差异。真正影响通话质量的是实现细节和可观测性，而非协议本身。纠结于切换协议或架构，往往掩盖了真正的问题。
客户端可观测性的价值
WebRTC的getStats() API能从客户端收集详尽的指标，提供服务器端无法获得的用户体验视角。服务器端指标只能判断“是否出问题”，而客户端数据能揭示“为什么出问题”。通过客户端遥测，可以快速定位根因，缩短排障时间，甚至在用户流失前捕获回归问题。
先收集数据，再决策
文章强调，在做出架构变更（如切换SFU、更换供应商、采用新编解码器）之前，必须先收集并分析客户端数据。没有数据支撑的决策如同“追逐潮流”，可能掩盖更深层的问题。建议先埋点收集getStats()，确保能“看见”问题，再基于数据采取行动。
Q&A
WebRTC和SIP在通话质量上有本质区别吗？
没有。WebRTC和SIP都使用RTP传输媒体，都能达到同样的媒体质量水平。质量差异主要取决于实现质量，而非协议本身。
为什么说WebRTC的可观测性比协议选择更重要？
因为通话质量问题的根本原因往往在于缺乏可观测性，而不是协议本身。通过可观测性（如getStats()）可以收集客户端指标，深入分析根本原因，从而快速定位和解决问题，而不是盲目切换技术或架构。
getStats()在WebRTC可观测性中扮演什么角色？
getStats()是WebRTC提供的API，可以收集客户端通话过程中的详细指标，包括连接状态、媒体质量等。这些数据能提供服务器端指标无法给出的用户体验洞察，是进行根本原因分析和优化的重要依据。
服务器端指标和客户端指标有何不同？
服务器端指标只能猜测用户的感受，主要用来判断是否出了问题，但无法解释为什么。客户端指标（如通过getStats()收集）能直接反映用户体验，帮助理解连接和媒体体验，是进行根本原因分析的关键。
在切换技术或架构之前，应该先做什么？
应该先收集数据，进行可观测性分析。具体来说，在WebRTC应用中，需要收集getStats()数据并保存，基于数据而非感觉做决策。不要在没有理解问题根本原因的情况下，盲目切换协议、SFU或供应商。
可观测性如何帮助提升服务质量？
可观测性可以快速定位问题，将发现问题和趋势变化的时间从数天缩短到数分钟，减少对用户投诉的依赖，在用户流失前捕获回归问题，并能带着数据与供应商沟通，从而提升服务质量。
