snowlyg

原来你公司也这样啊，看来大部分小公司基本都差不多

@cz5424 中转站应该是最近的大风口了吧

AI 改复杂一点的项目，AI 翻来覆去的改不好一个 BUG 了。你就知道其中的痛苦了。

@sponme 哈哈，996 都是福报。双休怎么不算福利。

HR 不搞点事情做，下岗的就是他了。

@Licsber 哈哈，博客的文章是 AI 自己重新整理的。原文章链接在我的 GITHUB 首页。

补充一个排查方法点，不重复主帖背景：WebRTC 断连时，direct path 和 TURN relay path 最好先拆开看。

我这次比较有用的做法是：

1. 不先追某一条 timeout 日志，而是先看 ICE state 是否进入 `DISCONNECTED / FAILED`。
2. 看 selected candidate pair ，确认当前媒体链路到底是 host / srflx / relay 。
3. 强制走 TURN relay ，避免局域网直连把问题掩盖掉。
4. 在同一组设备矩阵下反复跑 relay-only 测试，确认问题是否稳定复现。
5. 再回到 coturn 侧检查证书、安全参数和端口开放。

这次的体感是：如果 direct 和 relay 混在一起测，很容易把问题看成“网络随机抖动”；强制 relay 后，问题才更像一个可以复现、可以收敛的工程问题。

想请教一下大家：你们在 WebRTC 线上问题里，一般怎么确认当前真实走的是哪条 candidate path ？有没有更稳定的 relay-only 测试方式？

@lel020 很遗憾经过验证。音视频的问题，AI 能给的建议只能给一些参考。大部分都没什么用处，还有一些还会导致更严重的问题。