Q.850 causes

Q.850 cause 17 (User busy): what it means

Short answer: Q.850 cause 17 (User busy) means the destination did not accept the call because it was busy. It is a normal cause: the network worked and the destination's equipment is compatible. It becomes a problem when an 0800 number, an IVR or a trunk returns busy often, which usually means a channel limit has been reached. Compare concurrent calls with what you contracted.

Cause 17 in the reference
Cause17
Official name (ITU-T Q.850)User busy
ClassNormal event (1 to 31)
SIP response per RFC 3398SIP 486 Busy Here

How Monitor treats cause 17

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 17 reads: the line was busy.

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

Q.850 cause 17, User busy, is used when the destination cannot take another call because it is busy. The called equipment is compatible and the network worked; it was the destination that refused. Under RFC 3398 (section 7.2.4.1), cause 17 becomes SIP 486 Busy Here, and in the other direction both 486 and SIP 600 Busy Everywhere map back to 17. On SS7 links it comes in the ISUP REL; on ISDN E1, in the DISCONNECT; in SIP, sometimes in a Reason: Q.850;cause=17. In Asterisk, ${HANGUPCAUSE} is set to 17 and DIALSTATUS is usually BUSY. Many PBXs also respond 486 when they hit a concurrent call limit, so “busy” does not always mean a person on the phone: it may just be capacity running out.

When it appears

  • The person is already on another call, with no call waiting.
  • A mobile user who rejects the call: many networks return busy in that case.
  • An extension with “do not disturb” set to respond busy.
  • A concurrent call limit reached on the extension, the contracted SIP trunk or the PBX license.
  • An 0800 number or IVR with every channel in use at peak time.
  • A call queue configured to return busy when it fills up.

How to diagnose it

  1. Call from another line at the same moment. If it is always busy, suspect a limit, not a busy person.
  2. In Asterisk, core show channels shows how many calls are active; compare it with the number of channels in the contract.
  3. In sngrep, see where the 486 came from: your PBX, the SBC or the carrier. The Server or User-Agent headers in the response help.
  4. Check the call limits configured on the extension and the trunk (FreePBX, Issabel) and on the 3CX license, when it limits concurrent calls.
  5. See whether the busy responses cluster at peak hours, which points to a lack of capacity.

What to send the carrier

  • Date, time and time zone of the attempts that returned busy.
  • The A and B numbers and how many attempts in a row failed.
  • The Call-ID, the SIP/2.0 486 Busy Here line and the Reason received.
  • How many concurrent calls there were on your side at the time (the output of core show channels).
  • If the destination is one of your 0800 numbers, the number of channels contracted for it.

Frequently asked questions

Is cause code 17 on a mobile phone the same as Q.850 cause 17?

No. On LTE mobile networks, the 'cause code 17' that shows up in modem or phone logs comes from the 3GPP EMM causes and means Network failure. Q.850 cause 17 is the busy cause in telephony, used in ISUP, ISDN and the SIP Reason header. The numbers match; the tables do not.

Is a busy signal on my 0800 number always the carrier's fault?

Not necessarily. If the 486 comes from your PBX or your IVR, the limit is yours: channels, license or queue configuration. If it comes from the carrier before reaching your equipment, it may be the channel limit in the 0800 contract. The trace shows who responded, and that decides who to open the ticket with.

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.