Out-of-band signaling
Early telephone networks signaled in-band: the same path that carried your voice also carried the tones that set up the call. That is elegant until you realize anyone with a tone generator can instruct the network, which is precisely the vulnerability that made phone phreaking possible in the 1960s and 70s.
SS7 separates the two. Signaling travels over its own packet-switched network, entirely distinct from the circuits carrying audio. The consequences were substantial:
- Security. Subscribers cannot inject signaling, because they never touch the signaling network.
- Speed. Call setup dropped from seconds to well under a second, because signaling no longer waits on circuit seizure at each hop.
- Efficiency. A circuit is only seized once the far end is known to be available — no more tying up long-haul trunks to discover a busy signal.
- Features. A signaling network that can query databases mid-call-setup enables toll-free routing, calling name, number portability, and prepaid billing.
The network elements
| Element | Full name | Role |
|---|---|---|
| SSP | Service Switching Point | A switch that originates and terminates signaling — where calls enter and leave. |
| STP | Signal Transfer Point | A packet router for signaling messages. Always deployed in mated pairs for redundancy. |
| SCP | Service Control Point | The database tier — toll-free translation, LNP, calling name, prepaid balance. |
Every element has a point code, its address on the signaling network. The mated-pair discipline for STPs, with fully diverse linksets, is why the signaling network historically achieved availability that ordinary IP networks did not.
The protocol stack
| Layer | Protocol | Does |
|---|---|---|
| 1–3 | MTP1–3 | Message Transfer Part — physical, link, and network layers. Reliable delivery and routing by point code. |
| 4 | ISUP | ISDN User Part — call setup and teardown between switches. The trunk signaling. |
| 4 | SCCP | Signaling Connection Control Part — richer addressing, including global title translation for database queries. |
| 4 | TCAP | Transaction Capabilities — the query/response mechanism used for database lookups. |
| App | MAP / INAP / CAP | Mobile and intelligent-network applications: roaming, SMS delivery, prepaid, service logic. |
An ISUP call, simplified
| Message | Meaning |
|---|---|
| IAM — Initial Address Message | Call setup request, carrying called and calling party numbers and the selected circuit. |
| ACM — Address Complete Message | Enough digits received; the destination is being alerted. |
| ANM — Answer Message | Answered. Billing starts here. |
| REL — Release | Teardown, with a cause value. |
| RLC — Release Complete | Circuit is free again. |
If those look structurally similar to the Q.931 messages on a PRI D-channel, that is not coincidence — ISUP is the inter-switch relative of the same signaling family. See ISDN PRI & BRI.
What SS7 gave the enterprise, indirectly
Most enterprises never touched SS7 directly — they connected via PRI, and the carrier's switch was the SSP. But several capabilities enterprises depend on exist only because SS7 does.
| Capability | How SS7 provides it |
|---|---|
| Toll-free (8XX) routing | An SCP query translates the dialed 8XX number into the actual routing number at call setup — which is how the same toll-free number can route by time of day or origin. |
| Local number portability | An LNP database dip returns the LRN identifying the switch that now serves a ported number. |
| Calling name (CNAM) | A separate database query performed by the terminating carrier — not carried in the call setup itself. |
| Answer supervision | The ANM gives an unambiguous answer event, which is what accurate call accounting depends on. |
What replaced it
SS7 has not disappeared — it still carries a large amount of interconnect traffic — but new deployment is IP-based. The functions map like this:
| SS7 function | IP-era equivalent |
|---|---|
| MTP transport | SIGTRAN — SS7 over IP, using SCTP as the transport |
| ISUP call control | SIP (RFC 3261), with defined ISUP-to-SIP mapping at gateways |
| SCP database queries | ENUM, HTTP/REST APIs, and IMS application servers |
| Intelligent network services | IMS application servers and platform-native service logic |
| Trust and identity | STIR/SHAKEN — see caller ID authentication |
That last row is worth dwelling on. SS7's security model was perimeter-based: it was trustworthy because only carriers could reach it. Once signaling moved onto IP and the set of participants widened enormously, that assumption failed — and caller ID spoofing at scale is the direct consequence. STIR/SHAKEN is the industry's attempt to replace implicit network trust with explicit cryptographic attestation.
Why this matters in a migration
Two practical points:
- Interworking is lossy. Where calls cross between SS7 and SIP domains, information is mapped rather than carried. Cause codes, redirecting numbers, and originating information can all degrade. If reporting or routing depends on those fields, test them specifically.
- The database-backed features are separate purchases. Toll-free routing logic, LNP behavior, and CNAM are not properties of your trunk. They are services. Confirm which of them you are actually buying in the new arrangement, because the assumption that they simply carry over is one of the more common migration surprises.
Related reading
- ISDN PRI & BRI — the enterprise-facing relative of ISUP.
- SIP trunking & SBCs — the replacement architecture.
- STIR/SHAKEN — rebuilding trust that SS7 got from its perimeter.
Sources
Features that "just carried over" are usually the ones that didn't. We check them explicitly.
Book a call