The LiveKit Connection Tester is giving one of my users the following errors: Error: Could not get RTCStats (this is for both audio and video) And also a FAIL for “Resuming connection after interruption”

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

He’s using Firefox

Thanks — I’m looking into the two errors you reported for the user on Firefox: “Could not get RTCStats” and failing “Resuming connection after interruption.” I have a few quick checks and some questions to narrow this down. Quick checks to try now • Ask the user to update Firefox to the latest stable version and retry. • Have them test the same session from a Chromium-based browser (Chrome/Edge) to see if the errors are Firefox‑specific. • Confirm the network allows UDP traffic and/or that TURN is reachable (firewalls that block UDP can cause stats and reconnect issues). • If possible, retry from a different network (home vs corporate) to rule out network-level filtering. Information I need from you • Firefox version the user is running. • Whether the user succeeds when using a Chromium browser. • Whether you use a TURN server (and its hostname) or rely on STUN only. • Any console logs or the full Connection Tester output (copy/paste the error text or a screenshot). What I can do next • If you share the Firefox version and logs, I’ll point to targeted troubleshooting steps and possible workarounds for Firefox-specific WebRTC behavior. Sources: release/adapter_no_edge.js | Diagnosing Connection Errors with Connection Test Utility | Firewall Tips, with interactive elements

He can connect using Safari Firefox version is 151.0 Here’s a screenshot of the full output from the connection tester:

Thanks — this is helpful. You’ve told me Firefox 151.0, the user can connect with Safari, and the Connection Tester screenshot shows WebSocket/ICE/TURN succeed but both audio/video publish fail with “Error: Could not get RTCStats” and a FAIL on resuming after interruption. I’ll guide next steps to isolate and fix the Firefox-specific issue. Quick diagnosis summary • Signaling, ICE, and TURN are working (WebSocket, UDP, TURN checks are green). • The failures are specific to Firefox’s RTC stats collection and connection-resume behavior (publish and getStats-related). • Safari working rules out server/TURN-wide blocking and points to a Firefox-only client behavior or config. Please try these targeted checks (order matters) 1. Disable extensions and privacy features ◦ Have the user open a new Firefox Private Window (extensions disabled depending on setup) or temporarily disable extensions/privacy add-ons (e.g., uBlock, privacy/antitracking). Then rerun the Connection Tester. 1. Test with Firefox’s default privacy settings ◦ In Settings → Privacy & Security, temporarily set Enhanced Tracking Protection to Standard and disable “Strict” features. Retry the tester. 1. Confirm media permissions and hardware ◦ Ensure Firefox has Camera/Microphone permission for the tester site (click the lock icon → Permissions). ◦ Try selecting a different audio/video device in Firefox if available. 1. Check for enterprise policies / firewall differences ◦ Ask whether the user is on a corporate network with strict firewall/IDS that could interfere with WebRTC resumption or block certain getStats paths. Try from a different network (mobile hotspot) if possible. 1. Collect console logs and getStats error ◦ In Firefox, open DevTools → Console. Run the Connection Tester and copy any WebRTC/getStats errors or warnings. Please paste the console output (or a screenshot) here. ◦ If possible, open DevTools → WebRTC (or about:webrtc) and capture any peer-connection diagnostics. 1. Verify Firefox-specific flags ◦ Ask the user if they changed any about:config flags related to WebRTC (e.g.,

media.peerconnection.enabled

,

media.navigator.permission.disabled

,

media.peerconnection.stats.enabled

). If so, reset them to defaults. 1. Confirm LiveKit client/SDK usage (if applicable) ◦ Are you testing the public LiveKit Connection Tester page, or your app using a LiveKit JS SDK? If your app, which LiveKit JS SDK version are you running? Why these steps: Firefox sometimes handles getStats and connection state transitions differently; extensions, strict privacy settings, enterprise policies, or custom about:config flags often cause getStats failures even when ICE/TURN succeed. What I need from you next • Console logs or screenshots of DevTools console during the failed test. • Whether the user’s Firefox had extensions or enterprise policies enabled. • Which LiveKit SDK version is in use if this is in your app (not the public tester). If you share the console output and SDK version, I’ll correlate the errors to known Firefox behaviors and provide exact remediation or a workaround. , with interactive elements

