Reference10:Concept Voice Recording 2014

From innovaphone wiki
Jump to navigation Jump to search


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 records are stored in a first step on the Compact flash or WebDAV server and processed then form the recorder tool.

Voice recording can be done on a logical or fiscal gateway (BRI, GW, SIP etc.), and therefore all kind of audio traffic can be recorded. Technically spoken a gateway is doing media relay and writes the audio data to the WebDAV or CF.

The second way to record is recording directly from the Innovaphone IP-Phone. In this case the phone itself writes the audio data to the CF or WebDAV server.

See the “Scenarios” for further details.

The solution requires an Innovaphone PBX, the reporting tool 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.

IMPORTANT: All users that should be recorded need the REPORTING! We recommend reporting for all user, see chapter “Requirements” for further details.


As webdav server just the innovaphone webdav server (on a GW, IPVA or innovaphone LinuxAP) is supported.

The recorder use HTTP and HTTPS access and not a webdav protocol to access.

The Recorder must be physically and logically “nearby” the main PBX. “nearby” means in the same location (not remote), in the same network and also on a physical machine.

Our solutions are tested on single physical machines and we are not able to support the huge amount of virtualisation software (and there edition and version).

We recommend to user normal Windows software, so not a “server” edition.

Disable "Power Saving Mode" on the windows machine that runs the recorder application, so the SOAP connection it's not interrupt.

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, but not recommended. Please note that a working Webdav is mandatory, otherwise records will be lost! If recording is critical please define a second logical GW with recording and record on an independent webdav too as backup (you have to clear that drive manually to avoid disk full). Do never use the Flash memory ad webdav.


You require a PBX version 11 or 12.

For Version 13 see section known problems !


The recording feature requires the linux-platform-based innovaphone Reporting. Please update your platform to the latest Hotfix. Minimum Build 10043 is required.

Note: VoiceRecording (2014) will not work with the new V13-reporting.

Each user for whom calls are physically recorded (by creating a pcap file for the call using the Record to (URL) feature) must have reporting enabled and hence requires a reporting license. Although the recorder will discard all physically recorded calls if the user involved has no recording license, it still needs the CDR information for the call (without this information, the recorder can not determine the user the recorded file belongs to). If the recorder needs to process files for which no CDR is available, it will malfunction.

So generally, we recommend that all users in the PBX should have the reporting on as this is the simplest solution. However, if this is not feasible, then all users for whom recording pcap files are created must have reporting. Please note that if you configure the pcap creation on the trunk gateway all users that possibly could do calls through this trunk (which practically means: all users) must have recording. To limit the number of recording licenses you need to configure pcap creation on the endpoints (i.e. phones) rather.


This document describes Build 1134.

Application package can be retrieved from our download page.

The recorder and Player application was tested on Windows 10, win 7 or higher should also be fine, framework 4.5 is required (no Windows XP).

Disk space: One minute of conversation requires about 1 MB of memory if stored in Wave or Pcap Format. The wave voice data is not pure PCM, but a G.711 format in a wave container. PCM requires about 2 times much more disk space and is not used for storing. The audio files can also be encrypted. Encryption would double the required disk space.

The recorded conversation is a stereo file where the external caller is on the left channel whiles the internal one in the right channel.

It is possible to down mix the conversation to mono; this would save about 50%.

It is also possible to compress the audio data to mp3.

The following table shows the required disk space for one minute of conversation:


Example: 500 GB Hard disk, mp3 compression without encryption -> 1.389 days = 3,8 years of conversation

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 11 innovaphone PBX and a actual Build of the 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/mSATA/WebDAV not real high (but remember always 1 Minute =1 MB, so if you must record 30 conversations for 30 minutes = 900MB).

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.


Recording can only be done using G.711, G.729 or G.722 (Build 1134) codec.

Note: if you update an older recorder version to build 1134 delete first the file pcap2wav.exe in the directory where the recorder run and/or in the log path of the recorder.


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 4.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).

In theory it should work on any CPU, the Player was tested under Win7 32BIT, Win7 64Bit and Win8 64Bit and Win10.


The license model is based on user, so for each user to record a license is required.

The current implementation allows a recording of objects of type user or executive. Recordings on other objects will be discarded.

So in short: Per recorded user or executive object you need to have

  • one recording license
  • one reporting license

In start-up the recorder will read out the number of recording license in the PBX. After that the recorder will read out all users and check if a user is in the recording group (defined in the recorder setup). If a user with that group is found one license is counted down. If there are no more license but user in group detected they will be skipped. The recorder shows how many license where detected in the PBX and how many user are in the recording group. If there are more users than licenses a warning is show.

Remember that just users in the recorder user table are recorded; all other records are automatic deleted! This can be usefully if for example for internal reasons not just the user to record passes through the recording gateway but also others; not being in the group the records will be destroyed. But of course this will cause senseless PBX CPU workload because a recording anyway is done, just the recorder will delete after the files.

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!

Feature list


• 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


• 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 and 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)

• Mark record during a conversation on the IP-Phone (build 1077)

• Https from Build 10087 on

