Voice AI latency is the silence between the moment a caller stops speaking and the moment they hear the agent start to reply. It is the sum of several delays: the phone network, the system deciding the caller has finished, the language model starting to answer, the speech synthesiser producing its first audio, and the return trip. Each stage can be measured separately, and the worst calls matter more than the average.
Vendors often quote a single latency figure, and buyers often compare those figures as if they measured the same thing. They usually do not. This article gives you a model of where the time goes, a way to measure it on your own calls, and the questions to ask when someone says 'sub-300ms'.
What does latency mean on a phone call?
On a call, the number that matters is turn-gap: the time from the end of the caller's speech to the start of the agent's audio at the caller's ear. It is not the same as the time a model takes to generate text, and it is not the same as a server-side timer. Anything measured only inside the vendor's servers misses the network legs on both sides of the call.
What gap do humans expect?
In a cross-linguistic study of 10 languages, Stivers and colleagues (Proceedings of the National Academy of Sciences, 2009) found that the typical gap between conversational turns is on the order of 200 milliseconds, with average gaps across languages falling within about 250 milliseconds of the overall mean. The practical reading: people are used to very short gaps, and a pause that would be unremarkable in an email thread feels long in speech.
Where do the milliseconds go?
Think of one turn as a chain. The caller's audio travels to the system, the system decides the turn has ended, the language model starts answering, synthesis produces audio, and that audio travels back. Here is each link.
- Caller's device and mobile network: audio is captured, encoded, and carried over the cellular network. Poor signal adds delay and packet loss.
- PSTN and carrier interconnect: calls cross between telecom operators and, for AI calling, usually enter a SIP trunk provided by a telephony carrier. Each handoff adds some delay, and routes that travel through distant gateways add more.
- Media transport to the platform: the audio stream reaches the voice platform over the internet. Distance from the hosting region matters here.
- Jitter buffer: networks deliver audio packets at uneven intervals, so receivers hold a small buffer to smooth playback. A larger buffer protects quality but adds fixed delay.
- Speech recognition and endpointing: the system must decide when the caller has finished. Wait too little and it interrupts people who pause mid-thought. Wait too long and every turn feels slow. This is often the largest tunable component.
- Language model time-to-first-token: the delay until the model emits the first piece of its reply, which depends on model size, prompt length, and tool calls such as looking up an order.
- Text-to-speech time-to-first-byte: the delay until the synthesiser returns the first chunk of audio. Streaming synthesis starts speaking before the full sentence exists.
- Return transport: the same network legs, in reverse.
What might a budget look like?
The table below is illustrative arithmetic, not measurements. The values are invented round numbers chosen to show how a budget adds up and where trade-offs sit. They are not Vaami's figures, any carrier's figures, or any benchmark. Replace them with your own measured values.
| Stage (illustrative arithmetic, not measurements) | Example allowance | Trade-off |
|---|---|---|
| Network and carrier, both directions | 100 ms | Hosting region and route choice |
| Jitter buffer | 40 ms | Bigger buffer, fewer glitches, more delay |
| Endpointing wait | 150 ms | Shorter wait means more interruptions |
| LLM time-to-first-token | 200 ms | Smaller model or shorter prompt is faster |
| TTS time-to-first-byte | 100 ms | Streaming synthesis helps |
| Total in this example | 590 ms | Each stage must shrink for 300 ms |
The point of the example is arithmetic, not the numbers. Several stages that each look small add up quickly, and getting a total under 300 ms requires either overlapping stages (for example, starting synthesis before the model finishes) or measuring only part of the chain. That second possibility is exactly why the measurement definition matters.
What is different about Indian phone networks?
We are not going to quote India-specific per-hop timings, because we have no verified published figures to cite and numbers vary by carrier, city, and time of day. What can be said is structural.
- Mobile-first audio: most callers are on cellular networks where signal strength, handovers, and congestion vary within a single call.
- Hosting region: if a voice platform's media servers are far from the caller or the carrier's gateway, each audio packet travels further. Ask where the media and model servers run and where your SIP trunk terminates.
- Carrier route: outbound calls routed through different carriers can show different delay and answer behaviour. Test the actual carrier route you will use in production.
- Compliance steps: outbound campaigns to Indian numbers involve DLT-registered sender IDs and DND scrubbing, which happen before the call and do not add in-call delay, but they affect which carrier route is used. See our DLT explainer for the rules.
- Language: Hinglish and regional-language speech may behave differently from English in recognition, so latency should be measured per language, not once.
How do you measure voice AI latency yourself?
Measure from the caller's side, on real calls, using recorded audio of both parties. Server logs are useful for diagnosing which stage is slow, but they cannot tell you what the caller experienced.
- 01Define turn-gap: the time from the last audible sound of the caller to the first audible sound of the agent, measured on a recording of the call at the caller's end.
- 02Make 100 or more test calls over several days and at different times, on at least two mobile networks and one landline, because sample size and variety are what make percentiles meaningful.
- 03Mark every turn automatically with voice-activity detection on the two audio channels, then verify a sample by ear.
- 04Report p50 (median), p90, p95, and the maximum, per language and per call type, and not a single average.
- 05Separate turns that need a tool call, such as an order lookup, from turns that do not, since a lookup adds its own wait.
- 06Record the interruption rate as well: how often the agent started talking while the caller was still speaking. Faster endpointing can buy lower latency at the price of cutting people off.
- 07Repeat the test after any model, voice, or configuration change.
Why do averages hide the pain?
An average blends fast and slow turns. If most turns are quick but one in twenty stalls for several seconds, the mean can still look good while one caller in every call or two meets a long, awkward silence. The 95th percentile (p95) is the value that 95 percent of turns come in under, so it exposes the stalls the average hides. Ask for p50 and p95 together, and ask whether the figures cover all turns or only the successful ones.
Callers do not experience an average. They experience a call made of many turns, and a single long pause can end it. A system with a slightly higher median but a tight p95 often feels better than one with a lower median and an erratic tail.
How do you read the results?
Once you have a distribution of turn-gaps, look at its shape before its centre. A tight cluster with a short tail suggests a stable pipeline. A long tail suggests intermittent problems: cold starts, slow tool calls, overloaded models, or a poor network route. Break the slow turns down by stage using the vendor's logs, and by time of day, network, and call type, to find which link in the chain is responsible.
- If slow turns cluster at certain hours, suspect capacity or carrier congestion.
- If they cluster on turns involving lookups, the integration is the bottleneck, not the voice stack.
- If they appear on one network only, suspect the carrier route or the caller's last mile.
- If gaps are short but interruptions are frequent, endpointing is set too aggressively.
- If one language is slower, check the recognition and synthesis path for that language separately.
What does 'sub-300ms' mean, and what does it not mean?
Vaami's stated claim is sub-300ms end-to-end response latency in production. That is a claim about the full response path under real production conditions, and not a single-component benchmark. Like any latency claim, it only becomes useful to you when it is tied to a definition, and you should ask the same questions of Vaami as of any other vendor.
- Where does the clock start and stop: at the caller's end of speech and the first agent audio, or inside the vendor's servers?
- Is it a median, a mean, or a percentile, and what does p95 look like?
- Does it include the telephony leg, and from which carrier and region?
- Is it measured in production on live calls, or in a lab with no network?
- Does it include turns that call tools or look up data?
- Does it hold for every language you plan to use?
A latency figure is not a promise about every single turn, and it says nothing about whether the agent says the right thing. Speed is necessary, not sufficient: a fast wrong answer is worse than a slightly slower right one. The way to verify any claim is a live pilot with the measurement method above, run on your numbers, your carrier route, and your languages.
How Vaami's speech and language pipeline is built, and what the sub-300ms claim covers.
Vaami's India-focused calling agent with INR pricing and a free demo to run your own latency test.
If you want the short definitions behind the terms used here, the glossary entries for latency and endpointing and turn-taking cover them.
A short definition of latency in voice AI.
How a voice agent decides a caller has finished speaking.
Sources
- Stivers, T., Enfield, N.J., Brown, P., et al. (2009). Universals and cultural variation in turn-taking in conversation. Proceedings of the National Academy of Sciences, 106(26), 10587-10592. doi.org/10.1073/pnas.0903616106
- Vaami latency claim wording: vaami.ai/facts.
- The budget table is illustrative arithmetic by Vaami Editorial, not measured data.