Screen Recording Playback Failure for BYOC Trunks with Custom SIP Headers

Need some help troubleshooting an issue where screen recordings are failing to generate for interactions routed through our Singapore BYOC trunks, despite the call data appearing correctly in the WEM dashboard.

We are managing 15 BYOC trunks across APAC regions, and this behavior is isolated to the Singapore edge instances. The voice recordings are capturing perfectly fine, and the interaction metadata shows the correct trunk ID and carrier. However, when we query the /api/v2/analytics/screenrecordings endpoint for these specific interactions, the response body indicates a status of ‘failed’ with no accompanying error message in the standard response payload.

Upon digging into the server-side logs via the support bundle, we noticed a series of timeout errors originating from the screen recording service attempting to handshake with the agent’s desktop client. The SIP INVITE messages for these calls include custom headers we added for carrier-specific routing logic, specifically X-Custom-Routing-ID and X-Carrier-Auth. We suspect these headers might be interfering with the signaling required to initiate the screen capture session, although the voice path remains unaffected.

We have verified that the Genesys Cloud Desktop client is updated to the latest version (2024.1.0) on all affected agents. The outbound routing configuration uses the standard SIP trunk group with failover logic enabled, but the primary trunk is always selected for these specific carrier routes. Disabling the custom SIP headers temporarily resolves the issue, but this is not a viable long-term solution as we require these headers for billing reconciliation with our carrier partners.

Is there a known limitation or configuration setting that allows custom SIP headers to pass through without disrupting the screen recording handshake? We have reviewed the documentation on BYOC trunk configuration and SIP credentials, but nothing explicitly mentions header restrictions for the screen recording service. Any insights into how the screen recording service parses the SIP INVITE would be greatly appreciated.