RTC Inspector 是一个轻量、离线优先的 WebRTC Dump 分析桌面工具。它在本机解析 Chrome WebRTC Internals 和 rtcstats 日志，将分散的数据整理成概览、事件、SDP、ICE 和 Stats 视图，也支持把同一通话的多份日志合并，以及对比两次不同的通话。

开源地址

项目已在 GitHub 开源：

Est-Rogister/webrtc-dump-inspector

RTC Inspector 基于 Tauri 2、Rust、React、TypeScript 和 ECharts 构建。目前的主要目标平台是 macOS 和 Windows。所有日志都在本地桌面进程中解析

本地开发需要 Node.js 20+、npm 10+ 和 Rust stable：

git clone https://github.com/Est-Rogister/webrtc-dump-inspector.git
cd webrtc-dump-inspector
pnpm install
pnpm run dev

pnpm run dev 会同时启动 Vite 开发服务和 Tauri 桌面窗口。文件导入依赖 Tauri 原生能力，需要在桌面窗口中操作，不能只打开浏览器里的 Vite 页面。

如何使用 chrome://webrtc-internals/

1. 打开采集页面

在 Chrome 地址栏输入：

chrome://webrtc-internals/

建议在发起通话前打开该页面，并在整个问题复现过程中保持页面开启。随后回到需要测试的 WebRTC 页面，完成加入房间、发布或订阅音视频、切换设备、共享屏幕、重连等操作。

为了让日志更有诊断价值，最好记录清楚复现时间和操作步骤，例如“14:32 加入房间，14:33 开始共享屏幕，约 20 秒后远端画面卡住”。这些时间点可以帮助后续将用户现象与 Stats 曲线、状态变化对应起来。

2. 复现并导出 Dump

问题复现完成后，返回 chrome://webrtc-internals/。在页面顶部找到 Create a WebRTC-Internals dump 按钮，点击 Download the PeerConnection updates and stats data和Download the "rtcstats dump导出的文件名分别为 webrtc_internals_dump .gz和rtcstats_dump .gz

Snipaste_2026-09-15_10-15-45.png

采集时有三个细节值得注意：

  1. 尽量只保留与本次复现相关的页面和通话，减少无关 PeerConnection 干扰。

  2. 不要在问题出现后立刻关闭通话页面，先导出 Dump，以免遗漏最后阶段的状态。

  3. Dump 是某个时间点的诊断快照，不包含媒体包内容，也不能代替抓包或服务端日志。

3. 导入 RTC Inspector

启动 RTC Inspector 后：

  1. 点击“新建 Session”，选择刚导出的 Dump。

  2. 如果同一次通话还有 rtcstats 日志或另一端的日志，可以一次选择多份文件，或者使用“添加数据源”补充到当前 Session。

  3. 在左侧依次查看“概览、事件、SDP、ICE、Stats”。

  4. 如果要比较正常通话和异常通话，分别创建两个 Session，再进入“对比”模式选择 Baseline 和 Target。

同一 Session 中，相同 PeerConnection ID 的数据会自动聚合，重复事件、SDP、ICE 候选、候选对和 Stats 会去重。批量导入时，单个文件解析失败不会影响其他文件继续分析。

4. 从哪里开始排查

可以按下面的顺序快速缩小问题范围：

  • 概览：先确认 PeerConnection 数量、连接状态、媒体方向、编解码器和日志时间范围是否符合预期。

  • 事件：检查 createOffer、setLocalDescription、setRemoteDescription 等调用，以及 signaling、ICE 和 connection 状态的变化顺序。

  • SDP：确认音视频 m-line、方向、Payload Type、编解码器和协商结果。

  • ICE：查看本地与远端候选类型，以及最终选中的候选对。使用 relay 候选通常意味着媒体经过 TURN；只有 host 候选时，则需要留意 NAT 和网络可达性。

  • Stats：将发送/接收码率、丢包、帧率、RTT 和可用上行带宽放到同一时间线上，观察异常是否同时发生。

单个指标通常不足以下结论。例如，码率下降可能来自可用带宽下降、持续丢包、编码器降级，也可能只是画面内容进入静止状态。更可靠的方式是结合事件、ICE 路径和多条 Stats 曲线交叉判断。

已经实现的功能

当前 v0.2.0 已经完成一套可用的离线分析闭环：

双格式与压缩文件解析

  • 自动识别 Chrome WebRTC Internals 与 rtcstats Dump，不依赖固定文件名。

  • 支持原始文件和 gzip 压缩文件。

  • 文件损坏、格式无法识别或部分数据异常时返回结构化错误。

连接、SDP 与 ICE 分析

  • 汇总 PeerConnection、信令、连接状态、媒体方向和编解码器。

  • 展示 PeerConnection API 调用与状态变化时间线。

  • 查看 Local/Remote Offer、Answer 和 SDP 原文。

  • 展示本地与远端 ICE 候选、候选类型、选中候选对、RTT 和可用带宽。

  • 当日志没有直接记录 ICE gathering 状态，但已经存在有效候选和选中候选对时，标注 complete（推断），明确区分原始记录与推断结果。

Stats 趋势可视化

  • 展示发送与接收码率、丢包、帧率、RTT 和可用上行带宽趋势。

  • Stats 原始数据保存在 Rust 侧，前端按视图查询并限制返回点数，避免大时间序列直接压入 WebView。

多日志聚合与 Session 对比

  • 将同一通话的多份日志归入一个 Session，并保留数据源列表。

  • 对事件、SDP、ICE 和 Stats 进行聚合与去重。

  • 独立管理多个 Session，并排比较概览、事件、SDP、ICE 和 Stats。

  • 对比图表按每个 Session 的相对起点对齐，便于比较两次通话的质量变化。

后台导入与本地处理

  • Rust 后台任务队列支持批量解析、文件级进度和取消操作。

  • 单个来源失败时保留其他成功结果。

  • Session、来源和原始 Stats 统一保存在 Rust Session Store 中。

  • 日志全程在本机处理，不依赖云端分析服务。

未来实现的功能

Session 持久化与可分享报告

  • 保存 Session 元数据、索引、命名和用户标注，重启应用后可以继续分析。

  • 支持最近项目和原始文件重新关联。

  • 完善 macOS、Windows 的持续集成、安装验证、签名和发布流程。

外部 Chrome 实时采集

未来计划由 RTC Inspector 启动一个使用临时 Profile 的独立 Chrome，通过 Chrome DevTools Protocol 管理页面，并注入 WebRTC instrumentation，实时采集 RTCPeerConnection API、SDP、ICE、Console、Network 和周期性 getStats() 数据。

这部分不会复用用户日常浏览器 Profile，调试端口只监听本机，结束实验后会清理 Chrome 进程和临时数据。实时采集的数据仍会进入现有的 Rust Session Store，从而复用离线 Dump 的分析和对比能力。

隐私与使用边界

WebRTC Dump 可能包含本地或公网 IP、端口、ICE ufrag、SDP、访问页面 URL、设备信息以及业务标识。即使 RTC Inspector 不上传日志，在把原始文件或截图发给他人前，仍应先完成脱敏，并确认接收范围。

还需要明确的是，WebRTC Internals 只是客户端证据的一部分。复杂问题通常仍需要结合信令服务日志、TURN 日志、SFU/MCU 指标、服务端事件和必要的网络抓包。RTC Inspector 的价值，是先把浏览器侧最分散、最难读的一组信息整理清楚，让后续排查有一个可靠起点。