Q.850 causes

Q.850 cause 41 (Temporary failure): what it means

Short answer: Q.850 cause 41 (Temporary failure) means the network is not working correctly, but the condition should be short-lived, so a new attempt right afterward may complete. It is one of the most common causes because SIP 400, 481, 500 and 503 all become 41. Look for the original SIP response to find the real reason.

Cause 41 in the reference
Cause41
Official name (ITU-T Q.850)Temporary failure
ClassResource unavailable (34 to 47)
SIP response per RFC 3398SIP 503 Service Unavailable

How Monitor treats cause 41

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 41 reads: a temporary network failure.

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

Q.850 cause 41, Temporary failure, means the network is not working correctly and the condition is probably not going to last long: the user can try another call almost immediately. Under RFC 3398 (section 7.2.4.1), cause 41 becomes SIP 503 Service Unavailable. What makes it so frequent is the other direction: the same RFC maps SIP 400 Bad Request, 481 Call/Transaction Does Not Exist, 500 Server Internal Error and 503 Service Unavailable to 41. So a cause 41 on your PBX may originally be a message format error or an internal failure on a SIP server. It arrives in the ISUP REL, the ISDN DISCONNECT and a Reason: Q.850;cause=41. In Asterisk, ${HANGUPCAUSE} is set to 41, and the CDR shows hangupcause 41 when it records the field.

When it appears

  • A restart or momentary overload of a carrier SBC or proxy.
  • A 500 error on some SIP server along the path, translated into 41 by a gateway.
  • A malformed SIP message (400) generated by your PBX, for example with an invalid header.
  • A carrier server switchover during maintenance.
  • A brief flap of the link between your site and the carrier.

How to diagnose it

  1. Try again in a few seconds. If it completes, note the time and keep an eye on the frequency.
  2. Find the original SIP response in sngrep or with pjsip set logger on: 400, 481, 500 and 503 lead to different investigations.
  3. If it is a 400, read the status line and the Warning: many carriers say there which header they rejected.
  4. If it is a 503, see whether there is a Retry-After and respect the interval.
  5. In 3CX, turn on Verbose logging to record the full response in the Activity Log.
  6. If the failures repeat at the same time of day, cross-check them with the carrier’s maintenance windows.

What to send the carrier

  • Date, time and time zone of each failure, and the frequency (for example, how many per hour).
  • The A and B numbers.
  • The Call-ID and the full SIP status line received, with the Reason and the Warning.
  • Whether a new attempt right afterward completed.
  • The pcap of the call that failed.

Frequently asked questions

If cause 41 is temporary, do I need to open a ticket?

For an isolated occurrence that completes on the next attempt, usually not. If cause 41 repeats several times a day, or always on the same destination, it is no longer passing in practice, and it is worth opening a ticket with the times, the Call-IDs and the original SIP response for each failure.

Does a real test call tell a passing failure apart from one that lasts?

A real test call gets the network's final SIP response, like any call. When it fails, the attempt is retried before it becomes an alert. So a failure that disappears on retry raises no alarm, and one that persists becomes an alert sent by email and SMS.

Know before your customers do

Monitor calls every voice circuit all day and delivers each failure with the SIP code and the Q.850 cause as evidence.