Genesys Video Deployment Guide
Genesys Video Gateway 9.0.0
3/7/2020 Table of Contents
Genesys Video Gateway Deployment Guide 3 Overview 4 Architecture 5 Components 6 Codec Support 8 Ports and Protocols 9 Media Paths 11 Installing and Deploying Genesys Video Gateway 13 Environment 14 Interoperability Considerations 17 Base Preparation 20 Core Component Installation 26 Platform Configuration 29 TURN Server Installation and Configuration 33 Deployment Models 37 Network Address Traversal 38 Firewalls and Restrictive NAT 40 Deployment Types 42 Security Considerations 44 Scalability 46 Availability 48 Failover 58 Configuration Files 59 Management Interface 60 Configuration Options Reference 63 Hardware Sizing 65 Troubleshooting 66 Genesys Video Gateway Deployment Guide
Genesys Video Gateway Deployment Guide
This deployment guide can be used to install the Genesys Video Gateway (GVG) in your environment. It includes the following information:
• Overview—describes GVG, its architecture, components, codec support, protocols, and media paths. • Installing and Deploying GVG—includes environment requirements, base preparation, core component installation, platform configuration, and Turn server installation. • Deployment Models—provides information on how GVG can be deployed in a production environment, taking into account a variety of typical deployment types. • Management Interface—describes the interface available with GVG, where you provision users, view reports, and so on.
• Configuration Options Reference—descriptions of the parameters available for GVG. • Hardware Sizing—contains network and hardware sizing guidelines. • Troubleshooting—some common scenarios are described.
Genesys Video Deployment Guide 3 Overview
Overview
Genesys Video Gateway provides a server-side interface for WebRTC, Flash, SIP, and HTTP clients to build a video/voice contact center solution. The platform can scale horizontally, and can be monitored in real time with SNMP or through its Management User Interface.
Genesys Video Deployment Guide 4 Overview
Architecture
The following diagram shows WebRTC and Flash clients connecting first to the Collaboration Application Server (AS) within the platform. Following authentication by the AS's Central Login Service, the clients move to an available Collaboration MCU where they can send and receive signaling messages and connect to voice and video sessions. SIP clients can SIP call directly into an MCU.
Media flows directly between client and server where possible, using a range of UDP ports, or if more restricted access is required, the call can be relayed over TURN on a single UDP/TCP port (for WebRTC) or tunneled via HTTPS (for Flash).
Genesys Video Deployment Guide 5 Overview
Components
Genesys Video Gateway consists of the following high-level components:
• Collaboration Application Server (AS) • Collaboration Notification Server (NS) • Flash Server (FS) - not released as a separate Component/IP • Collaboration Multipoint Control Unit (MCU) • MCU Helper processes
• Collaboration TURN Server (TURN) - required for ICE approach to NAT traversal (TURN Server acts as both STUN and TURN server) • Database Server
Depending on your deployment needs, you can deploy AS or MCU on their own servers, or they can share the same server. You must, however, deploy NS as a common component in each server.
Typically, only one instance of the AS per deployment will be in High Availability mode. However, there can be multiple instances of the MCUs that operate as a farm rather than a cluster. Here farm indicates that that they are independent of one another and can be taken in and out of service in a pluggable, hot-swappable way.
You should deploy TURN in its own server. If you deploy TURN server in the same server as the AS, configuration changes are needed to avoid any port and monitoring conflict. You don't need to configure a TURN server cluster for load-balancing, but rather you can deploy a farm of TURN servers for scaling purpose. Both the browser client and the platform can interact with multiple STUN/TURN servers (based on configuration). However, it’s possible to setup a load-balancing configuration for the TURN server(s) as well (not described in this guide).
Collaboration Application Server
Written in pure Java and running in any J2EE container (Jetty by default), the AS takes care of authentication, serving web pages, business logic, and managing the distribution of clients across the available MCUs, which may or may not be on the same physical server.
Collaboration Notification Server
Written in pure Java and running in any J2EE container, the NS is the interface for all HTTP(S) clients interacting with the server. It will proxy signaling messages to the MCU as well as maintain connections and send notifications to the connected clients using either web-socket or Comet. It publishes the present state of connected clients to its parent Collaboration Application Server.
Genesys Video Deployment Guide 6 Overview
Flash Server
Flash Server can exchange voice and video with Adobe Flash clients over the various flash protocols (that is, RTMP) and including the RTMFP protocol that is a UDP low latency and secure protocol.
Collaboration MCU
This is the Conferencing and Trans-coding engine. Written in C++ with a pluggable architecture for different codecs and protocols, MCU brings together disparate as well as similar endpoints from SIP, Flash, and WebRTC into voice and video conferences supporting P2P, compositing, and selective forwarding (SFU) modes where appropriate.
Collaboration TURN Server
The TURN Server is a VoIP media traffic NAT traversal server and gateway. The TURN server provided by Genesys is evolved from the rfc5766-turn-serverproject.
Overall, for NAT traversal for UDP-based multimedia sessions, the protocol used is called Interactive Connectivity Establishment (ICE).ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). The TURN Server supports both STUN and TURN.
STUN is used by an endpoint to check with the STUN/TURN server to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. For more information, see RFC 5389.
To describe TURN in brief: if a host is located behind a NAT, then in certain situations it can be impossible for that host to send/receive media to/from other hosts (peers) using STUN. In these situations, it is necessary for the host to use the services of an intermediate node (TURN server) that acts as a media relay. The TURN protocol allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. For more information, see RFC 5766.
Database Server
You can install the database on the same hardware as the AS. Currently MySQL is used as the database server and gets installed as part of the installation process. The AS creates and populates the database with configuration and run-tme information.
Genesys Video Deployment Guide 7 Overview
Codec Support
The Genesys Video Gateway platform has the following codec support:
Codec Codec Type Supported Interfaces/Protocols G.711* Audio SIP Opus** Audio WebRTC Speex Audio Flash (Web) VP8 Video WebRTC, SIP H.264 Video Flash (Web), SIP
*There is a current limitation that G.711 is not supported in the Web-side for WebRTC calls.
**There is a current limitation that Opus is not supported in the SIP-side for SIP calls.
Genesys Video Deployment Guide 8 Overview
Ports and Protocols
Connection Map
The highlighted rows indicate connections local to the common host machine.
Source Destination Default Port(s) Transport Protocol(s) Browser Application Server 443 TCP Browser TURN Server 443 TCP Browser TURN Server 14049 UDP Browser Flash Server (RTMFP) 14049 UDP Browser Flash Server (RTMPT) 443 TCP Application Server Notification Server 14040 TCP Application Server Database 3306 TCP Notification Server Application Server 80 TCP Notification Server MCU 2131 TCP MCU Application Server 80 TCP MCU Notification Server 14040 TCP MCU SIP Server 5060 TCP/UDP MCU SIP Endpoint 9000-9999 TCP/UDP MCU TURN Server 49152-65535 UDP MCU MCP 20000-45000 TCP/UDP TURN Server MCU 5000-15000 TCP/UDP SIP Server MCU 5060 TCP/UDP SIP Endpoint MCU 5000-15000 TCP/UDP MCP MCU 5000-15000 TCP/UDP
Protocols
The table below shows the protocols used for the interaction between various components:
Flash Flash Notification TURN Application Database From/To MCU Server Server Server Server Server Server (RTMPT) (RTMFP) ICE+DTLS- ICE+DTLS- Browser HTTPS RTMPT RTMFP HTTPS - SRTP SRTP
Genesys Video Deployment Guide 9 Overview
Flash Flash Notification TURN Application Database From/To MCU Server Server Server Server Server Server (RTMPT) (RTMFP)
(TCP/TLS) (UDP) (TCP/TLS) (UDP) (TCP/UDP) (TCP/TLS)
SIP SIP Server ------(UDP/TCP)
RTP SIP ------Endpoint (UDP)
HTTP HTTP Notification - - - - - Server (TCP) (TCP)
ICE+DTLS- TURN SRTP ------Server (UDP)
Flash Proprietary Server ------(TCP) (RTMFP)
Flash Proprietary Server ------(TCP) (RTMPT) HTTP Application - - - - - TCP Server (TCP)
ICE+DTLS- HTTP HTTP SRTP MCU - - - - (TCP) (TCP) (UDP)
Genesys Video Deployment Guide 10 Overview
Media Paths
The following diagrams show the media path for various WebRTC and Flash cases. The platform first tries to connect using WebRTC; if unsuccessful then falls back to RTMFP; if still unsuccessful then falls back to RTMPT/S.
Media Path – WebRTC
Genesys Video Deployment Guide 11 Overview
Media Path – Flash RTMFP
Media Path – Flash RTMPT/RTMPS
Genesys Video Deployment Guide 12 Installing and Deploying Genesys Video Gateway
Installing and Deploying Genesys Video Gateway
Genesys Video Gateway runs on Red Hat Enterprise Linux 6.x and CentOS 6.x 64-bit. This deployment guide assume that all of the components (except the TURN Server) will be installed on the same server or image. If you want to set up an MCU or a farm of MCUs on different servers to where the Application Server has been installed, see External MCU Configuration.
Genesys Video Gateway offers the following core Installation Packages (IPs):
• Collaboration Common (This is no separate component, and performs some pre-requisites including installation of third-party software.)
• Collaboration Notification Server • Collaboration Application Server • Collaboration MCU • Collaboration TURN Server (You can use this TURN server, which is provided by Genesys, or you can use your own TURN server.)
NOTE: As part of the installation:
• New folders are created under “/” – described later as part of base preparation
• The main installation folder is created and populated - /opt/zenon
• Also, /home/saypage and /home/zenon_maint folders get created
Installing Genesys Video Gateway is a process that consists of the following tasks:
1. Setting up your environment with the recommended hardware. 2. Preparing the server. 3. Installing default configurations. 4. Configuring and customizing the platform. 5. Configuring your TURN server, or installing and configuring the Genesys TURN server.
Genesys Video Deployment Guide 13 Installing and Deploying Genesys Video Gateway
Environment
The following list is only a recommended configuration. In practice (especially for Lab/POC), you can use a lower configuration:
• CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz or greater • In Lab/POC: • 4-8 CPUs and 4-8GB RAM is recommended • Disk space allocation minimum 70GB
• In production: • 8-16 CPUs and 8-16GB RAM is recommended • Disk space allocation minimum 110GB
Important We recommend that you have a stand-alone deployment of Genesys Video Gateway (GVG) components. If GVG is deployed with other Genesys components, there can be several configuration and performance issues.
Check System Performance
Sysbench is a common benchmarking utility that you can use to test your server performance. Since it is one of the most common benchmarking utilities, you can easily find and compare performance results online.
Installing Sysbench
You can install Sysbench via yum. To install Sysbench 0.4.12 on Redhat/CentOS 6.x, you can wget the latest remi and epel repositories, install them, and then install Sysbench. wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm wget http://rpms.famillecollet.com/enterprise/remi-release-6.rpm rpm -Uvh remi-release-6*.rpm epel-release-6*.rpm yum install sysbench
Sysbench CPU Test
To run a single-threaded CPU test, run the following command. Typically with a value of 20000, a single-threaded test can take anywhere from 20 seconds to a minute or more. The shorter the time, the better the result, so faster CPUs will take less time to run the test.
Genesys Video Deployment Guide 14 Installing and Deploying Genesys Video Gateway
sysbench --test=cpu --cpu-max-prime=20000 --num-threads=1 run
Important For the Genesys Video Gateway deployment, we recommend that the total amount of time for the single-threaded CPU test be within one minute.
You can use the script below to run multi-threaded Sysbench CPU tests. Multi-threaded CPUs will not show their true performance unless you run the test with the correct amount of threads. If you have an 8-core CPU, you must run an 8-thread CPU test to get the true performance number. for each in 1 2 4 8; do sysbench --test=cpu --cpu-max-prime=20000 --num-threads=$each run; done
Sysbench Memory Test
To test the RAM performance, run the following memory operations speed test. sysbench --test=memory --memory-block-size=1M --memory-total-size=100G run
Important For the Genesys Video Gateway deployment, we recommend that the performance result be 4000 ops/sec and higher.
Sysbench Disk IO Test
To prepare test files, run the following command. Typically, prepare a test file with a size that is about two times more than the amount of RAM the server has. For example, if the server has 4GB RAM, use a 8GB file size. sysbench --test=fileio --file-total-size=8G prepare
Then, follow by a basic Sysbench random read/write test: sysbench --test=fileio --file-total-size=8G --file-test-mode=rndrw --init-rng=on --max-time=180 --max-requests=0 run
Finally, do cleanup: sysbench --test=fileio --file-total-size=8G cleanup
Important For the Genesys Video Gateway deployment, we recommend that the performance result be 1000 iops/sec and above.
Genesys Video Deployment Guide 15 Installing and Deploying Genesys Video Gateway
Next Steps
Check your interoperability considerations.
Genesys Video Deployment Guide 16 Installing and Deploying Genesys Video Gateway
Interoperability Considerations
The Genesys Video Gateway can be used with several types of components, including Genesys servers and many of the leading industry-standard web browsers. This topic provides information on the supported components.
Interoperable Components
• Google Chrome (desktop) • Mozilla Firefox (desktop) • Internet Explorer (desktop) • Apple Safari (desktop) • Opera (desktop) • Genesys SIP Server • Genesys Universal Routing Server (URS) • Genesys Voice Platform (GVP) Media Control Platform (MCP) • Genesys Interaction Workspace (IWS) SIP End Point • Third-party SIP soft-phones (Bria)
Tested Genesys Product Versions
The following table indicates which versions of the listed Genesys components are supported for use with Genesys Video Gateway.
Component 8.0 8.1 8.5 SIP Server — Yes N/A Workspace Desktop — — Yes Edition Workspace SIP Endpoint — — Yes GVP — — Yes URS — Yes N/A
Genesys Video Deployment Guide 17 Installing and Deploying Genesys Video Gateway
Tested Endpoints
Web Endpoint Version Chrome 42 and above Firefox 31 ESR Opera 29 and above IE 11.x Safari 8.x
SIP Endpoint Version CounterPath Bria 4.1 Genesys SIP Endpoint SDK 8.5.1 Workspace SIP Endpoint 8.5.1
SIP Server Configuration
In the TServer section of your SIP Server application • sip-hold-rfc3264—Enable SIP Hold per RFC 3264. object: Must be set to true.
• dual-dialog-enabled—Disable Dual Dialog Mode. Must be set to false. In the TServer section of your SIP Switch Extension DN • refer-enabled—Disable REFER support. Must be set objects (Agent): to false. • sip-cti-control—Must have an empty value only.
Create a TRUNK DN for MCU in your SIP Switch. In the • contact—Must be set to sip:
SIP Endpoint Configuration
Component Specific/Preferred Configuration
• Enable H264 • Enable VP8 CounterPath Bria • Enable G.711 • Disable Opus
Genesys Video Deployment Guide 18 Installing and Deploying Genesys Video Gateway
Component Specific/Preferred Configuration
• Enable H264 • Enable VP8 • Enable G.711 Workspace SIP EP • Disable Opus • Also make sure, in the interaction-workspace section, to set sipendpoint.policy.session.auto_accept_video = 1
Next Steps
Prepare the server.
Genesys Video Deployment Guide 19 Installing and Deploying Genesys Video Gateway
Base Preparation
Important You must have root access to complete the base preparation steps.
Using Repositories for Third-Party Libraries and Software
Third-party libraries and other software are bundled with the Common IP and are installed as part of the Common IP installation. Similarly, the TURN server IP contains a small number of third-party libraries which are installed as part of the TURN server IP installation.
However, depending in which base VM you use, you may still have dependencies for the above libraries that are not packaged along with the Genesys Video Gateway IPs.
Important If you are using a 64-bit OS, the /etc/yum.conf file must include multilib_policy=all.
Before installing the required libraries, you may need to add the following repositories:
• atrpms • epel • rpmforge
Note that if your organization's internal policy is to use another RHEL repository, that should be fine, too.
To get atrmps, run the following: wget -P /etc/pki/rpm-gpg/ https://raw.githubusercontent.com/example42/puppet-yum/master/files/ CentOS.6/rpm-gpg/RPM-GPG-KEY.atrpms rpm –import /etc/pki/rpm-gpg/RPM-GPG-KEY.atrpms
Then type: vi /etc/yum.repos.d/atrpms.repo
Now add these lines and save the file (note that you might need to correct the baseurl entry if you installed Common IP in an alternate location):
[atrpms] name=Fedora Core $releasever - $basearch - ATrpms
Genesys Video Deployment Guide 20 Installing and Deploying Genesys Video Gateway
baseurl=file:///usr/IPs/GVGCommon/rpms gpgkey=file:///etc/pki/rpm-gpg//RPM-GPG-KEY.atrpms enabled=1 gpgcheck=1
To get epel, type: wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
Then type: sudo rpm -Uvh epel-release-6*.rpm
To get rpmforge type: wget https://repository.it4i.cz/mirrors/repoforge/redhat/el6/en/x86_64/rpmforge/RPMS/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm
And then type: rpm –Uvh rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm
Followed by: wget https://repository.it4i.cz/mirrors/repoforge/RPM-GPG-KEY.dag.txt
And finally: rpm --import RPM-GPG-KEY.dag.txt
Step 1: Create Maintenance User
Create a maintenance user called zenon_maint to analyze logs and start processes, if required.
1. Create a group called zenon_maint_group that the user will belong to by running the following command (can be run from anywhere):
sudo groupadd zenon_maint_group
2. Create the user:
sudo useradd -c "maint user" -d/home/zenon_maint -g zenon_maint_group -s /bin/bash zenon_maint
3. Create a password for the user by typing:
sudo passwd zenon_maint
4. When prompted, type the password again. 5. Then type:
cd /etc
6. To open a vi session, type:
visudo
Genesys Video Deployment Guide 21 Installing and Deploying Genesys Video Gateway
7. Add the following lines to the end of the file, replacing hostname with the FQDN of the server:
zenon_maint hostname=/home/zenon_maint/zenon_install_pre_release zenon_maint hostname=/home/zenon_maint/zenon_install_release zenon_maint hostname=/bin/vi /opt/zenon/share/config/zenon/zenon_2100.cfg zenon_maint hostname=/bin/vi /opt/zenon/share/config/saypage/saypage_2130.cfg zenon_maint hostname=/bin/vi /opt/zenon/public_html/WEB-INF/infotypes_zenon.xml zenon_maint hostname=/bin/vi /opt/zenon/zenonserver/zs.properties zenon_maint hostname=/etc/init.d/restart zenon_maint hostname=/etc/init.d/restop zenon_maint hostname=/etc/init.d/snmp_start zenon_maint hostname=/etc/init.d/snmp_stop zenon_maint hostname=/opt/zenon/configure_and_run_snmp.sh zenon_maint hostname=/opt/zenon/sh/configure_HA.sh zenon_maint hostname=/opt/zenon/sh/reset_zenon.sh zenon_maint hostname=/opt/zenon/sh/reset_maxmcu.sh zenon_maint hostname=/opt/zenon/sh/kill_zenon.sh zenon_maint hostname=/opt/zenon/sh/monitor_zenon.sh zenon_maint hostname=/opt/zenon/sh/repair_all_databases.sh zenon_maint hostname=/opt/zenon/sh/dump_configs.sh zenon_maint hostname=/etc/init.d/mysqld zenon_maint hostname=/usr/bin/sg zenon_maint hostname=/usr/sbin/crm_mon
Step 2: Install Third-Party Libraries and Software
The Collaboration Common IP contains all of the third-party libraries and software. Run the scripts/install.sh script file (provided with this IP) from root access account to install the third-party items. Also, this script invokes some pre-install sub-scripts. If you are planning to install Application Server in this box, use the argument AS. For MCU-only installation, use the argument MCU.
1. Run the scripts/install.sh script file (provided with this IP) to install the third-party items: For example, run:
cd scripts sudo chmod +x *.sh sudo install.sh AS (or MCU)
Note: This can take several minutes to execute based on your system.
2. The pre-install script also creates the following folders and sets the necessary permissions for them:
/storage_1 /zenon_releases /zenon_backups /saypage_provision /opt/zenon /home/saypage/site
Notes:
• MySQL server (5.1.7) and JDK7 are installed as part of Common installation.
• If the autofs service is running on your system, stop and disable autofs. • The Common IP has an extras folder that contains RPMs for some utilities, like sysbench, netcat, nmap, crontab, etc.
Genesys Video Deployment Guide 22 Installing and Deploying Genesys Video Gateway
Step 3: (Optional) Edit the /etc/hosts File
Tip You can skip this step if your network's DNS is separately maintained and there is no need to look up the host table.
1. Check the entries in the /etc/hosts file. The localhost entry should appear after the localhost.localdomain entry, as shown in the following example (it may appear the other way around when you first open the file). Example:
127.0.0.1 localhost.localdomain localhost
2. If any other numeric values appear for localhost/localdomain, they can remain, but make sure they are listed in the correct order as stated above.
3. If you see an entry that starts with ::1, you must comment out this entry with a hashtag at the start of the line. 4. Add a line that references the IP address of your server or image, your chosen fully qualified domain name (FQDN) and hostname: Example:
X.X.X.X yourdomain.com yourhostname
Important Make sure that yourdomain.com resolves to the IP address above.
Step 4: (Optional) Edit the /etc/resolv.conf File
Tip You can skip this step if your network's DNS is separately maintained and there is no need to consult this configuration file for DNS resolution.
1. The resolver configuration file contains information that is read by the resolver routines the first time they are invoked by a process. Entries should exist within this file of the approximate form below, however editing this file might not be desirable, according the policies of your company. For the purposes of this installation, the following should be present:
nameserver X.X.X.X search localhost
Where nameserver is the IP address (in dot notation) of the name server that the resolver queries in order to map domains to IP addresses. You may need to insert localhost before another domain that might be present on the line starting with the word search.
Example:
Genesys Video Deployment Guide 23 Installing and Deploying Genesys Video Gateway
search localhost above.net
Step 5: Configure MySQL
Note: MySQL configuration is not needed for an MCU only setup.
1. Start MySQL (assuming that MySQL is installed in Step 2) by typing:
sudo service mysqld start
2. Log into MySQL by typing mysql at the console prompt (the root password is blank by default). Once logged in, type the following:
create database mzs; use mysql; select * from user; delete from user where host='
Note: It's possible that the server or image uses entries such as yourdomain or localhost.localdomain rather than the yourhostname that you might have referred to in Step 2, in which case you will need to delete entries in the user table where host="this name". The only entries that should remain are where host="localhost" or host="127.0.0.1".
3. Now run:
set password for 'root'@'localhost'=OLD_PASSWORD('
Where
Note: The password must be all lower case text, with a minimum length of 8 characters. No numeric or special characters are allowed.
4. Exit MySQL by typing exit and run the following command to ensure mysqld startup on reboot:
sudo chkconfig mysqld on
The next time you want to log into MySQL use: mysql -A -u mzs -p
Note: When the platform starts for the first time it will update and encrypt the MySQL password stored in /opt/zenon/sys/ supervisor_system.txt.
5. (Optional) To change the password for the mzs user, change it first in MySQL, set it in /opt/zenon/sys/ supervisor_system.txt for mysql_mzs, and then restart the platform.
Step 6: Set Selinux Mode for Installation
1. Set the following in /etc/sysconfig/selinux:
SELINUX=permissive
Genesys Video Deployment Guide 24 Installing and Deploying Genesys Video Gateway
2. Reboot the server by running:
sudo reboot
3. After the server has rebooted, log in and verify the Selinux mode using the command:
sudo getenforce
4. After the installation is done, you can set SELINUX to enforcing in /etc/sysconfig/selinux, and then reboot the server.
Next Steps
Install default configurations.
Genesys Video Deployment Guide 25 Installing and Deploying Genesys Video Gateway
Core Component Installation
After the server has been prepared, continue with installing the Genesys Video Gateway components.
Important You must install the platform with zenon_maint user. However, you need root/super-user access for the post-installation scripts (as specified below).
Step 1: Install Collaboration Notification Server
1. Get the Collaboration Notification Server IP.
2. Run the install.sh file. The Genesys Installation starts (sudo access is not required to install the IP). 3. When prompted, enter the following details to complete the installation: a. Your public domain name or the hostname of the machine if no public domain name is available. b. The destination folder, which is the temporary folder where the installation files will be unzipped. Make sure that the user performing the installation has write access to this temporary folder.
4. If the installation is successful, the console displays the following message: Installation of Collaboration Notification Server, version 9.0.00x.yy has completed successfully. Note: The installer output is written to the zs_install.log file, located in the same folder from where the installer is run. If you encounter any installation issues, be sure to check this log file.
5. When the installation is complete, go to the temporary folder that is entered and run the post_install_zs.sh script (requires sudo access), with the following argument:
sudo post_install_zs.sh
Step 2: Install Collaboration Application Server
1. Get the Collaboration Application Server IP.
2. Run the install.sh file. The Genesys Installation starts (sudo access is not required to install the IP). 3. When prompted, enter the following details to complete the installation: a. The private/internal IP of the box. b. Your public domain name or the hostname of the machine if no public domain name is available. c. The destination folder, which is the temporary folder where the installation files will be unzipped. Make sure that the user performing the installation has write access to this temporary folder.
Genesys Video Deployment Guide 26 Installing and Deploying Genesys Video Gateway
4. If the installation is successful, the console displays the following message: Installation of Collaboration Application Server, version 9.0.00x.yy has completed successfully. Note: The installer output is written to the zas_install.log file, located in the same folder from where the installer is run. If you encounter any installation issues, be sure to check this log file.
5. When the installation is complete, go to the folder where zas_install.log is run from and run the post_install_zas.sh script (requires super-user access), with the following argument:
sudo post_install_zas.sh [MySQL Password]
Step 3: Install Collaboration MCU
1. Get the Collaboration MCU IP.
2. Run the install.sh file. The Genesys Installation starts (sudo access is not required to install the IP). 3. When prompted, enter the following details to complete the installation: a. The destination folder, which is the temporary folder where the installation files will be unzipped. Make sure that the user performing the installation has write access to this temporary folder.
4. If the installation is successful, the console displays the following message: Installation of Collaboration MCU, version 9.0.00x.yy has completed successfully. Note: The installer output is written to the install.log file, located in the same folder from where the installer is run. If you encounter any installation issues, be sure to check this log file.
Step 4: Platform Start-up
1. Start the Genesys Video Gateway by running the following commands:
/etc/init.d/zenon_zs /etc/init.d/snmp_start
Important The user may be asked to enter the zenon_maint user password if the scripts are run from that account.
2. Check if the NS has started:
ps -elf | grep zs.prop 0 S 501 31460 30524 1 80 0 - 891051 futex_ Sep14 ? 00:45:17 /usr/share/jdk1.7.0_07/bin/java -Xbootclasspath/p:/opt/zenon/zenonserver/lib/npn-boot-1.1.1.v20121030.jar -Dfile.encoding=UTF-8 -Xms256M -Xmx1024M -XX:+UseParallelGC -XX:-UseGCOverheadLimit com.blackboard.zs.Main zs.properties log4j.properties
3. Check if the two MCU related processes are running:
ps -ef | grep maxmcu 0 S 501 30597 1 0 80 0 - 253344 futex_ Sep14 ? 00:01:14 /opt/zenon/bin/maxmcu -c -x /opt/zenon/share/config/zenon/zenon_2100.cfg 0 S 501 30628 1 0 80 0 - 550644 futex_ Sep14 ? 00:03:05 /opt/zenon/bin/maxmcu -c -x /opt/zenon/share/config/saypage/saypage_2130.cfg
4. To re-start the components, run:
Genesys Video Deployment Guide 27 Installing and Deploying Genesys Video Gateway
/opt/zenon/sh/stop_genesys_video.sh
Followed by:
/etc/init.d/zenon_zs
5. After the installation is done, you can set SELINUX to enforcing in /etc/sysconfig/selinux, and then reboot the server.
Step 5: Validate the Platform
After all of the components have been configured, you can check if the system is functioning by running some simple tests from a browser.
1. Type http://yourdomain.com/ to return the start page in a browser. 2. To test WebRTC operation, a loopback tester is at the following URL, which echos back audio and video in a WebRTC-capable browser.
http://yourdomain.com/user/demo/w.jsp
3. To test Flash operation, use the following URL from a browser other than Chrome. Click voice/video call and it should echo back audio/video.
http://yourdomain.com/user/demo/index.jsp
4. On the server itself, you can verify the MCU operation by using the following command. This command returns valid HTML for the MCU status page.
wget http://localhost:2131
5. On the server itself, you can verify the NS operation by using the following command. This command returns false if the platform is up and running. Note that wget is pre-installed as part of Common.
wget http://127.0.0.1:14040/?command=ZSSICK
Note: The Genesys Video meeting room feature is disabled by default, and by going to https://yourdomain.com, the following message displays:
Genesys Video Gateway
The feature you requested is currently not available.
Next Steps
Configure and customize the platform.
Genesys Video Deployment Guide 28 Installing and Deploying Genesys Video Gateway
Platform Configuration
After you have finished installing the core components, you must implement some changes in the settings.
Configure TURN in Collaboration Application Server Settings
1. In the Collaboration Application Server, edit the following file: /opt/zenon/public_html/WEB-INF/infotypes_saypage.xml
2. Add the following to the
In the above example, we assume two TURN servers are being used and each running both TCP and UDP listeners.
Update SSL Keystore for New Certificate
There are lots of different ways to set up SSL on a server; you may need to consult your network specialist on this step. The steps below are particular to .crt and .cer file extensions.
The file heller.keystore is installed (under /opt/zenon/zenonserver) with a default SSL key. In order to change it to a new domain certificate, follow these steps.
The keystore file can contain only one valid certificate at a time, so you must replace it with the new key. It's assumed that you have a .crt certificate from an authority like Verisign or GoDaddy.
Steps:
• cat www.yourdomain.crt gd_bundle.crt > yourdomain-chain.txt • Now create a pkcs12 type key using: openssl pkcs12 -export -inkey yourdomain.key -in yourdomain-chain.txt -out yourdomain.pkcs12
• Then we use java keytool to import the new key into the heller.keystore file making sure we replace the existing key as follows:
/usr/share/jdk1.7.0_07/bin/keytool -importkeystore -srckeystore yourdomain.pkcs12 -srcstoretype PKCS12 -destkeystore /opt/zenon/zenonserver/heller.keystore
• If you are prompted for a password, use changeit in all instances.
Notes:
Genesys Video Deployment Guide 29 Installing and Deploying Genesys Video Gateway
• The full certificate chain must be installed into the keystore when we cat to create yourdomain.txt. • You can test the newly installed certificate using https://www.geocerts.com/ssl_checker which will show you the full chain and also print out the certificates that are missing in the chain.
If a .cer file is used (usually in der format), it can be converted to pem format, and then used to create a pkcs12 certificate as below: openssl x509 -in rb.der -inform der -outform pem -out yourdomain.pem openssl pkcs12 -export -inkey rb.key -in rb.pem -out yourdomain.pkcs12
Configure Cross Origin Resource Sharing (CORS) in the AS
• For a GVG platform that has the client application installed on the same machine as the platform, the cross-origin filter in /opt/zenon/public_html/WEB-INF/default_pub.xml should have an empty value for the allowedOrigins parameter, instead of the current default value of '*'. This way, a request from any other origin will be failed by the browser with a CORS error.
• When the application/SDK is installed on separate Web Server(s), the allowedOrigins parameter should contain the HTTP Origin URLs of the systems hosting the application/SDK, delimited by a comma. Example value: https://appsvr.foo.com,https://sdksvr.foo.com
Configure Filter Against Cross-Site Scripting (XSS) in the AS
• Add the following filter in /opt/zenon/public_html/WEB-INF/default_pub.xml, just before the cross-origin filter:
Notes:
• This XSS filter is applied to query strings/request parameters, request headers, and cookies.
• When this filter catches an XSS issue, instead of a 4XX response, it will return 200 OK with an error message that says FAIL Insecure Request.
• The file /opt/zenon/sys/content_filter.properties contains some relevant parameters and actions that can be changed. Many of the elements that are considered a security threat are already configured in this file.
• Make sure the configuration
• /opt/zenon/public_html/WEB-INF/infotypes_saypage.xml
Genesys Video Deployment Guide 30 Installing and Deploying Genesys Video Gateway
• /opt/zenon/public_html/WEB-INF/infotypes_zenon.xml
Configure External MCU
Genesys Video Gateway supports deploying the AS and the Collaboration MCU(s) on different machines for scalability. To do this:
1. On the machine where the AS will be running, install the Common, NS, and the AS package. 2. On the machine where the Collaboration MCU will be running, install the Common, NS and the Collaboration MCU package. 3. Install the certificate on each of the server(s), like this:
/usr/share/jdk1.7.0_07/bin/keytool -importkeystore -srckeystore 1A_
where 1A_
Enter changeit when prompted.
4. On the Collaboration MCU host, update the /opt/zenon/zenonserver/zs.properties file with the following:
a. Make sure the line with cls.jetty.xml is commented, like this: #cls.jetty.xml=jetty-zenon.xml
b. Make sure the line with cls.root.dir is commented, like this: #cls.root.dir=/opt/zenon/public_html
c. Change login url with the public domain name (or hostname) of the application server host:
#login url login.url.1=http://
where
d. Make sure the line with mcu.url is uncommented, like this:
#To have ZS report CPU and MCU status to remoteCLS uncomment and set correctly mcu.url=localhost:2131
5. Update /opt/zenon/share/config/saypage/saypage_2130.cfg, and change CentralLoginServer with the FQDN of the AS host:
CentralLoginServer=http://
6. Update /opt/zenon/share/config/zenon/zenon_2100.cfg, and change CentralLoginServer with the FQDN of the AS host:
CentralLoginServer=http://
7. On the AS server:
a. Add the rows that point to the new Collaboration MCU host(s) in the MySQL database’s vidi_service table, and delete existing rows that contain localhost or 127.0.0.1 entries, which would look like the following (replace IP 135.17.37.94 with the IP address of the Collaboration MCU host):
mysql> select * from vidi_service; +------+------+------+------+------+ | name | version | endpoint | openfire | priority |
Genesys Video Deployment Guide 31 Installing and Deploying Genesys Video Gateway
+------+------+------+------+------+ | saypage | | 135.17.37.94:2130 | | 0 | | zenon | | 135.17.37.94:2100 | | 0 | +------+------+------+------+------+ 4 rows in set (0.00 sec)
Note: If you get an error message that looks like this:
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '* from vidi_service' at line 1
You can workaround this by first issuing SET SQL_SAFE_UPDATES=0; from the MySQL prompt.
• Issue SET SQL_SAFE_UPDATES=0;
• Issue delete from vidi_service;
• Issue INSERT INTO vidi_service (name, endpoint, priority) VALUES ('zenon', '135.17.37.94:2100', 0);
• Issue INSERT INTO vidi_service (name, endpoint, priority) VALUES ('saypage', '135.17.37.94:2130', 0);
b. Update /opt/zenon/public_html/WEB-INF/infotypes_saypage.xml to include the new Collaboration MCU host’s IP, like this:
(Where 135.17.37.94 is the public IP address of the Collaboration MCU host.) Remove the existing
c. Also update /opt/zenon/public_html/WEB-INF/infotypes_saypage.xml to make sure the DoLastCpuUpdateCheck is set to true, like this:
8. Restart the components by running the following commands:
a. /opt/zenon/sh/monitor_zenon.sh &> /dev/null
b. ps -elf | grep -i zs.prop
c. kill the process from the above
d. /opt/zenon/sh/reset_zenon_2100.sh &> /opt/zenon/logs/mcu_zenon.log
e. /opt/zenon/sh/reset_saypage_2130.sh &> /opt/zenon/logs/mcu_saypage.log
Next Steps
• If you are using your own TURN server, you must perform a few configuration tasks. • If you are using the Genesys Collaboration TURN server, you must install and configure it.
Genesys Video Deployment Guide 32 Installing and Deploying Genesys Video Gateway
TURN Server Installation and Configuration
Configure your Existing TURN Server (Non-Genesys)
If you already have a TURN server deployed in your network and prefer to use it instead of the Genesys Collaboration TURN Server, then do the following:
• For the Application Server setting for TURN server, check Configure TURN in Collaboration Application Server Settings.
• In the TURN server settings, add a new user mcu with password. The same password as configured in TURN Configuration in Application Server Settings should also be set here.
Install and Configure Genesys Collaboration TURN Server
Host Requirement
• RHEL/CentOS 6.x. • At least two vCPUs, 4GB Memory. SSD may be used, but is not mandatory. • The most important factor is the networking performance. Make sure that your network has: • High packet per second (PPS) performance • Low network jitter (<= 30ms) • Low latencies (<= 150ms)
For example, if you are deploying the TURN server in an AWS instance, then Enhanced Networking is only available on instances launched with HVM AMIs. Preferably, use C3/C4/R3 instances. For details on AWS EC2 instance types, check here.
Port Requirement
TURN server port requirements are described in the Port Usage section.
The Collaboration TURN Server IP for TURN server is available with this release and must be installed on a separate server. If you want to install the TURN server in the same machine as the Application Server, make sure there is no port conflict.
You must have root access to install the TURN server. To configure the server:
1. If you are using a 64-bit OS, the /etc/yum.conf file must include multilib_policy=all.
2. Ensure Selinux is disabled by editing the /etc/sysconfig/selinux file, and make sure that this line is set to disabled:
Genesys Video Deployment Guide 33 Installing and Deploying Genesys Video Gateway
SELINUX=disabled
3. Turn off the firewall by running:
sudo chkconfig iptables off
Note: The firewall can be turned on again and configured as per your requirements at a later date.
4. Reboot the server by running:
sudo reboot
5. After the server has rebooted, log in and verify Selinux is disabled using the command:
sudo getenforce
This returns Disabled.
6. Create the directory /opt/zenon by running:
sudo mkdir -p /opt/zenon
7. Place the files from your Collaboration TURN Server IP to /opt/zenon.
8. After unpacking, you will see the directories: sh, trn, trnssl, extras and files: root_cron and zenon_zs. 9. Make sure that the .sh and some other files have execute permission:
cd /opt/zenon sudo chmod -R +x *.sh sudo chmod +x zenon_zs sudo chmod +x trn/bin/turnserver sudo chmod +x trnssl/bin/turnserver
10. Run the extras/install.sh file to install the pre-requisite libraries:
cd extras sudo install.sh
11. Copy the contents of root_cron. Then run:
sudo crontab -e
12. Paste the contents of root_cron and save.
13. The zenon_zs file is the startup script used by the server to start the TURN services after reboot. Copy this file to the folder /etc/init.d, and then make the file executable.
14. Create a link to it in /etc/rc3.d as follows:
cd /etc/rc3.d sudo ln -s /etc/init.d/zenon_zs S99zenonzsstart
Note: This presumes that the runlevel of the server is 3. Typing sudo runlevel at the command line will confirm this. If 5 is returned, create the link in /etc/rc5.d
15. To configure the TURN services for UDP on port 14049:
cd /opt/zenon/trn sudo ./configure_trn.sh yourdomain.com X.X.X.X
Where X.X.X.X is the IP of the TURN server interface it will be listening on (typically eth0).
Genesys Video Deployment Guide 34 Installing and Deploying Genesys Video Gateway
16. To configure the TURN service for SSL on port 443:
cd /opt/zenon/trnssl sudo ./configure_trnssl.sh yourdomain.com X.X.X.X
17. An MCU password is required for the TURN server to communicate with it, and is stored in these files:
• /opt/zenon/trn/bin/turnuserdb.conf
• /opt/zenon/trnssl/bin/turnuserdb.conf
18. The line starting with mcu: must be noted (or edited in both files if a change is required). The same password as configured in TURN Configuration in Application Server Settings should also be set here. Note: We are currently using the long-term credentials approach for TURN server authentication. With this approach, the client-side JavaScript has access to the TURN server credentials. There is a short-lived credentials approach using TURN REST API to provide more security; currently, this is not implemented in GVG.
19. Finally, reboot the server by typing sudo reboot, and TURN services should be running when the server is brought back up. This can be confirmed using the command sudo ps -elf | grep trn that returns output like this (example output):
root 25313 0.0 0.0 106480 1676 ? S Jul04 107:29 /bin/sh /opt/zenon/sh/trnserver.sh root 25351 0.0 0.0 163860 16052 ? Ssl Jul04 32:32 /opt/zenon/trnssl/bin/turnserver -v -o -X 72.28.111.195 -a -b /opt/zenon/trnssl/bin/turnuserdb.conf -f -r mac1.saypage.com root 26443 0.3 0.0 304676 9264 ? Ssl Jul04 579:24 /opt/zenon/trn/bin/turnserver -v -o -X 72.28.111.195 --no-tls -a -b /opt/zenon/trn/bin/turnuserdb.conf -f -r mac1.saypage.com
Configure TURN Behind-NAT Settings
Note: You only need to perform this step if your TURN server is behind NAT.
1. When the TURN server is behind NAT, you must modify the following files:
• /opt/zenon/trn/bin/run.sh
• /opt/zenon/trnssl/bin/run.sh
2. Before modification, the first run.sh file will look like this:
/opt/zenon/trn/bin/turnserver -v -o -X
3. After NAT modification, the file looks like this:
/opt/zenon/trn/bin/turnserver -o -X
4. Before modification, the second run.sh file for TURN via SSL looks like this:
/opt/zenon/trnssl/bin/turnserver -v -o -X
5. After NAT modification, the file looks like this:
/opt/zenon/trnssl/bin/turnserver -v -o -X
Verifying your TURN Server
To verify whether your TURN server is running properly and is accessible, go to the following demo page: http://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
Genesys Video Deployment Guide 35 Installing and Deploying Genesys Video Gateway
This page tests the trickle ICE functionality in a WebRTC implementation. It creates a PeerConnection with the specified STUN/TURN servers, and then starts candidate gathering for a session with a single audio stream. As candidates are gathered, they are displayed in a text box, along with an indication when candidate gathering is complete.
Select and remove the default STUN server that is populated in this page, and then add your TURN server(s) instead. For example, if you have installed the Genesys TURN server in turn.example.net and set password as genesys for mcu user, add both:
• turn:turn.example.net:14049 (and user/password as mcu/genesys)
• turn:turn.example.net:443?transport=tcp (and user/password as mcu/genesys)
Then press Gather candidates and specifically check for relay candidates in the result (see example below). If no relay candidates are generated, either your TURN server is not running properly or is not accessible from your network.
Also, the type of candidates released to the application can be controlled via the IceTransports constraint.
Genesys Video Deployment Guide 36 Deployment Models
Deployment Models
Before deploying the Genesys Collaboration Manager to production, you should install it in a lab environment, and then create and test with sample applications in that environment.
Once you have successfully created and tested your application, see the following topics for an in-depth discussion of how Genesys Video Gateway can be deployed in a production environment.
• Network Address Traversal • Firewalls and Restrictive NAT • Deployment Types • Security Considerations • Scalability • Availability • Failover
Genesys Video Deployment Guide 37 Deployment Models
Network Address Traversal
When a device, such as a computer, is working behind a home router, it acquires an IP address from that router. In order to serve multiple devices at home, the router assigns its own IP address in a private subnet but allows all devices behind the router to reach out to the Internet. In a typical case, the home computer gets an internal address, such as 192.168.1.101. A browser accessing normal web pages will use TCP to connect from the browser client to a server, so home routers work very well in these scenarios.
With WebRTC, however, the browser needs to send a media stream directly to another browser over UDP, as shown in the following diagram:
Since the browsers on both devices will only see the IP addresses acquired from the home routers, they will not be able to connect directly to one another, since these addresses are private. The Interactive Connectivity Establishment (ICE) protocol (RFC5245) was designed to resolve this problem, which does not normally exist in a traditional VoIP environment, since all of the device endpoints are deployed within the office network and hence no address translation is required.
The following is a simplified view of how ICE deals with NAT:
Genesys Video Deployment Guide 38 Deployment Models
ICE uses the Session Traversal Utilities for NAT (STUN) protocol as a way to discover the server-reflexive address seen by a public server. Once a browser discovers all the addresses seen by public servers, it can use ICE to negotiate the connection with the peer. ICE parameters can be carried in SDP or in some other external signaling mechanism, and JSEP allows ICE negotiation independent of SDP negotiation.
Genesys Video Deployment Guide 39 Deployment Models
Firewalls and Restrictive NAT
In addition to dealing with NAT (Network Address Traversal), enterprise firewalls often implement restrictive access control as a means of protecting the enterprise network. A typical enterprise firewall might block all unknown ports from both inbound and outbound traffic. This means only a handful of known commonly used protocols, such as HTTP/HTTPS, ftp, and ssh, will be allowed to access the enterprise network.
Also, some routers may have a restrictive NAT translation policy that enforces address- and port-dependent mapping. This means the NAT binding can only be enabled for a specific address and port. When both endpoints are behind the same type of NAT, then both sides will be unable to find the actual binding outside of NAT.
In order to work with firewalls or restrictive NAT, ICE requires an additional intermediary called a Traversal Using Relays around NAT server (TURN server). This server, which is deployed on a public address, can relay media packets for a TURN client so that they are ultimately able to reach another endpoint. The browser that wants to send and receive media is considered as a TURN client and connects to the TURN server to acquire a relay address. Using this address the browser client can use this as a candidate in ICE negotiation during SDP offer/ answer negotiation.
The following diagram shows an example where the browser client on the left is a TURN client and the TURN client is behind a restrictive firewall that blocks UDP traffic but allows a connection to the TURN server. The web application that offers the use of this TURN server would provide the TURN server address and a credential in the web page. The browser uses the TURN server address and the credential to initiate a request for relay ports on its behalf. In the following example, port 34568 is assigned to the TURN client and the browser can create an SDP offer with port 34568 on the TURN server address (a public address) as a candidate.
Genesys Video Deployment Guide 40 Deployment Models
Genesys Video Deployment Guide 41 Deployment Models
Deployment Types
Contact Center Deployment with all-in-one Machine
In a typical Contact Center deployment, Genesys servers are generally deployed behind an Enterprise firewall and are only able to access specific services from the Internet. Genesys Video Gateway is one of the services that need to be accessible from the Internet for HTTP/HTTPS and SRTP. Genesys Video Gateway can then send SIP/RTP toward the Enterprise network and is also able to bridge the media.
In this type of deployment, Genesys Video Gateway must be deployed in the DMZ so that the component can handle inbound signaling and media traffic. In the simplest case, all of the core components of Genesys Video Gateway should be deployed in one machine, and the TURN server deployed in another machine (both in DMZ).
An example below shows:
• AS and MCU (and others) on the same server • 2 different services • 2 servers each running the same software but different configuration on each • Both using the same TURN and other Genesys services
Genesys Video Deployment Guide 42 Deployment Models
Distributed Architecture
In a distributed architecture:
• AS and MCU(s) are on different servers • F5 routing requests to active-standby AS pair • Using the same TURN service • AS, MCU and TURN should still be in DMZ
Genesys Video Deployment Guide 43 Deployment Models
Security Considerations
Secure Transports
For all communications between client and server that must be secure:
• HTTPS is used with SSL certificates from a trusted authority. • For WebRTC, DTLS-SRTP is used. • For Flash, RTMFP or RTMPT/S is used.
Note: Currently TLS and SRTP are not supported by MCU on the SIP-side.
Tools and Services
Fail2ban
To ban IP addresses that repeatedly have failed login attempts, Genesys recommends installing fail2ban. This rpm is shipped with the Common IP package in the extras folder.
You need root access to install this rpm: sudo yum -y --nogpgcheck localinstall python-inotify-0.9.1-1.el6.noarch.rpm sudo yum -y --nogpgcheck localinstall gamin-python-0.1.10-9.el6.x86_64.rpm sudo yum -y --nogpgcheck localinstall fail2ban-0.8.14-1.el6.noarch.rpm
The default install will ban IP addresses after three failed attempts for 600 seconds.
Telnet and FTP
Telnet and FTP services have known security issues. Genesys recommends disabling these services on the Platform.
Xinetd
Run the following command: sudo chkconfig xinetd off
Genesys Video Deployment Guide 44 Deployment Models
Port Usage
For port requirements, see Connection Map.
Genesys Video Deployment Guide 45 Deployment Models
Scalability
Collaboration Application Server
High Availability configuration is required to support an active-standby configuration for the Application Server. In the Availability section, such a configuration with F5 is described.
Collaboration MCU
Genesys Video Gateway is scalable to multiple instances of the MCU. This allows it to support a large number of simultaneous media sessions with the use of the Collaboration Application Server as the load balancer in front of the farm of MCUs.
The detailed capacity figures for MCU will be updated at a later date. A rough guide is provided below for scenarios with trans-coding requirement for each session (assuming a 8-core system):
WebRTC/SIP Transcode Interop
Codec MCU Capacity Opus 120 Video QVGA VP8 30 Video VGA VP8 14
Genesys Video Deployment Guide 46 Deployment Models
Collaboration TURN Server
There are a couple of HA and load balancing options for TURN Server. However, there may be no direct need to configure a TURN server cluster for load-balancing; rather multiple TURN servers can be deployed for scaling purposes. Both the browser client and the MCU are capable of interacting with multiple TURN servers (based on configuration). Realistically, with the TURN server, you can expect hundreds of video or thousands of audio calls per modern CPU (provided you have high-performance NIC, memory bus, etc).
For example, if you have one or more TURN servers, you can set all of them in the configuration, and both browser client and MCU should be able to use them. An example configuration is shown here: Configure TURN in Collaboration Application Server Settings
For more information on TURN server performance and scalability, you can check the following: TURN performance and load balance
Genesys Video Deployment Guide 47 Deployment Models
Availability
HAProxy
When the Application Server (AS) must be highly available, a Load Balancer, such as HAProxy, is required. HAProxy is a free, fast, and reliable solution offering high availability, load balancing, and proxying for TCP and HTTP-based applications. The currently supported versions are:
• version 1.5: the most feature-wise version; supports SSL, IPv6, keep-alive, DDoS protection, etc. • version 1.4: the most stable version for customers that don't need SSL; it still provides client-side keep-alive. • version 1.3: the old stable version for customers that cannot upgrade for internal policy reasons.
For AS HA testing, version 1.5 was used.
Depending on the complexity of the solution, balancing can be accomplished many ways using different techniques. One of the first things to identify is whether to use Layer 4 or Layer 7 balancing. Each is a solution for different needs, and currently both are used. Note: An Enterprise Edition is also available for HAProxy (see the References section).
Maintenance of an HAProxy deployment is the customer’s responsibility; it is up to the customer to consider either a free version or a commercial version of product.
Application Server
• Two Application Servers (AS) are used, each with its own MySQL database. • The databases run master-master replication. • Because of database replication, more than two AS's cannot be used, and only one can be active any one time, while the other AS will be in standby mode. • If configuring multiple AS instances behind a load balancer, you must ensure that the non-host specific configuration entries in the infotypes_saypage.xml file are consistent across the AS nodes. • Also, note that with HA configuration for AS, currently only warm-standby mode can be achieved.
Caveat: If both AS's become active and process requests at the same time, this may cause problems, especially with the database replication. You must ensure that only one AS gets the request at any given time.
MCU
There will be multiple MCUs used in such a system. In this case, all the MCUs will have the HAProxy address configured as the Application Server address (port 80, as internal communication between MCU/NS and AS is HTTP), and therefore will be talking to the active AS always via the proxy. Also, browser clients will use the HAProxy address to connect to the active AS (port 443).
Genesys Video Deployment Guide 48 Deployment Models
HAProxy Installation and Configuration
Install HAProxy
The HAProxy package is available under the default yum repository for CentOS, Redhat systems. Use the following yum package manager command to install HAProxy on your system:
# yum install haproxy
Or, you can build HAProxy from the source. The source code is covered by GPL v2. Source code and pre-compiled binaries for Linux/x86 can be downloaded here.
Configure HAProxy
The HAProxy configuration file /etc/haproxy/haproxy.cfg must be updated for setting up the service:
# vim /etc/haproxy/haproxy.cfg
In brief:
• The HAProxy services ports 80 and 443. • HTTP mode (layer 7) is used for port 80. • TCP mode (layer 4) is used for port 443.
• The configuration ‘option forwardfor’ in HAProxy must be enabled for port 80.
• This is for adding X-Forwarded-For header in requests to AS.
• The configuration ‘option httpchk’ in HAProxy must be enabled for port 80.
• This is for periodically monitoring the AS's with HTTP requests sent to the URL: /servlet/ com.requestec.smg.servlets.Brora?command=get_local_host
• By default, httpchk considers that response statuses 2xx and 3xx are valid, and that other statuses are invalid.
• The default httpchk interval is 2000msec (configurable).
• One of the two AS’s is set up as backup, so that this secondary AS will be used only when the primary is down.
A sample configuration file might look like this: global # 8 log levels: emerg alert crit err warning notice info debug log 127.0.0.1 local1 notice # “Jail Directory” with no write access to anyone. chroot /usr/share/haproxy user haproxy group haproxy daemon maxconn 4096 tune.ssl.default-dh-param 2048 defaults log global mode tcp
Genesys Video Deployment Guide 49 Deployment Models
option tcplog balance roundrobin option logasap retries 3 maxconn 2000 timeout connect 5000 timeout client 50000 timeout server 50000
# [HTTP Site Configuration] listen gvg-as 0.0.0.0:80 # The forwardfor options require mode http. mode http option forwardfor option httpchk GET /servlet/com.requestec.smg.servlets.Brora?command=get_local_host HTTP/1.0 server gvg-as1
# [HTTPS Site Configuration] listen gvg-as-https 0.0.0.0:443 server gvg-as1
For the above configuration, you might need to do the following:
1. Create a Jail directory, and remove write permission to anyone: mkdir –p /usr/share/haproxy chmod a-w /usr/share/haproxy 2. If logging is desired, set it up via syslog (which is the only viable option available), by adding the following in the file /etc/rsyslog.d/49-haproxy.con. (This will work if HAProxy is the only service using the UDP syslog port 514, otherwise, put these in /etc/rsyslog.conf instead).
#..otherwise consider putting these two in /etc/rsyslog.conf instead: $ModLoad imudp $UDPServerAddress 127.0.0.1 $UDPServerRun 514
#..and in any case, put these two in /etc/rsyslog.d/49-haproxy.conf:
local1.* -/var/log/haproxy_1.log & ~ #& ~ means not to put what matched in the above line anywhere else for the rest of the rules #http://serverfault.com/questions/214312/how-to-keep-haproxy-log-messages-out-of-var-log-syslog
Now when rsyslog is restarted (‘service rsyslog restart’), logging should go to /var/log/haproxy_1.log (make sure this file gets rotated and/or cleaned as necessary).
Start HAProxy Service
Start HAProxy service using following command, and configure it to auto-start on system boot:
# service haproxy start
Genesys Video Deployment Guide 50 Deployment Models
# chkconfig haproxy on
Check HAProxy Statistics
The configuration required for the HAProxy Statistics is shown above in the sample configuration file. You should be able to load a browser and connect to the IP of the HAProxy server, on port 80, with the stats URL added to the end:
For example: http://
You will be presented with a username/password prompt. Enter the details saved in the haproxy.cfg file that you previously set.
You will be presented with the statistics page similar to this:
HAProxy Redundancy
Important This is not currently tested.
High availability HAProxy setup is possible with Heartbeat on Linux systems. It requires one floating IP address (which will be used for HAProxy) that will be assigned to one of the computers in the cluster. When the current machine holding the IP address fails, failover server will take the IP address and continue serving requests. This is typically done using Virtual Router Redundancy Protocol (VRRP).
References
• MySQL Replication
Genesys Video Deployment Guide 51 Deployment Models
• MySQL Replication FAQ • HAProxy Configuration Manual • HAProxy Enterprise Edition • HAProxy Performance • HAProxy Redundancy
MySQL Replication
The MySQL databases on the Active and Passive AS servers can be configured to replicate data between them. This is called a Master/Slave configuration, which can cause problems if the Master is lost. The Slave database will be up-to-date, but once the original Active server is running and ready to act as a failover (Passive) in the cluster, no synchronization of the database will occur. To overcome this problem, the databases should be configured to act as Master/Master, each having a Slave process to the other:
• Master2 is the slave to Master1. • Master1 is the slave of Master2.
This will work only if one Master is written to at a time. To do this:
1. Stop the databases on server1 and server2.
service mysqld stop
2. Copy from the server that has the latest /valid data (example, server 1 - to the other server - example server2).
scp –r /var/lib/mysql/mzs server2:/var/lib/mysql
3. On server2 run:
chown –R mysql /var/lib/mysql/mzs
4. Followed by:
chgrp –R mysql /var/lib/mysql/mzs
5. Restart both MySQL servers:
service mysqld start
6. The databases will now be the same.
Step 1
1. On Master1, make changes in /etc/my.cnf:
[mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock old_passwords=1
log-bin
Genesys Video Deployment Guide 52 Deployment Models
# database which should replicated binlog-do-db=mzs # database that should be ignored for replication binlog-ignore-db=mysql server-id=1 slave-skip-errors=1062,1061,1060 [mysql.server] user=mysql basedir=/var/lib [mysqld_safe] err-log=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid
Step 2
1. On Master1, create a replication Slave account in MySQL.
2. Log into the database using the command mysql –u root –p 3. You will be prompted for the password that you set up during the platform pre-install stage.
mysql> grant replication slave on *.* to 'replication'@
4. Restart the MySQL Master1 by typing service mysqld restart.
Step 3
1. Edit /etc/my.cnf on Slave1 (Master2).
[mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock old_passwords=1 server-id=2 #( IP address of remote server in this case Master1) master-host =
[mysqld_safe] err-log=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid
Step 4
1. If there are any problems restarting after these changes due to man page location, on RHEL 4 and 5, add the following link on both servers.
cd /var/lib ln -s /usr/share
2. Restart MySQL Slave1 (Master2) by typing service mysqld restart.
Genesys Video Deployment Guide 53 Deployment Models
3. Log in to MySQL and type start slave;
4. Followed by show slave status \G
5. Check that Slave_IO_Running = Yes and Slave_SQL_Running = Yes.
Step 5
1. On Slave1 (Master2), edit /etc/my.cnf and add Master entries into it:
[mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock # Default to using old password format for compatibility with mysql 3.x # clients (those using the mysqlclient10 compatibility package). old_passwords=1 server-id=2
master-host = 198.168.16.4 master-user = replication master-password = slavep1 master-port = 3306 slave-skip-errors=1062,1061,1060
log-bin #information for becoming master added binlog-do-db=mzs # information for becoming master added binlog-ignore-db=mysql
[mysql.server] user=mysql basedir=/var/lib [mysqld_safe] err-log=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid
Step 6
1. Log into MySQL and create a replication Slave account on Master2 for Master1:
mysql> grant replication slave on *.* to 'replication2'@
Step 7
1. Edit my.cnf on Master1 for information of its Master.
[mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock
# Default to using old password format for compatibility with mysql 3.x # clients (those using the mysqlclient10 compatibility package). old_passwords=1
log-bin binlog-do-db=mzs binlog-ignore-db=mysql
Genesys Video Deployment Guide 54 Deployment Models
server-id=1 #information for becoming slave. master-host =
Step 8
1. Restart both MySQL Master1 and Master2. 2. This can fail with the following error:
mysql> start slave;
ERROR 1200 (HY000): The server is not configured as slave; fix in config file or with CHANGE MASTER TO
In this case, use the change master to command as shown below, after stopping the slave, and then start it. Note: You may want to first remove the file /var/lib/mysql/master.info.
mysql> stop slave; Query OK, 0 rows affected (0.00 sec) mysql> change master to master_host = ‘135.17.37.30’; Query OK, 0 rows affected (0.01 sec) mysql> start slave;
3. On MySQL Master2:
mysql > show master status;
4. On MySQL Master1:
mysql> show slave status\G;
5. Check that Slave_IO_Running = Yes and Slave_SQL_Running = Yes.
Step 9
1. If the Slave processes are not running, confirm that the replication user can log in remotely from Slave database host into the Master database, for example from
mysql -u replication –pslavep2 -h
For more information on MySQL Replication:
• http://dev.mysql.com/doc/refman/5.0/en/replication.html • http://dev.mysql.com/doc/refman/5.0/en/replication-faq.html
Files to be synchronized
Make sure that the following files and directories are synchronized across the two AS servers:
/opt/zenon/sys/login.txt
/opt/zenon/public_html/profiles/
Genesys Video Deployment Guide 55 Deployment Models
F5 High Availability
When a Collaboration Application Server (AS) must be highly available, similar to HAProxy, an F5 based HA configuration can also be used, where F5 manages the active and standby instance of AS. Any errors detected in the active AS result in a failover to the standby AS and an SNMP alarm.
If configuring multiple Application Server instances behind a load balancer, for non-host specific parameters, please ensure that the non-host specific configuration entries in the infotypes_saypage.xml are consistent across the AS nodes.
F5 HA Design and Configuration
• Assume there are two AS boxes: AS1 and AS2 having different IPs [IP1 AND IP2], but the same domain name is used for both.
• Initially, both the boxes are set as Passive. • F5 has its own logic to direct the traffic to AS.
• Make sure active header is configured in the /opt/zenon/public_html/WEB-INF/infotypes_saypage.xml file.
F5 sets the above domain name in the Host header. This must be pre-configured because when AS receives traffic, it checks the above IT file that it has those headers set.
When AS writes active headers and IP to the database table, the header must match with the domain names in the database table. The box that receive traffic sets itself to ACTIVE and writes it to a database table called maxmcu_active_zas.
The table stores the ACTIVE box IP and the domain name along with the updated timestamp. Make sure that the above table exists. There is no need to pre-populate the table as AS clears the table on startup and populates it when F5 traffic is received.
• Both boxes have their own set of databases: DB1 and DB2. Data is synchronized between two databases, using mysql replication.
• Each box has a monitor running, internal to each AS. This monitor periodically checks if the LOCALHOST IP of the current box is equal to that stored inside maxmcu_active_zas table. If that’s not the case, it sets itself to PASSIVE. • On the Passive box, the monitor returns immediately and doesn't check the database. Sleep time, in milliseconds, of this thread can be configured using this IT:
• F5 periodically keeps checking and tries a ping command – get_local_host. If F5 doesn't get a response, F5 redirects traffic to the other box.
URL Example: http://rbw1.genrtc.net/servlet/ com.requestec.smg.servlets.Brora?command=get_local_host
Genesys Video Deployment Guide 56 Deployment Models
Response:
PRODUCTION ACTIVE 10.144.245.74
N+M Instances of Collaboration MCU
In general, if Genesys Video Gateway is deployed as a farm of N MCU instances and you want to prepare for the potential failure of M instances, you can maintain maximum availability of the service by deploying N + M MCU instances. Configure the AS to detect the failure of any MCU instances and to direct incoming sessions to the remaining instances.
Genesys Video Deployment Guide 57 Deployment Models
Failover
Collaboration Application Server
As described in the Availability page, if F5 HA is used for Collaboration Application Server (AS) in active-standby mode, the failover can be achieved as the active AS goes out of service.
Collaboration MCU
If an MCU is taken out of service or fails completely, the users are moved to the next most suitable MCU. This can happen in two ways:
• The client loses connection to the MCU. It contacts the AS again, letting the AS know that it lost connectivity. The AS provides an alternative MCU and checks the faulty MCU server using the same network interface that the client would use. • The AS itself detects a problem with the MCU using results from a comprehensive set of regularly repeated tests which cover the SIP, Flash, and HTTP services. The tests are run on the MCU and results reported to the AS along with load statistics every few seconds. The MCU is then marked as unavailable until further tests succeed. Any clients currently waiting on that server will be moved to another server.
Currently, for a one-to-one media session, the platform does not provide continuity of the session when a failure occurs at MCU level. When a failure happens during such a session, the session is considered to have failed.
However, in case of conference calls, the client auto-redials and the AS then reallocates to a new MCU. The call disconnects for a moment, but then is immediately re-established.
Genesys Video Deployment Guide 58 Configuration Files
Configuration Files
The table below shows a full list of all the files used on the platform that can affect changes across a whole server (service-level changes):
Configuration File Location Purpose To set service level parameters for infotypes_saypage.xml /opt/zenon/public_html/WEB-INF both AS and MCU zs.properties /opt/zenon/zenonserver To set parameters for the NS saypage_2130.cfg /opt/zenon/share/config/saypage To set the ports for the MCU To set the parameters for the Flash zenoncdsrv.ini /opt/zenon/rtmfpcd Server (RTMFP) /opt/zenon/zenonserver/ To set parameter for the Flash democonfig.cfg AVFlashServices/AVFRW services Grants Flash player permission to crossdomain.xml /opt/zenon/public_html talk with servers other than the host To set the SNMP Agent IP and port snmp.properties /opt/zenon/share/config/snmp along with NMS IP address
The most important configuration file in terms of the number of changes it affects is the infotypes_saypage.xml file. Here, both AS and MCU configuration items are set at the service-level, which dictates the deployment behavior.
The AS configurations are set in the top
The following link is useful for checking the value of a parameter: http://
Genesys Video Deployment Guide 59 Management Interface
Management Interface
Genesys Video Gateway includes a Management User Interface (MI), which can be accessed at: https://your-as-domain.com/stats/
The default admin username/password is: admin/admin777.
To change the administrator password, login to the Management Interface. From the left panel, click Change Password and enter the current password and the new password.
In the Management Interface, you can view, download, and export real-time call data. In addition to tabular output, graphing tools are available, and you can add additional reports on demand. Here is an example view of the MI, which shows Graphs.
Genesys Video Deployment Guide 60 Management Interface
Management Interface, Graphs View
The Management Interface is also where you can provision users on the system. Using the Portal Configuration, you can set parameters in the server tables without having to directly access the server at all. Customer service type functions can also take place in the MI. Permissions are role-based and regular forced password changes can be configured. Here is another example view of the MI, which shows Administrator Provisioning.
Genesys Video Deployment Guide 61 Management Interface
Management Interface, Administrator Provisioning View
Genesys Video Deployment Guide 62 Configuration Options Reference
Configuration Options Reference
The Portal Configuration section in the Management Interface (MI) provides the details for all of the configuration parameters. This is where you can change the value of any parameter.
The following table contains a subset of configuration options that are considered important from the platform’s point-of-view:
Key Name Verbose Key Description Type Default Value Sets whether network Tech Check Network BOOLEAN TRUE speed is checked Sets whether Tech Check Tech Check on Apps menu BOOLEAN is shown on Apps menu Sets whether Tech Check Skip Tech Check on Login BOOLEAN is skipped on login Sets whether hardware is Tech Check Hardware BOOLEAN TRUE checked Sets whether WebRTC can WebRTC to Flash Failover Boolean TRUE failover to Flash Sets whether WebRTC is Enable WebRTC Boolean TRUE enabled or not Sets whether WebRTC is Enable WebRTC in Firefox Boolean enabled on Firefox browser Sets whether Javascript JS Console logging Boolean TRUE Console logging is enabled Asks for Video and Voice in Confirm User Cam and Mic Boolean present session for Users Sets whether Client logs Send Client logs to CLS are sent to server Sets the height of Camera WebRTC Cam Height Text Capture in WebRTC Sets the width of Camera WebRTC Cam Width Text Capture in WebRTC Sets the height of Camera Flash Cam Height Text Capture in Flash Sets the width of Camera Flash Cam Width Text Capture in Flash Flash Incoming Video Sets the height of Incoming Text Resolution Height Video Resolution in Flash Flash Incoming Video Sets the height of Incoming Text Resolution Width Video Resolution in Flash Sets the width of Incoming WebRTC Incoming Video Video Resolution in Text Resolution Height WebRTC
Genesys Video Deployment Guide 63 Configuration Options Reference
Key Name Verbose Key Description Type Default Value Sets the height of Incoming WebRTC Incoming Video Video Resolution in Text Resolution Width WebRTC
Genesys Video Deployment Guide 64 Hardware Sizing
Hardware Sizing
Network and Hardware Sizing Guidelines
To help you determine your needs, you can use the Sizing Calculator.
Genesys Video Deployment Guide 65 Troubleshooting
Troubleshooting
Verify Ports are Open
Verify whether domain, IP's, and ports are accessible from the client.
1. To send UDP, go to:
http://
2. And change the left box to:
rtmfp://
3. For SSL/TCP go to:
https://yourdomain.com
4. Verify that you receive a page and a green padlock in Chrome. 5. To listen on the MCU or AS when testing specific ports, you can use Wire-shark as shown here:
tshark -f "tcp port 443" -i eth0
Check MCU and MCU Helper Processes are Running
Check for MCU
Running this should print out at least one number: pidof maxmcu
Check for AVRW
Running this should report back two processes: ps aux | grep startav
Example: root 4022 0.0 0.0 279160 6588 ? Sl Jan22 5:35 /opt/zenon/avservices/AVReaderWriter/startavreader -x -c /opt/zenon/avservices/AVReaderWriter/AVServicesprod.conf root 4078 0.0 0.0 279160 6596 ? Sl Jan22 5:26 /opt/zenon/avservices/AVReaderWriter/startavwriter -x -c /opt/zenon/avservices/AVReaderWriter/AVServicesprod.conf
Check for AVFRW
Running this should report back a number:
Genesys Video Deployment Guide 66 Troubleshooting
ps aux | grep startflash
Example: root 4622 0.0 0.0 450884 7496 ? Sl Jan22 5:55 /opt/zenon/zenonserver/AVFlashServices/AVFRW/startflashwriter -x -c /opt/zenon/zenonserver/AVFlashServices/AVFRW/democonfig.cfg root 5129 0.0 0.0 450884 7492 ? Sl Jan22 5:52 /opt/zenon/zenonserver/AVFlashServices/AVFRW/startflashreader -x -c /opt/zenon/zenonserver/AVFlashServices/AVFRW/democonfig.cfg
Useful URLs
• Test interaction between components: https://
• WebRTC test page: https://
• Testing UDP ports: http://
• Click-To-Call demo page: http://
• Real-time monitoring: http://
• Current config value: https://
• Printing cookies: http://
Check Component Logs
For AS, NS, and MCU, the logs are stored in the /opt/zenon/logs folder. For the TURN Server, the logs are in the /var/log folder.
AS logs are logged into the cls.log file. The default log file size is 5Mb and it's rotated as cls.log.xx. A maximum of 100 files is supported.
NS logs are logged into the zs.log file. The default log file size is 20Mb and it's rotated as zs.log.xx. A maximum of 10 files is supported.
For MCU there are two processes:
• mcu_saypage_2130_[date]_xx.log files are generated every hour.
• mcu_zenon_2130_[date]_xx.log files are generated every hour. • The MCU logs are not rotated and need periodic cleanup.
TURN server logs are logged into the turn_xxx.log file. These are generated on a daily basis and need periodic cleanup.
To enable debugging for AS or NS, update /opt/zenon/zenonserver/log4j.properties, and set the log level to INFO in the Threshold parameter. The default is ERROR.
Genesys Video Deployment Guide 67 Troubleshooting
For MCU debugging, set Log Level parameter in /opt/zenon/public_html/WEB-INF/ infotypes_saypage.xml 4 or 5. The default is 3.
For debugging within the log files you can check for various messages, like these:
• To find the commands going into AS: grep Brora cls.log
• REQUEST_SPEED, SLOW REQUEST and SLOW QUERY shows the response time for the request.
• To find HTTP calls to AS from MCU: grep "http://localhost[^:]” mcu*.log
• To find HTTP calls to NS from MCU: grep “http://localhost:14040” mcu_*.log
• To find for MCU allocation pass/fail: grep MCUALLOCATION cls.log
• To find the messages received by NS from browser: : grep “( ZCSocket.onWebSocketText )” zs*.log.
• To find the HTTP responses sent to browser from NS: grep “( ZCSocket.sendMessage ) Message sent to client” zs*.log
• To find the HTTP requests received by NS from MCU: grep “Recvd Zebra message from MCU or CLS:” zs*.log
• To find the HTTP requests sent by NS to MCU: grep “HttpRequest.sendRequest” zs*.log
Startup Issues
If you see that the web pages are not accessible after startup, follow these steps:
1. Issue the following command as zenon_maint user: /usr/bin/sg zenon_maint_group "/opt/zenon/sh/ monitor_zenon.sh &> /opt/zenon/logs/startup.log”.
2. Kill the Java process returned by ’ps –elf | grep zs.prop’.
3. Look for any error or exception in the startup.log file generated in Step 1. You can also check the AS log file, cls.log, from the platform logs directory. 4. If the platform still has issues:
1. Stop the platform by using /opt/zenon/sh/stop_genesys_video.sh.
2. Clean the temp/cache/log files using the command '/bin/rm /tmp/org.red5* /opt/zenon/run/* /opt/zenon/logs/*' (This is to make sure that the issue is not related to file permissions.) If you encountered permission errors when performing the cleanup, you may need to do this step as ‘root’ user; make sure that you first backup any necessary log files from /opt/zenon/logs/.
3. Restart the platform using /etc/init.d/zenon_zs.
5. If the issue persists, reboot the system, and then restart the platform using the method in the previous step, provided it is not restarted automatically by init.d.
Genesys Video Deployment Guide 68 Troubleshooting
Check System Performance
The following commands can be used to extract information on the system’s performance.
1. First, install the sysbench package. It is included in the extras folder of the Common IP:
sudo yum -y --nogpgcheck localinstall postgresql-libs-8.4.20-2.el6_6.x86_64.rpm sudo yum -y --nogpgcheck localinstall sysbench-0.4.12-5.el6.x86_64.rpm
2. To test CPU performance, run:
sysbench --test=cpu --cpu-max-prime=20000 run
3. To test FILE IO (Disk performance), run:
sysbench --test=fileio --file-total-size=150G prepare
4. Then run:
sysbench --test=fileio --file-total-size=150G --file-test-mode=rndrw --init-rng=on --max-time=300 --max-requests=0 run
5. To test MySQL performance, run:
sysbench --test=oltp --oltp-table-size=1000000 --mysql-db=test --mysql-user=root --mysql-password=yourrootsqlpassword prepare
6. Then run:
sysbench --test=oltp --oltp-table-size=1000000 --mysql-db=test --mysql-user=root --mysql-password=yourrootsqlpassword --max-time=60 --oltp-read-only=on --max-requests=0 --num-threads=8 run
7. Finally, to clear the test table, run:
sysbench --test=oltp --mysql-db=test --mysql-user=root --mysql-password=yourrootsqlpassword cleanup
Garbled Audio Issue with Flash
If the client machine contains multiple recording devices (mics), then it's necessary to set the default recording device and possibly disable the unused or unavailable ones (like Jack mic or Doc mic if not available). Otherwise, Flash has some issues in selecting the correct mic and produces garbled audio in a Click-to-Call scenario.
In Windows, for example, go to the Sound window, and click or tap on the Recording tab. Your current default device is indicated by a green check mark. Select your preferred device and click or tap Set Default.
Genesys Video Deployment Guide 69 Troubleshooting
Genesys Video Deployment Guide 70