Unknown cause and irregular cases of 'not_connected' status

Support Help
1

Hi,

Recently we’ve launched an outbound agent for a client of ours. Only we’ve found that a significant amount of calls gets a ’not_connected’ status (some do, some not, there is no clear difference between those calls), something that is nowhere further explained, and when asking our client if they normally experience this when calling manually it almost never happens. Thus, we could really use some support here.

We have multiple agents for this client, but in the following examples we’ll show conversations from a single agent.

Some examples in which the call did not connect (some of many):

1. Agent id: agent_d53932969f4a0a9cfc345f63e8, call_id: call_b36a0bd40b79ef8adcf76972d2a

2. Agent id: agent_d53932969f4a0a9cfc345f63e8, call_id: call_6b873bd90cf248c7c0f090dae12

3. Agent id: agent_d53932969f4a0a9cfc345f63e8, call_id: call_c608896bfc9a7069bcb57035f92

Please let me know if there’s any other information I can provide.

Kind regards,

Bruno

2

Based on the available sources, the not_connected status falls under the disconnection reasons tracked by Retell AI(1). The API documentation lists several disconnection reasons including dial_busy and dial_failed(1), which are the most relevant to outbound calls that don’t connect.

For outbound calls that show not_connected, the issue typically relates to telephony-level problems rather than agent configuration. The disconnection_reason field in the call response provides details about why calls disconnect(1).

To diagnose your specific issue, you should:

Check the disconnection_reason field in your call details for each of the failed calls. This will tell you whether the calls are experiencing dial_busy, dial_failed, or another specific issue(1).

Review your telephony setup. If you’re using SIP trunking, ensure your configuration supports the call volume and that your telephony provider (such as Twilio, Telnyx, or Vonage) is properly configured(2). SIP trunking requires specific provider configuration to handle outbound calls reliably(2).

Verify number formatting and validity. Ensure the phone numbers you’re calling are formatted correctly and are valid numbers that can receive calls.

Since you mentioned this happens inconsistently with no clear pattern, I’d recommend checking if there are any rate limiting or concurrency issues with your telephony provider. Similar to the batch calling issue where UI delays can occur(3), telephony providers may have limits that aren’t immediately visible.

For direct support with your specific call IDs, I recommend:

3

Each call with a status ‘not_connected‘ has the disconnection reason: ‘Dial_no_answer’, and the detailed logs show the following error message:

e.g.:
”2026-01-28 18:45:41.571 call_b36a0bd40b79ef8adcf76972d2a error: Error dialing to user, SIP status code: undefined SIP error category: user_no_answer Error: twirp error unknown: canceled”

4

Based on the error details you’ve provided, the dial_no_answer disconnection reason indicates that the number dialed did not answer(1)(2). This is one of the standard disconnection reasons for outbound calls that fail to connect(1).

The specific error message you’re seeing - "SIP status code: undefined SIP error category: user_no_answer Error: twirp error unknown: canceled" - suggests the call is being placed but the recipient isn’t picking up within the expected timeframe(2).

Key points about dial_no_answer:

The dial_no_answer disconnection reason represents cases where the number dialed did not answer(1)(2). This is classified under the not_connected call status(2).

Potential causes for your situation:

Since you mentioned your client rarely experiences this when calling manually, but you’re seeing it frequently with the AI agent, consider these factors:

  1. Call timing - If your outbound campaigns are running at times when recipients are less likely to answer, this could explain the pattern.

  2. Caller ID presentation - The number your calls are coming from might not be recognized by recipients, leading to lower answer rates compared to manual calls from known numbers.

  3. Ring duration settings - There may be a timeout configured that’s shorter than what your recipients need to answer.

  4. Telephony provider configuration - If you’re using custom telephony through SIP trunking, verify your termination SIP URI configuration is correct(3). Issues with SIP configuration can manifest as inconsistent call connection problems(4).

Recommended troubleshooting steps:

Check your call detailed logs for the SIP error codes(1). The fact that the SIP status code shows as “undefined” suggests there may be a configuration issue with your telephony setup(1).

If you’re using a custom SIP trunk (like Twilio), ensure your authentication credentials are correctly configured(3)(4). One user reported similar intermittent issues that were related to SIP trunk authentication(4).

For direct assistance with these specific call IDs and error patterns:

5

Evy, any reason why some calls via the same agent and same twilio trunk do work while others do not?

6

Based on the sources, there are several reasons why calls through the same agent and Twilio trunk might work inconsistently(1).

Common Disconnection Reasons for Outbound Calls

When outbound calls show not_connected status, the disconnection_reason field tracks specific causes(1):

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

Troubleshooting Steps for Twilio SIP Trunk Issues

For your Twilio elastic SIP trunk configuration, check these specific points(2):

  1. Check your Termination SIP URI for any spaces and remove them(2)
  2. Use a localized termination URI near your region(2)
  3. Verify your username and credentials are correct (the username is different from the friendly name)(2)

Check Call History and Detailed Logs

The call history and detailed log contains the disconnection reason, the SIP error code, and the error message(1). In most cases, this provides enough information to identify the root cause(1).

If Configuration Issues Persist

If the configuration is not correct, delete the imported number and re-import(1). If that does not solve it, check with your telephony provider to see what’s the error on their side(1).

Number Marked as Spam

When a number experiences high outbound call volume spike without any warmup, and/or has a low pickup rate, it might be marked as spam by carriers(1). When this happens, the number will get blocked frequently(1). To remedy this, you can try to:

  • Purchase a new number, and warm it up before pouring all traffic to it (slowly add outbound traffic to it)(1)
  • Increase the pickup rate(1)
  • Register the number with Retell’s spam remediation feature(1)

Since you’re experiencing inconsistent behavior with the same agent and trunk, I recommend checking the detailed logs for each failed call to identify the specific disconnection_reason and SIP error codes, as these will reveal whether the issue is authentication-related, routing-related, or spam-related.

7

And what do you make of the fact that these calls do not send ‘call_started‘ events, but they do send ‘call_ended‘ and ‘call_analyzed‘ events?

8

This behavior is actually documented and expected for calls that don’t connect(1).

According to the webhook documentation, when a call does not connect (such as calls with dial_failed, dial_no_answer, or dial_busy disconnection reasons), the call_started webhook will not be triggered(1). However, the call_ended and call_analyzed webhooks will still be triggered for these calls(1).

The documentation explicitly states: “When the call did not connect (like calls with dial_failed, dial_no_answer, dial_busy disconnection reason), it will not have its call_started webhook triggered. It will still have its call_ended and call_analyzed webhook triggered.”(1)

This means the webhook behavior you’re observing is working as designed. The absence of call_started events combined with the presence of call_ended and call_analyzed events confirms these are calls that failed to connect at the telephony level(1).

To understand why these specific calls aren’t connecting, you’ll need to examine the disconnection_reason field in the call_ended webhook payload or retrieve the call details via the Get Call API(2). This will tell you whether the issue is dial_failed, dial_no_answer, dial_busy, or another connection-related reason(1)(2).

9

Hello @bruno_ipster

These calls look normal; they ring, but the user didn’t pick up or canceled.