What is browser calling, and how does a website call actually connect?
Browser calling lets website visitors talk to your team with no phone number or app. How WebRTC calls connect, how they are encrypted, and where they fail.
· 7 min read · By the CallCeptor team
A browser call is a voice call that starts and runs inside a web page. The visitor clicks a Call button, the browser asks for the microphone, and a few seconds later they are talking to someone. Nobody dials a number, and nobody installs anything.
That is the whole experience for the visitor. This guide explains what happens underneath, because your IT and compliance teams will ask, and the answers decide whether the call connects for every visitor or only most of them.
The standard underneath: WebRTC
Browser calling is built on WebRTC (Web Real-Time Communication), a standard published by the W3C and the IETF and supported by Chrome, Edge, Firefox and Safari. It gives a web page three things: access to the microphone with the user's permission, a way to send audio to another device with very little delay, and mandatory encryption of that audio.
Because the capability is in the browser itself, there is no plugin, extension or app to install, which is the difference from older "web phone" products.
How one call connects, step by step
- The click. The visitor clicks Call. On CallCeptor, the calling code only downloads at this moment, so the button costs nothing on page load.
- Microphone permission. The browser shows its own prompt. The visitor must allow it; a site cannot switch the microphone on silently.
- Signalling. The visitor's browser and the agent's console exchange a short description of how each can be reached and which audio formats they support. This goes through the calling service over an encrypted web connection.
- Finding a path. Each side tries to reach the other directly. When a firewall or office network blocks that, the audio goes through a relay server (TURN) instead.
- Audio. Once a path is found, the voice flows encrypted with DTLS-SRTP, usually with the Opus codec, which handles weak mobile networks well.
What the visitor needs
- A current browser: Chrome, Edge, Firefox or Safari, on desktop or mobile.
- A microphone, which every phone and nearly every laptop has.
- A normal internet connection. Voice needs far less bandwidth than video.
Where browser calls fail, and what to do about each
| Problem | What helps |
|---|---|
| The visitor blocks the microphone | Explain why before the browser prompt appears, and offer a callback to their phone if they decline. |
| An in-app browser (Instagram, LinkedIn) doesn't allow the microphone | Detect it and offer "call me back" or "open in browser". |
| Office or bank firewall blocks direct connections | A TURN relay over TLS on port 443, which looks like ordinary web traffic. |
| Nobody is at the agent console | Ring the agent's mobile, then book a callback with a deadline. |
Browser calling compared with a phone number
A phone number works well on a mobile phone and poorly on a laptop, where most research and product pages are read. A browser call works on both. It also carries context a phone call can't: the page the visitor was on, the campaign that brought them, and the answers to a short pre-call form. We cover that trade-off in more detail in click-to-call vs phone, WhatsApp and forms.
Security questions to ask any vendor
- Is call audio encrypted end to end between browser and console, or decrypted on a media server?
- Where do relay servers, recordings and call records live? For Indian financial firms, the expected answer is India.
- Who can listen to recordings, and is each playback logged?
- Does the widget load third-party trackers on your pages?
CallCeptor's answers are on the security and compliance page, and the terms used here are defined in the glossary.
Written by the CallCeptor team, who build browser calling and call routing for Indian financial firms. Product details reflect what CallCeptor does today; anything on the roadmap is marked as such. This guide is general information, not legal or regulatory advice. Spotted a mistake? Tell us. See how we write.