Why does this setting… cause Screen Recording metadata to mismatch with BYOC Trunk Failover events?
We are experiencing a critical data integrity issue in our Genesys Cloud environment (Region: Asia/Singapore) involving the correlation of screen recordings with voice calls routed through our 15 Bring Your Own Carrier (BYOC) trunks.
Specifically, when a call fails over from our primary carrier to a secondary carrier due to a SIP 488 error or timeout, the associated screen recording session-triggered via Architect flow actions-often retains the metadata of the initial trunk registration rather than updating to reflect the active carrier path at the time of recording termination. This results in significant discrepancies in our compliance reporting and agent performance analytics.
The issue manifests when using the POST /api/v2/recordings/screen endpoint to initiate recording sessions linked to interaction IDs. While the voice leg correctly updates its trunk metadata in the interaction history, the screen recording object seems to cache the initial context.
Our current Architect flow configuration for the screen recording trigger is as follows:
flow_id: "recording-trigger-v2"
actions:
- type: "StartScreenRecording"
parameters:
interaction_id: "${interaction.id}"
trunk_context: "${interaction.trunk.id}"
failover_handling: "dynamic"
Despite setting failover_handling to dynamic, the API response for the screen recording retrieval (GET /api/v2/recordings/screen/{id}) returns a trunk_id that matches the primary carrier, even when the call was successfully completed via the secondary carrier.
We have verified that the SIP registration states are healthy across all 15 trunks. The problem appears isolated to the metadata binding logic within the screen recording service during mid-call carrier transitions.
Has anyone encountered similar behavior with BYOC failover scenarios? Are there specific headers or payload fields in the screen recording API call that need to be refreshed manually during a failover event to ensure accurate metadata persistence? We are running Platform API v2 with SDK Python 2.1.8 for our bulk updates, but this specific issue occurs in real-time via Architect actions.