Choose a live-stream transport: MoQ vs HLS vs WebRTC

Written by Cedric Verstraeten Created Aug 19, 2026 Updated Aug 19, 2026

Live video has no single best transport. The right choice depends on what you are optimizing: the shortest delay, the largest audience, the strictest corporate network, or interactive audio.

This tutorial compares Media over QUIC (MoQ), HTTP Live Streaming (HLS) and WebRTC as they are used by Kerberos Hub. You will turn product requirements into a transport choice, then validate that choice on the network where it will run.

The short answer

Understand the three paths

All three options deliver the same camera video, but they organize the path differently. Each diagram below is interactive and can be opened in the architecture designer with Edit.

MoQ: real-time publish and subscribe

MoQ carries media over QUIC and WebTransport. The Agent publishes a broadcast to a relay and viewers subscribe to it. This separates the producer from the viewers: the Agent does not negotiate a peer connection with every browser, and the relay can fan one publication out to several subscribers.

The relay has an https:// URL, but that does not make this a TCP path. HTTP is the application protocol: HTTP/1.1 and HTTP/2 normally run over TCP, while the WebTransport used here runs over HTTP/3, which maps HTTP onto QUIC over UDP. If a network blocks UDP or HTTP/3, the current MoQ player cannot silently fall back to HTTPS over TCP; use HLS for that network.

The important benefits are:

• Low delay without a peer-to-peer topology. Media remains frame-oriented rather than waiting for complete HLS segments.
• Efficient fan-out. Adding viewers is primarily a relay concern instead of adding one direct Agent-to-browser path per viewer.
• Live-edge behavior. A real-time player can skip data that is already too old instead of making delay grow without bound.
• Independent delivery. QUIC avoids TCP head-of-line blocking between independent streams, although loss and congestion still affect playback.

In the current Kerberos implementation, the Agent publishes separate high- and low-quality H.264 broadcasts only while they are being watched. Hub playback uses WebTransport and WebCodecs and currently targets Chromium-based browsers. The initial path is video-only, so it does not replace WebRTC’s talk channel.

MoQ is the strongest candidate when you need near-real-time video for multiple viewers and control the browser environment. Its costs are a relay, a newer operational toolchain, HTTP/3/UDP network access and a less mature browser ecosystem.

HLS: compatibility and distribution

HLS packages video into a rolling playlist of fMP4/CMAF segments. The Agent pushes the live segments to Hub, and browsers fetch the playlist and media over HTTPS.

Its benefits come from using the web delivery path almost every network already understands:

• Firewall and proxy compatibility. HLS uses ordinary authenticated HTTPS requests without ICE, STUN, TURN or peer-to-peer connectivity.
• Shared delivery. Multiple viewers can fetch the same media session instead of opening a new media path back to the Agent.
• Operational familiarity. HTTP logs, reverse proxies and common observability tools can inspect the delivery path.
• Large-audience scaling. HLS is naturally compatible with caching and CDN-style distribution, although Kerberos Hub serves authenticated live playlists directly by default.

The cost is delay. A player needs enough segment or partial-segment data to decode smoothly, so HLS normally trails the live edge by seconds rather than frames. It is also one-way: Hub’s two-way talk feature is unavailable on HLS.

Choose HLS when a stream must work through restrictive enterprise networks, when broad playback compatibility is more important than immediacy, or when viewers greatly outnumber publishers.

WebRTC: interaction and mature real-time media

WebRTC is designed for live, bidirectional communication. In Hub, the Agent and browser exchange session descriptions and ICE candidates over MQTT. Media then flows directly when possible, with a TURN relay as the fallback when NAT or firewall rules prevent a peer-to-peer path.

WebRTC provides:

• The lowest interactive delay. It is designed to keep conversation and control responsive.
• Two-way media. In Hub, this is the only transport that supports the camera talk back-channel.
• Mature adaptation. Congestion control, jitter buffering, retransmission strategies and network statistics are established parts of the ecosystem.
• Direct delivery. A successful peer-to-peer path avoids routing media through Hub infrastructure.

That direct model has a scaling consequence: each viewer establishes a media session, and each relayed viewer consumes TURN capacity. WebRTC also asks more of the network than HLS because ICE, UDP reachability, NAT traversal and TURN credentials all have to work.

