Enable outbound calling — Custom Telephony / Twilio SIP trunk

Support Help
1

Hi Retell team,

I’m on Pay-As-You-Go with a custom Twilio SIP trunk configured. Inbound is connected; outbound is failing with telephony provider permission denied on every attempt. Twilio’s logs show no SIP INVITE received, so the rejection is happening on Retell’s side before the call leaves.

Per community threads (e.g. /t/outbound-calling-not-enabled-request-telephony-access-activation/175), this is the standard outbound-activation gate. Please enable outbound calling on this account.

2

Hey @laz

Could you please share a bit more detail such as Call ID ?

Thank You

3

Hey @shaw

Here are the failed Call IDs (all “telephony provider permission denied”, not_connected, 0:00 duration):

  • call_1ecad6dc3027b3181dc07e63747 — 2026-04-29 12:41:06 EDT

  • call_b719d18d72738a4d44a6fb18b7d — 2026-04-29 11:46:33 EDT

  • call_8526903c8d36ee58f8268483843 — 2026-04-29 11:43:57 EDT

  • call_b46969aabccacaec4049e7b0e55 — 2026-04-29 11:24:18 EDT

  • call_fbcd9c927ce39c810294dfcef4e — 2026-04-29 11:23:01 EDT

Before the support team suggests this is a downstream/Twilio issue — it isn’t, and I want to save us a round trip:

  1. Twilio’s Debugger and Error logs are completely empty for the time window of all 5 attempts (last 24h). No INVITE, no auth failure, no rejection of any kind. The downstream provider is not seeing the call at all.

  2. Each call shows 0:00 duration and $0.000 cost. If the INVITE had reached Twilio and been rejected, we’d at least see Retell’s side attempt establishment.

  3. The error message text — “telephony provider permission denied” — surfaces in Retell’s call history with effectively zero latency, faster than any plausible round-trip + carrier rejection.

The pattern — not_connected + permission denied + zero downstream activity — matches the community threads on the outbound-calling activation gate (e.g. /t/outbound-calling-not-enabled-request-telephony-access-activation/175 and /t/outbound-calls-disconnect-immediately-please-enable-outbound-and-inbound-calling/826). Please enable outbound on the account; happy to provide identity verification if needed.

Thanks.

5

Hello @laz

Team investigated all five calls and found the root cause via packet capture analysis. Despite the confusing “permission denied” surfacing in Retell’s UI, the rejection is coming from Twilio — but at a layer that doesn’t appear in Twilio’s standard Debugger, which is why your logs look empty.

Here’s exactly what’s happening:

  1. Retell successfully sends a SIP INVITE to your Twilio trunk cadence-retell.pstn.twilio.com
  2. Twilio’s gateway does receive it — it responds with 100 Trying (acknowledgement)
  3. ~18ms later, Twilio immediately returns 403 Forbidden — without first sending a 407 Proxy Authentication Required challenge

This pattern is the signature of a Twilio IP Access Control List (ACL) rejection. Your trunk is configured to authenticate by source IP, and the IP sending the INVITE 18.98.16.120 — Retell/LiveKit’s SIP proxy) is not on the allowed list. Twilio rejects these at the network edge, before their application-level Debugger logs anything.

To fix this, you have two options (either one will work):

Option A — Add Retell’s IP to the ACL (recommended if you want to keep IP-based auth):

  1. Go to Twilio Console → Elastic SIP Trunking → your trunk ST_G6ewraiSVDSt → Authentication → IP Access Control Lists
  2. Add IP 18.98.16.120 (this is Retell’s outbound SIP proxy)
  3. Save and retry

Option B — Switch to Credential List authentication:

  1. In the same Authentication section, remove or disable the IP ACL
  2. Under Credential Lists, create a credential list with the username cadence-retell-svc and the password you configured when setting up the trunk in Retell
  3. Save and retry — Twilio will then send a 407 challenge, and Retell will respond with the stored credentials

Your inbound calls work because inbound follows a different path (Twilio initiates the SIP to Retell, so Twilio’s ACL doesn’t apply).

Thank You