WebRTC is a set of browser APIs and related protocols for exchanging real-time audio, video and application data between compatible endpoints. It does not provide a standard signaling service: each application chooses how peers exchange the information needed to set up a connection.
The useful way to learn the terms is in the order a call uses them. A browser obtains media if needed, negotiates session details with a peer, tests network paths, and then sends media over a selected path; a multiparty application may add a forwarding intermediary.
WebRTC and the browser APIs
WebRTC stands for Web Real-Time Communication. It is not a single video-chat product or a complete calling application. It is a family of standardised browser interfaces and protocols that applications can use to build real-time communication, including audio, video and generic data exchange.
Two standards communities have distinct roles. The World Wide Web Consortium (W3C) specifies the browser-facing APIs. The Internet Engineering Task Force (IETF) specifies protocols used for communication between implementations. The APIs give an application ways to request media and configure a connection; protocols describe how endpoints can negotiate and carry it. The W3C WebRTC specification defines the JavaScript interfaces, while IETF RFC 8825 outlines the protocol architecture for browser-based real-time communication.
The browser APIs most often encountered are getUserMedia(), RTCPeerConnection and RTCDataChannel. They have different jobs. getUserMedia() requests local audio or video inputs, RTCPeerConnection configures and negotiates a connection, and RTCDataChannel provides a way for endpoints to exchange application data. A data channel is not another name for an audio or video track.
That distinction helps when reading documentation or debugging. A microphone permission problem belongs near media capture. A mismatch in negotiated media capabilities belongs near the peer connection and its session description. A text or application message sent outside the audio/video stream may use a data channel. These components can work together, but one does not automatically solve the responsibilities of the others.
WebRTC is broader than video calls. An application may use it for audio, video, or data, and can combine those functions according to its needs. The standards define building blocks; the application still supplies user experience, identity, call controls and the coordination path that lets endpoints find one another.
Local media and peer connections
When an application needs camera or microphone input, it can call getUserMedia(). The browser asks for permission and checks that the requested devices are available. Permission, device selection and capture are separate from getting a remote participant connected: a successful local capture does not prove that the network path to another peer will work.
Captured media is represented as tracks. A MediaStreamTrack represents one media source, such as camera video or microphone audio. A MediaStream groups zero or more tracks for use by an application. It is therefore better to think of a stream as a container than as one physical device; tracks can also represent conceptual sources, such as a composition or mix.
A calling application adds appropriate tracks to an RTCPeerConnection, the browser interface that manages the connection with another peer. It can also configure connection-related choices and obtain information about negotiation and connectivity. The peer connection does not itself mean that the other endpoint has already been located or reached. Those setup and path-selection tasks involve signaling and ICE.
This order is useful in practice. If your preview is blank, first check browser permission and whether the expected local track exists. If the preview works but the remote endpoint receives nothing, local capture may be fine and the issue may lie later in negotiation or connectivity. Keeping those stages separate prevents a common mistake: treating every failure as a camera or bitrate problem.
A browser-to-browser call is one use of these APIs, but the same concepts apply to other compatible endpoints. If you are comparing live video workflows rather than building a browser call, an article on streaming a pre-recorded video live from Android covers a different path: it is about sending a broadcast to YouTube, not establishing a WebRTC peer session.
Signaling, offer and answer
Before two peers can exchange media, their applications need to exchange setup information. That coordination is called signaling. WebRTC does not define a required signaling protocol, server or transport. An application might use a WebSocket service, another messaging channel, or a different design; the choice belongs to the application rather than to WebRTC's media transport.
Signaling commonly carries an offer, an answer, ICE candidates and call-control messages. The initiating peer creates an SDP offer describing the session parameters it would like to use. The other peer processes it and returns an SDP answer describing the compatible session it can accept. The application delivers those descriptions between peers through its signaling mechanism.
The offer and answer are not the video. They are negotiation information used to agree how the session can work. Likewise, signaling is not the audio/video transport. It is the coordination channel that helps peers exchange what they need to establish the media path. Once setup has progressed, media is carried using the negotiated transport over the path selected by connectivity checks.
This separation matters when diagnosing a call that never gets beyond “connecting”. If the application cannot deliver an offer or answer, the peers may never agree on a session. If the descriptions are exchanged but connectivity checks cannot find a working path, the problem is further along. A stable signaling channel does not guarantee that a media path will succeed, just as a possible media path does not make signaling unnecessary.
A practical call flow is therefore not a single “connect” event. The application creates a peer connection, creates and sends an offer, receives an answer, and exchanges connectivity information. Depending on the design, those messages may arrive in a different order or be bundled into application-specific events, but the roles remain distinct.
SDP and session details
SDP means Session Description Protocol. In WebRTC, an SDP offer or answer is a textual description containing session details such as media types, transport information, timing and codec capabilities. It is negotiation metadata, not a stream of audio or video and not a signaling server.
The codec information helps peers determine which media formats and parameters they have in common. A codec is an encoder/decoder format: one endpoint encodes media and the other decodes it. The offer and answer describe relevant capabilities so the endpoints can settle on compatible choices. There is no universally best codec in every situation; the useful choice depends on both ends' support and the requirements of the application.
SDP can look dense because it expresses several parts of a session in a compact form. You usually do not need to edit it by hand to understand its role. When a call fails after negotiation, comparing whether the offer and answer were exchanged can help separate a negotiation failure from later connectivity trouble. If a diagnostic log contains SDP, handle it as session information rather than as the call media itself.
Applications may also exchange ICE candidates separately as they are gathered. This is often called trickle ICE. The session description and the candidates are related setup information, but they are not identical: SDP describes the session, while candidates propose ways to reach the peer. The application carries both through signaling according to its design.
For readers whose practical goal is a YouTube loop rather than a browser call, codec and session negotiation are not the same as broadcast encoding choices. A YouTube Live aspect-ratio guide addresses the shape of a broadcast picture, while WebRTC SDP describes details exchanged between endpoints in a real-time session.
ICE candidates, STUN and TURN
ICE stands for Interactive Connectivity Establishment. It is the framework peers use to gather and test possible network paths. An ICE candidate is a proposed way to connect, with addressing and transport details. Peers exchange candidates through their application's signaling mechanism, then test candidate pairs to find a working route.
A candidate is not a guarantee that a route will work. It is a possibility to check. A network may permit a direct path between peers, or restrictions involving firewalls and Network Address Translation (NAT) may prevent that route. NAT lets devices on a local network share a public-facing address, which is one reason discovering and checking paths can take more than simply knowing each device's local address.
STUN and TURN have different roles. STUN can help a peer discover the network-facing address associated with it, information that can help ICE form candidate paths. STUN does not relay the call's media. TURN is a relay service that forwards traffic when direct connectivity is not available or does not succeed. The IETF's STUN specification, RFC 8489, describes STUN; RFC 8656 specifies TURN.
| Connectivity outcome | What happens | Practical trade-off |
|---|---|---|
| Direct candidate pair works | Peers exchange media over a direct path | Avoids a TURN relay hop, but depends on the network allowing the path |
| TURN-relayed path works | A relay forwards traffic between peers | Can reach peers when direct connectivity fails, with an intermediary path and additional network overhead |
ICE tests the available possibilities rather than assuming that one route always works. A direct path may be preferable when it succeeds, but a relay is important for reachability on restrictive networks. The extra relay path has a cost in network use and an additional hop; whether that matters depends on the call and deployment. Do not assume that every WebRTC call is direct peer-to-peer.
If a call works on one network but not another, that difference can be a clue. A restrictive office or mobile network may affect candidate checks differently from a home connection. Application operators should look at candidate gathering and selected-pair diagnostics where available, and check that the application has a working relay option for the networks it needs to support. A camera preview alone cannot reveal whether those network paths are viable.
Secure media transport
Once the session is negotiated and ICE has selected a working path, media packets travel using RTP, the Real-time Transport Protocol. RTCP, the RTP Control Protocol, works alongside it for control and reporting. They are complementary parts of the media transport, not competing choices: RTP carries media packets, while RTCP supports control and reporting about the communication.
The path chosen by ICE may be direct or relayed through TURN. That route describes where packets travel; it does not change the basic distinction between RTP media and RTCP control. Similarly, SDP describes the negotiated session and signaling delivered the setup information, but neither one is the media packet flow.
WebRTC protocols include security mechanisms for media transport; implementation details and configuration depend on the specifications and application. For a reader, the essential glossary distinction is that “secure transport” describes protections on communication, whereas signaling is the application’s setup channel. Do not infer from the word WebRTC alone that a particular application has handled every security, account or privacy concern. Those choices remain relevant at the application level.
A useful mental model is a sequence of separate layers: the browser captures tracks, the application coordinates the negotiation, SDP records session details, ICE finds a path, and RTP/RTCP carry and support the media exchange on that path. If you are instead keeping a prerecorded broadcast running overnight, the spare-PC YouTube radio guide concerns a persistent broadcast workflow, not the peer media transport described here.
SFUs and multiparty forwarding
A direct peer connection is easiest to picture with two endpoints. In a multiparty call, connecting every participant directly to every other participant can make each sender handle several outgoing media paths. Many conferencing systems instead use an intermediary called an SFU, or Selective Forwarding Unit; related terminology includes Selective Forwarding Middlebox (SFM).
An SFU receives media streams and forwards selected streams to recipients. It is not necessarily mixing everyone into one composite video. Forwarding can let the application choose which participants' streams a recipient receives, rather than requiring each sender to create a separate stream for every other participant. The SFU requires its own forwarding capacity and application design, so it changes where work happens rather than making work disappear.
Simulcast is a technique where a sender supplies multiple simultaneous encodings of the same video source, with different resolutions and bitrates. An SFU can select a suitable layer for each recipient's device or network conditions. A participant on a constrained connection may receive a lower-resolution version while another can receive a more detailed one, when the application and endpoints support that arrangement.
Mesh and SFU approaches therefore have different trade-offs. In mesh, participants send media to one another directly, increasing the upload work each sender may need to do as the group grows. With an SFU, senders can provide streams to an intermediary which forwards selected versions, but the application must operate and plan for that forwarding service. The appropriate design depends on expected group size, network conditions, quality goals and operational requirements; there is no universal answer on cost, latency or privacy without those deployment details.
If you are learning WebRTC to understand a call, remember the forwarding point: SFU is an application architecture commonly used for multiparty sessions, not a required component of every WebRTC connection. The same standards-based APIs and transport concepts can be used in a two-peer call without an SFU. When the participants, streams or recipient capabilities vary, forwarding and simulcast give the application more ways to manage what each endpoint receives.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
What is WebRTC?
WebRTC is a set of browser APIs and related protocols for real-time audio, video and application data between compatible endpoints. It is broader than any one video-chat application, and the application must provide its own signaling approach.
What is an ICE candidate?
An ICE candidate is a proposed network path to a peer, including addressing and transport details. Peers exchange candidates and test candidate pairs to discover a working route, which may be direct or use a relay.
What are STUN and TURN servers?
STUN can help a peer discover a network-facing address for connectivity checks; it does not relay the media. TURN is the relay service that forwards traffic when a direct route cannot be established, adding an intermediary path and network overhead.
Is SDP the video stream?
No. SDP is a text-based session description used to negotiate details such as media types and codec capabilities. The media itself is carried after negotiation over the selected transport path.