ISUP Cause Code 16 and the Meaning of Normal Call Release
In Signaling System No. 7, an ISUP Release message explains why a circuit-switched call is being cleared. Cause code 16 indicates that the call ended normally. It is a routine signaling event, not evidence of congestion, a faulty trunk, or a failed call attempt.
Understanding this distinction helps engineers interpret traces, validate call routing, and separate expected subscriber behavior from genuine network faults. The release cause appears in the Cause Indicators parameter carried by the REL message and should be read together with the preceding call flow.
Reading the ISUP Release Sequence
A typical ISUP call begins with an Initial Address Message (IAM), which reserves signaling and bearer resources. Depending on the call state, Address Complete Message (ACM), Call Progress (CPG), and Answer Message (ANM) may follow. When either side ends the conversation, the network sends a Release (REL) message.
With cause value 16, the REL message states that the call is being cleared because the user or application has completed the call normally. The receiving exchange then releases the associated circuit and returns a Release Complete (RLC) message. Once the RLC exchange is complete, the circuit can be made available for another call.
Engineers studying this sequence can use SS7 training resources to review ISUP message fields, MTP3 delivery, timers, and call-state transitions in greater depth.
Why Cause Code 16 Matters
The phrase “normal clearing” generally means that a connected call ended through an ordinary hang-up or an equivalent service action. On a mobile network, this may occur when a subscriber presses the end-call button. In a fixed network, it may reflect the calling or called party going on-hook.
Cause code 16 does not describe call quality. A conversation could have experienced audio problems and still end with normal clearing. Conversely, an abnormal disconnection may produce a different release cause, such as temporary failure, no circuit available, user busy, or recovery on timer expiry.
For billing and analytics, cause 16 commonly represents a completed or normally terminated call leg. However, billing systems should also inspect answer status, call duration, charging indicators, and the complete signaling record rather than relying on the release cause alone.
How Signaling Components Handle It
The ISUP layer defines the meaning of the release cause, while lower signaling layers transport the message. In traditional SS7, MTP2 and MTP3 carry the signaling data between exchanges. In IP-based deployments, SIGTRAN protocols such as SCTP and M3UA transport the SS7 user part without changing the interpretation of cause value 16.
| Signaling element | Role in normal clearing | Practical interpretation |
|---|---|---|
| REL | Requests call release | Includes cause indicator 16 |
| Cause Indicators | Describes the release reason | Normal call clearing |
| RLC | Confirms release completion | Circuit is returned to an idle state |
| MTP3 or M3UA | Routes signaling messages | Delivers ISUP between signaling points |
| Circuit state | Tracks bearer availability | Moves from occupied to idle after release |
The exact message direction depends on which exchange detects the end of the call. A serving switch, transit exchange, gateway, or interworking element may initiate the REL. The important point is that the receiving node must process the release and complete the circuit release procedure correctly.
Distinguishing Normal Clearing from Faults
A trace showing cause 16 after ANM is usually straightforward: the call was answered, remained established, and then ended normally. A REL with cause 16 before ANM can require closer analysis. Some services release a call before answer for legitimate reasons, so the cause alone does not prove that the call was successfully connected.
The timing and message order provide essential context. Look for missing RLC messages, repeated release attempts, unexpected timer expiry, circuit seizure conflicts, or a new IAM arriving before the old circuit is fully idle. These patterns may indicate signaling or resource-management problems even when the REL itself contains cause 16.
It is also useful to compare both call legs at an interworking boundary. A gateway may translate a SIP BYE, ISDN disconnect, or another release event into an ISUP REL with cause 16. Differences between the incoming and outgoing cause values can reveal mapping rules, normalization policies, or an intermediary that is rewriting release information.
Operational Checks for SS7 and SIGTRAN Networks
When investigating normal call release, examine the complete call reference rather than isolated messages. Correlate the CIC, point codes, linkset, signaling link, timestamps, and, where available, transaction or trunk identifiers.
The following checks help confirm that the release procedure is healthy:
- Verify that the REL contains a valid Cause Indicators parameter with value 16.
- Confirm that the expected RLC follows within the configured signaling interval.
- Check that the circuit changes to idle and is available for subsequent IAM messages.
- Compare release behavior across originating, terminating, and transit exchanges.
- Review SIGTRAN association, M3UA routing-key, and SCTP stability when messages are delayed or lost.
Network teams can also compare release-cause distributions over time. A sudden increase in cause 16 may reflect changed subscriber behavior, a service-platform update, or a new gateway mapping rule. A simultaneous increase in timer expiry or incomplete RLC exchanges points toward a signaling reliability issue instead.
Applying the Cause in Network Design
Cause code 16 should be preserved accurately when protocols are converted between SS7, SIP, ISDN, and other telecom interfaces. Poor mapping can turn an ordinary hang-up into a misleading failure code, distorting customer reports, call-detail records, and routing statistics.
For teams reviewing signaling architecture or service integration, telecom solutions can provide useful context for connecting protocol behavior with operational systems. Documentation should state which component originates REL, which component returns RLC, and how release causes are translated across each boundary.
A clear test plan should include answered calls, unanswered calls, caller release, called-party release, gateway-initiated clearing, and delayed responses. Capturing these scenarios in a protocol analyzer makes it easier to verify message order, cause preservation, circuit handling, and timer behavior.
Use cause value 16 as a precise diagnostic signal: it normally means the call has ended by ordinary clearing. Validate that interpretation against the full ISUP sequence, circuit state, and any interworking layer, then incorporate the result into trace analysis and monitoring rules.
