Skip to content Skip to main navigation Skip to footer

Single-server deployment

This documentation is valid for Voice Verify version 1.7.6.

Voice Verify is delivered as a single virtual machine. Both on-premise and cloud deployments are supported. We are able to provide the package for the following hypervisors:

  1. VMware
  2. Amazon Web Services

Hardware requirements

Phonexia Voice Verify as a virtual machine needs only specific hardware for successful operation. The HW specification is as follows.

CPU

Phonexia technologies are optimized for INTEL CPUs. Recommended series are

  • INTEL Xeon E5 generation 3 or 4
  • INTEL Xeon Gold
  • INTEL Xeon Platinum

The specific model selection depends on the expected traffic. To cover the peaks in the estimated load on Phonexia Voice Verify, the system needs enough dedicated CPU cores. There are three tiers according to the number of expected concurrent calls:

Tier Number of expected concurrent calls CPU cores required
1 50 12
2 100 20
3 150 30

For more than 150 concurrent streams, please consider the multi-server Voice Verify deployment. 

RAM

The amount of RAM required for the smooth operation of Phonexia Voice Verify again depends on the expected traffic. The table below shows amount of RAM needed for each tier:

Tier Number of expected concurrent calls GB of RAM required
1 50 16
2 100 24
3 150 32

Disk storage

There are two virtual disks required by Phonexia Voice Verify – a system disk and data disk.

  • System disk
    • Requires 10 GB
    • Contains:
      • Voice Verify
      • License file
      • Audio Source Profile ( = calibration profile)
  • Data disk
    • Capacity is defined by the number of calls processed in parallel
    • Crucial from a Disaster Recovery (DR) perspective + updates
    • Contains
      • Voiceprints
      • Logs
      • PBX instances database

Logs are created during various activities by Phonexia Voice Verify (mainly API requests) and are deleted after some time (90 days). The amount of logs depends on the traffic. The basic formula for the estimation of required disk capacity is dependent on the amount of audio processed by Phonexia Voice Verify. This formula is: 1 minute of 1 audio stream with usual usage (2 verification queries per second) creates 100kB of logs.

As an example, one stream running 24 hours a day straight generates 15GB logs during 90 days. This disk capacity is then required to keep all the necessary logs for this stream.

Networking requirements

The Voice Verify virtual machine needs to meet the following requirements:

  • static IP address (typically an IP address reservation on DHCP server)
  • has to be reachable for API requests
  • needs to be able to connect to a PBX (in case SIP calls are used)
  • allowed ports
    • TCP 22 – SSH connection
    • TCP 80 – WebSockets, Kibana, Grafana
    • TCP 5060 – SIP
    • TCP 8000 – Voice Verify
    • UDP 20000-20350 – RTP
  • domain requirements
    • the customer chooses a domain name on which he wants to run Voice Verify
    • The required DNS configuration for domain „mydomain.com“ is in the next table:
Record Type Value
mydomain.com A Pulic IP address
*.mydomain.com Cname mydomain.com

The domain does not necessarily need to exist, it is possible to include the domain name and corresponding URLs into hosts file (Windows C:\Windows\System32\drivers\etc\hosts or Linux/Mac /etc/hosts). Example:

<IP_ADDRESS> voiceverify.mydomain.com
<IP_ADDRESS> mydomain.com
<IP_ADDRESS> websocket-connector.mydomain.com
<IP_ADDRESS> elasticsearch.mydomain.com
<IP_ADDRESS> kibana.mydomain.com
<IP_ADDRESS> grafana.mydomain.com

where <IP_ADDRESS> is the IP address of the virtual machine.

Architecture

To obtain more detailed information about Voice Verify infrastructure, please contact Phonexia’s consulting team.

API

Once Phonexia Voice Verify is deployed, all its functionality is accessible via API. API integration into the software used in the call center consists of two parts:

  1. giving instructions to Voice Verify (enroll a person, verify, create a back-up,…)
  2. representation of the verification result (verified, not sure, not verified)

Phonexia Voice Verify provides API functionality for several processes:

  • Main functionality – voice enrollment/verification
  • Support administrative process – PBX connectivity, voice streaming, reports, logging, …
  • Maintenance – back-ups, restore

Current offline version of API documentation can be downloaded here:

Voice Verify 1.7.6 API reference

To view it, please unzip the file and import the downloaded JSON to https://editor.swagger.io/

A running instance of Phonexia Voice Verify provides interactive API documentation via http://voiceverify.<mydomain.com>:8000/swagger/ , where mydomain.com is the domain dedicated to it or assigned in the hosts file – see Networking requirements.

Voice input

The next step, after deployment of Voice Verify and loading the Swagger API interface, is providing a voice input. For this reason, these options are available:

Each real-time stream is internally bound to a unique uuid. Using this uuid, enrollment or verification can be called upon a specific voice stream. All voice input options can be combined.

Voice Verify maintenance

Preparation

Phonexia Voice Verify has to enter the Maintenance Mode (GET api/v2/lock) and end all running streams (POST api/v2/maintenance/force_off) before making a back-up.

API back-up and restore

There are two ways of making a back-up via Voice Verify API:

  1. Voiceprint snapshot
    • lets you export all voiceprints as JSON or a compressed JSON file
  2. Back-up
    • lets you back-up the whole database including:
      • voiceprints
      • Audio Source Profiles
      • PBX instances
      • Voice Verify settings

