Retell register-phone-call with direct SIP URI dialing from GoTo Connect Web Calls

Support Help
1

I am currently working on integrating a Retell AI agent with GoTo Connect Web Calls, and I am trying to confirm the correct SIP setup for this flow.

The Objective:
We want GoTo Connect Web Calls to place a call to a Retell agent using Retell’s register-phone-call flow and SIP URI dialling.

The intended flow is:

  1. A web user starts a call from our app using GoTo Web Calls.
  2. Our app calls Retell register-phone-call and receives a call_id.
  3. We build the SIP target as: sip:{call_id}@sip.retellai.com;transport=tcp
  4. We then pass that SIP URI into GoTo Web Calls createCall as the dial string.
  5. Retell should match the incoming SIP call to the registered call_id and connect the call to the configured agent.

The Problem:

  • On the GoTo side, createCall succeeds and the browser WebRTC session briefly connects, but the media drops after a few seconds.
  • On the Retell side, when we poll get-call, the call stays in registered status the whole time. It never progresses, never gets a telephony_identifier, and never shows a disconnection_reason.

At the moment, SIP trunking is not an option in this setup from the GoTo Connect side, or at least we are still trying to confirm that. So we are specifically trying to understand whether this direct SIP URI approach is expected to work with Retell.

Help requested:

Wondering if anyone or @Support please clarify:

  • Is sip:{call_id}@sip.retellai.com;transport=tcp the correct SIP target format for Retell register-phone-call when using TCP transport?
  • Is the call_id in the SIP user part the only thing Retell needs to route the call, or is there any additional requirement?
  • Does Retell expect any SIP authentication, username/password, trunk configuration, or specific headers in this flow?

If a SIP platform attempts the call but Retell does not accept or match it, would get-call typically remain stuck in registered like this?

Are there any known requirements or limitations for connecting a telephony platform directly to sip.retellai.com using this registered-call pattern, especially in cases where SIP trunking is not available?

Looking forward to any guidance or clarification.

Thanks.

2

Hi @rotem

1. SIP URI format: The format is sip:{call_id}@sip.retellai.com. Appending ;transport=tcp is supported and correct per the custom telephony docs.

2. Routing: Yes, the call_id in the SIP user part is what Retell uses to match and route the call to the configured agent.

3. Authentication: Retell simply expects an incoming SIP INVITE to sip:{call_id}@sip.retellai.com

4. Stuck in “registered”: This means Retell never received or matched the inbound SIP INVITE. If the call isn’t connected within 5 minutes, it will eventually disconnect with registered_call_timeout. The fact that it stays in registered strongly suggests the SIP INVITE from GoTo never reaches Retell’s SIP server.

GoTo Connect Web Calls may not be sending a standard SIP INVITE to **sip.retellai.com
**
Ensure GoTo’s firewall allows traffic to Retell’s IP block: 18.98.16.120/30, 143.223.88.0/21, 161.115.160.0/19. If GoTo can’t send a true SIP INVITE to an external URI, consider using a SIP intermediary like Jambonz or Cloudonix (listed as Retell telephony partners).

Still have any Issue please share the call IDs along with the PCAP file? This will help us investigate the issue more thoroughly.

Thank you!

3

Thanks @support, this is very helpful.

This clarifies a lot on the Retell side.

From our testing, the SIP URI format we used was:

sip:{call_id}@sip.retellai.com;transport=tcp

We also confirmed through get-call polling that the Retell call stayed in registered for the full watch window and never received a telephony_identifier or disconnection_reason, which matches what you described: Retell never received or matched the inbound SIP INVITE.

On the GoTo side, createCall returns SDP and the browser briefly connects, but the call stays at CONNECTING and media drops after a few seconds. We have now also received an initial response from GoTo support saying that outbound SIP URI targets are not supported in the Web Calls path, so at this point it does look like the INVITE is not actually being sent to Retell in a supported way.

We are still waiting on further clarification from GoTo about whether they support SIP in any other variation or supported routing model that could work here.

If needed, I can share one of the Retell call_id values from our tests. We do not currently have a PCAP because this was a fast lab validation rather than a packet capture setup, but if GoTo comes back saying SIP should be supported in some form, we can collect one next.

Thanks again.