If you’ve looked at a cloud phone system for your business, you’ve probably run into the term WebRTC without much explanation of what it actually is. It shows up in feature lists next to things like “no software install” and “call from any browser,” and then the explanation stops there.
That’s fine if you just want to make calls. It’s not fine if you’re the person responsible for deciding whether this technology will hold up on your office Wi-Fi, your employees’ home networks, and your company VPN, or if you want to understand what “encrypted by default” actually means for a system that’s about to carry every customer call your business makes.
This guide explains the mechanism itself: what WebRTC is, how a call actually gets from one browser to another (or to a real phone number), what’s encrypted and what isn’t, and what tends to go wrong in real offices rather than in vendor demos. It’s written for the person evaluating or running a phone system, not for a developer building one, though the underlying facts are the same either way.
How WebRTC Works: What is it?
WebRTC (Web Real-Time Communication) is a set of open technical standards that lets web browsers and other WebRTC-compatible endpoints send and receive live audio, video, and data in real time. In a compatible web browser, it can do this without a plugin, a downloaded app, or dedicated hardware. Depending on the connection, that traffic may travel directly between endpoints or through TURN relays, media servers, or other provider infrastructure. It’s standardized jointly by the W3C, which governs the browser-side API, and the IETF, which governs the underlying network protocols.
Before WebRTC existed, browser-based calling meant Flash, Java applets, or a proprietary plugin, all of which required installation, all of which had their own security patch cycles, and none of which worked consistently across browsers. Google open-sourced the early version of WebRTC around 2011 and helped push it through standardization over the following decade. As of today, every major browser (Chrome, Firefox, Safari, and Edge) ships WebRTC natively. That universality is precisely why a browser-based phone works the same way whether your employee is on a Mac at home, a Windows laptop in the office, or a Chromebook in a hotel lobby: the underlying mechanism doesn’t change per device.
However, it’s worth being precise about what WebRTC is not.
It is not a phone system. It doesn’t know what a business phone number is, doesn’t route calls to the right department, doesn’t handle voicemail, and has no built-in concept of a queue or an extension. WebRTC solves exactly one problem: getting audio, video, or data from one point to another, reliably and securely, over an internet connection that was never designed to make that easy. Everything that makes a browser phone feel like a phone system, the number, the routing rules, the call history, is built by the platform provider on top of WebRTC, not by WebRTC itself.
For a broader look at how phone numbers, lines, and call routing work together, see: What is a Cloud PBX?
The 3 Jobs WebRTC Has to Do
Every WebRTC call, no matter how simple it looks on screen, solves three separate technical problems in sequence. Signaling is required to establish the call, but WebRTC itself does not define how signaling works. The application or phone service implements it.
Introduction (signaling):
Two devices that have never spoken before need a way to exchange basic information about each other, including what audio/video formats they support and how they might be reached on the network.
Pathfinding (connectivity):
Once introduced, the two devices need to find an actual working route across the internet between them, which is harder than it sounds because of how home and office networks are built.
Secure delivery (media transport):
Once a route exists, the actual audio and video need to travel across it encrypted, in real time, adjusting automatically if the network gets congested partway through the call.
If employees currently use their personal mobile numbers for customer calls, it’s also worth reviewing the risks of using personal phone numbers for business before choosing a PC softphone.
Job 1: How Do Two Browsers Introduce Themselves to Each Other?
A signaling channel is how two browsers exchange the setup information a call needs before any audio ever flows: what codecs each side can use, whether video is involved, and the technical details ICE will need in the next step.
Here’s the detail that surprises most people: WebRTC itself does not define how signaling works. The standard leaves it entirely up to the application. In practice, this is the part of the system a phone provider actually builds and controls. Both browsers connect to the provider’s signaling service to swap setup information, and that service may remain involved after the call connects for functions such as hold, transfer, renegotiation, connection recovery, or hang-up.
This matters more than it sounds like it should, because the provider’s signaling and call-control layer is also where the “phone system” part of a phone system lives. It’s what decides that a call to your main business number should ring the sales team’s browser phones in a specific order, or fall to voicemail after four rings, or route differently outside business hours. None of that is WebRTC. All of it sits in the layer a provider builds around WebRTC.
To better understand the technology behind PC softphones, it also helps to understand the difference between a traditional PBX and a cloud PBX.
Job 2: How Does a Browser Call Find a Path Through Two Different Networks?
ICE (Interactive Connectivity Establishment) is the process WebRTC uses to find a working network route between two devices that can’t see each other directly. It’s the part of the mechanism that explains most real-world call problems, so it’s worth understanding even at a non-technical level.
Almost every device on a business or home network sits behind a router doing something called NAT (Network Address Translation), which is why your laptop has a private address like 192.168.1.14 that means nothing outside your own network. Two browsers on two different networks, each only aware of their own private address, have no direct way to find each other. There’s no dial tone equivalent that just works.
Each browser gathers a set of possible ways it might be reachable and tests the available candidate pairs in priority order:
Direct local connection:
Works when the endpoints can reach each other directly using host candidates. This commonly happens on the same local network, but can also happen across networks when publicly routable addresses are available.
STUN-assisted connection (Session Traversal Utilities for NAT):
A lightweight server briefly tells each browser what its address looks like from outside its own router, letting many home and office NAT setups establish a direct connection anyway. Whether this works depends on the NAT type, firewall rules, VPN configuration, mobile carrier network, and other environmental factors.
TURN-relayed connection (Traversal Using Relays around NAT):
The fallback for the networks STUN can’t solve, such as strict corporate firewalls, certain mobile carrier networks, and “symmetric” NAT setups common in larger enterprises. A TURN server sits in the middle and relays every packet of the call between the two sides. It is an important fallback, but it can still fail if the network blocks the available TURN transports, authentication fails, or the provider doesn’t have enough capacity. It also isn’t free in either sense of the word: it adds latency, and it consumes real bandwidth on the provider’s infrastructure for the full duration of every relayed call, not just the setup.
This is the single most important operational fact about WebRTC calling for anyone choosing a provider: if a provider doesn’t run TURN infrastructure, or runs too little of it, calls from certain office networks may not connect at all. Not degraded, not choppy, simply unable to establish. It’s also why “it worked fine in the demo” doesn’t guarantee it’ll work from your specific office; the demo may have been run on a network permissive enough that STUN alone was sufficient.
Once ICE finds a working path, that path is what carries the actual call. How long this takes depends on candidate gathering, firewall behaviour, TURN use, authentication, and general network conditions.
Job 3: What Does "Encrypted by Default" Actually Mean in WebRTC?
Encryption in WebRTC isn’t a setting anyone turns on. It’s mandatory for every media stream, with no unencrypted mode to fall back to. The IETF’s WebRTC Security Architecture (RFC 8827) requires it outright, which is a stronger baseline than a lot of older telephony technology, where encryption is often an add-on rather than the default.
Once a path exists, the call needs to travel across it without being readable by an ordinary network observer, including the office network, the ISP, or a TURN server that is only relaying the encrypted packets.
In practical terms, two mechanisms do the work:
- DTLS, a real-time variant of the same encryption technology (TLS) that secures a bank’s website, runs a handshake directly between the two WebRTC endpoints to establish session keys, without needing the signaling server to broker that exchange. Each side also confirms a certificate fingerprint exchanged earlier, which helps stop someone sitting in the network path from quietly substituting themselves for the intended recipient. However, because the fingerprint itself is exchanged through signaling, the security and authentication of the signaling service still matter.
- SRTP then uses those keys to encrypt the actual voice and video packets for the rest of the call.
One nuance worth being precise about, especially for anyone thinking about this from a compliance angle: WebRTC encryption protects the call in transit across the WebRTC leg, between the endpoints of that connection. If the WebRTC connection terminates at the provider’s cloud PBX, recording system, SFU, media server, or telephone gateway, that infrastructure may decrypt, process, record, or transcode the media. A call to a normal phone number is not necessarily end-to-end encrypted all the way to the recipient’s telephone.
WebRTC also says nothing about what happens to a call recording once it’s saved, or how long a provider retains call metadata, or where their servers are physically located. Those are provider-level decisions, not WebRTC-level ones, and they’re the right questions to ask separately if data residency or regulations like GDPR matter to your business. WebRTC being “mandatorily encrypted” is a good baseline, not a complete compliance answer on its own.
Audio and video themselves usually travel as RTP protected by SRTP over a network protocol called UDP, though TURN can carry the traffic over TCP or TLS when UDP is blocked. This is a deliberate trade-off: on a live call, a packet that arrives late can be worse than one that’s simply skipped, since by the time a resent packet shows up, the moment of audio it belonged to may already have passed.
UDP itself doesn’t automatically retransmit lost packets, although WebRTC can request retransmission at the RTP level when the packet may still arrive in time, particularly for video. Audio will often play through a small gap or use packet-loss concealment rather than wait too long for missing data. Running alongside it, RTCP continuously reports packet loss, jitter, delay, and other network conditions back and forth, which is how a call can lower video quality or audio bitrate when someone’s connection degrades mid-call, rather than simply dropping.
What gets encoded: the codecs, briefly
Both sides negotiate which audio and video format to use automatically, during the same setup exchange that handles signaling, so no user ever sees this happen.
For audio, Opus is mandatory to implement in WebRTC, alongside G.711, and scales cleanly from basic voice quality up to high-quality audio depending on available bandwidth. That flexibility is a large part of why WebRTC calls tend to degrade gracefully rather than cutting out entirely.
For video, the landscape is a bit more fragmented: WebRTC video endpoints are required to support both VP8 and H.264 Constrained Baseline. H.264 has strong hardware support on phones and integrates easily with a lot of older telephony and video equipment, while newer codecs like VP9 and AV1 compress more efficiently but demand more processing power and aren’t supported equally across every browser and device. That’s one reason call quality can vary between an older laptop and a current one even on identical connections.
If employees are handling customer calls across multiple locations, it is also worth considering how an IVR system can route incoming calls more efficiently before deciding how PC softphones should fit into your phone setup.
How Does a Browser Call Reach a Real Phone Number?
A gateway is the piece of infrastructure that translates between WebRTC on one side and the traditional telephone network on the other, often using SIP or SIP trunks connected to the public phone network. This is the piece most WebRTC explainers skip, and it’s the part that actually matters for a business phone system: WebRTC on its own only connects WebRTC-compatible endpoints, applications, or servers. It has no way to reach an actual landline, a mobile phone, or another traditional telephone endpoint without a gateway into the phone network.
From the browser’s perspective, a browser-based softphone is just speaking WebRTC to the provider’s platform. From the platform’s perspective, it takes that call and re-originates it onto standard telephony infrastructure to actually reach the outside number. The employee never sees this translation happen. It’s the layer of engineering that makes “call any phone number from your browser” possible in the first place, and it’s a meaningfully different piece of infrastructure than the browser-to-browser mechanism described above.
This is also why voice quality and reliability on outbound calls depend on more than just WebRTC working correctly. The gateway itself, and the telephony carrier relationships behind it, matter just as much once a call leaves the browser.
Beyond Voice: Data Channels
WebRTC also includes a lesser-known piece called the data channel, which lets two connected WebRTC endpoints exchange arbitrary data, not just audio and video, over the same underlying connection and with mandatory encryption.
Depending on the route ICE selects, that data may travel directly between the endpoints or through a TURN relay.
In a business calling context, this is typically what powers in-call chat, file sharing during a video call, or application-specific control data. Screen-share video itself is normally sent as a media track, although the data channel may carry screen-share controls or metadata.
More Than 2 People: How Group Calls Work
Two endpoints connecting directly to each other, as described above, works well for one-to-one calls. It stops working efficiently once you add more participants, because a true peer-to-peer mesh would require every participant’s device to separately encode and send a full audio/video stream to every other participant. A three-person call would create six directional media flows, and it only gets worse from there.
For anything beyond a handful of participants, the architecture shifts to a media server, most commonly something called an SFU (Selective Forwarding Unit). Each participant sends one or more streams up to the server, and the server forwards the appropriate streams back down to everyone else, rather than every device talking to every other device directly.
This is invisible to the end user. A group call still just looks like a group call, but it’s a materially different piece of infrastructure from a simple two-person call. It’s worth knowing that “WebRTC” alone doesn’t guarantee a provider has built this well; a provider that only handles one-to-one connections cleanly may still struggle with a five-person conference call.
Want to Learn More About Browser-Based Calling?
What This Means for Choosing a Provider
None of this needs to be knowledge you carry day-to-day once a system is running well. But the mechanism explains almost every question worth asking a vendor before signing a contract:
Ask about TURN infrastructure specifically.
“We support WebRTC” says nothing about whether calls will connect from a locked-down office network. Ask what happens on a strict corporate firewall.
Ask what happens when a browser tab is closed or the browser is running in the background.
Closing the page ends the connection it contains, while incoming-call behaviour in the background depends on the browser, operating system, and provider implementation. Providers may use push notifications or companion apps, but this is not something WebRTC solves on its own, so it’s worth confirming directly.
Separate "encrypted" from "compliant."
Mandatory encryption in transit is a genuinely strong baseline, but recording storage, retention policy, and data residency are provider decisions, not protocol guarantees. Ask about those separately if compliance is a factor for your business.
Ask how group calls are handled.
Not just one-to-one calls, especially if your team uses conference calling regularly.
Ask about the carrier relationships behind the SIP trunking that bridges calls to real phone numbers.
This is part of the system that affects outbound call reliability once a call leaves the browser, and it’s easy for a vendor demo to gloss over.
Test on your actual network before rollout.
Don’t just test it in the vendor’s demo environment. Home Wi-Fi, your VPN, and your office firewall are the conditions that matter, and a clean demo on the vendor’s own connection doesn’t tell you much about any of them.
For more on CIRCLE’s approach to infrastructure and security, see: Why Choose CIRCLE?
Bandwidth, In Concrete Terms
For IT teams planning capacity, WebRTC voice calls are lighter than most people expect. A single call often uses somewhere in the range of several tens of kbps to around 100 kbps per direction for audio alone, depending on the codec, bitrate, packet interval, network overhead, and whether TURN is being used.
Even a modest office connection can normally support multiple voice calls, although capacity planning needs to account for both upload and download traffic and the number of simultaneous calls.
Video calls are heavier and more variable, generally landing somewhere between 500 kbps and a few Mbps per participant depending on resolution, frame rate, network conditions, and the codec negotiated.
In practice, the bottleneck for call quality is often not raw bandwidth on a modern connection. It’s stability: packet loss, jitter, latency, and congestion on a shared VPN link can cause more dropped or garbled calls than insufficient bandwidth does. However, bandwidth can still become a real problem when many calls share the same connection or upload capacity is limited.
Where WebRTC Breaks in Practice
Most real WebRTC problems trace back to one of the layers above, not to the browser itself:
- No TURN fallback, or under-provisioned TURN capacity: calls may fail outright for users on strict networks, with no graceful degradation.
- Signaling server issues: nothing connects, even though the underlying network path would have worked fine, because the two endpoints never finished exchanging setup information.
- Browser tab closed or backgrounded: closing the page ends an active connection, while receiving new calls in the background depends on whether the provider has built a notification or companion-app workaround.
- VPN or symmetric NAT routing: can make TURN use more likely, adding latency and cost that scales with how many people are calling at once. Some network policies may also block the available TURN transports completely.
None of this necessarily shows up in a vendor’s own demo, which may be run on a clean, permissive office connection with TURN properly provisioned. It shows up during actual rollout: on home Wi-Fi, through a VPN, with a Bluetooth headset nobody tested against. A pilot worth running deliberately recreates those conditions rather than trusting the demo.
Want to Know If WebRTC Will Work in Your Environment?
How WebRTC Works: Quick Glossary
| Term | Description |
|---|---|
| SDP | the format used to describe the media capabilities and session parameters proposed by a WebRTC endpoint, including codecs and media types. |
| ICE | the process of gathering and testing available network candidate pairs between two endpoints and selecting one that works. |
| STUN | a protocol that helps an endpoint discover how its address and port appear outside its local network, allowing many connections to be established without a relay. |
| TURN | a fallback relay server used when a direct connection can't be established. |
| DTLS-SRTP | the mandatory encryption WebRTC applies to every audio/video stream. |
| SFU | the media server architecture used to scale a call beyond a couple of participants. |
| Gateway | the infrastructure that translates between WebRTC and the traditional telephone network, letting a browser call an actual phone number. |
FAQs About How WebRTC Works
Does WebRTC need any software installed?
No. It’s built into Chrome, Firefox, Safari, and Edge. Some providers add a companion app for background call notifications, but that’s a convenience layer, not a WebRTC requirement.
Can a WebRTC call reach a normal phone number?
Only through a gateway or other interconnection infrastructure that the provider operates, bridging WebRTC to the standard telephone network. WebRTC alone only connects WebRTC-compatible endpoints, applications, and servers.
Is a WebRTC call always encrypted?
The WebRTC media leg is always encrypted, with no unencrypted fallback mode. However, that encryption only covers the WebRTC connection. If the call terminates at a cloud PBX, recorder, media server, or telephone gateway, the provider may decrypt and process the media there. It also doesn’t determine how a provider stores recordings afterward.
Why do calls sometimes fail to connect on office Wi-Fi but work fine at home?
The office network’s firewall, proxy, VPN, DNS settings, or security policy may block direct ICE connectivity or access to the provider’s TURN infrastructure. Insufficient TURN capacity is one possible cause, but the network may also be blocking the transports or ports that TURN needs.
Does call quality depend more on the codec or the network?
Usually the network, although device performance and the provider’s infrastructure matter too. Codecs like Opus adjust automatically to compensate for a weaker connection, but a congested VPN, unstable Wi-Fi, high latency, or sustained packet loss will degrade a call regardless of which codec was negotiated.
WebRTC: The Bottom Line
A WebRTC call uses signaling provided by the application or phone service to introduce the endpoints, ICE to find a working path between them, and WebRTC to move audio and video across that connection encrypted.
Everything that makes it feel like a business phone system, the number, the routing, the voicemail, the connection to real phone numbers, is built by the provider on top of it. Understanding that split is what makes vendor claims easy to evaluate: ask what’s actually WebRTC and what’s the platform underneath it.
