olcRTC: Auth Providers and Transport Modes Explained

olcRTC has a two-layer architecture. The auth provider (auth.provider) decides which service hosts the WebRTC room and how credentials are obtained. The transport (net.transport) decides how tunnel bytes are placed inside that WebRTC session. You pick one provider and one transport independently, then combine them based on what works in your network.

SOCKS5 client
  → olcrtc cnc  (auth provider + transport)
    → WebRTC/SFU service
      → olcrtc srv
        → internet

Auth Providers

jitsi
telemost
wbstream
none (direct engine)

Jitsi

Field	Value
`auth.provider`	`jitsi`
Engine	`jitsi` (`internal/engine/jitsi`)
Registration	None required
Room ID format	Full URL: `https://<host>/<room>`

The Jitsi provider joins a Jitsi MUC via the XMPP/Jingle/colibri-ws stack. It parses the room URL you supply, extracts the host and room name, and connects using the zarazaex69/j library.Key behaviour: Jitsi’s Jicofo conference controller only sends a Jingle session-initiate once at least one other participant is present. This means both srv and cnc must be running and in the same room before the tunnel is established. If you open a room URL in a browser first, Jicofo may remove the empty conference. Let olcRTC itself be the first two participants.Public instances: A list of public Jitsi Meet instances is maintained in docs/examples/jitsi.instances.yaml in the repository. Any self-hosted Jitsi Meet instance without authentication also works — use the full URL https://HOST/ROOM.

Always test which Jitsi instance is reachable in your network before deploying. Open the instance URL in a browser; if the page loads, the host is accessible. Different instances may be blocked differently depending on your ISP or country.

Minimal config (server):

mode: srv
auth:
  provider: jitsi
room:
  # Check docs/examples/jitsi.instances.yaml for public instances
  id: "https://meet.example.org/REPLACE_ME_WITH_ROOM_ID"
crypto:
  key: "REPLACE_ME_WITH_64_HEX_CHARS"
net:
  transport: datachannel
  dns: "8.8.8.8:53"
data: data

Telemost (Yandex)

Field	Value
`auth.provider`	`telemost`
Engine	`goolom` (`internal/engine/goolom`)
Registration	Separate registration required (Yandex account)
Room ID	Obtained from Yandex Telemost

Telemost uses the Yandex Telemost API and the Goolom signaling engine. Credentials are obtained via the Yandex Telemost credential flow. Create a room through the Telemost service and use its room ID.Important transport restrictions:

datachannel — does not work (removed from Telemost)
seichannel — not supported
vp8channel — ✅ recommended
videochannel — works but is slow

Recommended config:

mode: srv
auth:
  provider: telemost
room:
  id: "<room-id>"
crypto:
  key: "<hex-key>"
net:
  transport: vp8channel
  dns: "8.8.8.8:53"
vp8:
  fps: 30
  batch_size: 64
data: data

WbStream

Field	Value
`auth.provider`	`wbstream`
Engine	`livekit` (`internal/engine/livekit`)
Registration	Separate registration required
Room ID	Created on the WbStream service site (`stream.wb.ru`)

WbStream uses the LiveKit SFU protocol via the upstream livekit/server-sdk-go client. The auth package acquires credentials via the WbStream API. Rooms must be created manually through the service web interface.Guest flow limitation: In the normal guest flow, WbStream issues tokens with canPublishData=false. This means datachannel opens the SCTP channel but routes no bytes — the tunnel appears up but is silent.

WbStream + datachannel does not work in the normal guest flow. WbStream issues tokens with canPublishData=false for guests, which prevents data from being routed over the data channel. Use vp8channel, seichannel, or videochannel instead. To use datachannel, you must set auth.token to a moderator account token (canPublishData=true) on both sides.

To grant moderator rights in the WbStream UI: open the participants list → click the three dots next to the client/server entry → press Moderator (required on both sides).You can also use auth.token in your YAML to supply a pre-issued account/moderator token directly:

auth:
  provider: wbstream
  token: "<your-account-token>"

In the guest flow, the obtained token is logged once so you can copy it back into auth.token.Recommended config (guest flow):

mode: srv
auth:
  provider: wbstream
room:
  id: "<room-id-from-stream.wb.ru>"
crypto:
  key: "<hex-key>"
net:
  transport: vp8channel
  dns: "8.8.8.8:53"
vp8:
  fps: 30
  batch_size: 64
data: data

None — Direct Engine Mode

Field	Value
`auth.provider`	`none`
Engine	Set in `engine.name`
Registration	Depends on the engine

When auth.provider: none, olcRTC skips the built-in auth provider and connects directly using the engine parameters you supply:

