Facing a data integrity issue with WebRTC softphone recordings during bulk export jobs for legal discovery requests. The environment is Genesys Cloud v2024.02, London region. The specific problem involves a mismatch between the start_time and end_time metadata fields in the exported JSON manifest versus the actual audio file headers.
When initiating a bulk export job via the /api/v2/recording/exports endpoint for interactions routed through the WebRTC softphone, the resulting S3 bucket files show timestamps that are consistently 300 milliseconds later than the interaction start time recorded in the Architect flow logs. This discrepancy is critical for maintaining a valid chain of custody, as legal teams require exact synchronization between the interaction timeline and the audio evidence.
The export job completes successfully with a status of completed, and no errors are returned in the job definition. However, upon inspecting the recordingId in the manifest, the duration field is also slightly inflated, suggesting a potential buffering delay in the WebRTC stream ingestion that is not being accounted for in the metadata generation.
Has anyone encountered this latency offset specifically with WebRTC softphone recordings? The issue does not appear with SIP trunked calls, which export with precise timestamp alignment. We are attempting to validate if this is a known limitation of the WebRTC recording pipeline or if there is a specific configuration in the Architect flow (e.g., Start Recording action settings) that can enforce stricter timestamp synchronization before the recording is committed to the storage backend.
Any insights into whether the Recording API allows for manual correction of these timestamps post-export, or if this requires a platform-level fix, would be appreciated. The current variance is causing rejection of evidence packages by external counsel.