Many basic maintenance tasks in Call Recording can be executed directly from the command line. For each of the following tasks, log in as an Administrator with Root privileges.
- Starting and stopping Call Recording
- Automatic running
- Reloading the Configuration manager
- Checking the Status of Call Recording
- Restarting and Shutting Down the Server
- Restarting the Decoder
- Restarting Call Recording Core
- Restarting the Call Recording System
- Restarting other Call Recording Components
- Restarting Clustered Servers
- Restarting Redundant Servers
- Restoring the Default Configuration
- Using Symlinks to the Call Recording PCAP Storage Directory
- Important Note on Synchronization
- Mounting Windows File Shares
- Advanced Configuration Parameters
- Limit on the Maximum Number of Threads
Starting and stopping Call Recording
Use the service commands for starting, stopping and restarting Call Recording services when logged on as root. The service command functions as a shortcut to the /etc/init.d directory.
[root@callrec ~]# service callrec
Use the absolute path for these commands as this does not require a change of directory and avoids issues with directory permissions. Usage:
/etc/init.d/callrec {start|stop|restart|status}
Starting Call Recording
Use the following command to start the Call Recording application:
/etc/init.d/callrec start
Or:
Log in as admin. Enter su - to log in as the root user. Enter the password, the default is zoomcallrec. and use:
service callrec start
The system displays confirmation of all services that start.
Starting Call Recording RMI: . [ OK ] Starting Call Recording NAMING: . [ OK ] Starting Call Recording CONFIGMANAGER: .. [ OK ] Starting Call Recording JTAPI: . [ OK ] Starting Call Recording RS eth1: [ OK ] Starting Call Recording DECODER - DecoderMasterCommunicator: . [ OK ] Starting Call Recording Screen Capture: . [ OK ] Starting Call Recording CORE: .... [ OK ] Starting Call Recording IPCC: .. [ OK ] Loading Call Recording Tools configuration views: [ OK ] Starting Call Recording WEB: .......... [ OK ]
Stopping Call Recording
Use the following command to stop the Call Recording application:
/etc/init.d/callrec stop
Or:
Log in as admin. Enter su - to log in as the root user. Enter the password, the default is zoomcallrec. and use:
service callrec stop
The system displays confirmation of all services that stop.
Stopping Call Recording WEB: ..... [ OK ] Stopping Call Recording IPCC: .. [ OK ] Stopping Call Recording CORE: .... [ OK ] Stopping Call Recording Screen Capture: ........... [ OK ] Stopping Call Recording RS eth1: ... [ OK ] Stopping Call Recording DECODER - DecoderMasterCommunicator: .. [ OK ] Stopping Call Recording JTAPI: .. [ OK ] Stopping Call Recording CONFIGMANAGER: .. [ OK ] Stopping Call Recording NAMING: .. [ OK ] Stopping Call Recording RMI: ........... [ OK ]
Restarting Call Recording
Restart stops the services and then starts them again.
Use the following command to restart the Call Recording application:
/etc/init.d/callrec restart
Or:
Log in as admin. Enter su - to log in as the root user. Enter the password, the default is zoomcallrec. and use:
service callrec restart
The system displays confirmation of all services that restart.
Stopping Call Recording WEB: ..... [ OK ] Stopping Call Recording IPCC: .. [ OK ] Stopping Call Recording CORE: .... [ OK ] Stopping Call Recording Screen Capture: ........... [ OK ] Stopping Call Recording RS eth1: ... [ OK ] Stopping Call Recording DECODER - DecoderMasterCommunicator: .. [ OK ] Stopping Call Recording JTAPI: .. [ OK ] Stopping Call Recording CONFIGMANAGER: .. [ OK ] Stopping Call Recording NAMING: .. [ OK ] Stopping Call Recording RMI: ........... [ OK ] Starting Call Recording RMI: . [ OK ] Starting Call Recording NAMING: . [ OK ] Starting Call Recording CONFIGMANAGER: .. [ OK ] Starting Call Recording JTAPI: . [ OK ] Starting Call Recording RS eth1: [ OK ] Starting Call Recording DECODER - DecoderMasterCommunicator: . [ OK ] Starting Call Recording Screen Capture: . [ OK ] Starting Call Recording CORE: .... [ OK ] Starting Call Recording IPCC: .. [ OK ] Loading Call Recording Tools configuration views: [ OK ] Starting Call Recording WEB: .......... [ OK ]
During restarting or stopping Call Recording may list processes or modules which have stopped responding. These processes are then terminated, and this does not influence restarting the system.
Automatic running
To automatically run Call Recording on startup, add Call Recording to server run levels during setup.This is the default during installation.
To add Call Recording to the startup sequence of the server, run the command in root:
/sbin/chkconfig --add callrec
Enable automatic startup of Call Recording with the following command:
/sbin/chkconfig --add callrec
Disable automatic startup of Call Recording with the following command:
/sbin/chkconfig callrec off
Reloading the Configuration manager
If Call Recording is restarted while recording calls, the recordings of the calls being recorded at the time are lost. However Call Recording uses an independent configuration server to store configuration information for all the components of the system. This means the entire Call Recording system does not need to be restarted to change the configuration of individual components that do not affect the recording of calls, such as the Tools service and Synchro service.
By reloading these configuration parameters, configuration can be reset in these components without restarting the system.
Reload the configuration with the following command:
/opt/callrec/bin/rc.callrec_configmanager reload
Reloading the Configuration manager causes the following:
- All configuration files are reloaded as changed
- Pending configuration operations are consolidated
- Registered observers remain active (other services do not need to reconnect)
Reloading the configuration manager is ineffective if the main system configuration changes, specifically decoder or encoder settings. This means that changing the sniffing method or encoding type needs a complete restart of the Call Recording system.
Checking the Status of Call Recording
Use the Application Communicator to check the status of Call Recording. The Application Communicator reports all processes and modules running and their current state.
The Application Communicator is invoked from command line. It has the following parameters:
- port [port] - rmi port (default: 30400)
- host [host] - rmi host (default: localhost)
- names - returns all names supported Application Communicator interface
- name [name] - rmi bind name (default: remoteCallRec)
- bindName [bindName] - rmi bind name - all path (default: //localhost:30400/remoteCallRec)
- help – shows help for all parameters
- stateNames - returns module names to provide state information
- state [{name}|all] - state information about a module or all modules
- verbosity [1|2|3|4|5] - set state verbosity (all information: 5, default: 2)
- stateOption [status|failed] - set state option
status - only status row (OK or FAILED)
failed - only FAILED row - versionNames - return module names provide version information
- version [{name}|all] - version info about application (one module, all modules)
- modifyNames - return module names you can modify properties
- modifyHelp [{name}|all] - return help about modifiable properties (one module, all modules)
- modifyInt [module,property,value] - modify int value (property of module)
- modifyString [module,property,value] - modify String value (property of module)
To check the status of the entire Call Recording system while Call Recording is running, use the shortcut command:
/etc/init.d/callrec status
Below is a typical extract from the command output:
[root@callrec ~]# service callrec status Application communicator trunk-SNAPSHOT, build: 100523_0107 (c) ZOOM International 2003 - 2007 Application state information: (//192.168.110.78:30400/remoteCallRec) Verbosity: 5 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Call Recording 4.6.0, build: 100525_2234, Copyright (c) 2002-2009 ZOOM International. All rights reserved
-- CoreOfCallRec -- 1001010 [Calls] [**...] - Count of active calls ... 0 1001015 [Calls] [****.] - Last call id ... 0 1002010 [Couples] [**...] - Count of active couples ... 0 1002015 [Couples] [****.] - Last couple id ... 0 1003010 [Streams] [**...] - Count of active streams ... 0 1003015 [Streams] [****.] - Last stream id ... 0 1004010 [ThreadManager] [**...] - Thread manager status ... Used - 2, unused - 2 1004011 [ThreadManager] [***..] - Min unused threads ... 20
-- DecoderCommunicator -- 7000020 [decoderServerCommunicator] [****.] - Prefer archives for files ... mp3, zip, wave 7000030 [decoderServerCommunicator] [****.] - Prefer archives for emails ... mp3, zip, wave 7001001 [decoderManager] [*....] - Info ... Decoder3 (Decoder3 4.6.0, build: 100525_2232) ............................................. [ OK ] 7000039 [decoderManager] [**...] - Email Template ... email 7000040 [decoderManager] [**...] - Email Error Template ... emailerror
Restarting and Shutting Down the Server
To restart the server from the local console, press CTRL+ALT+DEL combination. The system safely terminates all services and restarts.
To restart the server remotely, log in as admin then type su - and the password into the console and enter the command reboot.
To shut down the server, log in as admin then type su - and the password into the console and then enter the command halt.
Restarting the Decoder
If new calls are not visible in the GUI, then restart the Decoder:
- Log in as
adminthen typesu- - Type the command
/opt/callrec/bin/rc.callrec_ds restart
Restarting Call Recording Core
To restart only Call Recording Core, while the rest of components stay running:
- Log in as
adminthen typesu- - Type the command
/opt/callrec/bin/rc.callrec_core restart
Restarting the Call Recording System
To restart the entire Call Recording system without rebooting:
- Log in as ‘admin’ then type
su -root - Type the command
/etc/init.d/callrec restart or service callrec restart
Restarting other Call Recording Components
To restart individual Call Recording components:
- Log in as
adminthen typesu- - Type the command
/opt/callrec/bin/rc.COMPONENT_NAME restart
Where COMPONENT_NAME is:
| COMPONENT_NAME | Component to be Restarted |
|---|---|
callrec | All Call Recording components |
callrec_archive | Archive Tool |
callrec_callmonitor | Call Monitor |
callrec_configmanager | Configuration Manager |
callrec_core | Call Recording Core |
callrec_delete | Delete Tool |
callrec_ds | Decoder Server |
callrec_genesys | Genesys Integration Module |
callrec_instreamer | Audio Stream Recording |
callrec_mixer | Audio and Video Mixer |
callrec_naming | Naming Tool |
callrec_relocation | Relocation Tool |
callrec_restore | Restoring Tool |
callrec_rmi | RMI Service |
callrec_rs | Recorder Server |
callrec_rts_jtapi | JTAPI Adapter |
callrec_rts_sip | SIP Adapter |
callrec_rts_skinny | Skinny Adapter |
callrec_slr | Active Recorder |
callrec_synchro | Synchronization Tool |
callrec_screenrec | Screen Capture |
callrec_tools | All Tool Components |
callrec_web | Web Server (Tomcat5) |
Restarting Clustered Servers
Go to /etc/callrec/callrec.conf on each server of the cluster to see which services are enabled.
The components must be restarted in a specific order.
First stop Call Recording services on all clusters:
/etc/init.d/callrec stop
Then start the cluster that has the core service enabled:
/etc/init.d/callrec start
Start the rest of the cluster and check the status of all components.
If a component is located on more than one server and these servers are configured as a cluster, then you must name each component and restart them individually:
- For each server, log in as
adminthen typesu- Type the command
/opt/callrec/bin/rc.COMPONENT_NAME restart (see table above)
- Repeat steps 1 and 2 for each server
After restarting all servers in the cluster, log in to the server with the Call Recording Core module and type the command:
/opt/callrec/bin/rc.callrec_core restart
Restart the configuration manager with the command
/opt/callrec/bin/rc.callrec_configmanager restart
Restarting Redundant Servers
Redundant servers allow you to ensure there is no loss of data when you restart services. To restart redundant servers, restart the primary server (or cluster) and then the Call Recording Core and Configuration Manager. After Call Recording Core has restarted, restart the secondary server (or cluster). Finish the process by restarting Call Recording Core and Configuration Manager again.
Restoring the Default Configuration
Do not change your configuration settings without consulting the system administrator. Write down all custom settings so that they can be restored.
To revert all the Call Recording configuration settings to the original defaults, follow this process:
Stop the Call Recording service:
service callrec stop
Backup current configuration files, for example using tar:
tar -cf backup-cfg.tar / opt/callrec/etc/*
Replace current configuration files with the defaults:
/bin/cp /opt/callrec/etc/default/* /opt/callrec/etc
Execute the main Call Recording configuration script (see the Genesys Quality Management Suite Implementation Guide):
/opt/callrec/bin/callrec-setup
Start Call Recording:
service callrec start
- Log in to Call Recording and use the web configuration interface to confirm your default settings.
Using Symlinks to the Call Recording PCAP Storage Directory
It has been reported that there are occasional problems during Call Recording migration or upgrading if Linux symbolic links ('symlinks') have been used for key Call Recording folders. Specifically, an issue has been reported when the 'pcap' storage folder has been linked to a different physical location, using the Linux 'ln -s' command. In some cases, the symlink(s) are no longer found, causing failure of the associated Call Recording components.
It is therefore recommended that symbolic links are not used for the /opt/callrec/data/pcap PCAP storage directory.
Instead, specify the physical pcap folder location in the /opt/callrec/etc/callrec.conf configuration file, in the following section:
# # Path to store pcaps # PCAP="/opt/callrec/data/pcap"
Important Note on Synchronization
If the Call Recording installation is part of a multiple site cluster configuration including CUCM, all the servers in the cluster should be time-synchronized (via NTP) with the same server as CUCM.
If the servers are not properly synchronized, some of the recordings may have issues with stream synchronization.
Check the NTP daemon configuration file which is located in /etc/ntp.conf if it contains correct addresses of NTP servers.Look for "server" records and change the addresses of the servers to the ones you use in your network.
For example server 3.cz.pool.ntp.org
Stop the NTP daemon using the following command:
/etc/init.d/ntpd stop
Stop Call Recording and the Database using the following command:
/etc/init.d/callrec stop /etc/init.d/postgresql stop
Synchronize time manually using the following command:
ntpdate <timeserver IP address>
Write the current time to the system BIOS using the following command:
hwclock --systohc
Start the NTP daemon using the following command:
/etc/init.d/ntpd start
Check if the time/date is correct now using the following command:
date
Start the database and Call Recording again using the following command:
/etc/init.d/postgresql start /etc/init.d/callrec start
The system takes a while before it is synchronized (usually around 15 minutes from when the NTP daemon was started):
Check the synchronization state using the following command:
ntpstat
Mounting Windows File Shares
Connecting a Windows-based remote file storage facility to a Linux operating system can be tricky. To configure a connection to (or 'mount') a Windows file share for archive or backup media storage, for example, use the following procedure:
- Ensure the following information is available:
- Windows share username and password
- Windows server IP address or share address (of the form
//winserver/path/to/folder- note the use of forward slashes / instead of backslashes \) - Root (administrator) access to the Call Recording Linux server
When a Windows file share is used for Call Recording data storage, ensure that the password change policy is disabled for the Call Recording user account. Failure to disable enforced password changes can lead to Windows shares being made inadvertently inaccessible to Call Recording.
Log in to the Call Recording server and switch to the root account if necessary (using the
sucommand):su -
Create the required mount point (the directory to later access the Windows share). This can be any directory path, for example
/mnt/winserver:mkdir -p /mnt/winserver
Use the
mountcommand as follows (whereuserandpassare replaced by your Windows share username and password, and the share address & mount point are modified appropriately). This command should all be on one line:mount -t cifs //winserver/path/to/folder -o username=user,password=pass /mnt/winserver
Tip:To remove a mounted file share, use the
umountcommand:umount -t cifs /mnt/winserverOnce mounted, the Windows file share can now be accessed from the Linux system using standard directory commands:
cd /mnt/winserver ls -l
- In Call Recording Web GUI settings, enter the mount point directory path to reference the Windows file share (for example
/mnt/winserver/path/to/folder). Step 4 needs to be repeated each time the Linux system is restarted. To auto-mount this file share when the system starts, add the following single line to
the/etc/fstabfile (updating the share address, mount point,userandpassparameters as required)://winserver/path/to/folder /mnt/winserver cifs username=user,password=pass 0 0
Troubleshooting Tips
The following information may help to troubleshoot errors that result from trying to mount a Windows file share:
- Authentication issues may be fixed by providing more information. If the Windows server uses domain authentication, add the domain either in the options (
username=user,domain=domain,password=pass), or as part of the username (username=domain/username). - Password issues may be fixed by adding quotes around the password (
username=user,password="pass") - Connection issues may be due to a firewall. SMB connections from Linux require TCP ports 137, 138, 139, 445 to be open in the Windows server.
- If a
cifs_mounterror (value-22) is received, you may need to install the Samba client first:yum install samba-client. On older Linux releases (RHEL <= 4 and similar), the smbfs type needs to be used in the mount command, for example:
mount -t smbfs //winserver/path/to/folder -o username=user,password=pass /mnt/winserver
For more information on accessing an SMB file share from Linux, see the following how-to page: http://tldp.org/HOWTO/SMB-HOWTO-8.html.
Advanced Configuration Parameters
Some Call Recording components have advanced configuration parameters that are not included in the Call Recording Web GUI Settings section. These parameters can be specified in Call Recording configuration files, therefore root administrator access to the Call Recording servers is required.
After modifications have been made to configuration files, restart the Configuration Service and related components. For example, this can be achieved for the Active Recorder (SLR) as follows:
/opt/callrec/bin/rc.callrec_configmanager restart Stopping Call Recording CONFIGMANAGER: . [ OK ] Starting Call Recording CONFIGMANAGER: . [ OK ] /opt/callrec/bin/rc.callrec_slr restart Stopping Call Recording SLR 1: . [ OK ] Starting Call Recording SLR 1: [ OK ]
Active Recorder (SLR) Configuration Parameters
The Active Recorder (SLR) is configured in the callrec.derived configuration file, located by default at /opt/callrec/etc/callrec.derived on theCall Recording server. This file contains an SLR section, similar to the following:
# # SpanLess Recorder server # # SLR_IORFILE is prefix of files to save oir file for slr instance. # SLR_COUNT defines required count of SLRs instances to run. # SLR_PARAM[x] defines params for specific instance of SLR. # Every isntance must differ from others at least in address(-a) # or port(-P) to listen on. Also RPT port range must be exclusive # for all instances (-R and -S). # SLR_IORFILE="$TMP/slr" SLR_COUNT=1 SLR_PARAMS[1]="--connectionString amqp://192.168.10.1 -t 120 -m 40 -A 0 -A 8 -A 9 -A 18 -A 13 -A 19 -l /etc/callrec/slr.log4cxx.properties"
The SLR_PARAMS[1] property contains the parameters for the first Active Recorder instance. The main parameters and their values are shown in the following table. A complete list of parameters can be obtained by querying the slr module directly:
/opt/callrec/bin/slr --help
| Parameter | Description |
|---|---|
| -A --accept <num> | Accept payload num. can be specified as several options (0,8,9,18,13,19) |
| -m --minpackets <num> | Minimum packets representing not empty stream (default: 0) |
| -l --logger <name> | File with log4cxx configuration (default: slr.log4cxx.properties) |
| -e --sessionexpires <num> | Timeout of SIP session expiration in seconds (default: 1800). Valid range: 90 - 86400 |
| -s --rejectedsessions <num> | Max. rejected SIP sessions between 2 states (default: none) |
| -a --sipaddress <ip> | Listening SIP address (default: 0.0.0.0) |
| -P --sipport <port> | Listening SIP port (default: 5060) |
| -R --rtpport <port> | Starting RTP port (default: 16384) |
| -c --rtpportscount <num> | Count of allocated RTP ports in pool (default: SIP sessions * 2) |
| -n --notcp | Do not use TCP protocol |
| -S --maxsessions <max> | Max. concurrent SIP sessions (default: 400) |
| -M --requiremark | Starting mark for SIP session is required |
| --pingTimeout | The frequency in seconds to send ping to the Core. Disabled if zero. |
Notes on Parameters
-e (--sessionexpires):
The Active Recorder supports the SIP Timer extension (RFC-4028). During SIP session negotiation, the Recorder initially assumes that the remote party handles session renewal via the Timer extension mechanism. However, if the remote party does not support the timer extension or its processing, the Active Recorder performs this 'session audit' functionality itself. It starts a timer (configured with this parameter's value) after a re-INVITE request issued to the remote party has timed out, and issues a BYE request to terminate the session if that timer also times out.
--pingTimeout
The options allow to change (or disable) the frequency of ping sends form SLR to the Core. It is also recommended to alter the Recorder Communicator timeout value so it is at least twice the value set on the Recorder. For example if pingTimeout on the Recorder is 10s it should be 20s on Recorder Communicator. If SLR ping timeout is set to 0 it shall be some high value on recorder communicator (as it cannot be zero there). See the example of Recorder Communicator configuration:
<Group name="ha">
<Value name="pingTimeout">99999999</Value>
<Value name="stopRequestTimeout">30</Value>
</Group>
Example: recorders.xml - with ping switched off for recorders and with an extended waiting period for call finish.
Limit on the Maximum Number of Threads
Note for system administrators:
Since RHEL 6.2and CentOS 6.2, the number of created threads for an application has a soft limit applied. This can cause erratic behavior and random failures of the application.The installation scripts remove this configured limit but if the installation has been done without the installation then the limit still applies.
https://bugzilla.redhat.com/show_bug.cgi?id=432903
Edit the /etc/security/limits.d/90-nproc.conf file to remove the limitation:
/etc/security/limits.d/90-nproc.conf
* soft nproc unlimited