The call did not terminate

Support Help
1

We are currently testing the agent and made a call to a mobile phone number. We hung up the phone on our end, but Retell showed that the conversation was still active. We are using Twilio.
Fortunately, we noticed in time that the call was running for too long, so it didn’t drain too much of our balance.

Call ID: call_770d155d992e192b8a8789d39ba

2

signal-2026-06-12-161252
signal-2026-06-12-161252828×1600 38.2 KB

3

Hey @ukrmeat555 I have escalated your Call Id to the the team for a review.

4

Hello @ukrmeat555 we pulled the SIP capture from our SBC for call_770d155d992e192b8a8789d39ba.

  • Your number answered at 13:03:49 UTC (200 OK from Twilio). From that point until 13:05:49 UTC, zero SIP packets arrived from Twilio on our side — no BYE for the callee’s hangup.
  • The only BYE on the dialog is the one Retell sent out to Twilio at 13:05:49 UTC, when the call was stopped from your application. That’s why the call is recorded as manual_stopped rather than user_hangup.
  • Because no disconnect signal ever reached Retell’s session manager, the agent had nothing to react to and sat idle (transcript shows the agent spoke its turns and then waited for ASR input that never came) until your stop-call API cut the leg.
  • We did not negotiate SIP session timers (RFC 4028) on this outbound INVITE, so there was no timer-based fallback to tear down the stalled dialog either. We’re evaluating turning that on for BYOC outbound as a defense-in-depth fix.

The hop that needs to propagate the callee hangup back as a SIP BYE lives on your Twilio Elastic SIP Trunk and its upstream PSTN path to the +995 carrier — that’s outside what we can inspect from the Retell side. Suggested next steps:

  1. Open a Twilio support ticket referencing Call SID CAabedb7ebcc5b2493fe96988d70203a63 and ask Twilio whether their trace shows a BYE from the terminating carrier between 13:03:49 and 13:05:49 UTC on 2026-06-12. If no BYE arrived at Twilio either, it’s an upstream-carrier issue Twilio will need to chase; if Twilio did receive one and didn’t relay it to us, they’ll have the trace to debug it.
  2. Review your Twilio Elastic SIP Trunk configuration with Twilio for whatever hangup-detection / media-timeout options they expose on that trunk type — happy to share our SBC PCAP and signaling logs to attach to the Twilio ticket.
  3. As a defensive cap on the Retell side, you can lower max_call_duration_ms on agent_eb7ce0e03832c9466e4c6c5322 (currently 3,600,000 ms / 60 min) so a future stuck dialog auto-terminates sooner.

Thank You