Analyzing Backward ISUP Call Setup With Cause Indication
An ISUP call is established through a controlled exchange of signaling messages between originating and terminating exchanges. The Initial Address Message (IAM) travels forward, while messages such as the Address Complete Message (ACM), Call Progress (CPG), and Answer Message (ANM) travel backward toward the caller’s network.
A backward call setup analysis becomes especially valuable when the call appears to progress but later fails, when early media is unexpected, or when a release cause does not match the observed network behavior. The key is to correlate message direction, message sequence, cause value, timers, and circuit state rather than examining a single parameter in isolation.
Engineers working with SS7 and SIGTRAN can use the SS7 training resource to reinforce concepts involving ISUP, MTP3, call routing, and protocol traces. Those fundamentals make it easier to distinguish a genuine network fault from a normal interworking condition.
Reading The Backward Signaling Direction
The backward path begins when the destination exchange has received enough information to process the IAM. An ACM generally means that the destination side has analyzed the called number and that address completion has occurred. It does not mean that the called party has answered.
A CPG may follow when the destination exchange reports an intermediate event, such as alerting, call forwarding, interworking, or progress toward the subscriber. An ANM indicates that the call has been answered. If ANM never appears, the call has not reached the connected state from the ISUP perspective, even if a user hears ringing or an announcement.
The backward direction should therefore be read as a state transition. ACM shows progress through address analysis, CPG provides an event update when applicable, and ANM confirms answer. A later REL changes the outcome to release and must be examined together with its cause information.
Locating The Cause Information
The most important cause-related field is usually the Cause Indicators parameter in a Release Message (REL). It contains a cause value, coding standard information, location information, and, depending on the profile, diagnostic details. The cause value is commonly interpreted using Q.850 or a national ISUP specification.
Cause indication is not automatically evidence that the backward setup failed. Some variants permit cause-related information in other messages, and an optional cause parameter may describe a progress condition or an interworking result. Always identify the message carrying the parameter before assigning meaning to it.
A release with cause 16, “normal call clearing,” is very different from cause 17, “user busy,” cause 18, “no user responding,” or cause 34, “no circuit/channel available.” The same numerical value can also be presented differently by a local implementation, so the protocol version and operator-specific mapping must be checked.
Following The Message Sequence
Start with the IAM and verify that the called party number, numbering plan, nature of address, and routing digits are correct. An incorrect digit string can produce a legitimate backward response followed by a release, making the failure appear to be a congestion or subscriber problem.
Next, record the timestamps for ACM, CPG, ANM, REL, and RLC. The interval between IAM and ACM can reveal address-analysis delay, while the period between ACM and ANM shows how long the call remained in alerting or progress. RLC confirms that the circuit has been released and that the signaling transaction is complete.
A useful trace also includes circuit identification code (CIC), point codes, linkset information, and the transport path. In SIGTRAN networks, SCTP association events, M3UA routing contexts, and link congestion can explain missing or delayed ISUP messages even when the application-level call flow looks valid.
Distinguishing Common Outcomes
The sequence and cause value should be interpreted together. An ACM followed quickly by REL with a busy cause suggests a subscriber or service state, while an IAM followed by REL with an unavailable-circuit cause points toward resource allocation or routing capacity. An ANM followed by REL with normal clearing represents an established call that ended normally, not a failed setup.
| Observed Sequence | Likely Meaning | Checks To Perform |
|---|---|---|
| IAM → ACM → ANM | Normal answer | Confirm voice path and charging state |
| IAM → ACM → REL, cause 17 | Called user busy | Check subscriber state and busy treatment |
| IAM → ACM → CPG → REL, cause 18 | No response or alerting timeout | Review ringing duration and T7-related behavior |
| IAM → REL, cause 34 | No available circuit or channel | Check trunk occupancy and CIC selection |
| IAM → ACM → ANM → REL, cause 16 | Connected call cleared normally | Compare release timing with user hang-up |
| IAM with no backward response | Signaling or routing failure | Inspect point codes, links, timers, and transport |
Correlating Cause With Timers And Media
Timers help establish whether a cause was generated promptly by a remote exchange or locally after a timeout. T7 is associated with waiting for an ACM or CON after IAM, while other timers govern alerting, answer supervision, and release procedures according to the applicable ISUP specification. A locally generated cause after timer expiry should not be mistaken for the original remote fault.
Media observations are useful but secondary. Ringback heard by the caller may be generated locally, received as backward audio, or inserted by an interworking gateway. Early media can also carry announcements before ANM, so hearing a message does not prove that the called party answered.
Compare the ISUP trace with bearer-channel measurements, continuity checks, and switch logs. If signaling shows CPG but the bearer is silent, investigate media anchoring and gateway behavior. If audio is present before ANM, verify whether the operator permits in-band information during call progress.
Applying A Disciplined Analysis Method
A repeatable workflow prevents assumptions based on familiar cause descriptions. Capture the complete transaction from IAM through RLC, decode each parameter using the correct regional profile, and compare the trace with a successful call using the same route and CIC range.
Use these practical checks:
- Confirm message direction and sequence before interpreting any cause value.
- Decode the full Cause Indicators parameter, including location and diagnostics.
- Compare timer expiry with the timestamp of the generated REL.
- Track CIC, point codes, routing context, and trunk-group selection across nodes.
- Correlate ISUP events with bearer status, announcements, and SIP or media-gateway logs.
The final diagnosis should state where the call changed state, which network element generated the cause, and whether the condition was subscriber-related, resource-related, routing-related, or transport-related. That level of detail is more useful than reporting only a Q.850 number.
Use this method when reviewing live traces, lab exercises, or intercarrier disputes. Build a baseline from successful calls, preserve the complete signaling context, and document each backward event so that routing, operations, and protocol teams can act on the same evidence.
