SS7 and ISUP: the phone network SIP had to interwork with

The stack, briefly

SS7 separated signalling from voice: the talk path lives on 64 kbit/s trunk circuits, while call control travels a parallel data network of its own. MTP levels 1–3 are that network — links, reliability, and routing between nodes named by point codes. On top: ISUP for trunk call control, and SCCP + TCAP for transaction services — number translation, and the dialogues that mobile networks (MAP: location updates, SMS, roaming) and intelligent-network services (INAP/CAP: prepaid, freephone) run on. The nodes: SSPs (exchanges), STPs (signalling routers), SCPs (service databases). When SS7 is carried over IP rather than TDM links, the SIGTRAN family (M3UA over SCTP) replaces the lower layers and everything above continues unchanged.

An ISUP call, against its SIP twin

ISUP controls circuits: each trunk between two exchanges is a numbered CIC (circuit identification code), and the messages seize, ring, answer and release that circuit.

The asymmetries are where interworking gets interesting. ISUP has no ACK — answer is one message, not three. Early media is implicit (the voice circuit exists from seizure, so ringback simply plays down it) where SIP needs 183-with-SDP and P-Early-Media to say the same thing. A REL always carries a numeric cause; a SIP failure sometimes has to invent one, which is exactly what the Reason: header carries back. And ISUP worries about things SIP never had to: continuity tests on the voice path (COT), and glare — both ends seizing the same circuit at once, resolved by point-code arithmetic rather than luck.

SIP-I: ISUP riding inside SIP

When two TDM islands connect across a SIP core, the border gateways use SIP-I (ITU-T Q.1912.5; SIP-T is the IETF's earlier take): the SIP messages carry a multipart body with the original ISUP message embedded, Content-Type: application/ISUP. SIP does the routing; the far gateway re-emits the ISUP so nothing telco-specific is lost in translation. For the trace reader this is a gift — the INVITE contains the actual IAM, so the calling-party category, charge indicators and original cause values are right there if your tool decodes them. hiccup does.

Where you still meet all this

• Every PSTN breakout: the media gateway at the edge of an IMS or enterprise network turns SIP into ISUP. Its failures arrive in your SIP as status codes with Reason: Q.850;cause=… attached.
• National interconnects and number ranges that remain TDM-signalled long after the transport went IP (SIGTRAN, not SIP).
• Mobile roaming and SMS: MAP over TCAP is still the machinery under 2G/3G roaming, and its security problems (location tracking, SMS interception via rogue SS7 access) are why SS7 keeps making the news — a closed network's trust model, opened by decades of interconnect.
• SIP-I trunks between carriers, especially where one side is an incumbent that never quite finished its migration.

Reading it in a trace

1. On a SIP-I trunk, open the multipart body: compare the ISUP IAM's called number with the SIP Request-URI — mismatches (prefix handling, nature-of-address confusion) are the number-format ticket generator.
2. On teardown, trust the ISUP cause over the SIP status when both are present: the cause travelled from the far exchange; the status may have been improvised at the border. The mapping table lives on the Q.850 page.
3. A gateway answering everything with 503 while its peers are fine is often a circuit-group problem underneath (blocked CICs, a failed COT), invisible unless you can see the ISUP side.