WebRTC gets you live audio in the browser with no plugin, but "just use WebRTC" hides a lot: your own signalling server, ICE and TURN when direct paths fail, and a hard boundary where the phone network begins. This post follows one call from microphone permission to encrypted audio, then covers relay cost and how Indian networks change your test plan.
WebRTC (Web Real-Time Communication) is a set of open standards that lets browsers and apps send live audio, video, and data to each other without a plugin. Your server introduces the two sides. WebRTC then finds a network path, encrypts it, and streams the media, directly where it can and through a relay where it can't.
This guide follows one call from microphone permission to encrypted audio. It then shows what the relay costs, where WebRTC stops and the phone network starts, and how Indian networks change your test plan.
Note: Key takeaways
- WebRTC has three layers: a W3C browser API, a family of IETF protocols, and an open-source engine. People use the word for all three.
- Signalling is your job. WebRTC creates the offer and answer, but your own server has to carry them between the peers.
- Plan for a relay. Published estimates of relayed sessions run from about 8% to 25%, and each relayed call adds bandwidth you pay for.
- WebRTC stops at IP. Reaching a phone number takes a gateway and a carrier, and phone-call rules apply from that point.
- India is a wireless, mixed-IPv6 market. About 96% of Internet subscribers are wireless, and IPv6 capability runs from about 96% on Jio to under 2% on Hathway.
What does WebRTC mean?
The name breaks into Web, meaning it runs in the browser, and RTC, or real-time communication. That second part is the point: WebRTC favours getting audio to you now over getting every packet to you eventually.
In a design discussion, "WebRTC" can mean any of three different things:
| Layer | What it is | Who defines it | Who cares most |
|---|---|---|---|
| Browser API | Objects your page calls, such as RTCPeerConnection | W3C Recommendation, first published in January 2021 and last revised in March 2025 | Front-end developers |
| Protocol family | ICE, DTLS, SRTP, SCTP, and SDP used together | IETF, with RFC 8825 as the overview | Network and telecom engineers |
| Open-source engine | Code with capture, codecs, and network handling, which browsers ship and apps can embed | The WebRTC project | Teams building native apps |
The distinction matters when you compare vendors. A provider can speak the protocols without giving you the browser API, and a mobile app can embed the engine with no browser in sight.
The browser side is small. getUserMedia captures the microphone or camera, RTCPeerConnection runs the session, and RTCDataChannel carries anything that isn't audio or video.
What happens when a WebRTC call connects?
Setup and media take different routes. Your server handles the introductions, and then the peers talk to each other.
- The browser asks for the microphone. getUserMedia prompts the user and is limited to secure contexts, so plan on HTTPS from day one.
- The caller creates an offer. This SDP text lists codecs, encryption fingerprints, and ICE credentials. JSEP (RFC 9429) sets the rules for creating and applying it.
- Your server carries the offer and returns an answer. The callee's browser picks what both sides support.
- Both sides share network addresses as they find them. These are ICE candidates, and Trickle ICE (RFC 8838) lets checks begin before the list is complete.
- The peers test the paths. ICE (RFC 8445) sends connectivity checks across candidate pairs and selects a working one.
- The peers set up encryption. They run a DTLS handshake on the chosen path and compare certificates with the fingerprints from step 2.
- Media flows. Audio and video travel as SRTP. Data channels use SCTP over DTLS (RFC 8831), and all of it can share one port pair.
Each failure points at one of these stages, which makes the sequence useful for debugging:
| What you see | Stage | Check first |
|---|---|---|
| The other side never rings | Signalling | Your server logs and WebSocket connection |
| It rings, then no audio and the ICE state shows failed | ICE | STUN and TURN settings, and UDP rules |
| ICE connects, then the session closes | DTLS | Fingerprints changed in transit, or an SDP-rewriting proxy |
| Audio flows but only in one direction | Capture or negotiation | Microphone permission and the media direction in the SDP |
| Audio breaks up on some networks only | Path quality | Selected candidate pair, loss, and jitter from getStats |
Why does WebRTC leave signalling to you?
The standard specifies how offers and answers are built, and deliberately not how they travel. That keeps WebRTC out of your login, presence, and routing decisions. It also means no two WebRTC apps interoperate unless someone builds a bridge.
You have four realistic options:
| Approach | Best when | You operate |
|---|---|---|
| Your own messages over WebSocket | You control both ends, as in an in-app call | Signalling service, authentication, presence |
| SIP over WebSocket (RFC 7118) | The client must register and meet phone systems | A SIP client, with the registrar from you or a provider |
| WHIP (RFC 9725) | You push a live stream to a media server over HTTP | The publisher, with an ingest service |
| A vendor SDK | You want a working call without owning the plumbing | Your application and its token server |
If you take the SIP-over-WebSocket route, the registrar can come from your telephony provider. On Vobiz, that's a SIP endpoint: the browser client signs in with the endpoint's username, password, and registrar domain, and calls to it run the application you've attached.
How does WebRTC get through NATs and firewalls?
Most devices don't hold a public address, so a peer can't simply be dialled. ICE collects every address that might work, tests them in pairs, and uses the best pair that passes.
The preferences shown are the values RFC 8445 recommends. Two helpers supply the addresses:
- STUN (RFC 8489) tells a peer what address it appears to have from outside its NAT. It's only involved in setup, so it carries no media.
- TURN (RFC 8656) forwards the media when no direct path passes. It's your safety net, and often a large variable cost.
WebRTC endpoints must support TURN over TCP and over TLS, because some firewalls block all UDP. Offer those transports as well as UDP, or those users will fail to connect at all.
How often will calls use a relay?
There is no recent neutral figure, and every number here comes from a vendor or analyst. VideoSDK says about 8 to 15 percent of sessions, Metered says about 20 to 25 percent, and BlogGeek.me calls roughly 80 percent without a relay "common lore". Both Metered and VideoSDK sell related infrastructure.
Treat those figures as a starting assumption. Then log the selected candidate pair from getStats on real calls, which reports whether each side used a relay candidate.
The math for relay capacity is simple. A relayed Opus call at 32 kbps uses about 53.6 kbps per direction once you add the 4-byte TURN channel header to the figures in the chart below. The relay forwards both directions, so it sends about 107 kbps, or 48 MB an hour.
As an illustration, take 5,000 concurrent calls with 20% relayed. That's 1,000 relayed calls, or about 107 Mbps out of your TURN fleet, with the same amount coming in.
Is WebRTC always peer-to-peer?
No. Two people on a simple call can run peer-to-peer, but most business uses put a server in the media path. Then the "peer" your browser connects to is that server.
| What you're building | Topology | Why |
|---|---|---|
| One-to-one call in your app | Peer-to-peer, TURN as fallback | Lowest server cost |
| Three or four people, no recording | Mesh | Each sender uploads one stream per participant, so it fades quickly on mobile |
| Group calls or webinars | Selective forwarding unit (SFU) | Each sender uploads once and the server forwards to the rest. RFC 7667 calls this a selective forwarding middlebox |
| One combined stream for weak devices | Mixer (MCU) | The server decodes and mixes, which costs more compute |
| Recording, transcription, or an AI agent | Server as a participant | The server needs the decoded audio |
| Calls to phone numbers | Media gateway | The server joins WebRTC to the carrier network |
How does WebRTC reach a phone number?
WebRTC has no concept of a phone number. Reaching one takes a gateway, a carrier, and a number you're allowed to use as caller ID.
Three things change at that gateway:
- Audio can narrow. WebRTC endpoints must implement both Opus and G.711. When the phone side uses G.711, the caller's wideband audio is reduced to 8 kHz for that leg, whichever codec the browser sent.
- WebRTC's encryption ends. The DTLS-SRTP session terminates at the gateway. Any protection on the carrier leg comes from the telephony side.
- Keypad tones still work. The same RFC requires support for telephone events, so a browser client can drive a phone menu. On Vobiz, those digits reach your call logic through the Gather element, which collects keypad presses or speech and posts them to your action URL.
What codecs does WebRTC use, and how much bandwidth?
Every WebRTC browser must support a shared baseline, so two browsers can always agree on something.
| Media | Required | Often available | Notes |
|---|---|---|---|
| Audio | Opus, plus G.711 PCMA and PCMU | None needed | RFC 7874 recommends offering Opus first when the device handles more than 8 kHz |
| Video | VP8 and H.264 Constrained Baseline | VP9 and AV1, depending on browser | Support varies by browser version, so check your targets |
Opus spans 6 to 510 kbps. The same RFC suggests 16 to 20 kbps for wideband speech and 28 to 40 kbps for full-band speech. The audio is only part of what you send, though:
IPv6 headers are 20 bytes longer, which adds 8 kbps to each stream at this packet rate. For a voice agent, the wideband path matters most: it gives a speech model more of the voice to work with than an 8 kHz phone leg does. Vobiz's audio quality notes make the same point for speech recognition and list its wideband options, G.722 and Opus.
How is WebRTC different from SIP, WebSocket, and VoIP?
These terms sit at different levels, so a system often uses several of them at once. VoIP is the category. WebRTC is one way to do it, and so is SIP with RTP.
| WebRTC | SIP | WebSocket | |
|---|---|---|---|
| What it is | Complete real-time media stack | Session signalling protocol | General two-way channel over TCP |
| Carries audio itself | Yes, as SRTP | No, RTP or SRTP does | Only if you frame the audio yourself |
| Runs natively in a browser | Yes | Only over a WebSocket | Yes |
| Reaches phone numbers | Through a gateway | Yes, with a carrier | Through a telephony provider |
| Encryption | Mandatory | Optional TLS and SRTP | Optional, using wss:// |
| Late or lost packets | Skipped or concealed, so the call moves on | Depends on the media path | TCP resends, so later data waits |
They also combine well. A softphone can run SIP over a WebSocket for signalling and use WebRTC for its audio. If your choice is between SIP and WebSocket streaming on the telephony side, that guide covers it in depth. In short, on Vobiz:
- SIP trunk. Vobiz hands the call to a SIP platform such as LiveKit, which terminates SIP and brings the caller into a WebRTC room. The platform runs the agent and turn-taking.
- WebSocket stream. Vobiz fetches your Answer URL, a Stream element opens a wss:// socket to your server, and your code receives the caller's audio and sends replies on the same connection. Barge-in is yours to build, using the clear-audio command in the streaming protocol.
The last row of the table above shows up here too. RTP skips lost packets, while a WebSocket runs over TCP and resends them, which can add jitter on poor networks. The SIP vs WebSocket visualizer steps through both paths.
When should you use WebRTC?
Start with who is on the other end and what they already have open.
| You need | Use | Why |
|---|---|---|
| Agents answering calls in a browser or CRM | WebRTC client with SIP endpoint | No desk phone or softphone install |
| Click-to-call from your website or app | WebRTC plus a telephony provider | The caller stays on your page |
| An AI agent inside your web app | WebRTC to a media server | Wideband audio with no phone call |
| An AI agent people reach by dialling | SIP trunk or Voice API with media streaming | The caller has only a phone |
| Calling customers who don't have your app | SIP trunk or Voice API | WebRTC can't ring a phone on its own |
| Live video with very low delay, such as auctions or cloud gaming | WebRTC, with WHIP for ingest | Interaction matters more than scale |
| Sending files or game state between users | RTCDataChannel | Encrypted, with no media needed |
Is WebRTC secure?
The media layer is secure by rule. RFC 8827 requires SRTP for all media, DTLS for all data channels, and DTLS-SRTP for keys, and it forbids plain RTP and null ciphers. Other risks sit around that layer, and these are yours to handle:
- Signalling. The DTLS fingerprints travel in your SDP, so a compromised signalling path undermines the check. Use TLS and authenticate every user.
- Servers in the path. SRTP protects each hop. An SFU, gateway, or AI server that terminates it can access the media. SFrame (RFC 9605) offers end-to-end encryption through an SFU when your design allows it.
- IP address exposure. Connecting peers means revealing network addresses. RFC 8828 limits what a site sees until the user grants consent, and a relay-only policy can hide them further.
- Credentials. Issue short-lived TURN credentials and client tokens, and never put a long-lived account secret in front-end code.
What changes when your users are in India?
The textbook WebRTC setup assumes office Wi-Fi. India's Internet looks different, so test for it.
Per TRAI's April to June 2026 report, India had 1,114.17 million Internet subscribers at the end of June 2026, of whom 1,066.43 million were wireless. That's about 96%, against 47.73 million on wired connections. IPv6 capability then varies widely by operator:
These figures come from APNIC Labs' India page, and they change daily. They measure capability, not WebRTC success. Operators can run several networks, so read the numbers as a guide to variety.
Here's what we'd do with that data. These are our recommendations, not measured WebRTC results:
- Test on real SIMs and home broadband. Include at least Jio, Airtel, and Vi mobile data, and one IPv4-heavy cable provider. Office Wi-Fi tells you little about your customers.
- Run TURN and media servers on both IPv4 and IPv6. A Jio user and a Hathway user may share no IPv6 path, so that call falls back to IPv4 and any carrier-grade NAT in front of it. A dual-stack relay can bridge the two families.
- Host relays in India for Indian users. A relay abroad adds a long round trip to every packet of the call.
- Report relay share by operator. Your national average can hide a single network that relays most of its calls.
- Keep audio bitrates modest on mobile. Wideband Opus uses about 36 MB an hour both ways, which suits long agent shifts and prepaid data better than full-band audio does.
Phone-call rules still apply
A browser is only the start of the call. Once it reaches an Indian phone number, India's calling regulations apply, and the channel you started from changes nothing. That covers KYC, caller ID, number series, consent, and the media anchoring rule, under which both legs of a call stay in India. Check where your browser clients and media servers sit before you launch.
TRAI's Third Amendment regulations, issued on 18 September 2026 and summarised in press release 119/2026, also matter here:
- Definition. An A2P call is one started by an application, software system, or automated platform without direct human dialling, including autodialling, robo-calls, and pre-recorded or artificial voice.
- Duty. Once in force, senders must declare A2P use and caller ID ranges to their originating provider in advance. Undeclared calls found on investigation count as unsolicited.
- Live agents. Stakeholders asked TRAI to exclude calls with a live human agent, and TRAI declined because networks can't reliably tell the two apart.
- Charge. Terminating operators can charge originating operators up to ₹0.05 per minute on A2P calls, with 140xx, 1600xx, and 1601xx series exempt.
An AI agent or an app-triggered callback appears to fit that definition. An agent who types a number into a browser softphone looks closer to direct human dialling, but the text doesn't mention softphones, so confirm your flow with your provider. The declaration and the charge both start 60 days after Gazette publication. We couldn't confirm that date, so check whether they're in force when you launch.
Separately, Khaitan & Co reports that DoT notified new authorisation rules under the Telecommunications Act, 2023 in June 2026. If you plan to offer calling as your own service, rather than as a customer of an authorised provider, take legal advice first.
How Vobiz handles WebRTC
Vobiz connects your WebRTC clients to phone numbers and call control. Here's how each client type connects, per the docs:
- Browser testing. The hosted WebRTC Playground makes and receives calls in a browser tab using your Auth ID and Auth Token. It creates its own application on first connect, and you attach a DID to receive inbound calls. The inbound guide walks through it.
- Custom browser clients. Create a SIP endpoint, then register it over SIP on a WebSocket with the endpoint's username and password. Each endpoint holds one active registration, so give each agent their own.
- iOS apps. Run the browser SDK inside a WebView, or place calls through the Voice API and connect the app over your own transport.
- Call logic. An application holds the Answer URL that returns VobizXML. Calls to an endpoint hit it.
- Voice AI on phone calls. Connect trunks to a platform such as LiveKit, which brings callers into WebRTC rooms as SIP participants. Or use audio streaming for bidirectional WebSocket audio, with L16 at 8 or 16 kHz inbound and up to 24 kHz for playback.
- WhatsApp calls. The WhatsApp calling API takes a WebRTC SDP offer and runs over WhatsApp's own WebRTC infrastructure.
- Quality data. Each call detail record reports the negotiated codec, with call-quality scores, jitter, and packet loss. Current rates are on the pricing page. Test calls are real and billed to your account. Use your own credentials, confirm numbers first, and enter your Auth Token only on Vobiz services or your own server.
Frequently asked questions
FAQ
What does WebRTC mean?
WebRTC means Web Real-Time Communication. The name covers a browser API, a set of network protocols, and an open-source engine that work together. They let a web page or app send live audio, video, and data without a plugin.
Is WebRTC peer-to-peer?
It can be. Media goes directly between two peers when the network allows, and through a TURN relay when it doesn't. Many business deployments also put a media server in the path for recording, group calls, or AI. Setup always needs a signalling server.
Is WebRTC secure?
Encryption is mandatory: SRTP protects media and DTLS protects data channels, with no plain mode. Your application still has to secure signalling, login, and any server in the media path, because that server can access the audio.
Do I need a TURN server for WebRTC?
For a production service, yes. Some networks block every direct path, and those calls fail without a relay. Published estimates put relayed sessions between about 8% and 25%, so measure your own share. Offer TURN over UDP and over TLS.
Can WebRTC call a phone number?
Not by itself, because WebRTC connects browsers, apps, and servers over IP. To reach a phone number, you need a gateway that joins the session to a carrier, plus a number to use as caller ID. On Vobiz, a registered endpoint can place those calls.
Is WebRTC free?
The standards and the open-source code cost nothing to use. Running a real service does cost money: signalling servers, TURN bandwidth, and any media servers. Calls that reach the phone network also carry telephony charges.
Further reading on Vobiz
- WebRTC Playground · SIP endpoints
- What is SIP? · What is VoIP? · What is a Voice API?
- SIP vs WebSockets · Streaming over WebSockets · Audio Streams API
- India calling regulations · UCC management
Sources
Web and browser standards
- W3C, WebRTC: Real-Time Communication in Browsers, Recommendation, 13 March 2025.
- W3C and IETF, WebRTC becomes a W3C Recommendation and multiple IETF standards, 26 January 2021.
- W3C, Identifiers for WebRTC's Statistics API, Candidate Recommendation Draft, 25 September 2025.
- MDN, MediaDevices: getUserMedia and Codecs used by WebRTC.
- WebRTC project, Real-time communication for the web.
IETF standards
- RFC 6455: The WebSocket Protocol, December 2011.
- RFC 6888: Common Requirements for Carrier-Grade NATs, April 2013.
- RFC 7118: The WebSocket Protocol as a Transport for SIP, January 2014.
- RFC 7587: RTP Payload Format for the Opus Speech and Audio Codec, June 2015.
- RFC 7667: RTP Topologies, November 2015.
- RFC 7742: WebRTC Video Processing and Codec Requirements, March 2016.
- RFC 7874: WebRTC Audio Codec and Processing Requirements, May 2016.
- RFC 8445: Interactive Connectivity Establishment, July 2018.
- RFC 8489: Session Traversal Utilities for NAT, February 2020.
- RFC 8656: Traversal Using Relays around NAT, February 2020.
- RFC 8825: Overview of Real-Time Protocols for Browser-Based Applications, January 2021.
- RFC 8827: WebRTC Security Architecture, January 2021.
- RFC 8828: WebRTC IP Address Handling Requirements, January 2021.
- RFC 8831: WebRTC Data Channels, January 2021.
- RFC 8835: Transports for WebRTC, January 2021.
- RFC 8838: Trickle ICE, January 2021.
- RFC 9429: JavaScript Session Establishment Protocol, April 2024.
- RFC 9605: Secure Frame (SFrame), August 2024.
- RFC 9725: WebRTC-HTTP Ingestion Protocol (WHIP), March 2025.
India
- TRAI, Press release 135/2026: Performance Indicator Report, April to June 2026, 12 October 2026.
- TRAI, Press release 119/2026 on the Third Amendment, 18 September 2026.
- TRAI, Telecom Commercial Communications Customer Preference (Third Amendment) Regulations, 2026, 18 September 2026.
- APNIC Labs, Use of IPv6 for India, read 3 November 2026.
- Khaitan & Co, Update on the principal telecommunication services authorisation rules, June 2026.
Industry estimates
- BlogGeek.me, What is WebRTC and what is it good for? and WebRTC TURN.
- Metered, What is a TURN server?
- VideoSDK, TURN server for WebRTC.
If your voice AI agent also needs to reach ordinary phone numbers, Vobiz provides SIP trunks and numbers for that leg.






Top comments (0)