Troubleshooting · SIP Codes
SIP 403 Forbidden: The Server Refuses
403 is SIP's firm no: the request arrived, was understood, was authenticated or identifiable — and the server refuses to honor it as a matter of policy. Unlike 401 (an invitation to authenticate) or 404 (the target doesn't exist), 403 is about permission: something about who you are, where you're calling from, or what you're asking for is not allowed on that system.
That makes 403 one of the most actionable codes: the fix list is short, and every item on it is a setting somebody owns.
What generates a 403
- On REGISTER: the account is disabled or deleted; the extension/MAC is not provisioned on this server; the registration comes from an IP outside the account's allowed ACL; or the provider restricts registrations to specific networks/regions.
- On INVITE: the destination is outside the account's calling permissions (class of service): international blocked, premium ranges blocked, or a fraud-prevention rule triggered by a calling-pattern anomaly.
- On trunks: the PBX's source IP is not on the trunk's allowlist; the From/P-Asserted identity presents a number the account doesn't own; or the trunk's concurrent-call or spend cap has been hit and the provider expresses it as a refusal.
- Anti-fraud systems: a sudden volume spike, impossible call patterns, or destinations matching fraud profiles can produce 403s that appear 'random' until you talk to the provider's fraud desk.
403 vs its neighbors
The distinctions matter because they route the fix: 401/407 — 'authenticate first' (no refusal yet). 404 — 'that destination doesn't exist here' (a routing/dial-plan claim, not a permission claim). 603 — 'refused everywhere' (a global failure, usually the user or their domain declining). A 403 says specifically: exists, understood, not permitted. When a provider's documentation claims 403 means 'wrong password', read carefully — a true wrong password loops at 401; a 403 after successful authentication is a policy statement, and arguing about the password wastes the ticket.
Fix sequence
- Identify which request earned the 403 (REGISTER vs INVITE) and from which element — your PBX's log vs the provider's response are different jurisdictions.
- For REGISTER 403s: confirm the account exists and is enabled on that server, the extension/MAC matches provisioning, and your source IP satisfies any ACL (a changed office IP or new ISP breaks ACLs silently).
- For INVITE 403s: test the same destination from an account with broader permissions; if it works, it's class-of-service — adjust the account's calling permissions deliberately.
- On trunks: verify your egress IP against the trunk allowlist and that the caller ID you present is a number on the account.
- If 403s began suddenly with normal configuration, call the provider and ask the fraud/anti-abuse question directly — and ask whether a cap (spend, concurrency, destinations) was reached.
- Retest the original failing request and confirm the 403 is replaced by progress (a 401 challenge on REGISTER is progress; a 180/200 on INVITE is success).
Frequently asked questions
- Why would a provider 403 calls to one country only?
- Destination-based permissions and fraud rules are granular: a country or prefix gets blocked by class-of-service (you never enabled it) or by a fraud rule (that destination's fraud profile spiked). Both live on the provider side — a five-minute call with the exact destination and timestamp resolves which.
- We get 403 after moving offices.
- Your public IP changed, and registrations/trunks authenticated by source-IP ACL no longer recognize you. Update the ACL with the provider (and note the dependency for next time — or ask about credential-based auth instead).
- Does 403 mean we've been hacked?
- Not by itself. But 403s on registrations from unfamiliar IPs, or fraud-desk blocks on your trunks, can be the visible edge of credential compromise — if the pattern is foreign to your usage, treat it as a security review trigger: audit accounts, rotate secrets, review call detail for successful unusual calls.