Identify the transaction, responder and call leg
Capture one bounded failure and record the INVITE Call-ID, CSeq, request URI, response direction and responding address. A SIP 486 response is a busy outcome at the responding location; it does not identify the human action, device setting, channel limit or routing rule that produced it.
Determine whether Asterisk received 486 from a phone, provider or other next hop, or sent 486 back toward the caller after a local dial attempt. Preserve both legs when Asterisk is between participants. A display that says busy and a CDR disposition of BUSY are useful correlations, but neither replaces the original SIP transaction.
Keep SIP response, hangup cause and DIALSTATUS distinct
Asterisk's mapping table associates SIP 486 and 600 with AST_CAUSE_USER_BUSY, cause 17. The Dial application can expose DIALSTATUS=BUSY, and a CDR can record the BUSY disposition when the remote party was busy. These are related representations of an outcome, not evidence that every layer emitted the same code or that the reason was a physical handset already in a call.
Correlate the SIP trace, relevant channel's hangup cause, Dial result, CDR timestamp, unique ID and linked ID for the same attempt. Do not replace a specific upstream response with a generic busy label before the responsible leg is known.
Inspect loaded endpoint and device-state policy
For a local PJSIP endpoint, inspect the loaded endpoint, AOR, contacts and current channel or device state before editing configuration. Asterisk documents device_state_busy_at as the number of in-use channels that causes the endpoint's device state to report busy. That setting describes an Asterisk device-state threshold; it does not prove that a phone rejected an INVITE, that a queue obeyed that state or that a remote carrier returned 486.
Compare the loaded value with the intended call-waiting, queue, ring-group and voicemail design. If FreePBX generated the endpoint, use its supported interface and Apply Config path rather than editing generated PJSIP files. Record any change window and restore the prior threshold if the result differs from the approved call policy.
When a phone or upstream hop returned 486
Asterisk's PJSIP test plan treats a 486 received from the called party as a normal off-nominal busy exchange: Asterisk acknowledges the response and tears down that outgoing session, while a two-party path can return an error, preferably 486, toward the caller. This confirms transaction handling, not the operational reason the peer was busy.
Check the exact responding contact or trunk destination, active calls, do-not-disturb or call-waiting state and the peer's logs. For a carrier response, ask the provider to trace the same Call-ID and called identity. Do not infer account-wide capacity exhaustion or a platform outage from one destination's 486.
Verify dialplan busy treatment and fallback
Inspect the dialplan path after Dial() and how it handles DIALSTATUS=BUSY. Voicemail, an alternate contact, a ring group, a queue or an announcement may be intended; another deployment may deliberately return busy. Confirm the selected context, extension and actual branch rather than adding a fallback to an unrelated route.
Do not disable busy thresholds, call permissions or do-not-disturb merely to suppress the response. Define the desired behavior for a second call, all contacts busy, an explicit decline and an upstream busy result, then test those cases separately.
Prove the narrow correction
After correcting the demonstrated layer, repeat one call under the original busy condition and one nearby control call. Confirm the selected contact or trunk, emitted and received SIP responses, DIALSTATUS, final route and caller experience. Recheck voicemail or overflow only when it is part of the approved design.
Remove temporary protocol logging and redact credentials, addresses and personal calling data from retained evidence. No PBX, endpoint, device state, call waiting, do-not-disturb, carrier, queue, voicemail, capacity or live-call behavior was tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk: SIP and PJSIP hangup-cause mappings ↗
- Asterisk: Dial channel variables and DIALSTATUS ↗
- Asterisk: CDR disposition specification ↗
- Asterisk 22: PJSIP endpoint configuration ↗
- Asterisk: PJSIP_ENDPOINT device-state field ↗
- Asterisk PJSIP basic-call test plan ↗
- IETF RFC 3261: SIP 486 Busy Here ↗
- Asterisk: collecting bounded debug information ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.