WebRTC Contact Centre: Architecture and Trade-Offs

WebRTC brings browser-native voice, video, and data channels to contact centres without plugins. It uses STUN, TURN, ICE, and SDP to punch through firewalls and negotiate media. The architecture decisions centre on latency, codec selection, PSTN integration complexity, and infrastructure cost.

For most contact centre architects, the question is no longer whether to adopt WebRTC. It runs on billions of devices including smartphones and tablets, making it a de facto standard for browser-based communication. The real decisions are architectural: how you handle NAT traversal at scale, which codecs you choose, and how you connect WebRTC sessions to legacy telephony infrastructure. Cost comparisons with traditional SIP trunking depend heavily on TURN relay usage and call mix, so the sections below treat each factor concretely rather than as a blanket verdict.

What Is WebRTC in a Contact Centre Context?

WebRTC is an open standard that lets browsers exchange real-time audio, video, and data directly with each other or with a media server, without requiring any plugin or native app. In a contact centre, that means a customer can start a voice or video session from a web page while an agent handles the call from a browser-based desktop.

The protocol stack covers three main capabilities: media capture (microphone and camera access), peer-to-peer transport (SRTP over ICE/DTLS), and a data channel for arbitrary binary or text payloads. Contact centres use all three. Voice and video carry the conversation. The data channel supports features like file transfer, cobrowsing synchronisation, and real-time transcription feeds.

A customer clicks a link in an email, a chat widget, or an SMS and connects immediately. No app to download, no ActiveX control, no Java applet.

The architecture discussion that follows assumes a typical deployment where a media server or selective forwarding unit (SFU) sits between the customer browser and the agent desktop, rather than a pure peer-to-peer path, because that topology is more practical at contact centre scale.

How Does WebRTC Establish a Call? A Step-by-Step Walkthrough

Setting up a WebRTC session involves three steps: signaling, candidate discovery, and media negotiation. These happen in a defined sequence before any audio or video flows.

1. Initiate the session by generating an SDP offer. The calling browser (or the contact centre’s media server) creates a Session Description Protocol offer. This document describes the media capabilities the caller supports: codecs, bandwidth limits, encryption parameters, and media types. The SDP offer is the starting point for all subsequent negotiation.

2. Identify public IP and port data via STUN and TURN. Before the offer travels anywhere, the browser queries a STUN server to discover its public-facing IP address and port. If the network topology blocks direct access, the browser also requests relay candidates from a TURN server. Both sets of candidates are collected as ICE candidates and attached to the session description.

3. Transmit the offer through a signaling channel. WebRTC does not define a signaling protocol. Contact centre platforms typically use WebSocket connections, SIP over WebSocket, or a proprietary REST/webhook mechanism to carry the SDP offer from the caller to the contact centre platform. The signaling channel is separate from the media path and must be secured with TLS.

4. Exchange ICE candidates and generate an SDP answer. The receiving side, usually the contact centre platform or media server, processes the offer, selects compatible codecs and parameters, and returns an SDP answer. Both sides also exchange their ICE candidate lists through the same signaling channel. This exchange can happen in parallel with the offer/answer process (trickle ICE) to reduce setup latency.

5. Verify valid connection paths. ICE performs connectivity checks by sending STUN binding requests across each candidate pair. Host candidates (local network addresses), server-reflexive candidates (STUN-discovered public addresses), and relay candidates (TURN addresses) are all tested. ICE selects the highest-priority pair that succeeds.

6. Establish the media stream. Once ICE nominates a valid path, DTLS handshakes over that path to establish keying material for SRTP. Audio and video packets then flow as encrypted SRTP streams. For contact centres using a media server, the customer’s media terminates at the server, which then forwards it to the agent desktop in a separate SRTP session.

The full sequence from offer generation to first audio packet typically completes in under two seconds on a well-configured network. TURN relay adds latency to the ICE phase, which is one reason TURN server placement matters for geographically distributed contact centres. Each additional relay hop between the customer browser and the media server adds round-trip time that comes directly out of your 150 ms one-way latency budget.

