# WebRTC Guide, Part 1: What WebRTC Is and How a Call Actually Connects

> What WebRTC is and how it works: the 2021 standard, browser support, BYO signaling, SDP offer/answer, ICE, STUN and TURN, and when you need a TURN server.

Source: https://bytevancer.com/blog/webrtc-guide-part-1-how-webrtc-works · Published 2026-10-30 · ByteVancer · Real-Time Web

**WebRTC puts real-time audio, video and data in the browser with no plug-in. What it is, how two peers find each other, and when you need TURN.**

> **Part 1 of 3: WebRTC, explained** — **Part 1: What WebRTC is and how a call connects (you're here)** · [Part 2: Encryption, codecs, and SFU vs MCU vs mesh](https://bytevancer.com/blog/webrtc-guide-part-2-encryption-codecs-sfu) · [Part 3: WHIP, E2EE, MoQ, security and debugging](https://bytevancer.com/blog/webrtc-guide-part-3-whip-e2ee-moq-2026)

Video calls, screen sharing and peer-to-peer data in a browser tab all run on WebRTC. This series is for the developers who build on it and the product owners who pay for it, as of 30 Oct 2026. Part 1: what it is and how a call connects. Sources are at the bottom.

## TL;DR

- WebRTC = browser APIs plus IETF protocols for real-time audio, video and data, without plug-ins.
- An official standard since January 2021: W3C Recommendation plus the IETF RFC 8825 series.
- Signaling is yours to build. The spec deliberately leaves it out.
- ICE tries direct paths first; TURN relays when nothing else works, and the relay operator pays for the bandwidth.

## What is WebRTC?

MDN: WebRTC "enables Web applications and sites to capture and optionally stream audio and/or video media, as well as to exchange arbitrary data between browsers without requiring an intermediary", "without requiring that the user install plug-ins." webrtc.org says the project is supported by Apple, Google, Microsoft and Mozilla, with JavaScript APIs in the major browsers and a native library for Android and iOS. libwebrtc calls itself "a free, open software project".

**🎞️ From code drop to standard**
1. **31 May 2011** — Google open-sources WebRTC — "real-time voice and video on the web", to be integrated in Chrome
2. **27 Oct 2011** — First W3C Working Draft
3. **Jan 2021** — IETF RFC 8825 series — Overview, security considerations, security architecture
4. **26 Jan 2021** — W3C Recommendation — "now an official standard", royalty-free
5. **13 Mar 2025** — Latest W3C Recommendation — Includes candidate amendments

*W3C publication history, the 2021 W3C/IETF press release and Harald Alvestrand's 2011 announcement.*

## Browser support

**First version with the unprefixed API, from MDN browser-compat-data.**
- **Chrome** — RTCPeerConnection: 56 (prefixed from 23); RTCDataChannel: 24
- **Firefox** — RTCPeerConnection: 44 (prefixed from 22); RTCDataChannel: 22
- **Safari** — RTCPeerConnection: 11; RTCDataChannel: 11
- **Edge** — RTCPeerConnection: 15; RTCDataChannel: See MDN

## The core APIs

- `getUserMedia()`: camera and mic. Secure contexts only (HTTPS, localhost), always asks permission, and iframes need allow="camera; microphone". Its spec, Media Capture and Streams, is a W3C Candidate Recommendation Draft.
- `RTCPeerConnection`: the connection between two peers, with RTCRtpSender/RTCRtpReceiver per track.
- `RTCDataChannel`: arbitrary data over the same connection.
- `RTCSessionDescription`, `RTCIceCandidate` and `RTCStatsReport`: the offer/answer, network candidates and stats.

## How a WebRTC call connects

**One call, start to media**
Capture → Offer → Answer → ICE → Secure media

1. **Capture** — getUserMedia() returns tracks after the user says yes.
2. **Offer** — Caller: createOffer(), setLocalDescription(), send the SDP over your signaling.
3. **Answer** — Callee: setRemoteDescription(offer), createAnswer(), send it back.
4. **ICE** — Both sides trade candidates (host, server-reflexive, relayed) and test pairs.
5. **Secure media** — DTLS handshake, then SRTP media and SCTP data channels.

## Signaling is bring-your-own

webrtc.org: "Passing SDP objects to remote peers is called signaling and is not covered by the WebRTC specification." MDN: "You can use anything you like, from WebSocket to fetch() to carrier pigeons", and the server "doesn't need to understand or interpret the signaling data". RFC 8825 puts signaling protocols "outside the scope".

What travels is SDP, which MDN calls "not truly a protocol, but a data format". JSEP (RFC 9429, April 2024, replacing RFC 8829) defines the offer/answer dance in JavaScript. A signaling server is ordinary web backend work, the kind our [web development team](https://bytevancer.com/services/web-development) builds.

## ICE, STUN and TURN

- ICE (RFC 8445): "ICE works by exchanging a multiplicity of IP addresses and ports", then tests them. Candidates are host, server-reflexive or relayed.
- STUN (RFC 8489) tells a peer its public address. "STUN is not a NAT traversal solution by itself."
- TURN (RFC 8656) relays the media; it "comes at a high cost to the provider of the TURN server", so "it is best to use a TURN server only when a direct communication path cannot be found". MDN: needed behind symmetric NAT.

## A minimal peer connection

*Caller side, after the webrtc.org sample. The callee mirrors it: setRemoteDescription(offer), createAnswer(), setLocalDescription(), send the answer.*
```js
// signalingChannel = your WebSocket, fetch(), anything
const pc = new RTCPeerConnection({
  iceServers: [{ urls: 'stun:stun.l.google.com:19302' }],
});
signalingChannel.addEventListener('message', async (msg) => {
  if (msg.answer) await pc.setRemoteDescription(msg.answer);
  if (msg.iceCandidate) await pc.addIceCandidate(msg.iceCandidate);
});
pc.addEventListener('icecandidate', (e) => {
  if (e.candidate) signalingChannel.send({ iceCandidate: e.candidate });
});
pc.addEventListener('connectionstatechange', () => {
  if (pc.connectionState === 'connected') console.log('connected');
});
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
signalingChannel.send({ offer });
```

## Do I need a TURN server?

**Do I need a TURN server?**
- Users behind symmetric NAT or strict firewalls? → **Yes: run TURN**
- Must every call connect, on any network? → **Yes: TURN fallback**
- Must peers' IPs stay hidden from each other? → **TURN, relay-only**
- Otherwise → **STUN alone may do; test real networks**

A TURN entry is just `{ urls: 'turn:turn.example.com', username: 'USER', credential: 'PASS' }` in iceServers. The cost is bandwidth: RFC 8656 says the server "typically needs a high-bandwidth connection". [Part 2](https://bytevancer.com/blog/webrtc-guide-part-2-encryption-codecs-sfu) covers encryption, codecs and media servers.

## The whole series

1. **Part 1: What WebRTC is and how a call connects (this post)**
2. [Part 2: Encryption, codecs, and SFU vs MCU vs mesh](https://bytevancer.com/blog/webrtc-guide-part-2-encryption-codecs-sfu)
3. [Part 3: WHIP, E2EE, MoQ, security and debugging](https://bytevancer.com/blog/webrtc-guide-part-3-whip-e2ee-moq-2026)

## Frequently asked questions

**What is WebRTC?**
A set of browser APIs and IETF protocols for real-time audio, video and data between browsers without plug-ins. It became a W3C Recommendation on 26 Jan 2021.

**How does WebRTC work?**
Peers exchange an SDP offer and answer over a signaling channel you build, trade ICE candidates to find a network path, then send DTLS-SRTP encrypted media and SCTP data.

**Do I need a signaling server for WebRTC?**
You need some way to pass the offer, answer and candidates. WebRTC doesn't specify it; WebSocket or fetch() both work.

**What is the difference between STUN and TURN?**
STUN tells a peer its public address so a direct path can be tried. TURN relays the media when no direct path works, at a bandwidth cost to whoever runs it.

**Do I need a TURN server?**
If calls must connect for every user, including behind symmetric NAT or strict firewalls, yes, as a fallback. RFC 8656 advises using TURN only when a direct path cannot be found.

## Keep reading

- [WebRTC Guide, Part 2: Encryption, Codecs, and SFU vs MCU vs Mesh](https://bytevancer.com/blog/webrtc-guide-part-2-encryption-codecs-sfu) — How WebRTC works under the hood: mandatory DTLS-SRTP, data channels, VP8/H.264/AV1/HEVC codecs, congestion control, simulcast, and SFU vs MCU vs mesh servers.
- [WebRTC Guide, Part 3: WHIP, E2EE, MoQ, Security and Debugging in 2026](https://bytevancer.com/blog/webrtc-guide-part-3-whip-e2ee-moq-2026) — WebRTC in 2026: WHIP (RFC 9725) and WHEP, SFrame E2EE, WebRTC vs WebSocket, LL-HLS and MoQ, IP leaks and mDNS, libwebrtc CVEs, and debugging with getStats.
- [All ByteVancer engineering articles](https://bytevancer.com/blog)

## Adding calls or live data to your app?

We build the web app around WebRTC: signaling backend, TURN setup and the UI. See our [custom web application development](https://bytevancer.com/services/web-development) or [talk to the team](https://bytevancer.com/contact).

## Sources

- [MDN — WebRTC API](https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API)
- [webrtc.org](https://webrtc.org/)
- [libwebrtc README](https://webrtc.googlesource.com/src/+/main/README.md)
- [W3C public-webrtc list, May 31, 2011](https://lists.w3.org/Archives/Public/public-webrtc/2011May/0022.html)
- [W3C — WebRTC history](https://www.w3.org/standards/history/webrtc/)
- [W3C — WebRTC Recommendation](https://www.w3.org/TR/webrtc/)
- [W3C/IETF press release, Jan 26, 2021](https://www.w3.org/2021/01/pressrelease-webrtc-rec.html)
- [RFC 8825 — overview](https://www.rfc-editor.org/rfc/rfc8825.html)
- [RFC Editor — WebRTC RFCs](https://www.rfc-editor.org/subjects/webrtc/)
- [MDN browser-compat-data](https://raw.githubusercontent.com/mdn/browser-compat-data/main/api/RTCPeerConnection.json)
- [MDN — getUserMedia()](https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia)
- [W3C — Media Capture and Streams](https://www.w3.org/TR/mediacapture-streams/)
- [webrtc.org — Peer connections](https://webrtc.org/getting-started/peer-connections)
- [MDN — Signaling](https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Signaling_and_video_calling)
- [RFC 9429 — JSEP](https://www.rfc-editor.org/rfc/rfc9429.html)
- [MDN — WebRTC protocols](https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Protocols)
- [RFC 8445 — ICE](https://www.rfc-editor.org/rfc/rfc8445.html)
- [RFC 8489 — STUN](https://www.rfc-editor.org/rfc/rfc8489.html)
- [RFC 8656 — TURN](https://www.rfc-editor.org/rfc/rfc8656.html)
- [RFC 8827 — security architecture](https://www.rfc-editor.org/rfc/rfc8827.html)
- [RFC 8831 — data channels](https://www.rfc-editor.org/rfc/rfc8831.html)
- [webrtc.org — TURN server](https://webrtc.org/getting-started/turn-server)

---

*This is the Markdown copy of https://bytevancer.com/blog/webrtc-guide-part-1-how-webrtc-works — the page itself has the interactive charts and diagrams.*