Reading ISUP Release Cause Codes in Real Networks
ISUP release cause codes explain why a circuit-switched call ended, failed to progress, or was rejected before answer. They appear in REL messages and other signaling exchanges, giving engineers a standardized starting point for investigating call routing, subscriber status, interworking, and network availability.
A cause value is useful only when read in context. The same code can point to a normal customer action, a routing problem, a congested switch, or a signaling translation issue. The affected trunk group, message direction, call state, and neighboring network all influence the correct interpretation.
Understanding ISUP release cause codes every engineer should know helps reduce misdiagnosis. It also makes trace analysis faster across SS7, SIGTRAN, legacy PSTN, and mixed TDM-IP environments.
What ISUP Release Causes Represent
In ISUP, a release cause is carried in the Cause Indicators parameter. The value generally identifies the reason a call was cleared or could not be established. It may be generated by the originating exchange, a transit switch, the destination network, or an interworking gateway.
The code does not always identify the original fault. A transit switch may receive a routing failure and send its own normalized cause toward the originating side. Engineers should therefore compare both call legs and inspect IAM, ACM, ANM, REL, and RLC messages rather than treating one value as absolute proof.
The Main Cause Code Families
Cause 16, “normal call clearing,” usually indicates that the call ended normally, often after a BYE-like user action represented through ISUP signaling. Cause 17 means the called user is busy, while 18 and 19 distinguish no response from no answer after alerting. Cause 21 indicates rejection, and 20 commonly means the subscriber is absent.
Routing and numbering failures include cause 1 for an unallocated number, 2 for no route to a specific transit network, 3 for no route to the destination, and 24 or 28 for invalid or incomplete number information. Cause 22 signals a changed number, while 23 can indicate redirection to a new destination. These values often point toward digit analysis, translation, portability, or routing-table problems.
Common Codes In Live Call Traces
Network resource failures deserve close attention. Cause 34 means no circuit or channel is available, 38 indicates network out of order, 41 indicates temporary failure, and 42 points to switching equipment congestion. Cause 44 means the requested circuit or channel is unavailable, which can be narrower than the broader resource shortage represented by 34.
Interworking and protocol failures use another group of values. Cause 57 can indicate that the bearer capability is not authorized, 58 that it is unavailable, and 65 that it is not implemented. Cause 88 identifies an incompatible destination. Causes 96, 97, 98, and 111 are associated with missing information elements, unsupported message types, incompatible call states, or general protocol errors.
| Cause | Standard meaning | Typical investigation |
|---|---|---|
| 1 | Unallocated or unassigned number | Numbering plan and digit translation |
| 16 | Normal call clearing | User behavior and release direction |
| 17 | User busy | Destination status or call waiting logic |
| 18 | No response from user | Alerting, paging, and terminating access |
| 21 | Call rejected | Screening, barring, or policy rules |
| 28 | Address incomplete | Digit collection and overlap signaling |
| 34 | No circuit or channel available | Trunk capacity and circuit continuity |
| 38 | Network out of order | Remote switch and transport health |
| 41 | Temporary failure | Retry behavior and transient alarms |
| 42 | Switching equipment congestion | Processor, traffic, or route overload |
| 88 | Incompatible destination | Bearer, codec, or service compatibility |
| 102 | Recovery on timer expiry | ISUP timers and missing responses |
Read Causes With Message Flow
A cause code becomes more meaningful when paired with the message that carries it. A REL following an IAM may indicate that call setup failed before alerting. A REL after ACM may suggest that the destination was reached but the call later failed. An RLC confirms release completion, but it does not necessarily explain the original failure.
MTP3 transport context is equally important. Sequence numbers, service indicators, routing labels, and transfer messages can reveal whether the ISUP exchange was delivered to the intended signaling point. Engineers reviewing these fields can use this guide to understand MTP3 message types before interpreting an ISUP release in isolation.
Avoid Misreading Similar Values
Cause 17, 18, and 19 are frequently confused. A busy response is different from a subscriber who never responds, and both differ from a user who was alerted but did not answer. Mapping all three to “destination unavailable” removes valuable evidence about the access network and customer behavior.
Causes 34, 41, and 42 also require separation. A lack of available circuits suggests capacity or trunk allocation, a temporary failure may clear without intervention, and switching congestion can indicate an overloaded exchange. Check timestamps, route selection, traffic levels, and whether the code appears on one route or across the network.
Use A Consistent Diagnostic Method
Cause values should support, rather than replace, structured troubleshooting. Compare the originating and terminating point codes, verify the called digits, identify the first abnormal message, and correlate signaling with switch alarms, trunk utilization, and media-layer events.
For efficient analysis, apply these practices:
- Record the cause value, location, message type, and call direction.
- Compare failed calls with successful calls on the same route.
- Check numbering translations before escalating a network fault.
- Review ISUP timers when cause 102 or repeated partial call flows appear.
- Separate customer behavior from capacity, routing, and protocol failures.
A vendor may display a descriptive label that differs slightly from the Q.850 wording. Preserve the numeric value in reports, document local mappings, and confirm whether gateways rewrite causes during SS7-to-SIP or ISDN interworking.
Build Faster Signaling Investigations
A disciplined cause-code reference helps engineers move from a vague “call failed” alarm to a testable hypothesis. Over time, recurring values reveal route-specific congestion, faulty translations, incompatible services, or remote-network behavior that would be difficult to see from application logs alone.
Use these codes alongside packet captures, MTP3 analysis, ISUP call-flow diagrams, and timer knowledge to improve fault isolation across legacy and IP-based signaling networks. Apply the method to real traces and turn every release cause into a clearer operational decision.
