If you’ve ever tried building a real-time communications app using raw WebRTC or SIP, you know the challenge: the protocols are powerful, but the tooling is fragmented. You either stitch everything together yourself (painfully), or pay a premium for a bloated CCaaS/UCaaS platform with no room to innovate.
At SignalWire, we think there's a better approach: Programmable Unified Communications (PUC).
PUC gives you the flexibility of raw protocols, but in a fully programmable environment where media, logic, and AI live in the same layer, rather than as bolted on afterthoughts. WebRTC becomes just another addressable resource, and your app becomes the call flow.
That’s the foundation of our platform: Call Fabric. And at our latest LIVEWire event, we showed what happens when you bring WebRTC and AI together in a PUC environment.
Why architecture still matters in 2025
Today’s developers are often stuck choosing between building low-level voice and video systems from scratch, and buying locked-down solutions that hide the call stack and limit flexibility.
Call Fabric (our implementation of the PUC model), a suite of programmable resources. These resources, like Rooms, Subscribers, AI Agents, Phone Numbers, and SIP endpoints are scriptable, composable, and addressable via SignalWire Markup Language (SWML).
If HTTP made the web programmable, PUC does the same for telecom.
Even with great APIs, infrastructure choices still show up where users notice most: latency. When you're working with voice and video, milliseconds matter because they shape the flow of the conversation.
What many platforms don’t tell you is that a lot of latency is self-inflicted, especially in systems that chain together various services, use third-party media relays, or rely on bolted-together infrastructure.
Most legacy CPaaS vendors bounce WebRTC media through multiple hops:
Their TURN/STUN layer
Their signaling layer
Their processing layer
Their bridge layer
Then finally to the destination
Every hop adds 100-200ms and those delays add up fast.
SignalWire avoids all that. Here’s how:
Single-layer media routing
SignalWire runs media through a single-layer router and only anchors media when it’s actually needed (for example, for PSTN bridging, transcription, or recording). If your app allows peer-to-peer media, we’ll route it directly with no anchors.
Geographically distributed edge nodes
We deploy geographically distributed edge nodes to keep both signaling and media paths close to users. If you're embedding WebRTC into a global app, our infrastructure ensures that proximity, not platform logic, determines the route.
Your media doesn't backhaul through a fixed region or shared MCU. It stays near the user.
Built in TURN/STUN (But only when needed)
SignalWire offers built in TURN/STUN services. But unlike other vendors, you don’t have to preconfigure or deploy them yourself. We use them automatically only when peer-to-peer connections can’t be negotiated, avoiding unnecessary relays unless absolutely required.
No middleware bloat
Our signaling server is SignalWire. There’s no third-party middleware, and no extra layer to debug or optimize. Everything from call logic to AI agent invocation is handled inside the platform stack using SWML.
Telephony-grade foundation
SignalWire is built by the creators of FreeSWITCH, the same open-source platform used by telcos for high-throughput VoIP. But instead of giving you raw FreeSWITCH, we abstract it into programmable resources. You get performance and control, without the decades of telecom engineering experience usually required.
WebRTC as part of the stack
WebRTC brings direct, browser-based audio and video to the table, but it’s not a complete solution. It gives you media transport, raw WebRTC lacks all the higher-order features you need to build usable systems:
Call routing
Authentication
PSTN interoperability
AI and bot integration
Signaling
That’s why SignalWire treats WebRTC as a native, programmable resource. When you use our platform, a WebRTC user is just another address in your application’s topology. Call flows become address-based logic: you route calls to user123@yourdomain.signalwire.com, whether it’s a subscriber, AI bot, or live agent.
Demo 1: AI meets Click-to-Call with The LexiCall Librarian
To demonstrate WebRTC use in the SignalWire environment, we brought in Devon White, Developer Experience Specialist. He showed off LexiCall, an AI-powered librarian that can answer questions via Wikipedia or web search.
The experience starts with a click-to-call button in a browser, using WebRTC to connect directly to an AI Agent. Built entirely with SignalWire resources and SWML scripts, LexiCall both responds and adapts by
Using WebRTC as the transport
Using an AI Agent as the conversational layer
Tapping live data via the SignalWire AI Gateway (SWAIG) and Datasphere for real-time lookups
And it can even redirect users at the end of a call to surveys or follow-up pages based on in-call events.
Demo 2: Context-aware transfers from AI to live agent
In the second demo, Devon walked through a multi-phase call flow that highlights how programmable infrastructure handles dynamic, real-world scenarios:
A user calls into an AI receptionist via browser
The AI gathers caller context (such as “not a member? Here’s a signup form”)
Once context is collected, the call transfers to a live agent
The context travels with the call, and the agent sees it before answering
This showcased what programmable infrastructure looks like when done right. Using Subscribers, AI Agents, and SWML, Devon demonstrated WebRTC calls initiated via browser, dynamic context capture, and in-call scripting and routing that resulted in seamless AI-to-human transitions.
You could extend this same pattern for tech support, sales routing, telehealth intake, and more.
AI is native to the telecom stack
What makes this all work is tight integration with SWAIG and Datasphere, our versions of an AI Tool gateway and retrieval system that feeds LLMs real data from your chosen documents.
You can also fetch post-call metadata to get full call visibility: every input, output, function call, and transcription. It’s perfect for debugging or fine-tuning your agents.
LIVEWire Q&A session
As always, the LIVEWire delivered value not just in the demos, but in the live Q&A.
- Can I use my own STT or TTS providers?
Yes, and we offer many quality TTS providers, including Rime and ElevenLabs.
- Can I add whisper tones or menu options before bridging?
Absolutely, with confirm methods in SWML.
- Can I get real-time transcription visible to live agents?
Yes, try the live_transcribe SWML verb!
- Do I have to learn SWML in order to build AI applications on SignalWire?
Learning SWML is no longer necessary. You can control SWML with Python using the new Agents SDK.
TL;DR: WebRTC alone isn’t enough
WebRTC gives you transport, but not infrastructure. With SignalWire, you turn it into part of a larger programmable system where every endpoint is addressable, every behavior is scriptable, and every agent (human or AI) is reachable.
Sign up for a free SignalWire account today to find out what you can build, and join our community of likeminded developers on Discord.
