Our inbound voice agents stopped answering calls today. Calls connect to the phone number and ring, but the agent never picks up, and no calls are appearing in our Retell call history at all.
Example Twilio Call SID: CA02248ebf7e1851e5e1973708ac1242c9
Because the calls terminate instantly with a 487 and never show up in our Retell call history, it looks like the INVITE is being rejected before it reaches the agent layer, which points to a number registration or SIP trunk issue on the Retell/LiveKit side rather than the agent itself.
We’ve already confirmed on our end:
The numbers are assigned to the Twilio trunk
The Twilio origination URI points to 5t4n6j0wnrl.sip.livekit.cloud
The agents are published
Can you check whether these numbers are still correctly registered on your SIP layer, and whether the SIP endpoint for our account has changed? If the endpoint rotated, please send us the current SIP/termination details so we can update our Twilio trunk.
I’m also experiencing a similar issue. Any chance there was any new Retell release ~11AM Eastern/8AM pacific (maybe a little before)? OR otherwise can we get an update?
The result from us is when we dial the number that we then have a server dial to sip to Retell’s livekit sip url, we get the result where the phone keeps ringing without ever connecting (until hits max ring time and call ends).
But the calls that we route in directly to Retell with just a retell provisioned phone number still work.
Hey @mychal Just checked with the team and good news, the numbers are healthy on our side. Both +17869525244 and +17869811338 are still registered on the Retell SIP layer, bound to your published inbound agents, and have been answering inbound calls continuously today, including multiple successful calls within the last 15 minutes with normal durations and transfers.
The issue is the Origination URI on your Twilio Elastic SIP Trunk. 5t4n6j0wnrl.sip.livekit.cloud is an internal hostname and is not a supported customer-facing target — Twilio’s INVITEs to it never get a final 200 OK, so Twilio cancels them after a few milliseconds (which is exactly the 487 Request Terminated + 0.016s PDD pattern you’re seeing).
Please update the Twilio Elastic SIP Trunk (TK8a64b0871cb416050720114c57f64f90) Origination URI to:
sip:sip.retellai.com (host only, no DID in the user part — TLS/TCP/UDP all fine)
After that change, place one test call and it should land in Call History immediately. If you still see 487s after switching, send us a fresh failing test timestamp + Twilio CallSid and we’ll pull the SBC-side trace.
Hey @chris No Retell release in that window matches what you’re describing, and this second case is actually a different root cause than your original Twilio Origination URI issue.
For the example you sent (call_9960bbb2de817c54c9996fdedb0 on org_mqWi5tj9xck3o8ig / Trapeze):
The call did reach Retell (it’s recorded in our system).
It was rejected with disconnection_reason = concurrency_limit_reached at 16:32 UTC (12:32 PM ET).
That org’s purchased concurrency is 25. In that single minute we saw 167 inbound attempts and 164 were rejected at the concurrency gate. Outside that burst, every minute today is well under the cap and calls are completing normally (mostly user_hangup / call_transfer).
From the dial-to-SIP client’s perspective this looks exactly like “ringing forever” because Retell never returns a 200 OK on rejected attempts — the client just sits in early dialog until it times out. Retell-provisioned DIDs on the same org keep working because they’re not part of the same burst pattern.
Two paths from here for you:
Raise the purchased concurrency above 25 — happy to loop your CSM / account team in if you want to size it.
Pace the inbound burst on their dial-to-SIP server so it stays under the current cap until the increase is in place.
If you’re still seeing failures outside a burst minute, send me a fresh failing call_id and timestamp and I’ll dig in — but the spike pattern today is clearly concurrency, not a release.
Super weird we were also seaprately having failures not during that time period (around 30 mins before) already that entirely did not reach retell. But things are resolved for now (?). So I think I’m ok.