SIP 486
SIP 486 Busy Here in Asterisk
Of all the rejection codes, 486 is the one most likely to mean exactly what it says. The line is in use. That makes the interesting cases the ones where the user insists they were free.
What it looks like in the log
[2026-08-17 16:09:33] VERBOSE[20114][C-00002f81] res_pjsip_logger.c: <--- Received SIP response (596 bytes) --->
SIP/2.0 486 Busy Here
CSeq: 102 INVITE
[2026-08-17 16:09:33] VERBOSE[20114][C-00002f81] app_dial.c: Everyone is busy/congested at this time (1:1/0/0)What it means
A 486 comes from the callee's device or from the PBX acting for it, and it means the destination was reachable and understood the call but is already occupied. It is what the caller hears as a busy signal or busy tone. Unlike a 403 or a 488, this is usually not a configuration problem on your side at all.
The cases worth investigating are the ones where the callee never saw the call. Then the 486 was generated by something acting on their behalf, and the question becomes what.
Most common causes
-
01The callee was genuinely on another call
The default explanation, and the correct one most of the time.
-
02Call waiting is disabled
With call waiting off, a second call to a busy extension is rejected outright rather than presented. The user experiences one call; the caller experiences a busy signal they did not expect.
-
03Do Not Disturb on the device
Many phones express DND as 486 rather than 480 or 603. The user set it, forgot, and reports that calls are failing.
-
04A device call limit reached
An endpoint configured with a maximum number of concurrent calls returns busy on the one over the limit, which looks like a busy line even when the device is idle on its second appearance.
-
05A self-collision in the dialplan
If the dialplan dials a device that is already a party on this same call - a ring group that includes the caller, a forwarding loop back to the originator - the busy is real but the cause is the routing, not the user.
How to tell which one it is
Check whether the busy destination appears anywhere else on the same call. If the number returning 486 is also a party already connected on that call, the dialplan is ringing a phone that is busy because of this very call, and no amount of asking the user will explain it.
Otherwise, look at the call immediately preceding this one on the same extension. If it was still up at this timestamp, the busy is genuine and there is nothing to fix.
How to fix it
-
Enable call waiting where a second call should be presented
If users expect to see a second incoming call, call waiting has to be on at the device and permitted by the PBX.
-
Route busy to voicemail rather than failing
Handling
DIALSTATUS=BUSYexplicitly in the dialplan turns a dead-end busy tone into a voicemail prompt, which is usually what the caller wanted. -
Exclude the caller from ring groups
For self-collisions, filter the originating extension out of the group before dialling so a member cannot ring themselves.
-
Check device call limits
If an endpoint has a concurrent-call cap set lower than the number of line appearances the user has, raise it to match.