Can anyone explain why the audio segments from WebRTC softphone interactions are showing significant timestamp gaps in the bulk export manifest when processed for legal discovery? We are running Genesys Cloud v2024.06.0 and initiating exports via POST /api/v2/analytics/conversations/export with a strict legal hold filter. The issue specifically affects conversations routed through our WebRTC softphone endpoint, where the media_uri references valid S3 objects, but the metadata indicates missing audio chunks between 00:02:15 and 00:02:45. This creates a chain of custody concern for our compliance team. The export job completes successfully with status: completed, yet the resulting manifest.json shows discontinuous time ranges for the softphone media tracks. We have verified that the S3 bucket permissions are correct and the objects exist, but the playback reveals silent gaps matching the manifest discrepancies. This does not occur with PSTN or SIP trunked calls, only with the WebRTC softphone. We need to ensure the exported audio is continuous for court submission. Has anyone seen similar timestamp fragmentation issues with softphone media in bulk exports? We are considering re-exporting with different date ranges, but the problem persists across multiple jobs. Any insights into how the WebRTC media server handles segment boundaries during export would be appreciated. We are using the default recording retention policy and have not modified any Architect flows related to recording start/stop triggers.