• Slave sites from Build 10089 on

• G722 Codec from Build 1134 on

• PCAP recording from Build 1134 on

• Work as a service from Build 1134 on

• Work as http player server and/or PCAP to Wave/MP3 converter from Build 1134 on

• Work as a service from Build 1135 on


• 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 channel 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 channel

• 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 channels 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

• Browse last played records (build 1071)

• Browse marked records on this player (build 1071)

• Browse marked records in a system wide available directory (build 1071)

• Mark records on player and for system wide access (build 1071)

• Copy records marked in a player to the system wide available directory (build 1071)

• Write a central log for all player listening’s (build 1071)

• Work over http connections (build 1074)

• Limit view to a list of extensions (build 1077)

• Play PCAP files (build 1134)

• Double password for unlocking (build 1134)


If 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 on a central point

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 recording 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/G729/G722 on a logical gateway as endpoint. If you want record internal calls in this way calls must always transit a logical gateway (with the media relay flag on).

Recording with the IP-Phone

Recording can be done also directly from the innovaphone IP-Phone. If switched on all calls from and to this phone are recorded, there are no recording rules. Calls could be stored in different files, because a new call means also a new file. If for example a phone put on hold a conversations and establish a second call this second call will be stored a an separate file.

Doing voice recording using the IP-Phone or using a Gateway has advantages and disadvantages; it depends on your point of view and the scenario.

Here some issues to remember:

Recording on a gateway is like the old “ISDN Recording”: anything passing that interface is recorded. That has the advantage that any type of endpoint (IP, 3rt party, Dect, analog etc.) will be recorded. The disadvantage is that internal calls are not recorded. Also the CPU load of the PBX will rise while recording with an IP-Phone has nearly no influence.

Recording directly from the Phone has the limitation that just innovaphone IP-Phone are able to doing that. Only innovaphone IP-Phones IP2x2, IP11x, IP241 and IP240A with bigger DRAM ( can performing Voice Recording directly. 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).

In the V11r1 IP recording on the phone can just switched on or off in the setup, not from the user. In V11r2 recording can switched on and off by the user (similar to the 3party version).

Note: The recording described here does not require a phone 3 party conference; therefore a 3party conference is possible on the phone while Voice Recording 2014 is running.

Recording Modes

Standard Recording

Operating in the “Standard Recording” (STD) mode recorded calls are converted and saved after the call has finished.

Note: A recorder canoperate just in one mode (for example "Standard"). Mixed scenario are possible but require two or more recorders, the setup in this case has to be done very carefully.

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 ), you have to create a sub-directory TCR in your PCAP recording directory and copy the xml in, create a VM-Object in the PBX and insert those parameters in the recorder setup (TCR panel). Example: Your PCAp directory is, therefore the directory create is is 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.

Please note that the directory where the PCAP files are stored can be „the same“ than the one using „normal“ recording. The TCR XML is just a subdirectory of the PCAP recording directory!

Delete Records

Build 1188

A user can skip (not store) some conversations. This is done using a similar mechanism used with the TCR. If at the end of the conversation a file is found this record will be deleted. Therefore it works only if this file is created during the conversation. This can be done calling the XML TCRec.xml (with a feature key, the recording feature of a innvaphone IP Phone, putting the actual call on hold and call the xml or using an external application). The file has to be created in the recording directory/TMP.

File format: TCA-XXX_XXX.txt where xxx= the agent number.

Example: TCA-1234_1234.txt -> the record of the actual conversation of the agent 1234 will not be recorded.

The field itself could be empty, but observe that with Linux at least one character should be in.

Please note also that the time of the reporting, PBX and webdav must be the same. The Feature works also with the (old) CF. If a record is skipped because of theis feature he log will show the message “User Mark Record to delete found TCF=” and the Agent number.

Random recording

The recorder can work in this mode also as an alternative to the Standard- or Threat call recording. Random recording will record just a sample of calls on normal Agents (User), typically for quality check purposes.

The system allows record just each x call where x can be set in the setup. The system can even record just each y call for an agent. Only “to recording” calls are counted, not calls in general.

Example: “Record in System just each 3. Call”’: the system will store one record and then skip the following 2 one.

Example: “Record for a Gent just each 2. Call”: for each agent one call will be recorded and one not.

Both setups can be set isolated, but combined (3rd in system and 2nd for a agent) the system will first skip 2 calls and then for the specific agent skip each 2nd one.

Calls typically are not foreseeable especially if they are more agent involved and therefore it is for a single agent a “random” recording.

This feature requires build 1071 or higher.

PCAP Recording (1134)

If switched on the recorder keeps the native PCAP file format. While encryption is possible also in this recording mode no down mix to mono or single cannel recording (just the internal caller) id possible, of cause MP3 can also not be switched on in this recording mode.

Please note that this mode is mandatory if the recorder works as a service. A second recorder working in foreground can convert PCAP to wave or MP3 and also process the additional audio down mix. See relative articles.

Manual/Transparent/Optional recording

V11r2 (in the Phone) is required.

If the recording is done using a innovaphone IP Phone there are 3 recording modes possible:

