There is a romantic notion in the AI world that voice agents exist in a cloud-native bubble — clean REST APIs, low-latency WebSockets, perfect audio fidelity. The reality is less glamorous. The moment an AI voice agent places or receives a real phone call, it enters the Public Switched Telephone Network: a global infrastructure built over seven decades that does not care about your LLM latency requirements, your preferred audio codec, or your 99.99% uptime SLA.
For Indian Voice AI companies in particular, the PSTN is not a distant concern — it is the primary delivery channel. The vast majority of Cirio calls happen over PSTN-connected mobile and landline numbers. Understanding this infrastructure from first principles is not optional knowledge; it is a prerequisite for building voice agents that actually work reliably at scale across India's complex and heterogeneous telecom landscape.
The PSTN: Seven Decades of Infrastructure
The Public Switched Telephone Network is the aggregate of the world's circuit-switched telephone networks. It started as copper wire and analog switches in the 1950s and has evolved through digital TDM switching in the 1970s, fiber optic backbone networks in the 1990s, and now predominantly VoIP-based core transmission — but the endpoints and last-mile connections that reach actual handsets often remain legacy circuit-switched or early-generation digital infrastructure.
For an AI voice agent, connecting to the PSTN means obtaining telephone numbers called Direct Inward Dials (DIDs) from a telco or cloud communications provider, and handling calls through a SIP stack. SIP is the gateway between the cloud-native world of AI microservices and the legacy world of real telephony. Getting this interface right — and understanding all its quirks — is where many Voice AI implementations struggle.
SIP: The Protocol That Makes It Happen
SIP (Session Initiation Protocol, defined in RFC 3261) is the signaling protocol used to establish, modify, and terminate multimedia sessions — most commonly voice and video calls. It is a text-based protocol loosely modeled on HTTP, which means it is human-readable and reasonably extensible, but also verbose and stateful in ways that create real engineering challenges at scale.
A SIP call setup follows a well-defined flow: the calling party sends a SIP INVITE message to the terminating side. The terminating side acknowledges with 100 Trying, then 180 Ringing as the phone actually rings, then 200 OK when the call is answered. The originating side confirms with ACK, and the session is established. Tearing down the call uses a BYE transaction. Critically, the actual audio does not flow through SIP at all — it flows through RTP (Real-time Transport Protocol), a separate UDP-based stream that carries the encoded audio payload between endpoints. SIP just tells both sides where to send the RTP packets and which codec to use.
RTP packets are generated every 20 ms for most voice codecs. A single 1-minute call generates approximately 3,000 RTP packets per direction. Jitter buffers compensate for variable network latency, but sustained jitter exceeding 50 ms noticeably degrades perceived voice quality.
The Full Call Chain: From AI Agent to Real Phone
Here is the complete chain a call takes when your AI agent dials an Indian mobile number. Your AI application sends a SIP INVITE to your CPaaS provider (Twilio, Exotel, Plivo, Telnyx, or a direct SIP trunk). The CPaaS routes this through its own SIP infrastructure to a carrier interconnect with Airtel, Jio, Vi, or BSNL depending on the destination number. The carrier converts from VoIP to its own mobile network signaling and delivers the call to the destination handset. When the call is answered, RTP audio flows back through this chain to your AI agent in near real-time.
- CPaaS Layer — Twilio, Exotel, Plivo, Telnyx: your SIP interface to the PSTN
- SBC (Session Border Controller) — Security, NAT traversal, codec transcoding
- SS7 — Legacy signaling for circuit-switched interconnects to older infrastructure
- DID (Direct Inward Dial) — The actual phone number your AI agent answers on
- RTP — The UDP audio stream carrying encoded voice between endpoints
- STIR/SHAKEN — Caller ID authentication framework, increasingly enforced by TRAI
Why PSTN Audio Quality Is a Fundamental Challenge
Standard PSTN voice calls use narrowband audio: 8 kHz sampling rate, limited to the frequency range of 300 Hz to 3,400 Hz. This is the band that telephony engineers determined decades ago carries enough information for intelligible speech — but it strips out the high-frequency consonant detail and low-frequency warmth that make voices sound natural. It is why voices sound different on phone calls than in person.
For AI ASR systems, which are almost universally trained on wideband 16 kHz audio scraped from YouTube, podcasts, and speech datasets, narrowband PSTN audio creates a significant acoustic mismatch. The model sees an input distribution during inference (8 kHz, heavy compression, potential packet loss) that is substantially different from its training distribution. This degrades transcription accuracy by 15 to 30 percent compared to clean wideband audio, depending on the model and the severity of the narrowband degradation.
The mitigations are: train or fine-tune ASR models specifically on telephony-quality audio, apply neural upsampling (bandwidth extension) to the narrowband signal before feeding it to the ASR engine, and where possible negotiate HD Voice (G.722, 16 kHz wideband) on VoLTE calls between modern smartphones. HD Voice support has become common on 4G networks in India, and detecting and preferring G.722 in your SDP negotiation can meaningfully improve transcription accuracy on mobile-to-AI calls.
Latency: The Enemy of Natural Conversation
A natural conversation can tolerate roughly 150 to 250 ms of one-way audio latency before listeners start noticing the delay. The PSTN alone contributes 20 to 80 ms depending on routing geography and the number of switching hops. Add network jitter buffering (20 to 60 ms), RTP packetization delay (20 ms), codec encoding and decoding (10 to 30 ms), and you have consumed a substantial portion of your latency budget before a single word has been transcribed.
This is why Voice AI latency optimization is not simply about using a faster LLM. It requires understanding the full stack and minimizing delay at every stage: choosing CPaaS providers with low-latency interconnects to Indian telcos, co-locating your media server in Mumbai or Pune to minimize round-trip to Indian carriers, using streaming ASR and TTS rather than batch processing, and carefully tuning jitter buffer sizes to balance smoothness against latency.
The Indian Telephony Landscape
India has a particularly complex telephony environment for AI agents. Jio, Airtel, Vi, and BSNL operate overlapping 2G, 3G, 4G, and now 5G networks across 22 licensed telecom circles. Call quality varies enormously by region, time of day, and which two networks are on either end of the call. Many rural and semi-urban calls still traverse circuit-switched 2G or 3G infrastructure, resulting in narrowband compressed audio with significant packet loss rates.
Building Voice AI for India means engineering for the worst-case audio quality you will actually encounter across this landscape — which is substantially worse than what most academic Voice AI benchmarks assume. A system that achieves 95% word accuracy on clean LibriSpeech audio might drop to 78% accuracy on a real 2G call from rural Rajasthan. This gap between benchmark performance and production performance is one of the most important and underappreciated challenges in Indian Voice AI.
