复杂内网里的 WebRTC + gRPC 音视频通话方案：信令、媒体链路与自恢复

[snowlyg]

最近把一篇 WebRTC + gRPC 音视频通话方案做了脱敏整理，主要讨论复杂局域网/受限网络里，Android 终端之间做实时音视频时，信令、媒体链路和自恢复能力应该怎么拆。

这篇不是完整生产配置，而是一个架构复盘。重点是几个边界：

- gRPC 信令层负责设备状态、会话控制和事件分发。
- WebRTC 负责 SDP/ICE 、track 和媒体传输。
- Android 客户端负责权限、采集、播放、UI 状态和资源释放。
- RTC Gateway 需要承担自动发现、状态同步、故障恢复和观测入口。
- 音频质量、弱网恢复、设备重启、会话残留这些问题不能只靠业务层 timeout 判断。

文章地址：
https://www.lodan.me/posts/webrtc-grpc-lan-call-architecture/

想请教大家：在局域网或受限网络里做 WebRTC 时，你们更倾向把信令网关做成独立服务，还是内置到客户端/边缘节点？故障恢复通常靠 WebSocket 重连、gRPC stream ，还是自定义心跳/发现机制？

[Licsber]

学习了 描述的现实困难挺多 很有启发性
但 OP 的博客总感觉冗余太多 AI 优化有点过度了

我对协议了解的还不深 目前更偏向于直播分发场景
还没做到双向的语音交互（无人机场景也做不了 太吵
用 webrtc 主要是克服原来 hls 的延迟问题
找空按思路试试