ISUP

Overview

ISUP — ISDN User Part — is the SS7 application protocol that controls circuit- switched voice call setup, supervision, and release between telephone exchanges. Where MAP handles subscriber management and mobility, ISUP handles the actual voice call signalling: a caller dials a number, the originating exchange sends an IAM (Initial Address Message) toward the destination, the call is established, and ISUP supervises it until either party hangs up. Every 2G and 3G mobile-to- mobile, mobile-to-fixed, or fixed-to-mobile call is coordinated by ISUP messages travelling over the SS7 network between MSCs, gateways, and PSTN exchanges.

ISUP was standardised by the ITU-T as part of the SS7 suite in the 1980s, replacing the earlier Telephone User Part (TUP). It is designed for a circuit-switched network paradigm: calls occupy physical or logical circuits between exchanges, and ISUP tracks those circuit states. Each circuit is identified by a CIC (Circuit Identification Code) — a number identifying a specific bearer channel on a specific trunk between two exchanges. ISUP messages reference the CIC to which they apply, and exchanges maintain a state machine per CIC.

In the mobile network context, ISUP is spoken by the MSC (Mobile Switching Centre). When a mobile subscriber makes a call, the MSC acts as an originating switch and sends ISUP IAM toward the PSTN or toward the destination MSC for mobile-to-mobile calls. When a call terminates to a mobile subscriber, the incoming IAM arrives at the GMSC (Gateway MSC), which uses MAP SendRoutingInfo to find the subscriber's serving MSC, and then routes the call onward via ISUP ProvideRoamingNumber to reach the correct exchange.

ISUP is gradually being retired as operators migrate to IMS and VoLTE. In IMS, SIP replaces ISUP for call signalling. However, interworking between IMS and PSTN requires ISUP-SIP conversion at Media Gateways, and ISUP remains the protocol of record for inter-exchange signalling in networks that have not yet completed full IMS migration. In practice, ISUP persists in virtually every operator network that maintains any PSTN interconnect or that still operates 2G/3G voice.

---

How it works

Basic call setup — IAM to ANM

A call from a mobile subscriber to a fixed number illustrates the full ISUP message sequence.