How Does WebRTC Handle Firewalls and NAT Traversal?

NAT traversal is one of the most operationally significant parts of a WebRTC deployment. Most customers connect from home or office networks that sit behind NAT devices, and many corporate networks apply strict firewall rules that block UDP entirely.

WebRTC uses the ICE framework to work through this. ICE gathers multiple candidate types for each peer: host candidates from the local network interface, server-reflexive candidates discovered by querying a STUN server, and relay candidates allocated from a TURN server. It then tests candidate pairs in priority order and selects the best working path.

For the majority of connections, a STUN server is sufficient. The STUN server tells the browser its public IP and port, and that information is enough for the two peers to punch through symmetric NAT. STUN servers are stateless and cheap to operate at scale.

When STUN fails, which happens on networks with symmetric NAT or strict UDP filtering, the connection falls back to a TURN relay. The TURN server acts as a media relay: both peers send their RTP packets to it, and it forwards them to the other side. This guarantees connectivity, but at a cost. TURN relay traffic passes through your infrastructure, adding bandwidth and compute costs that scale directly with call volume.

WebRTC prefers UDP for media because UDP’s lower overhead produces better latency and jitter characteristics than TCP. When UDP is blocked entirely, ICE can fall back to TCP candidates, and TURN supports a TCP transport mode for exactly this scenario. TCP fallback increases latency and can cause audio quality problems under packet loss, because TCP retransmits lost packets rather than letting the codec handle them with concealment. For contact centres serving enterprise customers behind strict firewalls, planning for TCP fallback paths and testing audio quality over them is a necessary step. A TURN server that is geographically far from either endpoint adds round-trip latency to every media packet, so deploying TURN nodes in the same regions as your customer base keeps that added latency manageable.

What Are the Real Latency and Codec Trade-Offs for Contact Centres?

Codec choice and latency budgets are where WebRTC deployments either hold up under contact centre load or start causing complaints. The two codecs you will encounter most often are Opus and G.711, and they behave very differently under real-world network conditions.

Opus is the default audio codec in WebRTC. It adapts its bitrate dynamically, handles packet loss with built-in forward error correction, and performs well at bitrates as low as 6 kbps. For contact centres where agents handle calls over variable-quality connections, that adaptability matters. Opus also supports wideband and super-wideband audio, which makes speech more intelligible and reduces listener fatigue over long calls.

G.711 is the legacy PSTN codec, operating at a fixed 64 kbps per direction. It produces predictable, high-quality audio on clean networks, and it is the standard codec for SIP trunking and most PBX systems. The practical reason G.711 appears in WebRTC contact centres is interoperability: when a WebRTC session bridges to a PSTN call or a SIP trunk, the media server often transcodes to G.711 at the gateway. That transcoding step adds latency and CPU load, which matters at scale.

Audio-to-video synchronisation matters for any contact centre adding video channels. A 2018 study published at Aalto University found that audio was delayed relative to video by 150 to 320 ms in WebRTC-based video calls. The same research identified 240 ms as the acceptable threshold for audio/video synchronisation in real-time communication. Treat those figures as findings from a specific study rather than universal constants, because network conditions, browser implementations, and media server configurations all affect the actual offset in a given deployment.

For planning purposes, a useful framework is to treat 150 ms one-way audio latency as your operational ceiling for voice quality. Beyond that, agents and customers start talking over each other. TURN relay, transcoding hops, and geographic distance between the customer browser and the media server each consume part of that budget. Mapping your expected call paths against your TURN and media server topology before you deploy will surface the cases where you need to add a regional node or reduce transcoding steps.

Video adds more complexity. Higher resolution streams consume more bandwidth and increase jitter sensitivity. For contact centres using video primarily for identity verification or high-value advisory calls rather than bulk volume, a constrained video profile keeps bandwidth use manageable without requiring dedicated video optimisation hardware.

