WebRTC, SFUs, and Voice Codecs Explained

WebRTC moves audio and video between browsers, a codec such as Opus compresses voice so it fits on the wire, and a Selective Forwarding Unit (SFU) is a server that forwards each participant's video to everyone else in larger calls. Those three pieces explain most of what happens between a microphone and a remote speaker.

This guide is for developers and curious readers who want the mechanics: signaling, ICE, STUN and TURN, RTP, Opus, and the trade-off between a peer-to-peer mesh and an SFU. It ends with how Voxal combines them: voice stays peer-to-peer, while camera and screen sharing can use an SFU. If you only want the concept, start with what peer-to-peer voice chat is.

1. What is WebRTC?

WebRTC is a collection of standards and browser APIs for real-time audio, video, and data communication.

It allows applications to establish media connections between compatible devices without requiring developers to implement every transport and security mechanism from scratch.

WebRTC is not a single protocol. Several components work together.

Signaling

Before two devices can establish a media connection, they need to exchange information about the session and their connection capabilities.

This process is called signaling. Applications choose their own signaling mechanism; WebRTC does not prescribe one universal signaling server or signaling protocol.

Voxal uses signaling to coordinate room membership and connection establishment. Its signaling path is separate from the media path.

ICE, STUN, and TURN

Devices are frequently behind routers, firewalls, or network address translation (NAT). Discovering a workable connection path can therefore be more complicated than connecting two public IP addresses.

WebRTC uses Interactive Connectivity Establishment (ICE) to gather and test possible connection paths.

STUN helps a device discover how it appears from the public network.
TURN provides a relay path when a suitable direct connection cannot be established.

A TURN relay forwards encrypted media traffic. It is not the same thing as an SFU, which terminates media connections and selectively forwards media streams.

A direct connection is often desirable, but a relay can be essential for connectivity.

RTP and secure media transport

Real-time media is commonly transported using the Real-time Transport Protocol (RTP), alongside RTCP for control and reporting.

WebRTC uses secure RTP (SRTP) for media protection. The transport layer helps deliver packets, while the codec determines how the audio or video itself is represented.

These are distinct responsibilities: a codec does not establish a network connection, and a network connection does not determine how sound is compressed.

2. What is a voice codec?

A codec encodes and decodes media. For voice communication, its job is to represent speech efficiently while preserving intelligibility and acceptable audio quality.

Without compression, transmitting raw audio can consume considerably more bandwidth than a voice application needs.

A codec makes a trade-off between several factors:

Audio quality and speech intelligibility.
Bitrate and bandwidth usage.
Encoding and decoding complexity.
Delay and frame duration.
Behaviour under changing network conditions.

There is no single best codec for every application. Music streaming, telephone calls, gaming chat, and real-time group conversations have different priorities.

Diagram of a microphone sending a raw voice waveform through an Opus codec chip into a low-bitrate stream, with gauges for quality, bitrate, and latency. — The Opus codec compresses raw voice into a low-bitrate stream, balancing audio quality, bandwidth use, and delay.

Why Opus is widely used

Opus is an interactive audio codec designed for applications such as voice over IP, video conferencing, and in-game chat.

It supports a wide range of bitrates, sampling rates, and frame durations. This flexibility makes it suitable for both speech and more demanding audio applications.

Opus is also a required-to-implement audio codec for WebRTC endpoints under the WebRTC audio codec requirements.

That does not mean every WebRTC connection always uses Opus. Actual codec selection depends on the capabilities negotiated by the participating endpoints.

In Voxal, the browser's WebRTC audio pipeline uses Opus by default in the documented architecture. The browser handles much of the underlying encoding, transport, and decoding work.

For a real-time voice application, the codec is only one part of the experience. Microphone quality, audio processing, packet loss, network latency, jitter buffering, and device playback all matter as well.

3. What is an SFU?

SFU stands for Selective Forwarding Unit.

An SFU is a media server commonly used to support group video calls. Instead of requiring every participant to send a separate video stream directly to every other participant, each participant can send media to the SFU, which forwards appropriate streams to the other participants.

Imagine a room with six people, each sending a camera stream.

In a full peer-to-peer mesh, each participant may need to upload their outgoing video to five other participants. In a server-forwarded topology, each participant can send a stream to the SFU, which handles distribution.

This can significantly reduce the number of separate outgoing video streams a participant must maintain.

What does an SFU actually do?

An SFU typically receives encoded media streams and selectively forwards them. Depending on the implementation and negotiated features, it may choose which streams or quality layers to send to each receiver.

For example, a participant viewing a small thumbnail may not need the same video quality as someone displaying a speaker full-screen.

An SFU can help manage these different requirements without every sender independently transmitting a separate stream to every recipient.

However, an SFU is not free. It introduces infrastructure, server bandwidth, operational costs, and another component in the media path.

