Hi Retell team,
We are scaling outbound and have run into a high dial_failed rate. Our Twilio number attached to agent has been around for years, and is compliant with STIR/SHAKEN requirements.
Today’s dial_failed rate was 57%, which is incredibly disruptive. Tried the documentation to no avail.
Can you help?
A 57% dial_failed rate is concerning. Here’s how to troubleshoot this issue with your Twilio number(1):
Check call history and detailed logs first(1). The logs contain the disconnection reason, SIP error code, and error message—this is usually enough to identify the root cause(1).
For Twilio SIP trunking specifically, verify these configuration elements(2):
Termination SIP URI: Ensure there are no spaces in your Termination SIP URI(2). Use a localized termination URI near your region(2). You can find localized URIs in the Twilio console(2).
Authentication credentials: Double-check your username and credentials(2). Note that the username is not the friendly name shown in the credential list—verify you’re using the actual username(2).
Sufficient funds: Confirm you have sufficient funds in your Twilio account(2).
IP whitelisting: If using IP-based authentication, whitelist all IP addresses in the required range(2):
If configuration appears correct, check with Twilio directly(1). Review logs in your telephony provider’s dashboard and consider opening a support ticket with them(1).
The dial_failed disconnection reason represents cases where SIP error codes are not available or the error is unknown(1).
This is unhelpful.
43% calls are going through and this error is intermittent. So, clearly auth credentials are correct and SIP URI is correc.t
There’s only 1 number, connected to single Twilio account.
Sufficient funds exist.
Again, whitelisting is not an issue.
Twilio logs do not show calls reaching them.
Retell team, I do not want to chat with your generic AI for PROD outage. Can you answer this?
We are running into the same issue. Some calls go through; over 50% do not
477 SIP error category: unknown Error
I am also experiencing this issue. i have a telnyx number being run through retell. my dial failure rate is closer to 65%.
A 65% dial failure rate with Telnyx through Retell requires immediate investigation. Based on recent community reports, this issue has affected multiple users.
First, verify your Telnyx elastic SIP trunking configuration:(1)
FQDN Setup: Add Retell’s SIP server FQDN as sip.retellai.com with SRV as the DNS record type(1)
Outbound Authentication: Select credentials as the authentication method and add the username and password(1)
Required SIP Header: Telnyx requires the header X-Telnyx-Username: <username> to be included in outbound calls when using credentials as the authentication mechanism(1)
Transport Method: Select TCP as the transport method (UDP temporarily not supported due to a connectivity issue)(1)
Termination URI: When importing your number to Retell, supply Telnyx’s FQDN based on your SIP region choice (e.g., sip.telnyx.com)(1)
The telephony_provider_permission_denied disconnection reason represents cases where the SIP trunk authentication failed(2). Recent community cases have identified:(3)(4)
Unverified Origination Numbers: Telnyx error “403 Unverified origination number D51” indicates your originating phone numbers may not be verified in Telnyx(4)
Credential Mismatches: Username and password must match exactly between your Retell configuration and Telnyx trunk(3)
Missing Custom SIP Header: The X-Telnyx-Username header must be properly configured when importing the number or making outbound calls(5)(3)
Check Call History: Review the call detailed log for SIP error codes and error messages(2)
Verify Credentials: Double-check your configuration and ensure you imported the correct username, password, and custom SIP headers(2)
Contact Telnyx: Check with Telnyx support for errors on their side, specifically requesting they verify your origination numbers are properly verified(2)(4)
Request PCAP Files: Ask Telnyx for PCAP files of failed calls with specific call IDs for deeper analysis(3)
If your configuration appears correct but calls still fail randomly, the intermittent nature suggests a provider-level authentication or routing problem rather than a pure configuration error(3).
I’m experiencing the same issue when transferring calls; it didn’t happen before, and we haven’t changed any settings.
Based on similar transfer issues reported by other users, here are the most common causes and troubleshooting steps:
Check your telephony provider configuration first(1). The most frequent cause of sudden transfer failures is an issue on your telephony provider’s side rather than with Retell(1).
Common issues to verify:
SIP 500 errors indicate your telephony provider’s server encountered an internal error(1). Check your provider’s logs and consider opening a support ticket with them(1).
Incorrect Termination URI in your phone number configuration can cause transfer failures(1). Your Termination URI should be the URI from your provider, not Retell’s URI(1).
Transfer destination routing problems may cause calls to loop back to the agent’s own number instead of the intended destination(2). This typically indicates incorrect routing rules in your SIP trunk or telephony provider configuration(2).
For warm transfers specifically, additional permissions from your telephony provider may be required(3). If cold transfer works but warm transfer fails, contact your provider about enabling the necessary permissions for warm transfers(3).
Verify your transfer call configuration:
sip:username@domain(4)(5)For caller ID override issues, note that Retell-Twilio numbers support showing the user’s number on both warm and cold transfers, while Retell-Telnyx numbers only support this via SIP REFER with cold transfer(4)(5). If caller ID override isn’t supported by your provider, the transfer may fail(4)(5).
Check your call’s detailed logs for the specific disconnection reason and SIP error code to identify the root cause(1).
Hi Support,
Thank you for the response.
This is impacting production outbound operations.
To clarify, this issue is not related to call transfers.
We are experiencing intermittent outbound dial failures (~50–60%) with SIP category 477 / unknown.
Our trunk provider is Telnyx.
Telnyx confirms that failed calls never reach their network. Successful calls occur intermittently within the same time window, confirming that termination URI, authentication, and trunk configuration are valid.
This indicates the failure is occurring at Retell’s SIP edge prior to trunk handoff.
Please escalate this to an engineer and investigate:
SIP trace logs for the attached Call IDs
The SIP edge/region handling these attempts
Any degraded service or routing instability
Whether CPS enforcement or internal rate limiting is dropping calls before trunk handoff
This appears to be infrastructure-level rather than configuration-level.
Call IDs attached below.
(Attachment export_442ba3e456a422d723614557e.pdf is missing)
Hello @rayr
Can you share a call ID
\I don’t have specific information in the available sources about how to share a call ID with another user. However, one example call ID format from the sources is: call_138440ed15c00ec05519faebdd1(1)
If you need assistance with call IDs or have encountered an issue, you can create a ticket on the bug report channel, and yes you can DM the call ID(2)
For more detailed guidance, check out these potentially useful sources:
Gents, Retell team pushed an update last night that resolved our 477s. To my knowledge, none today.
Given the level of impact to PROD, it’ll be important for us to get details on why this happened and if this will happen again.
Omar, here’s ID for one of the impacted calls from y’day: call_cd537eefa359dc8aa32821cf5f4
Thanks,
Ray
02/27/2026 09:29 MST: call_b0f5b5d2273c63f5c34eefacad8
02/27/2026 09:27 MST: call_bccf5fd6b7f6b371731c379d613
02/27/2026 09:27 MST: call_0216b58ceeab1ce8293ed5f4f4a
I can see you’ve provided three call IDs with timestamps from February 27, 2026. To help you effectively, could you clarify what you’d like to know about these calls? For example:
You can retrieve call details using the Get Call API or List Calls API(1). If you’re looking for post-call analysis data, you can access it through the Dashboard, Webhook, or API once the call has been analyzed(2).
Please let me know what specific information you need about these calls, and I’ll provide detailed guidance.
all three.
Pull the SBC/SIP trace for these call IDs and confirm which SIP edge/region handled them
Confirm whether the failure is before trunk handoff (Retell edge) vs after handoff (carrier/provider)
Share the closest SIP error / TLS handshake detail you see for each call (even if it’s internal logging), and whether it matches the OpenSSL #1491 signature or a different failure mode
I don’t have access to internal SBC/SIP traces, regional routing logs, or detailed TLS handshake diagnostics for specific call IDs. As an AI assistant for Retell AI documentation, I can only provide information that’s explicitly documented in the available sources.
However, I can guide you on what’s available for troubleshooting:
For call disconnection analysis:
You can check disconnection reasons through the Retell Dashboard or by using the get-call API endpoint(1). When outbound calls show dial_failed, it represents cases where SIP error codes are not available or the error is unknown(2).
For debugging steps:
IP blocks for Retell traffic:
Retell’s traffic originates from these IP blocks(3):
18.98.16.120/30 (All regions)(3)143.223.88.0/21 (certain United States traffic)(3)161.115.160.0/19 (certain United States traffic)(3)For detailed internal traces and regional edge information, you’ll need to contact Retell support directly:
call_65fa4c2da35d3ec342b1cd78d01
call_28f6c3916d1c17124a78facdbb2
call_455ec0cc82de8e4aa8a92e83e39
and as many as you want, and the same thing every day “!”“”"
Hello @Jaime_Ferrer
I’m not sure what you mean. The calls you sent are successful
Can you explain more
Tool Result
2:06
tool_call_id: transfer_call_0f3f11
{“status”:“Transfer failed due to an error.. Please inform the customer that the transfer did not go through and offer to try again or assist them directly.”}
2026-02-26 12:48:39.959 call_65fa4c2da35d3ec342b1cd78d01 info: Starting call: call_65fa4c2da35d3ec342b1cd78d01
2026-02-26 12:48:41.002 call_65fa4c2da35d3ec342b1cd78d01 info: Transitioning from node begin (name: begin) to node start-node-1756134309247 (name: Welcome recepcionista)
2026-02-26 12:48:41.012 call_65fa4c2da35d3ec342b1cd78d01 info: Webhook triggered for call_started
2026-02-26 12:48:41.542 call_65fa4c2da35d3ec342b1cd78d01 info: Webhook response received for call_started
2026-02-26 12:49:15.703 call_65fa4c2da35d3ec342b1cd78d01 info: Transitioning from node start-node-1756134309247 (name: Welcome recepcionista) to node node-1761125040333 (name: Piden_catalan)
2026-02-26 12:49:16.254 call_65fa4c2da35d3ec342b1cd78d01 info: E2E latency for this turn: 1608
2026-02-26 12:49:22.963 call_65fa4c2da35d3ec342b1cd78d01 info: E2E latency for this turn: 1658.0029296875
2026-02-26 12:49:31.713 call_65fa4c2da35d3ec342b1cd78d01 info: Transitioning from node node-1761125040333 (name: Piden_catalan) to node node-1768911623753 (name: Logic Split Node)
2026-02-26 12:49:31.784 call_65fa4c2da35d3ec342b1cd78d01 info: Transitioning from node node-1768911623753 (name: Logic Split Node) to node node-1768911201298 (name: Agent Transfer humano)
2026-02-26 12:49:31.858 call_65fa4c2da35d3ec342b1cd78d01 info: Calling tool: agent_swap
Arguments: {“agentId”:“agent_e3ab32ad5e9b9e512b07da6d5a”,“postCallAnalysisSetting”:“only_destination_agent”}
2026-02-26 12:49:31.866 call_65fa4c2da35d3ec342b1cd78d01 info: Received result for tool: agent_swap_bce278 agent_swap
Result: {“status”:“TRANSFER SUCCESSFUL. You are a *new* assistant agent joining an *ongoing conversation* and the previous agent has now exited. Your job is to pick up where the last agent left off and respond *in your own voice*. DO NOT repeat the previous agent’s words, DO NOT announce the transfer, and DO NOT repeat greetings. Address the user’s last request immediately.”}
2026-02-26 12:49:31.928 call_65fa4c2da35d3ec342b1cd78d01 info: Transitioning from node begin (name: begin) to node node-1768910313791 (name: Horario Comercial)
2026-02-26 12:49:31.931 call_65fa4c2da35d3ec342b1cd78d01 info: Calling tool: Horario_comercial
Arguments: {}
2026-02-26 12:49:32.558 call_65fa4c2da35d3ec342b1cd78d01 info: Received result for tool: tool_call_2bec00 Horario_comercial
Result: {“Dia_semana”:“jueves”,“Hora”:“13:49”,“Fiesta”:“NO”,“Fecha”:“2026-02-26”,“Dentro_Horario”:“SI”}
2026-02-26 12:49:32.596 call_65fa4c2da35d3ec342b1cd78d01 info: Transitioning from node node-1768910313791 (name: Horario Comercial) to node node-1770648314691 (name: Conversation)
2026-02-26 12:49:49.568 call_65fa4c2da35d3ec342b1cd78d01 info: E2E latency for this turn: 2732
2026-02-26 12:49:53.532 call_65fa4c2da35d3ec342b1cd78d01 info: E2E latency for this turn: 1536
2026-02-26 12:50:02.898 call_65fa4c2da35d3ec342b1cd78d01 info: E2E latency for this turn: 3422.001953125
2026-02-26 12:50:25.793 call_65fa4c2da35d3ec342b1cd78d01 info: Transitioning from node node-1770648314691 (name: Conversation) to node node-1768910700350 (name: begoña)
2026-02-26 12:50:25.797 call_65fa4c2da35d3ec342b1cd78d01 info: Calling tool: transfer_call
Arguments: {“number”:“+34932133885”,“option”:{“agenticTransferConfig”:{“transferAgent”:{“agentVersion”:118,“agentId”:“agent_87e27c80924b43bad9eff3b36c”},“transferTimeoutMs”:101000,“actionOnTimeout”:“bridge_transfer”},“enableBridgeAudioCue”:true,“type”:“agentic_warm_transfer”,“agentDetectionTimeoutMs”:30000,“onHoldMusic”:“ringtone”},“extension”:“20”}
2026-02-26 12:50:25.801 call_65fa4c2da35d3ec342b1cd78d01 info: custom sip headers {}
2026-02-26 12:50:25.802 call_65fa4c2da35d3ec342b1cd78d01 info: Starting agentic warm transfer {
agenticTransferConfig: {
transferAgent: { agentVersion: 118, agentId: ‘agent_87e27c80924b43bad9eff3b36c’ },
transferTimeoutMs: 101000,
actionOnTimeout: ‘bridge_transfer’
},
enableBridgeAudioCue: true,
type: ‘agentic_warm_transfer’,
agentDetectionTimeoutMs: 30000,
onHoldMusic: ‘ringtone’
}
2026-02-26 12:50:31.177 call_65fa4c2da35d3ec342b1cd78d01 info: Transfer agent call started successfully
2026-02-26 12:50:47.789 call_65fa4c2da35d3ec342b1cd78d01 info: Received result for tool: transfer_call_0f3f11 transfer_call
Result: {“status”:“Transfer failed due to an error.. Please inform the customer that the transfer did not go through and offer to try again or assist them directly.”}
2026-02-26 12:50:47.791 call_65fa4c2da35d3ec342b1cd78d01 info: Transitioning from node node-1768910700350 (name: begoña) to node node-1770648540392 (name: Conversation)
2026-02-26 12:51:03.030 call_65fa4c2da35d3ec342b1cd78d01 info: Transitioning from node node-1770648540392 (name: Conversation) to node node-1768910848711 (name: asun)
2026-02-26 12:51:03.033 call_65fa4c2da35d3ec342b1cd78d01 info: Calling tool: transfer_call
Arguments: {“number”:“+34932133885”,“option”:{“agenticTransferConfig”:{“transferAgent”:{“agentVersion”:118,“agentId”:“agent_87e27c80924b43bad9eff3b36c”},“transferTimeoutMs”:101000,“actionOnTimeout”:“bridge_transfer”},“enableBridgeAudioCue”:true,“type”:“agentic_warm_transfer”,“agentDetectionTimeoutMs”:30000,“onHoldMusic”:“ringtone”},“extension”:“22”}
2026-02-26 12:51:03.036 call_65fa4c2da35d3ec342b1cd78d01 info: custom sip headers {}
2026-02-26 12:51:03.037 call_65fa4c2da35d3ec342b1cd78d01 info: Starting agentic warm transfer {
agenticTransferConfig: {
transferAgent: { agentVersion: 118, agentId: ‘agent_87e27c80924b43bad9eff3b36c’ },
transferTimeoutMs: 101000,
actionOnTimeout: ‘bridge_transfer’
},
enableBridgeAudioCue: true,
type: ‘agentic_warm_transfer’,
agentDetectionTimeoutMs: 30000,
onHoldMusic: ‘ringtone’
}
2026-02-26 12:51:08.669 call_65fa4c2da35d3ec342b1cd78d01 info: Transfer agent call started successfully
2026-02-26 12:51:13.014 call_65fa4c2da35d3ec342b1cd78d01 info: Received result for tool: transfer_call_999ba0 transfer_call
Result: {“status”:“Transfer failed due to an error.. Please inform the customer that the transfer did not go through and offer to try again or assist them directly.”}
2026-02-26 12:51:13.017 call_65fa4c2da35d3ec342b1cd78d01 info: Transitioning from node node-1768910848711 (name: asun) to node node-1768910371767 (name: Conversation)
2026-02-26 12:51:18.023 call_65fa4c2da35d3ec342b1cd78d01 info: E2E latency for this turn: 3707.0048828125
2026-02-26 12:51:38.362 call_65fa4c2da35d3ec342b1cd78d01 info: E2E latency for this turn: 2206
2026-02-26 12:51:52.686 call_65fa4c2da35d3ec342b1cd78d01 info: Transitioning from node node-1768910371767 (name: Conversation) to node end-call-node-1768910202235 (name: End Call)
2026-02-26 12:51:52.686 call_65fa4c2da35d3ec342b1cd78d01 info: Calling tool: end_call
Arguments: {}
2026-02-26 12:51:52.686 call_65fa4c2da35d3ec342b1cd78d01 info: Ending call: call_65fa4c2da35d3ec342b1cd78d01
2026-02-26 12:51:55.826 call_65fa4c2da35d3ec342b1cd78d01 info: Webhook triggered for call_ended
2026-02-26 12:51:55.827 call_65fa4c2da35d3ec342b1cd78d01 info: Webhook triggered for call_analyzed
2026-02-26 12:51:56.616 call_65fa4c2da35d3ec342b1cd78d01 info: Webhook response received for call_ended
2026-02-26 12:51:56.637 call_65fa4c2da35d3ec342b1cd78d01 info: Webhook response received for call_analyzed
Based on your call logs, you’re experiencing agentic warm transfer failures with the error “Transfer failed due to an error.” The transfers are failing after approximately 16-22 seconds, which is shorter than your configured agentDetectionTimeoutMs of 30,000ms and transferTimeoutMs of 101,000ms.(1)
Your configuration shows:
The logs indicate the transfer agent call starts successfully, but then fails before the configured timeouts are reached. This pattern is similar to issues reported in the community where warm transfers fail prematurely despite longer configured timeouts.(2)(3)
Potential causes to investigate:
Extension dialing issues - Your transfers include extensions (20, 22). Ensure your telephony provider supports extension dialing in the format being sent.(1)
SIP trunking permissions - If you’re using custom telephony via SIP trunking (like Twilio), verify that your SIP trunk has permissions for call bridging and warm transfers.(4)
Caller ID override - For warm transfers using SIP DIAL, Retell sets from and P-Asserted-Identity headers. Verify your telephony provider supports these for warm transfers.(1)
Human detection - The agentic warm transfer includes automatic human detection. If detection fails within the timeout window, the transfer will fail.(1)(5)
Recommended troubleshooting steps: