What are the benefits of rewriting Asterisk PBX in Rust?
- Linux Kernel Removes strncpy After Six Years and 362 Patches
- Linux Kernel Drops 40-Year-Old AppleTalk Protocol — AI-Generated Patch Flood Was the Last Straw
- Apple’s Native Linux Container Tool Has Arrived — But Can It Really Replace Docker?
- 60% of MD5 Password Hashes Can Be Cracked in Under an Hour with a Single GPU
- Dirty Frag: Root Access on Every Major Linux Distribution — No Patch, No Warning
Open Source · Rust · VoIP Infrastructure
What are the benefits of rewriting Asterisk PBX in Rust?
Asterisk has powered open-source VoIP infrastructure for over two decades. A new experimental project — asterisk-rs — explores what a ground-up Rust rewrite could offer in terms of speed, safety, and long-term maintainability.
Asterisk is one of the most widely deployed open-source PBX systems in the world. Written in C and first released in 1999, it underpins millions of VoIP deployments — from small business phone systems to large-scale carrier infrastructure. Yet C, for all its performance credentials, carries well-known risks: memory unsafety, buffer overflows, use-after-free bugs, and a class of vulnerabilities that Rust was specifically designed to eliminate at the language level. The open-source project asterisk-rs, published on GitHub, demonstrates what a Rust-native Asterisk could look like — and makes a compelling case for why the telephony industry should pay attention.
Why Rust for VoIP?
Rust is a systems programming language that delivers performance comparable to C while enforcing memory safety through its ownership and borrowing model — without a garbage collector. For VoIP systems, these properties matter enormously. A PBX handles real-time audio streams, concurrent SIP transactions, and stateful call signaling — all simultaneously. Memory errors in this context can cause call drops, audio corruption, or full service outages. Rust eliminates an entire category of such bugs at compile time.
The asterisk-rs Project at a Glance
The asterisk-rs project, available at github.com/ryanmurf/asterisk-rs, represents a full-scope translation of the Asterisk codebase from C to Rust. It condenses 1.16 million lines of C into approximately 204,000 lines of idiomatic Rust, organized as 18 crates in a Cargo workspace. AI-assisted development played a significant role in the pace of the translation, illustrating how modern tooling can accelerate even large-scale open-source modernization efforts.
Eliminating the pjproject Dependency
One of the most architecturally significant decisions in asterisk-rs is the replacement of pjproject — the C-based SIP and media library that Asterisk has long relied on for its PJSIP channel driver. Rather than wrapping pjproject via FFI, the project provides a pure Rust SIP stack alongside a C-compatible shim library called pjsip-shim. This shim passes 100% of pjlib’s own test suite, meaning it can serve as a drop-in replacement for downstream code that depends on the pjproject API.
Eliminating this dependency matters for several reasons. pjproject has historically been a source of CVEs, and its C codebase carries the same memory-safety risks as Asterisk itself. A Rust-native SIP stack removes both codebases from the attack surface simultaneously.
Performance: SIP Processing Speed
SIP signaling is the heartbeat of any VoIP system. Every call setup, teardown, registration, and presence subscription flows through the SIP stack. Benchmark results reported in the asterisk-rs project compare the Rust SIP stack directly against pjproject across key workloads:
| Benchmark | pjproject (C) | asterisk-rs (Rust) |
|---|---|---|
| SIP message parsing | baseline | 2–5× faster |
| SIP transaction throughput | baseline | 2–3× faster |
| Release binary size | ~30–50 MB | ~6.1 MB |
| pjlib test suite pass rate | 100% (native) | 100% (shim) |
The performance gains stem from Rust’s zero-cost abstractions, its async I/O runtime (Tokio), and the removal of the lock contention inherent in the original C threading model. For high-concurrency deployments — contact centers, hosted PBX providers, and carrier-grade systems — these multipliers translate directly into reduced hardware costs and improved call quality under load.
Security: The CVE Dimension
Asterisk has accumulated a significant number of CVEs over its lifetime — an inevitable consequence of a large, long-lived C codebase handling untrusted network input. The asterisk-rs project conducted an analysis of active CVEs and found that roughly half of them involve memory-related vulnerabilities: buffer overflows, improper input validation leading to memory corruption, and similar issues. These are precisely the class of bug that Rust’s type system and ownership model make structurally impossible in safe code.
The security implications extend beyond CVE counts. VoIP infrastructure is a high-value target: toll fraud, call interception, and denial-of-service attacks against PBX systems cost enterprises and carriers billions of dollars annually. A memory-safe SIP stack reduces the attack surface at the most exposed layer of the system.
Feature Scope of the Rewrite
Despite being experimental, asterisk-rs covers substantial functional ground. The SIP protocol stack implements the full RFC 3261 specification, including all major request methods, along with ICE/TURN/STUN for NAT traversal, DTLS-SRTP for encrypted media, PRACK for reliable provisional responses, and STIR/SHAKEN for caller ID authentication — the framework mandated by regulators to combat robocall fraud.
- Full RFC 3261 SIP implementation (INVITE, REGISTER, SUBSCRIBE, NOTIFY, OPTIONS, MESSAGE, REFER, UPDATE, INFO, PUBLISH)
- Pure Rust SIP stack replacing the pjproject dependency
- ICE/TURN/STUN for NAT traversal in enterprise and cloud deployments
- DTLS-SRTP for end-to-end encrypted media streams
- STIR/SHAKEN caller ID attestation for anti-fraud compliance
- 78 dialplan applications and 58 dialplan functions
- Hot-reload of dialplans without service interruption
- 14 channel drivers including PJSIP, IAX2, DAHDI, and Local
- AMI and ARI management interfaces for integration and automation
- Echo cancellation, noise suppression, AGC, and DTMF detection
- MOS score estimation via the ITU-T G.107 E-model
- OpenTelemetry tracing with OTLP export for observability
Deployment and Operational Benefits
Beyond raw performance and security, a Rust-native PBX offers meaningful operational advantages. The compiled binary is dramatically smaller than its C counterpart, simplifying containerized deployments in Kubernetes and reducing image pull times in cloud environments. Rust’s package ecosystem (Cargo) provides reproducible, auditable builds — a significant advantage for compliance-conscious operators in regulated industries such as healthcare and finance.
Hot-reload of dialplans — already present in asterisk-rs — means configuration changes can be applied without restarting the service, eliminating a common source of call disruption during maintenance windows. Combined with the async concurrency model, the Rust version is architecturally better suited to the cloud-native deployment patterns that have become standard in modern VoIP infrastructure.
What This Means for VoIP Infrastructure
Asterisk is not the only aging C-based VoIP system in widespread use. Kamailio, FreeSWITCH, and many carrier-grade SBC products share the same fundamental trade-off: decades of battle-tested functionality built on a foundation that predates modern memory-safety tooling. The asterisk-rs experiment demonstrates that rewriting these systems in Rust is technically feasible, and that the resulting code can be faster, smaller, and structurally immune to a large class of security vulnerabilities.
Whether the open-source telephony community pursues this direction formally — or whether commercial vendors begin shipping Rust-native VoIP components — remains to be seen. But the performance benchmarks, CVE analysis, and feature scope of asterisk-rs make a credible technical argument that the transition is worth undertaking. For the VoIP industry, memory safety is no longer a theoretical luxury; it is increasingly a competitive and regulatory requirement.
The project is available on GitHub under the GPL-2.0 license.
