Additional Configuration Parameters

Depending on customer need, it may be useful to configure other properties to fine-tune the way that the service operates.

Configuring VCDx Averaging Modes

The xDeTECH VCDx algorithms provide probabilities of whether a particular piece of audio sounds genuine. When those probabilities fall below critical thresholds, that audio segment is marked as a potential anomaly. Instead of responding with ANOMALY_DETECTED as soon as an anomaly is detected for one call audio segment, VCDx calculates an average over several audio segments and returns ANOMALY_DETECTED only when the average threshold over all of those segments falls below the thresholds. VCDx has two “averaging modes” which it uses when calculating whether an anomaly has been detected in a call.

WHOLE_CALL mode. In this mode the average is calculated over all segments in the call received so far. This mode works best for use cases where the client is a call center with human agents so any attacker would have to present as a clone / replay for the entire call.
LAST_N_SAMPLES mode. In this mode the average is calculated over the last N samples received rather than the whole call. This mode works best for use cases where the client is an automated agent so an attacker could potentially switch from genuine voice to a replay/clone part way through a call just to get past a particular check.

Property Name	Default	Purpose
snapins.averaging.mode	WHOLE_CALL	The averaging mode used as defined above.
snapins.averaging.wholecall.min.processing.requests	2	The first request for which an average will be calculated. For the default value, the first audio segments passed to VCDx will always return a `NOT_PROCESSED` status and subsequent segments will return `NO_ANOMALY_DETECTED` or `ANOMALY_DETECTED` based on the average segments supplied for the call so far. Note: segments that do not pass minimum audio quality do not count towards the count of segments received.
snapins.averaging.lastnsamples.window.size	5	How many samples the average will be calculated over. For the default value, the first three audio segments passed to VCDx will always return a `NOT_PROCESSED`result and the fourth will return `NO_ANOMALY_DETECTED` or `ANOMALY_DETECTED` based on the average over segments 1-4. The fifth call will return a result based on the average over segments 2-5 and so on.

Configuring VCDx Active Mode

VCDx is designed to work with both passive audio as well as active audio, where the user is prompted to speak a phrase and will respond with a short phrase segment. This can be a text-dependent phrase where every user speaks the same phrase, a short phrase that is unique to the individual, or a short-phrase response to a menu prompt.

When set to Active (text dependent) Mode, xDeTECH will trim any silence from the beginning and end of each audio phrase. The streamId header should be unique for each of these phrases and VCDx will return a replay and clone detection status, as well as an overall result for the provided audio. If using short phrase segments, you may also need to adjust the analysis.service.qc.min.speech.durationproperty.

Property Name	Default	Purpose
snapins.td.mode		A flag which, if set to true or false, determines whether the snap-ins will run in Text-Dependent mode. A text dependent mode parameter may be supplied in the audio analysis API. If supplied, the value in the request will override whatever value is configured here. This setting is only required if the audio supplied to the snap-ins is a one-off spoken phrase and not part of an audio stream. If set to true the snap-ins will trim silence from the start and end of the audio before processing.

Configuring VCDx Analysis Thread Pool

Depending on the mode of operation of VCDx a certain number of analysis threads are required to analyze audio for a particular call. How many calls can be processed per VCDx instance depends on the CPU/GPU resources available to them. In some cases it may be appropriate to increase the default number of analysis threads so that more calls can be processed simultaneously. The table below shows the relevant VCDx properties that can be configured.

Property Name	Default	Purpose
sentinel.snapin.execution .mode	PARALLEL	Defines how the three analysis processors (aka snap-ins) in VCDx are executed. `PARALLEL` : All three analysis processors are executed concurrently. `PARALLEL_QC_FIRST`: The quality control snap-in is executed first and if it passes the replay and clone snap-ins are executed concurrently. `SEQUENTIAL`: The quality control snap-in is executed first and if it passes the replay and clone snap-ins are executed sequentially.
sentinel.snapin.minimum .pool.size	3	Minimum number of threads required for VCDx to process audio effectively.
sentinel.snapin.number.of .threads	10	The number of worker threads available to analyse audio using the snap-ins. How many threads are used per call depends on the `sentinel.snapin.execution.mode`. `PARALLEL`: 3 `PARALLEL_QC_FIRST:` 2 `SEQUENTIAL`: 1 Note: This value must not be set to lower than `sentinel.snapin.minimum.pool.size`

Configuring VGSx Number of Attempts

By default, VGSx will split the call audio into segments of four seconds in length and call VCDx with each segment until either the call ends or an anomaly is detected. VGSx can be limited to stop call processing after a certain number of successful calls to VGSx. Calls which return a NOT_PROCESSED status are ignored.

Property Name	Default	Purpose
analysis.max.number.of.attempts	-1 (unrestricted)	The maximum number of successfully processed audio segments before audio processing completes regardless of whether the call completed.

Configuring VCDx Proxy

An external proxy can be specified for communication from VCDx to call out to the TrustX ARTHR service to retrieve and validate JWTs and to call out to the Metrics service.

Note that VGSx proxy will not be needed if the VCDx is located in the same docker container.

Property Name	Default	Purpose
trustx.proxyHost		Configure the host as a string value for the VCDx proxy.
trustx.proxyPort		Configure the port number as an integer value for the VCDx proxy.

VGSx Tester

By default, the VGSx Tester will handle 10 simultaneous requests for streaming. If this maximum is exceeded then the streaming of audio data between VGSx and the VGSx Tester is delayed which results in errors when processing files. To configure a different number of threads the two properties listed below must be updated to the same value.

Property Name	Default	Purpose
streaming.threadpool.core.pool.size	10	The maximum number of threads that the VGS tester can stream audio for simultaneously.
streaming.threadpool.max.pool.size	10	This value must be set to the same as the core pool size.

Last updated on