Barge-In and Turn-Taking Benchmark 2026: Why Voice AI Agents Talk Over Indian Customers (and How to Measure It)
The VP of Collections at a Pune-based NBFC played us three call recordings. In the first, the borrower said "haan bataiye" and the agent kept reading its script for another four seconds before responding. In the second, a truck horn went off outside the borrower's window and the agent stopped mid-sentence, waited, then restarted the sentence from the beginning. In the third, the borrower tried to say "मैंने कल ही pay kar diya" and the agent talked straight over the top of it, so the borrower repeated himself, louder, and then hung up.
Three failures, three different root causes, and not one of them shows up in the metric every vendor puts on the slide. The pipeline latency on all three calls was under 800ms. The word error rate was fine. The voice sounded good. The conversation still fell apart, because the agent could not work out whose turn it was to speak.
This post is the benchmark we run on turn-taking, the results across Indian network conditions, and the five numbers you should be asking any voice AI vendor for before you sign. Turn-taking is the most under-measured layer in the Indian voice AI stack, and it is the one that decides whether a call feels like a conversation or a fight for the microphone.
Why turn-taking is the metric nobody publishes
Every vendor benchmark you have seen measures the pipeline: speech to text, then the language model, then text to speech, summed into a "response latency" figure. We have written about that stack ourselves in the sub-500ms latency architecture post, and it matters. But pipeline latency answers only one question: once the agent has decided to speak, how fast does audio come out?
Turn-taking answers three harder ones. When does the agent decide the customer has finished? When does the agent decide the customer has started again? And when both are talking, who yields?
Those decisions are made by a different set of components: the voice activity detector, the endpointing model, the barge-in handler, and whatever logic sits between them. They are cheap to get wrong in a demo and expensive to get wrong in production, because demos happen on a laptop microphone in a quiet room and production happens on a G.711 call to a borrower standing next to a highway in Nashik.
The gap between those two environments is the entire subject of this benchmark.
What we measured
We ran 4,200 calls across four Indian telecom circles between March and July 2026, on live outbound workflows for collections, delivery confirmation and appointment reminders. Every call was recorded with separate near-end and far-end audio tracks so that overlap could be measured precisely rather than inferred.
Five metrics, each defined tightly enough to be reproducible:
Endpointing latency. Time from the true acoustic end of the customer's utterance to the first sample of agent audio. "True acoustic end" was hand-labelled by annotators on the far-end track, not taken from the VAD's own opinion, because using the VAD to grade the VAD is how vendors get flattering numbers.
False barge-in rate. Percentage of agent turns cut short by something that was not the customer speaking to the agent. Background speech, traffic, television, handset handling noise, network artefacts.
Missed barge-in rate. Percentage of genuine customer interruptions where the agent kept talking for more than 700ms after the customer started.
Interruption recovery time. When the agent does correctly yield, time until it produces a relevant response to what the customer actually said, rather than a restart of its own previous sentence.
Double-talk duration. Total milliseconds per call where both parties had voice energy simultaneously. A proxy for how much the call felt like an argument.
Conditions were crossed against network type (PSTN via G.711 a-law, PSTN via AMR-NB on mobile-originated legs, and VoIP via Opus), and against three background noise profiles labelled quiet, domestic and street.
Headline results
Endpointing latency by network and noise condition (median, milliseconds):
| Condition | VoIP / Opus | PSTN / G.711 | Mobile / AMR-NB |
|---|---|---|---|
| Quiet | 420 | 510 | 590 |
| Domestic | 610 | 780 | 910 |
| Street | 940 | 1,240 | 1,510 |
The quiet-room VoIP number, 420ms, is roughly what vendors quote. It is also the condition under which almost no Indian collections call is ever made. Move to a mobile-originated call on a street and the same system takes 1.5 seconds to work out that the customer stopped talking. To the customer that reads as an agent that is slow, confused, or not listening.
False barge-in rate:
| Condition | VoIP / Opus | PSTN / G.711 | Mobile / AMR-NB |
|---|---|---|---|
| Quiet | 1.2% | 2.1% | 2.8% |
| Domestic | 6.7% | 9.4% | 12.1% |
| Street | 14.3% | 19.8% | 24.6% |
Nearly one agent turn in four gets cut short by noise on a street-side mobile call. This is the failure the NBFC's second recording captured, and it is the one customers find most maddening, because the agent appears to keep losing its train of thought.
Missed barge-in rate:
| Condition | VoIP / Opus | PSTN / G.711 | Mobile / AMR-NB |
|---|---|---|---|
| Quiet | 3.4% | 4.1% | 5.2% |
| Domestic | 5.9% | 7.8% | 9.6% |
| Street | 11.2% | 15.1% | 18.7% |
Note the shape. False barge-in and missed barge-in move in the same direction as conditions worsen, which is the uncomfortable part. Most teams tune one knob, the VAD sensitivity threshold, and assume they are trading one error for the other. On clean audio that trade is real. On degraded audio both rise together, because the detector is no longer separating signal from noise at all, it is guessing.
Interruption recovery time (median, milliseconds from customer interruption to relevant agent response):
| System behaviour | Median recovery |
|---|---|
| Restart previous sentence from beginning | 3,100 |
| Resume previous sentence mid-way | 2,400 |
| Discard turn, respond to interruption | 890 |
Only the third row is correct behaviour, and in our sample only 41% of interruption events were handled that way by default configurations.
The five failure modes, and what causes each
1. The agent finishes its sentence over the customer
Cause is almost always a buffering decision rather than a detection one. The text-to-speech chunk has already been synthesised and handed to the media server, and the barge-in signal arrives at the orchestrator with no path to flush what is already in the jitter buffer. The detector was right; the plumbing had no stop valve.
Fix is architectural: the barge-in handler needs authority to drop queued audio frames at the media layer, not just to stop requesting new ones from the TTS. Ask vendors specifically whether barge-in flushes the media buffer. Many will not know the answer, which is itself informative.
2. The agent stops for a truck
Cause is an energy-threshold VAD doing the job of a speech-presence model. Energy thresholds cannot tell a horn from a human, and on AMR-NB the codec's own comfort-noise generation adds artefacts that look like onsets.
Fix is a semantic or speaker-conditioned VAD: a model that asks "is this speech, from the far-end speaker, directed at me" rather than "is this loud". The cost is a few tens of milliseconds of additional latency, and every deployment we have run comes out ahead on that trade in domestic and street conditions.
3. The agent waits too long after the customer stops
Cause is a fixed silence timeout, usually 700ms or 800ms, applied uniformly. Fixed timeouts are wrong in both directions. After "haan" the customer has clearly finished and 800ms is an eternity. After "मेरा account number है..." the customer is mid-thought and 800ms cuts them off.
Fix is semantic endpointing that conditions the timeout on what was just said and on prosody. A trailing rising intonation or a dangling postposition means wait; a complete clause with falling intonation means go. This matters more in Hindi and Bengali than in English because verb-final word order puts the semantic completion cue at the very end of the utterance.
4. The agent yields, then restarts its own sentence
Cause is treating barge-in as a pause rather than as a turn transfer. The agent stops, hears nothing it understands, and resumes its own script. From the customer's side this is the worst behaviour of the five, because it signals that the interruption was heard and ignored.
Fix is to discard the interrupted turn entirely and re-plan from the new conversational state. If the interruption was not understood, ask, do not resume.
5. Both talk, neither yields
Cause is symmetric back-off logic, or none at all. Human conversation resolves overlap through asymmetric yielding: one party has the floor and the other defers, and the roles are negotiated continuously.
Fix is to make the agent the party that always yields. In a customer service context the customer should win every overlap, without exception. This is a one-line policy decision that a surprising number of deployments have never explicitly made.
What the numbers do to business outcomes
Turn-taking failures do not show up as a technical alert. They show up as call abandonment, and they are usually misattributed to the script or the voice.
Across the collections workflows in the sample, calls with more than 2,000ms of cumulative double-talk had a 34% higher hang-up rate in the first 30 seconds than calls under 500ms. Calls with two or more false barge-ins in the first three agent turns showed a 22-point drop in intent-completion rate. On appointment reminder workflows, where the interaction is shorter and more transactional, the effect was smaller but still present at around 9 points.
Those are the numbers worth carrying into a vendor conversation, because they convert an engineering metric into a collections metric. A 24% false barge-in rate is abstract. A 22-point drop in promise-to-pay capture is not.
For context on how these interact with the rest of the funnel, the connect-rate and script variables are covered separately in our A/B testing playbook for Indian voice campaigns. Turn-taking sits underneath all of it: no script survives an agent that will not let the customer speak.
Indian-specific complications
Code-switching breaks endpointing models. A semantic endpointer trained on monolingual English learns that clause-final falling intonation plus a complete predicate means "done". Hinglish speakers routinely complete a Hindi clause and then append an English tag, so the model fires early. We measured a 1.7× increase in early-endpoint errors on code-switched utterances versus monolingual Hindi. This is a distinct problem from the recognition accuracy issues covered in the Hindi code-switching post, and it is not fixed by improving the ASR.
Acknowledgement tokens are not interruptions. Indian conversational Hindi is dense with back-channel tokens: "haan", "ji", "achha", "theek hai", "hmm". These are the listener signalling attention, not requesting the floor. A naive barge-in handler treats every one as an interruption and stops the agent five times in a thirty-second explanation. Our benchmark counts a back-channel-triggered stop as a false barge-in, which is why our false-barge-in numbers are higher than most published figures. Back-channel classification is worth building before anything else on this list.
Speakerphone is the default. A large share of Indian mobile calls, particularly in Tier-2 and Tier-3, are taken on speakerphone. That means acoustic echo of the agent's own voice returning on the far-end track, which every energy-based VAD reads as customer speech. Echo cancellation quality on the telephony leg matters more than the VAD choice.
Network jitter shifts the timing evidence. On congested mobile legs, packet arrival jitter of 80 to 200ms is routine. Endpointing decisions made on arrival timestamps rather than on reconstructed playout timing acquire that jitter as noise. Measure on the reconstructed stream.
The vendor evaluation checklist
Five questions, and the answers you want:
- What is your median endpointing latency on AMR-NB mobile audio with street-level background noise? A vendor who only has a quiet-room VoIP number has not tested for India. A good answer is under 900ms.
- What is your false barge-in rate under the same conditions, and do you classify back-channel acknowledgements separately? Under 10% with back-channel classification in place is strong. Anyone quoting under 2% is quoting quiet-room numbers.
- Does barge-in flush the media buffer, or only stop new synthesis? It must flush.
- On interruption, do you discard the turn and re-plan, or resume? Discard and re-plan.
- Can you provide separated near-end and far-end recordings for a sample of our own calls? If they cannot, they cannot measure any of this on your traffic, and neither can you.
Run these against your own audio, not the vendor's test set. The single highest-value thing an evaluating team can do is hand a vendor 200 recordings from their actual campaign and ask for the five numbers back.
A 30-day measurement plan
Week 1: instrument. Turn on dual-track recording on a 5% traffic slice. Most Indian telephony providers support this on the SIP leg; if yours does not, that is a procurement problem worth solving before anything else.
Week 2: label. Hand-annotate 300 calls for true utterance boundaries and interruption events. This is tedious and it is the only way to get a trustworthy baseline. Three annotators, adjudicate disagreements. Budget roughly 20 hours.
Week 3: measure and segment. Compute the five metrics, then split by network type, circle, time of day and background profile. The segmentation is where the actionable findings live. In our data the worst single segment was mobile-originated street-noise calls between 5pm and 8pm, which is also the highest-connect-rate window, so the failures concentrate exactly where the volume is.
Week 4: fix the cheapest thing first. In order of effort-to-impact: make the agent always yield on overlap, add back-channel classification, switch from fixed to semantic endpointing, then replace the energy VAD. The first two are configuration and a small model; the last two are real work.
Re-measure after each change against the same labelled set. Do not trust an A/B on conversion alone to tell you whether turn-taking improved, because the effect size on conversion is real but slow to reach significance.
Build, buy, or tune what you have
Three paths, and the right one depends almost entirely on whether you control the media layer.
Tune what you have. Correct first move for most teams. If your platform exposes VAD sensitivity, silence timeout and a barge-in policy flag, you can move false barge-in rate by 8 to 12 points and cut wasted latency by 200 to 300ms without writing a model. The ceiling is real though: configuration cannot give you back-channel classification or semantic endpointing, and those are where the remaining gains sit.
Buy a platform that treats this as a first-class concern. The question to ask is not "do you support barge-in", because everyone says yes. It is whether the vendor can show you segmented turn-taking metrics on narrowband Indian audio, and whether the barge-in path reaches the media buffer. A platform that owns its own telephony leg can flush queued frames in single-digit milliseconds. One that sits behind a third-party SIP trunk it does not control often cannot, and no amount of model quality fixes that. This is the main structural reason we build the telephony integration ourselves rather than reselling, and it is worth checking on any vendor you evaluate, including us.
Build the components in-house. Justified in one situation: you have unusual audio conditions, a large enough call volume to amortise the work, and an ML team that already handles audio. A speaker-conditioned VAD plus a semantic endpointer fine-tuned on your own labelled Indic telephony data will beat anything general-purpose on your traffic. Budget two engineers for a quarter plus the annotation cost, and be honest that you are also signing up to maintain it. Below roughly 200,000 minutes a month the arithmetic rarely works.
Whichever path you take, the measurement harness is not optional and is not something to outsource. Owning the labelled test set is what lets you tell whether a vendor change, a model upgrade or a telephony migration helped or hurt. Teams that skip this end up arguing about call recordings anecdotally, which is how the Pune NBFC at the top of this post spent four months blaming its script.
Compliance notes that intersect with turn-taking
Two regulatory points that bear directly on the recording setup this benchmark requires.
Dual-track recording is still recording. Under DPDP 2023 the consent you hold for call recording must be purpose-bound. If your existing consent language covers quality monitoring, turn-taking measurement sits comfortably inside it. If your consent was drafted narrowly around dispute resolution, extend it before you turn on the 5% slice. Separated tracks do not change the legal character of the data, but they do make it easier to argue the recordings are being used for service quality rather than profiling.
Disclosed recording obligations apply to the agent's opening. For IRDAI-regulated sales calls and for most RBI Fair Practices Code collections workflows, the recording disclosure has to be delivered clearly at the start. This interacts with barge-in in a way teams miss: if the customer interrupts during the disclosure and the agent yields, the disclosure was not completed. Policy should be that the disclosure segment is the one turn where the agent finishes, then acknowledges the interruption. That is the single defensible exception to the always-yield rule.
What changes in the next twelve months
Full-duplex speech models that handle turn-taking natively, rather than as a pipeline of separate components, are moving from research into production. They collapse the VAD, endpointer and barge-in handler into one model that predicts turn transitions directly from audio. Early results on English are good. Indic-language and telephony-band versions lag by roughly a year, which puts serious Indian production availability somewhere in mid to late 2027.
The second shift is telephony-side. As VoLTE penetration rises and more legs terminate on wideband codecs, the AMR-NB column in these tables shrinks. That helps, but slowly, and BSNL and rural circles will keep narrowband alive well past 2027.
The practical implication for anyone buying now: do not architect around the assumption that a single model will solve this shortly. Build the measurement harness, because the harness stays valuable regardless of which component you swap underneath it.
Bottom line
Pipeline latency is the metric vendors publish because it is the one they can make look good. Turn-taking is the metric that decides whether the call works. On Indian mobile audio with real background noise, the systems we tested took 1.5 seconds to detect that a customer had stopped speaking and cut themselves off on noise nearly a quarter of the time, and neither number appears on any vendor datasheet.
Measure endpointing latency, false barge-in rate, missed barge-in rate, interruption recovery time and double-talk duration, on your own audio, under your own network conditions. Make the agent always yield. Classify back-channels before you touch anything else. Everything else in a voice deployment sits on top of the agent and the customer agreeing on whose turn it is.
If you want the labelled test set or want us to run these five numbers against a sample of your recordings, talk to our team. We will send back the segmented results whether or not you end up buying anything.
Frequently Asked Questions
Tags :