Integrating WebRTC with Existing PBX, SIP, and PSTN Networks

Most contact centres cannot replace their telephony infrastructure overnight. WebRTC sessions need to reach agents on SIP endpoints, connect to PSTN numbers, and interwork with existing PBX routing logic. The standard approach is a WebRTC-to-SIP gateway, sometimes called a SIP proxy or session border controller (SBC) with WebRTC support.

The gateway terminates the WebRTC session from the customer browser, handles the DTLS-SRTP to SRTP conversion, and presents a standard SIP leg to the rest of the contact centre platform. From the PBX’s perspective, the inbound call looks like any other SIP call. This pattern lets you add WebRTC as a new ingest channel without rewriting dial plans or replacing routing logic.

SIP over WebSocket (RFC 7118) is the signaling mechanism that makes this work cleanly. The customer browser opens a WebSocket connection to the SBC, which speaks SIP over that connection. The SBC then forwards a standard SIP INVITE to the internal platform. This keeps the WebRTC complexity contained at the edge and leaves the core telephony infrastructure unchanged.

PSTN integration follows the same gateway pattern. The SBC bridges WebRTC sessions to SIP trunks that connect to the PSTN. Coverage and reliability depend on your SIP trunk provider, not on WebRTC itself, so the same provider evaluation criteria you would apply to a traditional SIP deployment apply here.

Cloud contact centre platforms have simplified this considerably by building WebRTC support directly into their agent and customer-facing interfaces. Webex Contact Center is one example: it handles voice, digital messaging, and AI-assisted agent guidance natively, with WebRTC embedded in the agent workspace. Agents use a browser rather than a separate softphone, and the platform manages the SIP gateway and PSTN connectivity behind the scenes.

Webex Contact Center exposes APIs and configuration options that let you integrate WebRTC-based voice into existing routing, CRM, and workforce management systems without building the gateway layer yourself.

Does WebRTC Cost Less Than Traditional SIP Trunking?

Often yes for per-minute media costs, but the total picture depends on what you build around it. WebRTC eliminates per-minute PSTN charges for browser-to-browser calls entirely. Browser-to-browser calls generate no carrier charges at all, while SIP trunking typically carries per-minute fees that add up quickly at high volume. That gap narrows as more contacts require a PSTN leg, but for centres with a large share of digital-channel traffic, the difference is real.

The cost shifts to infrastructure. You pay for STUN and TURN server operation, media server capacity, and signaling infrastructure. TURN relay is the largest variable cost because it scales with call volume and average handle time. On networks where most customers connect over home broadband, STUN alone handles the majority of connections and TURN usage stays low. On enterprise networks with strict firewall policies, TURN relay usage climbs, and so does the associated bandwidth bill.

SIP trunking carries its own costs: per-minute charges, DID number fees, and SBC licensing. For outbound-heavy or PSTN-dependent centres, SIP trunking costs can be substantial. WebRTC does not eliminate PSTN costs for calls that must reach or originate from phone numbers; those still traverse a SIP trunk at some point in the path.

The open-source path is worth considering for teams with engineering capacity. Projects available on GitHub, such as Janus, Jitsi, and FreeSWITCH with WebRTC modules, let you self-host the full stack: TURN, media server, signaling, and SIP gateway. Self-hosting removes licensing fees but adds engineering time for deployment, scaling, and ongoing maintenance. For most contact centres, that trade-off favours a managed platform unless specific compliance or data residency requirements rule out cloud options.

For teams that want video and cobrowsing on top of a WebRTC voice channel without building the stack themselves, Auvious adds those capabilities as a layer over existing platforms. The Video CX & Cobrowse Features page covers how video appointments and cobrowsing connect to platforms like Genesys Cloud, NICE, Talkdesk, and others, with agents escalating to video in one click from their existing workspace. The Video Agents Bundle is listed at $45/user/month on Talkdesk AppConnect, with a one-month free trial available.

