Slow room creation

Self Hosting
,
1

I am using a self-hosted LiveKit stack (with the Python Agents SDK) and experiencing a severe 7–8 second delay during call initialization across both web widgets and our Meta SIP inbound trunk. The issue is consistently a slow room-to-agent dispatch bottleneck; the frontend participant connects instantly, but there is a massive delay before the agent worker receives the job request and handles the first utterance, even though our agent container is running with active, pre-warmed idle processes. What internal server configurations or underlying Redis/Signaling components should we look into to fix this dispatch lag on a self-hosted setup, and is there a known issue with CreateRoom explicit agent dispatch (agents field) failing or delaying jobs compared to calling CreateDispatch manually?

2

This looks like a known issue in some self-hosted deployments. There are a couple of GitHub reports describing similar behavior, where pre-warmed workers remain idle and job dispatch is delayed by 15–50 seconds.

A few things check:

1. Use explicit CreateDispatch instead of the agents field

If you’re currently creating rooms with the agents field, try switching to an explicit CreateDispatch flow. LiveKit generally recommends explicit dispatching for SIP integrations and more complex deployments, as it tends to be more reliable and easier to troubleshoot.

2. Verify worker and room placement in multi-node setups

If you’re running a multi-node self-hosted cluster, take a look at issue #3645. Agent workers only serve the node they register with. If a room is created on a different node than the one hosting the worker, dispatch can be delayed or appear to stall. That could explain the 7–8 second gap you’re seeing.

Also, check your Redis deployment. Since Redis handles the signaling layer for job routing, high pub/sub latency or unstable connections can introduce additional dispatch delays.

3

@Rushi_Patel, 7-8s is way outside the documented baseline (“max dispatch time under 150 ms” per Agent dispatch | LiveKit Documentation ). For self-hosted, the dispatch path is server >> Redis >> worker. Top suspects:

  1. Redis network latency between LK server and your agent container.

  2. Worker agent_name mismatch (job sits unrouted until a timeout).

  3. PR #4488 (open) is fixing a 3s psrpc timeout when ListDispatch hits a non-existent room. If your dispatch hits that path on the first call, you’d see ~3s eaten there.

On the CreateRoom-agents-field vs CreateDispatch question: there are known issues. Bug #4357 (closed Mar 2026) was about dispatches via RoomServiceClient.createRoom missing the room field. Issue #4390 documents that roomConfig.agents from a JWT token is silently ignored when the room already exists. The recommended path is the explicit CreateAgentDispatchRequest:

  from livekit import api

  lkapi = api.LiveKitAPI()

  await lkapi.agent_dispatch.create_dispatch(
      api.CreateAgentDispatchRequest(
          agent_name="my-agent",   # must match worker registration exactly
          room="my-room",           # auto-created if missing
          metadata='{"user_id": "12345"}',
      )
  )

To isolate the bottleneck: log timestamps on

  1. participant connect,
  2. CreateDispatch call,
  3. worker entrypoint start.

The Gap between (2) and (3) is Redis or worker registration. Gap between (1) and (2) is your own backend logic.

5

since u have mentioned redis network latency btw LK server and my agent container,
one thing I want to discuss is that does the geo location of all the server affect the latency??
because all my servers (redis, livekit, livekit-sip and my agent) are running on the different region all over the world.
If geographic distribution does have a significant impact on latency, could you please help explain the underlying reasons? I’d like to share a clear technical explanation with my team to support the recommendation of deploying these services within the same region.

6

@Rushi_Patel Yes, geographic distribution can absolutely contribute to dispatch delays, and it’s worth checking how your infrastructure is deployed.

In a self-hosted setup, Redis acts as the messaging layer for job dispatch. A typical flow looks like this:

LiveKit Server → Redis → Agent Worker → LiveKit Server

If these components are spread across different regions, every network hop introduces additional latency. Once you add SIP infrastructure in another region, the total round-trip time can grow even further.

One key difference is that LiveKit Cloud handles geographic placement automatically. In self-hosted deployments, there is no built-in geographic affinity, so placement and routing need to be managed through your infrastructure design.

As a best practice, try to keep the following components in the same region and, ideally, the same datacenter:

  • Redis
  • LiveKit Server
  • LiveKit SIP
  • Agent Workers

Keeping Redis pub/sub traffic local minimizes latency and can significantly improve dispatch times.