- Manual: the user switch recording on/off using a Feature key

- Transparent: recording is always on

- Optional: recording is on by default but the user can switch it off using a feature key

The manual and optional mode is widely used because the operator can switch on and off recording during a conversation. For example if the customer want to buy the operator starts recording and give the advice that from now on the recording is on (by the way: that can be played also automatically modifying the last call recording). Switching off recording is usefully also if for example during a conversation a secret info (like a password) is stated and should not be recorded ad all.

The Recording link (url) to the Webdav or CF is defined in the user setup:


The mode is selected in the "recording" section:


Note: The recording described here does NOT require a phone 3 party conference; therefore a 3party conference is possible on the phone while recording is running.

Manual recording with announcement

(build 1198)

If a customer want to start and stop a recording this can be done using a innovaphone IP-Phone as described in the previous chapter.

This chapter described how to solve if on top there is also the requirement to play automatically an announcement at the beginning of the recording (typically something like “We advise you that this conversation will be recorded…”).

The problem is that audio can be reproduced only if you set “Dialup Recorder” in the phone, but doing this there is no PCAP and therefore CDR information. If you select “HTTP” then there is PCAP information/CDR information but no audio.

The workaround is that you select “Dialup Recorder” but as destination do not put in a XML or WQ but a trunk and then the XML or WQ. The result will be a call to the (recording) trunk and then to the XML/WQ.

Set up the Recording to Dialup Recorder in your phone


Example: You have a XML or WQ playing first the required announcement and then silence, this object has the number “76”.


Example for the second announcement:$coder?coder=g711a,g711u,g729&repeat=true You can download the silence announcement in our voicemail folder.

Set up a trunk object


In our example with the number "57" with the option “automatic hangup” selected pointing to a GW,


in this GW the PCAP recording is done.


be sure to choose Media Relay On:


and create a Route:


Set in the setup of the Recorder, tab “General” both numbers


and switch on “Convert to mono”.

Limitations: it is convenient (but not a must) to convert the call to mono and save some disk space because in this operational mode the announcement is on the left channel and both party on the right one.

Please note that also the call direction (in or out) is always flagged “out” even on incoming calls.


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.

Last Call Recording/Repeat

See relative article.

Do not confuse this feature with the Instant Play (rescue mode) feature of the innovaphone Player.

Working as a Fileserver for the Player

In this operational mode the recorder will not record any file or communicate with the PBX or the reporting but just act a http Fileserver for the innovaphone Player. The application can run in this mode on the same PC than the one of the recording, in huge scenarios for better workload share it is better to separate the two applications. For more information see the article “Player over http”.

Working as a PCAP converter

The recorder can also keep the original pcap file format; this is mandatory if the recorder work as a service. The player is able to reproduce even files in PCAP file format.

If a recorder works in PCAP recording mode no audio down mix to mono or single audio cannel is possible. Please note that encryption of PCAP can be done in the recorder.

If the customer wants down mix features and/or wave or mp3 files a recorder can be started in converter foreground mode doing this.

Similar to the Fileserver mode the recorder will not perform any recording task or communicate with PBX or reporting. Please note that the same application can work as a PCAP recorder and fileserver at the same time, the application has not to be started twice; in large scenarios for a better workload sharing anyway it is possible to start the two modes even on different PC´s.

In this working mode the recorder scan periodically all sub directory of the storing directory and if a PCAP file is detected it will be converted to Wave or mp3 and the down mix options will be observed.

If the original PCAP file is encrypted also the resulting wave or mp3 file will be encrypted. If the original PCAP file is not encrypted encryption is only done if the relative flag in the setup of the converter is switched on.

The idea of the converter mode is that the application is always on; the recording service provide the PCAP files and performs all the other tasks like the communication with the PBX, the file copy from the CF/mSATA/Webdav, renaming, encryption, TCR etc. while the converter in a second step convert. Anyway it is also possible start the converter in a second moment; of cause if there are many files to convert it will require some time until all PCAP files are converted. Therefore a typical situation is that the converter runs always, but if this operation fails (or example after a restart of the PC where only the service will start automatically or a logout of the user) the missing work can be done in a second moment or form another PC.

For the operation of the recorder as a service see relative article.

Command line arguments

The recorder application “innovaphone_Recorder.exe” can be started with command parameters.

This option is only required if the application is started as a service (se relative article).

The order of the parameter has neither influence nor eventual characters between.

The Setup parameters itself are not case sensitive, but the value (the path itself) is case sensitive.

recpath=c:\abc  is equal to RECPATH=c:\abc  but not equal to <> RECPATH=c:\AbC

Example for fine imputs:

innovaphone_recorder.exe recpath=c:\myiqmdir\ setup

innovaphone_recorder.exe /recpath=c:\myiqmdir\/setup

innovaphone_recorder.exe recpath=c:\myiqmdir\ -setup

The parameter “Setup” forces the application to open just the setup. No timer or interfaces are started. An exit of the setup will terminate the program.

The parameter “recpath” defines where the setup is stored.

