Retell SIP Endpoint Retired: Move to sip.retellai.com

Early Retell ran its SIP ingress on LiveKit Cloud, and the docs back then told you to send calls to a LiveKit hostname with a random-looking prefix. In November 2025 Retell moved everyone to its own domain, sip.retellai.com, and marked the old one deprecated. Plenty of trunks never got touched, because nothing broke. Back in March a user asked on Retell's community forum whether the old URI would ever go away, and the answer was that no decision had been made yet.

Now it has. Per Retell's deprecation notice, after 09/30/2026 calls sent to the legacy host “may no longer connect.” That covers three setups:

• Elastic SIP trunks (Twilio, Telnyx, Vonage, anyone else) whose inbound origination URI still names the LiveKit host.
• Dial-to-SIP integrations that register a call and then dial sip:{call_id}@5t4n6j0wnrl.sip.livekit.cloud.
• Custom PBX routes(Asterisk, FreeSWITCH, jambonz, a VoIP platform's “AI integration” screen) with the host hardcoded.

If you bought your numbers inside Retell and never touched SIP, you're not affected. This only bites people who brought their own telephony.

Because Retell never stores it. I pulled the phone numbers on my own Retell workspace through the API this morning. Two of them are imported from a client's Twilio trunk. Here's everything Retell knows about the SIP side of one of them:

"phone_number_type": "custom",
"sip_outbound_trunk_config": {
  "termination_uri": "<client>.pstn.twilio.com",
  "transport": "TCP",
  "auth_username": ""
}

That's the outbound leg: where Retell sends calls when the agent dials out. The inbound leg, where the carrier sends calls to reach your agent, is configured at the carrier. Retell has no field for it. So the retired hostname is sitting in your Twilio console, your Telnyx portal or your PBX, not in Retell. Staring at the Retell dashboard will tell you nothing.

Where to look:

• Twilio:Elastic SIP Trunking → your trunk → Origination → Origination URIs. Check every URI, including low-priority backups.
• Telnyx: the SIP connection (FQDN or IP type) attached to the numbers, under its outbound destinations.
• Code and config: grep -rn "livekit.cloud" across app repos, Terraform, Asterisk pjsip.conf, FreeSWITCH gateways and n8n workflows that build dial strings.

The backup URI is the sneaky one. It's tempting to add sip.retellai.comas priority 10 and leave the LiveKit host at priority 20 “just in case.” Calls work fine until the primary hiccups, then failover lands on a retired host. Delete it; don't demote it.

The host, and only the host. Keep whatever transport you had. If you're picking fresh, Retell recommends TCP.

# before
sip:5t4n6j0wnrl.sip.livekit.cloud;transport=tcp

# after
sip:sip.retellai.com;transport=tcp   # or udp, or tls

# dial-to-SIP (register first, then dial within 5 minutes)
sip:{call_id}@sip.retellai.com

Termination URIs, trunk credentials, the numbers you imported into Retell, agent bindings: all of that stays put. No re-import.

For dial-to-SIP, the 5-minute window is real. Call Register Phone Call, take the call_id, and dial within five minutes or Retell ends it with registered_call_timeout. If you register calls ahead of time in a batch job, that's a separate bug waiting to happen. Also remember that dial-to-SIP doesn't get Retell's built-in transfers; you handle transfers yourself. If you rely on them, an elastic trunk plus Retell's warm transfer is the better setup anyway.

This is the part that worries me. At 09:08 CT on retirement day I sent a plain SIP OPTIONS request to both hosts from my office in Allen, over every transport:

Both green. The old endpoint is LiveKit's shared SIP edge, and answering an OPTIONS ping only proves a SIP server exists at that address, not that it will route a call to your Retell agent. Carrier trunk monitors, Twilio's origination health checks and most PBX “qualify” settings use exactly that ping. They'll keep reporting healthy while real INVITEs fail.

So don't read a green trunk status as “we're fine.” The only proof is a real call that shows up in Retell's call history against the right agent.

Most hosted carriers don't care. On-prem PBXs and locked-down SBCs do. Retell publishes these blocks in its custom telephony guide:

18.98.16.120/30
3.42.144.0/23
153.57.128.0/18
143.223.88.0/21
161.115.160.0/19

Two things I noticed. The new host resolved inside 18.98.16.120/30, which is also the single block Twilio's guide tells you to whitelist for termination. And the legacy LiveKit IPs I got back sit inside 161.115.160.0/19. So a firewall that was built around the old host might pass today's traffic by accident and still be missing the block the new host actually uses. Add all five.

If you use TLS and pin anything, the certificate changed. The old host serves a ZeroSSL wildcard for *.sip.livekit.cloud. The new one serves an Amazon-issued certificate for sip.retellai.com, valid through 30 December 2026 when I checked. A PBX pinned to the old chain or CA will drop the TLS handshake with no helpful error. Retell says mTLS needs a support ticket and their AWS PCA root, so if you're on mTLS, open that ticket today.

It's a 30-minute job per trunk if you do it in this order:

1. Inventory. List every number imported into Retell (phone_number_type: "custom" in the list-phone-numbers API) and map each one to the carrier trunk that feeds it.
2. Add before you remove. On the trunk, add sip:sip.retellai.com with the same transport at the highest priority, then delete the LiveKit URI outright. No fallback entry.
3. Open the firewall for the five blocks above if anything sits between the carrier and the internet.
4. Call every number.From a real cell phone, not a web call. Check that each call lands in Retell's history with the right agent and that the agent can dial out.
5. Grep one more time. Search code, runbooks and onboarding docs for livekit.cloudso the next client setup doesn't copy the old host from a stale template.

Step 5 matters more than it sounds. My guess is that most trunks still on the old host got there by copying an old setup doc, not by anyone choosing it. When I set up voice agents for roofers, I clone the same checklist every time, and one bad line in a checklist becomes one bad line in every client account.

SIP isn't the only deadline on the same page. If you're already in there, check:

• Built-in Cal.com tools: check_availability_cal and book_appointment_calcan't be created or updated through the API after 09/30/2026. Existing ones keep running until 10/31/2026, when Retell migrates them to the Cal.com integration.
• Web SDK 2.x: retell-client-js-sdk 2.x moves to 3.x, where RetellWebClient becomes RetellClient and web call creation moves off /v2/create-web-call.
• LLM auto-migration: agents on claude-4.5-sonnet were moved to claude-4.6-sonneton 29 September. If your agent suddenly sounds different, that's probably why. Re-run your test calls.

Voice platforms move fast, and bring-your-own-telephony setups are the ones that break quietly. It's one of the trade-offs I weighed in Retell vs Vapi: Retell-bought numbers have fewer moving parts, and imported numbers give you control but make you own changes like this one. If you're starting fresh, my Retell AI setup guide walks through the whole build.