Hey everyone, I’ve run into a really strange issue with our bulk export jobs when handling SIP trunk recordings for legal discovery requests. We are using the Recording API v2 to pull metadata and then triggering the bulk export to S3. The issue is that for certain SIP calls, the recorded media file in S3 has a different duration than what is reported in the recording metadata JSON. Specifically, the metadata shows a duration of 120 seconds, but the actual WAV file is 118 seconds. This discrepancy breaks our chain of custody validation scripts, which require exact timestamp matching. The calls are coming through a standard SIP trunk, not a digital channel, so it is not the BYOC edge latency issue we saw before. We are running this from the London region, and the S3 bucket is in eu-west-2. The export job completes successfully with a 200 OK, but the audit trail shows the mismatch. We have tried adjusting the export start time by a few seconds, but it does not align the files. Is there a known issue with how Genesys Cloud calculates duration for SIP recordings versus the actual media stream? We need this to be precise for court submissions. Any insights on where the 2-second gap might be coming from would be appreciated. We are checking the server-side logs now, but nothing obvious stands out.