Affected number: +5531…0965 (agent agent_ee391c…012)
Summary: We’re seeing inbound calls fail to connect specifically when they arrive via a carrier-side conditional call forward (from a customer’s existing mobile line, forwarded to our Retell number through a Twilio Elastic SIP Trunk to sip:sip.retellai.com). A direct dial to the same number, same agent, same day, connects normally. We’ve ruled out account balance and concurrency limit on our end (see below) and would like help checking SIP-level logs on your side for the specific call IDs.
Reproduced twice today with identical signature -
-
call_b7a7f9…401974 - 2026-08-25 23:20:34 UTC - from +5522…2006 (forwarded) to +5531…0965 - Twilio leg: no-answer (0s) - Retell call_status: not_connected - disconnection_reason: user_hangup - duration 0s
-
call_69570e…53cc99 - 2026-08-25 23:50:54 UTC - from +5522…2006 (forwarded) to +5531…0965 - Twilio leg: no-answer (0s) - Retell call_status: not_connected - disconnection_reason: user_hangup - duration 0s
Control case that worked (same day, same destination, direct dial, no carrier forwarding involved) - call_5d16b3…5198de - 2026-08-25 23:31:11 UTC - from +5579…7434 (direct) to +5531…0965 - ended, agent answered normally, 6s (caller hung up on purpose after hearing greeting)
Same exact signature seen once before, unrelated date/number - call_6581f8…927125 (2026-08-08, to a different number on the same workspace) - same not_connected/user_hangup/0s/$0.000 pattern.
What we’ve already confirmed on our end -
- Our inbound_webhook (call_inbound) responded successfully and quickly both times (~1.1s round-trip per your own logs, matching our server’s own request logs - 201, ~360-460ms server-side) with valid dynamic_variables. So the call reached the point of a healthy webhook exchange before failing.
-
- Twilio’s Call resource for both failed attempts shows direction: trunking-originating, status: no-answer, duration: 0, straight to the Retell SIP endpoint - Twilio’s REST API doesn’t expose a SIP response code for this account/plan, and Monitor Events/Alerts show nothing logged for these call SIDs.
-
- Account credits balance was low at the time of all three calls (including the successful one) - ruled out as the differentiator, since the successful direct call happened under the same low-balance condition.
-
- Concurrent Calls Limit is 20 (checked in Settings → Limits) - nowhere near hit during a single isolated test call, ruled out.
- Open questions for your team -
-
- Can you check your internal SIP signaling logs for these two call IDs and tell us why the inbound INVITE wasn’t answered (e.g., a SIP error code, timeout, or something specific to how the call arrived)?
-
- We noticed our workspace’s Twilio CPS limit is set to 1. Is it possible that carrier-side call forwarding causes Twilio to send more than one connection attempt in quick succession (e.g. a retry) for the same call, and that a second attempt within the same second gets silently rejected by that CPS=1 limit, manifesting as ringing with no answer on the caller’s end instead of a visible error?
-
- Does Retell treat an inbound call differently when SIP Diversion/History-Info headers are present (i.e., a call that arrived via carrier forwarding) versus a clean direct dial? Could malformed/unexpected diversion headers from a Brazilian carrier (Vivo) cause the INVITE to be silently dropped after the call_inbound webhook exchange?
- Happy to provide a PCAP/packet capture if useful, or the full call IDs/phone numbers privately - let us know what data retention/transport settings we need for that to be available.