Why does this config cause SIP recording metadata mismatch in legal export batches?
We are processing a high-volume legal discovery request for a major telecom client. The requirement is strict: chain of custody must be preserved for every SIP trunk recording exported to our S3 bucket via the Bulk Export API. We are using the GET /api/v2/recordings/bulkexport/jobs endpoint to trigger the jobs.
The problem arises when the tenant timezone is set to Europe/London. The export job completes successfully with a 200 OK status, and the files land in S3. However, the metadata file (manifest.json) contains timestamps that are shifted by one hour compared to the actual SIP packet capture time. This happens specifically during daylight saving time transitions. The recordingStartTime in the manifest shows UTC+1, but the raw SIP headers in the .wav file metadata (read via a Python script using mutagen) show UTC+0.
Environment:
- Tenant Region: EU1
- API Version:
v2 - Export Format:
wav - Legal Hold Status: Active
We have verified that the server time is synchronized. The issue seems to be in how the Bulk Export service calculates the recordingEndTime when the recording spans a DST boundary. The discrepancy breaks our audit trail validation script, which expects exact matches between the manifest and the file headers.
Has anyone encountered this specific timestamp skew in the Bulk Export API for SIP recordings? Is there a parameter in the POST /api/v2/recordings/bulkexport/jobs payload to force UTC alignment for the manifest, or do we need to manually correct the timestamps post-export? We need a reliable solution for the current discovery batch, which involves over 50,000 recordings.