When a business call fails, SIP call rejected 403 486 troubleshooting starts with the response code, not a guess about the firewall. A SIP response tells you how a device, PBX, or provider handled the request. The code does not always identify the root cause, but it narrows the search.
Two common responses are 403 Forbidden and 486 Busy Here. They can appear during outbound calls, inbound calls, transfers, or call-forwarding attempts. The same code may come from different points in the call path, so you need timestamps, call numbers, and logs before changing settings.
What SIP 403 and 486 responses mean
SIP uses three-digit status codes. The first digit shows the broad result: provisional, successful, redirection, client failure, server failure, or global failure. A response such as 403 or 486 is useful evidence, but it is not a complete diagnosis.
403 Forbidden
A 403 response means the responding system understood the request but will not authorize it. The refusal can come from your PBX, an upstream SBC, or the carrier. An SBC is a session border controller that manages signaling between networks.
Common causes include an invalid trunk identity, an unauthorized caller ID, a blocked destination, failed authentication, an account restriction, or a provider policy. Some providers also use 403 when the account lacks permission for a number range or calling feature.
486 Busy Here
A 486 response usually means the called endpoint is busy and cannot accept another call. It may reflect a genuinely occupied extension, a phone in do-not-disturb mode, a call-limit setting, or a device that reports itself as busy.
However, 486 does not always mean a person is on the phone. A PBX may return it when a queue, ring group, endpoint, or trunk has reached a configured limit. A carrier may also map another failure into a busy response.
For protocol reference, consult the official Asterisk documentation. It provides documentation for SIP, endpoints, trunks, dial plans, and related call handling.
Start with the call path and evidence
Before changing a route or trunk, draw the expected path. An outbound call might travel from the phone to the PBX, through an outbound route, into a SIP trunk, and then to the provider. An inbound call reverses that direction.
Next, record these details:
- The exact time, including the time zone.
- The calling extension and destination number.
- Whether the failure affects one number, one extension, or every caller.
- The displayed response code and any reason text.
- Whether the call was direct, transferred, forwarded, or placed through a queue.
- Whether another route or test number behaves differently.
Compare a failed call with a successful call made soon afterward. Look for the first rejecting response, not only the final message shown to the user. A PBX can receive a provider response and then create a different local response for the phone. This comparison is central to SIP call rejected 403 486 troubleshooting because it separates local policy from upstream behavior.
Keep a copy of relevant logs before rotating or clearing them. Remove phone numbers, usernames, authorization values, and other sensitive data before sharing traces outside the organization.
Check registration without assuming it is the cause
Registration confirms that an endpoint or trunk has announced its contact address and credentials. It does not prove that outbound calling is permitted. A trunk can register successfully while the provider rejects a destination or caller ID.
For an extension, verify that the device shows the expected account, address, and registration time. Check whether another phone is using the same credentials. Duplicate registrations may cause calls to ring the wrong device or make an endpoint appear busy.
For a trunk, review the PBX status and the provider’s expected authentication method. Depending on the service, authentication may use a username and password, an IP address, or both. Do not replace working credentials unless the provider confirms the change.
If registration repeatedly disappears, separate that problem from a rejection during an active call. The guide on SIP registration loss covers credentials, timers, NAT, packet loss, clocks, duplicate logins, and provider limits.
Trace the dial plan and outbound route
A dial plan is the rule set that decides how a dialed number should be processed. In FreePBX, an outbound route normally matches a dial pattern and selects a trunk. A mismatch can prevent the call from reaching the provider at all.
Check the number as the user dialed it. Then check the normalized number sent to the trunk. Common differences include a leading access digit, country code, area code, extension prefixes, and emergency-call rules.
- Confirm that the extension can use the selected outbound route.
- Review route priority when multiple routes match.
- Check whether a dial pattern strips or adds digits.
- Verify that the route selects an available trunk.
- Compare the failed number with a permitted test destination.
If the call never reaches the trunk, focus on the PBX route, permissions, and dial pattern. If the provider receives the call and returns 403 or 486, continue into trunk and carrier checks. The article on FreePBX outbound trunk failures provides a related path through routes, authentication, codecs, permissions, and logs.
Review permissions, caller ID, and account limits
Permissions often explain a 403 response. An extension may be restricted from international, premium, long-distance, or external calls. A time condition may also select a route that the user cannot access.
Review the extension’s class of service and the route permissions. Check the outbound caller ID as well. Providers may reject a caller ID that is not assigned to the account, uses an invalid format, or violates a customer profile.
Account limits create another branch of the investigation. Confirm the permitted concurrent calls, destination classes, credit or account status, and any fraud-prevention hold. Only the provider can verify some of these controls.
Do not respond to a 403 by broadly opening firewall ports or disabling authentication. Those changes do not grant carrier permission and can increase exposure. Instead, identify which system issued the response and compare its reason with provider documentation or support records.
Investigate 486 busy conditions locally
For a 486 response, first test the called extension directly. Check whether the phone is already active, in do-not-disturb mode, or configured for call waiting. Confirm that the PBX sees the endpoint as reachable and not permanently busy.
Then review ring groups, queues, call-forwarding rules, and simultaneous-call limits. One queue may have no available agents. Next, a ring group may stop when one member rejects the call. In addition, a forwarding rule may send the call to a destination that returns 486.
Use a controlled test with one extension and one known available destination. If direct extension calls work but queue calls fail, focus on the queue or ring strategy. If every destination returns 486, examine trunk limits, PBX capacity, and the exact response source.
Do not confuse a busy response with poor audio. RTP carries the media after call setup. A call that never establishes has a signaling or policy problem, while established calls with missing media need a different investigation. See the guide to VoIP media and one-way audio when the call connects but speech fails.
Determine whether the provider rejected the call
Provider-side causes become more likely when registration is healthy, the dial plan selects the expected trunk, and the PBX sends a valid request. Look at the SIP trace to identify the source address and the response sequence.
Ask the provider to confirm the call attempt using its timestamp, destination, source number, and trunk identifier. Request the reason for the 403 or 486, along with any account, route, or destination restriction involved.
Provider teams may also need to check geographic permissions, number portability status, caller ID authorization, concurrent-call limits, fraud controls, and upstream routing. These checks require carrier access. A local PBX administrator cannot reliably infer them from the handset message. That distinction keeps SIP call rejected 403 486 troubleshooting focused on evidence rather than assumptions.
Keep the request specific. Send one successful and one failed example, but redact passwords and authorization headers. That comparison often helps the provider identify whether the difference is the number format, caller ID, route, or account policy.
A safe troubleshooting sequence
Use this order to reduce unnecessary changes:
- Capture the exact response, time, direction, and affected users.
- Identify whether the PBX, endpoint, or provider sent the response.
- Confirm extension or trunk registration status.
- Trace the dial plan and normalized number.
- Review route permissions, caller ID, and call limits.
- Test a controlled call to a known permitted destination.
- Compare the result with a successful call.
- Escalate provider-side evidence with redacted logs.
Change one relevant setting at a time, record the previous value, and retest. Avoid repeated retries to sensitive destinations. Excessive attempts can trigger account protections or make the evidence harder to interpret.
When remote help is appropriate
SIP call rejected 403 486 troubleshooting becomes much faster when someone can correlate handset behavior, PBX logs, SIP messages, route settings, and provider responses. Tech Rescue Ops LLC can help with a controlled trace and an evidence-based review when the failure affects business calls or the cause crosses system boundaries.
Professional assistance is especially useful when only some destinations fail, the response source is unclear, or a configuration change could interrupt active service. Preserve the timeline and logs first, then make changes with a rollback plan.