The parameter can be inserted in the cmd box (DOS like) or using a batch file. Please note that the cmd should be executed as administrator (windows 8: press the windows key, enter cmd and select pressing the right mouse key “execute as administrator”).

A batch file can be created easy, open the editor and enter the command string, for example

innovaphone_recording.exe setup

Now save the file as a batch file, for example RecordingSetup.bat in the directory where the Recorder is. If you click the file the application will start just showing the setup.

Note also here that it could be necessary to start the batch file with the administrator rights. Of cause you can make a shortcut for example to the Desktop.

If you start the recorder as a service it is also usefully being able to stop the service and start the recorder in foreground using the same setup, therefore just running in foreground, mainly for trouble shooting and maintenance reasons.

Also in this case you can start the recorder in a command line indicating the setup path or create a bat file.

If you have to start more recorder on one single PC (for example a recorder and a recorder as a fileserver) it will be also necessary indicate individual setup path using a command parameters.

Also the batch files should be started with administrator rights. To start an batch file with admin rights a little trick must be applied. After writing your .bat file, create a shortcut and put it for example on your desktop. Now press the right mouse, select property and select “Advanced Properties”.


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 voice 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.

Installation Step 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 course, 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. Your 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

4. Setup the recording gateway, see . If you want to do a test with internal phones you have to assure that in call 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 course 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. Start the application and open the setup.


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 required 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 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.

For installation as a service see relative article.

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.


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 note 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.


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.


As most application also the recorder requires a correct date and time. But also the PBX Date and time must be correct and the same as the one on the recording PC.

Basically obviously, writing a file all file data should be correct, and also the CDR ticket data should.

So verify that both, PBX and PC have always a correct and synchronized date and time.

Voice Recorder operation

As a normal application 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.

For operation as a service see relative article.

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. 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.
  • 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).



Open a separate window, see relative online help.

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).



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

Basically calls that should not be recorded should not be recorded even on the CF, this is desirable, but not always feasible.

In normal operations the recorder is connected to the PBX with a SOAP link and can so detect when a call is finished and the party involved. If there is a PCAP file and a SOAP connection fine, because in the very first step anything is clear and the recorder can decide to save or to just delete the PCAP file. But there is also the possibility that the recorder starts up later and “found” PCAP files stored in the meantime. In this case there could be or even not any SOAP information, if the call terminated before the recorder starts there will no SOAP info. Therefore if PCAP files are detected without any SOAP indication the recorder ask the reporting if there is any record to that PCAP. If yes the processing will follow the normal way, stored or just deleted. But if the reporting has no data there are more possible reasons. CDR data or the reporting could be “late”, so maybe in a few seconds data are in and processed. Or the reporting was just temperately busy or offline, a good idea is wait and try later again. Exactly that the recorder is doing, from build 1070 on the number of trial can be set in a range from 5 to 9999, default value is 5. On earlier build this value was set fix to 1444. Arrived to zero the call is deleted. Deleting recorded calls not knowing about the party involved is critical and therefore the recorder is so carefully.

The real problem is if in a system there are extensions creating PCAP files, but they did not produce CDR tickets / have no CDR license. In this case after a start-up each stored call will produce a PCAP file, the reporting query will fail and the recorder will try later again. To avoid large quantity of PCAP files and slow call processing switch on the reporting feature on each extension creating PCAP files. Or avoid that extension without a reporting creates PCAP files.

Receiving an answer form the reporting the recorder understand immediately the involved parties and can delete the file if the caller was not an Agent or store it.


If you try to stop the application a warning message appears, if you confirm the recorder application stops.


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"



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.


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.


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.

Audio encryption

The security system is based on AES encrypted xml data file. That file contains the CDR data but even the security parameter of the audio file. Therefore if an audio file is manipulated (changed in any way) that will be detected and show in the player (the “manipul” red label is on while off and the green “original” on if the audio file is the original one).

That means that the audio file itself is not encrypted, some customers want reproducing the file even with other media player.

But there are also customer that have another view and are worried about for example that such an audio file once copied is no more controllable. Or they simply do not thrust that the security features described works fine.

Therefore also the audio file itself can be AES encrypted if that option is switched on in the recorder. The player will detect automatically that an audio file is encrypted and reproduced it anyway. Here how a player shows a detected Audio encryption:


Of cause an encrypted audio file can be reproduced just with the innovaphone player, no other media player will work.

Please note that any innovaphone player can do the decryption, so if you want to assure that just “your” player can reproduce you have to define a customer decrypt key in the recorder (and player).

The recorder shows switched on encryption in the main view (see picture above).

Audio encryption has also disadvantages, recorder and player has more workload and require more disk space; in fact size of the audio files will double if encrypted!

Audio compression


As default the files are saved in the wave format. More precisely in G711 because wave is a container format and pure PCM would require near the double disk size than G711.

PCAP (Build 1134)

A recorder can save files also in the original PCAP format. As well as using wave or MP3 format encoding is supported also using PCAP files. A PCAP file require more or less the same disk space than wave recordings. Also the Player form Build 1134 on support PCAP file play.

