Scripting API variable loss during BYOC trunk failover

General Discussion
1

Just noticed that custom script variables drop when the outbound call switches from the primary BYOC trunk to the backup carrier mid-execution in Genesys Cloud v2.63 (Asia/Singapore). The Architect flow uses the Scripting API v1, but the context seems to reset on the SIP re-INVITE.

Error: Script context invalidated due to carrier transition. Variable ‘cust_ref_id’ is undefined.

Is this a known limitation with BYOC failover logic, or is there a specific setting to preserve the session state across trunk switches?

2

Take a look at at how Genesys Cloud handles state persistence across SIP re-INVITEs, especially when migrating from Zendesk. In Zendesk, the web interface often held session state client-side, so a network blip rarely killed the script context. Genesys Cloud is different. The Scripting API v1 context is tied to the specific media session ID. When a BYOC trunk fails over, that session ID changes, and the old context dies with it.

Here is how to fix this without losing your variables:

  • Move variables to a Data Action. Instead of keeping cust_ref_id in the script context, use a Data Action to write it to a persistent store (like a custom object or an external DB) at the very start of the flow. Read it back after the failover completes.
  • Use Flow Data instead of Script Context. Pass critical IDs through the main Architect flow data path. This survives carrier transitions because the flow itself isn’t resetting, only the media leg.
  • Add a “Wait for Media” block. After the failover, insert a small delay or a media check before the script runs again. This ensures the new SIP session is fully established before you try to access variables.
  • Check your BYOC Trunk settings. Ensure both primary and backup trunks are registered under the same Org ID. Mismatched org IDs can cause the platform to treat them as completely separate calls.

This approach mimics the robustness we used in Zendesk sidebars but adapts it to GC’s event-driven architecture. It’s a bit more work upfront, but it prevents those “undefined” errors during outages.

3

It depends, but generally… Scripting API v1 variables are session-bound, so a SIP re-INVITE during BYOC failover invalidates the context. To persist data like cust_ref_id, implement a webhook to ServiceNow via Data Actions before the call connects. This stores the state server-side, ensuring it survives carrier transitions without relying on ephemeral media session IDs.