最近把一篇旧的 Android WebRTC + Go gRPC 对接记录重新整理成了脱敏后的工程复盘。 文章地址： https://www.lodan.me/zh-cn/posts/golang-grpc-webrtc-android/ 这次重点不是讲某个 API 怎么调，而是把边界拆清楚： - Go/gRPC 信令层负责设备注册、会话控制、回调事件和 SDP/ICE 转发。 - Android 客户端负责权限、页面生命周期、本地音视频资源和 UI 状态同步。 - WebRTC PeerConnection 负责 offer/answer 、ICE candidate 、track add/remove 和连接状态。 - 排查问题时，日志至少要能串起 call id 、peer id 、signaling state 、ICE state 和 selected candidate pair 。 我现在的判断是：如果这些边界混在一起，线上问题很容易变成“看起来像网络问题”“看起来像设备问题”“看起来像 SDK 问题”。边界清楚以后，排查路径会直接很多。 想讨论一下：大家做 Android WebRTC 或 RTC Gateway 时，通常会把多少信令/状态逻辑放在客户端，多少放在本地网关或服务端？
最近把一篇 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 ，还是自定义心跳/发现机制？
最近把一篇 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 ，还是自定义心跳/发现机制？