https://livekit.io logo
Join Slack
Powered by
I am seeing frequent Participant left (CONNECTION_...
# ask-ai
h
I am seeing frequent Participant left (CONNECTION_TIMEOUT). I do not know what is the reason, is it bad agent config or livekit infra issue? Agent is deployed on livekit cloud(using build plan). Its happening for all session.
t
Thanks for reaching out, Rahul. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — I’m sorry you’re hitting frequent "Participant left (CONNECTION_TIMEOUT)". I’ll help pinpoint whether this is agent config or network/infra. Quick summary of likely causes: • This reason is for the media (WebRTC) connection timing out, not signaling. Common causes are client-side network problems (packet loss, UDP blocked, NAT/firewall changes), DTLS/SRTP handshake failures, or abrupt client crashes. • LiveKit Cloud addreses infra reliability, but media-path issues between client and media node are outside LiveKit’s control. Misconfigured ICE/TURN or agent networking can also cause this. To narrow it down, please provide or try the following (start with 1–3 and report results): 1. Reproduce scope ◦ Does this happen for all users on all networks, or only certain networks/devices? 1. Connection checks ◦ Run the Connection Test utility from affected clients and share results (WebSocket, WebRTC, TURN checks). 1. TURN/ICE config ◦ Confirm the agent’s TURN/ICE settings (are you forcing TURN? custom TURN credentials?). 1. Logs and timing ◦ Share an example session timestamp + agent logs around a disconnect. Look for ICE/DTLS failures or abrupt process exits. 1. Network details ◦ Are clients behind restrictive firewalls (corporate networks, mobile carriers)? Any consistent NAT type or router brand? 1. Client SDK version ◦ Which LiveKit client SDK and version are you using? Are agents on the Build plan using the default deployment with no custom network rules? If you prefer, start by telling me: • One example session timestamp (UTC) and participant ID, • Client network type (home Wi‑Fi, corporate VPN, mobile), • Whether the Connection Test shows TURN failing. With that I can point to targeted next steps (agent config checks, TURN testing, or deeper log analysis). Sources: Understanding the STATE_MISMATCH Disconnect Reason | Firewall Tips | Diagnosing Connection Errors with Connection Test Utility | Why is my Agent insights data missing? | LiveKit | Server lifecycle | LiveKit Documentation, with interactive elements
h
TURN/ICE config ◦ Confirm the agent’s TURN/ICE settings (are you forcing TURN? custom TURN credentials?). how to check this
t
Thanks — I’ll walk you through how to check TURN/ICE for your agent and client. Short answer: TURN/ICE settings are controlled by the client SDK that connects to LiveKit (the agent process acts as a client). To check whether TURN is forced or custom credentials are used, inspect the client/agent connection options and run the Connection Test utility. Please try these steps and share results: 1. Inspect client/agent code ◦ Look for 
rtcConfig
when calling 
connect(...)
. ◦ If you see 
iceTransportPolicy: 'relay'
— TURN is being forced. ◦ If you see an 
iceServers
array with custom entries, those are custom TURN/STUN servers. 1. Run the Connection Test (diagnostic) ◦ Use the Connection Test / ConnectionCheck in your client SDK to check WebSocket, WebRTC, and TURN. ◦ Example (JS):
Copy code
const checker = new ConnectionCheck({ url: 'wss://your-project.livekit.cloud', token: 'YOUR_TOKEN' });
   const turnResult = await checker.checkTURN();
   console.log(turnResult.status);
• If TURN fails but other checks pass, TURN connectivity is blocked by the network. 1. Verify whether LiveKit’s default TURN is being used ◦ If no 
iceServers
are configured, LiveKit supplies TURN automatically (
*.turn.livekit.cloud
). ◦ No code = default TURN behavior. 1. Check common network blockers ◦ Corporate proxies/DPI (e.g., Zscaler) or strict firewalls often block UDP/DTLS or inspect TLS and break DTLS. Ask your network team to allow/whitelist 
turn.livekit.cloud
and your project domain and disable protocol inspection for those domains. What to send me next (this helps me pinpoint root cause): • A short snippet of your agent/client connect call (the 
connect(...)
options). • Result of the Connection Test (especially TURN status). • One example session timestamp + participant ID and the client network type (home Wi‑Fi, corp VPN, mobile). I’ll use that to recommend the next steps (change client config, test TURN routing, or dig into logs). Sources: Firewall Tips | Diagnosing Connection Errors with Connection Test Utility | Zscaler proxy configuration, with interactive elements
h
this code i am using await ctx.connect(auto_subscribe=AutoSubscribe.AUDIO_ONLY)
t
Thanks — this 
await ctx.connect(auto_subscribe=AutoSubscribe.AUDIO_ONLY)
call does not show any TURN/ICE options. That means the agent is using the client SDK’s default ICE behavior (LiveKit will supply TURN automatically if needed). Next steps to verify and debug TURN/ICE: 1. Check the code path that creates the underlying RTC connection ◦ Find where 
ctx.connect
is implemented/which client SDK version you’re using and inspect if it accepts an `rtcConfig`/`iceServers` or 
iceTransportPolicy
option. ◦ If you don’t set 
iceTransportPolicy: 'relay'
, TURN is not being forced. 1. Look for any explicit 
iceServers
in your client/agent code ◦ If present, those are custom TURN/STUN entries and may override defaults. 1. Run the Connection Test / ConnectionCheck from the same environment as the agent ◦ Example JS usage (adjust for your SDK): create a ConnectionCheck with your project URL + token and run `checkTURN()`; confirm status is 
SUCCESS
or share the failure details. 1. Collect a short log sample ◦ When a participant disconnects, capture agent/client logs around the disconnect—look for ICE candidate exchange, DTLS handshake errors, or ICE failures. If you want, paste: • The file/lines where 
ctx.connect
is defined or the client SDK + version, • Output of a ConnectionCheck TURN test, • A short log around a disconnect. I’ll point to exact config changes or tests to run next. , with interactive elements
h
there is nothing like 
iceServers
in agent code
t
Thanks — since there’s no 
iceServers
and you’re not passing 
rtcConfig
, your agent is using the SDK’s default ICE behavior (LiveKit will provide TURN servers when needed). That means the issue is unlikely caused by a custom TURN config in your agent code. Next focused steps to debug CONNECTION_TIMEOUT: 1. Run a ConnectionCheck from the same host/environment as the agent and share the TURN result. ◦ If you’re not using JS, tell me the SDK language/version and I’ll give the exact snippet to run. 1. Collect a short log around a disconnect (15–30s before/after) and look for: ◦ ICE candidate exchange lines ◦ DTLS handshake failures ◦ ICE timeout/failure messages 1. Test from multiple networks/devices: ◦ If disconnects only happen on specific networks (corporate, mobile), suspect firewall/DPI blocking UDP/DTLS. ◦ If it’s everywhere, share SDK version + agent deployment details. If you want, tell me your SDK language/version now and I’ll provide the exact ConnectionCheck snippet and the specific log lines to look for. , with interactive elements
h
i use python sdk for agent
t
Thanks — since you’re using the Python SDK, here’s how to verify and test TURN/ICE from that environment and what to collect next. 1) Verify you’re using default ICE • If your connect call has no `rtc_config`/`ice_servers` and no 
ice_transport_policy
, the SDK uses default ICE and LiveKit supplies TURN automatically. 2) How to force TURN or supply custom TURN (Python) • You can pass 
rtc_config
when connecting. Example:
Copy code
from livekit import RTCConfig
rtc_cfg = RTCConfig(ice_transport_policy="relay")  # force TURN
await ctx.connect(rtc_config=rtc_cfg, auto_subscribe=AutoSubscribe.AUDIO_ONLY)
• To supply custom TURN servers, set 
ice_servers
on 
RTCConfig
. 3) Run a connection/TURN check from the agent host • Use the ConnectionCheck equivalent for Python (or run a small JS check from the same host/network). If you want the exact Python snippet for your SDK version, tell me the version and I’ll provide it. 4) What logs to collect (share these) • 15–30s around a disconnect. Look for: ◦ ICE candidate gathering and exchange logs ◦ ICE connection state changes (e.g., "failed", "disconnected") ◦ DTLS/SRTP handshake errors ◦ Any TURN allocation or authentication errors 5) Quick triage you can run now • Run ConnectionCheck from the same host and report TURN result (SUCCESS or FAILURE). • Test connecting the agent from a different network (home/mobile) to see if the issue follows the host or the network. • If you can, enable debug logging in the SDK and paste the log snippet for one disconnect (timestamp + participant id). Tell me: • Python SDK version, • Result of a ConnectionCheck (or say if you want the snippet), • One log snippet around a disconnect. I’ll give the exact Python code for the check and the specific log lines to look for next. , with interactive elements
2 Views
Open in Slack
PreviousNext
Powered by