Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#1,018 1 comentario 3 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
android, dart, flutter
Área
audio-video-rtc, mobile

Línea de trabajo

Start by following the reproduction steps on an affected Wi-Fi network and comparing the listed WebRTC stats with mobile data, where the issue disappears. The report does not identify a file, test, or specific code path to investigate. Done means finding a reproducible cause for the Wi-Fi stalls and an actionable fix or diagnosis.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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
Lenguaje dominante
Dart
Estrellas
421
Forks
260
Merge medio
3 d 9 h
PR fusionados (30 d)
11

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de livekit/client-sdk-flutter

Todos los issues de livekit/client-sdk-flutter

Issues similares

Más issues de Dart

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.