On our integrations page, Twilio gets one line: "Powers voice and SMS, with failover." True, and also easy to misread as "Twilio runs the AI." It doesn't. Here's what Twilio actually does in an AIVA call or text, what happens on our side of that line, and why the split matters more than the one-line summary lets on.
What Twilio owns
Twilio is telephony infrastructure. It's the part of the stack that deals with phone networks, not with understanding what anyone's saying.
Concretely: number provisioning (a new AIVA voice number, or a ported one, is a Twilio number underneath), call routing from the carrier network to us, SIP trunking, WebRTC media relay for browser-based calls, and SMS delivery out to carrier networks like Jio and Airtel. When we shipped SMS as AIVA's first non-web channel back in 2024, it ran on Twilio underneath, and it still does — customers bring their own number or buy one through us, and either way Twilio is the thing actually getting the message onto a phone.
Most AIVA customers never create a Twilio account or see a Twilio credential. We provision the number and manage the connection, and it stays invisible from the customer's side — that's deliberate. Telephony plumbing isn't something a clinic or salon owner should have to think about.
What actually happens between a ring and a response
Walking through one call end to end: a customer dials an AIVA number. The call hits the carrier network — Jio, Airtel, whichever the caller is on — and gets handed to Twilio's infrastructure over SIP, the same protocol basically every modern telephony system speaks underneath. Twilio terminates that leg and opens a media connection toward us. From there, audio streams into our inference service in real time, in small chunks, not as a full recording waiting to be picked up after the call ends — the whole architecture only works inside a sub-300ms budget if audio starts flowing the instant it exists, not after some buffering delay.
On the way out, it's the same path in reverse: our synthesized response streams back to Twilio, and Twilio relays it to the caller over the same connection. A browser-based call — someone testing AIVA from the dashboard, for instance, rather than dialing a phone number — takes the WebRTC path instead of the carrier/SIP path, but lands in the same place on our side once the audio actually arrives. Twilio owns getting audio to us and getting our audio back to a caller, reliably, over whichever transport the call started on. Nothing about what happens in between — the actual conversation — touches Twilio's systems at all.
What AIVA owns
Everything about the conversation itself sits on our side: speech recognition, language understanding, the reasoning that decides what to say or do next, speech synthesis, and the logic that decides when to book something or hand off to a person. None of that is Twilio — it's our own inference stack.
That wasn't always one hop. The original voice pipeline — internally we called it "the chain" — routed a call through four separate vendor APIs in sequence: one for transcription, one for language understanding, one for synthesis, with Twilio on both ends. Five network hops between a customer talking and AIVA responding, each one an independent point where something could fail silently, with no way to tell which hop had caused it short of checking several different vendor dashboards in turn. We rewrote it from scratch once that architecture became the hard ceiling on latency — you can't fit five network round-trips inside a 200ms budget no matter how fast any individual hop runs.
Today it's a single unified service that sits right next to Twilio's media server, in the same region — audio comes in from Twilio, gets processed in one place, and goes back out through Twilio. One hop each way, not five. Speech recognition, understanding, and synthesis all run inside that one process rather than being handed between separate systems, which is also why a failure is something we can actually see and diagnose, instead of a mystery spread across dashboards we don't control.
The codec detail that actually mattered
Some of the more interesting latency work turned out to live inside Twilio's own delivery leg, not our inference. We covered this in full in the latency write-up, but the short version: Twilio's default WebRTC encoder uses Opus at 20ms frame intervals, with a lookahead buffer added on top for the codec's bitrate prediction — a deliberate trade-off that favors call quality over latency, and a sensible default for a generic telephony product where nobody's chasing 200ms. Every audio packet was sitting in that buffer for extra milliseconds before it even left Twilio's side, on every call, by default.
Twilio exposes a preferredCodecs override for exactly this kind of tuning. Switching to shorter frames with no lookahead cut that leg from 35ms to 8ms, a 27ms improvement, with no noticeable quality difference in our own testing. That's the kind of gain that only exists because we're paying attention to what Twilio is doing under its defaults, rather than treating it as a black box we can't touch. It's also a small piece of a bigger number: the same audit found speech-to-text running at roughly 48ms, LLM inference cut from 82ms to 51ms by streaming tokens straight into synthesis instead of waiting for a full response, and the most common opening phrases pre-synthesized and served from cache instead of generated fresh on every call. None of those are Twilio's numbers to own or improve — they're ours. The codec fix is the one piece of that budget that happened to live on Twilio's side of the line.
Why the region has to match on both sides
The "same region" detail above is easy to skim past, but it's load-bearing. Twilio itself operates regionally — media servers and SIP infrastructure in multiple locations, not one global instance — and part of getting latency right is making sure we're talking to the Twilio infrastructure closest to the call, not just running our own inference somewhere convenient. We run inference out of three regions ourselves — Mumbai, Frankfurt, and Virginia — routed by where the caller actually is, for reasons that come down to physics, not preference: the fixed time it takes a signal to travel, which no amount of inference optimization removes. Get the Twilio leg and the inference leg in the same region, and that distance cost mostly disappears. Get them in different regions — inference in Mumbai, media relay routed to a Twilio edge somewhere else — and you've reintroduced exactly the travel-time cost the whole regional strategy exists to avoid, no matter how fast either side is individually.
Failover, in practice
"With failover" means what it sounds like: if a route has a problem, calls go over a backup route instead of dropping. We don't publish the routing details, for the same reason most companies don't publish retry logic in detail — it changes as we tune it, and the number that matters isn't the mechanism, it's the outcome.
SMS runs on the same infrastructure, different rules
SMS shares Twilio underneath — the same provisioned number can carry both voice and text, and message delivery to carrier networks goes over the same relationship — but the engineering problem on our side looks completely different from voice. A phone call is a continuous connection; the moment it ends, the conversation is over one way or another. A text message is a single, disconnected event with no session behind it, and a customer can reply six hours later having put their phone away and forgotten they were mid-conversation. Twilio's job on SMS is delivery — getting the message to a carrier network like Jio or Airtel and back — not remembering anything between messages. That's entirely our own engine's problem to solve, and it's a different kind of hard than getting voice under 200ms.
The number that matters
All of this — the single-hop architecture, the codec tuning, the regional routing — is in service of one thing: AIVA answers in about 198ms on average and resolves roughly 96% of calls without a human. That average sits comfortably under the roughly 300ms pause that shows up naturally between turns in ordinary human conversation, which is the actual bar we measure against — not "fast for a bot." Twilio gets the call to us and the audio back to the caller. Everything that happens in between is ours.
Why this is worth knowing
Not because you need to configure any of it — you don't touch Twilio directly, and that's the point. But if you're evaluating AIVA against a tool you'd build yourself on top of raw Twilio, this is the actual gap: Twilio gets you the phone call, and it gets you SMS delivery to a phone that never opens an app. It doesn't get you the 198ms response, the 96% resolution, or the twelve languages. That part took us over a year to build across a pipeline rewrite, a codec fix Twilio doesn't advertise, and three regional deployments — and none of it is Twilio at all.
See how the full voice stack performs on the voice platform page, how the same event data reaches your own systems in the webhooks write-up, or the complete connection list on integrations.