We have been using your services and are setting up an integration from our custom soft-switch to your LiveKit via SIP. Everything worked successfully for more than a month, but after December 5th, 2025, we can no longer connect to your system over SIP.
We have three IP networks added to our firewall on our side, and we can see that we are connecting to your system and receiving packets. We have tried changing the host settings both to the domain and the IP
address, but it did not help. Some calls are rejected as “busy,” while others keep ringing indefinitely.
I am attaching packet captures (dumps) of two calls (with sensitive IP address replaced with “A“ letters), you can see them here. Could you please review them and let us know what is wrong and how we can resolve this issue?
I can’t directly inspect your PCAPs from here, but I can point you to the concrete checks and configuration details that are documented and that typically cause the exact symptoms you’re seeing (busy vs. ringing forever) when connecting to Retell via SIP.
Confirm you’re targeting the correct SIP domain and transport
Retell documents sip:sip.retellai.com as the SIP server URI, with transport overrides if you want TCP/UDP/TLS.(1)
For example, for TCP: sip:sip.retellai.com;transport=tcp.(1)
Make sure your soft‑switch is dialing the correct URI (including ;transport= if you’re not on the default) and that this matches how you intend to connect (TCP/UDP/TLS).(1)
Verify IP whitelisting / firewall alignment
Retell publishes IP blocks for its SIP traffic so you can whitelist them on your firewall: 18.98.16.120/30 (all regions), 143.223.88.0/21 and 161.115.160.0/19 (US only).(1)
Some non‑US traffic may still come from other IPs but is being migrated to the first block.(1)
Double‑check that:
• All these ranges are allowed bidirectionally (SIP + RTP) on your firewall.
• You’re not still restricting to an older LiveKit domain/IP that no longer matches the documented blocks.(1)
Check whether you’re using “Dial to SIP” vs. SIP trunking
Retell describes two integration patterns: Elastic SIP trunking (recommended) and “Dial to SIP URI” using sip:sip.retellai.com.(1)
In Discord, Retell staff explicitly “highly recommend using SIP Trunking as the means to connect to RetellAI” instead of dial‑to‑SIP, especially when seeing intermittent “No Answer”/registration‑only issues.(2)
If you’re currently doing dial‑to‑SIP, consider moving to an Elastic SIP trunk integration per the documented custom telephony and Twilio‑style trunk flows; this is the recommended and more robust pattern.(1)(3)(4)(2)
Use the Retell Dashboard / API to see the call state and disconnection reason
Retell exposes detailed disconnection reasons and call status via:
• The Retell Dashboard (per‑call logs).(5)(6)
• The List Calls / get-call style APIs, where each call has call_status and disconnection_reason fields.(6)(7)
For outbound attempts that show “busy” or ring forever on your side, look up the corresponding calls and check:
• Whether they appear as not_connected with a reason like dial_busy, dial_no_answer, dial_failed, sip_routing_error, or telephony_provider_unavailable.(5)(6)
• Whether they are just registered and never move to ended, which in Discord has been associated with LiveKit not joining the call after registration in dial‑to‑SIP flows.(2)
This will tell you if Retell is rejecting as busy, failing routing, or never getting the media leg joined.
Validate your SIP routing and trunk configuration
For custom telephony, Retell recommends:
• Using Elastic SIP trunking with your provider (Twilio/Telnyx/Vonage/etc.), then importing numbers into Retell with the correct termination SIP URI and credentials.(1)(3)(4)
• For inbound, setting the origination URI at your provider to Retell’s SIP server address sip:sip.retellai.com.(1)(3)(4)
If you’re fronting Retell with your own soft‑switch, ensure:
• The INVITE is ultimately routed to sip:sip.retellai.com (or the documented LiveKit URI if you are explicitly using TLS and following that pattern).(1)(4)(2)
• There are no SIP routing loops or excessive hops that could trigger a sip_routing_error disconnection reason.(5)(6)
Check for known SIP/media‑layer causes from similar reports
In a similar SIP integration thread, Retell support listed the most common causes for “call registered but no audio/agent not triggered”:
• NAT/firewall blocking RTP (ports in the SDP not reachable).
• SIP ALG interfering.
• Codec mismatch (they specifically mention using PCMU/PCMA/Opus).
• Wrong SIP URI or region endpoint.(8)
Inspect the 200 OK SDP and your PCAP to see if RTP is actually flowing in both directions and matches the IP/port advertised in SDP.(8)
Use Retell’s disconnection‑debug flow for not‑connected calls
For calls that end up with not_connected, Retell documents these disconnection reasons: invalid_destination, telephony_provider_permission_denied, telephony_provider_unavailable, sip_routing_error, marked_as_spam, user_declined, dial_failed, dial_busy, dial_no_answer.(5)(6)
Their recommended steps are:
• First, check the call history and detailed log for the disconnection reason, SIP error code, and message.(5)
• If using custom telephony, double‑check your configuration and re‑import the number if needed.(5)
• If that still doesn’t resolve it, check with your telephony provider for their side of the error.(5)
If you’re on TLS
There is a Discord thread where Retell staff emphasize that when using transport TLS, the origination URI must follow what’s documented for TLS (LiveKit‑style URI) and that mis‑matching the URI/transport can cause “No Answer” behavior.(1)(2)
Double‑check that your TLS setup uses the correct documented URI for TLS and that your firewall allows the TLS handshake and subsequent SIP/RTP flows.(1)(2)
Given that your issue started after a specific date and you already see packets hitting your firewall, the most actionable next steps are:
• Confirm the exact SIP URI (including ;transport=) you’re dialing matches sip:sip.retellai.com and the documented TLS vs. non‑TLS guidance.(1)(2)
• Verify all the Retell IP ranges are still fully open on SIP and RTP ports.(1)
• For a few failing calls, pull the Retell call logs / API data and note call_status and disconnection_reason to see whether Retell is treating them as busy, routing error, or never fully connected.(5)(6)(7)
• If you are using dial‑to‑SIP, strongly consider migrating to an Elastic SIP trunk pattern as recommended.(1)(3)(4)(2)
Since I can’t see your specific call IDs or PCAP content, I can’t pinpoint the exact failure from here. If you share a couple of affected Retell call_ids with Retell support, they can correlate them with internal logs and your PCAPs.
If you’d like, I can also outline a general SIP‑debug checklist (independent of Retell) based on your traces—but that would be outside what’s explicitly documented.
@alvik Be advised that above a month ago, Retell introduced some changes to their signalling stack. As far as I understand, the only thing that currently resides on LiveKit is TLS based signalling. If you are using TCP based signalling (as the previous method with LiveKit), the SIP URIs changed.
The IP block for traffic is 18.98.16.120/30 (All regions), 143.223.88.0/21 (United States only), and 161.115.160.0/19 (United States only)(1). You can use this IP block to whitelist traffic to Retell’s SIP server(1).
If you’re experiencing connectivity issues after the infrastructure changes, verify that:
You’re using the correct SIP URI (sip:sip.retellai.com with the appropriate transport method)(1)
Your firewall/network allows traffic from Retell’s IP blocks(1)
If using TLS, media encryption (SRTP) is properly configured(1)
Without access to your packet captures, I recommend checking these configuration points against the Custom Telephony Overview documentation(1).