Inbound call accepted by SIP edge but never answered — shows 0s duration in dashboard

Support Help
1

Hi Retell team,

We had a caller-facing failure on an inbound call and we have a packet capture from your SIP edge showing the call was never answered despite being accepted. The call appears in our dashboard as call_c943461a7223ea55df888af8d24 with a 0-second duration, and the caller reported being disconnected / never picked up.

Call details:

  • Retell call ID: call_c943461a7223ea55df888af8d24
  • Time: 14:26:04 UTC (see pcap timestamps)
  • SIP Call-ID: 83b7b815bc24b7cd292553569b40f3b2@0.0.0.0
  • Twilio CallSid (inbound carrier leg): CAc50153d33e47936526fba711ad6ee6d4
  • Internal To-tag assigned by your side: SCL_GqKmjK7dXx8k

What the pcap shows (captured on your edge, 172.31.42.195):

  1. 14:26:04.843 — INVITE received from Twilio gateway (54.172.60.3). Standard SDP (PCMU/PCMA/telephone-event), call arrived via unconditional forward (Diversion header present).
  2. 14:26:04.843 — Your Kamailio edge responds 100 Trying.
  3. 14:26:04.927 — 180 Ringing sent with a To-tag, so an internal call leg was created.
  4. 14:26:05 through 14:26:33 — the identical 180 Ringing is retransmitted every 1 second (29 times). No 200 OK is ever sent. The capture ends ~29 seconds after the INVITE with the call still unanswered.

So the INVITE was delivered and accepted, an internal leg was created, but the call was never answered — the caller heard ~30 seconds of ringing and gave up. This is a medical scheduling line, so unanswered calls are a serious issue for our clinic client.

Questions:

  1. What happened internally after the 180 was generated? Did agent allocation, the LLM websocket connection, or the media server fail for this leg?
  2. Was our account at or near its concurrency limit at that time? If so, why did the call ring indefinitely instead of being rejected with a busy/486 so the carrier could fail over?
  3. Why does the dashboard show this as a 0-second call rather than surfacing an error state (e.g., “not connected” / “agent failed to answer”)? A 0s record makes these failures invisible in our monitoring.
  4. Is there a recommended configuration to have unanswered calls rejected quickly (e.g., 4xx/5xx after N seconds) so upstream forwarding can fall back to a human line?

We can share the full pcap on request. Please treat with urgency — this directly impacted a caller trying to reach their clinic.

Thanks,
Giovanni

2

Hey @gio Thank you for reporting this. I’ve shared the issue with our team for review.

We’ll keep you updated as soon as we have more information.

Best regards

3

Hello @gio Thanks for the detailed PCAP and call information. That helped us narrow this down quickly.

One correction first: the call ID originally referenced, call_c943461a7223ea55df888af8d24, appears to be a different successful call. The call matching the PCAP and Twilio CallSid CAc50153d33e47936526fba711ad6ee6d4 is:

call_bcf6d7dd814d50af987b8b0fc5d

For that call, the INVITE was admitted immediately, the inbound webhook returned successfully, and the LiveKit room was created. The SIP participant also joined the room, so the inbound SIP side was established.

The issue occurred on the agent side of the connection. The Retell worker did start for this call and stayed active for the full 30-second window, but its LiveKit room connection did not complete successfully. Because the agent side never became active and never published audio, Retell never sent a 200 OK back on the SIP leg. That is why your capture shows repeated 180 Ringing responses until the caller/carrier side disconnected.

This was not caused by concurrency. The workspace was below its concurrency limit at the time, and the call was admitted with no queue wait. If this had been a concurrency-limit rejection, we would expect an immediate SIP rejection rather than sustained ringing.

You are also right to flag the dashboard behavior. Because the call never reached 200 OK, the duration shows as 0 seconds. The disconnect was then labeled based on the final carrier-side disconnect event, which makes this look like a normal caller hangup even though Retell did not successfully answer the call. We are treating that as an observability gap and are escalating it internally so this type of failure is surfaced more clearly.

At this point, we have ruled out admission, webhook handling, SIP ingress, concurrency, and a worker crash. The remaining failure point is the worker-to-LiveKit room connection for this specific call. We are continuing to review the lower-level connection logs to determine the exact reason that connection did not become active.

For mitigation, Retell does not currently expose a customer-configurable setting to reject the SIP leg after N seconds if the agent side has not connected. The best immediate workaround is to configure the upstream Twilio routing with a shorter Dial timeout and failover route, for example routing to a human line if Retell has not answered within 10–15 seconds.

In summary:

  • The call was received and admitted by Retell.
  • The webhook returned successfully.
  • The LiveKit room was created and the SIP participant joined.
  • The Retell worker started, but its LiveKit connection did not complete successfully.
  • No 200 OK was sent, so the call remained in ringing until the carrier/caller disconnected.
  • Concurrency was not the cause.
  • The 0-second / user-hangup dashboard labeling is misleading for this failure mode, and we are escalating that internally.
  • We are continuing to investigate the exact lower-level connection failure.

Thank You

4

Hey Shah Fazal, thanks for your investigation and response, 2 remaining questions:

  • If on retell we setup a fallback number for those phone lines it would work in this case or that wouldnt change for those scenarios?
  • Would Opt in Stable Server help us on those kind of failures or this stability should address other kind of issues?

Thanks,

Gio

5

Any update here @Shah-Fazal ?

6

@gio I have pinged the team again on this.

7

Hey @gio For the fallback number, it likely would not have helped with this specific incident. Retell’s fallback number is currently used when the workspace is in outage mode or when an inbound call cannot obtain a concurrency slot within the fallback window. In this case, the call was successfully admitted, had a concurrency slot, and the SIP participant joined the LiveKit room. The failure happened afterward, while the agent worker was connecting to the room, so the call did not enter the normal fallback condition.
I would still recommend configuring a fallback number because it protects against platform outage and concurrency-related scenarios, but I would not rely on it as protection against this exact worker connection failure.
Opting into Stable Server may reduce exposure to newer infrastructure changes and could improve general stability, but we do not currently have evidence that it would have specifically prevented this call. The failure occurred in the worker-to-LiveKit room connection, and we are still investigating the underlying cause. We do not want to represent Stable Server as a guaranteed fix without confirming that this failure path is handled differently there.
For this clinic line, the most reliable immediate protection remains the upstream Twilio timeout and failover route. Setting a 10 to 15-second timeout means that if Retell does not return a 200 OK within that window, Twilio can route the caller to the human line regardless of why the Retell leg did not answer.
So, in summary:

  • Retell fallback number: useful for outages and concurrency exhaustion, but probably would not have triggered for this incident.
  • Stable Server: may improve general stability, but is not yet confirmed as a fix for this failure mode.
  • Twilio timeout and failover: currently the most dependable mitigation for any scenario where Retell continues ringing without answering.

Thank You