If the database export was done via API, the restoration of Phonexia Voice Verify can be done as follows:

  1. Put the system in Maintenance Mode (GET api/v2/lock)
  2. (Optional) wait till all the running streams are processed for enrollment or verification and then closed (GET api/v2/streams)
  3. Close all the open streams (POST api/v2/maintenance/force_off) to ensure database stability during import
  4. Import the backed-up database (POST api/v2/maintenance/loadbackup) from backup file or the voiceprint snapshot (POST api/v2/snapshot/import); successful upload of the file means that the database is put into the state of a creation of a backed-up file. That means that all enrolled voiceprints from the period between back-up used and its restoration are lost.
  5. Stop Maintenance Mode (GET api/v2/maintenance/unlock) and enable all system endpoints.

Back-up can also be done on the virtualization layer. As Phonexia Voice Verify is a fully virtual machine, it can easily be backed up by creating a snapshot from the virtual environment. Through this option, both System and Data disks are backed up and in case of disaster the system can be completely recovered. In case of a disaster or a need to return to the previous backed-up state, a virtual machine can be recreated by running the previously saved snapshot by VMware. Another option is to back-up the data disk and attach it to restore the backed-up state.

Updates

Reasons for update

  • New version released – feature change

Preparation for the update

  1. Put the system in maintenance mode (POST api/v2/lock)
  2. Wait till all running streams finish or force their closure (POST api/v2/maintenance/force_off)
  3. (Recommended) make backup of the system

During update, downtime is expected.

Phonexia Voice Verify runs on the server and uses an allocated disk for database of all information. Updates are done via replacing the entire Phonexia Voice Verify machine. The new machine is provided by Phonexia. It is crucial to preserve the dedicated disk for maintaining the production data.

Logging

Phonexia Voice Verify gathers information about events happening inside. The Client can extract various logs according to his needs. Logs include information about

  • Voice streams
  • Enrollment actions
  • Verification actions
  • Errors
  • Much more…

Logs are indexed by Elasticsearch and are deleted after 90 days due to storage capacity.. Phonexia Voice Verify provides a Kibana tool for visualization and export of logs. The Client can refer to Kibana manual. Login credentials can be obtained from Phonexia’s Pre-Sale/Consulting teams as the monitoring tool requires a deeper understanding of the whole Voice Verify architecture.

For billing purposes, the API provides an endpoint to extract logs of invoiceable actions (GET api/v2/logging_aggregate). The Client is obliged by contract to provide Phonexia logs including invoiceable actions per frequency as determined by the contract. Note that this endpoint provides various values, however invoicing is ruled by business terms (see contract or Phonexia Voice Verify pricelist) and only invoiceable actions as defined by contract are used for invoicing.

The best practice is exporting the invoiceable actions once per day (each day include the whole period from the beginning of the billing cycle).

The Kibana tool is accessible on http://kibana.mydomain.com.

Monitoring

Voice Verify contains an advanced monitoring tool Grafana accessible at http://grafana.mydomain.com. Login credentials can be obtained from Phonexia’s Pre-Sale/Consulting teams as the monitoring tool requires a deeper understanding of the whole Voice Verify architecture.

Calibration

As the calibration process requires in-depth knowledge of Speaker Identification technology, Phonexia takes care of it for its Clients. Please note, that for this step Phonexia needs purpose-bound and limited access to Client data.

Calibration is part of the Proof of Concept or Set Up phase and belongs under Professional Services.

  1. The Client prepares a dataset as specified below
  2. The Client provides data to Phonexia using one of the following options.
    1. Transfer of the dataset to Phonexia premises
    2. VPN access from Phonexia to Client storage with datasets
    3. Business trip of a Phonexia Technical consultant to the Client location
  3. Phonexia prepares a Calibration profile, called the Audio Source Profile (ASP). For the creation of ASP and the correct calibration, a discussion about the use case and CX vs. security preferences needs to take place between the Client and Phonexia.
  4. During the first installation, ASP is provided as part of package

ASP management

When a change requirement arises, Phonexia provides ASP and allows the Client to apply it to the running Phonexia Voice Verify instance POST /api/v2/maintenance/asp/.

To list all available ASPs, use GET /api/v2/maintenance/asp/. It is possible to obtain a detailed description of a specific ASP via GET /api/v2/maintenance/asp/{uuid} or remove it via DELETE /api/v2/maintenance/asp/{uuid}.

It is possible to store more ASPs, however, only one ASP profile can be used for verifications. This ASP is flagged as active. To get the currently active ASP, use GET api/v2/maintenance/asp/active. To set/unset a specific ASP as active, use POST api/v2/maintenance/asp/{uuid}/active.

The Client is requested to maintain the history and versioning of all datasets and ASPs.

Maintaining accuracy

During the project lifetime it is possible that some components in the Client infrastructure may change. When there is any change in any component providing a channel connection from the Customer to Phonexia Voice Verify, it can affect the accuracy of the system.

In case any component affects the channel changes, Phonexia recommends creating a new evaluation set, making an evaluation (by Phonexia) and utilizing a new calibration profile (POST api/v2/maintenance/load_asp/{name}/).

Regular update of the evaluation set is recommended during the lifetime of a project. Evaluation on an updated evaluation set to be done early (by Phonexia).

 

Related Articles