Q.850 cause codes

Where Q.850 appears in SIP

ITU-T Q.850 defines the cause values carried in ISUP REL and Q.931 DISCONNECT messages — the PSTN's entire language for "why this call is over". The two vocabularies do not line up: Q.850 has over a hundred causes, SIP a few dozen relevant statuses, so a gateway has to translate. RFC 3398 is the dictionary; the tables below are its defaults.

Because the translation loses detail in both directions, SIP grew a way to carry the original alongside it: the Reason header of RFC 3326, as in Reason: Q.850;cause=34;text="No circuit/channel available". You will meet it on BYE and CANCEL requests, and — since RFC 6432 made it explicit — on final responses too. One message may carry two Reason values, one SIP and one Q.850: the same event described from both sides of a gateway.

This is why the Reason header outranks the status code. A bare 503 might be nothing more than your own SBC's overload control; a 503 carrying Reason: Q.850;cause=34 was minted from a real ISUP release behind the trunk, by the network that actually failed.

The full cause-to-SIP mapping table

This direction answers "the carrier released with cause N — what status will my SIP leg see?". These are RFC 3398's defaults; almost every SBC and gateway exposes an override table, so a trace that disagrees with this one is configured, not broken.

Cause 44 is the one entry above that RFC 3398 does not enumerate by name: gateways map it, with the rest of the resource-unavailable class, to 503 — where the whole congestion family ends up anyway.

The reverse direction — the cause a gateway writes into the ISUP REL when the SIP leg says no — is also defined by RFC 3398:

Put the two tables side by side and you can watch information being destroyed. Causes 34, 38, 41 and 42 all become 503, and a 503 crossing back into ISUP becomes 41 — so whichever member of the congestion family a cause started as, two gateways later it is "temporary failure". Only the Reason header survives the round trip — when the boxes in the middle are polite enough to copy it.

The causes you actually meet

• 17 User busy — the genuine article: the far end is engaged. Arrives as 486; nothing to fix on your side.
• 18 No user responding versus 19 No answer from user — 18 means the destination never even alerted; 19 means it rang and nobody answered before the network's answer timer gave up. 18 points at a dead or misconfigured endpoint, 19 at an absent human.
• 21 Call rejected — a deliberate refusal by the subscriber's equipment or a screening service; the location field tells you which. RFC 3398 prefers 603 Decline over 403 when the user themselves said no.
• 28 Invalid number format — too few digits or the wrong shape of digits: a missing prefix, a national number where E.164 was expected, an overlap-dial string cut short. Check the called number against the trunk's numbering plan before blaming the carrier.
• 31 Normal, unspecified — the carrier's shrug: the catch-all of the normal-event class, carrying almost no diagnostic weight on its own.
• 41 Temporary failure — transient trouble, worth a retry — though a 41 that arrived over SIP may have been any 5xx once.
• 102 Recovery on timer expiry — an ISUP or Q.931 procedure timer expired: the PSTN's own request timeout. It maps to 504, and 408/504 map back to it — one of the few round trips that survives intact.
• 127 Interworking, unspecified — the failure happened in, or crossed, a network that does not speak Q.850, so no truer cause exists. Most SIP-side rejections pushed into ISUP land here, hence both common and uninformative.

Cause 16 is not an error

Cause 16, normal call clearing, means exactly what it says: somebody hung up. On a BYE it is routine teardown and belongs in no failure report — which does not stop a remarkable number of CDR tools counting it as one. It is the most common cause value in any healthy network.

The one place cause 16 deserves attention is on a call that was never answered. Usually the release was still normal — the caller abandoned and a CANCEL became that REL — but it can also be a far-end platform "politely" clearing a call it never intended to complete. The question is not "why cause 16?" but "who released, from which direction, how long after the call started?". The cause is innocent; the timing sometimes is not.

The congestion family: 34, 38, 42, 44

Four causes, one SIP status, four different problems. 34 — no circuit/channel available means full: every trunk on some segment of the route is in use. Capacity, transient, and an immediate retry — especially one the carrier can route differently — often succeeds. 42 — switching equipment congestion means the switch itself is overloaded: processing, not trunks. Same advice, but if it persists through quiet hours something is genuinely sick.

38 — network out of order is the serious one: not full, broken. Q.850 intends it for failures likely to last a while, so a burst of cause 38 is an outage signal, not a load signal. Retrying into it achieves nothing.

44 — requested circuit/channel not available is the odd sibling: a specific circuit was requested and refused. On ISUP that smells of a CIC state mismatch or glare (both ends seizing the same circuit at once); on a PRI, a channel-map disagreement. Unlike 34 it is usually configuration wearing a congestion costume — a trunk group that throws 44 repeatedly needs an audit, not a quieter hour.

What to check in the trace

1. Search the whole dialog for Reason: headers — on the BYE, the CANCEL and the final response. A Q.850;cause= value beats any amount of inference from the status code.
2. Note which direction the release travelled. Whoever sent the BYE, or the response carrying the cause, owns the network that holds the answer.
3. Compare the status against the table above. A pair that breaks the RFC 3398 default — a 480 carrying cause 17, say — means a box in the path runs a custom mapping, and its configuration is now part of the investigation.
4. A 503 with no Reason header may never have touched the PSTN: SBCs mint bare 503s for their own overload and licensing limits. Provenance first, meaning second.
5. Watch for double translation. If the status arrived as 503 and the cause as 41, the original may still have been 34, 38 or 42 one network away.
6. If you can see the ISUP or Q.931 side, read the cause's location field — "user", "local network" or "transit network" narrows down who rejected the call better than the cause value itself.