videocall-rs

videocall.rs

videocall.rs is an open-source, low-latency video conferencing platform and streaming API written entirely in Rust. It is a WebRTC alternative built on WebTransport (HTTP/3 and QUIC) with an automatic WebSocket fallback, and it runs in the browser, on native devices through a command-line client, and on mobile through iOS and Android SDKs. It is self-hostable, dual-licensed under MIT and Apache-2.0, and built for real-time video streaming from robots, drones, and embedded Linux boards (Raspberry Pi, Jetson) as well as conventional browser-to-browser calls.

Website | Documentation | Discord | Crates.io

Project status: Beta. Actively developed and used in production for non-critical workloads.

Table of Contents

• What videocall.rs is for
• Features
• FAQ
• Why WebTransport instead of WebRTC?
• How it compares
• Browser compatibility
• Architecture
• Getting Started
  • Prerequisites
  • Dev loop
  • Container images
  • OAuth (optional)
  • Nix build system
• Runtime configuration (config.js)
• Usage
• Meeting management
• Performance
• Security
• Feature flags
• Testing
• Release history
• Contributing
• Demos and media
• Contributors
• Sponsors
• License

What videocall.rs is for

videocall.rs gives you the building blocks for real-time video communication without the WebRTC stack. It is aimed at three audiences:

• Software professionals building custom video applications on a type-safe Rust API, from web apps to autonomous-vehicle feeds.
• Robotics and IoT engineers streaming low-latency video from drones, robots, and embedded devices using the lightweight videocall-cli and the mobile SDKs.
• Teams that want to self-host their own conferencing infrastructure with JWT authentication, SSO/OAuth, and transport encryption (TLS 1.3 / QUIC), deployed with the provided Helm charts.

The same core powers browser calls at videocall.rs.

Features

• Low latency by design. Media travels over WebTransport (QUIC/HTTP3), which avoids head-of-line blocking and recovers from packet loss faster than TCP-based transports.
• WebTransport with WebSocket fallback. Clients negotiate WebTransport where available and fall back to WebSockets automatically for compatibility.
• Encrypted in transit. WebSocket connections use TLS 1.3 and WebTransport uses QUIC’s built-in TLS 1.3, so media is encrypted between each client and the relay. See Security.
• Browser, native, and mobile clients. A Dioxus/WebAssembly web UI, a native videocall-cli for headless streaming, and videocall-sdk bindings for iOS and Android.
• Horizontally scalable. A NATS pub/sub backbone lets WebSocket and WebTransport servers scale independently behind a load balancer.
• Self-hostable. Kubernetes Helm charts, a fully native dev stack, and reproducible container images built with Nix.
• Pure-Rust media pipeline. VP9 encode/decode and Opus audio are pure Rust with no C libvpx or libopus dependency.
• Open source. Dual-licensed under MIT and Apache-2.0.

FAQ

Is videocall.rs a WebRTC replacement?

For most server-mediated video use cases, yes. videocall.rs does not use WebRTC’s peer-connection stack. Media flows over WebTransport (QUIC/HTTP3), or a WebSocket fallback, to a Rust server that forwards packets to other participants through NATS. You give up WebRTC’s mature browser SFU ecosystem, but you also drop ICE, STUN/TURN, and SDP negotiation entirely.

Can I self-host it?

Yes. The repository ships Helm charts for Kubernetes and a fully native local dev stack. Production container images are built reproducibly with Nix. See Getting Started and the architecture document.

Does it work in the browser?

Yes, on Chromium-based browsers (Chrome, Edge, Brave) and Safari (macOS and iOS). Firefox is not currently supported. See Browser compatibility.

How is it different from LiveKit, Jitsi, or mediasoup?

Those stacks are WebRTC selective-forwarding units. videocall.rs forwards media over WebTransport/QUIC instead of WebRTC, is written entirely in Rust (server, browser client, and native client), and requires no STUN/TURN/ICE infrastructure. See How it compares.

Can I stream from a Raspberry Pi?

