ISUP release cause codes: decoding common call failure reasons

ISUP release cause codes are the values carried in the Release Message when an SS7 call leg is cleared. They can quickly narrow a fault, but a number alone is rarely a diagnosis. Decoding one requires the applicable ITU-T Q.761 meaning, the switch vendor’s release cause table and the surrounding MTP3 or SIP evidence.

A useful model separates cause, reason and location. The Release Message identifies the triggering condition, while optional diagnostics can add a reason and network location. This matters when an Australian mobile call crosses carriers or reaches an IP interconnect: the last visible release may describe the end point rather than the originating fault.

Modern networks add NBN VoIP, OTT calling and handset handovers to the mix. The result is a practical troubleshooting problem, not a simple lookup list: every code must be read in the context of the route, platform and customer symptom.

Why release causes matter

ISUP supports call setup, bearer supervision and release. A failed leg commonly shows an Address Complete Message, a Release Message with cause information and a Release Complete confirmation. Reading those messages in sequence shows whether setup reached the far end and whether the release was local, remote or generated during an interworking conversion.

Do not transfer a Q.850 interpretation blindly into ISUP. Some decimal values look familiar, but the semantic mapping and the amount of diagnostic detail vary between platforms. Always record whether the log prints decimal or hexadecimal values and which side originated the Release Message.

Common failure families

Common failures fall into several families: routing and numbering, subscriber status and authorisation, called-party outcomes, and network resources or capabilities. Common tables often render decimal 11 as user busy, 12 as no answer, 17 as call rejected and 28 as invalid number format.

Other familiar values include normal release, often shown as 31, congestion as 41, access barred as 42 and incompatible destination as 47. These are mappings, not universal constants: vendor extensions and translations can differ. Busy, no answer and rejection may produce a technically completed release while still representing a failed customer call.

Tracing a failed call in Australia

Consider a Brisbane mobile call to a Melbourne PBX. It may traverse infrastructure operated by Telstra, Optus or Vodafone before crossing a carrier or IP interconnect. Point codes and transaction identifiers must then show whether the far end sent the release or merely acknowledged a release initiated locally.

Daily conditions matter too. Sydney and Melbourne commuters often move between cellular and Wi-Fi coverage, sometimes using dual-SIM handsets, while NBN-hosted VoIP may meet legacy-style carrier interconnect. A handover loss is different from an unreachable NBN endpoint, even when both reach the customer as a dropped call.

Matching codes to customer symptoms

Match the code to timing and behaviour. Busy normally returns promptly, no answer follows the ringing timer, and an access bar usually rejects the attempt before normal ringing. Congestion often appears at the same time as trunk occupancy or platform alarms. In a busy Melbourne rail corridor, handset evidence can separate network congestion from a genuinely unanswered handset.

Some Australian support requests involve poker-machine venues or gaming providers and concern bank-transfer payments. The POLi payment guide explains that payment path. If the payment succeeds while the voice call fails, keep the application transaction and ISUP release timeline separate; one outage should not be inferred from the other.

Where trace data misleads

Release logs can obscure their origin. Interworking gateways may translate cause values, and a platform may display a vendor label rather than the Q.761 description. The final Release Complete is not proof that the final Release Message came from the faulty exchange, which is why point codes and message direction remain essential.

Trace portals can also show a filtered record set. A discussion of dark pool trading illustrates how a visible feed can conceal activity outside the displayed view. The comparison is limited, but the operational lesson holds: a summary showing only the final code can omit IAM, ACM or release acknowledgements that change the interpretation.

Security and regulation in legacy interworking

5G deployment does not remove every legacy signalling dependency. IP-based 5G cores commonly use Diameter and service-based interfaces, yet interconnects with PSTN, older mobile cores or enterprise gateways may still involve SS7, SIGTRAN and media gateways. The broader risks in 5G SS7 security are directly relevant when an ISUP release follows interworking.

Australian operations are also shaped by ACMA, which administers the Telecommunications Act 1997, and the Australian Do Not Call Register operating under the Spam Act 2003. A rejected marketing call may therefore look like ordinary rejection in the network. Cause evidence must still be separated from questions about consent, caller identity and carrier compliance.

Diagnostic workflow for common failures

For an operational ticket, use a repeatable sequence that links the code to evidence rather than relying on the decimal value alone:

• Confirm the platform and cause catalogue, including decimal or hexadecimal format and any interworking translation.
• Collect IAM, ACM, REL and RLC records with timestamps, point codes and transaction identifiers.
• Keep cause, reason and location separate, and identify which network domain originated the release.
• Correlate the event with trunk occupancy, alarms, handset behaviour and application logs.
• Check whether the route used roaming, handover, NBN VoIP, number portability or an interconnect.
• Protect signalling payloads and subscriber details when exporting traces or sharing them outside the carrier.

An ISUP release cause is evidence, not a verdict. The dependable interpretation comes from matching the value to the exact platform, tracing the complete message sequence and identifying the function that actually failed, while keeping customer impact separate from the technical cause of release.