SIP 403 Forbidden with Asterisk carrier after successful authentication - trunk active but calls fail

Support Help
1

Hi everyone,

I’m experiencing a persistent SIP 403 Forbidden error when making outbound calls through a custom SIP trunk with an Asterisk-based carrier. The error occurs after successful authentication, and I’ve exhausted troubleshooting options on both sides.

Issue Summary

  • Error: SIP status code: 403, telephony_provider_permission_denied
  • Carrier: Asterisk-based (European provider)
  • Reproducibility: 100% - every outbound call fails

SIP Flow (from PCAP analysis)

1. Retell → Carrier: INVITE (no credentials)
2. Carrier → Retell: 401 Unauthorized (requests auth)
3. Retell → Carrier: ACK
4. Retell → Carrier: INVITE (with SIP Digest credentials)
5. Carrier → Retell: 403 Forbidden ❌
6. Retell → Carrier: ACK

Authentication works (401 → retry with creds), but the 403 comes after successful auth, not another 401.

Carrier Configuration (verified by their team)

Attempted configs (both failed):

Config A (host=sip.retellai.com):

type=friend
host=sip.retellai.com
username=[username]
secret=[password]
context=outbound_context
allow=alaw

Result: 403 Forbidden

Config B (host=dynamic):

type=friend
host=dynamic
insecure=port,invite
username=[username]
secret=[password]
context=outbound_context
allow=alaw
permit=18.98.16.120/30
permit=143.223.88.0/21
permit=161.115.160.0/19

Result: 403 Forbidden

Important: With host=dynamic, the trunk shows as active/online in Asterisk (sip show peer confirms connection), but calls still fail with 403.

Carrier confirms:
:white_check_mark: Peer is active
:white_check_mark: Context has outbound dial permissions
:white_check_mark: Credentials match
:white_check_mark: Network connectivity verified (ping successful)
:white_check_mark: Firewall disabled during testing

Retell Configuration

Phone Number: [European DID]
Termination URI: sip:[carrier_ip]:5060
Username: [carrier_provided_username]
Password: [carrier_provided_password]
Transport: UDP

Multiple DIDs assigned (rotate as caller ID for outbound calls)

PCAP Details

From PCAP analysis:

Authorization: Digest 
  username="[username]"
  realm="asterisk"
  algorithm=MD5

From: <sip:[caller_id]@5t4n6j0wnrl.sip.livekit.cloud:9000>
To: <sip:[destination]@[carrier_ip]>

The authentication challenge-response works correctly (MD5 hash validates), but the carrier rejects with 403 after accepting credentials.

Questions

  1. Is there anything non-standard in Retell’s SIP INVITE that could cause Asterisk to reject with 403 after accepting credentials?

  2. Are there known compatibility issues with Asterisk carriers using type=friend + host=dynamic + insecure=port,invite?

  3. Could the From domain (5t4n6j0wnrl.sip.livekit.cloud) be causing issues? Should it match the carrier’s domain?

  4. Do custom SIP headers (X-RetellAI-CallId, X-RetellAI-Direction, etc.) trigger ACL/permission denials in some Asterisk configs?

  5. Has anyone successfully integrated Retell with an Asterisk-based carrier that requires both authentication AND specific caller ID authorization?

Business Context

This integration is critical for our production deployment with a European carrier. We’ve built our entire voice automation infrastructure on Retell and are now blocked on this SIP trunk issue.

I’ve sent detailed PCAPs to support@retellai.com, but hoping someone in the community has encountered this specific “403 after successful auth” scenario with Asterisk-based carriers.

Any insights would be greatly appreciated! :folded_hands:

2

Hi @saritacolgil23

Could you please share a few call IDs where you experienced this issue, along with the email address you used to send the PCAP files? This will help us locate and investigate the cases more efficiently.

Thank you!

3

Sure!

Call IDs:

  • call_0ea3b6f4d1f2cfe219eebc6ce00 (2026-04-10 13:59:40 UTC)
  • call_06292c355f76d79bbba3c716569 (2026-04-10 14:36:06 UTC)

