# Outbound calls dropping mid-sentence, logged as user\_hangup with zero captured audio from the far end

**URL:** <https://community.retellai.com/t/outbound-calls-dropping-mid-sentence-logged-as-user-hangup-with-zero-captured-audio-from-the-far-end/3524>\
**Category:** Support Help\
**Tags:** bug\
**Created:** [August 21, 2026, 9:13pm UTC](https://community.retellai.com/t/outbound-calls-dropping-mid-sentence-logged-as-user-hangup-with-zero-captured-audio-from-the-far-end/3524 "2026-08-21T21:13:32Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![madam](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/madam/32/2545_2.png) [@madam](https://community.retellai.com/u/madam)\
**Post date:** [August 21, 2026, 9:13pm UTC](https://community.retellai.com/t/outbound-calls-dropping-mid-sentence-logged-as-user-hangup-with-zero-captured-audio-from-the-far-end/3524/1 "2026-08-21T21:13:32Z")

</div>

We’re running an outbound Conversation Flow agent (agent\_id: `agent_b7ef8160c126dbb63014868e59`) that calls drivers. We’ve had a real-world report of calls dropping partway through, and pulling the call data shows a pattern that looks like a silent disconnect being misreported as `user_hangup`, not an actual hangup on the far end.

Two example calls, same recipient, same day:

**Call 1** (`call_d5269550c7c066bd8f4589e9288`): duration 8 seconds, `disconnection_reason: user_hangup`. The transcript shows the agent’s own greeting cut off mid-word (“I’m reaching out about an order that was” — nothing after that). There is no user turn anywhere in the transcript, no audio, no words, from the far end at all.

**Call 2** (`call_eb8190506410fae47726bcfe787`), same driver, roughly an hour later: duration 32 seconds, `disconnection_reason: user_hangup`. This time the agent completes its full opening line and asks a question. The call then ends with, again, zero captured user speech anywhere in the transcript.

Neither call shows any tool call, error, or webhook failure on our side, both terminated before our flow’s logic ever branched. `in_voicemail` is false on both, and both have `recording_url`/`public_log_url` populated if that helps with investigation.

This looks consistent with a few other threads we found searching the forum describing the same shape of problem, calls logged as `user_hangup` where the actual audio shows a silent transport-level failure rather than a real hangup:

- “Agent hangup in the middle of the conversation”
- “Calls Dropped at the LiveKit Level”

Could someone take a look at these two calls specifically and confirm whether this is the same known issue, and if there’s a fix or workaround available? Happy to provide additional call IDs from the same agent if that’s useful, we can reproduce this pattern somewhat regularly on outbound calls.

Thanks.

---

<div class="post-metadata">

**Author:** ![Shah-Fazal](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/shah-fazal/32/2522_2.png) [@Shah-Fazal](https://community.retellai.com/u/Shah-Fazal)\
**Post date:** [August 21, 2026, 9:36pm UTC](https://community.retellai.com/t/outbound-calls-dropping-mid-sentence-logged-as-user-hangup-with-zero-captured-audio-from-the-far-end/3524/2 "2026-08-21T21:36:22Z")

</div>

Hello @madam Thanks for sharing your Call IDs. Let me check this with the team, and I’ll get back to you with an update.

Thank You

---

<div class="post-metadata">

**Author:** ![Shah-Fazal](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/shah-fazal/32/2522_2.png) [@Shah-Fazal](https://community.retellai.com/u/Shah-Fazal)\
**Post date:** [August 22, 2026, 1:03pm UTC](https://community.retellai.com/t/outbound-calls-dropping-mid-sentence-logged-as-user-hangup-with-zero-captured-audio-from-the-far-end/3524/3 "2026-08-22T13:03:46Z")

</div>

Hello @madam We reviewed both calls on Retell’s side (PCAP + runtime).

On both, the SIP ladder is clean and the terminating BYE arrives inbound at our SIP gateway from your Twilio trunk edge. Retell tore down within ~60 ms of receiving it. TTS, LLM, flow, and interruption logic were all healthy up to that instant no errors, no tool failures, no webhook issues.

- call\_d5269550c7c066bd8f4589e9288 - answered 12:47:37.706 UTC, BYE from Twilio at 12:47:46.134 UTC (~8.4 s). Twilio CallSid CA92ac933765523e86ca847c09a591bc61.
- call\_eb8190506410fae47726bcfe787 - answered 14:03:17.538 UTC, BYE from Twilio at 14:03:49.311 UTC (~31.8 s). Twilio CallSid CA9acd09fa15f82c1e2e33a66489fe0c84.

That’s why the platform labels these user\_hangup, the release came in from the carrier side, not from us. Important nuance: on BYOC, user\_hangup means “BYE received from your trunk”; it does not by itself prove the driver physically hung up. The BYE has no Reason:/Q.850 header and our PCAP is SIP-signaling only (no RTP), so we can’t tell from our vantage point whether it was the driver, the terminating carrier releasing the leg (screening/reachability), or a Twilio terminating-carrier media issue that resolved into a carrier-side BYE.

The authoritative next artifact lives in your Twilio subaccount: open each CallSid above in Twilio Voice Insights and pull:

- SIP Reason / Q.850 cause and Termination Source - distinguishes real hangup (e.g. Q.850 16 originating callee-side) from carrier release (102/41/31/…).
- Inbound RTP counters (packets in, jitter, MOS) - if inbound RTP was near-zero for the whole call, the callee’s audio never made it back to Twilio, which is the tell for a downstream media failure rather than a real hangup.

If either indicates a carrier-side drop, you can check with twilio referencing the subaccount SID and those two CallSids.

Share what Voice Insights returns and we’ll take it from there.

Thank You

---

<div class="post-metadata">

**Author:** ![madam](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/madam/32/2545_2.png) [@madam](https://community.retellai.com/u/madam)\
**Post date:** [August 23, 2026, 6:16pm UTC](https://community.retellai.com/t/outbound-calls-dropping-mid-sentence-logged-as-user-hangup-with-zero-captured-audio-from-the-far-end/3524/4 "2026-08-23T18:16:50Z")

</div>

Thanks for the detailed breakdown and amazing support. That’s exactly what we needed to narrow this down.

Pulled Voice Insights in the Twilio Console for both CallSids (screenshots attached). A few relevant fields for both calls:

- **Who Hung Up:** callee (both calls)
- **Last SIP Response:** 200 OK (both)
- **Twilio RTP Latency to PBX:** \<10ms (both)
- **Twilio RTP Latency to PSTN:** \<10ms (available on call 2)
- **Verified:** true (both, STIR/SHAKEN attestation passed)
- **Silence Detected:** true on `call_eb8190506410fae47726bcfe787` (the 32s call), not shown on `call_d5269550c7c066bd8f4589e9288` (the 8s call)

No Q.850/`Reason` header shown on either, which lines up with what you found on your PCAP side, there just isn’t one on this BYE.

Given `Who Hung Up: callee` plus clean RTP latency on both legs, this looks less like a platform or media-layer issue and more like the disconnect genuinely originated on the receiving end. The `Silence Detected` flag on the 32-second call is the interesting part, that one ran the full opening pitch and the confirmation question before ending, with silence flagged partway through, which reads more like a real person who went quiet and then hung up than an instant carrier-side reject.

Given the account doesn’t have Voice Insights Advanced Features enabled, this Console view is as deep as we can go on these two specific calls. Since the signal points at the callee side rather than anything on Retell’s platform, I think this closes out as “working as expected, not a Retell issue” from what we can see, wanted to close the loop with what we found either way in case hitting the same “user\_hangup with a short, silent call” pattern. What is your input on this?

Appreciate the fast turnaround on this.

 ![CA92ac933765523e86ca847c09a591bc61](https://canada1.discourse-cdn.com/flex008/uploads/retell1/original/2X/f/f611cb636b726d1eac61b0e094721fd412e38dbe.png)

 ![CA9acd09fa15f82c1e2e33a66489fe0c84](https://canada1.discourse-cdn.com/flex008/uploads/retell1/original/2X/0/0b833f094423211269bdc9049763552697dceced.png)

---

<div class="post-metadata">

**Author:** ![Shah-Fazal](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/shah-fazal/32/2522_2.png) [@Shah-Fazal](https://community.retellai.com/u/Shah-Fazal)\
**Post date:** [August 24, 2026, 1:04pm UTC](https://community.retellai.com/t/outbound-calls-dropping-mid-sentence-logged-as-user-hangup-with-zero-captured-audio-from-the-far-end/3524/5 "2026-08-24T13:04:33Z")

</div>

Hello @madam I’ve escalated this with the team for further investigation. I’ll get back to you as soon as I have an update.

Thank You

---

<div class="post-metadata">

**Author:** ![Shah-Fazal](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/shah-fazal/32/2522_2.png) [@Shah-Fazal](https://community.retellai.com/u/Shah-Fazal)\
**Post date:** [August 25, 2026, 1:33pm UTC](https://community.retellai.com/t/outbound-calls-dropping-mid-sentence-logged-as-user-hangup-with-zero-captured-audio-from-the-far-end/3524/6 "2026-08-25T13:33:42Z")

</div>

Hey @madam yes its working as expected on the retell side.

Thank You