[bug] Intermittent audio+video freezes on Wi-Fi only

[furkanKotic]

Title

Intermittent audio+video freezes on Wi-Fi only (both publish & subscribe stall), not resolved by TURN/relay; works fine on mobile data and with another RTC SDK

Description

We’re seeing intermittent, short freezes (audio + video) for some Android publishers only on Wi-Fi. During the freeze, the participant’s outbound (publishing) and inbound (subscribing) media both stall. Dropped frames increase and the stream resumes after a short period, but freezes repeat frequently.

This does not reproduce on mobile data (4G/5G). It also does not reproduce with another RTC provider SDK (same app, same device, same network), suggesting a stack/transport behavior difference rather than a pure network outage.

We tried multiple mitigation strategies (TURN/relay, custom coturn, bitrate caps, etc.) without improvement.

---

Environment

• Client SDK: livekit_client (Flutter) 2.6.4
• Platform: Android Xiaomi 12 lite
• Codec: H264 hardware encoder
• Network: Wi-Fi (issue). Mobile data does not show issue.
• Server: self-hosted LiveKit cluster (multiple nodes) behind HTTPS/WSS domain (Caddy L4 SNI routing), shared Redis.
• TURN: tested embedded TURN and external coturn (details below)

---

Symptoms

• During freeze:

  • audio + video freeze simultaneously for the affected participant
  • subscriber streams to that participant also freeze (they stop receiving other tracks temporarily)
  • dropped frames increase; later recovers

• Repeats frequently, but each freeze is short (seconds)

• Mobile data: stable (no freezes)

• Other RTC SDK in same app/environment: stable (no freezes)

---

What we observed in stats

We added periodic stats snapshots (every 2s) including:

• ICE selected candidate pair: RTT, availableOutgoingBitrate
• local candidate type/protocol (srflx/relay, udp)
• VideoSenderStats: packetsLost, jitter, roundTripTime, pliCount/nackCount, framesPerSecond, qualityLimitationReason

In freeze windows we see:

• spikes in jitter and/or packetsLost, and retransmissions rising
• connection quality dropping to poor
• sometimes availableOutgoingBitrate drops sharply
• happens with both direct srflx UDP and TURN relay UDP (depending on test)

---

Steps to reproduce

1. Connect to a room and start publishing audio+video from an Android device on a Wi-Fi network known to be affected.
2. Observe intermittent freezes where audio+video stop and the device also stops receiving other tracks temporarily.
3. Switch the same device to mobile data → issue disappears.

---

Expected behavior

Stable publish/subscribe on Wi-Fi similar to mobile data; short-term Wi-Fi jitter should degrade quality gracefully, not cause frequent full stalls.

Actual behavior

Frequent short stalls/freezes (audio+video) on Wi-Fi for some devices/networks, with dropped frames increasing and stream resuming later.

---

Troubleshooting / mitigations tried

TURN / Relay

• Forced relay-only:

  • iceTransportPolicy: relay

• Tested embedded TURN and custom coturn:

  • TURN connectivity checks succeed
  • freezes persist even when using relay candidates

• Attempted TCP relay forcing; Android WebRTC appears to still request UDP transport for TURN allocation (coturn shows 442 UDP Transport is not allowed when UDP relay disabled). So TCP media relay is not reliably achievable here.

Bitrate / resolution

• Max bitrate is already modest (~1200–1500 kbps)
• qualityLimitationReason is often none after ramp-up; still freezes occur
• Attempted VP8 / simulcast experiments; did not resolve issue

Server/network checks

• Basic reachability tests (HTTPS/WSS, TURN TLS handshake, STUN UDP reachability) are stable from a desktop environment
• Cluster/Redis healthy; no server-side crashes during freezes

---