Avaya CPSEE_TSP500 - Manual (Page 202)

Appendix 12 Integrated Recording
Page 12-8 Version 4.0 CPSEE_TSP500 User Guide
This document is confidential and proprietary to SER Solutions and is not for external use.
The mount point for the shared drive is /home/EncWorkingData. A subdi-
rectory EncImport is created for storing the audio files created by the TSP.
Disk Monitor Daemon
The daemon process (rec_watch.exe) must be started. Its purpose is to move
the audio files from their temporary storage on the RAM disk to the shared
drive on the RecServer. This daemon process will establish a socket connec-
tion with the TSP. This connection will allow the TSP to control the move-
ment of the audio files from the RAM disk to the shared drive on the
RecServer.
This daemon process is referred to as RecWatch in this document. Rec-
Watch is integrated in the TSP500 software installation. Because it requires
the IP address of the RecServer, the auto-startup features are disabled at
installation (similar to the TSP500 application), but can be activated by the
installer.
Recording Resource Manager
A remote node, the Recording Resource Manager (RRM), sends recording
control messages (Start, Stop, Pause Resume and Delete) to the TSP500 using
CPS Enterprise Edition SIP. Protocol C messages arrive at the TSP500 using
the standard CTI link. However, Call IDs generated by the RRM process
will not be synchronized with the Call IDs generated by CPS Enterprise Edi-
tion SRM. This is because the RRM is tunneling through the CPS Enterprise
Edition SIP, and not interfacing with the CPS Enterprise Edition SRM pro-
cess.
To prevent conflicts with the Call ID generated by the SRM, a fixed Call ID
(10996) has been defined for exclusive use by the RRM. Support has also
been added for handling a M_HEARTBEAT message from the RRM. This
heartbeat is in addition to the heartbeat generated by CPS Enterprise Edition,
and is distinguishable by the fixed Call ID allocated to the RRM. Once a
heartbeat is received from the RRM, the TSP500 will monitor the receipt of
future heartbeats. If it notices the loss of heartbeats from the RRM, it will
assume the RRM is down and terminate all current recordings. If a subse-
quent M_HEARTBEAT or Recording command is received from the RRM,
the TSP500 will assume the RRM is back up.
The RRM talks to both the TSP500 and RecServer. It is responsible for issu-
ing recording commands to the TSP, and sending notifications to the Rec-
Server as well as the data associated with the audio recordings.
A protocol C message M_RECORD_CONTROL has been defined. This is
the only message sent from the RRM to the TSP.
The Call ID field used in this message type is the fixed (reserved) call ID
(10996) Keeping track of multiple recording sessions will be handled using
the Agent ID field in the message, and not by the Call ID.