Most articles frame this as a choice. It isn’t. WebRTC and SIP operate at different layers of the same AI voice stack — and most production deployments use both. Here’s what each protocol actually does, where it fits, and how to connect them.
What is WebRTC and what is SIP?
WebRTC (Web Real-Time Communication) is a browser-native protocol suite for real-time audio, video, and data streaming between internet-connected devices — no PSTN access, no phone numbers, no plugins required.
SIP (Session Initiation Protocol) is the signalling protocol used by the telephone network to set up and manage voice calls, and the technology through which AI agents connect to real phone numbers via a carrier’s SIP trunk.
What WebRTC actually is (and isn’t)
WebRTC is a collection of APIs and protocols baked into every modern browser that enables real-time peer-to-peer audio, video, and data streaming. Its defining characteristic is that it requires no plugins, no installs, and no additional software on the caller’s side — a web page can start capturing and transmitting audio the moment it loads.
For AI voice applications, WebRTC’s value is in the browser. If your AI agent talks to customers through a web widget, a React Native app, or a browser-based softphone, WebRTC is the transport layer carrying audio from the customer’s device to your AI pipeline in real time.
What WebRTC cannot do natively: call a regular phone number. WebRTC has no access to the PSTN. A customer on a mobile phone dialling your number is not on WebRTC — they’re on the telephone network. Reaching them requires SIP.
What SIP actually is (and isn’t)
SIP is a signalling protocol — it’s responsible for setting up, managing, and tearing down calls on the telephone network. When someone dials a business phone number, SIP is what routes that call from their carrier to your phone system. When your AI agent dials a lead, SIP is what instructs the network to make that call happen.
SIP does not move audio by itself. The actual voice data travels separately over RTP (Real-time Transport Protocol). SIP handles the call control layer — who called who, when to answer, what codec to use, when to hang up — while RTP carries the voice.
To use SIP for inbound or outbound calling, you need a SIP trunk from a carrier. The carrier provides the connection between your system and the PSTN, along with phone numbers (DIDs) that callers can dial.
WebRTC vs SIP — the comparison table
| Dimension | WebRTC | SIP |
|---|---|---|
| Can call a real phone number | No — internet only | Yes — PSTN access |
| Works in a browser | Natively | Needs a SIP client or gateway |
| Requires a carrier/SIP trunk | No carrier needed | Carrier required |
| Full call control (transfer, forward) | Limited | Full SIP call control |
| Media latency (well-configured) | Very low — peer-to-peer | Low — sub-50ms PoP-colocated |
| Audio codec for AI voice | Opus (transcoding needed for PSTN) | G.711 — no transcoding |
| Outbound AI dialling campaigns | Not supported | Elastic SIP channels |
| Inbound calls from mobile phones | PSTN callers not reachable | Any caller, any network |
| Warm transfer to human agent | Complex without SIP | SIP REFER / attended transfer |
| Best for | Web/app-based AI voice chat | Phone calls — inbound and outbound |
Why most production AI voice stacks use both
Here’s what the comparison table obscures: in most real AI voice deployments, WebRTC and SIP are operating at the same time, at different layers.
Take a typical architecture: a caller dials a business number from their mobile phone. The call hits the carrier’s SIP trunk. The carrier delivers it as a SIP INVITE to a media gateway. The media gateway converts the SIP/RTP audio into a WebSocket or WebRTC stream and hands it to the AI platform. The AI platform uses WebRTC internally to carry audio between the telephony bridge and the AI pipeline (STT → LLM → TTS). The synthesised audio travels back the same way — out through the gateway, over SIP, and back to the caller’s phone.
SIP is at the PSTN edge. WebRTC is inside the platform. The caller experiences neither directly — they just hear the AI agent on a phone call.
The call flow: Caller (mobile/landline) → PSTN → IDT Express SIP Trunk → SIP/RTP → Media Gateway (FreeSWITCH) → WebRTC/WebSocket → AI Platform (Pipecat/Vapi) → API → AI Pipeline (STT → LLM → TTS)
The SIP layer is what gives the AI agent access to the telephone network. The WebRTC layer is what enables low-latency real-time audio processing inside the platform. Remove the SIP layer and your agent is unreachable by phone. Remove the WebRTC layer and your real-time audio pipeline has no transport.
Where the major AI voice platforms sit
Looking at the platforms builders are actually using clarifies the picture further. None of them are purely WebRTC or purely SIP.
| Platform | Internal Transport | PSTN Connectivity | Summary |
|---|---|---|---|
| Pipecat | WebRTC via Daily | SIP trunk (IDT Express, Daily PSTN) | Both |
| Vapi | WebRTC | SIP trunk (bundled or BYOC) | Both |
| Retell AI | WebRTC | SIP trunk (bundled or BYOC) | Both |
| Bland AI | WebRTC | SIP trunk (bundled or BYOC) | Both |
| LiveKit | WebRTC | SIP trunk (LiveKit SIP module) | Both |
| Custom WebRTC app | WebRTC | None (browser-only) | WebRTC only |
| Custom SIP stack | SIP / RTP | SIP trunk (direct) | SIP only |
Every major AI calling platform — Pipecat, Vapi, Retell, Bland, LiveKit — uses WebRTC for internal real-time audio and SIP trunking for PSTN access. The two protocols are complementary, not competitive.
The one scenario where you actually have to choose
There is one genuine fork in the road: where do callers reach your AI agent from?
If your only use case is a web or app chat widget — callers initiate conversations from a browser or mobile app, never dial a phone number — then you can build entirely on WebRTC and you don’t need SIP trunking. Your AI agent lives in the browser context and never needs PSTN access.
If any of your callers dial a phone number to reach your agent — inbound support line, outbound sales calls, appointment reminders, anything involving a phone — you need SIP. WebRTC alone cannot serve those callers.
Use WebRTC only when:
- AI voice widget embedded in your website
- In-app voice assistant (mobile app)
- Browser-based call centre (agents on web)
- No inbound phone number required
- No outbound dialling to mobile/landlines
Use SIP when:
- Inbound calls to a business phone number
- Outbound AI dialling campaigns
- IVR replacement on an existing DID
- Warm transfer to human agents
- AI agents with local numbers in 160+ countries
Use both (most production deployments):
- AI agent answers an inbound phone number and uses WebRTC internally for audio transport to the AI pipeline
- Outbound AI dialling via SIP with WebRTC handling real-time media between the gateway and the LLM
- Contact centre AI with warm transfers — SIP for call control, WebRTC for agent audio
- Any Pipecat, Vapi, Retell, Bland, or LiveKit deployment with PSTN requirements
The codec issue nobody talks about
WebRTC’s default codec is Opus — a variable-bitrate, wide-band codec optimised for internet conditions. The PSTN’s standard codec is G.711 — an uncompressed, fixed-bitrate codec optimised for low latency.
When a call crosses the WebRTC-to-SIP boundary, a codec conversion happens. Opus audio gets decoded and re-encoded as G.711 (or vice versa). That transcoding step adds 5–20ms of latency per leg — which matters in an AI voice call where you’re already spending 200–500ms on STT and LLM inference.
The way to minimise this: configure your media gateway to negotiate G.711 on both sides where possible. On the IDT Express SIP trunk side, G.711 is native — no transcoding at the carrier level. On the WebRTC side, G.711 can be negotiated through the gateway’s SDP handling. The fewer codec conversions in the path, the lower your floor latency.
Practical rule: If your AI voice call goes through more than one codec conversion between the caller’s phone and your STT model, audit your media path. Each unnecessary conversion adds latency you can’t recover elsewhere in the pipeline.
Setting up SIP trunking for your AI voice stack
If your architecture needs PSTN access — which it does if any callers dial a phone number — you need a SIP trunk from a carrier. The carrier provides the connection to the telephone network and the phone numbers (DIDs) your AI agent answers or calls from.
For AI voice deployments, the carrier requirements are specific: G.711 native passthrough (no transcoding at the carrier level), elastic concurrent channels (AI campaigns ramp fast), per-second billing (AI calls average 90–180 seconds — per-minute billing wastes 15–30%), and global DID availability if you’re deploying agents across markets.
IDT Express provides carrier-grade SIP trunking built for this use case — wholesale rates, G.711 native, elastic channels, 160+ countries for DID provisioning, and BYOC compatibility with Vapi, Retell, Bland, Pipecat, LiveKit, and custom stacks.
The short version
WebRTC moves real-time audio between browsers and AI platforms. SIP connects AI platforms to the telephone network. They’re not competitors — they’re adjacent layers of the same voice stack.
If your AI voice agent ever needs to answer or make a phone call, you need both: WebRTC for the real-time audio transport inside your platform, and a SIP trunk from a carrier for the PSTN edge. Every major AI calling platform — Pipecat, Vapi, Retell, Bland, LiveKit — is already built this way.
The only question is which carrier you bring to the SIP layer. That’s where the cost, latency, and coverage decisions actually live.
Frequently asked questions
What is the difference between WebRTC and SIP?
WebRTC is a browser-native protocol suite for real-time audio and video streaming between internet-connected devices — no plugins, no PSTN access. SIP is the signalling protocol used by the telephone network to set up and manage voice calls. WebRTC is an internet transport layer; SIP is the telephone network’s call control layer. They operate in different environments and are typically used together in production AI voice systems: WebRTC for real-time audio inside the platform, SIP at the PSTN edge for telephone connectivity.
Can WebRTC be used to make phone calls to regular phone numbers?
Not directly. WebRTC connects browsers and apps to each other over the internet but has no native PSTN access. To make or receive calls to regular phone numbers using WebRTC, you need a WebRTC-to-SIP gateway that bridges the internet protocol to the telephone network, plus a SIP trunk from a carrier. Twilio, Daily, and similar platforms provide this bridge as a managed service. In self-hosted AI voice deployments, FreeSWITCH or Asterisk typically serve as the gateway between the WebRTC audio stream and the carrier SIP trunk.
Do AI voice agents use WebRTC or SIP?
Most production AI voice agents use both. WebRTC is commonly used for real-time audio transport within the AI platform — between the caller’s browser or app and the AI pipeline. SIP is used at the PSTN edge to connect the AI agent to real phone numbers via a carrier SIP trunk. Platforms like Pipecat use Daily’s WebRTC infrastructure for real-time audio and SIP trunking (via IDT Express or another carrier) for PSTN access. Vapi, Retell, and Bland all follow the same pattern: WebRTC internally, SIP externally for telephone connectivity.
What is a WebRTC to SIP gateway?
A WebRTC-to-SIP gateway is a server-side component that translates between the WebRTC protocol (used by browsers and AI platforms) and SIP (used by the telephone network). It handles codec negotiation, NAT traversal, and protocol translation between the two environments. When an AI agent receives a call from the PSTN, the gateway converts the incoming SIP/RTP audio into a WebRTC stream for the AI platform to process. Common implementations include FreeSWITCH with WebRTC support, Kamailio, and cloud services like Daily PSTN.
Which is better for AI voice bots — WebRTC or SIP?
Neither is universally better — they solve different problems at different layers. WebRTC is better for browser-based or app-based voice interactions. SIP is essential for telephone network connectivity — making and receiving calls to real phone numbers, running outbound AI dialling campaigns, and supporting warm transfers to human agents. For any AI voice deployment requiring PSTN access, the correct answer is both: WebRTC for real-time audio transport inside the platform, SIP trunking at the PSTN edge via a carrier like IDT Express.
Does Pipecat use WebRTC or SIP?
Pipecat supports both. For real-time audio transport, it integrates natively with Daily’s WebRTC infrastructure. For PSTN connectivity, it uses SIP trunking — either via Daily’s PSTN bridge or by connecting a media gateway like FreeSWITCH to an external SIP trunk provider such as IDT Express. In production deployments requiring PSTN access, Pipecat uses WebRTC internally and SIP externally. See the Pipecat + IDT Express integration guide for the full setup.
How do I connect a WebRTC-based AI agent to the phone network?
You need two components: a SIP trunk from a carrier (for PSTN connectivity and phone numbers) and a WebRTC-to-SIP bridge (to translate between your AI platform’s WebRTC stream and the carrier’s SIP/RTP). The bridge can be FreeSWITCH, Asterisk, or a platform service like Daily PSTN. Your AI platform connects to the bridge via WebRTC; the bridge connects to IDT Express via SIP. Inbound calls arrive as SIP INVITEs from IDT Express, are converted to WebRTC audio by the bridge, and delivered to the AI pipeline. Outbound calls are originated through the bridge and terminated by IDT Express over the PSTN.
Ready to connect your AI agent to the phone network? Start free with IDT Express SIP trunking →