Yes. videocall-cli is a headless native client that streams from a camera on Raspberry Pi, Jetson Nano, and other embedded Linux devices. See CLI-based streaming.

Is the media encrypted?

Media is encrypted in transit. WebSocket connections use TLS 1.3, and WebTransport uses QUIC’s built-in TLS 1.3 encryption, so media is protected between each client and the relay. The relay server forwards media between participants; it is not end-to-end encrypted.

Why WebTransport instead of WebRTC?

WebTransport is the core technology that sets videocall.rs apart. Built on HTTP/3 and QUIC, it provides multiplexed, bidirectional streams and datagrams with modern congestion control. Choosing it over WebRTC has concrete consequences:

• No ICE, STUN, or TURN. Clients connect to a server over QUIC. There is no NAT-traversal negotiation, no candidate gathering, and no relay-server fleet to operate for connectivity.
• No SDP signaling dance. Session setup is a single QUIC handshake rather than an offer/answer exchange over a separate signaling channel.
• Better loss recovery. QUIC’s per-stream flow control avoids the head-of-line blocking that degrades TCP-based transports on lossy links, which matters on mobile and long-haul networks.
• Faster connection establishment. QUIC’s 0-RTT and 1-RTT handshakes reduce setup round-trips compared with WebRTC’s multi-step negotiation.
• A standards-track platform. WebTransport is developed at the IETF and W3C with active browser-vendor support.

videocall.rs still runs a forwarding server, so it is architecturally closer to an SFU than to peer-to-peer WebRTC. The difference is that the transport and signaling are radically simpler: no ICE, no TURN, no SDP. For a deep dive, see the architecture document.

How it compares

An honest, verifiable comparison with widely used WebRTC-based stacks. All four are open source and server-mediated (SFU-style); the differences are in transport and implementation language.

videocall.rs is the youngest of these and does not yet match their breadth of client SDKs, recording, and ecosystem integrations. Its advantage is a simpler transport and a single-language (Rust) codebase from server to browser.

Browser compatibility

Architecture

videocall.rs follows a microservices architecture in which clients connect over WebSocket or WebTransport and servers exchange media through a NATS pub/sub backbone.

Primary components:

1. actix-api streaming servers (websocket_server, webtransport_server, metrics) built on Actix Web.
2. meeting-api REST/auth API (login, meetings, host controls) on Axum with dbmate migrations.
3. dioxus-ui web frontend built with Dioxus and compiled to WebAssembly.
4. videocall-types shared protobuf data types and protocol definitions.
5. videocall-client client library for native and WebAssembly integration.
6. videocall-cli command-line client for headless streaming.
7. videocall-sdk iOS and Android bindings (UniFFI).
8. videocall-codecs / neteq pure-Rust codec wrappers and adaptive audio jitter buffer.

For details, including connection flows, message routing, and the encryption model, see the architecture document.

Getting Started

Development is fully native: the entire dev stack (postgres, NATS, prometheus, grafana, and the Rust services) runs as host processes supervised by process-compose, with hot reload everywhere. Docker only appears when you want to run the images, which are built by Nix. There are no Dockerfiles in the dev workflow. See docs/nix-architecture.md.

Prerequisites

• Modern Linux distribution, macOS, or Windows 10/11 (WSL2).
• Nix, which provides the dev stack, toolchains, and image builds.
  • One-time on multi-user installs: add yourself to trusted-users so builds can pull the project’s public binary cache instead of compiling everything locally. Until then Nix prints ignoring untrusted substituter 'https://videocall-rs.cachix.org' (harmless, but slow):

    echo "trusted-users = root $USER" | sudo tee -a /etc/nix/nix.conf
    sudo pkill nix-daemon
    

• Docker is not needed. It is optional, only if you want to docker run a published image locally.
• A Chromium-based browser (Chrome, Edge, Brave) or Safari (macOS, iOS). Firefox is not supported.

Dev loop (everything native, hot reload, zero Docker)

git clone https://github.com/security-union/videocall-rs.git
cd videocall-rs
make dev

