The Re-emergence of SIP: How Voice AI Brought Back the Beast

TL;DR: SIP—the complex telephony protocol we thought WebRTC would retire—has re‑emerged as the backbone of Voice AI bots in contact centres, dragging legacy headaches like unencrypted media and low‑quality audio with it, so we must relearn those 1990s quirks and patch them fast.

I genuinely thought we’d left SIP behind. When we built WebRTC in the early 2010s, it felt like we were creating a cleaner, more modern path forward for real-time communications. Yet here we are in 2024, and SIP has returned from the periphery to claim centre stage once again. The catalyst? Voice AI.

The Legacy Beast

SIP connected computer systems to telephony networks from the late 1990s through the 2000s. It became the foundation of everything from office PBX systems to 3G IMS architecture. At the time, it was revolutionary—the easiest way to bridge the gap between traditional telephony and computer systems.

But "easiest" came with a price. SIP sprawled across hundreds of RFCs, each addressing different use cases. Need to implement muting in a conference and signal that across to everyone? There’s probably a couple of RFCs for that. The real complexity emerged when different vendors implemented similar features using completely different approaches, which made sense that they were competing for time to market and then bringing what they did to the standards. Take DTMF tones as an example: there are three standardised ways to send them. These are in‑band audio, RFC 4733 telephone‑events (often still called “RFC 2833”), and SIP INFO messages. Three! Each one equally valid, which means any serious Voice AI implementation needs to support all three for broad compatibility.

The protocol became a testament to xkcd meme: the best thing about standards is there is always N+1 (the one being your way of doing it versus the others 😆).

The WebRTC Promise

When WebRTC emerged, we’d learnt from SIP and carved out a cleaner path with standardised APIs and a more focused feature set, a WebRTC "profile" if you will. For the past 15 years, this vision seemed to be playing out. WebRTC powered the explosion of video calling applications. Modern contact centres powered by WebRTC emerged, mainly waiting for legacy devices to be obsoleted and contact centre operators moving away from CAPEX (buy telephony hardware) to OPEX (buy seats on a CCaaS, CPaaS, or XCaaS).

SIP retreating to the edges—still there for legacy integrations where modern systems needed to connect with traditional telephony infrastructure, but surely fading away as those systems modernised.

The Voice AI Revolution

Voice AI is emerging and changing everything.

Contact centres are embracing voice bots at an unprecedented pace. These AI agents are replacing humans in numerous workflows—from basic customer service queries to complex multi-stage workflows. But here’s the catch: these bots can only communicate with customers through existing telephony infrastructure. And what powers that infrastructure? SIP.

Suddenly, SIP is essential. Every voice AI company building for the enterprise market needs SIP. The protocol we thought we’d deprecated has become the gateway to one of the most exciting areas of AI development.

Most production voice bots still run a three‑stage pipeline—streaming automatic‑speech‑recognition, an LLM for response, and text‑to‑speech for reply—which adds roughly 300 ms of latency without the VAD and networking delay. Emerging speech‑to‑speech models preserve speaker prosody, but they hide the intermediate text, making debugging and compliance logging trickier. Either way, low‑latency hand‑off to the PSTN depends on SIP-routing behaving itself.

This resurrection brings all of SIP’s historical baggage back to the forefront. We’ve grown used to Opus codec delivering crystal-clear 44.1 kHz audio with built-in error resilience. Now we’re back to G.711’s 8 kHz sampling rate—audio quality that grates the modern ear. Although wide‑band codecs such as G.722 and even Opus wrapped in RTP are widely implemented on modern SBCs, patchy carrier support often forces negotiations back down to G.711, keeping audio quality firmly in narrow‑band territory.
When a bot’s 16 kHz or 24 kHz synth is transcoded down to 8 kHz G.711, some of the intelligibility and emotion vanish, which is why landing even on G.722 can feel like night and day.

Encryption—or its absence—rarely features in PSTN conversations, yet WebRTC pipelines refuse null ciphers. As a WebRTC developer working with legacy SIP and the PSTN, you must accommodate three modes: plain RTP for PSTN, SDES‑encrypted RTP for legacy SIP, and DTLS‑SRTP for WebRTC. SRTP is defined for SIP, but carrier hops almost never preserve it end‑to‑end, so voice bots usually land in plain-voice. SIP over TLS (SIPS) protects signalling, but the media plane usually falls back to plain-voice.

And then there’s DTMF ("Press 1 for English, 2 for Spanish"). Those three different implementation methods I mentioned? They’re not just academic concerns. Voice bots or the infrastructure between them needs to reliably detect when users press phone keys, whether for authentication, menu navigation, or input capture (think "Enter you social security number"). Missing or misinterpreting a DTMF tone isn’t just a bug—it’s a failed customer interaction. So, as Voice AI infrastructure, or as a CPaaS and CCaaS vendors, we need to support all methods.

These quirks multiply quickly. Early media behaviour varies wildly between carriers. Some send audio before the call officially connects; others don’t. Some honour specific headers; others ignore them. Testing becomes a nightmare of edge cases and carrier-specific workarounds.

Old Challenges, Novel Solutions: AMD

Interestingly, the Voice AI era has introduced problems that traditional telephony never properly solved. Voicemail detection stands out as particularly thorny. When a voice bot makes an outbound call, it needs to determine whether it’s reached a human or a voicemail system. Current Answering Machine Detection (AMD) systems from CPaaS vendors are notoriously unreliable. But here’s where things get interesting: LLMs might actually be quite good at this. Instead of relying on simplistic audio analysis, an LLM can understand context and content. Is the voice saying "Hello?" or "Hi, you’ve reached John’s voicemail"? For an LLM, that’s a straightforward classification problem. I suspect we’ll see voicemail detection become a solved problem through better prompting leaning into LLM’s probabilistic nature rather than a deterministic AMD algorithm. It’s an elegant example of how AI can easily solve a technical complex problem of the past.

The Path Forward

As much as I might sigh about SIP’s return, I’m optimistic about where this leads. Yes, we’ll need to retrain a generation of engineers on protocols they never expected to learn. Outbound traffic must also satisfy STIR/SHAKEN caller‑ID attestation; unsigned AI calls risk displaying “Spam Likely” on modern handsets. Yes, we’ll spend countless hours debugging carrier-specific behaviours and codec negotiations.

But the end result—voice bots that actually work—will transform customer experiences. Today’s IVR trees are universally despised. They trap customers in rigid menu structures, forcing them to navigate byzantine option trees just to reach a human. Voice AI promises natural conversations that understand intent and resolve issues efficiently.

The irony isn’t lost on me. We’re using cutting-edge AI technology built on top of a protocol designed when dial-up modems were cutting-edge. But perhaps that’s the nature of real technological progress—not always replacing the old, but finding new ways to make it valuable again.

SIP is back. Time to dust off those RFCs.