WebRTC + Go gRPC Call Architecture for Constrained LAN Environments

snowlyg — Wed, 27 May 2026 14:29:46 +0000

I published a new architecture recap on building WebRTC calls around a Go gRPC signaling layer and Android clients in constrained LAN environments.

The design is intentionally split into clear ownership boundaries:

gRPC signaling handles device state, session control, and event delivery.
WebRTC owns SDP/ICE negotiation, media tracks, selected candidate pairs, and transport state.
Android clients own runtime permissions, audio/video resource management, UI state, and lifecycle cleanup.
An RTC Gateway gives the system a place for discovery, recovery, session mapping, and observability.

The main lesson is that call setup is only the beginning. The real engineering work is in recovery and observability: LAN paths can change, devices can restart, sessions can become stale, audio quality can degrade, and gateway state can drift away from client state.

Full write-up:
https://www.lodan.me/posts/webrtc-grpc-lan-call-architecture/

This is part of a longer series on WebRTC reliability, AEC dump debugging, server-side noise suppression, and RTC Gateway concurrency issues.

Debugging Android 14 WebRTC Disconnects on a coturn Relay Path

snowlyg — Sat, 23 May 2026 09:14:29 +0000

I recently wrote up a debugging case around Android WebRTC, coturn, TURN relay, and ICE failures. This is the anonymized version because the useful part is the debugging method, not the original environment.

Context

Android WebRTC audio/video call.
The service originally worked mostly on an internal network.
A TURN relay path through coturn was introduced for more complex network boundaries.
Older Android devices were mostly stable.
Android 14 devices often disconnected after 30-60 seconds.
Forcing the media path through TURN relay made the failure much easier to reproduce.

The Misleading Clue

The first clue looked obvious: a repeated timeout around a local relay-related address. It appeared near the disconnect window, so it was tempting to treat it as the cause.

That was not enough.

In WebRTC debugging, a noisy log line can be real without being the root cause. The better starting point was the ICE state transition:

IceConnectionChange -> DISCONNECTED / FAILED
StandardizedIceConnectionChange -> DISCONNECTED / FAILED

That moved the investigation away from "why does this timeout appear?" and toward "why does the selected media path fail?"

What Helped Narrow It Down

Force the path through coturn so direct LAN candidates did not hide the issue.
Test a newer WebRTC build to rule out a simple SDK version mismatch.
Expand the device matrix until the issue narrowed around Android 14 behavior.
Re-check TURN-side certificate/security settings and required port exposure.
Re-test the same matrix after adjusting the TURN-side configuration.

After the TURN-side changes, the 30-60s disconnect stopped reproducing in the same test matrix.

Takeaways

For WebRTC production issues, I would rather start from:

ICE state transitions.
Selected candidate pair.
Whether the call is using host, srflx, or relay candidates.
TURN server logs and port exposure.
Client-side network and app lifecycle events.

The loudest log line is useful, but it should not be allowed to define the investigation by itself.

WebRTC reliability is usually a system problem: client version, network path, TURN configuration, device behavior, and application state handling all interact. Treating it as a single log-line problem can waste a lot of time.