That’s it. make dev opens the process-compose TUI running the whole stack as native processes:

Services wait for middleware health (compose-style depends_on), recompile and restart instantly on save, and the TUI can restart individual processes on demand. Open http://localhost:3001 and navigate to a meeting at http://localhost:3001/meeting/<username>/<meeting-id>.

To stop: quit the TUI (F10 / Ctrl-C), or run make dev-down from another terminal. The TUI needs an interactive terminal; for scripted or headless use run nix-shell default.nix -A shells.dev --run "dev-stack -t=false".

Prefer one service per terminal? make dev-middleware starts just postgres/nats/prometheus/grafana; then make dev-websocket, make dev-meeting-api, make dev-ui, and so on run a single watcher each (these also work with plain rustup plus cargo-watch).

Overriding environment variables: every process in make dev sees env layered as built-in defaults < .env < .env.local, both untracked. Copy .env-sample to .env for documented knobs (OAuth, service URLs, JWT secret); put personal or secret overrides in .env.local, which is gitignored and never checked in.

Container images (the k8s deliverable)

Nothing local needs Docker: development, tests, and e2e all run native. The container images exist for Kubernetes. CI builds and publishes them from release.nix on every merge. To build one locally (for example, to debug an image’s entrypoint with docker run):

make image-websocket-server   # nix-build one image and docker-load it
make images                   # all of them

On Linux the images build natively; on macOS the service binaries are cross-compiled to aarch64-unknown-linux-musl with no VM and no remote builder. The first macOS build compiles a musl cross-toolchain (one-time, tens of minutes); after that it is cached in the Nix store.

OAuth (optional)

Both stacks read the same files: make dev layers .env then .env.local into every process. To enable Google login, create a .env from the sample and fill in credentials (or keep secrets in .env.local):

cp .env-sample .env

• Go to Google Cloud Console → APIs & Credentials.
• Create an OAuth 2.0 Client ID (Web application type).
• Add http://localhost:8081/login/callback as an authorized redirect URI.
• Copy the Client ID and Secret into your .env.

Without OAuth credentials the app runs with auth bypassed for local development.

Platform notes:

• Rancher Desktop (Windows/WSL2) with Traefik Ingress on port 3001: Rancher Desktop runs Traefik, which may conflict with the dioxus-ui frontend. Override the port in your local .env (not .env-sample):

  DIOXUS_SERVE_PORT=8088
  AFTER_LOGIN_URL=http://localhost:8088
  ALLOWED_REDIRECT_URLS=http://localhost:8088
  

  Then access the app at http://localhost:8088.
• Shell environment variables: if you have API_BASE_URL, OAUTH_REDIRECT_URL, or similar variables exported in your shell profile (~/.bashrc, ~/.zshrc), they override .env values. Remove them from your profile before running make dev.

Nix build system

The build system is native Nix, no flakes: default.nix (entry point), shell.nix (dev shells), release.nix (CI artifacts: packages and Docker images). Dependency pins live in nix/tamal/ and are managed by nixtamal; evaluating them needs plain Nix only. Full design: docs/nix-architecture.md. Coming from the old Docker dev environment? See docs/migrating-from-docker.md.

nix-shell                                              # default dev shell (frontend toolchain)
nix-shell default.nix -A shells.backend-dev           # backend toolchain + cargo-watch + dbmate
nix-build release.nix -A packages.websocket-server    # a single service binary (static musl)
make image-websocket-server                           # its Docker image, loaded into the daemon
make pins-update                                       # refresh nixtamal pins (nix/tamal/)

Runtime configuration (config.js)

The frontend is configured at runtime via a window.__APP_CONFIG object provided by a config.js file. The file is copied by Trunk and loaded at /config.js by dioxus-ui/index.html.

