WebRTC is a protocol for peer-to-peer data exchange. Because it has very little latency by design, it is often used for live video streaming.
After reading this article you will be able to:
Copy article link
Web Real-Time Communications (WebRTC) is an open-source technology that allows browsers to exchange data directly with only minimal use of an intermediary server or third-party software. Often WebRTC is used specifically for exchanging audio and video data.
WebRTC uses a set of APIs and protocols to set up peer-to-peer (P2P) connections directly between devices. It can support telephone connections, teleconferencing, audio and video streaming, file transfers, and screen sharing, among other types of communication.
Most technologies for exchanging and streaming data between devices rely on the use of servers in the middle to receive data from clients, store or cache the data, and forward the data to the other client. If Alice wants to talk to Bob using a chat app, her words travel first to a web server before they reach Bob's device. WebRTC, for the most part, allows Alice and Bob to send their communications directly to each other.
As a result, from the app developer's perspective, WebRTC-based apps require a little less backend infrastructure and can have less latency compared to apps that use client-server protocols. The other advantage of WebRTC is that users do not have to install anything: no plugins or additional software are necessary beyond a web browser.
WebRTC streams directly between browsers. Almost all browsers support WebRTC natively so users do not have to install a plugin or additional software, which makes WebRTC a logical choice for building real-time communications features into a web app.
While WebRTC is primarily P2P, in reality end user devices tend to be behind firewalls, they require network address translation (NAT) for connections, or they connect to the Internet via routers that do not support P2P. Therefore, WebRTC connections do require intermediary servers to enable devices to find each other or to forward data from one to the other. WebRTC relies on a set of specialized protocols and servers to accomplish this.
Session Traversal Utilities for NAT (STUN) is a protocol for finding out the public IP address of the other peer in the connection. The peers ask the STUN server for the other one's public IP address and whether or not the peer can be reached behind their router's NAT. If a public IP address is available for both parties, the WebRTC connection can then proceed directly between the peers.
Traversal Using Relays around NAT (TURN) is used in some cases when the other peer in a connection has no public IP address due to the use of firewalls or private IP addresses. Peers connect to a TURN server rather than directly to each other, and the server forwards their packets.
Interactive Connectivity Establishment (ICE) is the framework that allows browsers to connect to STUN and TURN servers.
Learn more about WebRTC protocols here.
For P2P media exchange between two devices, such as in a video call, they need to negotiate how they will send information to each other. This requires the use of a signaling server. The signaling server facilitates a back-and-forth between the devices as they decide on communication protocols, media resolution, video codecs, and other requirements for exchanging media streams, as well as exchanging routing information.
While WebRTC is designed to work P2P, it can also work with an intermediary media server. A media server can receive and forward media while taking into account device bandwidth limitations and other constraints. This is especially necessary when more than two devices are streaming to each other — say, when a dozen people wish to participate in a video call, instead of just two.
The Internet was built on the client-server model.
Typically, clients load websites, apps, and data from servers, rather than communicating directly with each other. Servers are more reliable and powerful than client devices, and they are configured specifically to serve client requests. They store data and execute code on the backend so that clients do not have to store all the data they need or run compute-heavy functions. This enables users of client devices to easily browse the web and get whatever resources they need (code, video, images, etc.) from servers without having to permanently download all the web content they display.
In contrast, P2P is a networking architecture in which any connected device communicates directly with any other connected device. P2P reduces or eliminates the need for servers, allowing client devices to connect and exchange data with each other. Because all connected devices in a P2P architecture can fill the same function of sending or receiving data, they are called "peers" instead of clients.
Streaming protocols like HLS, HDS, and MPEG-DASH presume a client-server model, with a server storing or caching audiovisual content and then streaming it to clients. WebRTC, however, mainly uses a P2P model, in which clients stream directly to each other.
WebRTC is often better suited for live streaming for this reason. HLS and MPEG-DASH typically have a minimum of ten seconds of latency between the source of the stream and any stream viewers, while WebRTC is much closer to being instant. Set up low-latency live streaming.
(In actual production, WebRTC does incorporate servers in order to work properly, as described above.)
WebSocket is another commonly used protocol for real-time data exchange. There are a couple of key differences between WebRTC and WebSocket that lead many app developers to prefer WebRTC for low-latency live streaming:
Cloudflare Stream allows developers to easily build WebRTC streams into their apps, and Cloudflare Realtime includes prebuilt components for developers to build video, audio, and chat features into their apps. Both products serve streams from the Cloudflare global network, which, with over 335 global locations, is within milliseconds of almost every Internet user in the world.
See these instructions to set up a WebRTC stream with Cloudflare Stream.
View this reference architecture to start building with Cloudflare Realtime.
Most streaming technologies rely on a client-server model where data must first pass through a middleman server to be stored or processed before reaching the recipient. WebRTC primarily uses a peer-to-peer (P2P) architecture, allowing devices to exchange audio, video, and data directly with one another. This direct connection typically reduces the need for extensive backend infrastructure and significantly lowers latency.
The main advantage is speed. Standard protocols like HLS often have a delay of several seconds between the source and the viewer. Because WebRTC is designed for real-time interaction, it is closer to being truly live, making it a better fit for use cases like video conferencing or interactive live streams.
One of the primary benefits of WebRTC is that it is natively supported by almost all modern web browsers. Users can participate in high-quality communications without downloading additional plugins or third-party applications.
Before two devices can share media, they must agree on how to communicate. A signaling server facilitates this negotiation by helping the devices exchange information about their respective routing requirements, video codecs, and media resolutions.
Cloudflare provides tools like Stream and Realtime that allow developers to integrate WebRTC-based video, audio, and chat into their applications without managing their own infrastructure. These services utilize a global network to ensure streams stay within milliseconds of users worldwide and include managed TURN services to help stream to devices behind firewalls.