YAML field	Description
`engine.name`	Engine name: `livekit`, `goolom`, or `jitsi`
`engine.url`	Signaling URL for the engine
`engine.token`	Access token for the engine

This is useful when you have a self-hosted LiveKit instance or when you manage credential acquisition externally.

mode: srv
auth:
  provider: none
engine:
  name: livekit
  url: "wss://my-livekit.example.com"
  token: "<my-livekit-token>"
room:
  id: "my-room"
crypto:
  key: "<hex-key>"
net:
  transport: vp8channel
  dns: "8.8.8.8:53"
data: data

Engines (Internal)

The engine is the low-level SFU/signaling implementation. You normally select the engine implicitly by choosing a provider. The term carrier may appear in logs as a historical synonym for the chosen auth/provider path.

Engine	Package	Capabilities	Used by
`livekit`	`internal/engine/livekit`	Data packets, video tracks via LiveKit SDK	`wbstream`, `none`
`goolom`	`internal/engine/goolom`	Telemost/Goolom signaling, publisher/subscriber PeerConnection	`telemost`
`jitsi`	`internal/engine/jitsi`	Jitsi MUC/Jingle/colibri-ws, datachannel + video tracks via pion	`jitsi`

internal/engine/builtin binds auth.provider to the correct engine at runtime.

Transports

datachannel
vp8channel
seichannel
videochannel

datachannel

The datachannel transport uses the engine’s native byte/data path. For the Jitsi engine this is the colibri-ws bridge channel (EndpointMessage{raw} broadcast over the JVB WebSocket). For LiveKit this is the data packet API (PublishDataPacket).

Property	Value
Mechanism	Native byte path of the engine
Reliability	Reliable, ordered
Max payload	12 KiB per message
Extra YAML fields	None

When to use: datachannel is the simplest and fastest transport. It has the lowest latency and is the recommended starting point with Jitsi.

WbStream + datachannel does not work in the normal guest flow. Guest tokens have canPublishData=false. The SCTP data channel opens, but data is silently dropped. Use vp8channel, seichannel, or videochannel with WbStream unless you have a moderator token.

No extra YAML configuration is needed:

net:
  transport: datachannel

vp8channel

The vp8channel transport disguises a KCP-based byte stream as a sequence of VP8 video frames. Every outgoing frame is prefixed with a valid VP8 keyframe header so the SFU passes bitstream validation. KCP provides ordered, reliable delivery on top of the RTP video track.

Property	Value
Mechanism	KCP over VP8-like video frames
Reliability	Reliable, ordered (KCP)
Max payload	60 KiB per message
Extra YAML fields	`vp8.fps`, `vp8.batch_size`

When to use: vp8channel is the primary video-path transport and works well with Telemost and WbStream. It is the recommended alternative when datachannel is not available.Recommended settings:

YAML field	Recommended	Default	Description
`vp8.fps`	`30`	`30`	VP8 stream FPS. Lower FPS reduces CPU load
`vp8.batch_size`	`64`	`64`	Frames coalesced per tick. Larger = higher throughput

net:
  transport: vp8channel
vp8:
  fps: 30
  batch_size: 64

vp8channel is stable with both wbstream and telemost. For Jitsi it is marked unstable (~) because Jicofo requires extra protocol steps (LastN, ReceiverVideoConstraints, source-add) to route video — use datachannel with Jitsi instead.

seichannel

The seichannel transport embeds payload bytes inside H.264 SEI (Supplemental Enhancement Information) NAL units. It includes its own ACK/retry mechanism on top of the video track.

Property	Value
Mechanism	Payload in H264 SEI NAL units with ACK/retry
Reliability	Reliable (ACK/retry at the transport layer)
Extra YAML fields	`sei.fps`, `sei.batch_size`, `sei.fragment_size`, `sei.ack_timeout_ms`

When to use: seichannel works with WbStream and is a fallback option. Telemost does not support it (fails E2E tests). Jitsi is marked unstable — Jicofo on self-hosted instances may cut or delay upstream video when there is no active receiver, causing seichannel ack timeout errors while the PeerConnection is formally alive.Recommended settings:

YAML field	Recommended	Default	Description
`sei.fps`	`30`	`30`	H264 stream FPS
`sei.batch_size`	`64`	`64`	Frames per tick
`sei.fragment_size`	`900`	`900`	Fragment size in bytes
`sei.ack_timeout_ms`	`2000`	`2000`	ACK timeout in milliseconds

net:
  transport: seichannel
sei:
  fps: 30
  batch_size: 64
  fragment_size: 900
  ack_timeout_ms: 2000

videochannel

