Technical Specifications

Reference this section during capacity planning or architecture reviews for compatibility, performance assumptions, and extensibility boundaries.

1. Support matrix

2. Performance references

• Concurrent calls: 500–800 per node is a common range depending on codec and recording strategy.
• Calls per second (CPS): lightweight scenarios sustain 30+ CPS, subject to carrier throttling.
• Latency: internal processing < 20 ms; end-to-end latency follows network quality.

2.1 SDES-SRTP Support

Since v0.4.10, RustPBX supports SDES-SRTP (RTP/SAVP) negotiation on SIP legs, in addition to DTLS-SRTP used by WebRTC.

• Inbound SDES-SRTP offer: an inbound SIP INVITE with RTP/SAVP profile and a=crypto line is answered with RTP/SAVP (instead of being downgraded to plain RTP/AVP, which some carriers reject).
• SIP-to-SIP anchored media: SDES-SRTP is mirrored from the caller leg to the callee leg, keeping media encrypted end-to-end through the media proxy.
• WebRTC gateways: WebRTC (ICE+DTLS) ↔ SIP (RTP/SAVP) interop continues to work — the proxy bridges the two transport modes automatically.
• Plain RTP: trunks and extensions that do not signal SDES-SRTP are served with plain RTP/AVP as before; no configuration change is needed.

No dedicated config field — SDES-SRTP is negotiated automatically based on the SDP offer. Carriers like Twilio Elastic SIP Trunks with Secure Media enabled will now interoperate correctly.

3. Observability & interfaces

• Health probe: handler::ami exposes /health for load balancers or black-box monitors; perfcli can batch ping nodes.
• Logging: configure log_level and log_file for tracing output shipped to ELK/Loki. HTTP access logs support AccessLogEventFormat.
• Diagnostics UI: templates/console/diagnostics.html bundles the WebRTC probe, trunk/route evaluation, and Web Dialer for most troubleshooting needs.
• Webhook / AMI: extend handler/ami.rs or handler/llmproxy.rs to emit callbacks or integrate with external voice bots.

4. Security & compliance

• Encryption: TLS/SRTP and WebRTC DTLS, with certificates managed by addons/acme if desired.
• Authentication: per-extension and per-trunk credentials; console middleware (console/middleware.rs) enables custom auth flows.
• Auditability: export call records and admin logs for retention programs—configure retention per policy.

5. Extension points

• Addons: plugin architecture via the Addon trait — community addons include ACME (TLS auto-renewal), Archive (recording archiving), Transcript (offline ASR), Queue, and Observability (Prometheus). Commercial addons extend to Wholesale routing, Contact Center (CC), IVR Editor, Voicemail, Endpoint Manager (phone provisioning), Enterprise Auth (LDAP/SAML), SBC, and Telemetry (OpenTelemetry).
• RWI (Real-time WebSocket Interface): WebSocket-based command/event protocol for call control (originate, answer, hangup, bridge, transfer, hold), queue management (enqueue, dequeue, agent assignment), and conference control. Suitable for building custom CTI panels, voice agents, and CRM integrations.
• Playbook / LLM: playbook/ and llm/ directories expose AI voice hooks for external models.
• Handlers: add custom APIs/protocols under handler/, e.g., webhooks or gRPC endpoints.

6. Deployment & resilience

• Multi-instance: run at least two nodes with a shared database; use an external SBC or load balancer for traffic splitting.
• State sharing: active call data lives in proxy/active_call_registry.rs; share state via Redis/database or partition traffic per business unit.
• Backups: store configs in Git, snapshot databases periodically, and offload recordings to object storage.

For official benchmarks, watch docs/specs for published reports or run cargo bench plus custom load tests in your staging environment.