An SFU also has a different privacy model from a TURN relay. Because an SFU terminates media transport and forwards media selectively, it can technically access the media it receives. Encryption between a participant and an SFU does not, by itself, provide end-to-end confidentiality from that SFU.

4. Peer-to-peer mesh vs. SFU

The two architectures solve related but different problems.

Diagram comparing a full mesh, where every participant connects to every other participant, with SFU forwarding, where each participant sends one stream to a central server. — In a full mesh every participant maintains a connection to every other participant. With an SFU, each participant sends one stream to the server, which forwards it to everyone else.

Peer-to-peer mesh

Each participant establishes media connections with the other participants.

Advantages:

Direct media paths are possible.
No central media server is required to redistribute media.
Small rooms can work without a media-forwarding service.

Trade-offs:

Each sender may need to upload a separate stream to every other participant.
The number of media connections grows as the room grows.
Upload bandwidth and connection management can become limiting factors.

SFU-based distribution

Each participant sends media to a central forwarding service, which distributes it to the other participants.

Advantages:

More efficient distribution for many group-video scenarios.
Less need for each sender to upload separate copies to every recipient.
More control over which video streams and quality layers receivers get.

Trade-offs:

Additional server infrastructure and bandwidth costs.
An intermediary enters the media path.
The privacy and trust model differs from direct peer-to-peer communication.

The key is not to assume that one topology must be used for every media type. Audio and video have different traffic patterns and requirements.

5. Why Voxal keeps voice peer-to-peer but can use an SFU for video

Voxal separates voice audio from camera and screen-sharing video.

Voice audio always remains peer-to-peer. It is never routed through the optional video SFU.

This is a deliberate architectural decision: voice is the core communication feature, and Voxal does not use the SFU as a central audio-distribution service.

Camera and screen-sharing video are different. In larger rooms, a full peer-to-peer mesh can require each participant to upload multiple video streams. That becomes increasingly demanding as the number of participants grows.

Voxal can therefore use Cloudflare's Realtime SFU for video and screen sharing when the configured routing preference allows it and the room exceeds the practical limits of the mesh.

The routing preference matters:

Allow relay for large rooms: Voxal can use the SFU when the room grows beyond a comfortable peer-to-peer video topology.
Prefer direct: Voxal tries peer-to-peer first and asks before allowing a relay when the mesh becomes unsuitable.
Direct only: Video and screen sharing never use the SFU, even if a large room struggles to establish all direct connections.

These settings affect video and screen sharing, not voice audio.

Diagram showing voice audio traveling directly between two participants while camera video is forwarded through a video SFU. — Voxal separates the two media types: voice audio always flows directly between peers, while camera and screen-sharing video can be forwarded through an SFU in larger rooms.

Why not route everything through the same server?

Because the best topology depends on the traffic being transported.

A voice stream is generally much smaller than a camera stream. Sending voice through a central forwarding service would introduce a different infrastructure and privacy trade-off without being necessary for Voxal's chosen voice architecture.

Video has a more demanding bandwidth profile and can benefit substantially from server-assisted distribution as group size grows.

Separating the two lets Voxal retain its peer-to-peer voice model while offering a more scalable option for group video.

6. What this means for privacy

Networking terms are sometimes used as if they automatically guarantee a particular level of privacy. They do not.

Peer-to-peer audio means that voice media is not routed through a central media server, but signaling servers may still coordinate connections and process associated metadata.

A TURN relay forwards encrypted media without decoding it. An SFU, by contrast, terminates media transport to selectively forward streams and can technically access the video it receives.

This is why Voxal's distinction matters:

Voice remains peer-to-peer, optionally using an encrypted TURN relay.
Camera and screen-sharing video may use an SFU in larger rooms, depending on the routing preference.
Local virtual-background processing happens on the sender's device, but that alone does not mean every video connection is direct.

Understanding the actual media path is more useful than simply describing an application as serverless.

7. Putting it all together

A real-time communication application combines several independent layers:

Signaling coordinates participants and connection setup.
ICE, STUN, and TURN help establish a viable network path.
WebRTC and secure RTP transport carry real-time media.
A codec such as Opus represents the audio efficiently.
The network topology determines whether media flows directly between peers or through a forwarding service.

Voxal's design applies these choices separately to voice and video. The result is a voice-first architecture in which audio remains peer-to-peer, while video and screen sharing can use optional server-assisted forwarding when larger rooms need it.

These distinctions are important when designing any real-time communication system. The goal is not simply to minimise servers or maximise direct connections; it is to make deliberate trade-offs between latency, bandwidth, reliability, scalability, and privacy.

Try Voxal

Voxal combines peer-to-peer voice chat, push-to-talk, hands-free mode, noise suppression, and optional video and screen sharing.

Try Voxal in your browser, or explore the implementation in the open-source Voxal repository.