videocall.rs: self-hosted video streaming over WebTransport

videocall.rs targets server-mediated streaming without ICE

videocall.rs addresses a specific architectural choice in real-time video: it does not use the WebRTC peer-connection stack. Media clients connect to a Rust server through WebTransport, which uses HTTP/3 and QUIC, with automatic fallback to WebSocket. The server forwards media to other participants through NATS. This makes the project relevant to teams that want to operate their own conferencing infrastructure or embed a video feed in a specialized application.

The README names three principal audiences. Software professionals can use the type-safe Rust API for custom video applications. Robotics and IoT engineers can publish camera streams through `videocall-cli` from drones, robots, Raspberry Pi systems, Jetson boards, and embedded Linux devices. Teams operating conferencing infrastructure can deploy the included Kubernetes Helm charts and connect authentication services such as JWT and SSO or OAuth.

This is not a drop-in WebRTC replacement. The project explicitly gives up WebRTC's established browser SFU ecosystem, along with ICE, STUN, TURN, SDP, and browser-native peer negotiation. Its value is narrower and more opinionated: a Rust media path centered on a relay, QUIC, and WebSocket compatibility.

The project describes itself as beta and says it is actively developed and used in production for non-critical workloads. That status matters for adoption planning. The last repository push was on 2026-10-07, while the listed releases for `videocall-types`, `videocall-transport`, and `videocall-nokhwa` were published on 2026-08-16.

WebTransport, WebSocket, and NATS form the media path

The defining mechanism is server-mediated forwarding. A client negotiates WebTransport where the environment supports it. Otherwise, the client falls back to WebSocket automatically. WebTransport carries media over QUIC and HTTP/3, while WebSocket provides the compatibility path. The media server then forwards packets between participants through NATS.

The README attributes several properties to QUIC. Multiplexed bidirectional streams and datagrams avoid the connection-wide head-of-line blocking associated with a single TCP stream, while QUIC supplies its own loss recovery and congestion control. The project also says WebTransport removes ICE candidate gathering, STUN and TURN infrastructure, and the SDP offer and answer exchange associated with WebRTC.

That design changes the operational boundary. Participants do not establish a WebRTC peer connection directly. They connect through the service's server and relay path, and NATS links independently scalable WebSocket and WebTransport servers behind a load balancer. The repository layout supports this broader system with separate crates for transport, types, codecs, client code, diagnostics, meetings, API services, and native streaming.

The codec documentation says VP9 encode and decode operations and Opus audio are implemented in a pure-Rust media pipeline, without C `libvpx` or `libopus` dependencies. The repository nevertheless includes Nokhwa-related crates and platform binding directories, so hardware capture support is more involved than the pure-Rust codec statement alone may suggest.

Native development starts with the Makefile and Nix stack

The repository's documented developer entry point is its GNU-style Makefile. Running `make` presents the available targets instead of implicitly building anything. The stated targets include the complete native stack, checks, clean operations, development processes, container images, and a shell.

Start by asking the Makefile what the checkout provides:

make help

The output should present the target list and conventions used by this checkout. The Makefile also documents a native development stack built around process-compose and assigns `DEV_PC_PORT` a default of `28080`. Integration and end-to-end stacks use separate ports and disposable data directories, which lets those workflows coexist with development processes.

The README points to `https://docs.videocall.rs` for full documentation and describes a fully native development stack plus Kubernetes Helm charts. The available repository text does not preserve the detailed prerequisite commands or the first client invocation, so those steps should be taken from the linked documentation rather than inferred from the crate names. In particular, there is no confirmed `cargo install` command or first-call configuration in the available instructions.

For deployment-related work, the documented project-level entry points are:

make all
make check

The Makefile describes `make all` as building every artifact, including Nix packages and container images. `make check` runs linting and backend and UI test suites. These are repository development commands, not minimal instructions for connecting a production browser client.

Browser support excludes Firefox and native peer calls

The README documents support for Chromium-based browsers, including Chrome, Edge, and Brave, plus Safari on macOS and iOS. Firefox is explicitly listed as unsupported. That restriction is a direct consequence of relying on WebTransport as the primary browser transport, although the project also includes WebSocket fallback.

The fallback should not be read as browser feature parity across every platform. The documentation names supported browsers, but it does not provide a compatibility matrix explaining whether each feature behaves identically over WebTransport and WebSocket. It also does not document browser support for direct native-to-native calling.

