OpenAI Realtime API vs Voice AI Platforms India 2026: What It Actually Takes to Ship AI Calling Agents on a Raw Model API

Your team shipped the demo in a weekend. That is the problem.

A Bengaluru engineering lead we spoke to in March had exactly this story: two engineers, one Saturday, a WebRTC page talking to the OpenAI Realtime API, function calls hitting their staging CRM. The agent booked a test appointment, handled an interruption, even switched to Hindi when asked. Monday morning the founder saw it and said the obvious thing: "Why are we evaluating vendors at ₹6 a minute? We can build this."

Ninety days later the same team was still fighting SIP trunk audio codecs, had discovered that TRAI DLT scrubbing has to happen at dial-time rather than when the campaign is queued, and had a working agent that sounded great on WebRTC and clipped its own sentences over a lossy Airtel PSTN leg. The demo took a weekend. The gap between that demo and a production dialer making 40,000 compliant calls a day in Hindi, Tamil and code-switched Hinglish is what this post is about.

This is not another generic build-vs-buy piece. We have already written that math twice, in the build vs buy TCO comparison and the enterprise build-vs-license framework. This post is narrower and more technical: what the Realtime API specifically gives you, the roughly dozen production layers it deliberately does not, and how to decide which side of that line your use case sits on.

The thesis

The OpenAI Realtime API is the best speech-to-speech model access most teams have ever had, and it is also about 20% of a production AI calling system for India. The model layer (understanding, generation, turn-taking, function calling) is now genuinely commodity-grade excellent. Everything that made voice AI hard in India before 2024 (PSTN termination, DLT compliance, code-switched accuracy on real telco audio, campaign orchestration, retry economics, observability) is still hard, and the Realtime API does none of it. If your voice agent lives inside your app over WebRTC, build on the raw API. If it has to dial Indian phone numbers at scale under TRAI and DPDP, you are either signing up to build a telephony company or licensing one.

Why this decision is landing on every CTO's desk in 2026

Three things changed between 2024 and now.

Speech-to-speech went GA and got cheap enough to prototype carelessly. The gpt-realtime family is out of beta, latency to first audio token is routinely under 300ms from Mumbai-region endpoints, and function calling inside a live conversation is stable. The barrier to a convincing demo collapsed. In 2023 a voice agent demo took a quarter; now it takes a sprint, which means every board deck has one.

The demo-to-production gap became the actual moat. When the model was the hard part, model access was the differentiator. Now that everyone has the same models (OpenAI, Gemini, Sarvam, open-weights Ultravox-style stacks), the differentiation moved down the stack into telephony, compliance and orchestration. That is precisely the layer the Realtime API does not touch.

Indian regulators did not get simpler. TRAI's DLT regime tightened through 2025 with stricter header and template enforcement, DPDP rules are now being audited in BFSI procurement, and the RBI's stance on collections conduct applies to a bot exactly as it applies to a human caller. None of this is in any model API's documentation, because it is not the model's job.

So the question in front of an Indian engineering leader in 2026 is no longer "can we build a voice agent?" You can. It is "which 80% of the system do we want to own?"

What the Realtime API actually gives you

Credit where due, because the list is substantial:

• Native speech-to-speech. No separate STT and TTS hop. The model hears audio and emits audio, which removes one full serialization boundary and the compounding errors of a three-model pipeline. Prosody, hesitation and tone survive in a way cascaded stacks struggle to match.
• Fast first token. Model-side time-to-first-byte of 200–400ms is normal. This is the number the demo sells.
• Server-side turn detection. Semantic VAD that decides when the caller has finished speaking, tunable for eagerness. On clean audio it is genuinely good.
• Function calling mid-conversation. The agent can hit your CRM, check an order status or write a disposition while talking. This is the piece that makes the weekend demo feel like a product.
• SIP ingress, minimally. OpenAI added a SIP interface, so you can point a trunk at it. What you get is a socket, not a calling platform: no dialer, no DID management, no carrier relationships, no answering-machine handling.
• WebRTC out of the box. For in-app and browser voice, this is the whole transport story solved.

If your product is an in-app voice copilot, a browser-based sales assistant, a voice interface inside your own mobile app, this list is most of what you need. Build on the raw API and do not look back. The rest of this post is about what happens when the agent has to make phone calls in India.

