What Is WebRTC? – Definition and How It Works

Learn what WebRTC provides, how ICE and STUN establish connections, and why it leaks addresses past a proxy.

WebRTC is a set of browser APIs for real-time peer-to-peer communication — audio, video, and arbitrary data — without a plugin and, ideally, without relaying through a server.

1. What It Provides

Video calling in a browser is the familiar use. The data channel is the less obvious one — a low-latency bidirectional channel that bypasses HTTP entirely.

2. Connection Setup Is the Interesting Part

Two browsers behind different home routers cannot simply connect; NAT sits in the way. WebRTC solves this with ICE:

1. Each peer gathers candidate addresses it might be reachable at.
2. host candidates are local network addresses.
3. srflx candidates come from a STUN server, which reports the public address it saw.
4. relay candidates come from a TURN server, which relays traffic when direct connection fails.
5. The peers exchange candidates and test pairs until one works.

The signalling — exchanging candidates and descriptions — is not specified by WebRTC; applications do it over their own channel, typically WebSockets.

3. Why It Reveals Your Address

Step 3 is the consequential one. To learn its public address, the browser asks an external STUN server over UDP — outside the HTTP stack.

An HTTP or SOCKS proxy configured for page loads does not necessarily carry that UDP traffic. So the address STUN reports can be the machine's real public address, even though every HTTP request went through a proxy.

The result: a page can observe two different public addresses for one visitor, which demonstrates a proxy rather than merely suggesting one.

4. What This Means for Automated Browsers

The clean case is the goal. Everything else trades one signal for another, which is why the most robust arrangement is a browser whose real egress is the intended address.

5. Media Capabilities Add Entropy

Beyond addresses, WebRTC exposes capability information:

RTCRtpReceiver.getCapabilities('video').codecs
RTCRtpSender.getCapabilities('audio').codecs

Supported codec lists vary by browser build, platform, and available hardware encoders. That contributes fingerprinting entropy independently of any address leak — so even a fully proxied WebRTC stack still describes the device.

6. Practical Configuration

For collection work, the usual questions are whether to allow WebRTC at all and what it will reveal:

browser = playwright.chromium.launch(args=[
    "--force-webrtc-ip-handling-policy=default_public_interface_only",
])

Chromium exposes policies restricting which interfaces are used and whether non-proxied UDP is permitted. The right setting depends on whether the target uses WebRTC at all — most data-bearing sites do not.

Test explicitly rather than assuming: gather candidates and compare any address found against the address your HTTP requests present.

7. When You Actually Need It

Very rarely for scraping. It matters when:

• The target is a real-time communication application.
• You are testing your own WebRTC product.
• A site probes WebRTC as part of its bot detection, in which case its availability and consistency matter even though you never use it.

The third case is the common one, and it is why the configuration question arises at all.

8. Summary

WebRTC provides peer-to-peer audio, video, and data in the browser, using ICE with STUN and TURN servers to discover reachable addresses through NAT.

Because that discovery happens over UDP outside the HTTP stack, it can report a public address that contradicts a configured proxy — the strongest kind of proxy signal — so either route UDP through the same egress, restrict interface handling, or run where the real egress is the intended one, and test rather than assume.

Potential Related Glossary

• Browser Fingerprints
• IP Rotation
• Residential Proxies
• Headless Browser