Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/openlibrecommunity/olcrtc/llms.txt

Use this file to discover all available pages before exploring further.

olcRTC supports four wire transports (datachannel, vp8channel, seichannel, videochannel) and three signaling providers (jitsi, telemost, wbstream). Not every combination is stable — some providers strip or block certain media types, and others require special account privileges for data routing. The matrix below summarises the current state from the E2E test suite.

Compatibility Matrix

Transporttelemostwbstreamjitsi
datachannel
vp8channel
seichannel
videochannel
Legend:
SymbolMeaning
Works — passes E2E tests
Does not work / not supported — fails E2E tests
Unstable — may work, result flaps between CI runs

Provider Details

datachannel — ✓ StableDatachannel on Jitsi is implemented on top of the colibri-ws bridge channel. Data is sent as an EndpointMessage{raw} broadcast. This works on any self-hosted or public Jitsi Meet instance without authentication (e.g. https://meet.jit.si/...). Check which instance is reachable in your network by opening it in a browser before configuring.vp8channel, seichannel, videochannel — ◑ UnstableVideo transports expose a sendable VideoTrack through the pion PeerConnection after the Jingle session-accept, but Jicofo requires additional protocol steps (LastN, ReceiverVideoConstraints, source-add) to actually route video between participants. This is why all three video-based transports are marked unstable on Jitsi.
Jitsi + seichannel — separate caveat. SEI NAL units ride inside the H.264 video stream. On some self-hosted Jitsi instances (e.g. meet.egovm.ru), Jicofo periodically cuts or delays upstream video when there is formally no receiver in the room. From olcRTC’s perspective this looks like a seichannel ack timeout even though the PeerConnection is formally alive. In steady state the transport works, but it flaps — a green or red CI result is enough for the test suite. For reliable data transfer over Jitsi, prefer datachannel or vp8channel.
# Stable Jitsi config
auth:
  provider: jitsi
room:
  id: "https://meet.example.org/my-room"
net:
  transport: datachannel

Required YAML Fields

Regardless of provider or transport, these fields are always required:
YAML FieldWhat to Enter
modesrv on the server, cnc on the client, gen to generate a room ID
auth.providerjitsi, telemost, wbstream, or none
net.transportdatachannel, vp8channel, seichannel, or videochannel
room.idRoom ID or URL (must match on server and client)
crypto.key or crypto.key_fileEncryption key — 64 hex chars (32 bytes). Generate: openssl rand -hex 32
dataAlways set to data
net.dnsDNS resolver, e.g. 8.8.8.8:53

Speed Ranking

Transports differ significantly in throughput. From fastest to slowest:

datachannel

Fastest. Direct SCTP over WebRTC data channel. No encoding overhead.

vp8channel

Fast. Data tunnelled inside VP8 video frames.

seichannel

Moderate. Data in SEI NAL units inside H.264. ACK-based reliability adds latency.

videochannel

Slowest. Requires ffmpeg for encode/decode. Most broadly compatible.

Best overall: jitsi + datachannel — stable on any self-hosted or public Jitsi Meet instance, needs no registration, and room creation is instant (just pick a URL). Check which Jitsi instance is reachable in your network using a browser before configuring.Best for commercial / production: wbstream + vp8channel — stable, no special token rights needed in the guest flow, works reliably with WbStream’s infrastructure.

Build docs developers (and LLMs) love