Security Considerations: Encryption, TLS, and SRTP in WebRTC

WebRTC mandates encryption by design. Every media stream uses DTLS-SRTP, meaning audio and video packets are encrypted before they leave the browser. This is not optional or configurable: the WebRTC specification requires it, so there is no path to an unencrypted media channel.

Signaling is a separate concern. The SDP offer, ICE candidates, and session control messages travel over your signaling channel, not over the WebRTC media path. You must secure that channel with TLS. A WebSocket signaling connection without TLS exposes session metadata and ICE candidates, which gives an attacker enough information to attempt a man-in-the-middle attack on the DTLS handshake.

For contact centres operating under compliance frameworks such as PCI DSS, HIPAA, or GDPR, encryption in transit is necessary but not sufficient. Recording also requires attention: your media server must decrypt SRTP streams to record them, then re-encrypt or store them securely. That decryption point is where most compliance audits focus. Confirm that your media server vendor can document how recording keys are managed and where recorded files are stored.

Data residency is the other pressure point. If your TURN servers or media servers sit in a different jurisdiction from your customers, media packets may cross a border in transit. Mapping your infrastructure topology against your data residency obligations before deployment avoids surprises during a compliance review.

FAQs

Is WebRTC over TCP or UDP?

WebRTC prefers UDP for media because it produces lower latency and handles packet loss more gracefully than TCP. The codec handles lost packets with concealment rather than waiting for a retransmit. When UDP is blocked by a firewall, ICE can fall back to TCP candidates, and TURN supports a TCP transport mode for exactly that scenario. TCP fallback works but typically increases latency and can reduce audio quality under congestion.

How do I talk to customer service on the phone using browser-based calling?

Most browser-based customer service calls work like any other contact: you open a support page, click a call or video button, and your browser requests microphone access. No app or plugin is needed. The contact centre platform handles the WebRTC session on its end. If the button does not appear, check that your browser is up to date and that you have allowed microphone permissions for that site.

What are some popular call centre platforms supporting WebRTC?

Several enterprise platforms embed WebRTC natively in their agent and customer interfaces. Webex Contact Center handles voice, digital messaging, and AI-assisted agent guidance with WebRTC built into the agent workspace. Several other enterprise platforms also embed WebRTC natively in their agent and customer interfaces.

Can WebRTC replace a traditional softphone in a contact centre?

Yes, for most use cases. WebRTC runs directly in the browser, so agents handle calls without installing a separate softphone client. The contact centre platform manages codec negotiation, ICE traversal, and SIP gateway connectivity behind the scenes. The main reason to keep a traditional softphone is compatibility with legacy PBX features or hardware headsets that require a dedicated SIP client, though most modern USB and wireless headsets work with browser-based WebRTC without additional software.

Does WebRTC work on mobile browsers without an app?

WebRTC is supported in Chrome, Safari, Firefox, and Edge on both Android and iOS, so customers can join a voice or video session from a mobile browser without downloading an app. Safari on iOS added WebRTC support in version 11, which covers the vast majority of active iPhone and iPad users. Performance depends on network quality and available bandwidth, particularly for video, but the protocol itself works across all major mobile browsers.

Conclusion

WebRTC gives contact centres browser-native voice, video, and data channels that work without plugins on billions of devices. The architecture decisions that determine whether a deployment succeeds are NAT traversal strategy, codec selection, media server placement, and how you bridge WebRTC sessions to existing SIP and PSTN infrastructure. Security is handled at the protocol level through mandatory DTLS-SRTP, but compliance obligations around recording and data residency require additional planning.

Before committing to a build path, map your expected call topology against your TURN and media server regions to identify where latency or TURN relay costs will be highest. Then decide whether the open-source self-hosted route fits your engineering capacity, or whether a platform that already handles the gateway and media layers makes more sense for your team.