Troubleshooting Missing ISUP IAM Messages in Call Origination
An Initial Address Message (IAM) is the first major ISUP message sent when a circuit-switched call is established. It carries essential call details, including the called number, calling party information, transmission requirements and the Circuit Identification Code (CIC). If the IAM does not appear, the call may fail before alerting or setup begins.
For Australian carriers and enterprise voice teams, the fault can sit anywhere between the subscriber-facing platform and the outgoing SS7 route. A call from Sydney to Melbourne may cross several signalling nodes, while traffic from a regional exchange may use a different media gateway, STP pair or SIGTRAN association.
The phrase “missing IAM” also needs careful handling. The originating switch may have generated the message, but a trace taken at the destination may not show it. An IAM can be rejected, misrouted, filtered or lost across an IP-based signalling path, so the capture point determines what “missing” really means.
A methodical investigation avoids guesswork. Start with the call reference, identify the exact signalling leg, verify MTP3 routing and CIC allocation, then compare the expected ISUP sequence with what the network actually transmitted.
Where IAM Fits In The Call Sequence
In a typical outgoing call, the originating exchange seizes a circuit and sends an IAM towards the terminating exchange. The destination normally responds with an Address Complete Message (ACM), an Answer Message (ANM), a release message or a cause indicating why the call cannot proceed.
IAM relies on lower signalling layers. MTP2 transports the signalling link, MTP3 provides point-code routing and network management, and ISUP carries call-control information. In SIGTRAN networks, M2PA or M2UA may replace traditional signalling links, while SCTP carries the IP transport. A failure at any layer can make the ISUP message appear absent.
Confirming What Missing Means
First compare traces from both sides of the suspected boundary. A capture at the originating switch can prove whether the IAM was created. A capture at an STP, signalling gateway or remote exchange can show whether it was forwarded, translated or discarded.
Check whether the trace is filtered by OPC, DPC, CIC, call reference or message type. A display filter that excludes a translated point code can hide a valid IAM. Confirm the timestamp source as well, since clock drift between Sydney and Perth sites can make a message appear outside the expected call window.
Tracing From Subscriber To Trunk
Begin at the originating call-control system and follow the call through route selection, trunk-group seizure and signalling-link selection. Confirm that the destination number was normalised correctly, including the Australian national format, area code and any carrier-selection prefix.
Next, verify the selected route against the trunk configuration. The switch may attempt to seize a circuit while the associated ISUP route is administratively blocked. It may also select a CIC range that the far-end exchange does not recognise. These conditions can produce a failed call with no usable IAM at the expected destination.
Common Causes In Signalling Networks
Incorrect MTP3 routing is a frequent cause. An invalid destination point code, unavailable linkset or inconsistent route set can prevent delivery before ISUP processing begins. Check route status, signalling link utilisation and change logs around the first failed call.
Configuration mismatches are equally important. Look for incompatible nature-of-address indicators, numbering-plan values, transmission-medium requirements, CIC ranges and originating point codes. In a SIGTRAN environment, inspect SCTP association state, ASP availability, routing keys and traffic-handling modes.
| Observation | Likely fault area | Useful verification |
|---|---|---|
| No IAM at the originating switch | Call control or route selection | Trace call setup and trunk seizure |
| IAM leaves the switch but not the STP | MTP2, MTP3 or SIGTRAN transport | Check linkset, point codes and SCTP status |
| IAM reaches the STP but not the far end | Routing, screening or gateway translation | Compare routing keys and forwarding logs |
| Far end receives IAM with wrong fields | ISUP or numbering configuration | Decode IAM parameters and compare standards |
| IAM appears, then immediate release follows | CIC, circuit state or remote rejection | Correlate REL, RLC and cause values |
Evidence To Collect During Triage
Capture one successful call and one failed call using the same route where possible. A side-by-side comparison often exposes a missing message, an unexpected route change or a different CIC allocation.
Useful evidence includes:
- Full ISUP message traces with OPC, DPC and CIC
- MTP3 route and linkset status at the failure time
- SIGTRAN SCTP and application-server event logs
- Switch route, trunk and number-normalisation records
For teams building stronger protocol knowledge, SS7 training products can provide structured material on ISUP, MTP3, timers, call routing and signalling architecture. That background helps engineers interpret packet captures instead of treating each missing message as an isolated fault.
Comparing TDM And SIGTRAN Paths
The physical network technology changes the investigation path, but the ISUP logic remains recognisable. On a traditional TDM link, engineers focus on timeslots, signalling link alignment, alarms and circuit continuity. On SIGTRAN, the same call setup may depend on IP reachability, SCTP associations and signalling gateway routing.
Australian operators commonly run hybrid environments while migrating legacy PSTN functions towards IP infrastructure. A call can therefore cross a TDM exchange, an IP signalling gateway and a modern softswitch. Regional services may add longer operational paths and different maintenance windows, so compare the exact route rather than assuming all traffic behaves like a Melbourne metro call.
Restoring The Expected IAM Flow
After locating the break, apply the smallest controlled correction. A route-set change may require coordination between paired STPs, while a CIC correction must match both ends of the trunk group. For numbering issues, test local, national and international formats separately rather than changing every translation rule at once.
Validate the repair with a controlled call and a complete message sequence: IAM, ACM or an appropriate failure response, ANM where answered, and REL/RLC when cleared. Test calls between major cities and a regional destination if those routes use different interconnects. Record the trace, configuration change and observed result.
Final Checks Before Closing The Fault
A call should not be considered restored merely because a handset rings. Confirm that the IAM reaches the intended destination, contains correct parameters and uses the expected CIC. Check that answer supervision, charging data and release handling remain correct after the change.
Review monitoring thresholds for repeated IAM failures, unavailable signalling links and abnormal release causes. The practical next step is to capture one failed and one successful call from the originating switch through the first signalling gateway, then compare their OPC, DPC, CIC and route selection fields.