The email address was: saritacolgil23@gmail.com
Here is all the VERY detailed information

4

Hi @saritacolgil23

Thank you for sharing this. I have forwarded it to our internal team for further investigation.

Best Regards

5

Hi @saritacolgil23

After analyzing the SIP packet captures for both calls, the 403 Forbidden is being returned by your Asterisk carrier (PBX 20.14.0) after it successfully accepts the authentication credentials. This confirms the issue is on the carrier’s authorization layer.

Recommended next step: Check your Asterisk CLI logs asterisk -rvvvvv during a test call to see the exact reason for the 403. This will pinpoint the cause. The Asterisk security log or SECURITY event will show precisely which authorization check failed

Thank You

7

Hi Retell team,

Thank you for the PCAP analysis. I’ve coordinated with the carrier’s technical team and they’ve identified an important detail:

The calls are NOT reaching the Asterisk dialplan/CLI.

When they run asterisk -rvvvvv during our test calls, no call activity appears in the Asterisk CLI output. This means the 403 Forbidden is being generated before the call reaches the dialplan layer.

What we know:

  • The SIP peer shows as “online/active” in Asterisk (sip show peer confirms registration)
  • Network connectivity is verified (ping successful to Retell IPs)
  • Firewall is disabled during testing
  • The 403 response is coming from their Asterisk server (PBX 20.14.0) based on PCAP
  • But NO call activity appears in asterisk -rvvvvv during test calls

This suggests the 403 is being generated at the SIP channel driver level (chan_sip or PJSIP), not at the dialplan/context level.

Questions:

  1. Could this be an ACL/IP permission issue at the SIP peer level in Asterisk, where the peer authenticates but the source IP is not authorized to make calls?

  2. Are there any SIP headers that Retell sends (X-RetellAI-*, P-Hint, etc.) that might trigger Asterisk’s security module to reject with 403 before reaching dialplan?

  3. Should we ask the carrier to check Asterisk security logs (/var/log/asterisk/security) for SECURITY events during our test calls?

  4. Is there a way to get more detailed SIP debugging from Retell’s side showing exactly what’s being sent in the INVITE that might help the carrier identify why Asterisk is rejecting at the channel level?

The carrier is willing to work with us but needs to understand why Asterisk is generating 403 without the call reaching dialplan.

Any guidance would be greatly appreciated.

8

Ok, you’re going about this the wrong way - and I’ll explain why. First of all, the flow you described above:

  1. Retell → Carrier: INVITE (no credentials)
  2. Carrier → Retell: 401 Unauthorized (requests auth)
  3. Retell → Carrier: ACK
  4. Retell → Carrier: INVITE (with SIP Digest credentials)
  5. Carrier → Retell: 403 Forbidden :cross_mark:
  6. Retell → Carrier: ACK

Basically says the following:

  • Asterisk identified that the username used to perform the INVITE/REGISTER was identified by Asterisk.
  • When Retell tried to complete the challenge-response, it failed, resulting in a 403 error

This will normally means the following (one of the below):

  • The digest request sent to Asterisk by Retell includes a username/password combination that is wrong.
  • The digest request sent to Asterisk by Retell includes a Realm that Asterisk on the other side doesn’t support.
  • You provider has another customer connected to Retell, causing a potential IP collision on their side (could happen).

Based on your Asterisk configurations, as you indicated above, you are using chan_sip (please move to chan_pjsip as soon as possible).

Are you using Asterisk as your office phone system? or is this the carrier system you are working with? Can you please provide some more information,. as I may be able to assist - after all, I did write 2 books about Asterisk and I wrote multiple patches for it.

9

Hi @saritacolgil23

Your issue has been escalated to our telephony team for further investigation. Once we receive an update, we will get back to you.

Thank you for your patience.

10

I had the same issue. I’m pretty sure it’s because your telephone carrier is not able to natively connect via SIP trunk to Retell. You will have to use a middleware like Cloudonix. So it will be your carrier connecting to Cloudonix to Retell.