RTCPeerConnection: Direct Browser-to-Browser Links
Think of an RTCPeerConnection as a direct phone line between two browsers. It's the core of WebRTC, enabling peer-to-peer video and data streams. The footgun: it doesn't find peers; you must use a separate signaling server to broker the initial handshake.
Why it exists
WebRTC was created to enable direct, low-latency communication between browsers without routing all data through a central server. This reduces server costs and latency for real-time applications like video calls. RTCPeerConnection is the core JavaScript object that solves the complex problem of how two clients, often behind different firewalls and NATs, can establish a direct data path.
The mental model
Think of an RTCPeerConnection object as your end of a direct tunnel to another browser. To establish this tunnel, you first call a central operator (a "signaling" server you must build) to get the other person's contact info. This info includes session descriptions (what kind of media to send) and ICE candidates (possible network paths). Once you've exchanged this info, you hang up with the operator and establish the direct call. The RTCPeerConnection is your phone for that direct call, managing the connection state and data flow.
How it works
A connection is established through a process called signaling. First, one peer creates an RTCPeerConnection object and generates an "offer" with connection details. This offer is sent to the other peer using your signaling channel (like a WebSocket). The remote peer receives the offer, sets it as its remote description, and creates an "answer". This answer is sent back. During this exchange, both peers also gather and share ICE candidates, which are potential network addresses. Once they find a compatible path, the direct connection is established. The API provides properties like connectionState and iceConnectionState to monitor this process.
When to use it
Use RTCPeerConnection for any application requiring real-time, peer-to-peer communication in the browser. This is the foundation for video and audio conferencing, live streaming with minimal delay, browser-based multiplayer games, and direct P2P file transfers.
When not to use it
Avoid it for one-to-many broadcasts where a centralized media server is more efficient (e.g., a webinar to thousands of viewers). The complexity of signaling and NAT traversal is also overkill for non-real-time communication where standard HTTP requests are simpler and sufficient.
One canonical example
A two-person video chat. Browser A creates an RTCPeerConnection, adds its camera stream, and generates an offer. This offer is sent to Browser B via a WebSocket server. Browser B receives the offer, creates its own RTCPeerConnection, adds its stream, generates an answer, and sends it back. As they exchange ICE candidates, a direct media path is formed, and video flows between them without passing through the server.
Interview question
What is the primary role of a signaling server in a WebRTC application utilizing RTCPeerConnection?
- a.To act as a relay server for media if a direct peer-to-peer connection cannot be established.
- b.To route all real-time media and data streams between the connected browsers.
- c.To manage the internal state and lifecycle of the RTCPeerConnection object on each client.
- d.To facilitate the initial exchange of connection metadata, such as session descriptions and ICE candidates.Correct
Why? this is the answer
The card states that RTCPeerConnection 'doesn't find peers; you must use a separate signaling server to broker the initial handshake' by exchanging 'session descriptions (what kind of media to send) and ICE candidates (possible network paths)'. Option B describes a central server model that WebRTC aims to avoid for media, while Option A describes a TURN server, which is a different component from the signaling server's primary role.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
- #webrtc
- #networking
- #web apis
- #p2p
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles