Skip to content Skip to main navigation Skip to footer

Multi-server deployment

This documentation is valid for Voice Verify version 1.7.6.

The multi-server version of Voice Verify needs at least 10 virtual machines (or physical servers) in order to run. The solution consists of several components designed for high availability (for most of the components) and for scalability. Both on-premise and cloud deployments are possible. The deployment process is semi-automatic and it requires cooperation between the customer’s and Phonexia’s DevOps Engineers, who perform deployment to the customer’s environment.

Hardware requirements

The customer defines the maximum expected load for Voice Verify. Phonexia’s DevOps Engineers calculate the server requirements, including the count of virtual machines/servers and specifications for CPU, RAM and HDD.


Phonexia technologies are optimized for INTEL CPUs. Recommended series are

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


Configuration for 500 parallel calls:

Virtual machine/server count CPU RAM HDD
4x 4 8 30 GB
18x 8 16 30 GB
3x 4 4 30 GB

In total, 25 virtual machines/servers with 172 CPU cores, 332 GB RAM and 750 GB HDD.

Networking requirements

Network communication is secure, all endpoints use certificates on customer defined subdomain. Most services use common HTTP on TCP 80.

  • all servers must have an internal static IP address and they have to be able to communicate with each other
  • one of them must be publicly accessible with a static public IP address
    • the customer chooses a domain name on which he wants to run Voice Verify
    • this domain must be redirected to the static public IP address mentioned above
      The required DNS configuration for domain „“ is in the following table:
Record Type Value A Public IP address
* CName
  • SSH access to virtual machines/servers (for deployment and updates only)
  • all servers must be deployed to the same subnet
  • allowed ports
    • inside the subnet
      • TCP port 2377
      • TCP and UDP port 7946
      • UDP port 4789
    • incoming communication from the public – only to the public IP address defined above (server/virtual machine hosting proxy server)
      • TCP 80 – HTTP
      • custom
        • TCP <custom_port_1> – can be set for WebSocket connection
        • TCP <custom_port_2> – can be set for Voice Verify API
        • by default, both of these run on TCP 80


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


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

A running instance of Phonexia Voice Verify provides interactive API documentation via http://voiceverify.<>:8000/swagger/ , where 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


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.


Reasons for update

  • New version released – feature change

Update is done by Phonexia’s DevOps team. Internet connection and SSH access to the public IP address corresponding to is needed.


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 via

Also, the multi server version of Voice Verify, in addition to standard logs, contains advanced monitoring logs, which are deleted after 24 hours due to storage capacity reasons.


Voice Verify contains an advanced monitoring tool Grafana accessible (scalable). 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.


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 /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