Skip to content

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 $avp expansions and failure_route chains.
  • 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_usrloc topologies 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.

Partners and sponsors

Cellact and Arnacon, SIPhon Platform Partner      Sainer, SIPhon sponsor

Development is backed by Cellact and its Web3 telecom project Arnacon as a Platform Partner, and by Sainer, an AI phone agent that answers, handles and escalates calls in a natural voice, as a sponsor. 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-sip mock library for testing scripts.