The twelve layers the Realtime API does not give you

This is the gap the Bengaluru team fell into, one layer at a time. We have written a full teardown of the telephony integration challenges for voice AI platforms in India; the summary version, specific to the raw-API path:

1. PSTN termination and carrier plumbing

The Realtime API terminates a SIP session. It does not get you DIDs, carrier interconnects with Airtel/Jio/Vi, trunk redundancy, codec negotiation with gateways that still speak G.711 at 8kHz, or a relationship with an Indian operator when a trunk starts dropping RTP mid-afternoon. You will run your own SBC or contract a CPaaS (Plivo, Exotel, Twilio), and now you are integrating and paying for two vendors before the first call connects.

2. Audio reality at 8kHz

The model is trained and demoed on 16–24kHz clean audio. An Indian mobile call arrives as 8kHz narrowband, often transcoded twice, with packet loss bursts on Jio VoLTE-to-2G handoffs in Tier-2 geographies. Turn detection that felt telepathic on WebRTC starts clipping callers mid-sentence, and barge-in (the caller interrupting the bot) becomes a tuning project of its own: echo cancellation on the trunk, VAD thresholds per carrier, jitter buffers you now own.

3. Latency over the full loop, not model TTFB

Model TTFB of 300ms is not the number your caller experiences. The production number is microphone-to-ear round trip: caller audio to your media server, to the API region, model processing, audio back down the same path. On real Indian PSTN legs we see teams land at 900ms–1.4s p50 and 2s+ p95 on naive architectures, which callers experience as "the bot is slow" and talk over. Getting under the sub-500ms budget that survives real telephony means regional media servers, speculative endpointing and careful buffer tuning. All yours to build.

4. Indic languages and code-switching off the demo path

The Realtime API's Hindi is Delhi Hindi. Production collections and COD calls hit Bhojpuri-inflected Hindi in Patna, Marwari-inflected Hindi in Jodhpur, Tamil-English switching four times in one sentence in Chennai. Recognition quality on demo audio and on your own campaign audio are different measurements, usually by a factor of 1.6–2.4x on error rate. Platforms that run Indian traffic have per-region prompt scaffolds, pronunciation lexicons for Indian names and addresses, and fallback flows for low-confidence turns. On the raw API, your team discovers each of these as a production incident.

5. TRAI DLT scrubbing at dial-time

Every commercial outbound call in India runs through the DLT regime: registered headers, approved templates, consent scrubbing against the DND registry. The scrub has to happen at dial-time, not when the campaign was queued the night before, because preferences change daily. This is a hard legal requirement with per-violation penalties, and it lives entirely outside the model API. Our TRAI DLT compliance playbook for AI outbound calling covers what "compliant" actually means; on the raw-API path, all of it is custom code plus a DLT platform integration.

6. DPDP consent and data residency

DPDP 2023 requires purpose-bound consent, and your legal team will ask where the audio goes. With the Realtime API, caller audio transits OpenAI infrastructure under OpenAI's data terms; for a bank or insurer whose compliance team requires in-country processing or contractual data-residency guarantees, that is a procurement blocker you cannot code around. Platforms answer this with region-pinned deployments and signed DPAs; on the raw API you inherit whatever OpenAI's current enterprise terms allow.

7. Campaign orchestration and retry ladders

A production calling operation is not "make a call." It is: upload 200,000 records, dedupe, scrub, prioritize, dial within permitted windows (and Hindi-belt borrowers do not pick up before 10:30am), detect answering machines, leave or skip voicemail, retry no-answers on a decaying ladder at different hours, cap attempts per TRAI norms, sync every disposition back to the CRM. This is a workflow engine, a scheduler, and a dialer. None of it exists in the Realtime API.

8. Answering machine and voicemail detection

Between 25% and 40% of Indian outbound connects are not a human: voicemail, carrier messages ("the number you are trying to reach..."), switched-off announcements in eleven languages. A bot that delivers its EMI reminder to a carrier announcement is burning ₹ per minute and polluting your metrics. AMD tuned for Indian carrier audio is unglamorous, essential and absent from the model layer.

9. Observability, QA and call scoring

