Q.850 cause 31 (Normal, unspecified): what it means

Short answer: Q.850 cause 31 (Normal, unspecified) is a generic cause: it reports a normal event when no other cause in the normal class applies. On its own it does not indicate a failure. The trouble is that many gateways use it as a default value and hide the real reason. Look for the original SIP response and the Reason on the previous leg.

How Monitor treats cause 31

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 31 reads: an unspecified network fault.

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 31 mean in practice?

Q.850 cause 31, Normal, unspecified, is meant for reporting a normal event only when no other cause in the normal class applies. In other words, it is the cause used by whoever does not know, or does not say, the reason. Under RFC 3398 (section 7.2.4.1), cause 31 becomes SIP 480 Temporarily Unavailable. In the other direction it is even more common: the RFC sets 31 as the default value for any SIP response not in the table, and also for 488 and 606 when the Warning is not about bearer capability. That is why a cause 31 on your PBX can come from dozens of different SIP responses. It appears in the ISUP REL, in a Reason: Q.850;cause=31 and, in Asterisk, in ${HANGUPCAUSE}. In LTE, the “cause code 31” in ESM messages (Request rejected, unspecified) comes from a different table.

When it appears

• A SIP-TDM gateway that receives a SIP response with no match in RFC 3398 and applies the default 31.
• A media negotiation failure (488 or 606) without a Warning about the bearer.
• Carriers that use 31 as a generic response to any rejection.
• Calls to a mobile phone that is switched off, on networks that do not give the reason in detail.
• Older equipment that does not implement more specific causes.

How to diagnose it

1. Do not stop at cause 31: find the original SIP response with pjsip set logger on (or sip set debug on) or in sngrep.
2. If the 31 came from the carrier in a Reason, ask it for the original cause or response from the destination network.
3. Group the cause 31 calls by destination and time. A single destination points to the far end; many destinations point to the route.
4. See whether there was a 488 or 606 with a Warning: then the problem is the codec, not the network.
5. In Asterisk 11 or newer, the HANGUPCAUSE function with the tech type keeps the SIP response for each dialed channel; write it to the log next to the cause.
6. In 3CX, turn on Verbose logging so the Activity Log shows the full SIP response.

What to send the carrier

• Date, time and time zone of the attempts.
• The A and B numbers.
• The Call-ID, the SIP response received and the Reason with cause=31.
• An explicit request for the original cause on its leg of the call, since 31 does not identify the reason.
• The pcap, if you have it, and the list of affected destinations.

Frequently asked questions

Is cause 31 an error?

By definition, no: it belongs to the normal class and only says there is no more specific cause. In practice, it shows up a lot in real failures, because gateways use it as a default value when they do not know how to translate a SIP response. If calls with cause 31 are not completing, treat it as a failure and look for the original response.

What is the difference between cause 16 and cause 31?

Cause 16 (Normal call clearing) says someone hung up an established call. Cause 31 (Normal, unspecified) says there was a normal event with no specific cause, and it usually appears on calls that never even completed. 16 is the expected end of a conversation; 31 calls for investigation when it repeats.