• Local: make dev and make dev-ui run scripts/start-dioxus.sh, which writes dioxus-ui/scripts/config.js from the environment before Trunk starts. To point the UI somewhere custom, override the relevant env vars in .env.local (see scripts/start-dioxus.sh for the keys) rather than editing the generated file. The Nix-built videocall/dioxus-ui image does the same at container startup via its entrypoint.
• Kubernetes / Helm: helm/videocall-ui/templates/configmap-configjs.yaml renders config.js from .Values.runtimeConfig. Define runtimeConfig in your values file and deploy or upgrade.

Voice Activity Detection (VAD) threshold

The vadThreshold config parameter controls how sensitive speaking detection is. It sets the minimum RMS audio level that counts as “speaking,” used for tile border glow, peer-list mic glow, and self-video glow indicators.

window.__APP_CONFIG = Object.freeze({
    // ... other config ...
    vadThreshold: 0.02   // default
});

The threshold can also be set via the VAD_THRESHOLD environment variable (see scripts/start-dioxus.sh) or via runtimeConfig.vadThreshold in Helm values.

Usage

Browser-based clients

1. Navigate to your deployed instance or local setup:

   http://<server-address>/meeting/<username>/<meeting-id>
   

2. Grant camera and microphone permissions when prompted.
3. Click “Connect” to join the meeting.

CLI-based streaming

For headless devices like a Raspberry Pi:

# Install the CLI tool
cargo install videocall-cli

# Stream from a camera
videocall-cli stream \
  --user-id <your-user-id> \
  --video-device-index 0 \
  --meeting-id <meeting-id> \
  --resolution 1280x720 \
  --fps 30 \
  --frame-format NV12 \
  --bitrate-kbps 500

The CLI joins an existing meeting; create the call from a browser first. For all options, see the videocall-cli README.

Meeting management

videocall.rs includes a meeting management system with ownership, waiting rooms, and host controls.

• Meeting ownership: each meeting has an owner (the creator) identified by their email.
• My Meetings: users can view and manage all meetings they own from the home page.
• Waiting room: non-owners enter a waiting room and must be admitted by an existing participant.
• Host identification: the meeting owner is marked with “(Host)” in the UI.
• Soft delete: owners can delete their meetings; deleted meeting IDs can be reused.

Workflow: navigating to /meeting/{meeting-id} creates the meeting and makes you the owner if it does not exist. Owners see “Start Meeting,” others see “Join Meeting.” Non-owners wait for admission; admitted participants are auto-joined and can then manage the waiting room.

Meeting management requires the FEATURE_MEETING_MANAGEMENT flag (see Feature flags):

export FEATURE_MEETING_MANAGEMENT=true

Details: Meeting Ownership & Workflow and Meeting API Reference.

Performance

videocall.rs is engineered for real-time streaming across a range of hardware and networks:

• One-on-one and small groups: a mesh-style topology with adaptive quality driven by per-receiver diagnostics (packet loss, latency, jitter, estimated bandwidth).
• Large conferences: the NATS-backed forwarding architecture scales out horizontally — add relay servers for capacity, with WebSocket and WebTransport relays scaling independently behind a load balancer.

Implementation choices that support this:

• Asynchronous core. Built on Rust’s async/await ecosystem with the Tokio runtime.
• SIMD-accelerated VP9 encoding. The pure-Rust VP9 encoder uses AVX2/SSE2 (x86-64) and NEON (aarch64) intrinsics for motion estimation, with scalar fallbacks.
• Binary protocol. All messages use Protocol Buffer serialization, keeping wire size small.
• Adaptive streaming. Senders adjust bitrate, resolution, and frame rate to the most constrained receiver based on diagnostics feedback.

Design goals still in progress (minimizing data copies on the media path, further congestion-control tuning) are tracked in the architecture document. Detailed benchmarking guidelines are a work in progress.

Security

• Transport security. WebSocket connections use TLS 1.3; WebTransport inherits QUIC’s built-in TLS 1.3 encryption. Media is encrypted between each client and the relay, but not end-to-end: the relay forwards decrypted media between participants.
• Authentication. JWT-based access control with SSO/OAuth integration.
• Access controls. Meeting ownership, waiting rooms, and host controls (see Meeting management).

