SIPhon¶
A high-performance SIP proxy, B2BUA, and IMS platform — a Kamailio/OpenSIPS-class protocol engine, scripted in Python instead of a config DSL.
SIPhon is written in Rust — the transports, the RFC 3261 transaction and dialog state machines, the registrar — and scripted in free-threaded Python, which decides policy. You get the parts that are genuinely hard to get right as a fast, memory-safe core, and you drive them with real code:
- Python, not a config language — real functions, imports, a debugger, and
pytest(with a mock SDK) instead of$avpexpansions andfailure_routechains. - One YAML file for config — documented inline, no
modparam. - Hot-reload — edit a script, save, done. No restart.
- The B2BUA is first-class — two independent dialogs, topology hiding, media anchoring, header policies, forking — in ~50 lines of readable Python.
- Fast — tens of thousands of calls per second per node (~28–30k cps on commodity hardware), so you usually add nodes for redundancy, not throughput.
from siphon import b2bua, gateway
@b2bua.on_invite
def on_invite(call):
call.media.anchor(engine="rtpengine") # hide the media path
call.remove_headers_matching("^X-") # strip internal headers
call.dial(gateway.select("carriers").uri) # bridge to a trunk
That's a topology-hiding SBC with media anchoring. More like it in the Cookbook.
New here? Start with the Cookbook¶
The Cookbook has complete, working starting points for the common roles — each with the config, a real script, and how to test it:
Registrar · Stateful proxy · Load balancer · SBC (B2BUA) · Media & RTP profiles · Hardening & security · Monitoring
Running it in production¶
- Scaling, clustering & redundancy — how to run more
than one node, what shared state actually means here, what the Redis backend buys
you (durability + boot snapshot, not live cross-node sync), and why SIPhon
ships no
clusterer/DMQ-style replication engine. Start here if you're asking "how does SIPhon cluster?" - Deployment & operations — concrete topologies (single node, redundant pair / N nodes, IMS), the ops runbook (graceful drain, health/readiness probes, metrics & alerting, capacity planning, backup/DR), and a light Kubernetes shape.
- Supply chain & SBOM — what every release publishes (SPDX + CycloneDX SBOM), how to feed it to your own scanners, how dependency advisories are audited, and how to report a vulnerability.
- Migrating from Kamailio / OpenSIPS — a
concept map for porting routes and modules, and how to translate
clusterer/dmq_usrloctopologies to SIPhon's model.
Internals¶
- Handler execution model — how Python handlers run, the blocking contract, and the elasticity / backpressure / liveness guarantees of the handler pool.
- Feature readiness matrix — per-feature maturity (Production / Implemented / Planned) with config keys and validation notes.
Runnable deployments¶
Reference deployment artifacts — a front-LB + 2-backend demo with a failover-proof script, plus Kubernetes manifests — live in deploy/.
Commercial support & sponsorship¶
Running SIPhon in production and want a hand — or want to fund a feature? Commercial support and feature sponsorship are available from Real Time Telecom B.V., run by SIPhon's maintainer. See Commercial support.
Platform Partner¶
Development is backed by Cellact and its Web3 telecom project Arnacon as a Platform Partner. Their support helps drive the SIPhon roadmap forward.
Also¶
- The main README — overview, install, full scripting API, performance baseline.
- siphon.yaml — the annotated reference configuration.
- sdk/ — the
siphon-sipmock library for testing scripts.