This narrows the project's practical audience. Conventional WebRTC applications often begin with broad native browser interoperability and add TURN when direct connectivity fails. videocall.rs instead requires participants to use the project's browser client, native client, or mobile SDK against a compatible server. Teams migrating an existing consumer conferencing product need to verify browser support and calling topology before treating the transport difference as a transparent replacement.

Safari support does not remove this constraint. Its presence makes the browser target wider than Chromium alone, but Firefox remains outside the documented set. The project also identifies itself as beta, so deployments that depend on every browser in an existing customer base face a different risk profile from deployments with a controlled set of clients.

Transport encryption does not mean end-to-end conferencing encryption

videocall.rs documents encryption between each client and the relay. WebSocket connections use TLS 1.3, while WebTransport uses the TLS 1.3 encryption built into QUIC. The same section states plainly that the relay forwards media between participants and that the system is not end-to-end encrypted.

That boundary is essential for security review. Traffic is protected while it crosses the client-to-server connection, but the server-mediated forwarding path means participants do not receive the confidentiality property associated with a design where media remains encrypted from sender to recipient. Deployments that require end-to-end encryption cannot treat the transport encryption statement as satisfying that requirement.

The system supports self-hosted deployment, JWT authentication, and optional SSO or OAuth according to the README. Those controls can address service access and identity integration, but the available documentation does not state who may hold decryption keys, what administrative access is possible, or whether media is retained after relay forwarding. It also does not document a complete threat model or operational hardening guide in the available sections.

For a security-sensitive evaluation, the first review should therefore distinguish two questions. The first is whether TLS 1.3 protects client-to-relay transport as documented. The second is whether any requirement depends on media remaining encrypted while the relay processes or forwards it. The project answers the first clearly and marks a limitation for the second.

Rust, SDKs, and codecs broaden deployment beyond a web client

The repository is organized as a Cargo workspace rather than a single CLI. Workspace members include `actix-api`, `meeting-api`, `bot`, `videocall-types`, `videocall-meeting-types`, `videocall-meeting-client`, `videocall-client`, `videocall-cli`, `dioxus-ui`, `videocall-sdk`, `videocall-codecs`, `neteq`, `videocall-diagnostics`, `videocall-transport`, and `matomo-logger`.

That structure supports several client forms. The README identifies a Dioxus and WebAssembly web interface, the native `videocall-cli` for headless streaming, and `videocall-sdk` bindings for iOS and Android. Camera publishing from embedded Linux is the most distinct use case because a browser conference interface is not the only required client.

The project also separates transport, protocol types, codecs, networking, diagnostics, meetings, and deployment concerns into dedicated crates. Recent package releases include `videocall-types-v6.0.1`, `videocall-transport-v0.2.1`, and `videocall-nokhwa-v0.10.10`. The presence of versioned transport and type crates indicates that application code may need to coordinate package versions rather than depend on one undifferentiated release.

The MIT and Apache-2.0 dual licensing offers permissive choices for integration. The repository includes both `LICENSE-MIT` and `LICENSE-APACHE`. This statement identifies the available license files and does not replace examination of notices, dependency licenses, or organization-specific compliance requirements.

Compared with LiveKit, Jitsi, or mediasoup, the architectural difference is direct. Those systems use WebRTC selective-forwarding units, while videocall.rs forwards through WebTransport or WebSocket and removes ICE, STUN, TURN, and SDP from its documented path. A team choosing based on mature WebRTC interoperability will favor the former category; a team committed to Rust and a QUIC-centric server may prefer videocall.rs.

Beta status and Firefox exclusion bound production use

videocall.rs is most convincing as a self-hosted foundation for a controlled client set, especially where headless video from embedded devices matters. It is less suitable as an invisible substitute for WebRTC in a product that must support Firefox, native browser-to-browser calling, or the wider browser SFU ecosystem.

The README's production statement includes an important qualification: the project is used in production for non-critical workloads. Its beta status, separate transport versions, explicit Firefox exclusion, and lack of end-to-end encryption should remain visible in an adoption decision.

The available documentation also leaves several verification points unresolved. It does not provide a complete WebTransport and WebSocket feature matrix, document first-use installation commands in the available text, explain media retention, or define the full administrative security boundary. Teams should verify those details against `https://docs.videocall.rs` and the repository's architecture documentation before committing a sensitive workload.

Editorial conclusion

Adopt videocall.rs when a self-hosted, Rust-based media path is more important than WebRTC compatibility. Do not select it for Firefox, native browser-to-browser connectivity, or end-to-end encryption without first confirming its current browser, deployment, and security boundaries.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. security-union/videocall-rs on GitHub