I’ve asked the user to send additional data. What I know now: – The user is not on a corporate network

Thanks — that helps. Since they’re not on a corporate network and Safari works, this points to a Firefox-specific client issue. I’ll ask for a few remaining diagnostics and suggest the highest‑value checks. Quick ask (please get these from the user) • DevTools console log during the failed test (paste text or screenshot). • Whether they have any Firefox extensions enabled (try with all extensions disabled). • Whether they used the public LiveKit Connection Tester page or your app. If your app: which LiveKit JS SDK version? • Any about:config WebRTC-related flags changed (or confirm they haven’t changed them). High-priority steps for the user to try now 1. Run Firefox in Troubleshoot Mode (Help → Troubleshoot Mode) or a new profile with extensions disabled, then rerun the tester. 2. In Firefox Settings → Privacy & Security set Enhanced Tracking Protection to Standard and retry. 3. Ensure site Camera/Microphone permissions are allowed (lock icon → Permissions). 4. Open DevTools → Console before running the test and capture any getStats/peerConnection errors (copy/paste here). If you send the console output and confirm whether this is the public tester or your app + SDK version, I’ll map the error to specific Firefox behaviors and provide the next concrete fix or workaround. , with interactive elements

(…continued, I keep pressing return instead of shift+return) – This is the public LiveKit tester, not a self-install – Camera/mic are both set to “Allow temporarily”

Thanks — this is very helpful. Since it’s the public Connection Tester, Safari works, they’re on Firefox 151.0, not on a corporate network, and camera/mic are allowed temporarily, the next most useful item is the Firefox DevTools console output. Could you ask the user to run the tester once more and capture these three things, then paste them here? 1. DevTools Console logs: Open Firefox DevTools → Console before starting the test, reproduce the failure, then copy/paste any errors or warnings that appear (especially anything mentioning getStats, RTCStats, peerConnection, or DOMExceptions). 2. Confirm extensions / Troubleshoot Mode: Try again in Troubleshoot Mode (Help → Troubleshoot Mode) or a fresh profile and tell me whether the failures persist. 3. about:webrtc or about:config info (optional but helpful): ◦ Open about:webrtc (or about:config if they changed flags) and copy any peer-connection diagnostics or note if they changed WebRTC flags. When you share the console output (or screenshots) and the result from Troubleshoot Mode, I’ll map the exact errors to Firefox behaviors and provide a precise next step or workaround. , with interactive elements

I don’t yet have a console screenshot from the user for the Connection Tester (I will send when I do) but here’s one for the user trying in our own app, using the same server and JWT:

Thanks — this is useful. I’m responding to the console error from your app and the Connection Tester failures in Firefox 151.0. What the logs show • The app console error — "PublishTrackError: publishing rejected as engine not connected within timeout" plus repeated "leave-reconnect disconnected" — means the LiveKit client’s engine is failing to reach a stable connected state, so publish attempts time out. • The Connection Tester shows ICE/TURN/websocket succeed but both audio/video publish fail with “Could not get RTCStats” and resumption fails. Together this points to a Firefox-specific WebRTC/client connection problem (not a server-wide or TURN-only outage), where Firefox either fails to return stats and/or the peer connection/DTLS handshake doesn’t complete reliably. Highest-value actions to try next 1. Get the Connection Tester console logs (Firefox DevTools → Console) while reproducing the tester failure and paste them here. This is the single most helpful artifact. 2. Have the user retry in Firefox Troubleshoot Mode (Help → Troubleshoot Mode) or a fresh profile with all extensions disabled. Report whether failures persist. 3. Force relay/TURN in your app (to rule out UDP/ICE issues): ◦ Connect with rtcConfig: { iceTransportPolicy: 'relay' } and see if publishes succeed. 1. Try Firefox with hardware acceleration disabled and confirm Camera/Mic permissions are allowed (you mentioned “Allow temporarily” — try “Allow”). 2. If you can reproduce in your app, include the LiveKit JS SDK version you’re using. Why these matters • Console logs will show getStats/DTLS/ICE errors that explain the RTCStats failure and the engine not-connected timeout. • Troubleshoot Mode rules out extensions/privacy settings. • Forcing TURN relay isolates UDP/ICE problems that can manifest differently in Firefox. • SDK version helps me map the behavior to known SDK/browser interaction issues. If you send the Connection Tester console output and tell me results from Troubleshoot Mode and the relay test (and the SDK version if testing in-app), I’ll give the exact next remediation steps or a targeted workaround. Sources: Diagnosing Connection Errors with Connection Test Utility | client-sdk-js | livekit/livekit_composite | DeepWiki | WebRTC Codecs Guide | LiveKit | Firewall Tips | release/adapter_no_global.js, with interactive elements