When a campaign underperforms, you need to know whether the problem was connect rate, turn-two comprehension, a mispronounced brand name or a broken function call. That means full-call transcripts aligned to audio, latency traces per turn, automatic QA scoring, disposition analytics by language and region. The API gives you events on a socket; the analytics warehouse on top is a product of its own.

10. Human handoff

Some fraction of calls must escalate to a human with context: warm transfer over the same trunk, screen-pop into the agent desktop, conversation summary attached. SIP REFER plus CRM integration plus queueing. Yours to build.

11. Economics at scale

Covered in detail below, because the "APIs are cheap" intuition does not survive audio-token pricing.

12. The maintenance treadmill

Model versions deprecate, prices move, carriers change behavior, TRAI updates templates rules. A platform amortizes that churn across hundreds of customers. Your two-pizza team absorbs it alone, forever. This is the quiet cost that never appears in the build estimate.

The comparison matrix

Dimension	OpenAI Realtime API (raw)	DIY cascaded stack (STT + LLM + TTS)	Managed platform (Caller Digital and peers)
Telephony / PSTN	SIP socket only; you bring trunks, DIDs, SBC, carrier ops	Fully yours: CPaaS or direct interconnects	Included: trunks, DIDs, carrier failover managed
Latency on Indian networks	300ms model TTFB; 900ms–1.4s p50 full loop until you optimize	Tunable per component; hardest to get under 800ms	500–800ms full loop typical, pre-optimized for Indian carriers
Indic languages & code-switching	Good demo Hindi; degrades on regional accents at 8kHz	Choose Indic-first STT (Sarvam, AI4Bharat lineage); most control	Pre-tuned per language/region with fallback flows
TRAI DLT / DPDP compliance	None; fully custom	None; fully custom	Built in: dial-time scrubbing, consent logs, calling windows
Campaign orchestration & retries	None	None	Included: dialer, retry ladders, AMD, calling windows
Observability & call QA	Socket events; build your own warehouse	Build your own	Dashboards, transcripts, QA scoring included
Cost model	~$0.30–0.50 per 3-min call in audio tokens (₹8–14/min effective at 2026 list prices) plus CPaaS per-minute plus infra	Component costs ₹2–5/min possible at volume, plus heavy engineering	₹4–9/min all-in, or per-outcome pricing
Time to production (India outbound)	2–3 quarters realistically	3–4 quarters	2–6 weeks
Ongoing maintenance	2–3 engineers permanently	3–5 engineers permanently	Vendor's problem
Who it suits	In-app/browser voice, engineering-led product companies, non-telephony channels	Very large scale (5M+ min/month) with strict cost/control needs	Anyone whose agent must dial Indian numbers compliantly, soon

The numbers: what the raw-API path actually costs

Run the math the way a finance team will, not the way a hackathon does.

Model cost. Realtime audio pricing in 2026 sits around $32 per 1M audio input tokens and $64 per 1M output tokens on the flagship tier (cheaper minis exist, with a quality cut you will notice on noisy Hindi). A conversational minute burns roughly 1,600–2,000 audio tokens each way once you count both legs and silence handling. A typical 3-minute collections or COD call lands between $0.25 and $0.50 in model cost alone: ₹8–14 per minute effective at current exchange rates before you have paid for anything else. The mini tiers pull this down to ₹2–4/min, and are often where teams end up after quality-testing against their own audio.

Telephony cost. Domestic outbound termination via CPaaS runs ₹0.35–0.60/min. Small next to the model line, but the CPaaS platform fees, DID rentals and DLT platform charges add up to a second vendor bill.

Engineering cost. The honest estimate we see from teams that have done it: 3–5 engineers for 2–3 quarters to reach a production-grade India outbound system (telephony, compliance, orchestration, observability), then 2–3 engineers permanently. At Indian senior-engineer loaded costs of ₹35–60 lakh/year, the build is a ₹1.5–3 crore first-year line item before a single campaign runs. That only pays back above roughly 1.5–2 million minutes a month, and only if the team executes cleanly.

Platform comparison. Managed platforms price India outbound at ₹4–9/min all-in, and increasingly per outcome rather than per minute. At 300,000 minutes/month, the platform bill is ₹15–25 lakh/month with zero engineering headcount attached; see current pricing for how we structure it. The crossover point where raw-API economics win is real, but it is much further out than the demo suggests, and it assumes your engineers' time was free to begin with.

