# Unknown cause and irregular cases of 'not\_connected' status **URL:** \ **Category:** Support Help\ **Created:** [January 29, 2026, 12:57pm UTC](https://community.retellai.com/t/unknown-cause-and-irregular-cases-of-not-connected-status/701 "2026-01-29T12:57:15Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![bruno\_ipster](https://avatars.discourse-cdn.com/v4/letter/b/b487fb/32.png) [@bruno\_ipster](https://community.retellai.com/u/bruno_ipster)\ **Post date:** [January 29, 2026, 12:57pm UTC](https://community.retellai.com/t/unknown-cause-and-irregular-cases-of-not-connected-status/701/1 "2026-01-29T12:57:15Z")
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 ---
**Author:** ![support2](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/support2/32/15_2.png) [@support2](https://community.retellai.com/u/support2)\ **Post date:** [January 29, 2026, 12:57pm UTC](https://community.retellai.com/t/unknown-cause-and-irregular-cases-of-not-connected-status/701/2 "2026-01-29T12:57:40Z")
Based on the available sources, the `not_connected` status falls under the disconnection reasons tracked by Retell AI[(1)](https://docs.retellai.com/api-references/create-phone-call). The API documentation lists several disconnection reasons including `dial_busy` and `dial_failed`[(1)](https://docs.retellai.com/api-references/create-phone-call), 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)](https://docs.retellai.com/api-references/create-phone-call). 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)](https://docs.retellai.com/api-references/create-phone-call). **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)](https://docs.retellai.com/deploy/custom-telephony). SIP trunking requires specific provider configuration to handle outbound calls reliably[(2)](https://docs.retellai.com/deploy/custom-telephony). **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)](https://discord.com/channels/1186424376300679209/1450001150135894101), telephony providers may have limits that aren’t immediately visible. For direct support with your specific call IDs, I recommend: - Visit [Contact Sales](https://retellai.octolane.com/) - Ask questions on [Discord](https://discord.com/invite/wxtjkjj2zp) - Visit [https://github.com/RetellAI/](https://github.com/RetellAI/) ---
**Author:** ![bruno\_ipster](https://avatars.discourse-cdn.com/v4/letter/b/b487fb/32.png) [@bruno\_ipster](https://community.retellai.com/u/bruno_ipster)\ **Post date:** [January 29, 2026, 1:17pm UTC](https://community.retellai.com/t/unknown-cause-and-irregular-cases-of-not-connected-status/701/3 "2026-01-29T13:17:47Z")
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” ---
**Author:** ![support2](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/support2/32/15_2.png) [@support2](https://community.retellai.com/u/support2)\ **Post date:** [January 29, 2026, 1:18pm UTC](https://community.retellai.com/t/unknown-cause-and-irregular-cases-of-not-connected-status/701/4 "2026-01-29T13:18:15Z")
Based on the error details you’ve provided, the `dial_no_answer` disconnection reason indicates that the number dialed did not answer[(1)](https://docs.retellai.com/reliability/debug-outbound-call)[(2)](https://docs.retellai.com/reliability/debug-call-disconnect). This is one of the standard disconnection reasons for outbound calls that fail to connect[(1)](https://docs.retellai.com/reliability/debug-outbound-call). 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)](https://docs.retellai.com/reliability/debug-call-disconnect). **Key points about `dial_no_answer`:** The `dial_no_answer` disconnection reason represents cases where the number dialed did not answer[(1)](https://docs.retellai.com/reliability/debug-outbound-call)[(2)](https://docs.retellai.com/reliability/debug-call-disconnect). This is classified under the `not_connected` call status[(2)](https://docs.retellai.com/reliability/debug-call-disconnect). **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)](https://retell.discourse.group/t/i-m-trying-to-use-a-toll-free-number-connected-from-twilio-through-a-sip-trunk/127). Issues with SIP configuration can manifest as inconsistent call connection problems[(4)](https://discord.com/channels/1186424376300679209/1186462578310910112/1375533669619470396). **Recommended troubleshooting steps:** Check your call detailed logs for the SIP error codes[(1)](https://docs.retellai.com/reliability/debug-outbound-call). The fact that the SIP status code shows as “undefined” suggests there may be a configuration issue with your telephony setup[(1)](https://docs.retellai.com/reliability/debug-outbound-call). If you’re using a custom SIP trunk (like Twilio), ensure your authentication credentials are correctly configured[(3)](https://retell.discourse.group/t/i-m-trying-to-use-a-toll-free-number-connected-from-twilio-through-a-sip-trunk/127)[(4)](https://discord.com/channels/1186424376300679209/1186462578310910112/1375533669619470396). One user reported similar intermittent issues that were related to SIP trunk authentication[(4)](https://discord.com/channels/1186424376300679209/1186462578310910112/1375533669619470396). For direct assistance with these specific call IDs and error patterns: - Visit [Contact Sales](https://retellai.octolane.com/) - Ask questions on [Discord](https://discord.com/invite/wxtjkjj2zp) - Visit [https://github.com/RetellAI/](https://github.com/RetellAI/) ---
**Author:** ![bruno\_ipster](https://avatars.discourse-cdn.com/v4/letter/b/b487fb/32.png) [@bruno\_ipster](https://community.retellai.com/u/bruno_ipster)\ **Post date:** [January 29, 2026, 1:24pm UTC](https://community.retellai.com/t/unknown-cause-and-irregular-cases-of-not-connected-status/701/5 "2026-01-29T13:24:00Z")
Evy, any reason why some calls via the same agent and same twilio trunk do work while others do not? ---
**Author:** ![support2](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/support2/32/15_2.png) [@support2](https://community.retellai.com/u/support2)\ **Post date:** [January 29, 2026, 1:24pm UTC](https://community.retellai.com/t/unknown-cause-and-irregular-cases-of-not-connected-status/701/6 "2026-01-29T13:24:32Z")
Based on the sources, there are several reasons why calls through the same agent and Twilio trunk might work inconsistently[(1)](https://docs.retellai.com/reliability/debug-outbound-call). **Common Disconnection Reasons for Outbound Calls** When outbound calls show `not_connected` status, the `disconnection_reason` field tracks specific causes[(1)](https://docs.retellai.com/reliability/debug-outbound-call): - `invalid_destination`: The destination phone number is invalid[(1)](https://docs.retellai.com/reliability/debug-outbound-call) - `telephony_provider_permission_denied`: SIP trunk authentication failed[(1)](https://docs.retellai.com/reliability/debug-outbound-call) - `telephony_provider_unavailable`: The telephony provider is not available or has errors[(1)](https://docs.retellai.com/reliability/debug-outbound-call) - `sip_routing_error`: Loops or issues with SIP routing[(1)](https://docs.retellai.com/reliability/debug-outbound-call) - `marked_as_spam`: The call is marked as spam[(1)](https://docs.retellai.com/reliability/debug-outbound-call) - `user_declined`: The user explicitly declined the call[(1)](https://docs.retellai.com/reliability/debug-outbound-call) - `dial_failed`: SIP error codes are not available, or error is unknown[(1)](https://docs.retellai.com/reliability/debug-outbound-call) - `dial_busy`: The number dialed is busy[(1)](https://docs.retellai.com/reliability/debug-outbound-call) - `dial_no_answer`: The number dialed did not answer[(1)](https://docs.retellai.com/reliability/debug-outbound-call) **Troubleshooting Steps for Twilio SIP Trunk Issues** For your Twilio elastic SIP trunk configuration, check these specific points[(2)](https://retell.discourse.group/t/i-m-trying-to-use-a-toll-free-number-connected-from-twilio-through-a-sip-trunk/127): 1. **Check your Termination SIP URI for any spaces and remove them** [(2)](https://retell.discourse.group/t/i-m-trying-to-use-a-toll-free-number-connected-from-twilio-through-a-sip-trunk/127) 2. **Use a localized termination URI near your region** [(2)](https://retell.discourse.group/t/i-m-trying-to-use-a-toll-free-number-connected-from-twilio-through-a-sip-trunk/127) 3. **Verify your username and credentials are correct (the username is different from the friendly name)**[(2)](https://retell.discourse.group/t/i-m-trying-to-use-a-toll-free-number-connected-from-twilio-through-a-sip-trunk/127) **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)](https://docs.retellai.com/reliability/debug-outbound-call). In most cases, this provides enough information to identify the root cause[(1)](https://docs.retellai.com/reliability/debug-outbound-call). **If Configuration Issues Persist** If the configuration is not correct, delete the imported number and re-import[(1)](https://docs.retellai.com/reliability/debug-outbound-call). If that does not solve it, check with your telephony provider to see what’s the error on their side[(1)](https://docs.retellai.com/reliability/debug-outbound-call). **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)](https://docs.retellai.com/reliability/debug-outbound-call). When this happens, the number will get blocked frequently[(1)](https://docs.retellai.com/reliability/debug-outbound-call). 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)](https://docs.retellai.com/reliability/debug-outbound-call) - Increase the pickup rate[(1)](https://docs.retellai.com/reliability/debug-outbound-call) - Register the number with Retell’s spam remediation feature[(1)](https://docs.retellai.com/reliability/debug-outbound-call) 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. ---
**Author:** ![bruno\_ipster](https://avatars.discourse-cdn.com/v4/letter/b/b487fb/32.png) [@bruno\_ipster](https://community.retellai.com/u/bruno_ipster)\ **Post date:** [January 29, 2026, 2:04pm UTC](https://community.retellai.com/t/unknown-cause-and-irregular-cases-of-not-connected-status/701/7 "2026-01-29T14:04:09Z")
> [@support2](#): > > (1) 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? ---
**Author:** ![support2](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/support2/32/15_2.png) [@support2](https://community.retellai.com/u/support2)\ **Post date:** [January 29, 2026, 2:04pm UTC](https://community.retellai.com/t/unknown-cause-and-irregular-cases-of-not-connected-status/701/8 "2026-01-29T14:04:42Z")
This behavior is actually documented and expected for calls that don’t connect[(1)](https://docs.retellai.com/features/webhook-overview). 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)](https://docs.retellai.com/features/webhook-overview). However, the `call_ended` and `call_analyzed` webhooks will still be triggered for these calls[(1)](https://docs.retellai.com/features/webhook-overview). 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)](https://docs.retellai.com/features/webhook-overview) 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)](https://docs.retellai.com/features/webhook-overview). 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)](https://docs.retellai.com/api-references/get-call). This will tell you whether the issue is `dial_failed`, `dial_no_answer`, `dial_busy`, or another connection-related reason[(1)](https://docs.retellai.com/features/webhook-overview)[(2)](https://docs.retellai.com/api-references/get-call). ---
**Author:** ![Omar\_Ashraf](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/omar_ashraf/32/102_2.png) [@Omar\_Ashraf](https://community.retellai.com/u/Omar_Ashraf)\ **Post date:** [January 30, 2026, 6:42pm UTC](https://community.retellai.com/t/unknown-cause-and-irregular-cases-of-not-connected-status/701/9 "2026-01-30T18:42:28Z")
Hello @bruno_ipster These calls look normal; they ring, but the user didn’t pick up or canceled.