Multi-Region Deployment When Every Millisecond Is Audible

A voice deployment that tests perfectly in one region has a specific way of going wrong when you open it up: nothing breaks. Calls connect, audio flows, nobody files a bug. People just start talking over each other, and the agent starts feeling a beat slow.

That is almost always a map problem rather than a code problem. Here is how the budget actually gets spent, and which decisions are worth making before you have customers in three continents.

Physics owns part of the budget before you write anything

ITU-T G.114 puts the comfortable ceiling for one-way mouth-to-ear delay at around 150 ms, with up to 400 ms tolerable if you have no choice. That is the whole budget — capture, encode, network, jitter buffer, decode, playout.

Light in fibre moves at roughly two thirds of its speed in vacuum, which works out to about 5 ms of one-way delay per 1,000 km. Fibre does not run in straight lines, so budget around 1.5× the great-circle distance and you will not be far off.

Mumbai to Frankfurt is roughly 6,400 km. As a round trip through real routes that is comfortably north of 100 ms — most of your conversational budget spent before a single packet has been processed. You cannot optimise that away. You can only decide not to spend it.

Signalling and media are different problems

The most useful thing to internalise is that SIP signalling and RTP media travel independently, and only one of them is latency-critical.

Signalling is a handful of messages at call setup. An extra 80 ms on an INVITE costs you 80 ms of ring time that nobody perceives as a quality problem. Centralising it — or anycasting it — is fine.

Media is 50 packets per second for the entire call, in both directions, and every millimetre of that path is audible. This is what has to be close to the people talking.

Teams that treat these as one system end up either distributing infrastructure that did not need distributing, or anchoring media wherever the signalling happens to terminate. The second one is the expensive mistake.

The hairpin that costs you 200 ms

Two people in Singapore call each other. Your SBC is in Frankfurt. Media goes Singapore → Frankfurt → Singapore.

That call is now carrying roughly 20,000 km of round trip for a conversation that could have stayed inside one city. Nothing is misconfigured. Every component is doing its job. The call just sounds like a satellite link.

This shows up in a few reliable ways:

• A single global media anchor. Easy to operate, and it makes the worst case the common case for anyone far from it.
• Relay selection by round-robin rather than proximity. ICE will happily select a TURN candidate on another continent if that is what your allocation policy hands it. What matters is not the relay you configured but the one the connection actually chose.
• Carrier hand-off in the wrong place. If your PSTN breakout is in one region and your customers are in another, the leg between them is on your bill in latency terms whether or not it is on your invoice.

The general rule: anchor media at the region nearest the endpoints, and let signalling travel. For a call between two parties in different regions, anchor near one of them and accept a single crossing rather than two.

Where the model sits is part of the media path

This is the one that catches teams adding a voice agent to infrastructure that was already fine.

The moment a model is in the loop, your media path is no longer endpoint → media server → endpoint. It is endpoint → media server → inference → TTS → media server → endpoint. If the media server is in Mumbai and the inference endpoint is in us-east-1, you have added a transcontinental round trip to every conversational turn — twice, if speech-to-text and text-to-speech are separately hosted.

Humans start expecting a reply about 200 ms after they stop talking. The chain that has to fit inside that is endpointing, network to inference, model time, TTS time-to-first-byte, network back, and jitter buffer. Each link is defensible on its own. The sum is what the caller hears, and geography is usually the largest term nobody costed.

Co-locate inference with the media anchor, or stream the audio to something you run in the same region. A model that is 40 ms slower but in the right country will feel faster than a better one that is an ocean away.

Data residency and latency pull in opposite directions

Sometimes the right region for latency is not a region you are allowed to use.

If recordings for an Indian customer must stay in India, that constrains where media can be anchored and where it can be stored — and those are two separate decisions. Media can be processed in-region and the resulting artefacts stored in-region, without the control plane living there too. Splitting the control plane from the media plane is what makes it possible to satisfy a data-residency requirement without also duplicating your entire platform per country.

This is the argument for deployment models rather than one global cloud: some regions want a shared tenancy, some want a dedicated instance, and some want the whole thing inside their own network. All three should be the same software.

Failover for media is not failover for HTTP

A stateless HTTP service fails over by sending the next request somewhere else. A call in progress has no next request. It has an RTP stream with sequence numbers, an ICE session, and a jitter buffer holding state.

Three things worth deciding in advance:

1. In-flight calls. They will drop when a media node dies. Accept that, and optimise for how fast new calls route around it. Pretending otherwise leads to designs that fail in more interesting ways.
2. Health checks that test media, not the process. A media server that is listening on its signalling port and no longer forwarding RTP passes a TCP health check and fails every call it is given.
3. Regional drain, not regional failover. Stopping new allocations to a region and letting existing calls finish is almost always better than moving them.

How we deploy it

SIPRTC runs regional media anchors with signalling that can terminate anywhere, so a call is pinned to the media region closest to its endpoints rather than to wherever the INVITE landed. Carrier breakout is regional too, which is the half people forget. The same build runs in our shared cloud, in a dedicated single-tenant instance, or entirely inside a customer’s own infrastructure — because for a lot of our customers the nearest region and the legally permitted region are the same conversation.

None of this is exotic. It is mostly the discipline of asking, for every hop, where does this actually happen — and refusing to accept “in the cloud” as an answer.

Compare notes?

If you are running real-time audio across regions, we would like to hear what your topology looks like and where it hurts — particularly if you have solved the residency-versus-latency tension in a way we have not thought of.

Get in touch, or find us on LinkedIn. And if you are debugging something more specific, the failure modes that show up at the call level are worth reading first.