### Answer Based on the available sources, silent calls where the agent speaks but receives no response could be related to voicemail or IVR detection. [(1) ]() When your agent makes outbound calls, it may reach a voicemail or IVR system instead of a person. By default, if voicemail detection isn't configured, the agent will continue speaking even when it reaches a voicemail greeting, which could explain the silent calls you're experiencing. To address this issue, you can configure voicemail detection in your agent's Call Settings: 1. Enable Voicemail Detection in your agent settings under Call Settings 2. Choose the behavior when voicemail is detected: - Hang up if reaching voicemail - The agent disconnects when it detects a voicemail - Leave a message if reaching voicemail - The agent waits for its turn to speak, then leaves a message You can also enable IVR Hangup to automatically disconnect when an IVR system is detected. To check if calls are reaching voicemail or IVR, review the disconnection reason in your call logs. If voicemail is detected, the call will have a disconnection reason of

voicemail_reached

. If IVR is detected, the disconnection reason will be

ivr_reached

. Note that voicemail and IVR detection only runs for the first 3 minutes of the call.

​ To learn more, see the sources I considered: [[1] Handle voicemail and IVR](https://docs.retellai.com/build/handle-voicemail) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

@AI Evy but the disconnection reason says user hangup not agent

### Answer If the disconnection reason shows

user_hangup

, this indicates expected behavior where the user hung up the call [(1) ]() . This is different from voicemail or IVR scenarios. For inbound calls specifically (which you mentioned you're experiencing on your inbound numbers) , silent calls with

user_hangup

as the disconnection reason suggest the caller connected but didn't speak, then disconnected . A few things to check: 1. Review the transcript - Check if there's any captured audio or if it's completely silent from the user side [(2) ]() 2. Check call analysis - The

in_voicemail

field in the call analysis can confirm whether voicemail was detected 3. Examine the public log - The

public_log_url

contains detailed debugging information about the call, including audio reception issues If you're consistently seeing silent calls where no audio is received from the user side, this could indicate a potential issue with audio transmission. The disconnection reason

error_no_audio_received

would appear if Retell hasn't received audio from the telephony provider for a while after connection [(1) ]() . Since this started recently on your inbound numbers, I'd recommend checking your call logs for any patterns in the

public_log_url

to see if there are audio reception issues being logged [(2) ]() .

​ To learn more, see the sources I considered: [[1] Debug call disconnection](https://docs.retellai.com/reliability/debug-call-disconnect) [[2] Get Call](https://docs.retellai.com/api-references/get-call) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

### Answer The logs show the call lasted approximately 30 seconds (from 19:03:22 to 19:03:53) , and the LLM processed input twice, which suggests the agent was attempting to respond but may not have received clear user audio. To investigate further, you can retrieve detailed call information using the Get Call API endpoint [(1) ]() :

bash
curl --request GET \
  --url <https://api.retellai.com/v2/get-call/call_d7605944d12c55559ec90e056a3> \
  --header 'Authorization: Bearer <token>'

This will return comprehensive call data including : -

transcript

- Shows what was actually said by both parties -

transcript_object

- Provides timestamped utterances to see when speech occurred -

public_log_url

- Contains detailed debugging information about audio reception -

recording_url

- The actual call recording to verify if user audio was captured -

disconnection_reason

- Confirms why the call ended Since you mentioned the disconnection reason is

user_hangup

, check the transcript and recording to confirm whether: 1. The user actually spoke but wasn't transcribed (potential ASR issue) 2. No user audio was received at all (potential telephony issue) 3. The user connected but remained silent before hanging up The fact that this pattern started recently on your inbound numbers suggests a systematic issue rather than random caller behavior. The public log will show if there were any audio reception warnings during the call .

​ To learn more, see the sources I considered: [[1] Get Call](https://docs.retellai.com/api-references/get-call) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

### Answer I'd be happy to help analyze the Get Call results, but I don't see the actual response data in your message. Could you please share the JSON response from the Get Call API? [(1) ]() Once you provide the response, I can help you examine key fields that will reveal what happened during the silent call: -

transcript

- The full conversation text to see if any user speech was captured -

transcript_object

- Timestamped utterances showing exactly when the agent and user spoke -

recording_url

- Direct link to the call recording for verification -

disconnection_reason

- Confirmation of why the call ended -

duration_ms

- Total call duration in milliseconds -

latency

- Performance metrics that might indicate issues Please paste the full JSON response and I'll help identify what caused the silent call behavior.

​ To learn more, see the sources I considered: [[1] Get Call](https://docs.retellai.com/api-references/get-call) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

### Answer Based on the logs you've shared, the call shows

user_hangup

as the disconnection reason, which indicates the user (caller) ended the call [(1) ]() . The logs show the LLM processed input twice (at 19:03:25 and 19:03:49) , suggesting the agent attempted to respond during the ~30-second call. To fully diagnose the silent call issue, you need to check additional fields from the Get Call API response that you haven't shared yet : Critical fields to examine: 1.

transcript

- Shows the full conversation text to confirm if any user speech was captured 2.

transcript_object

- Provides timestamped utterances showing exactly when the agent and user spoke 3.

recording_url

- Direct link to the call recording for verification 4.

duration_ms

- Total call duration in milliseconds 5.

call_analysis

- Contains

in_voicemail

field to confirm if voicemail was detected You can access the public log at the URL you provided to see detailed debugging information about audio reception issues . Next steps: Since this pattern started recently on your inbound numbers, check if the transcript shows any user utterances. If the transcript is empty on the user side but shows agent responses, this could indicate: - The user connected but remained silent before hanging up - A potential telephony issue where user audio isn't being transmitted to Retell - An ASR (speech recognition) issue where user speech wasn't transcribed Could you share the

transcript

,

transcript_object

, and

duration_ms

fields from your Get Call response? This will help identify whether user audio was actually received.

​ To learn more, see the sources I considered: [[1] Get Call](https://docs.retellai.com/api-references/get-call) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

### Answer I'd be happy to help analyze the additional details, but I don't see any data in your message. Could you please share the specific fields from the Get Call API response? [(1) ]() To diagnose the silent call issue, I need to see: -

transcript

- The full conversation text to confirm if any user speech was captured -

transcript_object

- Timestamped utterances showing exactly when the agent and user spoke -

recording_url

- Direct link to the call recording for verification -

duration_ms

- Total call duration in milliseconds -

call_analysis

- Contains the

in_voicemail

field to confirm if voicemail was detected You can retrieve all of this information using the Get Call API:

bash
curl --request GET \
  --url <https://api.retellai.com/v2/get-call/call_d7605944d12c55559ec90e056a3> \
  --header 'Authorization: Bearer <token>'

The public log URL you shared earlier (` contains detailed debugging information about the call, including any audio reception issues. Please share these additional fields so I can help identify what's causing the silent calls on your inbound numbers.

​ To learn more, see the sources I considered: [[1] Get Call](https://docs.retellai.com/api-references/get-call) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

### Answer Based on the call data you've shared, this is actually expected behavior for this particular call, not a technical issue. Here's what the data reveals: [(1) ]() What happened: - The caller connected to your inbound number but never spoke during the 29-second call - Your agent greeted the caller and asked for their name, then followed up asking if they were still on the line - The caller hung up without providing any response -

in_voicemail: false

confirms this wasn't a voicemail -

disconnection_reason: "user_hangup"

correctly indicates the caller ended the call The transcript shows only agent utterances: - Agent spoke twice (greeting and follow-up) - Zero user utterances captured - The call summary confirms: "The caller did not respond before hanging up" Why this is normal: This appears to be a caller who connected but chose not to engage - they may have been screening the call, changed their mind, or had another reason for not responding. The

user_hangup

disconnection reason is the correct classification for this scenario. However, if you're seeing a pattern: Since you mentioned these silent calls started appearing frequently last week on your inbound numbers, you should: 1. Check the recording - Listen to the

recording_url

to verify if there's any background noise or attempted speech that wasn't transcribed 2. Review the public log - The

public_log_url

contains detailed debugging info about audio reception 3. Look for patterns - Check if these silent calls are coming from similar phone numbers or at similar times, which might indicate spam/robocall screening behavior If the recordings confirm complete silence from callers across multiple calls, this likely represents caller behavior (screening, wrong numbers, etc.) rather than a technical issue w

ith your Retell AI setup.

​ To learn more, see the sources I considered: [[1] Get Call](https://docs.retellai.com/api-references/get-call) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.