SS7 vs SIGTRAN

Introduction¶

SS7 (Signalling System No. 7) is the out-of-band signalling network that sets up phone calls, routes SMS, handles roaming, and queries subscriber databases. SIGTRAN is the set of protocols that carry SS7 over IP instead of dedicated TDM links. The application logic is identical; only the bottom of the stack changes.

The SS7 stack¶

Key identifiers:

• Point Code (PC) — the "IP address" of a signalling point (SSP, STP, SCP). ITU is 14-bit; ANSI is 24-bit. Networks are addressed by PC at MTP3.
• Global Title (GT) — usually an E.164 number (like a phone number / GT of an HLR); SCCP translates a GT to a PC + SSN via GTT (Global Title Translation).
• Subsystem Number (SSN) — which application at a node (HLR = 6, MSC = 8, etc.).

Node types: SSP (service switching point — a switch), STP (signal transfer point — a router), SCP (service control point — a database like the HLR).

Why SIGTRAN¶

TDM SS7 links are 56/64 kbit/s, expensive, and don't scale to IP-era traffic volumes (especially SMS and data-session signalling). SIGTRAN carries the same MTP3/SCCP/TCAP payloads over IP.

The transport: SCTP¶

SIGTRAN uses SCTP, not TCP, because SS7 needs:

• Multi-homing — an SCTP association binds multiple IPs on each end; a path failure doesn't drop the association.
• Multi-streaming — independent ordered streams avoid head-of-line blocking (one stuck message doesn't stall others).
• Message orientation (preserves message boundaries), configurable ordered/unordered delivery.

The adaptation layers¶

M3UA is what you'll see most: an ASP (Application Server Process) connects to an SGP (Signalling Gateway Process) over SCTP; the SG bridges to the legacy TDM SS7 world (or it's IP end to end).

M3UA concepts: AS (Application Server — a logical function, e.g. "the HLR"), ASP (a process serving it), Routing Key (which traffic maps to which AS, by DPC/OPC/SI/SSN), ASP states (ASP-UP, ASP-ACTIVE).

Interworking¶

A Signalling Gateway terminates TDM MTP on one side and M3UA/SCTP on the other, passing MTP3-user messages (SCCP, ISUP) between them transparently. Point codes, GT routing, and TCAP dialogues work across the boundary unchanged — a legacy MSC and an IP-based HLR interoperate fine.

Verification and troubleshooting¶

# SCTP association state (Linux, lksctp-tools)
ss --sctp -a
cat /proc/net/sctp/assocs
sctp_status <assoc-id>

# Capture and decode
tshark -i any -d sctp.port==2905,m3ua -O m3ua,sccp,tcap

• M3UA ASP won't go ACTIVE — SCTP association is up but the routing key / network appearance doesn't match, or the far end expects a different traffic mode (loadshare vs override vs broadcast). Check ASP-UP vs ASP-ACTIVE in the logs.
• SCTP association flapping — path MTU / firewall dropping SCTP (protocol 132, not TCP/UDP — many NAT/firewalls mishandle it), or heartbeat timers too aggressive. Confirm both multi-homed paths are reachable.
• Messages routed to the wrong node — GTT table wrong, or MTP3 route for the DPC points at the wrong linkset. MTP3 route and SCCP GTT config.
• TCAP dialogue times out — the far SSN isn't bound / "subsystem prohibited" (SCCP SSP/SSA management), or the response is being sent to the wrong OPC.
• Works on TDM, fails over SIGTRAN — point code format mismatch (ITU 14-bit vs ANSI 24-bit) across the SG, or the SG isn't translating the network indicator.
• One-way signalling — asymmetric SCTP path (one multi-homed IP unreachable), or M3UA routing key defined in one direction only.

Related tools and reading¶

• On-site: Port Checker (SCTP 2905).
• Related posts: SS7 vs Diameter, SMSC basics for sysadmins.