Thanks — this is helpful information. I’m responding to the WebSocket connection failures you reported when calling the LiveKit Inference TTS/STT endpoints (wss://agent-gateway.livekit.cloud/v1/tts and the STT equivalent), including the repeated "failed to synthesize/recognize speech after 4 attempts" and the unrecoverable

stt_error

. What this error indicates • The stack trace shows the WebSocket fails during initialization in

@livekit/agents

v1.0.47, which means the agent process cannot establish a WSS connection to the inference gateway. • Because both TTS and STT fail and you see 4 retry attempts then a session close, this looks like a connectivity problem rather than a credentials problem (you already confirmed

LIVEKIT_API_KEY

,

LIVEKIT_API_SECRET

,

LIVEKIT_URL

and that inference is enabled). What I recommend you check next (step-by-step) 1. Verify name resolution and TLS connectivity from the agent runtime: a. Run DNS lookup from the same host/container:

nslookup agent-gateway.livekit.cloud

or

dig agent-gateway.livekit.cloud

. b. Verify TLS handshake:

openssl s_client -connect agent-gateway.livekit.cloud:443 -servername agent-gateway.livekit.cloud

(look for successful certificate exchange and no network timeouts). 1. Confirm outbound network access to the gateway over port 443: ◦ From the same runtime environment run:

curl -v <https://agent-gateway.livekit.cloud/>

or

telnet agent-gateway.livekit.cloud 443

to confirm the host is reachable and TCP connects. 1. Check for proxies, corporate firewalls, or egress filtering: ◦ Ensure the environment allows outbound WSS/HTTPS traffic to

agent-gateway.livekit.cloud

(and

*.livekit.cloud

if possible) on port 443. ◦ If you use an HTTP proxy, verify Node is configured to use it or that the agent can bypass the proxy for WSS connections. 1. Inspect runtime environment restrictions: ◦ If the agent runs inside a private VPC, restricted container, or on-prem network, confirm NAT/egress rules allow connections to external hosts. ◦ If running in a serverless or containerized environment, try a simple test job from the same environment to confirm general outbound connectivity. 1. Capture more detailed client logs: ◦ Enable debug/logging from

@livekit/agents

(or the WebSocket library) to capture connect attempt timestamps, DNS resolution results, or TLS errors. Share any recorded error text beyond the stack trace (for example: DNS failure, connection timed out, TLS certificate verify failed). 1. Rule out transient service issues: ◦ Retry from a different network (e.g., your laptop on home network) or a cloud VM to see if the same endpoints succeed — if they do, the cause is environment-specific. If you can share just one additional piece of info it will help narrow this quickly • From the agent host, what is the exact error you get when running

openssl s_client -connect agent-gateway.livekit.cloud:443

or a

curl -v

? (Copy/paste the failing lines — e.g., DNS timeout, connection refused, TLS verify error, or HTTP 4xx/5xx.) Why these checks matter • WebSocket (WSS) connections can fail because of DNS, TLS validation, firewall/proxy rules, or blocked outbound ports. These are the most common causes when credentials are valid and retries are happening but never succeed. If after these checks you still see failure • Share the additional log output (from the TLS/DNS test and any debug logs from

@livekit/agents

). I’ll use that to point to the exact likely cause and next action (for example, specific firewall rules to change, proxy settings to apply, or a more targeted fix). I’m here to help walk through the commands and interpret the results — paste the outputs when you have them and I’ll guide the next steps. Sources: Introducing LiveKit Inference: A unified model interface for voice AI | How We Built a Globally Distributed WebRTC Mesh Network | Firewall Tips for LiveKit Connectivity | LiveKit

Here's an example Room name: voice-4050b809-83e8-4f8d-a827-bbdb7ae171a4-session_1772046118557_6899wjk Room Session ID: RM_LeheZyHBrpFF

which STT and TTS are you using?

can you share observability of that session with us and share the observability link here?

I am not able to repro this with the same models fwiw

Here's a session link https://cloud.livekit.io/projects/p_5oyry9787wp/sessions/RM_LeheZyHBrpFF/observability?mode=transcript

has the tts error

We should have better error messaging there, will look into that

Or is there a way for me to clean up hung sessions?

So those warnings leads me to believe that there is something not causing these sessions to become inactive or the TTS/STT connections to be persisting post ending the call

Let me know if there's a good way to be able to see this/flush the sessions!

Could be a bug with your dashboard though, calls here say over an hour but if i click on one of them it shows 2-3 minutes

Following up here 🙂