Twilio error 31486 maps directly to SIP response code 486 Busy Here, returned by a SIP endpoint when it is already engaged in a call and cannot accept a new one, or when a SIP UA is configured to reject new calls when its maximum simultaneous call limit is reached. Unlike a 480 (temporarily unavailable), a 486 is specifically an active rejection because the endpoint is occupied, and the caller should understand the called party is present but busy. Your TwiML Dial action handler receives DialSipResponseCode=486 along with DialCallStatus=busy.
What Causes This Error
A SIP phone or softphone that supports only a single concurrent call and is already on an active call returns a 486 Busy Here for any new incoming call, which is standard SIP behavior for single-line devices. SIP PBX extensions configured with a maximum concurrent call limit of 1 (common for agent extensions in contact center deployments) return 486 when the agent is already on a call, regardless of how many new calls are trying to reach them. Auto-attendant menus or SIP servers configured with a maximum queue depth that reject calls with 486 once the queue is full use this response code to signal that the system cannot handle additional callers at that moment. Some SIP clients and PBX platforms use 486 as a generic rejection code rather than using 603 Decline, returning 486 even when the phone is ringing and the user manually rejects the call instead of answering it.
How to Fix It Step by Step
In your TwiML Dial action handler, check the DialSipResponseCode parameter for a value of 486 alongside DialCallStatus of busy, and implement appropriate TwiML fallback logic: for a single-agent busy scenario, play a hold message and use Twilio Queues or a second Dial attempt to a different agent; for a fully occupied queue, offer the caller a callback option using Twilio's callback queue feature. If 486 errors are caused by a PBX extension being on an active call, consider configuring call waiting on the SIP device or PBX extension so that a second incoming call can be signaled to the agent, who can then choose to accept or decline it rather than returning an automatic 486. Review your SIP PBX's concurrent call limit settings for affected extensions and increase the limit for extensions that are expected to handle call forwarding or call center scenarios where simultaneous calls are legitimate. For Twilio SIP Domain routing, implement a round-robin or least-recently-used routing strategy in your TwiML that selects from a pool of SIP URIs and skips URIs that return 486, distributing load across multiple available endpoints.
How to Prevent It from Recurring
Implement agent presence detection in your contact center application using the Twilio TaskRouter or a SIP OPTIONS keepalive ping approach to track which agents are currently on calls, and avoid routing new calls to agents who are already busy rather than relying on the PBX to return 486. Design your TwiML Dial logic to include multiple destination options using the dial action fallback: if the first SIP URI returns 486, immediately retry with the next available agent from your routing queue without the caller experiencing dead air. Set the timeout attribute on the Dial verb to a short value (15 to 20 seconds) and handle all non-answered outcomes including busy through the action callback, rather than waiting the default 30 seconds before handling the busy response. Monitor your 486 rate per extension using the DialSipResponseCode field in your StatusCallback webhook data and identify which extensions are generating the most busy rejections, as high 486 rates on specific extensions may indicate understaffed queues or misconfigured call routing.
When to Call a Specialist
If 486 responses are occurring on SIP extensions that should be idle (the agent reports they are not on a call), there may be a hung call or zombie SIP session on the PBX that is holding the extension in a busy state without the agent being aware of it, which requires PBX-level session management to identify and clear. A specialist can design a comprehensive contact center call routing architecture using Twilio TaskRouter that eliminates dependency on SIP 486 handling by managing agent availability through the TaskRouter activity model, routing calls only to agents confirmed as available before the call is initiated. For high-volume contact centers where 486 handling directly impacts SLA metrics, a specialist can optimize the entire call routing and failover strategy to minimize the impact of busy agents on caller experience.
Conclusion
Error 31486 is a SIP 486 Busy Here response that is handled by implementing TwiML action-based fallback routing, agent availability detection, and load distribution across multiple SIP endpoints. If this error is blocking your production system, contact our team and we will diagnose and fix it within the hour.
Ready to Transform Your Business Communications?
Get a free consultation with our VoIP experts and discover how we can help you save costs, improve efficiency, and scale your business.
Comments (0)
Join the discussion and share your thoughts (AI-moderated for quality)
Be the first to comment
No comments yet. Share your thoughts below.