Skip to content

Deployment

A library, not a runnable product

siphon-sigtran is a Rust library that plugs the ss7 / gsm_map / gsm_cap / inap namespaces and an SS7 runtime into a SIPhon binary you build and compose. There is no siphon-sigtran server to run on its own. Everything here is parameterised on your image and your binary crate; see Using it in a SIPhon build.

What ships in the image

A signalling node built on siphon-sigtran needs, in the runtime image:

  • Your composing siphon binary (the one that calls configure_from + register at startup).
  • libpython for the embedded interpreter pyo3 runs, present in the runtime image.
  • Your script (ss7.py or whatever you name it) mounted at runtime so handlers hot-reload without a rebuild.
  • Your sigtran.yaml mounted alongside it.
  • Kernel SCTP. The node speaks SCTP; the host/container needs the sctp module loaded (modprobe sctp) and the SCTP ports reachable.

The runtime split

                    ┌──────── your signalling node (a SIPhon binary) ────────┐
   peers  ──SCTP──▶ │  siphon-sigtran runtime (Rust):                        │ ──SCTP──▶ peers
                    │    • associations (M3UA / M2PA over kernel SCTP)       │
                    │    • MTP3 routing + SCCP GTT + content routing         │
                    │    • TCAP dialogue engine                             │
                    │    • dispatch ──▶ your script (Python)                 │
                    └────────────────────────────────────────────────────────┘
                              your script owns:
                        overrides · deferred dips · MAP/CAP termination

Signalling addressing

SS7 is addressed by point code and global title, not by the pod's IP. Two consequences for any deployment:

  • The node's point code is config, not a runtime discovery. Peers are provisioned to reach you at that PC; keep it stable across restarts.
  • Outbound associations originate from a specific, provisioned IP. A peer that you connect to has your source IP and PC provisioned, so the node's signalling IPs must be stable and cannot be NATed behind a shared egress (SNAT also breaks SCTP multihoming). This shapes the Kubernetes model; see Kubernetes & scaling.

Wiring config

The composing siphon binary loads sigtran.yaml at startup: point extensions.sigtran at it in your main siphon.yaml (see Configuration and Using it in a SIPhon build).

# siphon.yaml
extensions:
  sigtran: /etc/siphon/sigtran.yaml

The associations, routes, GTT, and content rules all reload with the script, so editing the config and letting SIPhon reload takes effect without a restart.

Graceful shutdown

On rollout or scale-down the orchestrator sends SIGTERM. The node should stop accepting new associations, let in-flight dialogues finish or age out on their TCAP timers, and exit. Give it room to drain before SIGKILL (a preStop delay plus terminationGracePeriodSeconds in Kubernetes).

Next