When the raw API is the right call

An even-handed reading, because there are teams for whom licensing a platform is the wrong answer:

• The voice agent lives in your product, not on the phone network. In-app voice, browser copilots, kiosk interfaces. WebRTC transport, no TRAI, no PSTN. The Realtime API is close to the whole stack here, and a platform adds a layer you do not need.
• Voice is your core product differentiation. If you are building a voice-native product where conversation quality is the moat, you want model-layer control: prompt-level turn tuning, custom tool schemas, model routing. Own it.
• You genuinely run at platform-scale volume. Above roughly 5 million minutes/month with a strong infra team, owning the stack can beat platform pricing, the same way big companies eventually in-house their CPaaS.
• Non-Indian, single-language markets. A US English use case skips the DLT, code-switching and 8kHz-regional-accent problems that make India specifically hard. The gap between API and production is smaller there.

If two or more of those describe you, prototype on the raw API with a straight face. If none do, the weekend demo is a sunk-cost trap wearing a hoodie.

When it is not

The flip side, stated plainly: if the agent's job is to dial Indian mobile numbers for collections, COD confirmation, lead qualification or renewals, at tens of thousands of calls a day, under TRAI and DPDP, in more than one Indian language, and you need it live this quarter, the raw-API path means building a telephony and compliance company as a side quest. The model was never the hard part of that system. We have watched three mid-market teams take the API route for exactly this workload in the past year; two came back to a platform evaluation inside six months, and the third is still building, with the original business case quietly re-dated twice.

A 30-day decision playbook

Do not decide this in a meeting. Decide it with a structured spike:

1. Week 1: build the WebRTC prototype. Two engineers, raw Realtime API, your real prompts and function calls. This validates the conversation design and costs almost nothing. Everyone should see it; it sets the quality bar.
2. Week 2: put it behind a real Indian phone call. SIP trunk from a CPaaS, real mobile handsets on Jio and Airtel, including one Tier-2 location. Measure full-loop latency p50/p95, barge-in behavior and comprehension on your own recorded campaign audio, not demo phrases. This is where the gap becomes measurable instead of theoretical.
3. Week 3: write the compliance and ops spec. DLT scrubbing at dial-time, DPDP consent logging, calling windows, retry caps, AMD, human handoff, analytics. Estimate it honestly with your own engineers. This document is the real cost of the build path.
4. Week 4: price both paths at your 12-month volume. Raw-API total (model + CPaaS + engineering + maintenance) against 2–3 platform quotes at the same volume. Include time-to-revenue: a platform live in week 6 versus a build live in Q3 is usually the deciding line, not the per-minute rate.

Teams that run this spike make the decision with numbers. Teams that skip it make the decision twice.

What changes in the next 12 months

Three shifts worth pricing into the decision. Model costs keep falling: realtime audio pricing has dropped roughly 60% since launch and the mini tiers will keep compressing, which improves raw-API economics at the margin without touching the telephony and compliance gap at all. Indic-first speech-to-speech models (Sarvam's line and AI4Bharat-lineage work) will narrow the regional-accent gap, and the serious platforms will adopt them faster than individual teams can evaluate them. And expect at least one more tightening cycle on TRAI's UCC enforcement and DPDP audits in BFSI, which moves the compliance layer from "nice to have" to "procurement gate" for anyone selling into banks and NBFCs. None of these trends make the raw-API path easier for Indian outbound; they make the model layer cheaper while the moat stays exactly where it is.

Bottom line

The OpenAI Realtime API in 2026 is a superb conversation engine and a misleading demo of a calling system. For in-app and browser voice, build on it directly. For production AI calling in India, the model is the easy 20%: PSTN termination, 8kHz audio reality, TRAI DLT at dial-time, DPDP residency, Indic code-switching, orchestration, AMD, QA and the permanent maintenance tail are the 80% the API will never ship. Run the 30-day spike, price both paths at your real volume, and be honest about whether you want to be a telephony company. Most teams do not. Talk to us if you want to see the platform side of that comparison on your own call recordings and your own campaign math.