Streaming
Streaming sends one source to many viewers. A single camera, screen, or feed reaches an audience that only watches. This differs from a call: the traffic flows one way, and the viewer count can grow well past what a direct mesh can handle.
What it enables
Live broadcast with the low latency WebRTC is known for. A presenter, a gamer, or an event camera reaches viewers in well under a second, fast enough that chat and reactions stay in step with what is on screen. Traditional streaming protocols add seconds of delay; WebRTC keeps the gap small.
How it works (high level)
The source captures media the same way a call does, through getUserMedia or getDisplayMedia. The difference is distribution. Sending one stream to a thousand viewers from a single browser is not practical; the upload cost is too high.
A media server solves the fan-out. The source uploads its stream once. An SFU (selective forwarding unit) forwards copies to each viewer. The source's upload cost stays flat no matter how many people watch. Each viewer holds one WebRTC connection back to the server.
The connection still uses the same pieces: SDP negotiation, ICE for the path, and SRTP for encrypted media. Viewers usually receive only; they negotiate a receive-only track and send nothing back but feedback the connection needs to adapt quality.
For very large audiences, WebRTC is sometimes the first hop into a wider delivery network, trading some latency for reach beyond what real-time transport can serve directly.
Where it's used
Live game streaming, auctions, sports and event feeds, webinars with one speaker and many listeners, and low-latency broadcast where a few seconds of delay would break the experience.