The videochannel transport encodes data as visual QR codes or tile patterns inside actual video frames generated by ffmpeg. It includes ACK/retry for reliability.

Property	Value
Mechanism	QR/tile frames via ffmpeg with ACK/retry
Reliability	Reliable (ACK/retry at the transport layer)
Requires	`ffmpeg` installed (or path set via `ffmpeg:` YAML field)
Extra YAML fields	`video.*` block
Status	Experimental

Two codecs:

qrcode — encodes data as QR codes; works at any supported resolution
tile — encodes data as pixel tiles; requires exactly 1080×1080 resolution

When to use: videochannel works with WbStream and Telemost. It is the slowest transport and is considered experimental. Use it as a last resort when other transports are unavailable.Recommended settings:

YAML field	Recommended	Default	Description
`video.codec`	`qrcode`	`qrcode`	`qrcode` or `tile`
`video.width`	`1080`	`1920`	Width in pixels
`video.height`	`1080`	`1080`	Height in pixels
`video.fps`	`30`	`30`	FPS
`video.bitrate`	`"5000k"`	`"2M"`	Bitrate, e.g. `"5000k"` or `"2M"`
`video.hw`	`none`	`none`	`none` or `nvenc`
`video.qr_recovery`	`low`	`low`	QR error correction level
`video.qr_size`	`0`	`0`	QR fragment size (0 = auto)
`video.tile_module`	`4`	`4`	Tile size in pixels 1..270 (`tile` only)
`video.tile_rs`	`20`	`20`	Reed-Solomon parity % 0..200 (`tile` only)
`ffmpeg`	(path)	`ffmpeg`	Path to the ffmpeg executable

net:
  transport: videochannel
video:
  codec: qrcode
  width: 1080
  height: 1080
  fps: 30
  bitrate: "5000k"
  hw: none

Compatibility Matrix

Transport	telemost	wbstream	jitsi
`datachannel`	❌	⚠️	✅
`vp8channel`	✅	✅	⚠️
`seichannel`	❌	✅	⚠️
`videochannel`	✅	✅	⚠️

Legend:

✅ Works (passes E2E tests)
❌ Does not work / not supported (fails E2E tests)
⚠️ Unstable (may work, may not)

Notes:

telemost datachannel: DataChannel was removed from Telemost.
telemost seichannel: Not supported by Telemost.
wbstream datachannel: Fails in guest flow (canPublishData=false); requires a moderator token to work.
jitsi video transports: Jicofo requires additional protocol steps to route video — unstable in practice; prefer datachannel or vp8channel with Jitsi.

Speed Ranking

From fastest to slowest:

Rank	Transport	Reason
1	`datachannel`	Direct native byte path, no encoding overhead
2	`vp8channel`	KCP over VP8 frames, minimal encoding overhead
3	`seichannel`	H264 SEI embedding, ACK/retry overhead
4	`videochannel`	Full video encoding via ffmpeg, highest overhead

Recommended Combinations

Start with jitsi + datachannel — no registration required, works on any self-hosted or public Jitsi Meet instance. Use wbstream + vp8channel as a stable alternative for production scenarios.

Use case	Provider	Transport	Notes
Getting started, self-hosted	`jitsi`	`datachannel`	No registration, simplest setup
Production, commercial	`wbstream`	`vp8channel`	Stable, no special rights needed
Telemost users	`telemost`	`vp8channel`	Only stable combination for Telemost
WbStream fallback	`wbstream`	`seichannel`	When vp8channel is unavailable
Experimental / last resort	`wbstream`	`videochannel`	Requires ffmpeg

Get Started

Configuration

Reference

Integrations

olcRTC: Auth Providers and Transport Modes Explained

Auth Providers

Jitsi

Telemost (Yandex)

WbStream

None — Direct Engine Mode

Engines (Internal)

Transports

datachannel

vp8channel

seichannel

videochannel

Compatibility Matrix

Speed Ranking

Recommended Combinations

Build docs developers (and LLMs) love

Get Started

Configuration

Reference

Integrations

Documentation Index

​Auth Providers

​Jitsi

​Telemost (Yandex)

​WbStream

​None — Direct Engine Mode

​Engines (Internal)

​Transports

​datachannel

​vp8channel

​seichannel

​videochannel

​Compatibility Matrix

​Speed Ranking

​Recommended Combinations

Build docs developers (and LLMs) love

Auth Providers

Jitsi

Telemost (Yandex)

WbStream

None — Direct Engine Mode

Engines (Internal)

Transports

datachannel

vp8channel

seichannel

videochannel

Compatibility Matrix

Speed Ranking

Recommended Combinations