Reference10:Concept Voice Recording 2014
The innovaphone Voice Recorder application allows recording while the innovaphone Player application a comfortable search and playback of phone calls.
All kinds of calls can be recorded:
- Incoming calls
- Outgoing calls
- Calls from innovaphone IP Phones
- Calls form 3rd party IP-Phones
- Calls from IP-DECT phone sets
- Calls from analogue phone sets
- Calls from with mobile phones (mobility, forking)
- Calls done on a legacy PBX (soft migrations scenarios)
The solution requires an innovaphone PBX, the recording toll and two applications;
- a recording tool described in this document called “Recorder”
- a search and playback tool called “Player”.
The usage of the Player is not part of this description, a separate localized help and user manual is available.
While the recorder (this description) has to be installed by professionals and the maintenance is done by system administrations people (and therefore English wording and this description is good enough) the player is operated by End user and may be not digital native, skilled or knowledge base workers.
Note also that the setup of the player is a typical admin job and not described in the player manual.
Feature list
General
• Using an innovaphone IP-Phone set immediately after call end the recording can be listened using the phone. One feature key stroke and the conversation is reproduced and repeated endless (auto replay). This call can also be transferred or put in a 3 party conference (immediate sharing)
• Online Help and tooltips for application and setup
• Setup password protected, setup files are encrypted
• Recorder in Demo Mode (20 minutes) , Player for free
• Many recorder in one system and unlimited number of players
Recorder
• Recording of any type of calls direction
• Recording of calls from any device: IP-Phones (innovaphone and 3rt Party), analogue phones, GSM (mobility), IP-DECT
• Recording of calls from/to legacy PBX (smooth migration)
• Recording can be done in a logical gateway or direct from a innovaphone phone set
• Recording of encrypted calls
• Standard und thread call recording. If thread call recording is on after a settable time period (for example 5 minutes) a call will be automatically deleted. If the user calls inside the time period a code the last call will be saved. This marking to keep the recorded call can be done from any type of phone. If the phone is a innovaphone IP Phone the marking can be done also during conversation
• Storage of all relevant data including the time to answer for each call
• Detail protocol of each call, documentation of the entire call flow, not just the recording period but even previous and following one. Detail report on all call situations, transfer, call forwarding, pick-up, group call, conference etc. Also calls in waiting queues or announcements are reported with second accuracy
• Encrypted protocol data
• Display number of channels in recording with start timestamp
• Error and Event log files
• Email alert in case of master alarm
• Automatic backup (copy to mass storage archive)
• Automatic delete of records older than 2-99 month (not on archives)
• Recordings are saved as wave files, can be reproduced with any player
• Wave data integrity supervision
• File name contains primary data (Timestamp, Caller and called, direction, time to answer, UID)
• Counter of recorded conversations
• Data Link to player, remote control of the recorder from player
• Interface to external applications, via TCP or URL, recorder provides data for later retrieving. Player can be controlled sending commands to the recorder (3rd party)
Player
• Integrity of the recorded wave files are recognized and displayed
• Agent note, a Player displays automatically agent notes and can add text notes to each call
• Integration with iQM server, display of missed calls, possibility to recall immediately
• Naming of Players
• Month and Day filter
• Filter for internal and external number with wildcards
• Filter for incoming and outgoing calls
• View of oldest or newest call on top
• SOS mode can be switched on/off with just one click. If on all unnecessary key are hide, the newest calls are displayed on top of the call list and filters are switched off
• Selection of calls, one single call, more single selected calls, from to, all
• Online search and display, can be switched off
• Copy, move and delete of calls
• Move and delete operations are logged in centralized manipulation log
• Permissions
• Multiple selected calls can are transferred automatically in a playlist and can be reproduced
• Display record size
• Display number of records in playlist and actual play
• Jump forward and backward in playlist
• Jump to next/previous title in search result list if playlist contains just one record
• Marc record in playlist, select actual record and clear all others
• Play one title after the other in playlist
• Play a beep if record change in playlist (loop playlist)
• Repeat play (loop record), up to 4 positions, stored automatically
• Repeat play of all stored memory positions
• Display internal and external number with name resolution
• Display timestamp, time to answer an call ID
• Display System and Player status
• Display if local remote control interface is on
• Display of play was forced be recorder remote control
• Keys for Stop, Play, Fast Forwarding, Rewind, Pause and Eject
• Display duration record
• Display elapsed time or count down, switchable
• Original time elapsing display
• Progress bar adjustable, direct jump to selected position, drag and drop
• Start and Stop position can be marked an played in loop (selection loop)
• Volume control with audio meter and peek indication
• Delta level Indication (L-R and R-L meter)
• Overflow level audio meter
• Enhanced sensitivity for audio meter
• Attenuation left and right cannel adjustable
• Audio setup can be stored and recalled
• Audio level at maximum
• Levels are stored and set on restart
• Level meter with peek indicator for left and right cannel
• Mute
• Large additional display with call details
• Automatic decryption if files are copied
• Player can be limited to display just calls of one extension
• Communication with recorder, display of link status, last master alarm and cannels in recording
• Reset recorder from player
• Search an play on backup directories
• Operate as Media player, reproduction of audio format wav, mp3, wmp and video format avi, wmv, mp4 and mpg
• 1rst and 3rd party remote control
• Document security, manipulation is detected and displayed
Scenarios
Recording is possible on each logical Gateway and therefore on external lines (ISDN, SIP or H323 Trunks). In theory “external” is just a convention, even internal calls passing through those gateways could be recorded, but this is more a theoretical issue. An innovaphone gateway can also be used as a “recording” bar and introduced between a legacy PBX and the PSTN. Remember anyway that the innovaphone PBX must be activated and the Reporting tool is required.
Being recording defined on a logical Gateway opens different options, for example activate recoding just for a dedicated route. For example just for incoming calls or just for some outgoing calls. Typical examples for such a setup are business and private calls, where just business calls should be recorded. For example if a call is done using “0” as prefix recording is done, using “9” not.
Or normally (“0”) no voice recording is done, but if a user access to a trunk with a particular prefix (“9”), recording is on. This for example is widely used in selling contracts by phone (like mobile phone carrier do); they call the customer and if the customer agrees in the commercial proposal to extend or to “sign” the contract they will call back the customer again using another prefix and record now the conversation.
Recording rules can also be executed automatically because configured in the gateway setup. For example you can exclude certain user from recording or vice versa, doing recording just for some users. For example all calls to the financial operators are recorded, all other calls not. Or all users are recorder but the management not.
All that is a question of setup in then innovaphone gateway (and PBX) and not described in detail in this document, being standard features and described in many other articles (and being part of the advanced technical training).
Please note that recording starts when a connection is established and terminates when the connection is terminated. That means that eventual waiting situations in waiting queues, music on hold sequences calls etc. are recorded too.
Keep in mind that each extension that should be recorded must be active in the reporting, means require a recording license. Even if you operate a soft migration you must go up in the PBX to a dummy user with reporting on and back again down to the relay.
Notes: Recording can be done just in G711A on a logical gateway as endpoint. If you need to record internal calls they must always transit a logical gateway (with the media relay flag on).
The recorded files are in a wave format and can be played with a normal Mediaplayer, the delivered Player allows additional features.
The recorded records are stored in an indicated path and a copy of the records can be done automatically.
Errors and events are stored in a log file and alarms tracked; a mail can be send if an alarm occurs.
It is possible to limit the duration of the storing period; older files will be deleted automatically. This is to avoid disk full errors, keep in mind that this kind of systems usually works unattended all the time.
The number of player and recorder is unlimited.
Recording can be done also directly from the IP-Phone. Doing VR using the IP-Phone has the following advantages or disadvantages; it depends on your point of view and the scenario.
- CPU-Load: No CPU power from the PBX is required, a Phone has enough CPU-Power to do that and more, and therefore it becomes an extremely scalable solution. If you do not use an external WebDAV server but a CF anyway the PBX CPU has some load (playing WebDAV server for the Phone)
- All calls on the phone are recorded (not just those crossing a gateway), so even internal calls (basically everything the phone is doing).
- Al users working on the phone are recorded. This means also that each possible user on the phone must have the reporting license otherwise a call from that user will cause a major alarm.
- Transferred calls to other extensions are after the call transfer no longer recorded. In case of gateway recording it is different, until the call cross the gateway recording is done.
- If you mix both setup in a scenario you should avoid that a Phone is doing recording and cross a gateway doing recording too. If that happen recording is done in two points and you double for nothing disk space and resources (and confuse everybody).
- Only innovaphone IP-Phones IP2x2 series and “A”-types (like IP110A, but not IP110) can performing VR directly.
Switch on the recording has to be done in the phone setup file, there is no menu option. Mode information about that is in the online help of the recorder setup.
Standard Recording
Operating in the “Standard Recording” (STD) mode recorded calls are converted and saved after the call has finished.
A recorder has to operate in one mode (STD or TCR), a mixed scenario is possible using two recorders, setup in this case has to be done very carefully.
SRTP
Recording of encrypt conversation is possible, no particular setup is necessary, the system will decrypt automatically the media stream and store the conversation in unecnryptet wave files for further processing.
Thread Call Recording
Operating in the “Thread Call Recording” (TCR) mode only marked calls are converted and saved, all other calls are deleted automatically.
A call can be marked manually from the user or automatically from his innovaphone IP-Phone. A call can be marked during the call or after call, but within a defined time period (for example until 5 minutes after the call-end). Not marked calls are deleted while marked calls will contain the entire call, so from the beginning on (even if marking is done during or after the call).
Marking calls during the conversation can be done only using innovaphone IP-Phones while all type of phones can mark a call after the conversation. To mark a call after a conversation the user must call a XML object.
In a typical setup the user will hear a confirmation if he is marking a call, something like “the last conversation was recorded and will be saved” or similar.
If marking is done using an innovaphone IP-Phone during the call (pressing the redial key) audio or no audio can be played. For example an automatic advice like “this conversation will be recorded” or similar can be played.
Setup TCR
This paragraph discusses the different setups and aspects for Thread Call Recording. If you are not interested in those details skip it.
TCR require a XML (TCRec.xml included in the software package of the Last call recording feature, see Related Articles, see Related Articles, go to the article and follow the download http://download.innovaphone.com/ice/wiki-src#lcr ), you have to create a directory and copy the xml in, create a VM-Object in the PBX and insert those parameters in the recorder setup (TCR panel). The XML can be called directly or using the recording functions on the innovaphone phones. If called directly the xml will play the audio file Track1.g711a, if called through the recording function of the IP-Phone the file Track2.g711a. If the files are not present the user will hear nothing. A solution for the confirmation could also be to play just a “beep” if calling directly the xml. You could copy the beep.g711a file (for example from the VM) and rename it. A better option is record them using the universal track recording tool, see related articles at the end iof this page.
Some additional information if you use the recoding function of the innovaphone IP-Phone: Keep in mind that this function will not really recording the voice but just calling the XML (the recoding is done by the Gateway or the phone, but directly and not using this function). As explained the XML will play the file Track2.g711a if present, but to hear the announcement you have to use on your phone at least version 10.0887 or higher and switch on the flag “Two Way Media” in the Recording section of the phone setup. The rest is the usual one, if you setup “Mode=transparent” each call will flagged as “to record”, if Mode=manual you have to press the redial key to flag. No problem if the user presses more than one time the record key, just the actual call will be recorded.
The xml itself will terminate after playing the Tack 1 or 2, delayed for 2 seconds. If the user press the redial key in this way he will see in the display of his IP-Phone appear “Recording” for 2 seconds and has a feedback (even if no tone is played) that the conversation is flagged to record.
Last Call Recording/Repeat
See relative article.
Do not confuse this feature with the Instant Play (rescue mode) feature of the innovaphone Player.
Overview
The recording itself is done by the innovaphone gateway. In each logical gateway a recording path can be configured as a URL; that means that the voice will be recorded in a file, this file can be on a compact flash or on an external WebDAV server. The recorder application copy the recorded file, read out the reporting, combine both, and rename the file. The original file on the compact flash/WebDAV is deleted. The new filename is formed using date and time, caller and called user, direction of the call, the time to answer (ringing time) and the unique ID number. The recorder converts the file from pcap to the wave format and stores the converted file in a directory. If requested a copy of this record can be saved in a second directory (for example a SAN or NAS disk area). A maximum number of storage time expressed in month can be defined, older files will be deleted automatically. In this way no disk space overflow will be in unattended systems. Parallel to the payload (the wave voice file) also a XML file containing the reporting data is created, the name of the file is the same than the one of the voce and just the extension is xml instead of wav. That is basically what the recorder is doing; copy and convert recorded files, retrieve data from the reporting, renaming of the files and copy them to different destinations as well as keeping track of history.
The player allows searching and browsing of records, show the oldest or newest first, can filter the search etc. For example it can be displayed calls in any direction or just incoming or outgoing calls, or calls from a certain number or to a certain number, using even wildcards for quick filter options. See relative description for details. Once the calls a displayed they can be marked using windows usual methods (one, many, all, range, etc.). The marked files can be copy, past, deleted or played in a playlist. A record in the playlist can be marked and the player allows the usual operations of a windows media player. Looping and audio signal before playing the next record in the playlist is included as well as moving inside the playlist from one call to the other. If all that sounds complicated calm down, it is quite simple in using and designed for “users”.
The player can even operate in a mode called “rescue mode” or “direct play mode”. If switched in this mode the latest record is always on top. This is a typical requirement for an emergency center operator, he is interested in replay the last or lasted recordings in a quick and simple mode.
The player shows also the reporting details and generally the most important data of the conversation. If recorded files are copied also the relative reporting information is copied. Many player can be installed and work in the same moment in a scenario, while the recorder typically is just one. So the recorder is a kind of server and the player a kind of client. More recorders can be installed in a scenario and if necessary a player can be installed on the same PC where a recorder is working. Being the recorder always on usually it will be installed on a dedicated machine doing just that located in the server room.
But remember that the recording job is done as described by the gateway. So even if a recorder application is switched off voice recording is done. The idea anyway is not that the recorder is switched off and just sometimes switched on to retrieve the files. But if you must shut down the application or reboot or enter in setup, no data will lose.
The following diagram shows the logical interfaces between the innovaphone voice recorder, the innovaphone player and the rest of the equipment.
(*) = Option
The player main data source is the disk where the records are stores. There could be active many player at the same time, and in theory also more than one recorder. One player could monitor just one recorder, but it is possible to start more player on the same PC.
Requirements
Recorder
The recorder application requires a PC or server with Windows OS Win 7 or higher, also windows server 2008 (Windows 2003 server not tested) or higher is supported.
Disk space: One minute of conversation requires about 1 MB of memory. A lot, but a TB HD today is cheap and for example even a 500 GB Raid 1 external NAS is not real expensive. Typically a recorder should have a Raid system, but remember that the recorder is able to do also a security copy. The copy to an external security drive is possible because in many scenario’s customer has to archive records for many years. The recorder requires a NTFS file system (no FAT32), usually today a standard on PC.
Some examples: to store 1000 hours a 60GB disk is required, 100.000 hours require a 6 TB Disk, 200.000 hours a 12 TB Disk. On the one hand a Year has 8.600 hours, on the other recording 30 cannel always busy for 10 hours a day for 200 workdays requires 60.000 hour a year. Now if you have this workload (10 hours busy a day on 30 cannels) probably a 16 TB Disk for €1.000 is not a problem.
Remember that on minute require in reality less the 1MB (about 900kB) and it is stereo. Zipping the files reduce about 30%, not really a deal.
No particular memory or CPU speed is requested, standard editions are quite good enough. Invest better in a good quality because in professional environments those machines have to work for many years.
Voice recording requires a Version 10 innovaphone PBX and a Version 10 Reporting tool. No compatibility with older versions is possible. PBX and/or Reporting can run on a gateway as well as on VMware.
The recording of the pcap file is done by the PBX firmware and requires a Compact flash or a WebDAV server. The recorder software will detect those records and copy them on the real storage path. Therefore the storage requirement for the CF/WebDAV not real high (but remember always 1 Minute =1 MB, so if you must record 30 conversations for 30 minutes = 900MB).
Voice recorder and Player could run on the same PC as well one single PC can also be used for the reporting, recording, playing and webdav server (and PBX if you like). So anything on one server is theoretically possible.
The two extreme setups are:
- innovaphone PBX on the GW, reporting on the GW, pcap recording on the CF, recording application on a PC
- innovaphone PBX on the PC, reporting on the PC, pcap recording on the PC, recording application on a PC
Each combination between is possible.
Remember that the CF is a relative slow drive, you will note this if you copy a file from the CF to the local HD of your PC. Exact this file copy is one of the task of the recorder, even a critical one (so not a good idea do anything else in between). The result is that the copy of a huge file (a long conversation) or many files will virtually froze the recorder software. In reality the recorder is just hanging around and waits that the file copy is finally done. So a recording on an external webdav server will solve this, but the CF has the nice flair working even if all PC’s are down. Take your choices and live with them.
Player
The player application requires a PC with Windows OS Win 7 or higher, the Mediaplayer is necessary. All that on a standard office PC is installed and you have to do nothing in particularly. Require Framework 3.5. In theory also a Windows server 2008 could host the player, but in the server versions the media player typically is not installed and there are also different DLL missing. So if you have time or you are well Microsoft server trained face also that if necessary (normally not).
Legal Aspects
Please take extremely care about the legal issue: in most country voice recording of telephone calls is forbidden and persecuted by law as a crime. In some country it is legal in certain circumstances, for example you have to inform the caller that the call will be recorded. That can be done automatically (using for example a waiting queue) or “manually”, telling the far person that this call will be recorded. Of cause also this announcement should be recorded. In some country recording is legal without any announcement for certain services, for example in case of emergency calls or calls to the police. In most country authority like the secret service do not really care about all that stuff and do what they want, but this is probably not your case.
So inform yourself and the customer about the local legal situation. Using the recording tools is on your own risk and innovaphone will not take any responsibility, even not for eventual malfunctions. See also our general trading terms, valid even for this solution. If you have any doubt about legal questions in using voice recording; don´t do it, don’ use it!
Installation Sep by Step
In this and many other wiki articles everything you need to install and operate the product is (hopefully) described. Partners some time have the problem that they could not find a logical flow in the description and the do not realize what is important and what interesting, but not essential.
To help here a simple step by step instruction, all details and comments are in the other paragraph and, of cause, in other articles.
1. Check the Software version of your PBX, it must be 10 or higher otherwise do an upgrade or forget this recording. You PBX must be up and running and to test you need at least 2 Phones.
2. Check that you have a valid license for the recording, if not just a demo-mode is possible, after 20 minutes the recorder stop and you have to restart him again.
3. Your CF should be working fine, create a directory to buffer the pcap files (for example http://123.123.123.123/DRIVE/CF0/IF_REC).
4. Setup the recording gateway, see http://wiki.innovaphone.com/index.php?title=Reference10:Voice_Recorder/Setup#Gateway_Setup . If you want to do a test with internal phones you have to assure that in ca ll from one user to the other this gateway will be involved. Create for example a access code to this GW and flag Media-Relay. If you call this access code followed by the internal number ths should happen. Of cause if you have a real trunk the you will do all that using the relative GW. At the end of the story your call must passing the recording gateway, check it; open you PBX interface, click on gateway and calls: you should see that the call goes through the recording GW. A pcap file will created at the CF directory indicated in the setup of the gateway (the same one you create in pass 3).
5. Start up the reporting (on a xx10 GW or IPVA), it must be up and working, you should be able to see the reports of the call done using the recording gateway.
6. Create SOAP user, a blank empty user object called SOAP (or _TAPI_ or _whatever_)
7. Create a root directory where the recorded files should be stores (for example “c:\mytest\” or “G:\myExternalDrive\”).
8. Now create a directory and put the innovaphone_recorder.exe and the pcap2wav.exe in the same directory (this is done automatically if installation is done with the installer).
9. Start the application and open the setup.
Installation
While the Recorder works “hidden” for the user, the Player has a huge user interface. The Player is typically installed on one or more PC of users. Therefore for the Player more effort to design a foolproof interface was done. The Player description is available, please check the relative section in the innovaphone Wiki. Recorder and player applications are single executable file. The setup is stored in a xml file located in the same directory where the application is running; no registry entry is done; if you delete the directory where the recorder/player is in, the application is de-installed. If you like install on the same computer the recorder and the player application you have to create two different directories and copy the applications twice. Automatic execution is possible inserting in the auto start directory the recorder application.
Please note that the setup file is in xml format, but his content is encrypted.
The installation tool will copy all reqired files, if you install manually copping file note the following issues:
If you install a recorder application manually you must copy the “pcap2wav.exe” utility in the same directory!
Note: This utility “pcap2wav.exe” can be downloaded in the V7 application folder, access to a directory and download the “tools” Zip file; inside you will find the pcap2wav.exe. The recorder is not a service because there is a full user interface available. To ensure that the recorder starts up even after a boot put the application in your autostart folder. In the setup an option to start up minimized is available.
Before starting the recorder application check the following items on the recorder PC:
- the directory where the recordings should be stored must be visible and it must be possible to create subdirectories, try using the file explorer
- If backup is requested also a write access to the backup path must be possible (but it is not necessary to be able create subfolders).
- Access to the reporting tool must be possible, use a browser to check
- The access to the CF (or the WebDAV server) must be possible, try to map a drive and access to the directory where the pcap files are
Do the setup the innovaphone PBX, the gateway and the reporting.
See eventually also http://wiki.innovaphone.com/index.php?title=Reference10:Voice_Recorder/Setup#Recorder_Setup for a better understanding of the requirements.
If you do now a call which has to be recorded this call must be logged in the reporting tool and a pcap file must be created in the indicated url path. Go only ahead if that is up and running.
Now start the recording software and open the setup and set the values. An online help will explain the single parameters. Maybe it is also a good idea reading first the rest of this article.
The installation of the Player is similar just simpler. After installing start the application, enter the setup and that its. But it has no sense install or setup a Player without before having a working recorder.
On a single PC multiple Recorder and Player can be installed, simple install and run them on different directories.
CPU load
The power of the innovaphone CPU on the different gateway models is high enough to ensure the recording of all ISDN cannels (or the same number of SIP/H323 Trunk) on that gateway. If recording is done on a CF the innovaphone PBX CPU will be involved also in the copy operation (if recording is done on an external WebDAV server no CPU load of the PBX for copy is required). After the copy operation no more CPU power of the PBX CPU is required.
The reporting CPU (which is anyway the second core in case of a gateway or a separate CPU in case of VMware) has some small workload because the recorder checks each 5 seconds the reporting. Using the player will cause no workload for PBX, reporting or recorder CPU, so just the local workstation CPU power is require. Therefore the number of player is practically insignificant for any CPU load.
Logging
Recorder and the Player applications write an individual error log, this log is a text file and stored in the same directory where the application is. See online help for file names and description of the other files used by this applications.
The recorder can also write a trace file; if tracing option is switched on all operations of the recorder are logged in a file named “iREC_sys_log.txt”. Please not that this files become very large if the option is always on, and this file will not be deleted or resized automatically. The idea is not to keep on tracing all the time but to switch on the trace during the first period or in case of trouble checking. If enabled in the setup the player stores all special operations in a central log file. All copy, delete and move operations done using the player are in this way stored automatically in a central log file.
A “user operational” log file is in a central point and unique for all players installed. Here all user manipulations done using the player applications are reported, so copy or delete is traced. This file is named “iREC_Player_log.txt” and located in the “\TMP” subdirectory of the root recording directory. In this way all operations of all Player-User are visible at a glance in one single file.
Security
The setup of the recorder and player is stored in an AES encrypted setup xml file. Therefore the user cannot manipulate or read out setup values. The access to the setup can be protected with a password. If a user deletes the setup file the software assumes that this is a new installation and allows access to the setup without password. If the user enters the correct path for the recording the software read out a centralized password and it is not possible to save the setup without that password. There is no way to read out or decode the password and this means that if you, as administrator, forget the password you have to clear the centralized password and the setup of the recorder and re-configure all. Try to avoid that situation and remember your password.
The centralized password is in the located in the “\TMP” subdirectory of the root recording directory and named “SPlayer.xml”. It is also encrypted of cause.
The Reporting xml data string is even encrypt.
In the first column header of the player a looked/unlooked symbol is displayed showing the encrypt/clear file mode. If (using the player) a encrypt records is copied it will be automatically decrypt, while moving a file (cut and paste) will not change the original file mode. In this way a clear copy of a xml can be done from an authentic encrypted data string.
Voice Recorder operation
The recorder can operate in 3 layouts; minimized in the taskbar, viewing a small window or an extended panel.
Switching between small and large view is done pressing the “>” key, press “_” for minimize.
Start up
During start up the basic operational parameter are checked while the master alarm is disabled. The master alarm supervision is just switched on after about 20 seconds. This is necessary because sometimes network operation during start up fails, but becomes up in a second attempt. For example mapping of network drives fails frequently at the first attempt but once up they will remain connected without any problem. The sequence of testing is done by design and the software will not proceed in operation if a parameter fails but continuously try to fix it.
This initial health check during start-up is done in the following order:
- checking setup: try to understand if the setup parameters are reasonable and in particularly if the WebDAV drive or CF can be mapped. If mapping fails the “SETUP” lamp will be red, error message “Setup not o.k.” is viewed.
- checking reporting: pings the reporting, if ping is o.k. try to load a dummy page. If ping or dummy fails the “REPORTING” lamp is red, error message “Reporting Link failure” is viewed.
- checking to access to the recording directory (url): try to read out the indicated path, if fails “PCAP” lamp is red, error message “PCAP directory access fails” is viewed.
- checking if access to the storage path is possible: If reading fails the “DISK” lamp is red, error message “Store path fails” is viewed.
If in the setup no backup path is indicated this last task is skipped and the Backup lamp is grey. Otherwise the access to the path is tested, if access fails the “BACKUP” lamp is red, error message “Backup path fails” is viewed.
If a test is passed the relative lamp becomes green. If after start up 6 lamps are green (or 5 green and one grey) everything is working fine and the message “Normal Operation” is displayed in the System status line.
After 20 second the Master alert supervision is switched to active, an eventual error causes a Master Alarm (see relative section).
Normal operation
The check counter shows you how many times the recorder reads out the recording directory and checks the reporting. As you see al 5 seconds a reading attempt is done, if data are found further processing operation will start. This counter goes automatically to 0 reaching 9999 and shows you that the software is working and checking but has no further signification.
The counter “Channels in recording” shows you how many recordings are ongoing. The panel shows you the ID of each recording file and the initial recording time. In this way you can see how long a call is jet in recording.
If the call ends it will disappear from the list. If there are more records then default lines a scroll down will automatically appear.
If you click the innovaphone logo the software version is displayed. The version is also displayed in the headline of the setup.
Extended view
If you enlarge the window with the “>” key two additional panels appears.
The left one shows the regular normal operations, the right one the errors and basic messages (like Start-up). The messages displayed of the error panel are stored automatically in an error log file while the messages of the status panel only file if that is enabled in setup. Both windows can be cleared pressing the relative button. This clearage is just an “optical” issue; no file is deleted or similar. Both windows shows up to 100 entries, if entry becomes too large a scrollbar appear automatically. If “full” the oldest message will be cleared. On top the error panel can also display the last 30 Error reading out the error file.
Pressing the “<” key the windows will be resized again.
There is no operational difference between the different layouts. The recording application starts always with the small window stile.
The following picture shows two alarms, Reporting (because there where files without CDR records) and Software (because there was a license overflow).
License
The license model is based on user, so for each user a license is required. “User” is basically the number (extension) of a user, not the name.
If the recorder is installed between a PBX and a trunk line (soft migration) there will be just numbers. Remember anyway that even the recording must work and therefore for each recording user also a valid reporting licensed is required.
In start-up the recorder will read out the number of recording license in the PBX. If a record is detected and a number associated this number is stored and the license counter decreased. Same numbers will not decrease the counter. If a new number is detected and no more licenses are available the recorder will store this last record normally and stop further operations. Recording in this situation will be buffered on the CF/webdav directory.
The recorder shows the number of license loaded and the number of license used. After startup the “Lic” counter shows the number of license loaded, while the “Used” counter displays initially “0000” and increase if used.
In other word you have to avoid that overflow doing appropriate setup in the routing/PBX.
If an overflow occurs software alarm is triggered, the error log file written, the alarm signaled on the player if enabled, an alarm email is done, a warning triangle near the license counter appears etc. If you press the “LIC” button the right error table shows the actual status, the number of license, the uses one and the number (user) causing the overflow.
So if you do a correct setup and provide the right number of license a overflow should never happen. If due to an design error a license overflow happen you should proceed as following:
- Stop the recorder (he is anyway halted and doing no operations)
- Add the required right number of license or modify the setup of your PBX that just the right number of extensions will do a recording
- Start the recorder up again.
Setup
Open a separate window, see relative online help.
http://wiki.innovaphone.com/index.php?title=Reference10:Voice_Recorder/Setup#Recorder_Setup
Note: during setup the recording timers are disabled, this means that no normal operation is done. For normal operation the setup must be terminated (with or without saving).
Alarms
About 20 seconds after startup, and always during normal operation, alarms are detected from a particular master alarm routine. Some alarms are self-healing, others not. If an alarm occurs the relative source is switched from green to red, if an alarm disappears from red to green. You can simply test is, just shut down the reporting during operation and you will see that the reporting indicator becomes red. If you start up the reporting again the indication will switch automatically from red to green.
An alarm master routine will control the system and summarize the alarms. On the left side there is an indicator “Master alarm” and two buttons, “RESET” and “OFF”. While the alarms can toggle and appear and disappear, the master alarm once triggered will indicate that there was at least one serious error. The detail can be shown in the error log, but the point is that the master alarm shows you the correct operation in time and store the error event.
With the “OFF” button the master alert can be switched manually off. If the master alarm is switched off the “OFF” button will blink red to indicate this exceptional situation. A manual switch off of the master alarm could be necessary during setup or test, or simply to avoid receive alarm emails being anyway in front of the application or similar.
If the master alarm detect at least one error it will be switch on the Master Alarm status, the relative indicator will blink red, a warning triangle will appear and, if configured in the setup, and a warning email is send to the administrator.
The icon of the application in the taskbar is changed and a warning triangle appears on the recorder logo; also operating in minimized status the Master Alert situation is visible.
As explained the master alarm will not recover if an error disappears: to reset the master alarm the “RESET” button has to be clicked. Clicking the Reset Key the Master Alarm becomes again armed and will trigger again if an error is detected.
The single errors are partly described in the startup section while the “SOFTWARE” indicator will go into alarm if there is an unexpected error in the software. While some errors are expected and supported and will not cause such an error (for example “no files” if you browse an empty directory) others are not (for example if the decoding of pcap file fails). So while some errors could be an exception (like the failing of file conversation) others could be persisting (like “disk full”) or are simply bugs.
A particular expected, but not tolerable error is described in the next section.
Reporting time out error
Each extension recorded must have the reporting license active. If that is not (or of the reporting is switched off for a longer period causing loss of CDR data) the recorder got a pcap file with an ID number, but no CDR data for that file from the reporting. The recorder waits up to 120 minutes to receive valid CDR data, after that time he will give up and save and convert the file with incomplete data. If that happened the “REPORTING” lamp will switch to red and a master alert will trigger. Instead of caller, called number etc. a “U” (like “unknown”) is used in the filename. So if a file name contains “ .. _U.U.U_U_ ..” means that there was a reporting time out. The only usable data are the ID and the creation time of the file, that is the reasonable starting time of the recorded conversation.
The things goes even worst if there is a call up for more than 2 hours, because this situation is similar for the recording application: a record in recording is detected but there is no valid response from the Reporting for that record ID . After 2 hours the recorder try to solve the situation, switch on the reporting error lamp copy and rename the recorded file, but then will happen also a Software error, because the deleting of the pcap file will fail (because the file is jet in use). Remember: while “_U_” should not happen, “_U_” because of busy conversation should never happen. Therefore we recommend limiting the speech time to 120 minutes (the recorder trigger if the value is more than 121 minutes). That can be done in the main window of the innovaphone PBX, field “Max Call duration (h)”, put 2 in. To less 2 hours for conversations? Send us an email we will enlarge that timeout to your requirement.
Terminating
If you try to stop the application a warning message appears, if you confirm the recorder application stops.
Files
Voice files are stored a subdirectory of the indicated path in the recorder setup.
The files are Wave stereo files where the left channel contains one speaker and the right channel the other one.
There are two working sub directories: the directory “/TMP” contains the central activity log file where the player applications will report their activities (“iRec_Player_Log.txt”). The second is the directory “/REC”, it is a working folder. Both folders are created automatically. The recorder creates a subdirectory for each month, so for June 2013 for example a directory “2013_06” is created and all recorded files in that period will be stored there. Note that in the backup folder no subdirectory folder are created and therefore all files in the backup path are in the same folder.
The recording files are always a couple, one file contains the audio (in wave format, can be reproduced using also standard audio player) and an xml file with the same name containing connection data. Both files are anyway independent and our player handles automatically a single wave file as well as the pair with additional detailed connection data.
One goal of the recorder was to produce a wave file that contains all relevant data.
The format of the name of the Wave file is the following:
"Date and Time of conversation start" + "internal user" + "direction" + "external user" + "time to answer in seconds" + "serial number"
Example:
“2013_06_24_1638_39_o_0800102_7_75c1f48e909d31188fc00903306225f.wav”
Date: 24.06.2013
Time: 16:38
Internal: 39
Direction: o = outgoing
External: 0800107
Time to answer: 7 seconds
Serial: 75c1f48e909d31188fc00903306225f
The file “2013_06_24_1638_39_o_0800102_7_75c1f48e909d31188fc00903306225f.xml” contains the reporting data of this call.
Eventual notes are stored in a file named “2013_06_24_1638_39_o_0800102_7_75c1f48e909d31188fc00903306225f.txt”.
This file is AES encrypt, see relative chapter. If this file is copied with the innovaphone Player it will be automatically decrypt and becomes a standard XML file.
The player retrieves the name of the wave file and displays the data from the xml file if present, otherwise at least the data inside the filename.
If you like you can open the xml file even with an editor and see all the relevant data, much more then displayed using the player.
The player shows also the duration of the call (the recoding) and other details. See relative description.
Encryption
The setup files for player and recorder are encrypted, as fix key is used an innovaphone specific secret key. The notes are not encrypted while the reporting and security file (the .xml) is encrypted.
So the reporting and security files are encrypted (those ending with “.xml”) using again as default the innovaphone system key. This default encryption key can be replaced with a customer specific key. In the in the setup of the recorder can be defined a customer key. The only reason to define a customer key is to avoid that other customer can decrypt the files, a remote and strange, but thinkable situation.
If this is done in the Recorder also in all Players must be set this customer decrypt key. Be careful in handling that key, because if you forget the key you will lose all encrypted information. The Player can handle contemporaneously the default key and the specific key. There is no update procedure foreseen if you change the key.
Example:
After 3 month of default operation you decide to insert a customer specific encryption key, for example “MySuperSecret007Key”.
You modify also the Player and insert in the setup this new key. Now you will observe that all data, the one of the first 3 month and the following one, will be decrypt automatically correct; the user will see no difference.
After other 5 Month you decide to return to the default key (leaving blank the key field again in recorder and player). Anything is going well, all records are decrypted correctly.
After other 2 Month you decide to enter a key named “MyBrandNewKey”, doing setup of recorder and player. You will observe now that the data of the month period 0 to 3 , 5 to 7 and after Month 7 will be decrypt while Month 3 to 5 (the one with the old key) will be displayed without CDR data and status “unknown”.
Therefore think well about your key, basically once selected it should remain. If you have the list of all Keys you can of cause change it on the fly in a player and decode the records in the period.
External Applications
The recorder as well the player can be interfaced with external applications like booking or ticketing systems or similar.
The basic idea is that the external application will share common information in his database with the recorder and pilot a player. The user should be able to play a recorder conversation directly from his application interface.
In this chapter the interface is described. If you are not interested is such a feature you can skip this paragraph.
This description is done for the software developer of the external applications. No particular setup for the recorder or player is described, part of other descriptions.
For better understanding the description “hides” all other interfaces.
The “recorder” is a software solution running on a Windows “server” (can also be a simple PC). In the network there will be one or several “players” able to reproducing the recorded conversations.
Under “agent” in this description we understand operators working with the voice recording and using an external application.
It is possible to have a TCP connection between player and recorder but this is not mandatory because the player just access to stored data and read out setup file in the network. The number of player has no limit while the number of player connected to the recorder via TCP is limited to 100. That means that the external application can control up to 100 “agents” trough the recorder. But it is also possible to control a player directly; in this case the remote control has no limit.
Contact us if you have more than 100 agents with voice recording using an external application, we can easily extend this limit.
Principle and definition
This is the described scenario:
Recorder communicates with Player 1, Player 2 … Player x
The Application server communicates with the Application Client 1, 2, … xx
This description regards the TCP/IP interface in the following picture, the only one to build new from the application point of view.
Going on in the description as “Appclient” is intended the User frontend (“Application on terminal x” in the picture).
“AppServer” is called the server of the application (Application Server in the picture), so the server for the ticketing or booking system or whatever.
Keep in mind that just one AppServer can communicate with the Recorder while even each Player can be called even directly from the Appserver or an AppClient. Do not confuse: There are two ways to interface the voice recording system, via TCP and via URL. The smarter and better way is the TCP one. We describe both, read both because in the second section some concepts described in the first one are not repeated.
TCP/IP Interfacing
This is the preferred and smart way to realize the interface. All messages and command goes to one single interface as shown in the picture. The Appserver act as a TCP/IP “Master” and will receive from the recorder messages and can send commands to the single Players trough the recorder. So it is a 3rt Party interface, piloting single player using one single IP address. The “play” command for a certain player is send to the recorder (and not to the relative player).
If for example a AppClient wants that the Player starts reproducing a record the command flow will be:
AppClientX press the play key -> AppServer send command to the -> Recorder -> Recorder send a command to -> PlayerX
So the idea is that in the applications is a “Play” and a “Stop” button; if the agent press this button the recording relative to the displayed database record will start to play, pressing stop the play will stop. Therefore the applications database must contain the record name.
The problem is that the entire information about the record is available just a certain time period after the call end. In most of the cases the application session is terminated or a new one started. Therefore the link is provided in two times.
When voice recording starts, the recorder will send a first record to the AppServer in the following format:
!FRST!<Extension Number of the Agent>!<UID>!<Agentname>
<FRST> = indicate that this is the first (of two records)
Extension Number = the Phone number of the Agent
<UID> = a unique ID of the record
<Agentname> = the CN (common name) of the Agent in the PBX
Example:
!FRST!24!c03a55c2e909d311b6450090331b3e3b!Rossi
where “24” is the extension number of the agent, “c03a55c2e909d311b6450090331b3e3b” is the unique “serial number” of the record and “Rossi” the name of the agent.
Just the filed “!FRST!” has a fix length, all the others not; the single field therefore has to be separated searching the “!”.
At this point the applications probably store this information (number, ID and Name) in his database or buffer this info until the Agent has his client ready or similar. Important is that the database record of the application is linked to the record UID.
Basically it is necessary for later data processing that the application server knows the name of the player (in our example “Rossi”). The simplest way to do that is giving the extension in the PBX the right common name (the same name than the application user name). If that is not possible (for example because the application has other items to identify a user) the application has to hold a cross reference table: application user name 1 = recording user name 1 etc. Consider also that not necessarily a record is played only on the player of a certain agent; recording for agent 1 can be required to be played on work station agent 2.
When a call has terminated, the record converted, saved etc. (means, ready to be played) a second record is transmitted from the recording server to the AppServer:
!LAST!<Extension Number of the Agent>!<UID>!<Track>!<Agentname>
<Track> = Name of the recorded file, to transmit later to the recorder to play.
Example:
!LAST!24!93adee5ee909d311b6450090331b3e3b!2013_09_24_1107_39.o.024_1_93adee5ee909d311b6450090331b3e3b.wav!Rossi
You see that the UID is in again and on the same position; even the extension number and name is repeated. In this way the application can easily search the UID in his database (and the name and/or the number) and when found complete the record entry with the record name (in the example 2013_09_24_1107_39.o.024_1_93adee5ee909d311b6450090331b3e3b.wav). You see the UID is also part of the record name and in theory the original “stand alone” UID in the application database is no longer required. Therefore a overwriting of the UID field in the application database with the record name is possible.
Note: In the actual version a reverse search is not implemented (that the player told the application to display a record). If implemented in the future the search string will be the entire record name and not just the UID, therefore the stand alone UID has no further sense from the voice recording point of view.
From the timing point of view the first message is critical because the UID has to be written until the Agent has opened his application record and that can be even a short time.
The last string is not very time critical because the retrieving of a record and a update can be done in every moment.
The recorder software has a small send buffer (about 25 recordings) where the messages will be buffered if the AppServer is not reachable or the link is down or. If for example the AppServer is switched off and later on again, the recorder will send to the AppServer the FRST and LAST messages buffered during downtime. The Buffer is a Fifo (first in first out) but not an Overflow-Fifo; if full not the oldest but simply all newer messages are lost. The buffering is done just to buffer short time periods, for example to allow a restart of the AppServer PC without losing information (but not for a “offline” operation).
In the application software design should also be considered the possibility that the AppServer receives a First record, is then stopped, and receives the second one after the restart.
That’s all regarding the recording part, now we discuss the remote control of the player.
Remember that a name can be assigned to a player, for external applications that is mandatory. The name can be defined in the player setup; a good idea to simplify the scenario is to give the player the common name of the phone. So in our example we will name the player of the agent “Rossi” just “Rossi”. Not a must of cause, you can call the player of Rossi even “myFirstAgent” or “1234”; but in doing so the external application must store a table where “Rossi” is mapped to “myFirstAgent”. To avoid such complication we suggest unifying the names and assigning to the phone user, Player name and application user in the same one.
To force a certain player to reproduce a certain recording the AppSever has to transmit to the recorder the following command string:
TRAC!<PN>!<Track>
<PN>=player name
Example:
TRAC!Rossi!2013_09_24_1107_39.o.024_1_93adee5ee909d311b6450090331b3e3b.wav
The Player with the name “Rossi” will start playing the record 2013_09_24_1107_39.o.024_1_93adee5ee909d311b6450090331b3e3b.wav.
There are not foreseen any error messages, if for example the player will not find the record or is switched off nothing will be transmitted to the AppServer. In case of record not found on the Player a blank result will indicate the fail. If the recorder start reproducing a record a green “RC” label (for Remote Control) near the play symbol shows that a remote control message and not a manual play key press has started the reproduction.
There are available also other commands:
STOP (Stops the actual play)
EJEC (the actual record is unloaded, the player stops)
PAUS (the actual record is paused)
PLAY (the actual record is played again)
Example:
EJEC!Rossi
Will force the player Rossi to stop the reproduction of the track and go in an idle mode.
Generally it is not necessary that the AppServer takes care about the actual Player status or observe command flows. If the Player is for example playing a track and the application server send the command to play another track he will Eject the actual track and play the desired one.
Note also that the player can work minimized in the taskbar and play “invisible”, so the user will see just the application. In the setup of the player can also be defined an automatic popup if a remote play is received and automatic hiding if an eject-command is received. If this is enabled in this way the player is minimized in the taskbar and the user works just with the application screen.
The TCP/IP link between recorder and AppServer is based on the fact that the recorder acts as a slave while the AppServer act as a Server. In the Setup of the recorder the IPadress and the port of the AppServer has to be indicated. The recorder expects on the same port where he is transmitting the response from the AppServer.
The recording server performs a keep alive with an interval settable in seconds. The keep alive message send from the recorder to the AppServer each xx seconds is:
RecKA
The message has no further meaning and can be thrown away from the AppServer. If any command is received from the Appserver the keep alive will be skipped and repeated after the, in the recorder setup indicated timespan. Unknown messages form the application server will be throw away from the recorder server.
URL Interfacing
URL interfacing is similar to the TCP one except the player interface. The two methods of interfacing are in alternative, so the application server has to do one of the two (no mix possible).
If this option is enabled in the recorder server setup the first and last messages will be transmitted as an extension of a URL statement. The root URL can be defined in the recorder setup.
If the setup for example contains the URL sting “http://zz.aa.bb.xx/myApp/myapp.php “ (note the blank at the end, any character is possible), the recorder will perform the following command if the recording starts:
“http://zz.aa.bb.xx/myApp/myapp.php !FRST!24!c03a55c2e909d311b6450090331b3e3b!Rossi “
The “!LAST” command is transmitted in the same way.
If selected URL interfacing it is not possible send commands from the AppServer to the recorder, so the Appserver just receives URL commands from the recorder.
To force a player to reproduce a track the player has to be interfaced directly. In the player has to be open a remote control port (defined in the player setup); messages coming to this port will be processed. So addressing a single Player is done sending a command to a specific IP- address and port. Therefore probably in the AppServer a table “Name or Number /IP-AD+Port” has to be stored. So the URL Interfacing is from the player point of view a 1st party interface; so each single player has his own remote control interface.
Note that also the application client (or any other software, for example a browser) can do a player remote control.
The command set for the direct remote access to a single player is similar to the one of the recorder:
<IPLTRAC><PN>
There are also available the commands
IPLPLAY
IPLSTOP
IPLEJECT
IPLPAUS
Example:
IPLTRAC2013_09_24_1107_39.o.024_1_93adee5ee909d311b6450090331b3e3b.wav
will force the player to reproduce the indicated record 2013_09_24_1107_39.o.024_1_93adee5ee909d311b6450090331b3e3b.wav.
Basically the interface of the player is anyway a TCP/IP interface and no mini Webserver is integrated. But a “Get” from an browser will be detected and decoded, but no answer occurs. That means if you try to launch a command with a browser it will work, but the browser will show you “no page”.
Example:
The Player runs on a PC with the address 192.168.0.14 and as the remote control port is indicated port 9090.
If you post in your browser “http://192.168.0.14:9090/IPLPLAY“, the player will start to play the marked record.
If a port for direct remote control is switched on a “RC on” label is displayed in the player status line.
General Note
The first UID will be detected form the recording using the SOAP interface in the PBX. Therefore all Agents has to be in the same group that the SOAP user object.
Example: You have a simple user object called “MYSOAP”, put that object in an active group called “Recording” and now put all you Agents in the same group.
Remember that basically recording is done even without the group stuff. So the group is just required to detect the UID in “advanced”. But there is also an additional benefit; the reporting has less stress because the recorder will query the reporting just at the end of the call (knowing via SOAP when the “end” is) while calls without the group are detected as “finished” because the reporting has a valid CDR record, and so the recorder polls each 4 second the reporting on active calls. That means that it is in any case a good idea put the agents in a group, even if no external application is running.
Related Articles
Reference10:Player_Voice_Recording