I still don’t have a screenshot from the console, but the user is able to connect successfully now on the connection tester under both the following conditions: – Disable extensions and privacy features – Test with Firefox’s default privacy settings

Thanks — great detective work and thanks for the update. I’m responding to your note that the tester passes when Firefox extensions/privacy are disabled or set to default. What this shows • The issue is Firefox-specific and caused by extensions or strict privacy settings blocking WebRTC stats or interfering with the peer connection. • Network, TURN, and server-side connectivity are fine (since Safari and the tester with defaults succeed). Recommended next steps for your user (pick applicable items) • Permanently allow the tester/app site: ◦ In the site lock (address bar) set Camera and Microphone to “Allow” (not just “Allow temporarily”). • Disable or whitelist problematic extensions: ◦ Have the user enable extensions one-by-one to find the culprit (privacy blockers, anti-tracking, or WebRTC-related add-ons are likely). • Use Troubleshoot Mode or a clean profile: ◦ If the user must keep many extensions, create a separate Firefox profile or shortcut for calls with only essential extensions enabled. • Relax Enhanced Tracking Protection for your site: ◦ In Settings → Privacy & Security set protection to Standard, or set a site exception. • If you control client code, consider forcing TURN relay as a fallback: ◦ Use connect options with

rtcConfig: { iceTransportPolicy: 'relay' }

to ensure relay-based media if extensions still interfere. • Ask users to keep Firefox up to date and check for any about:config WebRTC flags changed—reset to defaults if unsure. If you want, I can: • Provide a short troubleshooting script the user can run (step-by-step to isolate the extension). • Explain how to create a dedicated Firefox profile for calls. • Walk through adding a site exception for Enhanced Tracking Protection. Which option would you like me to prepare for the user? , with interactive elements

Is

rtcConfig: { iceTransportPolicy: 'relay' }

likely to be helpful in general for people encountering issues with connecting? Or would it only really be a fallback for this particular problem in Firefox? I’m wondering if I couldn’t set it behind a “Try again” button in our app if the room connection fails?

Thanks — good question. Short answer: using

rtcConfig: { iceTransportPolicy: 'relay' }

is a useful general fallback, not just a Firefox workaround. When it helps • Useful for restrictive networks that block UDP/ICE or perform deep packet inspection (corporate Wi‑Fi, some mobile carriers). • Helpful when ICE/TCP/UDP attempts fail but TURN over TCP/TLS (port 443) can get through. • Can resolve cases where browser extensions or privacy settings disrupt direct peer connectivity by forcing relay through TURN. Tradeoffs • Higher latency and bandwidth costs because all media is relayed through TURN. • Not guaranteed to fix every case (TURN still must be reachable). • Shouldn’t be the default for all users — prefer direct peer paths when available. Recommended implementation 1. Try normal connection first (default behavior). 2. On failure (e.g., engine not connected / publish timeout), show a “Try again with relay” button. 3. On retry, connect with: ◦ rtcConfig: { iceTransportPolicy: 'relay' } 1. Optionally run your Connection Test / ConnectionCheck before retrying to confirm TURN reachability. 2. Log which users fall back to relay so you can monitor frequency and impact. If you want, I can draft the exact retry UI flow and a small code snippet showing how to reconnect with relay and detect the original failure types to trigger the fallback. Which would be most helpful? Sources: Firewall Tips | Diagnosing Connection Errors with Connection Test Utility, with interactive elements