videocall.rs

An open-source, high-performance video conferencing platform built with Rust, providing real-time communication with low latency and end-to-end encryption.

Website | Discord Community

Table of Contents

• Overview
• Features
• Why WebTransport Instead of WebRTC?
• System Architecture
• Getting Started
  • Prerequisites
  • Docker Setup
  • Manual Setup
• Usage
• Performance
• Security
• Roadmap
• Contributing
• Project Structure
• Demos and Media
• Contributors
• License

Overview

videocall.rs is a modern, open-source video conferencing system written entirely in Rust, designed for developers who need reliable, scalable, and secure real-time communication capabilities. It provides a foundation for building custom video communication solutions, with support for both browser-based and native clients.

Project Status: Beta - Actively developed and suitable for non-critical production use

Features

• High Performance: Built with Rust for optimal resource utilization and low latency
• Multiple Transport Protocols: Support for WebSockets and WebTransport
• End-to-End Encryption (E2EE): Optional secure communications between peers
• Scalable Architecture: Designed with a pub/sub model using NATS for horizontal scaling
• Cross-Platform Support: Works on major browsers (Chrome/Chromium, with Safari support in development)
• Native Client Support: CLI tool for headless video streaming from devices like Raspberry Pi
• Open Source: MIT licensed for maximum flexibility

Why WebTransport Instead of WebRTC?

WebTransport is a core technology that differentiates videocall.rs from traditional video conferencing solutions. As a developer, here's why our WebTransport approach is technically superior:

Technical Advantages

• No SFUs, No NAT Traversal: WebTransport eliminates the need for complex Selective Forwarding Units and NAT traversal mechanisms that plague WebRTC implementations and cause countless developer headaches.

• Simplified Architecture: No more complex STUN/TURN servers, ICE candidates negotiation, or complicated signaling dances required by WebRTC. Just direct, straightforward connections.

• Protocol Efficiency: Built on HTTP/3 and QUIC, WebTransport provides multiplexed, bidirectional streams with better congestion control and packet loss recovery than WebRTC's dated SCTP data channels.

• Lower Latency: QUIC's 0-RTT connection establishment reduces initial connection times compared to WebRTC's multiple roundtrips.

• Clean Development Experience: WebTransport offers a more intuitive developer API with a promise-based design and cleaner stream management.

• Future-Proof: As part of the modern web platform developed by the IETF and W3C, WebTransport has strong browser vendor support and an actively evolving specification.

Developer Implications

For developers integrating videocall.rs, this means:

• ✅ Drastically simpler deployment architecture
• ✅ No complex network configuration or firewall issues
• ✅ Better performance in challenging network conditions
• ✅ More predictable behavior across implementations
• ✅ Less time spent debugging connectivity issues
• ✅ A forward-looking technology investment

Read our Architecture Document for a deep dive into how we implement WebTransport and the technical benefits it provides.

System Architecture

videocall.rs follows a microservices architecture with these primary components:

graph TD
    Clients[Clients<br>Browsers, Mobile, CLI] -->|WebSocket| ActixAPI[Actix API<br>WebSocket]
    Clients -->|WebTransport| WebTransportServer[WebTransport<br>Server]
    ActixAPI --> NATS[NATS<br>Messaging]
    WebTransportServer --> NATS

Loading

1. actix-api: Rust-based backend server using Actix Web framework
2. yew-ui: Web frontend built with the Yew framework and compiled to WebAssembly
3. videocall-types: Shared data types and protocol definitions
4. videocall-client: Client library for native integration
5. videocall-cli: Command-line interface for headless video streaming

For a more detailed explanation of the system architecture, please see our Architecture Document.

Getting Started

⭐ RECOMMENDED: Docker is the only fully supported development method ⭐

We strongly recommend using the Docker-based setup for development, as it's well-maintained and provides consistent behavior across platforms. The manual setup described below is not as well maintained and may require additional troubleshooting.

Prerequisites

• Modern Linux distribution, macOS, or Windows 10/11
• Docker and Docker Compose (for containerized setup)
• Rust toolchain 1.85+ (for manual setup)
• Chrome/Chromium browser for frontend access

Docker Setup

The quickest way to get started is with our Docker-based setup:

1. Clone the repository:

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

