Error reference

SIP 403 Forbidden on outbound calls

Short answer

A 403 Forbidden means Cloud SIP refused the call before it reached the phone network, because it couldn't match the call to your SIP domain and the way it's secured. It's almost always the domain your PBX sends calls to, the IP access control list, or the trunk's username and password.

Applies to
Cloud SIP
Works with
Any SIP PBX or SBC
Who can do this
Whoever manages your PBX and your Enfonica project

Check for a known incident first. If there is one, we're already working on it, and there's nothing to change on your side.

Checking Enfonica system status…

Status page
On this page
  1. What are you seeing?
  2. Every outbound call fails with 403 Forbidden
  3. Calls used to work but now fail with 403 Forbidden
  4. How do I read the 403 in a SIP trace?
  5. Questions
  6. What to send us
  7. Related

What are you seeing?

Every outbound call fails with 403 Forbidden

SIP/2.0 403 Forbidden

If no outbound call has worked yet, the trunk settings in your PBX (your phone system) don't match your SIP domain. On every call, Cloud SIP checks three things in order: the SIP domain the call is addressed to, the IP address it comes from, and its username and password. Work through the causes below, most likely first.

The call isn't addressed to your SIP domain

Cloud SIP identifies your trunk by the SIP domain in each call request. Every call must be addressed to your SIP domain's name, for example sip:+61255501234@example.sip.enfonica.com. Cloud SIP refuses a request that's addressed to one of Enfonica's IP addresses, has no domain, or has a misspelled domain. It refuses the request even when the IP address it comes from is in your IP access control list.

Check

Look at a SIP trace from your PBX. If the request line or the To header of the INVITE shows an IP address, no domain, or a domain that isn't exactly yours, this is the cause. A single wrong letter is enough.

Fix

In your PBX's trunk settings, set the host, domain, or proxy to your SIP domain exactly as the Console shows it. To find it, go to Cloud SIP in the Console, open your SIP domain, and copy the name shown next to SIP domain.

Your PBX's public IP address isn't in the IP access control list

If your SIP domain has any entries in its IP access control list, only devices in those networks can make calls. The address that counts is the public IP address the call arrives from. If your PBX is behind a firewall or NAT, that address can differ from the one your PBX reports.

Check

Find the public address in your firewall, or in a SIP trace taken outside it. If that address isn't in the list, this is the cause.

Fix

  1. In the Console, go to Cloud SIP, and open your SIP domain.
  2. Under IP access control list, select Add IP range.
  3. Enter the address in CIDR notation. A single address ends in /32, for example 203.0.113.10/32.
  4. Select Save Changes.
  5. Wait a minute, and then make a test call.

The username doesn't exist, or the password is wrong

If your SIP domain has users, every call must authenticate with one of their usernames and passwords (SIP digest authentication). Cloud SIP first answers the call with a challenge, and your PBX replies with its credentials.

Check

Look for this sequence in the trace: 407 Proxy Authentication Required, then a second INVITE with credentials, then the 403. The 407 is normal. The 403 after it means that the username isn't a user on this SIP domain, or the password doesn't match.

Fix

  1. Under Users on your SIP domain, check the username.
  2. If you're not sure of the password, select Change password, and set a new one.
  3. In your PBX, enter the bare username (pbx01, not pbx01@example.sip.enfonica.com) and the new password.
  4. Make a test call.

The SIP domain has no authentication set up

A SIP domain with no IP access control list and no users can't make calls at all. This protects a new SIP domain from anyone who learns its name.

Check

Open your SIP domain in the Console. If it shows Authentication not configured, this is the cause.

Fix

Add your PBX's public IP address under IP access control list, or select Add user under Users. Then make a test call.

You use both an IP access control list and users, and one of them fails

With both set up, a call must come from an address in the list and also carry a valid username and password. For a PBX with a fixed address, this is the most secure setup.

Check

Open your SIP domain. This is the cause if it shows User authentication with IP restrictions, and the calls come from a platform whose addresses change, such as a hosted AI voice agent or cloud dialer.

Fix

For a platform whose IP addresses you can't list, remove the IP access control list entries. Rely on the username and password alone.

Calls used to work but now fail with 403 Forbidden

SIP/2.0 403 Forbidden

When working calls start failing with a 403, something changed on one side of the trunk. These are the changes we see most.

Your public IP address changed

Internet providers sometimes change a connection's public IP address. A new firewall, a move to new hosting, or a failover link can also send calls out through a different address.

Check

Look at when the failures started. This is the likely cause if they started after a network change, or if only calls through a backup connection fail.

Fix

Add the new public IP address to the IP access control list. Include the address of any backup link your PBX might use.

The trunk settings in your PBX were changed or overwritten

A PBX upgrade, a restored backup, or a configuration template can overwrite the trunk's domain, username, or password. A password changed in the Console has the same effect until the PBX has it too.

Fix

Compare the trunk settings in your PBX with your SIP domain in the Console, and correct anything that differs.

How do I read the 403 in a SIP trace?

Find the line that starts with SIP/2.0 403 Forbidden, and then look at the INVITE right before it:

  • Its request line and To header show the domain your PBX used.
  • Its Proxy-Authorization header, if there is one, shows the username.

Cloud SIP stops a call it refuses with a 403 at the edge of Enfonica's network, before the call starts. The call doesn't appear in Cloud Voice > Calls, so use your PBX's call log or SIP trace instead. If you can't capture a trace, send us an example with the details below, and we'll find the request in our logs.

For other errors on outbound calls, see Outbound calls aren't going through.

Questions

My 3CX says "Calls forbidden by Administrator". Is that a 403?

Usually. 3CX shows this message when the trunk refuses a call with a 403, so work through the causes above. It can also mean that the user or extension isn't allowed to make external calls in 3CX, so check that too. For the trunk settings that work, see Connect 3CX to Cloud SIP.

How long do changes take to apply?

Up to about a minute after you select Save Changes. If a test call straight after a change still fails, wait a minute and try again.

Can my PBX send calls to an Enfonica IP address instead of the SIP domain name?

Not on a standard SIP domain. Send calls to your SIP domain's name, which resolves to both of Enfonica's signaling addresses.

If your equipment can't send a domain at all, contact us. A SIP domain we've set up this way shows IP access only in the Console. We change its IP access control list for you on request.

How many IP ranges can I add?

Up to 100 per SIP domain. To cover several neighboring addresses, enter them as one CIDR block, for example 203.0.113.0/28.

What to send us

Include these and we can find the call straight away.

  • The number that made the call and the number it called, in full international format (for example +61255501234).
  • The date and time of the call, with your timezone.
  • Whether the call was inbound or outbound.
  • The call ID, if the Console shows the call.
  • What happened: an error message, silence, a busy tone or a dropped call.
Contact support

Our support team are telco specialists, backed by the engineers who run the network.