DEV Community

snowlyg
snowlyg

Posted on • Originally published at snowlyg.github.io

Debugging Android 14 WebRTC Disconnects on a coturn Relay Path

#webrtc

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
Enter fullscreen mode Exit fullscreen mode

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

  1. Force the path through coturn so direct LAN candidates did not hide the issue.
  2. Test a newer WebRTC build to rule out a simple SDK version mismatch.
  3. Expand the device matrix until the issue narrowed around Android 14 behavior.
  4. Re-check TURN-side certificate/security settings and required port exposure.
  5. 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.

Full write-up:
https://snowlyg.github.io/posts/android14-coturn-webrtc-disconnect/

Top comments (0)