WebRTC: Media and Data Directly Between Browsers

Two browsers exchange an offer and an answer through a server, then send audio, video and data to each other directly.

WebRTC lets two browsers send audio, video and data straight to each other, without a server relaying the conversation. To start, each describes what it can send in a message called an offer or an answer, and the two messages are passed between them through a signalling server the application provides. Once each knows the other's addresses, media flows directly, encrypted, over UDP.

Picture two people starting a video call in a web app. Their browsers have never met and know nothing about each other's address, cameras or codecs, the formats used to compress the video. The app's own server introduces them; after that, it steps aside.

Offer and answer through a signalling server, then a direct media path

How it starts. WebRTC does not say how the offer and answer travel. The application chooses, usually a WebSocket to its own server. Each message is written in SDP (Session Description Protocol), a text format listing the media, codecs and encryption details. Alongside it, each browser sends candidates: addresses at which it might be reached. The browsers then test pairs of addresses until one works, a process called ICE (Interactive Connectivity Establishment).

Who may send. Both peers, at the same time, directly. The signalling server sees only the setup messages, never the media.

One message on the wire. Audio and video travel as SRTP packets, real-time media with encryption, over UDP. Arbitrary data travels on data channels, which run SCTP inside DTLS, the datagram version of TLS, also over UDP, and can be reliable and ordered or neither. Every byte is encrypted; WebRTC has no unencrypted mode.

After a drop. If the path fails, for instance when a laptop moves to another network, the peers run an ICE restart: they gather fresh candidates, exchange them through the signalling server again, and test new pairs while the call holds.

UDP is the choice because late media is useless. A video frame resent half a second later only freezes the picture; skipping it keeps the call live.

So WebRTC needs a server to make the introduction, and then keeps it out of the conversation.

← → move through sections and cards