VoIP vs WebRTC sets a family against one of its members. VoIP covers every technique that carries a call over the internet. WebRTC is the standard that lets a browser do it with nothing to install. A call started from Chrome, Edge, Firefox or Safari is a VoIP call, so the useful comparison sits elsewhere: between the browser and the SIP phone on the desk.
This guide explains what the two words cover, then follows one call end to end, from your laptop microphone to the other person’s cell phone. Every technical claim rests on the original W3C and IETF texts, read on November 11, 2026 and cited along the way.
VoIP vs WebRTC: what is the difference?
The difference is a matter of level. VoIP answers “where does the voice travel?”: over a data network, cut into packets, instead of a reserved phone circuit. WebRTC answers a narrower question: “how can a browser send and receive that voice?”
Saying “VoIP or WebRTC” is like saying “vehicle or electric car.” One is a special case of the other. In practice, the person asking is choosing between two ways to equip a team: phones and software that speak SIP, or an app that opens in a tab.
Those three dates place the two worlds. SIP is more than twenty years old and runs most business telephony. WebRTC is younger, but it is no longer experimental: Mozilla’s MDN documentation says its core interface has been available across browsers since September 2017, and the W3C published it as an official standard on January 26, 2021.
- SignalingSIP desk phone or softphoneSIP, standardized (RFC 3261)WebRTC browserOpen: chosen by the application, often SIP over WebSocket
- Audio codecSIP desk phone or softphoneG.711 almost always, others depending on hardwareWebRTC browserOpus and G.711 both mandatory (RFC 7874)
- Voice encryptionSIP desk phone or softphoneOptional: SRTP if the provider turns it onWebRTC browserMandatory: DTLS-SRTP, plain voice forbidden
- Firewall traversalSIP desk phone or softphoneNetwork settings, sometimes a session border controllerWebRTC browserBuilt in: ICE, with STUN and TURN relays
- SetupSIP desk phone or softphoneA handset to plug in or software to deployWebRTC browserNone: a web page and microphone permission
Sources: RFC 3261 (SIP), RFC 7874 (codecs), RFC 8827 (security), RFC 8835 (transports), RFC 8825 (overview).
The table above sums up what really changes from one stack to the other. On encryption, the firewall and setup, the browser requires or builds in what SIP telephony leaves optional. On signaling it is the other way around: SIP is standardized, and WebRTC leaves the choice to each application. That is what a standard looks like when it is written later, with twenty years of IP telephony behind it.
WebRTC does not replace VoIP. It replaces the phone on the desk with a browser tab.
What is VoIP, exactly?
VoIP, short for Voice over IP, carries voice as data packets. Three building blocks work together in every call of this kind.
Around those blocks sit hardware and contracts: IP desk phones, software called softphones, a hosted or on-premises phone system, and a link to a carrier. Each piece has its own article on this site, so we will not repeat them here: VoIP vs traditional phone systems, how SIP trunking works and what a softphone is.
Hold on to one thing for the rest of this guide: in classic VoIP, every block is a choice. The provider picks its codecs, turns encryption on or leaves it off, and the company network often has to be tuned to let calls through.
What is WebRTC?
WebRTC, short for Web Real-Time Communication, is a set of standards that lets a browser exchange audio, video and data in real time. Two bodies split the work. The W3C defines the interface developers use in the page. The IETF defines the protocols that travel on the network.
The abstract of the W3C Recommendation, in its March 13, 2025 version, fits in one sentence: it defines interfaces that allow media to be sent to and received from another browser or device implementing the appropriate real-time protocols. The words “or device” matter. The other end of the call does not have to be a browser. It can be a telephony server.
WebRTC does not live only in browsers either. The project’s own site, webrtc.org, states that the technology is available in all modern browsers and, as a library, for Android and iOS applications. A mobile calling app can therefore run on the same engine as a Chrome tab.
What WebRTC standardizes:
What WebRTC leaves out is just as important. RFC 8825, the overview of the whole suite, puts the choice of signaling protocols outside its scope: between the browser and the server, each application does as it pleases, with a standard or a proprietary protocol. That is why two browser-calling services are not compatible with each other, while two SIP phones from different brands are, in principle.
WebRTC vs SIP: rivals or teammates?
Teammates, in almost every case. “WebRTC vs SIP” assumes a choice, yet the two often work inside the same call: WebRTC between the device and the provider, SIP between the provider and the carriers. You will meet three setups.
| Setup | What the team uses | What it means |
|---|---|---|
| All SIP | IP desk phones and installed softphones, registered to a phone system | Hardware that can move to another provider, but a network to tune and encryption to verify. |
| WebRTC in front, SIP behind | An app in the browser; the provider's gateway speaks SIP to carriers | Nothing to install and encryption required up to the gateway, but an app tied to the provider. |
| Mixed | The browser for most seats, a few SIP phones on the same account | Each seat gets the tool that fits. Check before you sign: not every provider allows it. |
The first setup is still the norm for office phone systems with a front desk and desk phones. The second is common in calling software built for sales and support teams. The third is the most flexible, and it is the one question 7 targets in the list to send providers, further down.
In all three cases, the person you call sees no difference. Their phone rings, shows a number and carries a voice. The choice only concerns your side of the call: what you have to buy, install, tune and maintain.
How does a WebRTC call reach a phone number?
This is the part most explanations skip. WebRTC was designed to connect two browsers. The public switched telephone network (PSTN) only knows numbers and carriers. Something has to translate between them.
- 01Mic and headsetYour voiceThe browser asks for microphone permission, on an HTTPS page.
- 02BrowserWebRTCIt compresses voice with Opus, encrypts it with DTLS-SRTP and looks for a network path (ICE).
- 03InternetSTUN and TURNSTUN reveals the public address. If the firewall blocks it, a TURN relay carries the voice.
- 04GatewayWebRTC to SIPIt decrypts, converts Opus to G.711 when needed and translates the signaling to SIP.
- 05Phone networkThe number you dialThe carrier routes the call to the landline or mobile, which rings as usual.
How to read it: WebRTC protects the voice between the browser and the gateway. On the phone network, protection depends on the carriers the call crosses.
Here is what happens at each step, in order.
- 01
The page asks for the microphone.
On the first call, the browser shows a permission prompt. MDN states that the request is only possible on a secure page, loaded over HTTPS, and that user permission is always required. If the request is denied, the call cannot start. - 02
The browser sets up the call.
It tells the provider’s server which number was dialed and what it can do: its codecs, its possible network addresses, its security fingerprint. That is signaling, and its format depends on the provider. Many use SIP carried over WebSocket, a mode defined in RFC 7118. - 03
Both sides look for a path.
The browser and the server test the possible routes for the voice. The best one that answers wins. On a filtered network, that will be a relay. - 04
The gateway translates.
This is the key piece. RFC 8825 defines a gateway as a WebRTC-compatible endpoint that mediates media traffic to non-WebRTC entities, and notes that a signaling gateway may be needed to convert to SIP. It decrypts the voice, changes codec if the far side requires it, and opens a regular SIP call. - 05
The carrier rings the phone.
The call enters the phone network through a carrier trunk, exactly as a call from an office phone system would. The other person sees your caller ID and picks up on a landline or cell phone. Nothing tells them you are calling from a tab.
Two practical consequences follow.
First, the quality of a browser call is decided in two halves. The WebRTC half depends on your computer and your connection. The telephone half depends on the carriers your provider picked. A provider that is careful with the first and careless with the second will deliver mediocre calls, and the reverse is true too.
Second, the number the other person sees, its reputation and the area code it shows have nothing to do with WebRTC. They depend on the carrier side. For that topic, see our guide to the virtual business phone number and, for calls abroad, the list of international dialing codes by country.
Opus vs G.711: which codec carries your voice?
IETF RFC 7874 is unambiguous: a WebRTC endpoint is required to implement Opus, plus PCMA and PCMU, the two variants of G.711. It recommends offering Opus before G.711 whenever the device can process audio wider than a phone line.
In a call between two browsers, Opus runs the whole way. In a call to a phone number, the gateway often has to convert Opus to G.711 to talk to the carrier. That conversion has two effects: it adds a little processing, and it brings the voice back to telephone bandwidth. The nicer Opus sound does not always make it past the gateway. That is not the provider’s fault; it is the limit of the network on the other side.
The order of magnitude to remember: voice uses very little. A connection that struggles to hold a call is almost never short on bandwidth. It is short on consistency, which is what our VoIP speed test measures. The full diagnosis of choppy audio or echo has its own guide on VoIP call quality problems.
Is a WebRTC call secure?
On the leg it controls, yes, and by design. RFC 8827, which describes the WebRTC security architecture, sets four requirements that classic SIP telephony does not impose.
In SIP telephony those protections exist, but they are options the provider turns on or not, and that the handset supports or not. That is the sharpest difference between the two worlds.
Read the guarantee precisely, though.
Securing a phone setup is about more than encryption. The fraud that costs money usually exploits stolen credentials or uncapped international calling. That subject is covered in our guide to VoIP security and toll fraud. Call recording follows rules that do not depend on the technology in use: see call recording laws for business.
STUN, TURN and ICE: how does the call get through your firewall?
An office computer almost never has a public address. It sits behind a router that shares one address among many machines, and usually behind a firewall. For a voice stream to reach it, something has to find a way in. WebRTC assigns that job to three mechanisms.
RFC 8835 adds two requirements that explain why browser calls work even on closed networks: the browser must be able to reach a TURN relay over TCP, and also over TLS on top of TCP. A network that blocks UDP, as some hotels and large enterprises do, generally lets TLS out. The call takes that path, at the cost of a little extra latency.
ICE, defined in RFC 8445, ranks those paths from most direct to most roundabout and keeps the first one that works.
- Direct connectionThe browser and the provider’s server reach each other with nothing in between.
- Direct, with help from STUNA STUN server tells the computer its public address. Voice then flows directly.
- TURN relay over UDPVoice goes through one of the provider’s relays, which passes it on.
- TURN relay over TCP or TLSLast resort: voice uses the same kind of connection as a secure web page.
How to read it: the further down, the longer the path. A call relayed over TLS works, with a little more latency. Sources: RFC 8445 (ICE), RFC 8835 (WebRTC transports).
That ranking explains a common observation: the same laptop gives crisp calls at home and slightly delayed ones at the office. The app did not change. The office network simply forced the call onto a longer path.
For a network admin, three steps usually do it.
- 01
Ask for the relay list.
Your provider should be able to give the domain names, address ranges and ports of its signaling servers and relays. The default ports are 3478 for STUN and TURN, and 5349 for their TLS variants, but each service can use others. - 02
Let UDP out to those relays.
Voice over UDP is the shortest path. If your policy forbids it, the call falls back to TCP or TLS, where quality is more sensitive to loss. - 03
Watch out for TLS inspection.
A device that decrypts and re-encrypts all outbound traffic can break the signaling or slow the voice. Exclude the service’s domains from inspection if calls fail for no visible reason.
VPNs deserve their own note. A VPN that sends all traffic through a central site lengthens the voice path. If remote workers complain about delay, check that first.
What WebRTC changes for a business
The appeal of browser calling is not technical. It is logistical.
Cost follows the same logic. An IP desk phone is bought, configured and replaced. A tab costs nothing beyond the laptop already issued. One purchase remains worthwhile, and it is not optional: a decent wired headset. The buying criteria are in our guide on how to choose a headset for calls.
For a sales team, the deciding argument is elsewhere: the features that save time (automatic dialing, recording, transcription, CRM logging) are software features. They arrive faster and more completely in a web app than in a piece of hardware. Our comparison of the best VoIP for sales teams puts a per-rep price on that.
What are the limits of browser calling?
An honest guide has to say what the browser does badly.
Add Wi-Fi to the list. The browser is not to blame, but tab calling happens mostly on laptops, so often on Wi-Fi, while desk phones are wired. Part of the complaints blamed on WebRTC really come from there.
Finally, browsers are not strictly identical. The standard guarantees they understand each other, not that every provider tested its app with equal care on all of them. Always ask which browsers are officially supported, and in which versions.
When should you keep a SIP phone or an installed softphone?
The decision is not made for the whole company at once. It is made seat by seat. In a small company, that sorting ties into another question: how many phone lines you really need.
| Situation | Best fit | Why |
|---|---|---|
| Sales reps and prospecting | Browser | Calls start from the contact list, and every call is logged with no retyping. |
| Remote and distributed teams | Browser, plus mobile app | No hardware to ship, the same number everywhere. |
| Front desk and main line | SIP handset | It rings at all times, answers with one motion and depends on no computer. |
| Shop floor, warehouse, counter | SIP handset or cordless | No computer within reach, noisy surroundings, hands busy. |
| Locked-down fleet, mandated browser | Installed softphone | IT controls the version and the microphone permissions. |
| Conference room | SIP conference phone | A microphone built for several voices beats a laptop on the table. |
Three questions settle the cases that are not in the table.
- 01
Does the seat have to ring when nobody is logged in?
If yes, you need a device that is always on: a SIP phone, or at least a mobile app. - 02
Does the person already work in a browser all day?
If yes, calling from a tab spares them one more tool. If they have no computer, the question answers itself. - 03
Who controls the machine?
On a personal or lightly managed computer, the browser is the easiest route. On a tightly controlled fleet, software installed and configured by IT brings fewer surprises.
For someone who mostly calls from a phone, the question shifts: it becomes how to run a business number on a personal phone.
The two worlds coexist well. Many companies keep a few SIP phones at the front desk and in meeting rooms, and have everyone else call from the browser or a cell phone. If you are choosing between apps, our comparison of the best softphone apps for sales covers both the ones you install and the ones that open in a tab.
How do you set up a computer for browser calling?
Seven checks prevent most problems before they happen. They take ten minutes per seat.
- 01
Plug in a wired headset.
A laptop’s built-in mic and speakers cause echo and pick up keyboard noise. A USB or 3.5 mm headset fixes both at once. - 02
Allow the microphone for the right site.
In Chrome, Google’s help page gives the path: Settings, Privacy and security, Site settings, then Microphone. That is also where you pick the default microphone. Other browsers have an equivalent setting. - 03
Test the mic and the headset.
Our mic test confirms in a minute that the right device is picking up your voice. - 04
Prefer Ethernet to Wi-Fi.
If a cable is not possible, move closer to the access point and avoid networks shared with heavy downloads. - 05
Measure how steady the connection is.
A speed test is not enough. What matters is latency, jitter and packet loss. The VoIP speed test linked above measures them. - 06
Lighten the load during calls.
Close video tabs and postpone backups. Keep the browser up to date: it contains the calling engine. - 07
Stop the laptop from sleeping.
Set the computer not to sleep during a calling block, and do not close the app’s tab.
Troubleshooting: five typical browser-calling failures
When a call goes wrong, the symptom almost always points to the half of the path at fault.
| Symptom | Most likely cause | First thing to try |
|---|---|---|
| The other person can't hear me | Microphone permission denied, or wrong device selected | Check the microphone in the site settings, then run a test again |
| I can't hear anything | Audio output sent to a device other than the headset | Pick the headset as the output in the system and in the app |
| The call won't connect at all | Firewall or traffic inspection blocking the signaling or the relays | Try from a phone hotspot to confirm, then look at the network |
| Choppy or robotic voice | Unstable Wi-Fi, packet loss or an overloaded computer | Switch to a cable, close heavy applications |
| Delay between replies | Path lengthened by a VPN or a relay over TCP | Test without the VPN, then ask for UDP to be opened to the relays |
One habit pays off: the hotspot test. If the call works perfectly on your phone’s network and badly on the office one, the computer and the app are in the clear. The problem is in the local network.
What should you ask a provider?
Sales pages say “VoIP,” “cloud” or “WebRTC” without saying what sits behind the word. This message, ready to copy, gets the answers that matter.
Hi, we are evaluating your product for a team that will call from the browser. Could you tell us:
Question 7 tells you a lot. A provider that accepts both the browser and SIP phones lets you equip each seat for its use. A provider that accepts only one of the two makes that choice for you.
Four myths about WebRTC
Glossary: sixteen terms to read a product page
Sales pages stack acronyms. Here are the ones you will meet, in the order a call runs into them.
- VoIP: voice over IP. Any call carried over a data network instead of a phone circuit.
- SIP: the most common signaling protocol. It sets up, changes and ends the call, without carrying the voice.
- WebRTC: the set of standards that lets a browser or an app exchange voice in real time.
- Softphone: phone software installed on a computer or cell phone, usually speaking SIP.
- Codec: the algorithm that compresses voice on the way out and rebuilds it on arrival.
- Opus: an adaptive codec, mandatory in WebRTC, that delivers wider-band voice than a phone line.
- G.711: the legacy codec of the phone network, at 64 kbit/s, understood by every carrier.
- RTP: the protocol that carries voice packets.
- SRTP: the encrypted version of RTP.
- DTLS-SRTP: the key-exchange method WebRTC requires for encryption.
- ICE: the mechanism that tests the possible network paths and keeps the best one.
- STUN: the server that tells a computer its public address.
- TURN: the relay server that carries the voice when no direct path works.
- Gateway: the provider’s equipment that translates between WebRTC and the phone network.
- SIP trunk: the link between the provider, or the company phone system, and a carrier.
- PSTN: the public switched telephone network, where landline and cell numbers live.
A quick test: if a product page says “WebRTC” and never mentions a gateway, carriers or phone numbers, it describes only half of the call.
Where Skipcall fits
Skipcall is phone software for teams that prospect by phone. You call and text from the web and mobile app, on the same account and the same number, with no handset or box to install. Each user has a number, available in 23 countries. Calls are logged in HubSpot, Pipedrive, Salesforce or Attio, and other tools connect through the API or a CSV import.
If your team mostly calls to prospect, two comparisons pick up where this guide stops: telesales software and the best power dialers.
What to remember
- VoIP is the family, WebRTC is a member. A call placed from a browser is a VoIP call. The useful comparison is the browser versus the SIP phone or softphone.
- WebRTC stops at the gateway. It covers the leg between the browser and the first server. To reach a phone number, a gateway translates to SIP and hands the call to a carrier.
- Two mandatory codecs. Opus, adaptive and wideband, and G.711, the phone network’s language. Conversion between them happens at the gateway.
- Encryption is required, but not end to end. Voice is encrypted between the browser and the server, with no way to opt out. The rest depends on carriers.
- The standard handles the firewall. ICE looks for a path, STUN gives the public address, TURN relays when needed, including over TLS.
- Choose seat by seat. The browser for sales reps, remote work and fast rollouts. The SIP handset for the front desk, the shop floor and meeting rooms.
- Ten minutes of setup per seat prevent most failed calls: wired headset, microphone permission, steady connection, a laptop that stays awake.
Sources read on November 11, 2026: the W3C WebRTC Recommendation and the January 26, 2021 press release; IETF RFC 8825 (overview), RFC 8827 (security), RFC 8835 (transports), RFC 7874 (audio codecs), RFC 6716 and RFC 7587 (Opus), RFC 3551 (G.711 over RTP), RFC 8445 (ICE), RFC 8489 (STUN), RFC 8656 (TURN), RFC 7118 (SIP over WebSocket), RFC 3261 (SIP); ITU Recommendation G.711; webrtc.org, the WebRTC project site; MDN, getUserMedia and RTCPeerConnection; Google Chrome Help on the microphone.
