olcRTC Documentation

olcRTC (OpenLibreCommunity RTC) is an encrypted TCP-over-WebRTC tunnel. It is designed to bypass network restrictions by disguising traffic as ordinary participation in a WebRTC/SFU service (such as Jitsi Meet, Yandex Telemost, or WbStream).

To an outside observer, the connection appears to be a standard WebRTC call to an allowed service IP. The payload is additionally secured using a shared crypto.key with XChaCha20-Poly1305 encryption.

olcRTC (OpenLibreCommunity RTC) is an encrypted TCP-over-WebRTC tunnel. It masks network traffic as standard video calls on permitted services (such as Jitsi, Yandex Telemost, or WbStream).

Core Security & Protocol Features:

• Encryption: Uses XChaCha20-Poly1305.
• Multiplexing: Uses smux over WebRTC data/video channels.
• Traffic Flow: app -> SOCKS5 -> olcrtc cnc -> WebRTC/SFU сервис -> olcrtc srv -> internet.

Note: Ensure the video calling service you intend to use is on the allowlist and functional in your network before proceeding.

olcRTC (OpenLibreCommunity RTC) is an encrypted TCP-over-WebRTC tunnel designed to mask traffic as standard WebRTC/SFU service participation (e.g., Jitsi Meet, Yandex Telemost, or WbStream). This allows bypassing network restrictions where direct access to arbitrary VPS/IPs is blocked.

Architecture

• Client Mode (cnc): Starts a local SOCKS5 proxy. Applications (browsers, curl, sing-box, etc.) connect to this proxy.
• Server Mode (srv): Connects to the same WebRTC room/session, receives encrypted smux streams, and performs TCP dials to target destinations.

Data Flow

SOCKS CONNECT $\rightarrow$ smux stream $\rightarrow$ XChaCha20-Poly1305 $\rightarrow$ transport $\rightarrow$ engine $\rightarrow$ WebRTC/SFU

olcRTC supports various providers, transports, and platforms:

• Providers: jitsi, telemost, wbstream (Recommended start: jitsi + datachannel).
• Transports: datachannel, vp8channel, seichannel, videochannel.
• Platforms: Linux, macOS, Windows, Android (via gomobile), and it is available as an embeddable Go library.

The sub.md format is a plain text file hosted on a server that client applications use to manage server lists. It contains a list of olcrtc:// URIs supplemented with metadata for both the entire subscription and individual servers.

Note: This is a convention for client applications; the olcrtc core does not process this file.

File Structure

The file is parsed top-to-bottom using three types of entries:

1. Global fields: Prefixed with #, these apply to the entire subscription.
2. Server URIs: Lines starting with olcrtc:// representing a single server.
3. Local fields: Prefixed with ##, these apply only to the immediately preceding olcrtc:// URI.

Empty lines between entries are permitted.

Liveness checks use an encrypted control stream (the first smux stream after CLIENT_HELLO/SERVER_WELCOME) to send CONTROL_PING and CONTROL_PONG. This verifies the actual tunnel path rather than just the WebRTC connection status.

If the threshold of missed pongs is reached, the current smux session is rebuilt. In failover mode, the supervisor will attempt the next profile.

liveness:
  interval: 10s
  timeout: 5s
  failures: 3

When running ./script/srv.sh, you will be prompted to select a Carrier and a Transport.

Carriers

1. jitsi: Default. Stable on datachannel, requires no registration, easy to self-host.
2. telemost: Requires a Room ID from the Telemost website.
3. wbstream: Requires a Room ID from the WBStream website.

Transports

• datachannel: Fastest, lowest ping. Recommended with jitsi. Note: Does not work with WBStream DC in guest flow, and Telemost has removed DC support.
• vp8channel: Works with telemost and wbstream. Fast but higher ping.
• seichannel: Works only with wbstream. Slow but low ping.
• videochannel: Works with wbstream (stable) and telemost (as possible). Slowest with highest ping.

Recommended combinations:

• jitsi + datachannel (Best performance)
• wbstream + vp8channel (Alternative)

The olcrtc CLI operates in three distinct modes defined by the mode key in your YAML configuration:

To run the CLI, pass the configuration file as an argument:

olcrtc server.yaml
olcrtc client.yaml

olcRTC operates in three distinct modes depending on your role in the tunnel:

• srv (Server): The server-side component. It accepts encrypted tunnel streams from clients and performs TCP dials to the target destination addresses on the client's behalf.
• cnc (Client): The client-side component. It listens on a local SOCKS5 proxy. Applications (like browsers or curl) connect to this local proxy to route traffic through the tunnel.
• gen (Generator): A utility mode used to create Room IDs for providers that support room creation.