Hey, what is the most common reason for having a T...
# ask-ai
m
Hey, what is the most common reason for having a Telephony Call in Livekit cloud with no session associated?
✅ 1
t
Thanks for reaching out, Hugo. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — you're asking why a Telephony Call in LiveKit Cloud might show up with no associated session. The most common reason is that the SIP call/room is created but the agent process never starts or fails to join the room in time. Key causes to check: • Agent startup timeout: the room exists but the agent didn’t connect within the expected window (cold start, startup errors, or timeouts). • No available agent replicas: scaling or deployment issues mean no agent was dispatched to the call. • Agent initialization errors: crashes or errors during
connect()
/
session.start()
prevent the AgentSession from being established. • Dispatch misconfiguration: routing/dispatch rules or metadata prevent an agent from being assigned. Next steps to troubleshoot: 1. Check agent logs around the call timestamp for startup or connection errors. 2. Verify agent replica counts and deployment health. 3. Look for timeouts or error messages about room connection failing. 4. Review dispatch rules/metadata to ensure agents should be assigned. If you want, share the call timestamp, room ID, and any agent logs or error messages and I’ll help interpret them. Sources: Why is my Agent insights data missing? | LiveKit | Job lifecycle | LiveKit Documentation, with interactive elements
m
Is there a way to check it using LiveKit API? I mean list all such calls, or dig up some logs of what happened there? Is there a way to check logs that show which workers the job offer was sent to, how they declined or response timed out, etc?
t
Thanks — you asked whether you can use the LiveKit API to 1) list telephony calls with no associated session, and 2) see logs that show which workers received job offers and how they responded (declined / timed out). Short answer: • There is no API that directly lists “telephony calls with no associated session.” • There is no system-level API that exposes per-worker job-offer telemetry (which workers were offered a job and their accept/decline/timeout responses). What you can do instead: • List active rooms and participants via the Room APIs (e.g., list rooms / list participants) to find rooms that exist but lack expected agent participants. • Pull agent runtime logs to investigate what happened for specific calls: ◦ Use the LiveKit CLI to read agent logs:
lk agent logs --id <agent-id>
. ◦ Enable DEBUG-level logs or use your log forwarding (Datadog/Sentry) to capture more detail. • Enable Agent Observability (if your project has it and agents use supported SDK versions) to get traces/logs/transcripts for sessions that did start. • Add custom logging in your agent entrypoint to record dispatch events (which offers it receives, accept/decline, timeouts). This is the reliable way to get per-worker offer outcomes. If you want, share one example call timestamp and room ID (or agent ID) and I can point to which logs and commands to run next to investigate that specific incident. Sources: Where to find your Agent Logs | LiveKit | Creating SIP Inbound Trunks and Dispatch Rules with Python SDK, with interactive elements
m
What if there's no session, just a telephony call record? What does it mean?
t
If you see a telephony call record with no associated session, it means the SIP call reached LiveKit and a room was created or logged, but no AgentSession was successfully established for that call. Practically, this indicates the call reached the platform but no agent process completed joining/starting a session for it. Common implications: • The agent failed to start or didn’t connect within the required timeframe (cold start, startup error, or timeout). • No agent replicas were available to accept the job (scaling or deployment issue). • The agent crashed or errored during initialization (e.g., during
connect()
or
session.start()
). • Dispatch rules or metadata prevented an agent from being assigned to that call. What to check next: • Agent logs at the call timestamp for startup/connection errors. • Deployment/replica health to confirm agents were available. • Any timeouts or “room connection not established” messages. • Dispatch rules and routing metadata to ensure the call should have been assigned. If you share the call timestamp, room ID, or agent ID, I can guide you to the exact logs and commands to inspect. , with interactive elements