Genesys Cloud - Developer Community!

Hello everyone,

We have a requirement to pass call-context information during an external transfer from Genesys Cloud to an external vendor-owned IVR DID.

In our Architect IVR flow, calls can be transferred to the vendor IVR for different voicemail scenarios. The vendor IVR needs to identify the reason for the transfer and route the call to the correct voicemail queue/skill.

The scenarios are:

1. Holiday voicemail

2. Business hours closed voicemail

3. Emergency/technical check voicemail

4. Spanish caller opt-in / Spanish queue routing

We have checked with Genesys Support and they confirmed the following:

• UUI is not supported for Genesys Cloud Voice calls.

• The visible external trunk is "PureCloud Voice - AWS", which is provider-managed.

• Customers cannot modify protocol settings, inject custom SIP headers, or control SIP header pass-through on this trunk.

• Adding a Set UUI Data block in Architect before the external transfer will have no effect for a Genesys Cloud Voice trunk.

• Even where outbound UUI is supported, custom header data is unlikely to survive public PSTN routing to an external third-party DID.

• Recommended Architecture: If your business application requires passing custom SIP headers or UUI elements to an external vendor, the standard supported approach is utilizing a Bring Your Own Carrier (BYOC) trunk model (Cloud or Premises). This allows you to manage your own Session Border Controller (SBC) where you have complete control over the trunk signaling properties and header passthrough parameters.

Given these constraints, has anyone implemented a similar use case where Genesys Cloud Voice transfers calls to an external vendor IVR and the vendor needs to know the transfer context?

We are looking for recommended patterns or alternatives, such as:

• Using separate DIDs per scenario, for example one DID for holiday voicemail, one for business-hours-closed voicemail, one for emergency/technical voicemail, and one for Spanish routing.

• Passing context through ANI/DNIS manipulation, if supported.

• Using a data action/API call to update an external system before the transfer, where the vendor IVR can look up the call context.

• Moving to BYOC only for this integration path.

• Any other Genesys-supported approach for passing external transfer context to a third-party IVR.

Also, if we decide to proceed with the recommended BYOC architecture, could someone please clarify the implementation approach?

Specifically:

• Where would the custom SIP headers or UUI values be set: in Architect, on the external trunk, on the SBC, or through another mechanism?

• Can Architect variables, such as voicemail type or language selection, be mapped into SIP headers when using BYOC?

• What configuration is required on the Genesys Cloud side to allow SIP header/UUI pass-through with BYOC?

• What configuration would typically be required on the SBC to preserve or inject the required headers before sending the call to the external vendor?

• Are there any limitations when the call still terminates to a public PSTN DID on the vendor side?

• Would the external vendor also need SIP trunk connectivity instead of a standard DID to reliably receive the custom headers or UUI?

What would be the best practice for this type of requirement when using Genesys Cloud Voice with a provider-managed trunk, and how should we design the solution if we move forward with BYOC?

Thank you.