VALT Technical Specifications

Introduction

This document is designed to be a reference for any person wishing to implement or is interested in the architecture of the Valt application. This document describes each application’s architecture and sub-architecture, along with any associated interfaces and components.

Software Overview

Valt Software: This software is designed to enable users to easily record, review, and manage Audio and Video events in a secure and organized fashion. The software allows users to tag recordings with searchable information, as well as mark specific points within the video files, and tag those markers with searchable information. It has been designed to work with the latest IP camera technology.

Beam Software: This is an iOS application designed to work in conjunction with our Valt software, and is intended to provide a mobile capture and streaming component to our core Valt software. This software enables users to capture Audio and Video events using any iOS device. It allows these events to be streamed live to the Valt software platform, so users can view and initiate events from the iOS device onto the Valt software itself. Beam also allows users to capture content offsite, tag it with information, and automatically have that video upload to the Valt Server when network connectivity to the server is restored.

Server Side Software Architecture

Our software is built on the standard LAMP (Linux, Apache, MYSQL, and PHP) architecture. The software has been designed to work on the latest LTS version of Ubuntu Linux (Server Edition). There are 3 main components to the software application:

Web Server: This makes up the bulk of the application and consists primarily of PHP web pages being served up by the Apache web server.

Database: The database stores all the unique customer specific information.

Media Server: This portion of the application handles all the communication with the cameras and video streams being served out to the client PCs. It also handles all the recording and clip creation.

From a physical or virtual server perspective the entire server side software stack can be run on a single server. For applications requiring more than 50 cameras or consisting of different departments the software can be broken out and additional “Media Servers” can be added. These servers would only run the Media Server portion of the VALT application. This multi-server architecture allows for flexibility and scalability.

Single Server Example:

Multi-Server Example:

Client Side Software Architecture

The Valt client software is browser based. The software has been validated with the following web browsers:

    •	Internet Explorer 10, 11, 12 (Deprecated)
    •	Microsoft Edge
    •	Chrome
    •	Firefox
    •	Safari

The client software consists of two primary components as shown below.

Client PC Requirements

The maximum number of cameras that can be viewed within a single browser tab is 9. Multiple tabs or instances of the application can be opened on the same computer. Here are some conservative client PC requirements for live observation:

Image	Processor	Memory	720P	1080P
	Core i3	4GB	2	1
	Core i5	4GB	4	3
	Core i7	8GB	7	5

Solution Architecture Overview

A complete customer solution is typically composed of some combination of the following components:

    •	Server & Storage
    •	IVS Valt Software 
    •	Axis IP Cameras / Encoders
    •	Microphone Equipment
    •	Client Workstations / Laptops
    •	Optional Components
            o	Talkback
            o	Buttons / RFID Readers
            o	iOS Devices running IVS Beam for Mobile Capture

Solution Network Architecture

Below is a typical standard suggested network architecture diagram. We see this architecture often used in Law Enforcement & Simulation, as well as other environments, where security is important and segmenting access to only the necessary ports / devices is desired but in transit encryption is not a requirement.

If LDAP is being used, the server will also need access to the authentication server(s) as shown below. For LDAP integration using our software, we will also need a bind account and password with read-only access to LDAP.

Below is a diagram of a sensitive network environment, where in-transit encryption is a requirement. This type of network architecture is typical of environments that are using the system to capture / observe actual patient interactions within clinical training environments.

For SSL, we will need the customer to set up a DNS name for the server (example ivs-valt.mysite.edu). We will also need a wildcard or generated signed certificate that is compatible with apache and can be applied by an IVS engineer.

If LDAP is being used, the server will also need access to the authentication server(s) as shown below. For LDAP integration within our software, we will also need a bind account and password with read-only access to LDAP.

Authentication

There are three different authentication methods that can be used for VALT: Local, LDAP/LDAPS and SSO. Any combination of these can be implemented and used at the same time.

Local Authentication

Local accounts are created and assigned to groups within VALT. Local accounts can be created manually or imported from a [[Importing_Users_from_a_file|list].

Bandwidth & Storage

Most of our customers record and stream the video events using our software in either 720P or 1080P resolution. Below is a breakdown of different estimate requirements under both resolution scenarios.

Cameras to Server: This is a persistent 1:1 connection for each camera added to our system. This estimate is assuming H.264 compression is set at 30% @ 30fps, with AAC 16 KHz 32kbit audio:

720P: 500Kbps – 1.8Mbps per camera depending on lighting, color, and scene activity. 1080P: 1.1Mbps – 2.8Mbps per camera depending on lighting, color, and scene activity.

Client to Server Live Observation: This is an on demand connection, and will only be used when clients are performing live observation via the software. This estimate is assuming H.264 compression is set at 30% @ 30fps with AAC 16 KHz 32kbit audio:

720P: 500Kbps – 1.8Mbps per client connection depending on lighting, color, and scene activity. 1080P: 1.1Mbps – 2.8Mbps per client connection depending on lighting, color, and scene activity.

Client to Server Review: This is an on demand connection, and will only be used when clients are performing video review via the software. This estimate is assuming H.264 compression is set at 30% @ 30fps with AAC 16 KHz 32kbit audio:

720P: 500Kbps – 1.8Mbps per client connection depending on lighting, color, and scene activity. 1080P: 1.1Mbps – 2.8Mbps per client connection depending on lighting, color, and scene activity.

Storage: This is the typical storage requirements we see in our applications. This estimate is assuming H.264 compression is set at 30% @ 30fps with AAC 16 KHz 32kbit audio:

720P: ~1GB per hour per camera also dependent on lighting, color, and scene activity. 1080P: ~1.8GB per hour per camera also dependent on lighting, color, and scene activity.

Software Architecture: Containers

Containers are used within our software to segment different objects from different users. The objects that can currently be segmented into containers are: User Groups, Templates & Rooms. Containers are often used in higher educational clinical training applications, where more than one department is sharing a single server or server cluster.

An example would be a university putting in an IVS system to record student / patient interactions for both their Psychology and Speech Pathology programs. Containers would allow them do designate 3 levels of administrators.

Global: This level would see all the Users Groups, Users, Templates, Rooms & Cameras on the IVS system.

Psychology: This level would only see User Groups, Users, Templates, Rooms & Cameras assigned to the Psychology container.

Speech Pathology: This level would only see User Groups, Users, Templates, Rooms & Cameras assigned to the Speech Pathology container.

There is no limit to how many containers / sub containers can reside within our system.

Software Architecture: Users & Groups

From a permissions perspective, the Valt software solution is very flexible, designed to be adaptable to the customer's workflow. The majority of permissions are defined at the “user group” level, with then “users” being added to the corresponding “user groups” inheriting the permissions. Some additional access permissions can be defined at the user level as well. For additional information about user and group permissions, visit Adding a User Group.

See below for a matrix of permissions available in the Valt software:

Users & Groups Rights Table

Permission	Group	User
General	X
General: Home	X
General: Alert	X
General: Edit Profile	X
General: Change Password	X
General: Password Rules	X
General: Notifications	X
Upload	X
Upload: Sharing	X
Upload: Author	X
Upload: Retention	X
Observe	X
Observe: Recording	X
Observe: Recording: Start	X
Observe: Recording: Prepare	X
Observe: Recording: Pause	X
Observe: Recording: Pause: All Authors	X
Observe: Recording: Pause: Resume All Authors	X
Observe: Recording: Stop All Authors	X
Observe: Recording: Sharing	X
Observe: Recording: Evaluation	X
Observe: Recording: Evaluation: View Option Values	X
Observe: Recording: Evaluation: View Field Values	X
Observe: Recording: Evaluation: View Total Values	X
Observe: Recording: Change Author	X
Observe: Recording: Retention	X
Observe: Recording: Options	X
Observe: Recording: Options: All Authors	X
Observe: Recording: Add Markers	X
Observe: Recording: Delete Markers	X
Observe: Recording: Prepare	X
Observe: Recording: Pause	X
Observe: Recording: Pause: All Authors	X
Observe: Recording: Pause: Resume All Authors	X
Observe: Search	X
Observe: Multi-Record	X
Observe: Views	X
Observe: Views: Recording	X
Observe: Talkback	X
Observe: PTZ	X
Observe: PTZ: Control	X
Observe: PTZ: All Authors	X
Observe: PTZ: Presets	X
Observe: PTZ: Add/Delete	X
Observe: Lock	X
Observe: Lock: Unlock all Users	X
Observe: Edit Sharing	X
Observe: Edit Sharing: Create Link	X
Review	X
Review: Markers	X
Review: Markers: View All Authors	X
Review: Markers: Add	X
Review: Markers: Edit	X
Review: Markers: Remove	X
Review: Markers: Overlay	X
Review: Tools	X
Review: Tools: Clip	X
Review: Tools: Redact	X
Review: Delete	X
Review: Download	X
Review: Download: Audio	X
Review: Download: Multiview	X
Review: Change Author	X
Review: Edit Information	X
Review: Evaluation	X
Review: Evaluation: View Option Values	X
Review: Evaluation: View Field Values	X
Review: Evaluation: View Total Value	X
Review: Evaluation: Edit	X
Review: Edit Sharing	X
Review: Edit Sharing: Link	X
Review: Change Author	X
Review: Edit Retention	X
Schedule	X
Schedule: Add	X
Schedule: Exceptions	X
Schedule: Edit	X
Schedule: Edit: All Authors	X
Schedule: Delete	X
Schedule: Sharing	X
Schedule: Change Author	X
Schedule: Retention	X
Schedule: Control	X
Schedule: View All Authors	X
Reports	X
Reports: Add	X
Reports: Edit	X
Reports: Delete	X
Admin	X
Admin: General	X
Admin: General: Software Information	X
Admin: General: Global Settings	X
Admin: General: Media Servers	X
Admin: General: Customization	X
Admin: Templates	X
Admin: Rooms	X
Admin: Users & Groups	X
Admin: Users & Groups: LDAP	X
Admin: Users & Groups: LDAP: User Import	X
Admin: Users & Groups: LDAP: Servers	X
Admin: Users & Groups: LDAP: Sync Schedules	X
Admin: Users & Groups: SSO	X
Admin: Logs	X
Admin: Help	X
Admin: Media Servers	X
Admin: Containers	X
Admin: Update	X
Admin: Multi-Delete	X
Rooms	X	X
Video Access	X	X
Default Retention Rule	X
I/O Record Name	X
Max Record Duration	X
Schedule View	X
Reports View	X
Search Results View	X
Search Results Display Columns	X
Filters	X
Views	X
Restricted Access	X	X
Expiration Date	X	X
Review List Period	X
Email		X
Mobile PIN		X
Card Number		X
SSO/SAML IDP		X
Display Name		X
Control Type		X

Software Backups & Maintenance

Our software runs on Ubuntu 16.04 LTS. It does not come preconfigured with any automated backup software. From a redundancy perspective, our hardware does ship with different RAID levels for the different volumes (typically RAID1 mirror for OS and software and RAID5 for video storage volume). It is recommended to backup the MySQL database (v3). This database contains all the unique software settings and video pointers required to rebuild the OS volume. If you have an existing backup system to integrate with that is recommended, and if you do not wish to perform MySQL backups, a cronjob can be set up on the server.

Example:

0 0 * * * mysqldump -uroot -padmin51 v3 | gzip -c > /usr/local/valt/backup/v3_`date "+\%F_\%T"`.sql.gz

0 1 * * * find /usr/local/valt/backup/ -type f -mtime +7 -name '*.gz' -print0 | xargs -r0 rm –

Some customers also opt to create a backup of the video files. The video volume mount point for this is /usr/local/WowzaStreamingEngine/content/valt_recordings

Video can be moved from media server to media server at any time, so additional media servers can be added when you are running low on disk space. Where the video resides physically is transparent from an end user perspective.