2. Start the server (replace <server-ip> with your machine's IP address):

   make up
   

3. Open Chrome using the provided script for local WebTransport:

   ./launch_chrome.sh
   

4. Access the application at:

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

Manual Setup (Experimental)

⚠️ Warning: This setup method is experimental and not as well maintained as the Docker approach. You may encounter issues that require manual debugging.

For advanced users who prefer to run services directly on their machine:

1. Create a PostgreSQL database:

   createdb actix-api-db
   

2. Install required tools:

   # Install NATS server
   curl -L https://github.com/nats-io/nats-server/releases/download/v2.9.8/nats-server-v2.9.8-linux-amd64.tar.gz | tar xz
   sudo mv nats-server-v2.9.8-linux-amd64/nats-server /usr/local/bin
   
   # Install trurl
   cargo install trurl
   

3. Start the development environment:

   ./start_dev.sh
   

4. Connect to:

   http://localhost:8081/meeting/<username>/<meeting-id>
   

For detailed configuration options, see our setup documentation.

Usage

Browser-Based Clients

1. Navigate to your deployed instance or localhost 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 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

For detailed information about the CLI tool and all available options, see the videocall-cli README.

Performance

videocall.rs has been benchmarked and optimized for the following scenarios:

• 1-on-1 Calls: Minimal resource utilization with <100ms latency on typical connections
• Small Groups (3-10): Efficient mesh topology with adaptive quality based on network conditions
• Large Conferences: Tested with up to 1000 participants using selective forwarding architecture

Technical Optimizations

• Zero-Copy Design: Minimizes data copying between network stack and application code
• Asynchronous Core: Built on Rust's async/await ecosystem with Tokio runtime
• SIMD-Accelerated Processing: Uses CPU vectorization for media operations where available
• Lock-Free Data Structures: Minimizes contention in high-throughput scenarios
• Protocol-Level Optimizations: Custom-tuned congestion control and packet scheduling

Resource Utilization

Our server-side architecture is designed for efficiency at scale:

• Horizontal Scaling: Linear performance scaling with additional server instances
• Load Distribution: Automatic connection balancing across server pool
• Resource Governance: Configurable limits for bandwidth, connections, and CPU utilization
• Container-Optimized: Designed for efficient deployment in Kubernetes environments

Performance metrics and tuning guidelines will be available in our performance documentation. (WIP)

Security

Security is a core focus of videocall.rs:

• Transport Security: All communications use TLS/HTTPS.
• End-to-End Encryption: Optional E2EE between peers with no server access to content.
• Authentication: Flexible integration with identity providers.
• Access Controls: Fine-grained permission system for meeting rooms.

For details on our security model and best practices, see our security documentation.

Roadmap

Version	Target Date	Key Features
0.5.0	Q2 2023	✅ End-to-End Encryption
0.6.0	Q3 2023	✅ Safari Browser Support
0.7.0	Q4 2023	✅ Native Mobile SDKs
0.8.0	Q1 2024	🔄 Screen Sharing Improvements
1.0.0	Q2 2024	🔄 Production Release with Full API Stability

Contributing

We welcome contributions from the community! Here's how to get involved:

1. Issues: Report bugs or suggest features via GitHub Issues

2. Pull Requests: Submit PRs for bug fixes or enhancements

3. RFC Process: For significant changes, participate in our RFC process

4. Community: Join our Discord server to discuss development

See our Contributing Guidelines for more detailed information.

Technology Stack

• Backend: Rust + Actix Web + PostgreSQL + NATS
• Frontend: Rust + Yew + WebAssembly + Tailwind CSS
• Transport: WebTransport (QUIC/HTTP3) + WebSockets (fallback)
• Build System: Cargo + Trunk + Docker + Helm
• Testing: Rust test framework + Playwright for E2E tests

Key Technical Features

• Bidirectional Streaming: Fully asynchronous message passing using QUIC streams
• Error Handling: Comprehensive Result-based error propagation throughout the codebase
• Modularity: Clean separation of concerns with well-defined interfaces between components
• Type Safety: Extensive use of Rust's type system to prevent runtime errors
• Binary Protocol: Efficient Protocol Buffer serialization for all messages

For a more comprehensive technical overview, see the Architecture Document.

Demos and Media

Technical Presentations

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

Channels

• YouTube Channel

Contributors

Dario Lencina

Griffin Obeid

Ronen Barzel

Leone

Victor Martínez

Special thanks to JasterV for the Actix websocket implementation which contains fragments from the chat-rooms-actix project.

License

This project is licensed under the MIT License - see the LICENSE.md file for details.