1. IAM — Initial Address Message: The originating MSC selects an available CIC on the trunk toward the next exchange and sends an IAM. The IAM contains:

   • Called Party Number (the dialled digits, in E.164 format)
   • Calling Party Number (the caller's CLI — may be restricted)
   • Nature of Connection Indicators (satellite call, continuity check required)
   • Forward Call Indicators (ISDN access, interworking, end-to-end signalling)
   • Bearer Capability (64 kbps unrestricted for voice) The IAM is routed through the SS7 network based on the dialled number, passing through STPs and transit exchanges toward the terminating exchange.

2. ACM — Address Complete Message: When the terminating exchange has sufficient address information to route the call and is alerting (ringing) the called party, it returns an ACM. The ACM signals that the backward path is complete and the call can proceed. Intermediate exchanges propagate the ACM back toward the originating MSC. At this point, ringing tone is typically played to the caller.

3. ANM — Answer Message: When the called party answers, the terminating exchange sends an ANM. The ANM signals that the call is connected. Billing begins at the originating exchange upon receipt of the ANM.

4. REL — Release Message / RLC — Release Complete: When either party hangs up, the exchange that detected the disconnect sends a REL toward the other exchange, containing a Cause indicator (e.g., Cause 16 = Normal Call Clearing). The receiving exchange releases the circuit and returns an RLC. The CIC is now free for reuse.

CON — Connect (single-message completion)

For exchanges that support it, the CON message combines ACM and ANM into a single message — used for automatic answer scenarios (voicemail, IVR systems).

Continuity check

Before establishing a circuit, an exchange may request a continuity check to verify the physical bearer (trunk) is functioning. The originating exchange sends a continuity check tone on the circuit; the distant exchange loops it back. An exchange sends a COT (Continuity) message if the check passed, or a CCR (Continuity Check Request) if it failed and should be tried on an alternate circuit.

Call release with cause

The REL message carries a Cause parameter — a Q.850 cause code indicating why the call was released:

• Cause 1: Unallocated number
• Cause 16: Normal call clearing
• Cause 17: User busy
• Cause 18: No user responding
• Cause 21: Call rejected
• Cause 31: Normal unspecified
• Cause 41: Temporary failure
• Cause 42: Switching equipment congestion

These cause codes have billing implications — some cause codes stop billing immediately; others affect how the CDR is written.

---

Architecture role

ISUP connects the circuit-switched nodes of the telephone network. In a mobile network, every inter-exchange voice call uses ISUP. The MSC is the primary ISUP node in the mobile core — it originates and terminates ISUP calls on behalf of its registered subscribers.

In 2G/3G networks: The MSC originates ISUP IAMs for outgoing calls and terminates incoming IAMs. The GMSC uses MAP to find the subscriber's serving MSC, then routes via ISUP. STP nodes relay ISUP messages between exchanges based on point code routing, just as they do for MAP.

Superseded by SIP in IMS: SIP replaced ISUP for call signalling in IP Multimedia Subsystem deployments. VoLTE uses SIP for all call setup; the only ISUP remaining is at the IMS-PSTN gateway (the MGCF — Media Gateway Control Function) for interworking with legacy networks.

ISUP persists at interconnect boundaries: Even in fully IMS-capable operators, ISUP is still used for interconnect with operators who have not deployed SIP. The industry-wide migration from ISUP to SIP interconnect (SIP trunking) has been gradual and uneven.

The SS7 STP routes ISUP messages using MTP3 point code addressing between exchanges. Unlike MAP messages (which use SCCP Global Title addressing for flexible routing), most ISUP messages are routed by point code — the originating MSC knows which exchange to address based on number analysis results.

---

Key interfaces

---

Security posture

ISUP's security posture is lower risk than MAP because it primarily targets call signalling rather than subscriber data or mobility functions. An ISUP attack requires SS7 network access and the ability to inject messages at an exchange boundary — conditions that also enable MAP attacks, which are generally more valuable to an attacker (location, SMS interception). Operators and security researchers prioritise MAP defences, and ISUP attacks are less frequently documented in the wild.

That said, ISUP is a significant vector for financial fraud. Toll fraud — where an attacker manipulates ISUP to route calls through victim operators who bear the termination costs — costs the global telecommunications industry billions annually. Calling Line Identification (CLI) spoofing in ISUP IAMs enables vishing (voice phishing), impersonation of banking institutions, and fraudulent call completion to premium-rate numbers.

---

Attack surface

CLI spoofing via IAM manipulation

The Calling Party Number parameter in the ISUP IAM is the source of the caller's CLI (Calling Line Identification). ISUP provides no mechanism to authenticate that the CLI presented in the IAM actually belongs to the originating subscriber. An attacker with SS7 access can send an IAM with an arbitrary CLI — impersonating a bank's contact centre number, a government agency, or a private individual. The receiving exchange displays the spoofed number to the called party.

Impact: CLI spoofing enables vishing campaigns — calls appear to come from trusted numbers (banks, HMRC, police). Mass-scale vishing attacks using spoofed CLIs are a documented real-world fraud vector.
Difficulty: Low given SS7 access. STIR/SHAKEN provides CLI authentication for VoIP calls but is not applicable to pure ISUP paths.

Toll fraud via tandem switching abuse

In tandem routing, calls transit through intermediate exchanges before reaching the destination. An attacker who controls a transit exchange can reroute calls to premium-rate numbers — the originating exchange believes the call is being delivered to its intended destination, but it is actually being routed to a premium number that generates revenue for the attacker. The originating operator is billed for the termination at the premium rate.

Impact: Significant financial losses for the originating operator — premium call fraud can generate millions in fraudulent termination fees before detection.
Difficulty: Medium. Requires control of a transit exchange (which some unscrupulous carriers make available commercially).

IAM flooding — circuit blocking

Sending a high volume of IAM messages that seize circuits (in the Initial Address state) but never complete (no ACM returned) blocks the target exchange's circuits. While the incomplete calls time out and are released, an attacker who sustains the flood can keep a significant fraction of an exchange's circuits in a seized state, blocking legitimate calls.

Impact: Partial or complete denial of service for the targeted exchange's inbound or outbound call capacity.
Difficulty: Medium. Requires SS7 access and the ability to generate volume. Rate limiting and CIC state monitoring mitigate this.

REL cause code manipulation for billing bypass

The REL cause code affects how the terminating exchange handles call accounting. Some cause codes (e.g., Cause 31: Normal unspecified, sent before answer) result in no billing. An attacker who can inject a REL toward the terminating exchange before the ANM is sent — simulating a pre-answer release — can cause the terminating operator to incorrectly log the call as unanswered, generating no revenue for the legitimate call.

Impact: Revenue loss for the terminating operator; useful for competitors engaged in interconnect fraud.
Difficulty: Medium. Requires SS7 access and knowledge of the target's CIC assignments and billing logic.

---

Mitigations

ISUP defences are primarily applied at interconnect boundaries where calls from external networks enter the operator's SS7 fabric.

• CLI validation at ingress: Validate the Calling Party Number in incoming IAMs against the originating operator's number range (IR.21 data). IAMs from operator A presenting a CLI in operator B's number range should be flagged or blocked — this is a CLI spoofing attempt. Apply this at the SS7 interconnect firewall or STP screening table.

• STIR/SHAKEN for VoIP interconnect: STIR/SHAKEN provides cryptographic CLI authentication for SIP calls. For VoIP-to-ISUP interworking, identity assertions from the SIP network can be preserved or validated at the MGCF. This does not protect pure SS7 paths but reduces the CLI spoofing surface where SIP trunking is used.

• CIC state monitoring: Monitor circuits for the proportion of IAMs that never reach ACM or ANM. A high rate of unanswered IAMs from a specific interconnect point may indicate toll fraud (tandem routing to premium numbers that intentionally avoid completing) or IAM flooding DoS.

• IAM parameter validation: Apply SS7 screening at STPs or dedicated ISUP firewalls to reject IAMs with malformed mandatory parameters, impossible cause combinations, or inconsistent forward call indicators. Many fraud scenarios rely on subtly invalid ISUP messages that some exchanges process permissively.

• International call monitoring: Apply anomaly detection on international ISUP traffic — flag unusual call volumes to specific country codes, unusual CIC utilisation patterns on international trunks, or high rates of short- duration calls (characteristic of toll fraud testing before scaling up).

---

Spec references

• ITU-T Q.761 — General aspects of ISUP. Defines the functional description, the state machine, and the parameter structure. The foundational specification.

• ITU-T Q.764 — ISUP signalling procedures. Defines each procedure (call setup, overlap sending, continuity check, call release) in detail. The normative reference for ISUP state machines and message sequence charts.

• ITU-T Q.850 — Cause codes used in Q.931 and ISUP. Defines all release cause codes, their meanings, and their mapping to SIP response codes in IMS interworking.

• 3GPP TS 29.007 — ISUP-PLMN interworking requirements. Defines how 3GPP-specific parameters (TMSI, IMSI) are carried in ISUP messages and how mobile network interworking procedures apply to the standard ISUP call model.

---

Related topics

ISUP is an application protocol running over SS7, just as MAP is. Both use MTP/SCCP/TCAP as transport, though ISUP messages are routed by MTP3 point code rather than SCCP Global Title, since the originating exchange knows the destination exchange address from number analysis.

The MSC is the primary ISUP node in a mobile network — it originates and terminates ISUP calls on behalf of its registered subscribers. STP nodes relay ISUP between exchanges.

SIP superseded ISUP for call signalling in IMS deployments. SIP is semantically similar to ISUP (INVITE ≈ IAM, 180 Ringing ≈ ACM, 200 OK ≈ ANM, BYE ≈ REL) but uses HTTP-like text encoding over IP rather than binary encoding over SS7.

SIGTRAN carries ISUP over IP in softswitch deployments — the ISUP messages remain unchanged but the MTP transport layer is replaced by SCTP/M3UA.