Can anyone clarify the expected behavior of screen recording metadata when calls are routed through specific BYOC configurations in the ap-southeast-1 region? We have recently audited our recording compliance logs and noticed a significant discrepancy in how session data is tagged for trunks originating from our primary carrier in Singapore compared to our standard PSTN routes. While the audio files themselves are intact and accessible via the standard object storage endpoints, the associated metadata fields, specifically call_leg_type and direction, often default to null or incorrect values for approximately 15% of inbound calls on these specific trunks. This issue appears to correlate with SIP 100 Trying responses that are sometimes delayed by our carrier’s edge devices, potentially causing the Genesys Cloud platform to miss the initial handshake metadata before the media stream is established. The problem does not seem to affect outbound calls, which suggests the issue lies in how the platform processes the initial INVITE for inbound traffic on these specific SIP endpoints. We have verified that the trunk registration status remains REG_REGISTERED throughout the duration of these calls, and there are no visible errors in the standard SIP trace logs that would indicate a protocol violation. Furthermore, the analytics dashboard shows these calls as completed interactions, but the screen recording module fails to attach the correct contextual data, making automated quality assurance processes unreliable for this segment of traffic. We are currently on version 2024-09 of the platform and have confirmed that the recording policy is set to ALL_CALLS with no regional exclusions. Is there a known limitation or required configuration adjustment for handling delayed SIP signaling on ap-southeast-1 BYOC trunks to ensure accurate screen recording metadata population?