https://livekit.io logo
Join Slack
Powered by
```Initial connection failed with ConnectionError:...
# ask-ai
n
Copy code
Initial connection failed with ConnectionError: could not establish pc connection. Retrying with another region: <https://air>-*****.omumbai1a.production.livekit.cloud {room: 'test_call_141713_ba8ba29f', roomID: 'RM_Vd9c5qfgqxm**', participant: 'test_691010', pID: 'PA_Dx368JBvQkWT'}
what could be happening?
t
Thanks for reaching out, neyssi. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — I see the error you shared: "ConnectionError: could not establish pc connection" when joining room 
test_call_141713_ba8ba29f
, and that the client retried using another region (
omumbai1a.production.livekit.cloud
→ another region). That error means the WebRTC peer connection (PC) couldn’t be established during signaling/ICE negotiation. Here are the most likely causes and clear next steps you can take. Most likely causes • Network/firewall blocking: UDP or other traffic required for direct WebRTC is blocked by a corporate firewall or NAT. If TURN is not reachable/available, the connection will fail. • ICE negotiation failure: STUN/TURN unreachable, NAT traversal issues, or no viable candidate pair found. • Region-specific routing problems or transient server issues: the initial region may be unreachable or experiencing problems (retrying other regions is a valid fallback). • Client-side constraints: less common for this error, but device/browser restrictions or missing media permissions can complicate setup. Immediate troubleshooting steps 1. Run the LiveKit Connection Test utility to check WebSocket, WebRTC, and TURN reachability: ◦ This quickly shows if STUN/TURN or WebSocket is blocked or misconfigured. 1. Try forcing TURN relay (if you suspect firewall restrictions): ◦ In the client connection options, set the ICE policy to use relays only:
Copy code
connectOpts.rtcConfig = { iceTransportPolicy: 'relay' };
• This forces TURN usage (often succeeds behind restrictive firewalls). If your TURN server supports TCP/TLS (port 443), that’s most reliable in corporate networks. 1. Verify TURN/STUN configuration: ◦ Ensure any configured TURN server credentials are correct and that the TURN server is reachable from the client network. 1. Check token and server access: ◦ Confirm the JWT you’re using is valid and has the expected grants. Authentication issues usually surface earlier, but it’s worth confirming. 1. Reproduce from a different network: ◦ Try connecting from a mobile network or home Wi‑Fi to determine if a corporate network policy is the blocker. What I can help with next • If you’d like, share: ◦ Which SDK and version you’re using (web, iOS, Android), and ◦ Whether you’re behind a corporate network or home/ISP network. ◦ Any TURN/STUN configuration you’ve set (no secrets — just confirm whether TURN is configured). • I can walk you through running the Connection Test, interpreting its results, and next steps based on those results. If you prefer, start by running the Connection Test and paste the result summary here — I’ll help you interpret it and recommend targeted fixes. Sources: Firewall Tips for LiveKit Connectivity | LiveKit | Diagnosing Connection Errors with the Connection Test Utility | LiveKit | client-sdk-swift | livekit/livekit_composite | DeepWiki
n
How do i do the connection test
t
Thanks — I’ll walk you through running the LiveKit Connection Test and how to interpret the results. What the Connection Test checks • WebSocket connectivity (signaling) • WebRTC connectivity (ICE/STUN) • TURN server reachability (if configured) Quick steps to run the test 1. Open the Connection Test page in your browser: ◦ Go to https://livekit.io/connection-test 1. Enter your server URL (optional but helpful): ◦ If you have a specific region URL (for example your production host like 
<https://air-xxxxx.omumbai1a.production.livekit.cloud>
), paste it into the “Host” or server field. ◦ If you leave it blank the test will use the default LiveKit endpoints. 1. Provide an API token if prompted (optional): ◦ The test can run without a token for basic checks. If you want a more thorough test for your deployment (auth/signaling), use a valid short-lived JWT. 1. Start the test: ◦ Click the “Run Test” or similar button. The test runs WebSocket + STUN/TURN checks and attempts to gather ICE candidates. 1. Review the results: ◦ Green / Passed: connectivity for that step is working. ◦ Yellow / Partial: some candidates or paths succeeded but others failed. ◦ Red / Failed: that check couldn’t reach the service (e.g., TURN unreachable, STUN blocked, or WebSocket failed). What to look for (common failure signals) • WebSocket failure: browser cannot reach the signaling endpoint — check DNS, server URL, TLS certs, or firewall blocking port 443. • STUN/ICE failures: no ICE candidates gathered or no successful candidate pairs — indicates NAT traversal problems or STUN blocked. • TURN unreachable: if UDP is blocked and TURN is not reachable (or credentials wrong), connections will fail behind restrictive networks. If the test fails or shows warnings • Copy the test output (or a screenshot) and share: ◦ Which checks failed (WebSocket, STUN, TURN). ◦ Any error messages shown. • Note the network you tested from (corporate VPN, home, mobile) and the SDK/browser you’re using. If the test passes but you still see the error • Tell me the test results and which SDK/version you’re using. I’ll help interpret the results and suggest next steps (e.g., force TURN, adjust ICE policy, verify TURN credentials). Would you like me to wait while you run the test and paste the results here? I can walk through the findings with you step‑by‑step.
3 Views
Open in Slack
PreviousNext
Powered by