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.

#Architect
#Archy
#CXasCode
#DataActions
#EmbeddableFramework
#Integrations
#MobileMessenger
#PlatformAPI
#PlatformCLI
#PlatformSDK
#Scripts
#Triggers
#Uncategorized
#WebMessaging

------------------------------
Federico Collia
------------------------------

Hi @Federico Collia,

Your understanding is correct: with Genesys Cloud Voice / PureCloud Voice, there is no supported mechanism to inject dynamic SIP headers or UUI into the provider-managed trunk. Therefore, placing a Set UUI Data action before the transfer will not solve this particular path.

I would separate the design into two cases:

1. Transfer to a public PSTN DID

If the vendor IVR is reached through a standard public DID, I would not use SIP headers, UUI, or ANI manipulation as the routing mechanism. Even when UUI is available on a BYOC trunk, it is not reliable once the call crosses the public PSTN.

For this model, separate DIDs per destination are probably the most deterministic approach:

• Holiday voicemail DID

• Closed-hours voicemail DID

• Emergency / technical voicemail DID

• Spanish voicemail or Spanish-routing DID

It is simple, transparent for the vendor, easy to test, and does not depend on signaling data surviving between carriers.

A Data Action before the transfer can also be an option, but only if the vendor can reliably correlate the arriving call with the context record. ANI alone is usually not a strong correlation key, especially where multiple calls, reused caller numbers, blocked caller ID, or timing differences can occur.

2. Transfer through a direct SIP connection

If the vendor can expose a SIP trunk or terminate the call through an SBC/PBX under its control, BYOC becomes a valid option.

The typical pattern would be:

1. Route the external transfer through a dedicated BYOC Cloud or BYOC Premises trunk.

2. Enable UUI passthrough on that external trunk.

3. In Architect, build a compact dynamic payload, for example:

   reason=holiday;language=es

4. Use Set UUI Data for Transfers immediately before the external transfer.

5. Send the call through the dedicated BYOC route to the vendor SIP endpoint.

6. Have the vendor SBC/PBX/IVR read the UUI header and route accordingly.

For example, Architect would own the dynamic business context:

• voicemail reason

• language selection

• routing category

• a short correlation token, if needed

The trunk configuration would own the UUI transport settings:

• UUI Passthrough enabled

• selected header type

• encoding format

• protocol discriminator, where applicable

Custom SIP headers configured directly on the Genesys Cloud external trunk are useful for static information, but they are not a native method for inserting dynamic Architect variables into arbitrary headers at runtime.

If the vendor requires a proprietary header such as X-Voicemail-Reason, an SBC in the SIP path could parse the UUI payload and transform it into that vendor-specific header before forwarding the INVITE. That transformation would occur on the SBC, not in Architect.

So, in summary:

• Genesys Cloud Voice + public vendor DID: use separate DIDs or a vendor-side lookup design.

• BYOC + direct SIP vendor endpoint: use Architect Set UUI Data plus UUI-enabled external trunk.

• BYOC + vendor-specific dynamic headers: use UUI from Genesys Cloud and translate it on an SBC, if needed.

• Public PSTN termination: do not rely on UUI or custom SIP headers reaching the vendor.

I would also recommend validating the design with SIP PCAPs on both sides: first at the Genesys BYOC trunk and then at the vendor SBC/IVR. That confirms whether the expected UUI/header is present in the outbound INVITE and whether it survives the full SIP path.

------------------------------
Fernando Sotto dos Santos
Consultor de Atendimento Senior Grupo Casas Bahia
------------------------------