Q.850 cause 16 (Normal call clearing): what it means

Short answer: Q.850 cause 16 (Normal call clearing) is the normal ending: one of the parties hung up after the call was set up. It does not indicate a failure. It becomes a problem when many calls end with 16 within a few seconds, with no audio, or right after the IVR answers. In that case, check who sent the BYE and whether RTP flowed in both directions.

How Monitor treats cause 16

When the carrier gives the Q.850 cause in the Reason header of the SIP response, Monitor keeps it beside the SIP code on every test call, and it appears in the incident's evidence, ready for the ticket with the carrier. On the English screens, cause 16 reads: the call was cleared normally.

Like any failure, a test call read as Down is repeated 3 times, every 2 minutes, and only 4 failures in a row open an incident.

What does cause 16 mean in practice?

Q.850 cause 16, Normal call clearing, indicates the call was cleared because one of the users involved asked for it, in other words, someone hung up. It is the most common cause in any call log and does not represent a failure. On an SS7 link it travels in the ISUP REL message; on an ISDN E1, in the Q.931 DISCONNECT. In SIP there is no equivalent error response: RFC 3398 (section 7.2.4.1) says cause 16 normally results in a BYE or a CANCEL, often with Reason: Q.850;cause=16. In Asterisk it appears as hangup cause 16 in ${HANGUPCAUSE} and, in the CDR, as hangupcause 16 when the field is recorded. In 3CX logs and those of other PBXs, the same cause usually comes alongside the side that hung up. On LTE networks, the “cause code 16” in EMM messages is something else (MSC temporarily not reachable) and should not be confused with this cause.

When it appears

• On every answered call that ends when someone hangs up: this is the normal case.
• On calls lasting 1 to 3 seconds after the 200 OK, when the IVR answers and drops. The cause is normal, but the answer is not.
• When audio flows in only one direction and the person hangs up because they hear nothing: the log shows 16 and the real defect is in the media (NAT, firewall, SIP ALG).
• When a device clears the call on its own, because of a maximum call duration or missing RTP, and reports 16 in the BYE, because as far as signaling goes the clearing was orderly.
• On dialers that hang up when they detect voicemail or silence.

How to diagnose it

1. Split the cause 16 calls by duration. A high volume under 5 seconds deserves attention; the rest is usually normal.
2. In sngrep, see who sent the BYE: your side or the carrier. That tells you who hung up.
3. Check whether RTP flowed in both directions: in Asterisk, rtp set debug on shows the packets; in sngrep, the flow shows the RTP when it passes through the machine.
4. Open the BYE and read the Reason header. A cause=16 coming from the carrier right after the answer means the destination hung up.
5. If the drops happen at a fixed time (for example, always near 32 seconds), look for a lost ACK or a session timer: the hangup is automatic, even if it arrives with cause 16.

What to send the carrier

• Usually nothing: an isolated cause 16 is no reason to open a ticket.
• If there is a pattern, a list of short calls with date, time and time zone, the A and B numbers, and the duration of each.
• The Call-ID of each example and which side sent the BYE, with the Reason header.
• If audio was missing, the pcap with SIP and RTP showing the direction with no packets.
• When the pattern started and whether it repeats with the same destination.

Frequently asked questions

Is hangup cause 16 in Asterisk an error?

No. In Asterisk, `${HANGUPCAUSE}` equal to 16 means someone hung up in an orderly way, whether your user or the destination. It is the most common value in any call log. It is only worth investigating when it comes with very short durations, missing audio or complaints of dropped calls, because then the normal hangup may be the result of another problem.

Why does cause 16 have no SIP response code?

Because it is not a rejection. Under RFC 3398, cause 16 normally results in a BYE, when the call was already answered, or a CANCEL, when it was still ringing, with no status code. The value usually travels inside those messages in the `Reason: Q.850;cause=16` header, defined in RFC 3326.

Does a real test call help reveal when cause 16 hides a problem?

Yes, because it is a real call: besides the final SIP response, it checks the audio in both directions and measures voice quality (MOS-LQO). So a call that ends with cause 16 but has no audio does not go unnoticed. Failures are retried before they become an alert, and the alert goes out by email and SMS.