Initial scoping: architecture + Asterisk→Rust port plan
Establish rutster — a memory-safe, API-first, security-first telephony platform; spiritual successor to Asterisk for the WebRTC/microservices era. - README: project framing, design pillars, open decisions - docs/ARCHITECTURE.md: three-plane (control/media/app) model - docs/PORT_PLAN.md: every Asterisk subsystem mapped to a disposition (core / WASM-plugin / service / edge-FFI / dropped / replaced) with rationale Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01C2bfD7MkqEdfnMXxXBu456
This commit is contained in:
54
docs/ARCHITECTURE.md
Normal file
54
docs/ARCHITECTURE.md
Normal file
@@ -0,0 +1,54 @@
|
||||
# Rutster Architecture
|
||||
|
||||
## The reframe
|
||||
|
||||
Asterisk's power was: *one process, load any `.so`, wire anything to anything in the
|
||||
dialplan.* That composability is the thing to match — but it does **not** require a
|
||||
1.2M-LOC monolith. Rutster delivers the same "build anything" through a different
|
||||
substrate:
|
||||
|
||||
- a **small hardened core** (media + signaling glue + call model),
|
||||
- a **WASM plugin runtime** for safe, third-party-extensible logic,
|
||||
- **declarative routing** as data for the common path,
|
||||
- a **programmable API** (REST/gRPC + event stream) modeled on Asterisk's ARI.
|
||||
|
||||
More extensible than Asterisk, because extensions are safe to run from people you
|
||||
don't fully trust.
|
||||
|
||||
## Three planes
|
||||
|
||||
### Control plane (stateless-ish, horizontally scalable)
|
||||
The ARI-style resource API (channels / bridges / endpoints / recordings / playbacks)
|
||||
over REST + gRPC + a WebSocket/SSE event stream. Registrar, routing, auth. This is
|
||||
where "the dialplan" disappears — replaced by declarative routing + external services
|
||||
reacting to call events (the Twilio / ARI-Stasis model). Asterisk's
|
||||
`rest-api/api-docs/*.json` is a reusable spec for the resource model.
|
||||
|
||||
### Media plane (stateful, latency-pinned, scaled separately)
|
||||
RTP/SRTP termination, mixing/bridging (softmix), transcoding, record/playback. A
|
||||
controllable media node driven over gRPC by the control plane. Built on the Rust
|
||||
WebRTC media ecosystem (`str0m` sans-IO design, `webrtc-rs`). **The media datapath
|
||||
stays tight** — do not over-decompose it across service hops; latency and failure
|
||||
modes compound.
|
||||
|
||||
### App plane (your services + plugins, outside the core)
|
||||
IVR, queues, voicemail, dialers, custom routing — driven via the API, deployed
|
||||
independently. WASM plugins for in-call logic that needs to run close to the core;
|
||||
microservices for stateful/business/billing logic.
|
||||
|
||||
## Cross-cutting
|
||||
|
||||
- **Event bus** (NATS / Redis Streams / Kafka) replaces Asterisk's internal Stasis bus
|
||||
for cross-service events; a lightweight in-core dispatcher handles intra-core.
|
||||
- **State store** replaces `astdb` + realtime/sorcery.
|
||||
- **Security is load-bearing, not a row:** memory-safe fuzzed parsers, TLS/SRTP
|
||||
mandatory, deny-by-default routing + toll-fraud engine, mTLS gRPC admin (no AMI),
|
||||
WASM tenant isolation, SBOM + KMS/Vault for secrets.
|
||||
- **Observability:** OpenTelemetry traces that follow a single call across
|
||||
signaling → media → app services.
|
||||
|
||||
## Biggest technical risk
|
||||
|
||||
The **SIP stack**. No mature pure-Rust option exists → FFI pjproject or front the edge
|
||||
with a battle-tested SBC initially; treat a pure-Rust stack as a long-term goal, not a
|
||||
v1 dependency. Everything else builds on the existing Rust media ecosystem.
|
||||
Reference in New Issue
Block a user