Web Real-Time Communication (WebRTC) is an open set of standards and browser programming interfaces that lets web pages and apps capture a microphone and camera, and send live audio, video and data over the internet. It is built into current mainstream browsers and is available as a library for mobile and desktop apps, so users can join a call or talk to a support agent without installing a plugin. The browser interfaces are standardized by the W3C and the underlying protocols by the IETF.
At a glance
- WebRTC lets browsers and apps send live voice, video and data with no plugin.
- It handles media and encryption; call setup (signaling) is left to each product, often using SIP or a custom protocol.
- Media and data are encrypted in transit by default, but servers in the path often decrypt media for group calls, recording or phone-network bridging.
- Call quality still depends on the network: firewalls, latency, jitter and packet loss.
- Many UCaaS, contact center and CPaaS products use it for browser softphones and click-to-call.
What problem it solves
Before WebRTC, live voice or video in a browser meant installing a plugin or a vendor’s client. That was a barrier for customers who just wanted to talk to support, and a headache for IT teams managing desktop software. WebRTC put real-time media into the browser itself.
For businesses this shows up in three places. Agents and employees can use a browser softphone instead of a desk phone. Customers can start a call or video session from a website or app without leaving it. And developers can build voice, video and data features into their own applications, often through a communications platform as a service (CPaaS) provider’s toolkit.
How it works
- Capture and encoding. The browser or app captures audio and video and compresses it with a codec. Opus and G.711 are required for audio in browsers, and VP8 and H.264 for video; many implementations also support newer video codecs.
- Signaling. The two ends need to exchange session details before media can flow. WebRTC deliberately leaves this to the product, which may use SIP over WebSockets, its own API or another protocol.
- Getting through the network. Most devices sit behind firewalls and network address translation (NAT). WebRTC uses ICE to find a working path, STUN to learn public addresses, and TURN relay servers when no direct path works.
- Encryption. Media is sent with SRTP, keyed through DTLS, and data channels run over DTLS as well. Unencrypted media is not allowed by the standard.
- Servers in the middle. Direct peer-to-peer connections work for simple one-to-one calls. Business products usually route media through servers: selective forwarding units for group calls, recording servers, and gateways or session border controllers that connect WebRTC calls to SIP trunks and the public phone network.
Because media often passes through those servers, “encrypted by default” usually means encrypted on each hop, with the provider able to see media where it is mixed, recorded or bridged. Some products add end-to-end encryption for certain call types, often with feature trade-offs.
When it matters for buyers
- Choosing a UCaaS or contact center platform. Ask whether agents can work fully in the browser, and what they lose compared with the desktop app. Browser softphones simplify rollouts but depend on browser updates and device settings. Our contact center as a service page covers what to compare.
- Adding click-to-call or video to your website or app. That usually means a CPaaS toolkit or a contact center vendor’s widget, priced per minute or per session.
- Locked-down networks. Corporate firewalls, web proxies and VPNs can block or degrade WebRTC media. Check the provider’s network requirements and whether TURN relays are near your users.
- Regulated conversations. Healthcare, finance and legal teams need to know where media is decrypted, where recordings are stored and how long they are kept.
- Call quality complaints. WebRTC adapts to poor networks, but it can’t fix them. Wi-Fi congestion, VPN hairpinning and an overloaded laptop are common causes of choppy browser calls.
Questions to ask vendors
- Which browsers and versions are supported, and what features are missing in the browser compared with your desktop app?
- Where are your media servers and TURN relays located, and which ports and protocols must our firewall allow?
- Is media decrypted on your servers, and in which cases (group calls, recording, transcription, phone-network bridging)?
- Do you offer end-to-end encryption, and what features does it disable?
- How do WebRTC calls connect to our phone numbers and SIP trunks?
- What call-quality data (packet loss, jitter, round-trip time per call) can we see, and for how long is it kept?
- How are usage charges calculated for browser or in-app calls, per minute, per session or per participant?
How it differs from SIP
Session Initiation Protocol (SIP) is a signaling protocol: it sets up, changes and ends calls between phones, phone systems and carriers. WebRTC is mainly about media: capturing, encrypting and sending audio, video and data from a browser or app, and it leaves signaling to the product. The two often work together. A browser softphone may use WebRTC for the audio and SIP over WebSockets to set up the call, and a gateway or session border controller connects those calls to SIP trunks and the public phone network. Both are forms of voice over IP (VoIP).