SIP 403 Forbidden: Causes and Fixes

SIP 403 Forbidden means the server understood your request and is refusing to fulfill it — and, per RFC 3261, “authorization will not help.” The refusal is definitive: retrying the same call with the same credentials will not fix it. On a voice trunk, a 403 is your carrier saying no — to your credentials, your destination, your balance, or your traffic itself.

That “authorization will not help” clause separates 403 from an ordinary auth challenge — and for a dialer operation, a wall of 403s is frequently the moment a carrier cuts you off. Below: the cause ladder in the order the rungs are cheapest to rule out, how to diagnose yours, and what a 403 looks like from Asterisk and VICIdial. For the full class-by-class reference, start with the SIP response codes guide.

The 403 cause ladder

RFC 3261 defines the semantics; what a 403 means on a trunk is carrier convention — Telnyx publishes a whole family of documented 403 refusals, and Twilio’s error catalog does the same. In the order they are cheapest to rule out:

1. Bad credentials or an unlisted source IP. The first thing to rule out: a wrong registration password, or IP authentication where the originating box is not on the carrier’s allowed list. New server, new datacenter IP, failover to a secondary machine — each produces an instant wall of 403s until the IP is whitelisted.

2. Unauthorized destination. The number you dialed is outside what your account may call: international dialing disabled, a specific country not on your whitelist, or a rate-deck restriction on premium or high-cost destinations. The tell is the pattern — domestic calls complete while one destination class fails.

3. Balance or billing block. Prepaid balance exhausted, a negative balance, or a billing hold. Every call 403s regardless of destination, and the fix is on the billing portal, not in your PBX.

4. Carrier policy refusal. The carrier’s fraud or acceptable-use enforcement has flagged your traffic — the “your account has been flagged” 403. Unusual volume spikes, high short-duration ratios, or destinations associated with fraud can all trigger it. This is the rung that ends carrier relationships, covered below.

5. Caller ID the carrier rejects. Carriers commonly refuse calls whose From number is unverified, not provisioned on the account, or on a do-not-originate registry. If calls started 403ing right after you changed outbound caller ID, check here first.

Concurrent-channel and per-destination rate limits also surface as 403 on some carriers — worth knowing when a burst of simultaneous dials fails while single calls complete.

Diagnosing which 403 you have

The code alone does not tell you the cause; the context around it does. Work down this list — each step either identifies the rung or eliminates it:

1. Read the full response, not just the code. Many carriers put the real reason in the reason phrase or a custom header — “out of funds” and “destination not allowed” are different problems wearing the same number. Pull the SIP trace before theorizing.

2. Place one manual test call to a known-good domestic number from the same trunk. If it completes, credentials and balance are fine — look at destination or caller-ID restrictions. If it 403s too, the problem is account-level.

3. Check registration and source IP. Confirm the trunk is registered (or that your originating IP matches what the carrier has on file). A recent server move or failover event is the classic silent cause.

4. Check the balance. Thirty seconds on the portal rules the third rung in or out.

5. Call the carrier. If credentials, balance, and destination all check out, the refusal is policy — only the carrier can say whether it is a caller-ID rule, an AUP flag, or a fraud trigger. The answer determines whether you are fixing a setting or finding a new carrier.

One contrast worth internalizing: 403 is a refusal, not a failure. A carrier that is overloaded or out of routes returns SIP 503 Service Unavailable — temporary and retryable. A 403 says the request was understood and denied; retrying just documents your traffic hammering a carrier that already said no. And if your logs show SIP 603+ (“Network Blocked”) rather than 403, that is a different story entirely — an analytics block with its own FCC-mandated redress path, covered in our SIP 603 guide.

What a 403 looks like in Asterisk and VICIdial

In Asterisk’s chan_sip, the hangup-cause mapping (hangup_sip2cause) translates a received 403 to AST_CAUSE_CALL_REJECTED — ISDN cause 21, the same bucket as 401, 407, and 603. So a VICIdial or Asterisk operator often does not see “403” at the dialplan layer at all; they see call-rejected hangup causes stacking up in CDRs while the actual SIP code sits one layer down.

That mapping matters for triage: a spike in cause-21 rejections is ambiguous between a 403, a challenge loop (401/407), and far-end declines (603). Confirm the underlying code with a SIP trace — sip set debug on, pjsip set logger on, or a packet capture — before acting. A dialer showing thousands of rejected calls with zero answers is a trunk-level 403 until proven otherwise; the broader sequence for that symptom is in our VICIdial troubleshooting guide.

Two dialer-specific notes. First, do not re-dial 403’d calls aggressively — the RFC is explicit that the refusal is definitive, and re-dialing a policy-blocked destination at dialer speed makes the pattern that triggered the block worse. Second, when a 403 flood starts mid-campaign, pause the campaign before diagnosing: every refused attempt is logged on the carrier’s side too.

When a 403 flood means the relationship is over

Rungs one through three and five are settings: fix the credential, fund the account, whitelist the destination, provision the caller ID. Rung four is different. A policy 403 — the fraud flag, the AUP enforcement — is the carrier telling you it no longer wants some or all of your traffic.

Sometimes that is recoverable: a legitimate volume spike explained, a compromised endpoint cleaned up, a destination pattern documented. Ask the carrier what triggered the flag and what evidence would clear it. But when the answer is vague — or the account was cut without warning and support goes quiet — the practical read is that this carrier never underwrote dialer traffic in the first place, and your campaigns were living on borrowed time. At that point the fix is not a ticket; it is a carrier built for dialer traffic — and if the account is already dark, the suspended dialer account runbook is the hour-one checklist.

Preventing the 403 you cannot afford

Settings-level 403s are prevented by checklist discipline: update the carrier’s IP list before failover events, keep destination whitelists in sync with campaigns, provision every outbound caller ID before it dials, and alarm on balance thresholds.

The policy-level 403 is prevented at signup, not in production. A carrier that runs KYC upfront — asking what you dial, at what volume, with what consent basis, before turning the trunk on — has already underwritten your traffic profile. A carrier that asks nothing does its underwriting later, silently, with a fraud filter, and its answer arrives as a mid-campaign 403 flood. Bias disclosed: SIPNEX is an FCC-licensed carrier that serves dialer operations deliberately, which is exactly why we ask upfront.

Frequently asked questions

SIPNEX is an FCC-licensed carrier with its own STIR/SHAKEN SP certificate, signing dialer traffic at A-level attestation on trunks underwritten for that traffic from day one. If your current carrier’s answer to your traffic profile was a mid-campaign 403 flood, tell us what you dial — we would rather ask now than block later.