Thanks — I hear you’re seeing a 25–29% failure rate after upgrading to AgentServer where dispatches are created but no call reaches your telephony provider. Below are targeted places to check first and quick actions to gather diagnostic data. What to check first (start here) • Agent availability / worker count ◦ Ensure you have multiple AgentServer workers for each

agent_name

. If only one worker runs, it can be overwhelmed and fail to accept jobs even though dispatches are created. Run ≥3 workers per agent_name for redundancy and to handle bursts. • Dispatch acceptance in your agent code ◦ Confirm your

on_request

handler explicitly accepts jobs (e.g.,

await req.accept()

in async handlers). If the agent never accepts, the call won’t be placed. • Connection/accept timeouts ◦ Look for errors like “room connection was not established within 10 seconds…” — this indicates no worker accepted the job in time. Increasing worker count or ensuring

setup_fnc

prewarms resources can help. • Resource pressure on agent hosts ◦ Check CPU, memory, and other apps on the same hosts. Heavy load can cause agents to reject or time out on jobs. • SIP / telephony integration and network reachability ◦ Verify your SIP service is deployed and reachable from AgentServer and that SIP trunk credentials and addresses are correct. Network latency or firewall rules between AgentServer and SIP gateway can block call attempts. • Telephony provider visibility ◦ If provider logs show no attempts for those numbers, the call never left your stack. Correlate dispatch IDs/timestamps in your LiveKit logs with missing provider entries. Quick diagnostics to collect 1. Collect agent server logs (include timestamps around failed dispatches). Look for job rejection, timeout, or “no worker available” messages. 2. Note dispatch IDs and timestamps for failed calls and search agent + SIP logs for those IDs. 3. Check host resource metrics (CPU/memory) during bulk runs and worker counts per

agent_name

. 4. Confirm your

CreateSIPParticipant

(or equivalent) requests used for those dispatches and whether

wait_until_answered

or similar flags are set. Short-term mitigations • Scale up worker count immediately (add more AgentServer instances) to see if failure rate drops. • Prewarm any required models/resources in

setup_fnc

to reduce job start latency. • Increase logging verbosity on agents and SIP gateway while testing. If you’d like, share one example failed dispatch ID plus the adjacent agent logs (timestamps ±30s) and the number of agent workers running during the test — I can point to the exact log entries to look for. Sources: examples/bank-ivr | livekit/livekit_composite | DeepWiki | Agents Framework | livekit/livekit_composite | DeepWiki | Agent server options | LiveKit docs | SIP Lifecycle Management Agent | LiveKit docs | How to Get Help from LiveKit