Context:
My config is not working as expected regarding the integrity of screen recording metadata during carrier failover events. We are managing 15 BYOC trunks across APAC regions, primarily utilizing Singapore and Tokyo endpoints. The environment relies on Genesys Cloud v2023.12 for omnichannel routing. Recently, we observed that when a primary trunk in Singapore experiences a SIP 408 Request Timeout and triggers an automatic failover to the secondary Tokyo trunk, the associated agent desktop screen recordings lose their correlation to the specific interaction ID in the Recording API.
The issue manifests specifically when using the /api/v2/recordings endpoint to fetch metadata. The interactionId field populates correctly for the initial leg of the call handled by the primary trunk. However, once the failover occurs and the call is bridged to the secondary trunk, the screen recording session continues, but the subsequent segments are either orphaned or incorrectly tagged with a generic unknown interaction reference. This breaks our chain of custody for compliance reviews in the legal hold export process. We have verified that the SIP credentials and outbound routing logic are identical across both trunks, and the SIP registration state remains healthy (200 OK) on the backup trunk. The problem appears isolated to the telemetry ingestion pipeline rather than the media stream itself, as the audio recordings remain intact and correctly linked.
We are using the standard Recording API v2 with the includeScreen flag set to true. The delay between the failover event and the metadata sync failure is approximately 300 milliseconds, which suggests a race condition in the event ingestion layer. We have checked the Security Audit logs, but they do not reflect any specific errors related to recording metadata association during the swap.
Question:
Is there a known limitation or configuration requirement for maintaining screen recording metadata continuity during BYOC trunk failover? We need to ensure that the interactionId remains consistent across the entire session, even if the underlying SIP trunk changes. Should we be implementing a specific custom attribute in the Architect flow to force re-association, or is this a backend ingestion bug we need to escalate via a support ticket? Any insights into how the recording service handles session handoffs during network instability would be appreciated.