记录一次 Android 14 + coturn 下 WebRTC 通话 30 秒后断开的排查

[snowlyg]

最近整理了一次 WebRTC 问题排查，脱敏后记录一下。

背景是一个 Android WebRTC 音视频通话场景。原来主要在内部网络使用，后续为了支持更复杂的网络边界，引入了 `coturn` 做 TURN 中继。

问题现象：

- Android 14 设备和旧版 Android 设备通话时，Android 14 端经常在 30-60 秒内自动退出。
- 旧版 Android 设备基本正常。
- 少数情况下双方也能持续正常通话。
- 强制走 TURN relay 后更容易稳定复现。

一开始日志里有一条本地地址相关的中继协商 timeout ，而且经常出现在断开前后，所以很容易误判为根因。

后面看 WebRTC 状态变化，真正关键的是：

```text
IceConnectionChange -> DISCONNECTED / FAILED
StandardizedIceConnectionChange -> DISCONNECTED / FAILED
```

排查过程大概是：

1. 先统一链路，强制走 `coturn`，避免内部网络直连把问题掩盖掉。
2. 替换过 WebRTC 依赖版本，排除单纯的 SDK 版本问题。
3. 扩大设备矩阵，问题逐渐收敛到 Android 14 设备。
4. 回到 TURN 服务侧检查证书、安全参数和端口开放。
5. 调整 `coturn` 相关配置后，同样测试矩阵下不再出现 30-60 秒自动断开。

这次最大的教训是：WebRTC 问题不要只盯某一条高频日志。更可靠的路径是先看 ICE 状态机、candidate pair 、当前到底走的是直连还是 relay 。

另外，直连和中继混在一起测，很容易让问题看起来像“网络随机抖动”。强制走 relay 后，问题才变成可复现、可分析。

欢迎交流 Android WebRTC 、coturn 、TURN relay 和 RTC Gateway 稳定性问题。

完整整理在这里：
https://snowlyg.github.io/posts/android14-coturn-webrtc-disconnect/

[lel020]

比起具体的问题和原理，我更想知道，像这样的问题，AI 有没有办法解决？多少提供点思路的话，AI 能不能自己分析出这个问题？

[snowlyg]

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

[snowlyg]

补充一个排查方法点，不重复主帖背景：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 测试方式？