The role of intermediate signaling network identification in ISUP
Buried inside every ISUP Initial Address Message that crosses an SS7 backbone sits a deceptively small field: the Intermediate Indicator, often shortened to II. Two bits long, it answers a single commercial and routing question: has this call hopped through another signaling network before reaching us? The answer drives wholesale billing, transit charging, and the way engineers troubleshoot hairpin routes through exchanges in Sydney, Melbourne, and Brisbane.
The indicator travels alongside other transit-related elements such as the hop counter. Every switch that forwards the ISUP message can read it, leave it untouched, or rewrite it to reflect only the hop it handled itself. That simple act of preservation or rewriting is what keeps interconnect settlements honest between carriers in Australia and abroad.
For Australian operators the parameter matters well beyond textbook signalling. With interconnect agreements still defining how Telstra, Optus, and TPG Telecom settle wholesale traffic, and with the ACMA keeping an eye on charging accuracy, a correctly populated II flag is part of the commercial settlement story. Trainers usually begin with live traces captured on Australian transit switches before moving to international traffic patterns.
What the II parameter actually does
The II field communicates whether the message has transited one or more intermediate signaling networks since the original originating exchange placed the call. The standard defines three meaningful states: no intermediate network encountered, one intermediate network encountered, and more than one intermediate network encountered, with the last case rarely seen in live Australian traffic.
Engineers typically read the II parameter alongside the hop counter, which decreases by one every time the message passes through a forwarding signaling point. A switch in Parramatta receiving an IAM with II set to "one intermediate network" can apply a transit charge band even when the intermediate hop was an aggregator in Singapore or a wholesale partner across the Tasman.
How intermediate signaling points fit into the ISUP message flow
An ISUP message follows the path defined by MTP3 routing labels, hopping from originating exchange through whatever tandems the carrier has provisioned. Each transit switch that forwards the IAM typically preserves the II setting unchanged, while decrementing the hop counter. The terminating switch then infers the route depth from those two untouched fields.
In a typical Australian transit scenario, a call from Adelaide to Cairns might originate on Telstra infrastructure, traverse a TPG transit tandem in Brisbane, and terminate on Optus equipment at the far end. The receiving Optus switch reads the II flag as "one intermediate network" and applies the matching wholesale tariff. Engineers debugging dropped calls often begin by extracting II alongside the called-party number, calling-party number, and hop counter, a routine covered early on the SS7 Training resource hub.
Charging, transit networks, and Australian carrier interconnect
Australian interconnect is unusually rich because of the country's geography. Long-haul voice traffic between Perth and the east coast still relies on a handful of transit tandems, and any call crossing a competing carrier's footprint picks up an extra settlement layer. The II parameter is the trigger that lets the terminating carrier apply the correct wholesale tariff rather than charging the call as if it had been carried entirely on-net.
Wholesale billing teams in Sydney and Melbourne routinely reconcile II values against operator-determined records travelling through the same signaling links. When a mismatch surfaces, the dispute usually points to a misconfigured tandem or a legacy ISUP variant that does not update the parameter correctly. These mismatches remain a regular source of ACMA audit queries and are typically traced using the structured walk-throughs in the training catalogue.
Operational quirks when crossing international gateways
International gateway switches, particularly those operated out of exchanges near Sydney's cable stations, handle a wider range of II patterns than domestic tandems. Traffic arriving from Asia-Pacific carriers often carries II already set to "more than one intermediate network", since the originating carrier may have transited a regional aggregator before the call reached Australian shores.
The Australian gateway must decide whether to preserve that flag or rewrite it to reflect only the hop that occurred on Australian soil. Most carriers rewrite the value to keep wholesale settlement honest, but this can confuse engineers who compare traces against the originating switch in another country. Timing constraints around adjacent ISUP timers can compound the problem, since the gateway has only a short window to alter the message before sequencing rules kick in.
Comparing II with adjacent ISUP parameters
| Parameter | Primary purpose | When it is updated | What it tells the receiver |
|---|---|---|---|
| Intermediate Indicator (II) | Marks whether intermediate networks have transited the call | Set by the first intermediate signaling point, preserved by later hops | Whether to apply transit charging |
| Hop Counter | Counts remaining allowed signaling hops | Decremented by each forwarding switch | How close the call is to the maximum hop limit |
| Calling Party Category | Identifies the type of originating subscriber | Set by the originating exchange | How the receiving network treats the caller for billing |
| Transmission Medium Requirement | Indicates the requested bearer type | Set by the originator, rarely changed | Whether to reserve a speech, data, or 64 kbps channel |
These four fields travel together in most IAMs but answer different questions. A practical habit is to read them in a fixed order and compare II against the hop counter. If II says "one intermediate network" but the hop counter only dropped by one from its initial value, the call transited a single signaling point. If the hop counter dropped further, the trace deserves a closer look.
A useful next step is to reproduce one of those scenarios in a lab using a vendor or open-source ISUP simulator, recording the IAM byte by byte, and confirming that your understanding of II matches the bytes on the wire.
