WebRTC — the open browser standard for real-time audio and video — is used in two different ways across voice AI products: with a phone number attached, and without one. This distinction shapes how the system is built, what journey the user goes through, and what the product is used for. This post walks through what each term means, how the two approaches differ in design, and which use cases each one is suited for.

The Terms

WebRTC is a transport layer, not a product. It's the standard that lets a browser stream audio and video in real time without a plugin — the same technology behind Google Meet and Zoom. On its own, it doesn't involve phone numbers, carriers, or identity; it moves audio between two endpoints.

• Spec: w3.org/TR/webrtc
• Overview: webrtc.org
• Developer reference: MDN WebRTC API

A Web SDK is a developer toolkit built on top of WebRTC, typically embedded on a web page or inside an app to offer a "talk to our AI" experience. Identity here is a session or room ID that exists for as long as the browser tab or app session is open — there's no phone number involved.

SIP (Session Initiation Protocol) is the signaling protocol that sets up, manages, and ends phone calls, whether on a hardware handset or a browser tab. A SIP endpoint registers against a real, callable phone number — a DID (direct inward dialing number).

SIP over WebRTC describes a browser registering as a SIP endpoint tied to a real DID. It uses the same WebRTC transport as a Web SDK, but the identity is a persistent phone number rather than a session ID — functionally, a phone delivered through a browser tab.

Communication Design

Session-based (Web SDK). The browser connects to an AI backend through a signaling server, using WebRTC to stream audio. There's no SIP registration and no DID involved. The identity of the conversation is a session or room ID generated for that interaction, and it ends when the tab or session closes.

Number-based (SIP over WebRTC). The browser registers as a SIP endpoint against a real DID, using the same SIP handshake (INVITE / 200 OK) a hardware phone would use, allowing it to send and receive calls to and from the phone network. The identity is the phone number itself, which persists independent of any single session — it can be reached from a hardware phone, a different browser, or an app at a later time.

User Journey

Session-based (Web SDK): a visitor arrives on a page, clicks to start a conversation, grants mic access in that tab, and has the interaction inline. The session ends when they navigate away or close the tab, and there's no way to reach that same person again unless they return to the same page and start a new session.

Number-based (SIP over WebRTC): a user — a support agent, a driver, an authenticated app user — opens a web app tied to a real number they're reachable at. They can place or receive calls the way they would on an ordinary phone, including to and from the regular phone network (PSTN), and the number remains reachable across sessions, devices, and time.

Use Cases

Session-based / Web SDK:

• Landing-page demos or sales-page voice agents
• Embedded on-site support widgets
• Internal tools where interactions start inside the app

Number-based / SIP over WebRTC:

• Browser-based contact center agents, without hardware phones
• In-app calling that bridges to real numbers — for example, a delivery driver calling a customer from an app
• Interactions that need outbound calling, such as reminders or follow-ups, placed from a browser

Side by Side

Where AI-Native Telephony Sits in This Picture

WebRTC is the shared transport in both approaches described above. What differs is whether a phone number is registered to the session. AI-native telephony infrastructure, like Vobiz, provides the number side of this: a DID that can be registered to a browser over SIP-over-WebRTC, to a hardware SIP phone, or bridged to the regular phone network. Numbers are provisioned in under 10 minutes, span 130+ countries, and run at roughly 80ms latency over SIP trunking.

In practice, the choice between the two approaches comes down to whether the interaction needs a persistent, callable identity or only a session that lasts as long as the tab is open. If it's the former, that's what a registered phone number provides, regardless of whether it ends up in a browser, a hardware phone, or bridged to the regular phone network.

FAQs