Choose WebRTC when interaction matters, viewer counts per camera are modest, or two-way talk is a requirement rather than a bonus.

Compare the operational tradeoffs

No transport removes the need for capacity planning. MoQ and HLS centralize fan-out, so their relay or Hub egress must be sized for all viewers. WebRTC can distribute that load across direct paths, but TURN becomes the central bottleneck whenever direct connectivity fails.

Give the firewall team the transport rules

Start with the connections every mode uses. These ports are independent of the selected media transport:

All rules below are egress rules with stateful return traffic unless the destination service is hosted behind a firewall you manage. Do not open a fixed inbound port on an Agent or camera. Replace example hostnames and ports with the values from the deployment.

MoQ firewall rules

For the default relay at https://relay.uug.ai/anon, add:

MoQ adds no TCP media port and uses no peer-to-peer path, STUN server, TURN server or TURN relay port range. A TLS-inspecting HTTP proxy does not automatically make MoQ work because it may only proxy HTTP/1.1 or HTTP/2 over TCP. The network must permit direct QUIC/HTTP/3 traffic over UDP 443 to the relay.

If you self-host the relay on a different port, replace UDP 443 with the explicit port in moqRelayUrl and AGENT_LIVE_MOQ_URL, and expose that UDP port on the relay or load balancer.

HLS firewall rules

HLS adds no UDP requirement. In addition to the common Hub and MQTT rules, allow:

The browser-to-Hub rule is normally already covered by the common Hub HTTPS rule. HLS is therefore the simplest option for an HTTPS-only network: all media crosses TCP 443, while MQTT/WSS carries only requests and readiness signals on its configured TCP port.

WebRTC firewall rules

WebRTC uses MQTT for signalling, then ICE chooses either a direct media path or TURN. Add rules for the deployment’s configured AGENT_STUN_URI, AGENT_TURN_URI and Hub turn.host:

There is no universal TURN port in Kerberos configuration. The Helm example uses turn.yourdomain.com:8443; the Agent defaults reference 3478. Use the actual configured value, and include the transport requested by the TURN URI or server policy.

When you operate coturn yourself, its public firewall must also expose the TURN listener and the configured UDP relay port range. Coturn defaults that range to 49152-65535 when min-port and max-port are not set; production deployments often narrow it explicitly. If the site firewall cannot permit dynamic peer UDP, set AGENT_FORCE_TURN=true and allow the TURN paths instead, accepting the added relay bandwidth and latency.

Make the decision

Work through these questions in order. A hard requirement should eliminate transports before you compare softer benefits.

Apply the choice in Hub

The Hub Helm chart exposes the transports under kerberoshub.frontend.features.liveview. This example offers all three choices and starts Live mode with MoQ:

kerberoshub:
  frontend:
    features:
      liveview:
        liveStreamMode: "moq"
        hlsEnabled: "true"
        moqEnabled: "true"
        moqRelayUrl: "https://relay.example.com"
        moqBroadcastPrefix: "devices"

Use webrtc, hls or moq for liveStreamMode. The transport selector remains available when HLS or MoQ is enabled, so operators can override the default for an individual stream.

MoQ also has an Agent-side requirement. AMD64 and ARM64 Agent images include the publisher, but it remains opt-in:

AGENT_LIVE_MOQ_ENABLED=true
AGENT_LIVE_MOQ_URL=https://relay.example.com
AGENT_LIVE_MOQ_BROADCAST_PREFIX=devices

The Agent and frontend must use the same relay and broadcast prefix. Production relays should issue short-lived, subscriber-scoped credentials; do not treat an anonymous relay endpoint as an authorization boundary.

To run the relay yourself, follow Deploy a MoQ relay on Kubernetes. It covers TLS, the UDP LoadBalancer, Hub values, Agent variables and end-to-end verification.

For the other production paths, follow Set up WebRTC live view with TURN or Set up HLS live view. Both guides cover Hub values, Agent requirements, firewall rules, diagnostics and a complete fallback-path test.

For the complete Hub live-view flow and troubleshooting steps, continue with Live view.