Deduplicate Recordings policy

The deduplication policy allows correlating 2N/dual-stream recordings and keeping the better quality record only (and deleting the other copy). To determine which copy/instance is better, either the voice quality check results (if available) or the number of RTP packets processed counter is used. The correlation of the records is based on the telephony platform call ID (which can be ambiguous) and the start - end time of the record.

Supported integrations:

Skype for Business voice/video/screen share recording
Network port mirroring based SIP/SCCP based voice/video recording
Cisco proxy-based voice/video recording
BT IPTrade recording
Speakerbus recording
IPC Unigy recording
Avaya DMCC (multiple registration) based voice recording

Deduplication does not remove any copy in case of the following ambiguous situations:

The clock of the Recording Servers are out of sync, the start time of the two records differ more than 5 seconds.
The length of recorded media files differs for more than 3 seconds.
The RTP packet counters differ more than 200 RTP packets.
There is a mid-call failover at one of the recorders. This scenario leads to violating the first 3 requirements for the ongoing records involved in the failover.
For trading turret integrations, when one recorder starts later than the other leading to starting the recording of the ongoing calls later than the other. This scenario leads to violating the first 3 requirements for those records.

The clock of the Recording Servers must be synchronized, a maximum of 5 seconds drift is allowed for 2N correlation.

If the record is under retention (e.g. on WORM storage), the policy will skip the deduplication for the record.

To create a Deduplication Policy, follow the steps below:

Step 1 - Follow the generic policy creation steps described on the following page: Data management policies

Step 2 - Select Deduplicate Recordings as the action

Step 3 - Select your filters to specify which conversations should be processed by this policy