For the full model, see the security architecture and the security documentation.

Feature flags

videocall.rs uses environment-based feature flags to enable optional or experimental functionality at runtime. Flags are loaded lazily on first access and can be overridden for testing.

Flags are set via environment variables with the FEATURE_ prefix:

export FEATURE_MEETING_MANAGEMENT=true
# or, with Docker:
docker run -e FEATURE_MEETING_MANAGEMENT=true ...

Truthy values (case-insensitive) are true, 1, and yes. Any other value, or an unset variable, is treated as false.

Testing

UI testing (dioxus-ui)

The Dioxus frontend uses a three-layer testing pyramid, all running in a real browser via wasm-bindgen-test:

# Run UI component tests natively (requires Chrome + chromedriver)
cd dioxus-ui
CHROMEDRIVER=$(which chromedriver) cargo test --target wasm32-unknown-unknown

CI runs these via .github/workflows/wasm-test.yaml. For the full guide, see dioxus-ui/README.md.

Backend testing (actix-api)

The actix-api crate has unit and integration tests that run against real PostgreSQL and NATS instances, started natively by make check-backend. Coverage includes session management, WebSocket and WebTransport meeting lifecycles, packet classification, the metrics server, and feature-flag behavior.

Tests use #[serial_test::serial] because they share a database, and each cleans up its own data. Everything runs natively, no Docker: make check-backend starts postgres 18 and NATS (JetStream) from nixpkgs under process-compose in a throwaway data dir, runs dbmate migrations, then clippy, fmt, and cargo test in the pinned nix-shell.

make check-backend          # all backend tests (native postgres/NATS, fresh state per run)
make check-backend-sqlite   # same, against the SQLite meeting-api backend
make check-backend-down     # stop the test middleware and delete its state

CI runs these via .github/workflows/cargo-test.yaml on PRs touching actix-api/, videocall-types/, or protobuf/. Full guide: actix-api/TESTING.md.

E2E testing (Playwright)

Full browser-based end-to-end tests using Playwright. Tests run against the Dioxus UI, verifying meeting flows in real browsers; authentication is bypassed via JWT cookie injection, so no OAuth setup is needed.

The E2E stack runs natively, no Docker (e2eStack in nix/dev-stack.nix): postgres and NATS from nixpkgs, the meeting-api and websocket servers, and the Nix-built release UI dist served by caddy, which is the same payload the production images ship. Tests run automatically on pushes to main and can be triggered manually from the GitHub Actions page. See the e2e-* targets in the Makefile.

Release history

Contributing

Contributions are welcome.

1. Issues: report bugs or suggest features via GitHub Issues.
2. Pull requests: submit PRs for bug fixes or enhancements.
3. Community: join the Discord server to discuss development.

See the Contributing Guidelines for details.

Technology stack

• Backend: Rust + Actix Web + PostgreSQL (or SQLite) + NATS.
• Frontend: Rust + Dioxus + WebAssembly + Tailwind CSS.
• Transport: WebTransport (QUIC/HTTP3) + WebSocket fallback.
• Media: pure-Rust VP9 and Opus; NetEQ adaptive audio jitter buffer.
• Build system: Cargo + Trunk + Nix + Helm.
• Testing: cargo test + wasm-bindgen-test (browser UI tests) + Playwright (E2E).

Git hooks

The repo ships its hooks in githooks/ (currently pre-push: cargo clippy -D warnings and cargo fmt --check). Enable them once per clone:

git config core.hooksPath githooks

Demos and media

• Scaling to 1000 Users Per Call
• Initial Proof of Concept (2022)
• YouTube channel

Contributors

Dario Lencina

Seth Reid

Griffin Obeid

Ronen Barzel

Leone

Victor Martínez

Sponsors

Hosting for the public videocall.rs instance is supported by DigitalOcean. Using this referral link helps fund the project:

License

Dual-licensed under the MIT License and the Apache License 2.0. See LICENSE-MIT and LICENSE-APACHE for details.