Could you please clarify under what circumstances a LiveKit session times out and why the reason received in the webhook triggered to our backend service is reported as “UNKNOWN_REASON”?

Thanks for reaching out, Jasmeet. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

My Flutter app uses SDK version 2.5.1, and my livekit-server, which is self hostted has version 1.9.3. Flutter app show error session timeout but i my webhook there is “unknow-reason” of disconnect.

Thanks — I’m responding about your Flutter app (SDK 2.5.1) showing session timeouts while your self-hosted server is v1.9.3 and webhooks report UNKNOWN_REASON. This is a version compatibility issue. SDK 2.5.1 expects a newer server; your server v1.9.3 can produce unexpected disconnects that map to UNKNOWN_REASON. To fix this: 1. Upgrade your self-hosted LiveKit server to v2.0.0 or later so it’s compatible with Flutter SDK 2.5.1. 2. After upgrading, reproduce the timeout and check webhooks again — the disconnect reason should be a known enum value instead of UNKNOWN_REASON. 3. If the issue continues, enable debug logging on the server and capture: ◦ server logs around the disconnect time ◦ the raw webhook payload your backend received ◦ the client-side logs from the Flutter SDK Which would you like to do first — proceed with the server upgrade, or collect logs now? Sources: client-sdk-js | livekit/livekit_composite | DeepWiki

but the livekit-server latest version is v1.9.8 which is publish last week

Thanks — I see you’re saying the latest self‑hosted server is v1.9.8. That helps clarify things: Flutter SDK 2.5.1 expects server behavior that isn’t guaranteed on the 1.9.x line, so mismatches can still produce session timeouts and webhooks marked UNKNOWN_REASON. Two practical options: • Downgrade the Flutter SDK to a 2.4.x client that is compatible with LiveKit server 1.9.8. • Move the server to a release that provides the protocol/enum compatibility required by SDK 2.5.1 once a 2.0.0+ server build is available. I can help with either path: • If you want to downgrade the Flutter SDK, tell me your current pubspec and I’ll recommend a specific compatible client version and any code changes to watch for. • If you prefer to wait for or plan a server upgrade, I can list the server-side logs and webhook fields to capture so we can re-check disconnect reasons after upgrading. Which would you like to do?

This issue occurred when we shifted our server from c4.xlarge to c6i.8xlarge. Do you think this makes any change? We just changed the instance type without any config changes.

Thanks — I’m responding to both parts: whether the instance type change could cause your session timeouts/UNKNOWN_REASON, and what to check next. Short answer • Changing from c4.xlarge to c6i.8xlarge does not change LiveKit’s DisconnectReason enum or protocol behavior, so it won’t directly turn a known disconnect into UNKNOWN_REASON. The primary root cause remains the client/server compatibility mismatch between your Flutter SDK and the 1.9.x server line. Possible indirect effects of the instance change • Networking: if the instance’s IP, VPC, subnet, or security groups changed, you could see connectivity interruptions or packet loss that cause clients to drop and trigger timeouts. • Firewall/NAT/idling: different instance placement or NAT behavior can affect long‑lived WebSocket/UDP connections. • Resource or kernel/network driver differences: a much larger instance could have different NIC drivers, ENA settings, or kernel tunables; misconfiguration could cause jitter, MTU, or throughput anomalies. • DNS or load balancer changes: if you reattached the instance behind a LB or changed DNS TTL, clients might briefly reconnect to different endpoints. What to check now (quick list) 1. Confirm client/server versions and compatibility — the SDK/server mismatch is still the likely source. 2. Inspect server logs around disconnect times for network errors, process restarts, or OOMs. 3. Check system/network metrics on the new instance (packet drops, interface errors, CPU, memory). 4. Verify no IP/SG/NACL/DNS changes occurred and that keepalives are allowed through your network path. 5. Capture the raw webhook payload and client logs at disconnect time to see any client-side error codes or network error messages. If you want, I can: • Provide the exact log lines/fields to look for on the server and client. • Suggest commands to check network/interface stats on the instance. Which would you like me to give next?

We also add ASG and a load balancer. Does this make any type of changes?

Thanks — I’m responding about whether adding an ASG and load balancer could affect your LiveKit sessions and produce timeouts / UNKNOWN_REASON. Short answer • Yes. Adding an ASG and a load balancer can introduce networking behaviors that break long‑lived LiveKit connections (WebSocket/UDP) and cause clients to disconnect or report unclear reasons — even though they don’t change enums or protocol semantics. What specifically can cause trouble • Connection stickiness: if the LB isn’t configured for session affinity, subsequent requests or WebSocket upgrades can hit a different backend instance and tear the session. • Idle timeouts / health checks: LBs often close idle TCP connections after a timeout or mark instances unhealthy from aggressive health checks, forcing reconnects. • Port/protocol handling: LiveKit uses signalling (WebSocket/TCP) and media (UDP). Some LBs only handle TCP and may break UDP media paths or not forward WebRTC candidate traffic correctly. • ASG scaling/replacements: instance termination or replacement can abruptly drop connections if not drained gracefully. • NAT/load balancer IP changes: changes in client-visible IPs can affect STUN/ICE behavior and cause renegotiation failures. • Sticky network differences between instance types (drivers, ENA) are still possible but secondary to LB/ASG behavior. Practical checks and mitigations 1. Ensure WebSocket affinity / sticky sessions on the LB so signalling stays on the same instance. 2. Set LB idle timeouts longer than your expected session inactivity (or disable aggressive timeouts). 3. Use a load balancer that supports UDP or terminate only signalling at the LB and allow direct UDP for media (or use a TURN/relay that’s reachable). 4. Configure graceful draining on ASG scale-in so existing connections finish before termination. 5. Ensure health check paths are lightweight and don’t cause frequent flaps; exclude long‑lived connections from health checks. 6. Check LB logs and metrics for connection resets and backend switching during disconnect windows. 7. Verify ICE candidate flow (STUN/TURN) from clients after the change — look for failed candidate pairings in client logs. 8. Collect server logs, LB access logs, and client logs timestamped around a disconnect to correlate events. Next step • Tell me which load balancer type you’re using (ALB, NLB, Classic, or an external LB) and whether it’s configured to forward UDP or only TCP/WebSocket, and I’ll give exact LB settings and health‑check values to use.