Guest connection dropping with DTLS timeouts after recent LiveKit Server Update

Self Hosting
,
1

Hello everyone,

I recently updated my self-hosted bare-metal LiveKit server container. Ever since the update, my guests are experiencing severe connection stability issues and continuous audio dropouts during live streams.

My Architecture:

  • Host: Pushing a local mix out of OBS Studio via Ingress WHIP.
  • Guest: Joining the room via a normal browser link, generated from my app.
  • Production Mix: Pulling the guest’s stream back into OBS Studio via an OBS Browser Source (LiveKit JS SDK v2.18.1).

The Bug:
The host stream stays stable. However, when checking the server logs for the guest participant, the session is failing after less than 10 seconds. The server drops the connection and throws multiple data channel warnings: dtls timeout: read/write timeout: context deadline exceeded across the _reliable, _lossy, and _data_track labels. (While my guest is talking, their Audio keeps dropping, or cutting in & out. ) Which, I do try to have them wear headphones, though most are Athletes, and do are joining me, just before or after a game.

The update was supposed to address latency/lag, but it has introduced a strict transport or timeout threshold that is aggressively dropping the guest’s data channels. What is the correct course of action on a bare-metal deployment to adjust DTLS timeouts or ICE handshake rules to keep these guest data tracks alive?

2

@DoC_DiD_iT, That error is a symptom, not a knob. dtls timeout: context deadline exceeded across _reliable/_lossy/_data_track means the guest’s transport never established; the data-channel warnings are downstream (#4195).

The cause is the update itself: v1.13.1 dropped backwards compatibility for TURN auth without a TTL (v1.13.1 notes, #4539). If your TURN creds used the old no-TTL form, TURN broke on upgrade, and guests on mobile or stadium NAT need TURN to relay, so their ICE path never completes. The WHIP host is fine because Ingress ingests server-side.

Fix is TURN, not timeout tuning: re-issue TURN credentials with a TTL, then confirm the TURN ports (turn.udp_port 3478, turn.tls_port 5349) and ICE/UDP range (rtc.port_range_start..rtc.port_range_end) are open (ports & firewall).