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

Inbound data packets never delivered while media flows normally (2.13.0, LiveKit Cloud 1.13.7)

Abierto
  • ¿Algo no está bien?
#1,221 1 comentario 0 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
45/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
android
Área
mobile-dev

Línea de trabajo

Start by tracing Engine._onDataChannel and how _reliable and _lossy messages reach DataReceivedEvent; compare that flow with the JS client's _data_track handling and verify which channel carries the missing packets. Done means inbound data from the reported browser setup reaches the Flutter client and a regression test covers delivery.

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

Descripción

Summary

On Android with livekit_client: 2.13.0 against LiveKit Cloud (server 1.13.7), no inbound data packets are ever delivered to the client, while inbound media on the same connection works normally. DataReceivedEvent never fires. Outbound publishData from the same client is received correctly by browser participants, so the failure is inbound-only.

Two livekit-client (JS, 2.18.9) participants in the same room exchange data perfectly, so the room, the server and the publishers are fine.

Expected

A browser calling localParticipant.publishData(bytes, { reliable: true, topic: 'x' }) should surface as DataReceivedEvent on the Flutter client in the same room.

Actual

Nothing arrives. Measured over a session with zero reconnects and zero signal errors:
Inbound media 4 × TrackSubscribedEvent, 3 × AddRecvStream — works
Inbound data 0 packets, 0 DataReceivedEvent
Outbound data published fine; browser participants receive it
EngineFullRestartingEvent / RoomReconnectingEvent 0
Could not send message, socket not connected 0

Ruled out

With setLoggingLevel(LoggerLevel.kALL):

  • The server does open the channel. FINE: Server opened DC label: _reliable and _lossy, both reaching a connected state.
  • SCTP is healthy. DataChannel received OPEN_ACK message, sid = 1 and sid = 3; negotiated m=application <port> UDP/DTLS/SCTP webrtc-datachannel.
  • Not the reliable-sequence dedupe in Engine._emitDataPacket. No Ignoring duplicate or out-of-order packet is logged, and the JS client starts reliableDataSequence at 1, which passes the sequence <= lastReceived check.
  • Not a protocol mismatch. Both clients negotiate protocol=16.
  • Not transport fallback. The session ran on UDP (ICE selected UDP pairs overwhelmingly).
  • Not app-side lifecycle. The Room was created once and never disposed or reconnected during the measurement window.

Possibly relevant observation

The server opens a third data channel that this SDK drops:

FINE:    Server opened DC label: _reliable
FINE:    Server opened DC label: _lossy
WARNING: Unknown DC label: _data_track

Engine._onDataChannel switches on _reliableDCLabel / _lossyDCLabel and warns on anything else, so no onMessage handler is attached. livekit-client 2.18.9 has a third branch — dataTrackDataChannel = '_data_track' → handleDataTrackMessage — which this SDK has no equivalent of.

I can't confirm which channel the packets actually arrive on, so I'm not claiming this is the cause — but it is the one asymmetry I found between the working JS client and the failing Flutter one against the same server.

Environment

  • livekit_client 2.13.0 (latest on pub.dev at time of writing)
  • Flutter 3.41.2, Android 16 (API 36), arm64
  • LiveKit Cloud, serverVersion: 1.13.7, subscriberPrimary: true
  • Peer: livekit-client 2.18.9 in a desktop browser
  • Token grants: roomJoin, canPublish, canSubscribe, canPublishData
  • Reproduced on both WiFi and cellular

Workaround in use

Publishing on the lossy channel (outbound is unaffected either way) and polling our own server-persisted message history for anything inbound. Features with no server-side persistence — raise-hand, typing indicators — simply don't reach the Flutter client.

Happy to supply fuller logs or test a patch.

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.