We run a production voice agent on LiveKit Cloud (Ship plan, US East / oashburn1b, livekit-agents 1.6.2, Python, inbound via Twilio Elastic SIP trunk).
On July 18 between roughly 02:44 and 02:45 UTC, three consecutive inbound calls connected but the agent never produced audio - callers heard silence and hung up. The same code worked perfectly a few hours before and a few hours after, including a full end-to-end call, so we don’t believe this was an application change.
What our worker logs show around that window:
- 23:44 UTC (Jul 17): “failed to connect to livekit, retrying in 0s” followed by “registered worker”
- During the silent calls: sessions started normally (job received, noise cancellation active with code 200, turn detector initialized), but the initial TTS greeting never reached the caller
- Repeated “dropping pass-through signal - no stream available” warnings from livekit_api::signal_client
- “publisher data channel ‘_reliable’/‘_lossy’ closed unexpectedly” on teardown
- STT partially worked: fragments of caller speech were transcribed, but the sessions behaved abnormally (transcripts start with the caller, no agent greeting recorded)
status.livekit.io shows no incident for that window, though US East RTC shows 99.86% 90-day uptime, so brief unlogged degradation seems plausible.
Questions:
- Did anyone else running agents in US East see silent/no-audio sessions around that time?
- Is there a recommended way to detect this condition from inside the agent (e.g. confirming the TTS audio track actually published) so we can retry the greeting or fail fast instead of holding a silent line?
- What do people use as a production safety net for this failure mode? We’ve since configured our Twilio trunk’s disaster recovery URL to forward callers to a human when LiveKit doesn’t answer - but in this case the calls DID connect, so the DR path never fired. Curious how others handle “connected but silent” specifically.
Happy to share room names/timestamps privately if a LiveKit engineer wants to look up the sessions.