Australia region for agents, and does LiveKit Inference run in the agent's region?

Agents
, , ,
1

We’re building voice agents that place outbound calls to Australian numbers (mobiles), over SIP via Twilio or Telnyx (carrier undecided). Rest of the stack is LiveKit Agents (Node), LiveKit Inference (deepgram/nova-3, google/gemma-4-31b-it, cartesia/sonic-3.5), multimodal turn detector, on LiveKit Cloud.

We are trying to optimise latency. As far as we can tell, Cloud agent regions are us-east, eu-central, and ap-south (Mumbai), with no AU region, so an Australian call runs the pipeline in Mumbai and pays a Sydney to Mumbai round trip (about 140 to 160ms) on every turn. A Sydney SIP carrier does not fix this because the agent still runs in Mumbai.

Questions:

  1. Is an Australia (Sydney) agent region on the roadmap, and any rough timeline?
  2. When we pin the agent to a region (ap-south today), does LiveKit Inference (STT, LLM, TTS) run in that same region, or can it be served from elsewhere? This is the key one for us: are our tokens round tripping to a different region than the agent? And would that behaviour hold for a future AU region (Inference co located there too)?
  3. For an all Australia workload today, what setup gives the lowest turn latency?If we self host the worker in AWS ap-southeast-2, can we still use LiveKit Inference, or would those calls route offshore anyway? Which SIP region is closest to Australia right now?

Thanks.

2

The best way to optimize latency is to ensure that the agents are hosted as close to the models as possible. You have a couple of options using LiveKit cloud:

  • Host your agents in Mumbai, as you are doing already, and then use models (LLM, STT, TTS) hosted in that region. The leg to your clients in Australia does have the round trip cost, like you say, but that is less than if you hosted your models in Australia.
  • Self-host your agents in Australia, and then use locally hosted models (LLM, STT, TTS). This means you would avoid the round trip SIP leg but you would lose the convenience of cloud-hosting your agents.

To answer your questions:

Is an Australia (Sydney) agent region on the roadmap, and any rough timeline?

I do not have any timeline to share publicly for agent hosting on LiveKit Cloud I’m afraid. Details for self-hosted deployments, as in hosting the agent yourself on a local could but relying on LiveKit for everything else, are here: Self-hosted deployments | LiveKit Documentation

When we pin the agent to a region (ap-south today), does LiveKit Inference (STT, LLM, TTS) run in that same region, or can it be served from elsewhere? This is the key one for us: are our tokens round tripping to a different region than the agent? And would that behaviour hold for a future AU region (Inference co located there too)?

No, Pinning traffic to a region will pin LiveKit media traffic within the region, as in communication between your agent and clients, but it will not affect the connection with your models. The typical way to approach this would be to use a plugin-based model with a region based endpoint and connect to that by specifying the base_url . Again, I do not have a date for LiveKit Inference support in the region that is guaranteed to connect to a local endpoint that I can publicly share I’m afraid.

I did write this blog about regional deployments that gives an overview, I usually share it as a starting point:

For an all Australia workload today, what setup gives the lowest turn latency?If we self host the worker in AWS ap-southeast-2, can we still use LiveKit Inference, or would those calls route offshore anyway? Which SIP region is closest to Australia right now?

Inference calls will not necessarily always connect to local inference endpoints, although you would see good performance with Deepgram Nova-3 (since we host that model in LiveKit Inference) and Cartesia.

We do have a SIP region in Australia.

I spent some time trying to find a 3rd party video that talks about this, but I couldn’t find what I was thinking of. For the lowest guaranteed latency, I would recommend self-hosting your voice agent within the region and connecting to models that offer a regional endpoint.