How to Give Your LiveKit, Vapi, or Retell Voice Agent a Real Indian (+91) Phone Number

The problem: your voice agent is ready, but India won't pick up

You have a working voice AI agent — maybe built on LiveKit Agents, Vapi, or Retell — and you need it to be reachable on a real Indian phone number. Not a virtual number from a gray-market SIM reseller. Not a US Twilio number with unreliable India routing. A legitimate +91 business inbound number that your users can call from any Indian mobile or landline.

Here is what the standard path looks like:

1. Find a licensed Indian telecom operator or ITSP (Internet Telephony Service Provider).
2. Submit KYC documents, company registration proof, sometimes a signed LOA (Letter of Authorization).
3. Wait days or weeks for number provisioning.
4. Receive SIP credentials — if you are lucky, a vague PDF with no webhook documentation.
5. Figure out on your own how to bridge that SIP trunk to your agent framework.
6. Hope the number actually works for inbound calls from BSNL, Jio, and Airtel.

Most developers building voice AI side projects or SaaS products hit a wall at step 2. And even teams that get through provisioning discover that Indian telecom providers have almost zero developer-friendly tooling: no webhook endpoints, no call logs via API, no programmable routing rules.

This article explains the underlying telecom concept (DID routing), how it should connect to a voice AI agent, and what a developer-first approach looks like.

What is a DID, and how does inbound call routing actually work?

DID stands for Direct Inward Dialing. It is a phone number leased from a telecom carrier that, instead of connecting to a physical phone line, routes inbound calls over SIP (Session Initiation Protocol) to a destination you configure — a SIP URI, a media server, a WebRTC gateway, or an HTTP webhook.

The routing chain for a typical voice AI agent looks like this:

Caller dials +91 XXXXX XXXXX
         |
   Telecom PSTN (Jio, Airtel, BSNL)
         |
   ITSP / DID provider  <-- this is the layer most teams lack
         |
   SIP trunk or webhook  <-- where your code takes over
         |
   Your voice agent (LiveKit, Vapi, Retell, Asterisk, etc.)
         |
   AI model + TTS/STT

The ITSP layer is the piece that turns a PSTN call into something a developer can interact with. A good DID provider exposes:

• A SIP endpoint you can point at a media server (LiveKit SIP, FreeSWITCH, Asterisk)
• A webhook that fires when a call arrives, letting you dynamically decide routing (transfer, drop to IVR, connect to agent)
• Call detail records accessible via API so you can build billing logic or debug dropped calls
• Fallback routing so calls do not silently fail if your agent is down

Most Indian telecom providers expose none of this. They provision the number and give you a SIP trunk — full stop. The webhook layer, the fallback logic, and the call logs are your problem.

Why Indian numbers specifically are harder than US numbers

If you have built voice agents targeting the US market, you are used to Twilio, Vonage, or Plivo — providers that are developer-first from day one with REST APIs, webhooks, and SDKs.

India has structural differences:

Regulatory layer. Inbound business numbers in India require TRAI-compliant provisioning. The operator must verify the entity behind the number. This is not optional — it is what makes the number legitimate and ensures it works across all Indian carriers.

PSTN interconnect complexity. India has fragmented carrier interconnects. A number that works on Jio may not route cleanly from BSNL or a rural landline without proper carrier agreements on the ITSP side.

No developer-first incumbents. The large Indian telecom operators (Airtel Business, Jio Enterprise) are built for enterprise customers with long contract cycles, not for a developer who wants to spin up a number over a weekend.

The result is that most voice-AI developers building for the Indian market either skip inbound entirely, use SMS fallback, or cobble together offshore numbers with unreliable India routing.

What a clean DID-to-agent connection looks like

The ideal flow for a voice AI agent on an Indian number:

1. Number provisioned and verified (handled by provider)
2. Inbound call arrives at DID
3. Provider fires webhook POST to your URL:
   { "call_id": "...", "from": "+919...", "to": "+9198...", "timestamp": "..." }
4. Your webhook responds with routing instruction:
   { "action": "connect", "destination": "sip:agent@your-livekit-host" }
   -- OR --
   { "action": "connect", "destination": "wss://your-retell-agent" }
5. Media is bridged; your agent handles the conversation
6. Call ends; CDR record available via API

With LiveKit specifically, you would run the LiveKit SIP component pointed at the DID provider's outbound SIP trunk, and use the webhook to trigger agent dispatch. With Vapi or Retell, you configure the inbound SIP URI in their dashboard and the DID provider terminates to it.

The critical insight: the DID provider only needs to answer the call and deliver it to your SIP/webhook endpoint. Your agent framework handles everything after that. The hard part is finding an Indian provider that actually exposes that clean hand-off.

Boni Voice API: the developer path for Indian DIDs

Boni Voice API (boni.one/apis/voice) is built exactly for this gap. It provides dedicated Indian (+91) inbound business numbers with developer-oriented routing.

What the API surface covers:

• India DID provisioning (boni.one/apis/voice/india-did): get a +91 number assigned to your account, configured for inbound routing.
• Webhook routing: point the number at an HTTP endpoint. Boni fires a webhook on inbound calls so your service decides in real time what happens.
• SIP routing: connect to a SIP URI — LiveKit SIP, Asterisk, FreeSWITCH, or a hosted provider like Vapi/Retell.
• LiveKit connector (boni.one/apis/voice/livekit): native integration for teams running LiveKit Agents who want to skip the SIP plumbing and go directly to agent dispatch.
• Call logs: inbound call records accessible so you can build audit trails or debug routing failures.
• Fallback handling: Boni manages what happens when your agent endpoint is unreachable, so callers do not hit dead air.

Pricing starts at Rs 500/month per number — within range for a side project or early-stage SaaS. Onboarding is assisted beta; you get in via WhatsApp (link on the product pages above) so a human helps you through initial setup and KYC, which keeps the provisioning compliant without requiring you to negotiate directly with a telecom operator.

The KYC requirement is not optional — it is the same requirement that makes the number legitimate. Boni handles that layer on your behalf.

Who this is for

• Voice AI developers building phone agents targeting Indian users who need a reachable +91 inbound number.
• AI agencies deploying customer service or IVR agents for Indian businesses.
• SaaS platforms that include phone-channel features and need to provision numbers programmatically for their customers.
• n8n / no-code automation builders who want to trigger voice agent flows from inbound Indian calls via webhook.
• LiveKit / Vapi / Retell users who have the agent working and just need the Indian number layer sorted.

Getting started

1. Visit boni.one/apis/voice or directly boni.one/apis/voice/india-did.
2. Use the WhatsApp CTA on the page to start the assisted onboarding.
3. Complete number provisioning (KYC handled with Boni's help).
4. Configure your webhook URL or SIP URI in the Boni dashboard.
5. Start receiving calls on your +91 number routed to your agent.

If you are on LiveKit, the dedicated connector page at boni.one/apis/voice/livekit covers the specific integration steps.

Getting a legitimate Indian inbound number for a voice agent is genuinely hard today. The problem is not technical — it is the opaque telecom layer sitting between PSTN and your code. Once that layer exposes a clean webhook or SIP hand-off, the rest is standard agent development. That is the gap Boni Voice API is built to close.