We're attempting to integrate a custom voice bot.  We have this setup:

• Genesys Cloud Voice DID on the PureCloud Voice trunk
• Call Route pointed to Architect Flow
• Architect Flow that transfers to a pseudo DID
• Pseudo DID is mapped in Sites > Number Plan to hand off to a BYOC Carrier SIP trunk that lands on our bot

This works for the initial transfer out from the Architect Flow to the bot via the BYOC Carrier trunk, but when the bot sends back a SIP REFER, Genesys never responds or takes the requested action to transfer.  The bot will re-send the REFER until Genesys sends a SIP 408 Request Timeout back to the bot trunk about 10 seconds after receiving the first REFER message.

In this case, the REFER is telling Genesys to transfer the call to another pseudo DID that maps to a different Architect Flow.  Dialing the desired transfer-to pseudo DID works as expected from within the platform, as well as attempting a transfer to it from an Architect flow directly.

The PCAP that generates does show all the REFER messages, so this appears to be a Genesys-internal processing issue, but I have no means tell "where".  I escalated to our reseller, but wanted to post here in case someone's seen this before and also so I can post the solution once found.

This solution was built per this blueprint https://developer.genesys.cloud/blog/2021-09-03-transferring-calls-to-external-using-byoc/

Phew, this was hard to spot, but so simple once I did.

In the Refer-To: header in the SIP REFER from the bot, the URI didn't have the sip: prefixed to it.  I'm not sure why Genesys wouldn't just hard fail that request with a SIP 400 Bad Request instead of sending it to apparent black hole somewhere, but once we got the developer to revise that header, it worked like a champ.  Now of to play with UUI data, probably.