Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#1,221 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
android
Ambito
mobile-dev

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Dart
Stelle
421
Fork
260
Merge medio
2g 5h
PR unite (30g)
17

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di livekit/client-sdk-flutter

Tutte le issue di livekit/client-sdk-flutter

Issue simili

Altre issue su Dart

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.