SIP 486 Busy Here

What the response actually means

RFC 3261 is careful about the scope. 486 says the request reached the callee's end system and that end system will not take another call — but it explicitly leaves room for somewhere else to answer, which is why a proxy is entitled to keep trying other contacts or a voicemail system. Its neighbours differ in exactly that respect:

• 480 Temporarily Unavailable — contacted, but nothing there to ring: not registered, logged out, do-not-disturb.
• 603 Decline — the user was asked and actively refused.
• 600 Busy Everywhere — busy on behalf of the user everywhere, so stop looking. Rare in practice, and a proxy is obliged to take a 6xx seriously.

A 486 may carry Retry-After. It is worth reading, because a machine that bothers to tell you when to come back is usually doing capacity control rather than reporting a human being on the phone.

What actually causes it

Admission control on an SBC or PBX

Session limits, concurrent-call caps per trunk or per customer, and burst-rate limits all have to reject something once they bite. Which code they use is vendor- and configuration-dependent — 486 and 503 are both common — so the code alone does not identify the mechanism. The load pattern does: capacity rejections cluster at busy hour, apply across unrelated destinations, and stop when concurrency drops.

A full hunt group, queue or line appearance

The PBX has run out of places to put the call. Distinguishable from a busy handset because the rejection typically arrives before any 180 Ringing, and repeats for every caller into that group rather than for one extension.

Q.850 cause 17 arriving from the PSTN

On an interworked call, RFC 3398 maps ISUP cause 17 (user busy) onto 486, and back the other way. If the far end is a gateway, look for a Reason header (RFC 3326) of the form Reason: Q.850;cause=17;text="user busy". That header is the single most useful thing in the whole message: it tells you the verdict was made in the TDM network, not by any SIP element in your path, and it hands you the cause value to take to the carrier.

Beware the sibling cause: 34, "no circuit/channel available", is congestion rather than a busy user and maps to 503. If a carrier is returning 486 where you would expect 34, that is worth a conversation, because the two are handled very differently by most retry logic.

A genuinely busy device

Still real. Many phones also emit 486 rather than 603 when the user presses the reject key, so a 486 that lands a second or two after 180 Ringing usually means a human, and a 486 that lands before any ringing usually does not.

What to check in the trace

1. Time from INVITE to 486. Under about 100 ms means the decision was local to the first box in the path — no signalling had time to reach a phone.
2. Whether a 180 Ringing preceded it, and whether the To tag on the 486 matches the branch that was ringing.
3. Reason, Retry-After, Warning, and any Server or User-Agent header. Vendors are much more candid in these than the status line suggests.
4. Via depth: did the 486 traverse the whole path, or does it appear only on your ingress leg with no corresponding rejection on the egress leg? The second case means your own SBC decided it.
5. Concurrency at that moment. Count the calls that were up on the same trunk when the rejection happened, and compare it with a configured limit. Admission control is the only cause on this list that correlates with a number.
6. Whether the call forked. With a forking proxy, one branch returning 486 does not end the call — the proxy picks a single final response from all branches, preferring a 6xx if one arrived and otherwise the lowest response class it collected.