Twilio Number to agent rings busy, while other assigned to same AI Agent are successful

I have an issue with my main number from Twilio ringing busy. It was working just fine and stopped without any changes that I can determine. I added a new phone number from Twilio and one from Telnyx to my agent and both work. So the issue seems to be specific to the number. How do I go about getting this resolved? I have the non-working number submitted for SMS review so I don’t to release the number and move to another.

Since your other Twilio and Telnyx numbers work but this specific Twilio number rings busy, the issue is likely with your Twilio Elastic SIP Trunk configuration for inbound calls. Here are the key troubleshooting steps:

Check Your Twilio Origination Settings

For inbound calls to work, you need to verify your origination setup in your Twilio Elastic SIP Trunk(1). The origination SIP URI should be set to sip:sip.retellai.com(1).

For toll-free numbers specifically, you may need to specify the transport protocol. The correct origination URI format would be sip:sip.retellai.com;transport=tcp(2).

Common Inbound Issues

If your inbound call is not connecting, check your origination setting in your SIP trunking provider and review the logs in your telephony provider(2). You may need to open a ticket with Twilio directly(2).

Verify Number Assignment

Ensure your number is properly moved to the Elastic SIP Trunk in Twilio(1). After moving the number to the trunk, you need to import it to Retell so the system knows how to route the call(1).

Since Your Number is Under SMS Review

You don’t need to release the number to fix this issue. The problem appears to be configuration-related rather than number-related, since your other numbers work fine(1).

Next Steps

Check your Twilio Console logs for this specific number to see error details. Verify the origination URI is correctly set to sip:sip.retellai.com (or with ;transport=tcp for toll-free)(2)(1). Confirm the number is still assigned to your Elastic SIP Trunk in Twilio(1).

If these steps don’t resolve the issue, you can visit Contact Sales, ask questions on Discord, or visit https://github.com/RetellAI/(2).

I am not using SIP trunking that I manage. I purchased all of the number through Retell and have them mapped to my Retall AI agent directly. I do not have access to Twilio utilites as they are brokered through Retell. I will pursue the other support options noted.

I understand - you’re using Retell-managed numbers, not custom SIP trunking. Since the issue is specific to one number while your other Retell-managed numbers work fine, and you haven’t made any configuration changes, this appears to be a backend issue that Retell support will need to investigate.

Since you don’t have direct access to the underlying telephony provider (Twilio) for Retell-managed numbers, you’ll need to work directly with Retell support to troubleshoot this specific number issue.

You can reach Retell support through:

When you contact them, mention that:

  • The number was working previously and stopped without configuration changes
  • Other Retell-managed numbers (including new ones) work fine with the same agent
  • The number is under SMS review, so you need to keep it
  • The issue appears to be number-specific rather than agent-specific

This will help them investigate whether there’s a backend routing issue or carrier problem with that specific number.

Hello @FTIAdmin,
Can you share the org ID and which number has the issue?
Also, does the call show up on Retell or not?


I don’t have specific information about sharing org IDs or troubleshooting specific number issues in the available sources. However, I can provide guidance on debugging outbound call issues with Retell AI.

When an outbound call has a status of not_connected, you can check the disconnection_reason field to diagnose the issue(1). Common disconnection reasons include(1):

  • invalid_destination: The destination phone number is invalid
  • telephony_provider_permission_denied: SIP trunk authentication failed
  • telephony_provider_unavailable: The telephony provider is not available or has errors
  • sip_routing_error: Issues with SIP routing
  • marked_as_spam: The call was marked as spam
  • user_declined: The user explicitly declined the call
  • dial_failed: SIP error codes are not available, or error is unknown
  • dial_busy: The number dialed is busy
  • dial_no_answer: The number dialed did not answer

Troubleshooting steps:

  1. Check the call history and detailed log, which contains the disconnection reason, SIP error code, and error message(1)

  2. If using custom telephony(1):

    • Double check your configuration
    • If the configuration is incorrect, delete the imported number and re-import
    • Check with your telephony provider for errors on their side
  3. If using numbers purchased from Retell(1):

    • Ensure the destination number can accept the call (currently, numbers purchased from Retell can only make calls to US numbers)

For calls marked as spam, you can(1):

  • Purchase a new number and warm it up gradually
  • Increase the pickup rate
  • Register the number with Retell’s spam remediation feature

To view whether calls appear in your Retell dashboard, you can access the call history through the Call History page, which now supports custom filters and reorderable columns(2).

**

Hello Omar,

Thank you for reaching out to me.

I am new to the platform but here is the info I have:
Workspace ID: org_9Le0f0IeJTup7ac5
Agent ID: agent_15a6e2e14e61cb055f2ca47d9f
Retell LLM ID: agent_15a6e2e14e61cb055f2ca47d9f

954-833-7870 - Twilio immediatly rings busy, it was working in the last 2 days, although I don’t know when it started having issues. I do not see any calls in the Retell Call Log. The other working numbers are 812-992-1212 Telnyx and 602-806-2393 Twilio. FYI have other agents that are working and I do see calls being logged as shown below and my last two test calls to 954-833-7870 are not showing up in the log.:

Thanks,

Damon

Based on your situation where 954-833-7870 rings busy immediately and doesn’t show in Retell’s call logs, while your other numbers (602-806-2393 from Twilio and 812-992-1212 from Telnyx) work fine, this indicates the issue is at the Twilio configuration level before calls even reach Retell(1).

Key Diagnostic Points

Since calls to 954-833-7870 don’t appear in Retell’s call logs at all, the calls aren’t reaching Retell’s SIP server(1). This is different from calls that connect but fail - those would show up in your logs(1).

Immediate Steps to Check in Twilio

Verify the number 954-833-7870 is still assigned to your Elastic SIP Trunk in Twilio Console(1). Check that your Elastic SIP Trunk’s Origination URI is correctly set to sip:sip.retellai.com(1)(2).

For some numbers, especially toll-free, you may need to specify the transport protocol: sip:sip.retellai.com;transport=tcp(1).

Review Twilio Logs

Check your Twilio Console logs specifically for 954-833-7870 to see if there are error messages or routing issues(1). Since your other Twilio number (602-806-2393) works, compare the configuration between these two numbers in Twilio.

Possible Causes

The number may have been accidentally unassigned from your Elastic SIP Trunk(1). There could be a Twilio-side routing issue specific to this number(3). The origination settings may have changed or been reset(1).

Re-import if Needed

If you need to change the configuration of the imported number in Retell, you would need to delete and re-import the number(1). However, try the Twilio-side checks first since that’s where the issue likely is.

Getting Support

For inbound call issues, check your origination setting in your SIP trunking provider and review the logs in your telephony provider, and perhaps open a ticket with them(1).

You can also:

I have stated this already; I do not use my own SIP trunking to connect to Retell. I purchased the number through Retell, even though it is Twilio, your firm is managing the infrastructure. I do not have any access on this number to view Twilio configuration

Hello @FTIAdmin

Your issue here is with your inbound webhook; your call fails to start because of it. To make sure, try removing the webhook and trying again.