WebRTC (Web Real-Time Communication) is an open standard that enables browsers and mobile apps to exchange audio, video, and data directly with each other over encrypted peer-to-peer connections – no plugin, no proprietary client, just the browser. It has become the foundation for modern unified communications because it makes browser-based calling and conferencing as capable as native applications while eliminating the installation barrier entirely.

The WebRTC stack has three core APIs. getUserMedia captures audio and video from the user’s microphone and camera. RTCPeerConnection manages the peer-to-peer media connection: it handles codec negotiation (VP8, VP9, H.264 for video; Opus for audio), ICE traversal to punch through NATs and firewalls, DTLS-SRTP encryption, and bandwidth adaptation. RTCDataChannel creates bidirectional binary data channels alongside the media streams, enabling file sharing, real-time text, and application-state synchronisation in the same connection. For large-scale conferencing where pure peer-to-peer is impractical, Selective Forwarding Units (SFUs) like mediasoup, Janus, LiveKit, and Jitsi act as media routers that receive streams from each participant and forward them selectively to others – reducing each client’s upload bandwidth from N-1 streams to a single stream. ICTContact and ICTBroadcast, ICT Innovations’ contact centre products, integrate WebRTC to enable agents to take and make calls directly from their browser without installing a softphone, which simplifies deployment and works on any device with a modern browser.

Unified communications platforms built on WebRTC are converging voice, video, screen sharing, messaging, and file transfer into single sessions. The enterprise trend is toward “communications-embedded” applications: rather than switching to a separate meeting tool, users communicate inside their CRM, support platform, or project management tool. This is where WebRTC’s browser-native nature is a genuine competitive advantage – any web application can embed real-time communications with a few hundred lines of JavaScript and a signalling server. The remaining technical challenges are media quality under poor network conditions (packetloss concealment, adaptive bitrate, jitter buffers), scalability for large-group sessions, and E2E encryption for highly regulated industries where even SFU servers should not decrypt media streams.

Frequently Asked Questions

Does WebRTC require a server?

WebRTC uses servers for signalling (exchanging session descriptions and ICE candidates between peers) and usually for STUN/TURN servers to handle NAT traversal. The actual media can flow peer-to-peer for simple two-party calls, but group calls almost always use an SFU or MCU media server to manage routing efficiently. WebRTC is often described as peer-to-peer, but production deployments always involve server infrastructure.

What is the difference between an SFU and an MCU in WebRTC conferencing?

An SFU (Selective Forwarding Unit) receives media streams from each participant and forwards them individually to others without mixing them. Each client receives separate streams and does its own rendering. An MCU (Multipoint Control Unit) mixes all streams into a single composite stream before sending it to each participant, which reduces client processing but increases server CPU cost significantly. SFUs are the dominant architecture in modern conferencing because they scale better and add less latency.

How does WebRTC handle poor network conditions?

WebRTC includes several mechanisms for handling packet loss and congestion: NACK (requesting retransmission of lost packets), FEC (Forward Error Correction, sending redundant data proactively), PLI (requesting a keyframe when video decoding fails), and GCC/REMB (Google Congestion Control algorithms that adapt bitrate to available bandwidth in real time). These mechanisms are built into the browser and SFU implementations and require no application-level code to activate.

Can WebRTC be used for softphone replacement in a contact centre?

Yes – this is one of the most common enterprise WebRTC deployments. A WebRTC softphone runs entirely in the browser, connects to a SIP gateway or SFU, and supports all standard telephony features: hold, transfer, conference, and DTMF. It eliminates the need to install and maintain a standalone softphone application on every agent machine. Platforms like ICTContact and ICTBroadcast use WebRTC exactly this way, giving agents full calling capability directly from their browser-based interface.