Async-friendly WebRTC implementation in Rust

Sponsored with 💖 by

Gold Sponsors:

Silver Sponsors:


Bronze Sponsors:
AdrianEddy

Overview

WebRTC.rs is an async-friendly WebRTC implementation in Rust, originally inspired by and largely rewriting the Pion stack. The project is currently evolving into a clean, ergonomic, runtime-agnostic implementation that works with any async runtime (Tokio, async-std, smol, embassy).

Architecture:

• rtc: Sans-I/O protocol core with complete WebRTC stack (95%+ W3C API compliance)
• webrtc (this crate): Async-friendly API with runtime abstraction layer

📖 Learn more: Read our architecture blog post for design details and roadmap.

🚨 Important Notice: v0.17.x Feature Freeze & v0.20.0+ Development

v0.17.x is the final feature release of the Tokio-coupled async WebRTC implementation.

Current Status (February 2026)

• v0.17.x branch: Receives bug fixes only (no new features). Use this for Tokio-based production applications.
• Master branch: Under active development for v0.20.0 with new Sans-I/O architecture and runtime abstraction.

What's Changing in upcoming v0.20.0+?

The new architecture will address critical issues in v0.17.x:

• ❌ Callback hell and Arc explosion
• ❌ Resources leak in callback
• ❌ Tight Tokio coupling (cannot use async-std, smol, embassy)

v0.20.0+ will provide:

✅ Runtime Independence

• Support for Tokio, async-std, smol, embassy via Quinn-style runtime abstraction
• Feature flags: runtime-tokio (default), runtime-async-std, runtime-smol, runtime-embassy

✅ Clean Event Handling

• Trait-based event handlers with native async fn in trait
• No more callback Arc cloning or Box::new(move |...| Box::pin(async move { ... }))
• Centralized state management with &mut self

✅ Sans-I/O Foundation

• Protocol logic completely separate from I/O (via rtc crate)
• Deterministic testing without real network I/O
• Zero-cost abstractions

How to Provide Feedback

We're actively designing v0.20.0+ and welcome your input:

• Review the architecture blog post
• Join discussions on GitHub Issues
• Chat with us on Discord

For production use: Stick with v0.17.x branch until v0.20.0+ is stable.
For early adopters: Follow master branch development and provide feedback!

Building and Testing

# Update rtc submodule first
git submodule update --init --recursive

# Build the library
cargo build

# Run tests
cargo test

# Build documentation
cargo doc --open

# Run examples
cargo run --example data-channels

Semantic Versioning

This project follows Semantic Versioning:

• Patch (0.x.Y): Bug fixes and internal improvements with no public API changes.
• Minor (0.X.0): Backwards-compatible additions or deprecations to the public API.
• Major (X.0.0): Breaking changes to the public API.

While the version is 0.x, the minor version acts as the major — i.e., a minor bump may include breaking changes. Once 1.0.0 is released, full semver stability guarantees apply.

Pre-release versions are published with the following suffixes, in order of increasing stability:

• -alpha.N: Early preview. API is unstable and may change significantly.
• -beta.N: Feature-complete for the release. API may still have minor changes.
• -rc.N: Release candidate. No further API changes are expected unless critical issues are found.

For example: 1.0.0-alpha.1 → 1.0.0-beta.1 → 1.0.0-rc.1 → 1.0.0.

Open Source License

Dual licensing under both MIT and Apache-2.0 is the currently accepted standard by the Rust language community and has been used for both the compiler and many public libraries since ( see https://doc.rust-lang.org/1.6.0/complement-project-faq.html#why-dual-mitasl2-license). In order to match the community standards, webrtc-rs is using the dual MIT+Apache-2.0 license.

Contributing

Contributors or Pull Requests are Welcome!!!