Issue to integrate Genesys Cloud with Retell AI

Hi,

We are trying to integrate Genesys Cloud with Retell AI. We are looking to integrate using External trunk, but Retell documentation use Phone Trunk, which require On prem Edge.

Anyone successfully able to do this integration using external trunk ?

Hey @yanick.daviault The Retell Genesys Cloud integration uses a SIP Phone Trunk (Genesys’ trunk type for registering external SIP endpoints). Despite the “Phone Trunk” name, this does not require an on-prem Edge — it’s a Genesys Cloud–native trunk that terminates against Genesys’ cloud media servers in AWS. Retell registers to it as a SIP endpoint at sip.retellai.com on port 8060 (TCP/UDP) or 8061 (TLS).

“External Trunk” (BYOC) in Genesys is intended for carrier interconnect (PSTN provider Genesys), not for terminating calls into an application/SIP endpoint like Retell, so it’s not the right trunk type for this integration.

Full setup steps: Connect Genesys Cloud to Retell - Retell AI — including Retell IP ranges to whitelist, ports, supported codecs (PCMU/PCMA/G.722), and inbound/outbound routing.

Thank You

I don’t think the documentation is up to date with the latest Genesys Cloud setup. As SIP Phone Trunk require an edge server and it’s requested when you add the DID in Retell.
Termination SIP URI: Your Genesys SIP trunk endpoint. This is the SIP address Retell will dial for outbound calls — typically the FQDN or IP of your Genesys Edge or SBC, on port 8060 (e.g., your-edge.genesys.com:8060). Check your Genesys trunk configuration or contact your Genesys admin for the correct address.”

I did create an External SIP trunk, which work at 90%..
If I call from retell to Genesys it work 100%
If I call from my station in Genesys to retell using that trunk it work at 100%
If I call from external DID to Genesys and then transfer to Retell, it’s not working and look like due to a limitation in my core voice trunk in Genesys. I will ask Genesys.

If you did the full setup on your side with Phone trunk, will be interested to see how you did it exactly.

thanks

Hey @yanick.daviault you’re right, and thanks for the correction. Our Genesys doc is written around Genesys’ “SIP Phone Trunk” terminology, but for a cloud-to-cloud integration with Retell the right choice in current Genesys Cloud is exactly what you built: an External Trunk (BYOC Cloud) pointed at sip.retellai.com:8060 (or :8061 for TLS). No Edge required. We’ll get the doc updated to reflect that.

On the transfer scenario (external DID → Genesys → Retell failing while station → Retell and Retell → Genesys work), that’s almost always a Genesys routing problem on the transfer leg, not a Retell/trunk problem:

  1. Site → Number Plans / Outbound Routes: the Site that owns the flow or user doing the transfer must have a number plan whose classification is selectable by an outbound route that includes your Retell External Trunk. If the Site was originally built for PSTN egress only, the Retell trunk won’t be listed there. Number plans are evaluated top-down — make sure the Retell-matching plan sits above any PSTN plan that would otherwise match.
  2. Carrier trunk restrictions: some inbound carrier trunks reject “trunk-to-trunk” forwarding (the leg that comes in on carrier and leaves on Retell). If Genesys shows the INVITE toward Retell being sent and Retell never sees it, the block is on your side; if Retell sees the INVITE and responds but the carrier tears down, the ingress carrier is refusing the bridged leg. That’s what you’d need to confirm with your Genesys admin / carrier.
  3. Architect flow vs blind transfer: if the transfer is happening in an Architect flow, use a Transfer to Number action that hits the Retell-mapped DID (so Genesys re-routes via the outbound route) rather than a raw SIP transfer that would try to REFER back to the carrier.

To narrow it down quickly, pull the Interaction Detail Record for a failing transfer in Performance → Workspace → Interactions — the SIP event timeline shows whether the outbound leg was ever attempted on the Retell trunk, and any 4xx/5xx from either the Retell side or the carrier side. If you can share one interaction ID (or the SIP capture) we can look at it together.

Thank You