Note: If the recorder work as a service only PCAP Recording is possible. See relative article.

Note: The Recorder can work also as PCAP to Wave or MP3 converter and/or http Player server. See relative articles.


As an option a mp3 compression can be activated. The required disk size is about 75% less, so one minute in wave requires about 1Mb while the same data in mp3 will require 250kb.

If you wonder why the savings are not much higher consider that even the wave format itself is jet compressed as explained.

All other functions like encryption (an encrypted file size is again doubled, so one minute of mp3 audio encrypted requires about 500kb) or reproducing are the same, the user has nothing to do and the player works always in the same mode.

There is just one situation where an action is required: if the recorder works for a certain period with wave and then with mp3 (or vice versa) in the directory of that month there will be mixed files (wave and mp3). The player detect this and shows automatically an additional key where the user must switch between those two formats: if a directory has just one type of files no action is required and the button is hided.

MP3 Stereo to Mono conversion

If the MP3 option is on, files could also be converted form stereo to mono. The file size savings will be nearly 50%, so one minute conversation in mono MP3 requires about 130kB.

Note that conversion from wav to mp3 causes quality lost and stereo to mono even. Once converted, there is no possibility to return to the original format in terms of quality or format. So a bad mono mp3 quality cannot be recovered and even the stereo separation of the cannels cannot be done once converted to mono.

MP3 just internal channel

An interesting option in using MP3 is to record just one channel, the left (default) or the right one. The result is a mono file (130kB/min) where just one party is recorded.

If a GW point to an external trunk the internal user is always talking on the left channel. Therefore with this option on just the voice of the internal user is recorded, and doing that in many countries is simply allowed without any restrictions (basically I can record myself).

If recording is done on the phone the channel assignment is vice-versa, the internal caller (the phone) is recorded always in the right channel. Therefore in the setup of the recorder can be selected which cannel should be recorded. That means also that no mixed scenarios (GW and Phone recording) are supported for that feature.



The recorder is able to handle redundancy scenarios with active and standby devices. The recorder has to handle 3 sources in different scenarios, the PBX itself, the reporting and the CF or webdav server. Those devices can be all together in one single device (for example in an active IP6010 with reporting and CF and a standby IP6010 with reporting and CF) or on different devices (for example an active and a standby IP800 and two reporting on two different PCs). Another example is active and standby PBX on Gateways but reporting on a high availability VMware environment, so at the end just one reporting from the recorder point of view.

Therefore the standby can be defined for each of those devices. If you have no redundancy scenario just leave blank the relative setup values.

Active/Standby PBX

The failure of the PBX is detected because the SOAP connection will go down. If that happen the recorder will try to establish an alternative link to the standby PBX, if that fails he try again with the primary PBX and so one. That means also that a breakdown of the SOPA connection, for example if you reset the PBX, will require some more seconds until the system is up again (because first the recorder try the standby PBX, this will also fail and after that the main SOAP will be up again).

Note that after a restart the recorder try always the first the main address and then the standby one.

In the panel of the recorder near the PBX status indicator is shown the actual link: if the “ACT” lamp is green than the active PBX is tempted, if gray and the “STB” lamp on the standby link is on.

Please note that the recorder can handle differences in active and standby mode just regarding the IP address. All other parameter must be the same, so for example the path to the reporting must be the same.

Active/Standby Reporting

If the link to the reporting fails and there is a standby address indicated the recorder try to reach the reporting using the standby IP address for the reporting. If there is just one reporting leave the standby address blank.

As you (hopefully) know the reporting can also be installed on two devices, in that case both PBX (the active and the standby one) will transmit CDR ticket to both reporting applications. The reporting database is replicated and therefore if both devices are on the recorder will find the same informations on each reporting. So in theory if both are on it is not important where the reports are requested. In fact if the active reporting fails the recorder will try a connection to the standby reporting. Now if the active device and relative reporting is on again the recorder could also continue get records from the standby reporting. And he will do that until he is restarted or the standby reporting is down because the reporting will answer. If that is not desired flag the option in the recorder setup (“follow Standby/Active PBX”); doing so the recorder will communicate again with the reporting on the active PBX if the active PBX is up again. So basically the switch is done on link down but also following the SOAP.

Active/Standby CF/mSATA

If the PCAP files are buffered on a CF/mSATA and the PBX goes down also the recorder has to re-map his drive to the standby PBX. In the setup there is a flag in the PCAP section (“follow Standby/Active PBX”), if on the recorder will try to reach the CF of the standby PBX (he takes the IP address of the standby PBX) in the setup.

In scenarios where an external Webdav server is used that flag should not be switched on. The redundancy in that case is demanded to the external devices (for example VMware).

So if you have a “classic” innovaphone redundancy (for example two IP6010 with reporting and CF) indicate the standby address in the PBX and Reporting panel and switch on the “follow Standby/Active PBX” in the reporting and PCAP panel and anything is fine.

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



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.



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:


<PN>=player name



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)



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:


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 available only on a local port ( and used for interfacing with the reporting (see relative article). The following description is just for internal use.


There are also available the commands







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”.


If you post in your browser ““, 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.

Recording rules

The recording rules describe how the innovaphone PBX and the innovaphone voice recorder works in complex situations.

While basic calls are simple and straight forward in logic, voice recording behavior becomes non clear in complex situations.

What about voice recording if for example a recorded user transfers the call to a “normal” user? Answer: This call will be entirely recorded and booked under the recording user by design; those behaviors are intended under “recording rules”. From a technical point of view mostly no other solution is possible, from a political point of view any rule could be endless discussed.

Remember that in this chapter “Agent” is just the wording for “user enabled to recording with license” while “user” is a “normal” user, eventually even recording pcap files, but he is not in the recording user group.

In theory senseless recording should not be done. So deleting a record because it should not be stored is a task of the recorder; not recording at all if not necessary is better. That can be achieved avoiding or forcing extensions to the recording gateways or doing recoding directly from the IP-Phone.

The length (or contend) of a record depends; if the recording is done on a GW the entire call will be recorded (if not you will find a note in the rules), from his very first answer to the end. Therefore all the parties involved are even recorded. If recording is done on the phone level just the active call time on that phone will be recorded.

Generally spoken there are not necessary recording rules if the recording is done from the innovaphone IP-Phone: the recording starts when the phone answer the call and ends when the phone hangs up.

So the following table shows the recording rules if recording is done on a GW level.

“External” is the external calling or called party. Of cause if you record even internals calls (forcing all calls in a GW) in some situation the “External” is in reality a internal user, but this will not change the rules. The recorder recognizes the “external” party involved simply because it is the longest number involved.

The recorder stores always even the reporting data and therefore all details are visible in case of doubts. The audio filename anyway if formed just from the internal user number and the external user number even if more numbers are involved in the call (for example in a 3party conference).

Example: External call from number 012345 goes to the Agent number 24, after 3 second he will answer: the result will be a file name like “2014-05-12 14:00_24_i_012345_3_UID”.

Later on in the player you can search “24” or “012345” (or a fraction of it like “0123*” ecc.). In the reporting you can search also all other fields (like other involved extensions) and start the player than from the reporting (see relative function in the innovaphone player).

Note: the following rules works on any type of call transfer (with or without announcement).

“Delete” means that the call will be deleted on the CF. “Call” means that they talk. For example “Agent calls External” indicated the direction and means also that the involved parties talk (or at least produce a pcap file).


• External call to Agent = Agent

• External call to User = Deleted

• External call to Agent, User pick-up the call = Agent

• External call to User, Agent pick-up the call = Agent

• External call to broadcast group, Agent answer = Agent

• External call to broadcast group, User answer = Deleted

• External call to User, User hold and transfer to Agent = Agent

• External call to Agent A, Agent A hold and transfer to Agent B = Agent A

• External call to Agent A, Agent B pick up the call = Agent A

• External call to WQ, WQ call XML with DTMF input, XML call WQ, WQ call Agent = Agent (just the external Number is considered, not the DTMF codes and numbers between)

• External call to WQ, Agent A transfer call to Agent with or without announcement = Agent A (from Build1185)

• External call to WQ, Agent transfer call to User without announcement = Agent (from Build1185)

• External call to WQ, Agent transfer call to User with announcement = Deleted (from Build1185)

• External call to WQ, User transfer call with or without announcement to Agent = Deleted (from Build1185)

• Agent call External = Agent

• Agent call External, Agent hold and call transfer to User = Agent

• Agent call User, User hold and transfer to External = Deleted

• Agent call External, Agent hold and talk with User but no call transfer = Agent (just external conversation is recorded)

• Agent A call External, Agent A hold and transfer to Agent B = Agent A

• Agent B call External, Agent B hold and transfer to Agent A = Agent B

• User call to Agent, Agent hold and transfer to External = Agent

• User call External, User hold and transfer to Agent = Agent

• User call External = Deleted

• User call External, User hold and talking with Agent but no call transfer = Deleted

• User call Agent, Agent hold and Agent talk with External = Agent (just the external conversation is recorded)

• External call to Agent, Agent has activated a unconditional call forward (CFU) to a User = Deleted

• External Call to Agent, Agent has activated a call forward on busy (CFB) to a User and is busy = Deleted

• External Call to Agent, Agent has activated a call forward on no response (CFNR) to a User, User answer after timeout = Agent

• External call to Agent A, Agent A has activated a unconditional call forward (CFU) to Agent B = Agent B

• External Call to Agent A, Agent A has activated a call forward on busy (CFB) to Agent B and is busy = Agent B

• External Call to Agent A, Agent A has activated a call forward on no response (CFNR) to Agent B, Agent B answer after timeout = Agent A

Note: If Threat call recording is on a call can be marked to store from the calling or called agent. But if both parties are Agent, the called Agent has to dial the code for storing: if the caller dials the code the record will not be saved.

From version 11 on the generated pcap file have a different format. While in former versions the name of a pcap file was a unique single long number form version 11r1 on the ticket as two additional id, one is build form the serial number of the device and the other one if an increasing number. This new format is also generated when recording is done form directly the phone. The recorder can handle both formats automatically, no special setup is required.

We want to focus your attention on the reason of the new format. If for example the recording is done on the phone the phone will generate a new pcap file each time a new call is opened form the PBX point of view.

Example: Phone rings and the user answers, the recording starts with record 1. Then the user put the call on hold and call another extension, this generates record number 2. Then the phone returns to the first call and continuous talking that will be the 3td call. Of cause using the player you will see those 3 calls one after the other (using the user as filter). That this is one situation you recognize looking the reporting details displayed and if you select the 3 calls the player will play one after the other (switch on the loop key) and you listen the entire call in one shoot.


Build 1167

TAN stand for “Transaction authentication number” used mainly in electronic banking and is a 6 digit long number. Of cause also other applications could use numbers like ticket systems or project handling.

In voice recording a record should be assigned to a TAN and a filter (search) should be possible. The actual integrated function work exclusive with a 6 digit number.

Please note that also a automatic association is possible as described in the relative chapter in this document: in this case all TAN issues are handled by the 3rt party application while this feature works without 3rt party application.

The operation depends of the Recording Mode in the innovaphone IP-phone.

If the Recording Mode in the IP-phone is switched on to “transparent” or “off” during a conversation the agent press the redial key.

If the Recording Mode in the phone is switched to “manual” or “optional” during a conversation the agent press a feature key (Redirect).

Than the agent enter the prefix for the TAN feature (the prefix for the TAN feature depends of the setup, see installation) and the 6 digit TAN code (without * and #) of this conversation.

During that operation the agent is in conversation with the far party, no DTMF tones are transmitted. In any moment (but during the conversation, not after) the Agent press the redial button to store the number. His phone release and ring again, during that the far party hear a call control tone. If the agent picks up the receiver the connection is again established. Therefore it is good practice to inform the far party that he will be shortly disconnected for operational reasons.

The call can be terminated now in any moment normally, the TAN information will be in the record and also in the reporting. The Recorder has not to be online in that moment because all information about the TAN is in the reporting.

A record can be edited in any moment using the player (if relative permission is switched on in the setup). A TAN can be edited (for example because erroneous operation in the online operation) and to any record can be added a TAN number. Please note that once a TAN number was add to the record the number can be modified but not cancel. Best practice is to assign “000000” as TAN for “no TAN records”. Please note that the option to add TAN to records and filter for TAN can be used also without the recorder just using the player. In the player a filter for TAN can be activated and combined with any other filter. To filter enter the 6 digit TAN code and press enter. To reset the filter clear at least one digit and press enter.


In the record name the TAN is at the end of the filename, starting with a “T”.

The TAN feature is designed to work with innovaphone IP-Phones. The feature works also if a player-server is installed (http access to records). The feature is integrated in the reporting, therefore a player could be controlled directly as usual also from the reporting.

The feature works in the same way regardless if the Agent was called or has called a customer.


In the Setup of the Agent, Tab “permission” the “TAN” checkmark enables the player to search and modify TAN numbers. If that checkmark is on the main view of the player shows automatically the relative optional window with tooltip support.


To enable the online input during the conversation there are more setups required. Copy the xml “TAN.xml” on the CF/msata/webdav and create a VM object pointing on it. The number of this object will be the “TAN prefix”. Open the Recorder setup, tab “PBX” and enter the TAN prefix.

TCR require a XML (TAN.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 ).

Known Problems

CDR on trunk

It is recommended to switch on also the CDR on the involved trunk line if the recording is done on the trunk. If a call on a trunk cause a PCAP file without involving an internal object with reporting (for example a call rerouted to an external destination) there is no CDR ticket for that PCAP file.

Version 13

The V12 Recording (this description) works also with an V13 installations. The licenses are identical to the V13 (this recorder can also work with V13 licenses).

Please note that this product require a V12 reporting and is not compatible with the V13 reporting. Therefore if you run this recording in a V13 environment you have to setup on a different platform (for example a Vmware) a V12 reporting. Also, the V13 mSata/FLASH Webdav cound is not used by the recording V10. You must use a V12 Application Platform Webdav (or an IPVA AP Webdav) to store the pcap files. Typically no problem, since the reporting must already be installed in V12 and a subsequent Ap platform has booted up.

Open a ticket

If you have a problem with the recording tool you have to open a ticket as usual. Describe your problem, but send us also the following information:

- Setup of your PBX (with standard password or tell us the password)

- Version of the reporting

- Attach all log and error files and the setup of the recorder. All those files are in the log folder (so zip the entire folder), you find the path and link to the folder in the recorder setup.

- Make some screenshots if possible.

- Open the reporting and do a query where the recorded conversations are in (if possible). Do an export in XML and attached it.

No CDR ticket after start-up

If a record is not found on the CF and there is no SOAP info about that (for example if you start the recording and there are old terminated calls) the recording checks if the reporting has a related record. If a record is found and it is an Agent involved the record is stored as usual, if no Agent is involved the record will be deleted.

But if there is a recording file found and in the recording there is no related record, the recorder cold simply deletes that record; but this could be fatal. For example the reporting could answer once bad, or the link between the reporting and the PBX is temporary down; in that cases the recording will be lost if simply deleted. Therefore the recorder waits in this situation and asks the reporting again after 2 hours. If even after 2 hours the reporting answer with no record found the file will be deleted (otherwise normally processed and stored or deleted as described before).

Note that the reporting is not aware about the health of the connection between PBX and the Reporting. If the recorder gets no answer from the reporting an alarm occurs and the reporting will not proceed with the storage. But the answer “no record found” is not a clear situation for the software. Therefor this situation has to be avoided and occurs for example if pcaps are recorded, but the users involved have no reporting while the recorder is down and starts up later. So the recorder will “find” pcap files but no reporting information.

During online operation this will not happen, because the SOAP driver will tell the recorder that a specific record has to be deleted, and so the recorder will not check the reporting. This is done even to speed up the recorder because the communication with the reporting is relatively slow. If for example there are many users doing a recording (because a bad setup or simply because a huge PBX) and there are only few users to record a huge amount of files are simply to delete without any further processing. Deleting of files is relatively fast during online operation while in case of startup and then recover historic records it becomes slow, and very slow if there are no CDR tickets. The online deleting of files is just “relatively fast” because the SOAP is very fast but the recorded file has to be closed before deleting. Trying to delete a not closed file will cause an error, if that happen the system after e while will recover, but it is not nice. On top there is no way on a CF to understand if a file is in use or not. Therefore the system will wait 2 seconds before deleting a file.

No CDR ticket online

There is even an unclear situation in online operation. Imagine that an Agent transmits no CDR information to the reporting (for example because there is no reporting license assigned to that user) or, because of a bad setup in the PBX, the ticket will not arrive to the reporting. A call of an Agent is terminated, the SOAP driver informs the upper layer of the software about that and now the recording ask the reporting about the CDR details. Note that the reporting is not down; the recorder can reach the reporting and get also answers (otherwise the REP alarm would be on). If after a detected call end of an Agent signaled by SOAP and a timeout of 5 seconds no CDR is in the reporting a garbage select routine is activated in the recorder software; this routine ask a second time after other 5 seconds the reporting. If even now the response is “no record found” the reporting waits for this call 2 hours. After 2 hours a third time the reporting is asked, if no record is found the pcap is deleted, otherwise normal processed.

If a record is waiting in the 2 hours timeout status in the field “status” the countdown proceed is shown, for example “P1443”, after 5 seconds “P1442” and so one (number*5/60 = time in minutes to zero).

To fix it just stop the recording, solve the problem if possible (if you are lucky for example the CDR data are in the PBX buffer and will be send to the reporting when connection is up again), if not save the Pcap file, at least it will not be deleted. Then delete the pcap file on the CF to avoid a slowdown of the entire system.

A simple but good idea is to enable the CDR on the recording trunk line, in this case “some information” for the call is retrieved all time and at least the system will not face that problem.

All described can be the result of a bad or erroneous setup, or the customer is aware of that and simply not interested in a good working application. So a “no record” answer could be a real alarm or not. Therefore in the setup that can be selected.

See recording setup, panel reporting, option “Alarm if no CDR ticket found”.

Asynchronous reporting/PBX date and time

PBX and reporting must have the same date and time. If not, the reporting will detect that and display error and warning messages about a possible manipulation in the files.

So check first the actual date and time of PBX and reporting.

IPVA: Remember that date can be set in the reporting in administration, General, Configure NTP server.

Voice Recorder Window is truncated

It could happen that the Voice Recorder Window is truncated. The reason for this is the screen resolution setting in windows. To solve the problem, the screen resolution adaptation must be switched off (set to 100%) in windows system settings.

Player Crash on start-up

If the player won’t start try first play a wave file using the Windows media Player. If the Windows Media Player cannot reproduce the wave file (for example because there is no audio device or the audio device is not ready) the player will not start up. Fix first the PC problem.

Recorder stopped responding after the start

We have had reports that recording did not run on windows 2008 r2. Symptoms were: recorder stopped responding after the start (recorder hang) and the link to the PBX was down. This had been fixed by running sfc.exe.

PBX Trap

If the PBX is doing a restart during a recording no CDR record will be produced. Therefore the partial PCAP File will be dropped. If the trap of the PBX is during a file copy from the Webdav, the recorder try up to 5 minutes, but will recover the operation automatically after that time.

Recorder stopped converting records into mp3

It can happen that the recorder does not convert any recordings into mp3, even if the mp3 driver is detected and the mp3 conversion is turned on. In that case, you should check if the name of the storage path contains special characters like ()", or space.

Using Network Drives

Windows mapping of network drives and also the integrated possibility to map networks drive do not work correctly because of windows bugs. If destination of the storage you are using is a Webdav folder and you want to use a mapped drive (for example F: or N:), mapping the drive using Windows feature will cause writing/reading issues, and Recording won't convert the file in .wav in the storage path. Work around: To avoid this, use a third party software like "Net Drive" to create the network map.

Related Articles











Reference13r2:Concept App Service Recordings