I notice occasionally livekit never answers when I SIP dial. Is this a known issue?

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

can I increase that 10 second timeout?

Yes — you can increase the 10-second room connection timeout. What this controls • The timeout is the `JobProcess`'s

connectionTimeout

value. It determines how long the agent waits for a participant to join the room before failing the incoming SIP call. How to change it 1. Set

ctx.proc.connectionTimeout

in your agent entry before the room join attempt. 2. Example (TypeScript):

export default defineAgent({
  entry: async (ctx: JobContext) => {
    // Increase timeout to 60 seconds
    ctx.proc.connectionTimeout = 60;

    // ...rest of your agent logic
  }
});

Guidance on choosing a value • Short timeouts (10s) reduce waiting time for truly failed attempts but can cause missed answers when network or backend delays occur. • Increasing to 30–60 seconds is a common mitigation for intermittent network or provisioning delays. • Avoid extremely large values unless you expect long setup delays, since callers will wait longer for a failed answer. Next steps I can help with • Recommend a timeout value based on your typical SIP setup and observed delays (tell me your average SIP setup time or concurrent call counts). • Review logs around failed calls to confirm whether increasing the timeout will help. Which would you like to do next? Sources: Agents (Python) | livekit/livekit_composite | DeepWiki

what 'room connection' are you reffering to? Isn't the problem that the agent isn't available in under 10 seconds? And if that is the case, wouldn't setting the timeout on the job to be higher not help?

Thanks — that’s a great question. I’ll clarify what I mean by “room connection,” how it relates to agent availability, and when increasing the timeout will (or won’t) help. What “room connection” means here • When a SIP call arrives, the LiveKit agent creates or joins a LiveKit room for the call and waits for the SIP participant to finish establishing media and join that room. The 10-second timeout is the maximum time the agent will wait for that room/participant connection to be established before treating the incoming job as failed and not answering the call. How that differs from “agent availability” • Agent availability is about whether an agent instance (worker/replica) is ready to accept a job when the SIP INVITE arrives. • The room connection timeout is a subsequent step: even if an agent is available and accepts the job, the call can still fail if the participant/room join does not complete within the timeout window. When increasing the timeout helps • If the inbound SIP call is accepted by an agent quickly, but the SIP→room join or media setup occasionally takes longer than 10s (for example due to network latency, NAT traversal, or slow downstream services), increasing

ctx.proc.connectionTimeout

to 30–60 seconds can prevent those calls from being treated as failed and reduce missed answers. • In short: increasing the timeout helps when the bottleneck is the room/participant joining step finishing within the agent that has already accepted the job. When increasing the timeout won’t help • If the real problem is that no agent accepts the job within 10s because you have too few replicas, overloaded servers, or autoscaling is slow/misconfigured, then increasing the per-job connection timeout only delays failure detection — it does not create additional agent capacity. In that case you need to address agent availability (more replicas/instances, dedicated resources, faster autoscaling). Recommended approach • Run both mitigations together: ◦ Short-term: increase

ctx.proc.connectionTimeout

(e.g., 30–60s) to avoid losing calls due to transient room-join delays. ◦ Medium/long-term: ensure enough agent replicas and resource capacity so an agent accepts the job promptly. Use

lk agent status

, monitor CPU/memory, and tune autoscaling or run multiple worker instances per

agent_name

. • If you’re unsure which is the dominant issue for your environment, check these diagnostics: a. Did an agent accept the job? (Agent logs /

lk agent status

around the incoming call time.) b. If accepted, are there logs showing room-join attempts and timing? Look for timestamps showing how long room join took. c. If no agent accepted the job, inspect replica counts and resource usage during the call arrival window. If you want, I can help interpret

lk agent status

output or sample logs — paste the output or a log excerpt with timestamps and I’ll point out whether the failures look like agent-availability problems or room-join timeouts. Which diagnostics would you like to run first?