← All notes

Voice AI

Your voice agent is only as good as the trunk

Model quality gets the attention, but most production voice AI failures trace back to telephony: codecs, jitter, DTMF, and call routing nobody tested.

  • Invexa Technologies
  • 3 min read

A demo that sounds flawless on a laptop microphone often falls apart on the first real phone call. The model did not change. The audio did. Between the caller’s handset and your inference server sits a mobile network, a codec, a SIP trunk, a media server, and usually a public internet hop, and each of those is an opportunity to lose the intelligibility the model depends on.

Telephony is the least glamorous part of a voice AI stack and reliably the largest source of production incidents.

The Constraints You Inherit

Indian telephony delivers narrowband audio: 8kHz sampling, typically G.711 at 64kbps or G.729 at 8kbps on cost-optimised routes. That discards everything above roughly 3.4kHz, which is exactly where the consonant information distinguishing “s” from “f” lives. Recognition models trained on wideband studio audio lose several points of accuracy on this input unless they have seen telephony data.

What to control:

  • Codec choice. Prefer G.711 where you can pay for it. G.729 saves bandwidth and costs accuracy, particularly for Indic languages with dense consonant clusters.
  • Jitter and packet loss. Above 30ms jitter or 2 percent loss, endpointing starts misfiring and the agent interrupts callers. A jitter buffer helps, and it also adds latency, so it is a trade rather than a fix.
  • Media path. Keep the media server in the same region as the inference endpoint. A round trip from a Mumbai trunk to a US inference region adds 200 to 250ms before any model has done anything.
  • DTMF handling. Callers still press keys, especially for numbers. Support RFC 2833 out-of-band digits and do not rely on in-band tones surviving transcoding.

Compliance Is Part Of The Infrastructure

Outbound voice in India sits under TRAI’s commercial communication rules. Calls to numbers on the DND registry, the wrong calling line identity, or unregistered headers get connections blocked and can put a number series at risk. This is a routing and data problem more than a legal one: scrub lists before dialling, use registered CLIs mapped to the right consent category, and respect calling windows.

Recording adds its own layer. Announce it at the start of the call, store the audio with the same retention discipline as any personal data under DPDP, and keep the transcript linked to the consent record rather than floating in a bucket.

Build For The Call That Goes Wrong

The scenarios that matter are the ones a happy path demo never reaches. What happens when the caller’s network drops mid-sentence? When the inference provider returns a 503? When all human agents are busy at 7pm?

Sensible defaults: a barge-in aware endpointer so callers can interrupt, a fallback prompt after two consecutive recognition failures rather than a third attempt, an automatic warm transfer with the conversation summary when confidence drops, and a graceful “we will call you back” path when the downstream system is unavailable. Every one of these needs a load test, because concurrency limits on trunks and on inference endpoints are the two things that bite simultaneously during a spike.

Instrument the boundary. Log codec, jitter, packet loss and round trip time per call alongside recognition confidence, and the correlation between poor audio and poor outcomes becomes obvious within a week.

At Invexa, we treat the telephony layer as part of the product rather than a pipe to be plugged in later, because the best conversational design in the world cannot survive audio that never arrived intact.

Next step

Have a project in mind?

A 30-minute call is usually enough to know whether we are the right team for it. If we are not, we will say so.

Start a project

Replies within one working day

Start a project