On Linux

Here are the steps to install OrkAudio using installers on CentOS or Red Hat Enterprise Linux (RHEL).

Requirements

• You need a minimal installation of CentOS or RHEL. A graphical desktop is not required.
• You need to be logged in as "root" to install the Oreka software.

Installation

• Use the installer file provided to you by OrecX, e.g. orkaudio-1.2-660-x1459-i386.centos5-installer.sh.tar
• Untar it: tar -xvf orkaudio-1.2-660-x1459-i386.centos5-installer.sh.tar
• Run the installer: ./orkaudio-1.2-660-x1459-i386.centos5-installer.sh (accept all required components)
• If the installer fails, please contact support@orecx.com . It is also possible to attempt the procedure in

On Windows

Requirements

• You need to be logged in as Administrator before proceeding.
• Access to the internet is highly recommended for download of the Oreka software.

Installation

Use the installer file provided to you by OrecX, e.g. orkaudio-1.2-657-x1463-win32-installer.zip . Copy this file to a temporary folder on the target machine, unzip it and run the embedded executable. This will install WinPcap as well as OrkAudio.

Upgrade with RPM installer (Linux)

In this procedure, please replace version numbers with the relevant ones.

• Take a backup copy of the entire /etc/orkaudio directory, e.g:

  # cp -r /etc/orkaudio/ /tmp/backup-etc-orkaudio
  

• Download and upgrade to the new version:

  # service orkaudio stop
  # wget --http-user=orecxaccess --http-password=XXXXXXXXXXXX http://files.orecx.com/orecx/company/orkaudio-commercial-2.70-1686.x8127.x86_64.centos7.gcc48-installer.tar
  # tar xvf orkaudio-commercial-2.70-1686.x8127.x86_64.centos7.gcc48-installer.tar
  # chmod +x orkaudio-commercial-2.70-1686.x8127.x86_64.centos7.gcc48-installer
  # ./orkaudio-commercial-2.70-1686.x8127.x86_64.centos7.gcc48-installer
  # service orkaudio start
  

Upgrade with individual RPM files (Linux)

In this procedure, please replace version numbers with the relevant ones.

• Take a backup copy of the entire /etc/orkaudio directory, e.g:

  # cp -r /etc/orkaudio/ /tmp/backup-etc-orkaudio
  

• Download and upgrade to the new version:

  # service orkaudio stop
  # wget --http-user=orecxaccess --http-password=XXXXXXXXXXXX http://files.orecx.com/orecx/company/orkaudio-commercial-2.51_1292x6999.x86_64.centos7.gcc48.rpm
  # yum upgrade orkaudio-commercial-2.85_1728x8354.x86_64.centos7.gcc48.rpm
  # service orkaudio start
  

Upgrade with Windows installer

• Take a backup copy of the orkaudio directory under Program Files
• Stop the orkaudio service
• Uninstall previous version OrkAudio
• Run the latest orkaudio installer (e.g. orkaudio-1.2-657-x1463-win32-installer.exe)
• If any custom changes had been made to the old config.xml or logging.properties files such as IP filtering or NIC selection, apply those changes to the new files (do not simply overwrite the new files with the old ones, some configuration settings might have changed between the two versions)

Upgrade with Windows binary archive

• Stop the OrkAudio service
• Unpack the orkaudio zip archive downloaded from your OrecX space (e.g orkaudio-1.2-688-x1537.zip)
• Select and copy all files inside the top directory. This should include orkaudio.exe, some .dll files as well as subdirectories
• Paste the files on top of your orkaudio install directory so that all .exe and .dll files are all replaced by the new ones in the archive
• When done, all replaced files are usually seen as selected in the Windows file explorer This can give you a good indication of the success of the operation
• Restart the OrkAudio service

Audio Output Files

Audio output files are written to the c:\oreka\audio under Windows and in /var/log/orkaudio under Linux by default.

Audio files are classified according to the following default scheme (see also TapeFileNaming and TapePathNaming in File and Path Names in OrkAudio ):

yyyy/MM/dd/hh

Audio file themselves are named after the following scheme:

yyyyMMdd_hhmmss_trackingID.extension

You can modify the audio files location by editing the <AudioOutputPath> configuration parameter described in Configuration . Note that if this parameter is changed, OrkWebApps needs to be told where to look for the recordings. This requires modifying Tomcat's $tomcat/conf/server.xml file to update the context path docBase parameter accordingly:

<Context path="/audio" docBase="c:/oreka/audio/" ></Context>

If this parameter does not exist already, just add it under the <Host> section. Don't forget to restart Tomcat after this change.

Configuration Files

OrkAudio configuration files are located in the install directory under Windows and in /etc/oreka under Linux. The files are:

• config.xml : this is the main OrkAudio configuration file. Plugins also read their configration parameters from subsections of this file. Please see Configuration for more details.
• logging.properties : this is the log4j logging configuration file which allows for great flexibility in logging scope and output format. Please see http://logging.apache.org/log4j/1.2/manual.html

Log Files

Log files are located in the install directory under Windows and in /var/log/oreka under Linux. By default, Oreka produces the following output:

• orkaudio.log : this is the main OrkAudio logfile.
• tapelist.log : this logfile contains the details (metadata) for each recording that was performed by OrkAudio.
• messages.log : : this log file contains a subset of details (metadata) for each recording that was performed by OrkAudio. Useful for re-creating database entries.

Plugins Files

Plugins exist as dll files under Windows and as DSO (Dynamic Shared Objects) with .so extensions under Linux. They are located in {OrkAudioInstallDirectory}/audiocaptureplugins under Windows and in /usr/lib under Linux.

• VoIp.dll - libvoip.so : VoIP recording plugin for SIP, Cisco Skinny and pure RTP protocols.
• H323voip.dll : VoIP recording plugin for H.323, Avaya, Nortel UNISTIM and MGCP protocols.
• SoundDevice.dll - libsounddevice.so : Sound Card based recording
• Generator.dll - libgenerator.so : Audio generator for faking audio capture (useful when testing)

Wire audio encodings

Wire audio encodings are detected automatically by OrkAudio. Audio is not usually stored in its original wire format. Audio is recorded in real time to mcf files in order to maximize capturing performance and is later transcoded to the final storage format as specified in Storage audio formats . The following encodings are supported:

• G.711 ulaw
• G.711 alaw
• GSM 6.10
• iLBC
• G.729A
• G.723.1
• G.722

Storage audio formats

The storage format is the file format used to archive recordings to disk. Mcf capture files are transcoded from the wire encoding to the final storage format on a best effort basis. All possible storage encodings are currently wrapped into the wav container format. This means that all generated audio files have a .wav file extension and easily play on any existing Windows or Linux media player. The following formats are supported, please see Configuration for more details.

• GSM 6.10 wav : default format
• G.711 ulaw wav
• G.711 alaw wav
• PCM wav : uncompressed audio, not recommended.

Basic Configuration

Configuration of OrkAudio and its plugins is performed by modifying the config.xml file (see also Configuration Files ). Core OrkAudio configuring parameters are the following:

• <AudioOutputPath> : this parameter controls the root directory where capture and storage audio files are stored. It can be a relative or absolute path.

• <CapturePlugin> : this parameter controls which audio capture plugin should be used. Valid values are VoIP.dll and libh323voip.dll in Windows, and libvoip.so and libh323voip.so under Linux.

• <TrackerHostname> : the hostname or IP address of the server where OrkTrack (a component installed with OrkWebApps) resides. If you use the OrkTrack hostname instead of the IP address (recommended), make sure that DNS is set up correctly and that you can ping that hostname from this OrkAudio server. Exemple:

  <TrackerHostname>my-orktrack-server1</TrackerHostname>
  

  You can also enter several orktrack engines, e.g. for redundancy. They must be comma separated. When using non-standard TCP ports for OrkWebApps (standard is port 8080), it is possible to specify them in the hostname:port format. For example, if one tracker is on port 8080 and the second tracker is on port 80:

  <TrackerHostname>my-orktrack-server1:8080, my-orktrack-server2:80</TrackerHostname>
  

• <StorageAudioFormat> : this parameter controls the final file format of the tapes. Valid values are the following: gsm, ulaw, alaw and pcmwav. "gsm" is the default value and is the best compression rate available. All values generate wav files with various degrees of compression.

• <TapeProcessors> : usually set to BatchProcessing, Reporting. Reporting ensures that the metadata about recordings is "reported" to the database through OrkTrack.

• <DeleteNativeFile> : this parameter allows you to keep the uncompressed .mcf file even after the transcoding to the .wav is complete. The default is "yes". Set it to "no" to keep the .mcf file.

• <TapeDurationMinimumSec> : minimum duration in seconds for a call to be recorded.

• <AllowAutomaticRecording> : if set to "yes" (default setting), calls will be recorded by default. "no" indicates that only explicitly requested recording will occur (e.g. from Live Monitoring in OrkWebApps).

• <LookBackRecording> : if set to "yes" (default), will always record the call from the beginning regardless of when the request to start the recording was initiated, while a "no" setting will record only from the time the request was made.

File and Path Names in OrkAudio

It is possible to configure the path to which audio files are written as well as the audio file names through dynamic parameters

First, the TapeFileNaming tape processor needs to be added to the list of processors in the top node of the orkaudio config.xml file:

<TapeProcessors>BatchProcessing, TapeFileNaming, Reporting</TapeProcessors>

Secondly, the <TapeFileNaming> and/or <TapePathNaming> must also be added in the top node of the orkaudio config.xml file. They both contain a CSV list of elements. If an element appears between square brackets, it will be replaced by the value corresponding to the keyword. If an element appears without square brackets, it will be used verbatim in the file name. Example:

<TapeFileNaming>myrecordings-,[nativecallid]</TapeFileNaming>

with a native call ID of FDBCE@69.13.45.6 will result in the following file name: myrecordings-FDBCE@69.13.45.6.wav .

If the TapeFileNaming parameter is missing, the default naming scheme applies which is a timestamp plus the internal trackingID.

If the TapePathNaming parameter is missing, recordings are distributed to the default year/month/day/hour folder tree structure described in Files Location .

Note: TapePathNaming configuration is always relative to AudioOutputPath.

Here is a list of acceptable keywords for tape and path naming:

• [nativecallid]: this is the call ID extracted from the underlying protocol (SIP, Cisco Skinny, ...)
• [trackingid]: this is the internal Oreka tracking ID
• [direction]: in, out or unkn
• [shortdirection]: I, O or U
• [remoteparty]
• [localentrypoint]
• [localparty]
• [localip]
• [remoteip]
• [hostname]
• [year]
• [day]
• [month]
• [hour] in 24 hours format
• [min]
• [sec]

You can also use any tag or additional custom extracted field in file names by using its tag/field name as a key. e.g for a SIP field called X-Unique-ID, add [X-Unique-ID] to TapeFileNaming or TapePathNaming. See also Extracting arbitrary fields from SIP headers

Additional example:

<TapeFileNaming>myrecording,[hour],[min],[sec],_,[shortdirection],_,[remoteparty],_,[localparty],_,[hostname]</TapeFileNaming>
<TapePathNaming>mypathprefix/,[year],[month],/,[day]</TapePathNaming>

Configuring the VoIP plugin

VoIP plugin specific configuration is found in the config.xml file under the VoIpPlugin tag. Many options are available for this plugin, such as limiting traffic, blocking traffic from/to a specific IP address, ... The default config.xml has some of the main options listed in it and commented out. If any of these parameters are not documented here, please contact support@orecx.com for more details.

<Devices>\Device\NPF_{E0E496FA-DABF-47C1-97C2-DD914DFD3354}</Devices>

<Devices>eth2</Devices>

<PcapFilter>host 192.168.0.34 or net 192.168.1.0/24</PcapFilter>

<SipExtractFields>contact, max-forwards, X-UNIQUE-ID</SipExtractFields>

Live Monitoring

For Live Monitoring from OrkWebApps to work, the 59120 port must be accessible on the server where OrkAudio is running. In Linux check the iptables settings. in Windows, the firewall settings.

See also Live Monitoring (On-Demand Recording) for configuring OrkWebApps.

Starting the OrkAudio service

Under Windows, start the OrkAudio service in Service Management (start/run/services.msc).

Under Linux, start the OrkAudio service by typing service orkaudio start on the command line.

Verifying that OrkAudio started

You might need to double-check that the orkaudio service was started correctly.

In Linux, use the following command:

# ps -ef | grep orkaudio

A line showing that orkaudio is running must appear:

root     32071     1  0 10:02 ?        00:00:00
/usr/sbin/orkaudio

In Windows' Service Management tool (start/run/services.msc), ensure that the orkaudio service is started

OrkAudio Auto-Start

During installation using the official installers, OrkAudio will install itself as an automatic service, i.e. a service that restarts automatically if the server is rebooted. This is important in the case of power failure, maintenance or other unpredictable events that may cause the system to fail or be restarted. Ensure that the service is configured properly as follows:

• In Windows' Service Management tool (start/run/services.msc), right click on the orkaudio service and ensure that the Startup type is set to Automatic
• In Linux, the command "chkconfig -- list orkaudio" should yield a response such as below:

# orkaudio        0:off   1:off   2:on    3:on    4:on    5:on    6:off

If not, chkconfig orkaudio on will need to be executed.

Trial versus Production license

Note that there are two types of license files: trial and production. The trial type is sent to you by OrecX as a first license and allows you to record everything on the wire. It is good to start with this type of license to uncover any configuration tweaks that may be necessary.

For example, you may be seeing only the RTP streams but not the control packets, thus no phone number or extensions can be associated to calls. With a trial license, you will be able to quickly detect such a situation and correct it since all calls would be recorded and would appear in the OrkUI Browse page with the local and remote party typically showing as IP addresses.

With a production license, users must be configured in OrkWebApps with their phone numbers or extensions (or other) as a login string, for Oreka to be able to associate the local party in the VoIP packets with the configured user and thus recording the call. If no users have been configured in OrkWebApps, a production license will inhibit all recording. See also Login Strings

Before migrating to a production license, make sure all extensions, phone numbers, SIP URIs, ... that need to be recorded, are configured as login strings for defined users in OrkWebApps. The login string field must match what you see in the local party field in the Browse page.

OrkWebApps Configuration files

OrkWebApps have a set of configuration files that allow them to know where and how to access the database, and what information to write to log files. The main configuration files can be found under /etc/orkwebapps in Linux, and typically under C:\Program Files\OrkWebApps in Windows. These folders contain 5 main files:

• database.hbm.xml : for application database access information.
• logging.properties : for application logging configuration.
• localpartyMap.csv : for mapping the local party seen by orkaudio to the one configured in OrkUI (e.g. IP address to an extension).
• remotepartyMap.csv : for mapping the local party seen by orkaudio to the one configured in OrkUI.
• config.properties : for configuring the tracker name (orktrack) and orktrack clustering options

The OrkTrack web application's web.xml file has two important parameters: ConfigDirectory and TomcatHome. The former one must point to the installation folder (e.g. /etc/orkwebapps ) while the latter points to the container folder (e.g. /opt/tomcat8). This is usually the case by default.

OrkWebApps Log files

Both the OrkWebApps applications, and the Tomcat web server have their own logging mechanisms. Below are the files of interest for both cases. All of them except catalina.out reside in /var/log/orkwebapps under Linux and typically in C:\Program Files\OrkWebApps in Windows. The level of logging is defined in the logging.properties file. Logging levels are ERROR, INFO, DEBUG and TRACE.

• orkwebapps.log : this file contains all messages logged by OrkTrack.
• orkwebapps_mm.log : this file contains only messages logged by OrkTrack's Media Manager module.
• orkwebapps_security.log : this file contains only security related messages logged by OrkTrack.
• catalina.out : this is the file where Apache Tomcat logs its own messages. It resides in the $tomcat/logs/ folder.

On Linux

You can use ps -ef | grep mysqld to verify if mysqld is running, and service mysqld start to start it if it is not.

Once the MySQL is running, start the Apache Tomcat web server, e.g. service tomcat start .

On Windows

Go to Start/Run... and type services.msc. This opens the Services Manager application. Ensure that the MySQL service is running. If not, start it.

Once the MariaDB or MySQL service is running, start the Apache Tomcat web server, by right-clicking on the Apache Tomcat service and selecting Start.

System Tag Types

System tag types may be pre-defined by the system at installation or applied automatically at the occurrence of specific events. Some of the most common automatic or system tag types are the following:

• Monitored: automatically applied to a recording when a user listens to a call in the Live Monitoring page.
• Recordings metadata: additional recording metadata such as nativecallid, on-demand, ucid, split, hunt group, ... some of which are only obtainable through an additional CTI connector.
• Agent and Agent Group: applied to a recording when it is subject to Agent Tracking - typically used on systems with hotdesking.
• Speech Analytics keywords: these keywords configured in Speech Analytics profiles are automatically applied when the Speech Analytics engine detects them in an audio recording.

User-Defined Tag Types

User-defined tag types are defined and applied manually by users or through the Oreka API. Here are some examples of common uses:

• Applying a tag type such as Reviewed to indicate that the call was reviewed by a manager.
• Applying a tag type such as Patient ID and adding the actual ID as a tag text.
• Bookmarking a spot in the recording where the agent yelled at a customer. The spot in the recording may be specified with the offset.
• Bookmarking a recording with the Credit Card tag type, and adding the credit card number as tag text, the time it was uttered at as tag offset and the time length it lasted as duration. This can be useful with PCI compliance where the credit card info acquisition is omitted from the audio recording.

Using Tags

Tags may be applied in one of three ways:

• In OrkWebApps manually by the user from the Browse page by clicking on the tag icon.
• In OrkWebApps manually by the user from the recordings details page.
• By API, using one of the addtag API variations.

Tags are listed in the recordings details page. They are also displayed on the OrkMPx media player, when hovering over them. Tags may be used as search criteria to list recordings, but they may also be used as criteria in Audio programs or Media Manager copy, move and delete programs giving great flexibility in terms of filtering capabilities.

Login Strings

Each user can have multiple login strings entered as a csv list of text strings. Those login strings serve two purposes:

• They act as unique identifiers for OrkWebApps users.
• They specify what phone numbers or extensions are to be recorded.

When a new call occurs, if the local party field, as would be seen in the OrkWebApps Browse page, matches one of the user's login strings, the recording will be associated to that user. The login string matching is case sensitive .

For example, Tom's login strings might be " tom, 5312 ". Any call to extension 5312 will be associated to Tom, and Tom will be able to log into OrkWebApps using either " tom " or "5312" as an identifier (assuming Tom has a password defined. OrkWebApps login is denied for users with blank passwords).

Configuration of users and login strings is very important for correct behavior when using production licenses. Refer to Trial versus Production license

Importing CSV List of Users

When you have a great number of users to provision in OrkWebApps, it could be a daunting task to create them all, one at a time, from the UI's Users page. In this case, you can use the Import Users feature available on that page. This feature allows you to import a comma-separate list of users directly into OrkWebApps. Below is a sample file format:

#BULK_USER_IMPORT
#First Name, Last Name, LoginString, Password, Recordable, Force Password Change, Email, Group, External User
John,Smith,jsmith@abc.com,abcdefg,true,false,,Sales Group
Jane,Doe,jdoe@abc.com,1234567,true,false,jdoe@abc.com,,true

Only the firstname and lastname fields are mandatory. The rest can be left blank if not required. Also, only one login string can be entered on one line. The "recordable" and "force password change" fields can be set to "false"/"true", "0"/"1" or "no"/"yes". The "force password change" field, if set, forces the corresponding user to change their password the next time they login. This is mainly useful when defining new users.

There are three other global settings that can be configured when importing users: "Keep old login strings", "Recordable" and "Enable".

• Keep old login strings allows you to select whether a user in the csv list that already exists in OrkWebApps should have their login string(s) replaced by the login string in the imported file, or whether the new login string is to be simply added to that user's existing login string(s).
• recordable sets the default value of the recordable field for new users. It defaults to true. If the CSV entry in the file defines the recordable field for a given user, that value overrides the global setting.
• enable applies only to existing users, and selects whether it to leave them intact or enable them if they are disables. The default value is true. If true, disabled users will be enabled; if false, existing users are kept intact.

Local Party Mapping

Sometimes, the local party reported by the OrkAudio appears in OrkWebApps in a format that does not meet your requirements, e.g. MAC address, IP address, ... In cases where this cannot be modified at a configuration level neither at the recorder level nor at the telephony platform level, Oreka provides you with a special tool to circumvent the issue: local party mapping.

To map the local party to an extension (or other) to meet your requirements, create or edit a localpartyMap.csv file in the OrkWebApps installation folder, and add the entries following the example below:

10.10.1.1, 1540
10.10.1.2, 1541
00:08:5d:13:19:a0, 3523
SIP/SOFTHONE034, 3681
...

The first entry is what you want to replace, the second, is the target output.

Once this file is completed, restart Tomcat (or at least OrkTrack), for the new changes to take effect.

Remote Party Mapping

This is the same as the local party mapping above, but for the remote party. The file name is remotepartyMap.csv in this case.

User Auto-Provisioning (UAP)

Oreka may be configured to automatically provision users based on recordings, i.e. whenever a new recording is detected, its local party can be automatically provisioned in OrkWebApps. This feature is mainly useful in active recording setups using SIPREC, whereby the decision of what users to record is pre-configured in the telephony platform, hence ensuring that auto-provisioning will only occur for required users.

To configure UAP, first the OrkAudio config.xml configuration file needs to be updated as follows (OrkAudio needs to be restarted for this change to take effect):

<SipUAPlugin>
    <SipRecReportLocalNameAsTag>yes</SipRecReportLocalNameAsTag>
</SipUAPlugin>

Then, the following setting must be enabled in the OrkWebApps database:

orkuserconfig.userAutoProvisioning = true
orkuserconfig.uapNameSplitChars    = "_. "  or " "

The orkuserconfig.uapNameSplitChars field is usually required to contain a blank space.

The user first and last name will be obtained from the OrkAudio recorder typically in the format "firstname lastname", and will be parsed accordingly to provision the user.

Some important notes on how UAP works:

• With UAP, the recording's local party (i.e. user's login string) is key. If the local party is not found as a configured login string in OrkWebApps, it is provisioned and associated to a new recordable and external user with the corresponding first and last name. This is regardless of whether another user by the same first and last name already exists (the login string is unique in Oreka, but the not the user name.)
• UAP is subject to user and login string license limits. Once reached, no new users are auto-provisioned.
• UAP not only adds new users, it can also update existing ones. This is true only if the login string already exists and is associated to a user who is marked as external .

If you need assistance, please contact support@orecx.com .

Single Sign On (SSO)

OrkWebApps can be configured to act as a single sign on (SSO) consumer, allowing user login based on authentication from an external platform. SSO is supported for the following 3 platforms:

• Broadworks
• LDAP
• SAML

The main configuration of SSO is in the database. For SAML, there is also an OrkUI configuration component.

When Broadworks or LDAP SSO are configured, OrkWebApps will authenticate logins against those platforms, but only for users that already exist in the OrkWebApps database as "external" non-disabled users. Additionally, if SSO User Auto-Provisioning (UAP) is configured, authentication against the SSO platform, if successful, will auto-provision the user in OrkWebApps.

The database configuration is done in the database's orkuserconfig table. Here are some of the main fields to configure:

• ssoType currently supports "Broadworks", "LDAP" and "SAML". The field is not case sensitive.
• ssoURL is the URL that OrkWebApps will use to request authentication from the SSO producer. The examples below are typical URLs used for Broadworks and LDAP. $userId is a parameter that will host the login user name for Broadworks.
• ssoUap boolean can be set to true to enable SSO UAP (Single Sign On User Auto-Provisioning). It applies only to Broadworks and LDAP SSO. When enabled, if the user attempting to log into OrkWebApps does not exist, they are auto-provisioned with basic access policies ("Users" security group), and set to be "external". Otherwise, if the user already exists as "external", its attributes (mainly first name, last name and email) are updated if necessary.

orkuserconfig.singleSignOn = true
orkuserconfig.ssoType = "Broadworks"
orkuserconfig.ssoURL = "https://xsp.bwvoip.net/com.broadsoft.xsi-actions/v2.0/user/$userId/profile"
orkuserconfig.ssoURLSecondary = "https://secondary.source.com/v2.0/user/$userId/profile"

orkuserconfig.singleSignOn = true
orkuserconfig.ssoType = "LDAP"
orkuserconfig.ssoURL = "ldap://ldap.forumsys.com:389/"
orkuserconfig.ssoAuth = "simple"
orkuserconfig.ssoPrincipal = "cn=$cn,dc=example,dc=com"

{
  "serverHostname": null,
  "serverPort": null,
  "configOptions": {
    "edit": {
      "alwaysShow": true
    },
    "SAML": {
     "samlLoginUrl": "",
    },
    "debug": {
      "isLoggingActive": false,
      "isOrkmpxAudioExtractionEnabled": false
    }
  }
}

Access Policies

Each role may have one or more Access Policies. Users associated to a particular role inherit all that role's access policies. Here is a list of available Access Policies available in Oreka, grouped by the resource they apply to:

Recordings

• View Recordings
• Play Recordings
• Delete Recordings
• Email Files
• Export Files
• View Live Recordings
• View Media Type Filter
• View Remote Party
• View Statistics

User Provisioning

• View Users
• Edit Users
• Create Users
• Edit Login Strings

Group Provisioning

• View Groups
• Edit Groups

Role Provisioning

• View Roles
• Edit Roles
• Assign Users To Roles

Program Provisioning

• View Programs
• Edit Programs

Workstation Provisioning

• Edit Workstations

Tags

• Edit Tag Types
• Edit Tags
• Delete Tags

Quality Monitoring

• Edit Scorecards
• Create Evaluations
• View Evaluations
• Edit Evaluations
• Delete Evaluations

Admin Features

• View Audit Trail
• View System Info
• Edit System Info

Additionally, Access Policies have scopes associated to them. The allowed scopes are listed below:

• None: when no Access Policy exists for a given resource in a role, users from that role have no access at all to that resource.
• Own: provides users access only to their own resource (e.g. their own recordings, tags, ...)
• Group: provides users access to their resources as well as to the resources of users belonging to their direct parent groups and their subgroups. This is typically granted to Group Administrators or Supervisors.
• All: allows users access to the resources of all users in the system. This type of policy is usually granted only to Administrators.

Example 1: Call center with Agents and Supervisors

In this example, call center agents shall be able to see their own recordings, supervisorA shall be able to see recordings for groupA and groupB, supervisorB shall be able to see recordings for groupB only. Here are the steps to configure this:

• Create one recordable user per recorded extension
• Create one non-recordable user per supervisor
• Create group A
• Create group B
• Add every agent user to either groupA or groupB (it is possible to add certain agents to both groups if wanted)
• Add supervisorA to groupA and groupB
• Add supervisorB to groupB only
• Add both supervisors to the Supervisors role

Example 2: Business hosted telephony provider

In this example, each end-customer is a company with several users and each company shall be mapped to a group. CompanyA shall be mapped to groupA, CompanyB shall be mapped to groupB. Within each company, one person shall be administering the system. Only this person might be able to access the live monitoring system. It shall not be possible for any company user to see data for another company, or even know that it exists. Here are the steps to configure this:

• Create one recordable user per recorded extension for both companies
• Create one non-recordable user per supervisor, e.g. supervisorA1 and supervisorA2 and supervisorB1
• Create one non-recordable user per company administrator, e.g. groupadminA and groupadminB
• Create regular groupA for companyA
• Create regular groupB for companyB
• Add every recordable user to either groupA or groupB
• Add supervisorA1, supervisorA2 and groupadminA to groupA
• Add supervisorB1 and groupadminB to groupB
• Add all supervisors to the Supervisors role
• Add groupadminA and groupadminB to the Group Administrators role
• Edit the access policies of the Supervisors and Users role in order to remove the live monitoring privilege altogether. The Group Administrators can access live monitoring by default, so no need to change access policies there.

Overview

In order to restrict what is recorded by Oreka, it is possible to create so-called recording programs from the Programs page. Those programs let OrkWebApps administrators specify recording schedules as well as filtering criteria. Any number of these programs may be created to achieve high complexity recording rules.

Very important note: when at least one audio or screen recording program is active, recordings become subject to Programs and are no longer retained by default.

A program is initiated by a trigger event, which causes a set of criteria to be evaluated. If the criteria are met, a corresponding action is taken. Hence, the Programs feature's usefulness is not limited to selective recording. The criteria-based functionalities allowed by programs are:

• Selective audio recording
• Selective audio and screen recording
• Selective screen recording (scheduled)
• Selective copying, moving, deleting or emailing of recordings (Media Manager)

The Copy, Move, Delete and Email recordings programs collectively define what we call the Media Manager feature.

Triggers

Triggers are events such as a pre-configured time or the completion of a recording. Scheduled (time-based) triggers may be one-time events or repeatable triggers that restart at a given frequency.

One-shot triggers are configured by setting the "Trigger first execution" field. Recurring triggers also set the "Trigger repeat period (in days)" field which establishes the frequency of the trigger.

Only Media Manager programs currently use those explicit triggers. Audio recording programs have implicit triggers based on the completion of the recording process.

Criteria

Criteria are conditions that are evaluated when the trigger event occurs. If met, they cause the program action to be executed. Examples of criteria are target user, target group, local party, remote party, ... The available criteria depend on the type of program in question. The "Handle as exclusion criteria" option ensures that the action is taken only if the criteria are NOT met.

The criteria list may vary between different programs. Also, local party, remote party, local entry point and tag text criteria may support regular expressions or simple wildcards CSV depending on whether they appear in scheduled or immediate programs. For example, in order to retain all recordings made to or received from phone numbers starting by the digit 5,6 or 7, enter "[5-7].*" in the remote party field of your program.

Be careful with the Target group criteria: it applies to the recording's user's parent groups as well as all their subgroups.

Scheduled Media Manager programs are bound in time by the two following criteria:

• Earliest timestamp: earliest timestamp is updated automatically by the software every time a new batch of recordings is processed. It sets the earliest recording that should be considered, and ensures that recordings previously evaluated don't get re-processed the next time the program is executed.
• Retention period (in days): this specifies the upper boundary of recordings (latest) that may be copied, moved or deleted. Recordings newer than that boundary are kept intact.

Actions

Actions are executed when the program is evaluated and the criteria are met. Actions may be one of the following:

• Keep an audio recording.
• Keep an audio/screen recording pair.
• Start/stop a screen recording.
• Copy recordings (Media Manager).
• Move recordings (Media Manager).
• Delete recordings (Media Manager).
• Email recordings (Media Manager).

Selective Recording (Audio and/or Screen)

Selective recording can be achieved with the Audio recording and Screen recording (scheduled) types of programs.

The basic Audio recording program will simply keep or discard a recording based on the defined criteria. The decision is made when the recording completes. Almost any recording metadata may be used as a program criteria including local party, remote party, call direction, duration, user associated to the recording, time of the recording, ... There is also a "recording percentage" criteria that ensures that only a certain random percentage of recordings is kept.

The Audio recording program may also be used to trigger screen recordings that are to be associated to the audio recordings with the "Trigger Screen Recording?" option. This option is only available when Screen Recording is licensed. In this scenario, when an audio recording starts, the program in question automatically triggers a screen recording. It also sends a message to the screen recorder to stop the recording when the audio recording completes, and associates it to the audio recording counterpart.

The other type of selective recording is Screen recording (scheduled) . This is for screen recordings only, and provides the ability to configure time-based trigger events for starting and stopping the screen recording (e.g. record only between 10AM and 2PM, or only on Thursdays, ...).

Media Manager (Copy, Move, Delete and Email)

The Media Manager (MM) functionality provides a mechanism to apply certain actions to existing recordings. These MM actions may be scheduled (time-based), or triggered when a recording completes. The latter is available for the copy and move programs, but not for the delete program. Deleting recordings as soon as they complete is rarely useful.

For copy and move programs, the actions are defined by the following parameters:

• Target service: this field must point to a File Server type service. It designates the target location where the media files are to be copied or moved and applies only to Copy and Move programs.
• Path name (string substitution): edit the secondary "Pathname" field if the target file's path is to be different from the original file's. Note that this refers only to the not the . The primary path refers to the "File absolute path" of the service in question, e.g. /var/log/orkaudio/audio , while the secondary path refers to the <TapePathNaming> path configured in the recorder's config.xml. The default being a date-based hierarchy e.g. 2009/11/12/09/20091110_154500_ABC.wav. You can heance use this field to customize your path name based on recording metadata. See for the list of string substitutions available for path naming in OrkWebApps.
• File name (string substitution): edit the "File name" field if you wish to customize the name of the target file. See File and Path Names in OrkWebApps for the list of string substitutions available for file naming in OrkWebApps.

Delete programs have the following action parameters:

• Delete files in file system: enable if actual media files need to be deleted.
• Delete entries in database: enable if deleting the recordings' metadata in the database is required.

Below are but a few examples of the many Media Manager uses:

• Configuring different delete retention periods for different groups.
• Moving recordings to different location depending on underlying customer (group).
• Backing up recordings for only a handful of groups.
• Renaming media files differently based on different criteria.
• Emailing media files immediately after they are written to the associated user.
• ...

File and Path Names in OrkWebApps

It is possible to configure the media files path and filename as a combination of the following dynamic parameters. Note that the pathname refers only to the secondary part of the pathname that typically defaults to year/month/day/hour/ .

• [orkuid]: the unique tape UID
• [segid]: the segment ID number
• [direction]: the direction, i.e. IN, OUT, UNKNOWN
• [shortdirection]: the short representation of the direction, i.e. I, O, U
• [localparty]: the local party field, typically containing a phone number or extension
• [remoteparty]: the remote party field, typically containing a phone number or extension
• [hostname]: the hostname obtained from the service associated to the recording
• [year]: the year in 4 digit format (e.g. 2009)
• [yy]: the year in 2 digit format (e.g. 09)
• [month]: the month, in 2 digit format (e.g. 02)
• [mm]: the month, in 2 digit format (e.g. 02)
• [day]: the day, in 2 digit format (e.g. 08)
• [dd]: the day, in 2 digit format (e.g. 08)
• [hour]: the hour, in 2 digit, 24 hour format (e.g. 18)
• [min]; the minutes, in 2 digit, (e.g. 06)
• [sec]: seconds, in 2 digit, (e.g. 06)
• [group]: the parent group of the user associated to the recording. NOTE: this assumes the user has only one parent group, otherwise the results are unpredictable.
• [grandparentgroup]: the grand parent group of the user associated to the recording. NOTE: this assumes the user has only one parent group, and one grandparent group, otherwise the results are unpredictable.
• [email]: email address of the user associated to the recording.
• [firstname]: first name of the user associated to the recording.
• [lastname]: last name of the user associated to the recording.
• [<tagname>]: a tag type associated to the recording (e.g. [nativecallid])
• [ucid]: UCID associated to the recording, if CTI is used and yields this metadata.
• [trunkgroup]: trunk group associated to the recording, if CTI is used and yields this metadata.
• [trunkmember]: trunk member associated to the recording, if CTI is used and yields this metadata.
• [nativecallid]: native call id associated to the recording, if CTI is used and yields this metadata.

Programs Priority

Since multiple programs may be defined, a legitimate question that often comes up is: what happens when a given recording meets the criteria of two or more programs? Which program(s) gets priority and which one(s) decides on the fate of the recording?

The answer is that it depends on the priority configuration. By default all deployments give priority to "negative" programs, i.e. to programs that would cause the rejection of a recording. Hence, even if many programs report that a recording should be kept, all it takes is for one program to reject the recording for it to be discarded.

This behavior may be reversed in the database configuration to ensure that one "positive" program guarantees that the recording gets kept.

All recording programs get evaluated for every new recording. When multiple programs agree that a recording should be kept, they all get associated to that recording.

Services

Media Servers are represented in OrkWebApps by logical entities called services. Sevices may represent other types of servers such as SMTP servers for sending emails and Tracker servers representing OrkTrack processes.

In the context of media servers, services are used to link the recordings' metadata in the database to the corresponding media files: every recording's metadata has a reference to a specific service. When a recording is moved to another location described by another service, its service reference is modified accordingly to keep that association. Services also define the parameters needed to access the media files by URL, directly on the local disk, or by ssh/sftp or AWS S3 API for remote servers.

There are 5 types of services that can be defined:

• Audio
• Screen
• File Server
• SMTP Server
• Tracker
• WebUI

The first three refer to media servers. The Audio and Screen types describe typical recorder servers, while the File Server refers to servers dedicated to general media file storage only. Those three types inherit the same configurable attributes as shown below, while the SMTP, Tracker and WebUI services have different sets of parameters.

Services for recorders are created automatically by Oreka when the recorders are started. The recorders sign into OrkTrack and register themselves. These services may be later edited by the administrator, e.g. for configuring ssh/sftp access information and file absolute path.

File server type services are typically used with the Media Manager move and copy programs to designate a target location where to move or copy files. These target locations may be typical servers accessible by ssh/sftp, AWS S3 storage locations or a CallMiner Analytics platform accessible using the CallMiner Ingestion API (CM-API). Regardless of their nature, they always need to be created manually by the administrator.

Creating Scorecards

The first step in setting up QM is to create one or more scorecards. Scorecards establish the criteria that will be used to evaluate a recording. Scorecards may include one or more sections which in turn may host one or more questions. Each question may allow several answers with a different score associated to each. Sections and question scores may also be weighted differently.

Other scorecard features are:

• Auto-fail: some answers may be designed to automatically fail the scorecard results. This allows flexibility in giving great weight to some very important criteria.
• Exclusion: some answers may be designed to have no effect on the final score. For example, a not applicable (N/A) answer typically indicates that the corresponding question is moot, and should be omitted from the scorecard results calculation.
• Comments: there are multiple level of comments that can be added to a scorecard including the scorecard itself, its sections as well as the answers.

Creating a scorecard requires filling a CSV scorecard template file. Please refer to How do I configure a scorecard for QM? for more details on the format of the scorecard CSV file.

If a scorecard needs to apply to more than one group, one of two approaches may be used:

• Create two separate identical scorecards, one for each group, with a slightly different name, and associate them separately to each group,
• Create a parent group and make both groups in question its member or children groups, then associate the scorecard to the parent group. The two subgroups will automatically inherit access to that scorecard from their common parent group.

Importing Scorecards

Once a scorecard is created and configured to be associated to a group, it may be imported in OrkWebApps in the Scorecards page. Errors in the scorecard are detected and reported by the import function, and will cause the entire scorecard to be rejected.

Scoring calls based on scorecards

To "score" a recording, click on the scorecard icon in the OrkWebApps "Browse" page or go to the recording details page and select the "Scorecards" tab. OrkWebApps looks for the group(s) associated to recording's user, and makes any scorecard template associated to that user's parent groups available for the evaluation. Once the call is “scored”, the scorecard results may be saved for later review as well as for generating QM statistical reports.

Generating QM reports

Reporting on QM is possible through several reports with the ability to define a slew of filters for greater flexibility. In fact, all search filters that are available in the Browse are applicable to the QM statistics reports below. Reports may be generated in 3 formats: PDF, HTML and CSV unless explicitly specified otherwise. Here is a summary of the types of reports available:

• Scorecard results report (PDF only)
• Group report: a summary report displaying the number of scored calls, minimum/average/maximum score for each group.
• Group Detailed report: a report detailing the number of scored calls, minimum/average/maximum score for each question in each scorecard grouped by groups.
• User report: a summary report displaying the number of scored calls, minimum/average/maximum score for each user.
• User Detailed report: a report detailing the minimum/average/maximum score for each question in each scorecard grouped by users.
• Scorer report: a report listing the score and summary info of every recording grouped by scorers.

Securing access to your media files

Securing access to media files in Oreka ensures that only users legitimately logged in to OrkWebApps are allowed accessing the files. In addition to the Access Policies, the following configuration is needed at a system level:

• For each server that is storing recordings, configure the web server (e.g. tomcat or httpd) to allow access to the files only from the server where OrkWebApps is installed. Direct URL access to the files from user client PCs will no longer be allowed.

  • For single-server deployments, modify tomcat's server.xml file as follows:

    <Context path="/audio" docBase="/var/log/orkaudio/audio" >
    
        <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127.0.0.1" deny=""/>
    
    </Context>
    <Context path="/screen" docBase="/var/log/orkaudio/screen" >
    
        <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127.0.0.1" deny=""/>
    
    </Context>
    

  • For multi-server deployments, modify every recorder's tomcat's server.xml as above, but change the "allow" field content to include the hostname or ip address of the server where OrkWebApps is running.

Securing access to the application (OrkWebApps) using TLS

Secure access to OrkUI uses TSL, and requires that the URL to the application rely on https instead of http. To configure this functionality, simply edit the web.xml file stored under $tomcat/webapps/orkui/WEB-INF , and modify the line:

<transport-guarantee>NONE</transport-guarantee>

to

<transport-guarantee>CONFIDENTIAL</transport-guarantee>

After this change, access to OrkUI becomes https://localhost:8443/orkui . If you continue using http://localhost:8080/orkui , you will be automatically re-directed to the new https URL.

Note: the change above assumes that Tomcat was installed by the OrecX OrkWebApps installer. The installer performs some customizations to the Tomcat server.xml file to make the functionality above accessible. Contact support@orecx.com if your server.xml file does not contain these customizations.

OrkUI Language Support

The main OrkUI localization files are available in the $tomcat/webapps/orkui/assets/i18n folder.

• English : en_new.json
• French : fr_new.json
• Italian : it_new.json

Reports language files are stored in the $tomcat/webapps/orktrack/reports/i18n folder and have the following naming format i18n_en.properties.

For other languages, please contact support@orecx.com.

Changing your Browser's Language

The selection of the OrkWebApps language usually occurs automatically by default, and depends on your Operating System language. For example, if you are running the French version of Windows, OrkWebApps will appear in French by default.

If you would like to change the displayed language, you would have to use the Language Options of your Browser.

Overview

OrkWebApps Clustering allows multiple OrkWebApps to synchronize their caches and real-time(live) data which enables them to operate in a HA (High Availability) environment, or in a Load Balancing configuration. OrkWebApps Clustering assumes that there is a shared underlying database for persistence.This can be one physical database or a replicated database setup. The actual clustering occurs between the OrkTrack component of OrkWebApps as shown in the Figure A below.

Figure A

Clustering accomplishes two main end goals:

1. Ensures that any provisioning of resources that need to be cached for faster access is propagated to peers. This includes provisioning of users, groups, programs and services.
2. Ensures that any real-time (live) data, such as metadata about live recordings are propagated to peers. This includes all recording start and stop messages, keep, discard and tagging live functionalities.

High Availability (HA)

OrkWebApps Clustering for HA helps provide redundancy and eliminates single-point-of-failure scenarios. In a HA environment, only one OrkWebApps is operational at any one point in time. All messages from all processes as well all user sessions are directed to the active node. See Figure B below.

Figure B

The system may be manually switched over, or configured to automatically switch over in case of failure (using tools external to OrkWebApps). When this occurs, the roles of the nodes are swapped, and all traffic is redirected to the second node. As shown in Figure C below, after a switch over, the nodes swap roles, the Standby node becoming Active while the Active goes into Standby mode. Synchronization also changes direction.

Figure C

Load Balancing

In a load balancing setup, all nodes are active and continuously share their state. Hence, all nodes are responsible for forwarding their API inputs to their peers. In such a setup, user sessions can target any OrkUI as long as the session always communicates with that OrkUI (sticky session). Different recorders may target different OrkTracks

Figure D

Configuration

OrkUI Branding

OrkUI provides the ability to customize the following attributes:

• The product URL
• The two main background colours.
• The corresponding text colours.
• The brand logo
• The company logo
• The favicon image (little icon that appears on the Browser tab)
• The product title
• The About Dialog labels:
  • The "About OrkUI" header
  • The OrkUI build label
  • The OrkTrack build label
  • The Copyright product label.

{
  ...
  "brandingOptions": {
    "appTitle": "",
    "images": {
      "productLogo": "assets/images/brand-logo.png",
      "companyLogo": "assets/images/company-logo.jpg",
      "faviconLogo": "favicon.ico"
    },
    "about": {
      "header": "OrkUI",
      "uiLabel": "OrkUI",
      "restLabel":"OrkTrack",
      "copyright": "© 2018 OrecX."
    },
    "color": {
      "primaryColor": "#003366",
      "secondaryColor": "#93AA47",
      "primaryTextColor": "white",
      "secondaryTextColor": "white"
    }
  }
}

{
  ...
  "brandingOptions": {
    "appTitle": "",
    "images": {
      "productLogo": "/assets/abc-logo.png",
      "companyLogo": "/assets/abc-logo.jpg",
      "faviconLogo": "/assets/abc.ico"
    },
    "about": {
      "header": "ABC",
      "uiLabel": "ABC",
      "restLabel":"ABC-BE",
      "copyright": "©2021 ABC."
    },
    "color": {
      "primaryColor": "#FF5003",
      "secondaryColor": "#93AA47",
      "primaryTextColor": "white",
      "secondaryTextColor": "white"
    }
  }
}

OrkUI Configuration

The OrkUI configuration file is located in the $ORKWEB_HOME/orkui folder, which is typically /etc/orkwebapps/orkui (Linux) or C:/Program Files/OrkWebApps/orkui (Windows). This folder contains the OrkUI configuration file app.config.json.

The recent OrkWebApps installers will configure a context path /assets/ in Tomcat's server.xml as <orkweb_home>/orkui/. This is the context path needed for OrkUI to access that configuration file as well as other customized assets such as the logo, product and favicon files. In the absence of any of these, OrkUI will fall back on its own internal default settings.

The file is a JSON file, with the following configuration sections:

{
  "serverHostname": null,
  "serverPort": null,
  "configOptions": {
    "SAML": {
      "samlLoginUrl": ""
    },
    "formats": {
      "dateFormat": "MM-DD-YYYY",
      "timeFormat": "hh:mm:ss a",
      "dateTimeFormat": "MM-dd-yyyy hh:mm:ss a",
      "durationFormat": "HH:mm:ss"
    },
   "defaults": {
      "initialPageSize": 20,
      "pageSizeOptions": [10,20,50,100]
    },
    "password": {
      "passwordRecovery": true
    }
    "orkMPx": {
      "quickRewindSec": 10,
      "quickAdvanceSec": 30

    },
    "evaluations": {
      "legacy": false
    }
...
  },
  "brandingOptions": {
   ...
  }
}

The configuration fields are described below.

serverHostname

This field specifies the domain name of the OrkTrack server. If left null, it assumed that OrkTrack is deployed on the same server.

serverPort

This field specifies the port to use for the OrkTrack server. If left null, it will use the same port used for OrkUI.

samlLoginUrl

This field is used with Single Sign-On applications such as SAML. When present, all access to OrkUI URLs without an access token will redirect to the samlLoginUrl URL.

See SAML SSO for additional information.

"recordings": {
  "initialPageSize": 15,
  "pageSizeOptions": [10,15,20,50,100]
},

"password": {
  "passwordRecovery": true
}

"orkMPx": {
  "quickRewindSec": 10,
  "quickAdvanceSec": 30
}

"evaluations": {
  "legacy": true
}

Scorecard CSV File Format

• A line starting with the # symbol is considered to be a comment.
• A non-comment line must contain comma-separated fields. The number of fields depends on the type of entry. There are 4 types of entries, distinguishable based on the first field:
  • Scorecard, name, comments
  • GroupID, ID
  • Section, name, weight, comments
  • Question, name, weight, comments
  • Answer, description, value, excluded, autofail, comments
• Fields that are empty may be left blank. If one or more fields at the end of the line are empty, they may be simply omitted. OrkWebApps will assign to them default values. Extra trailing fields that should not be there are simply ignored.
• Entries are hierarchical and at least one entry is required at each level, i.e. a scorecard that does not have separate sections must define a section anyway. The only entry that is optional is the Group. If not specified, the scorecard is not associated to any group (not recommended).
• A file may include multiple scorecards.
• About the fields:
  • "id" is the oreka unique ID of the group the scorecard is to be associated with.
  • "name", "description" and "comments" fields are of type String. The string fields must be surrounded by double-quotes, e.g. "Group Name", and should not include any double quotes, commas, etc within them (for now)
  • "weight" fields are decimal values (stored as float). Default weight value: 1.0
  • "value" field is a number (stored as integer).
  • "excluded" and "autofail" are booleans, and take values: true or false, yes or no, 0 or 1. Defaults: false for both.
  • The keywords (Group, Scorcard, Question, Answer) are case-insensitive. They are mandatory at the beginning of the line.
  • name, description and value fields are mandatory. The rest are optional but must be represented (i.e. by a comma separator). See above for the default values for optional fields.

Scorecard CSV File Example

# Oreka sample scorecard CSV file: Scorecard_Generic_Example2_Sales.csv
# Below
is a summary description of the fields required:
#
#   Scorecard,name,comments
#   GroupID,id
#   Section,name,weight,comments
#
Question,name,weight,comments
#   Answer,text,value,excluded,autofail,comments
#
Scorecard,"Sales QA
Form",
GroupID,15
#
Section,"Opening Call",,""
Question,"Professional Greeting - Intro",,""
Answer,"No",0,,,
Answer,"Yes",1,false,false,""
#
Section,"Information
Verification / Data Collection",,""
Question,"Verify Zip Code",,
Answer,"No",0,,,
Answer,"Yes",1,,,
Question,"Collect
Name",1.0,""
Answer,"No",0,,,
Answer,"Yes",2,,,
Question,"Collect Phone Number",1.0,""
Answer,"No",0,,,
Answer,"Yes",2,,,
Question,"Verify
if Existing Customer and if Residence or Business",1.0,""
Answer,"No",0,,,
Answer,"Yes",2,,,
#
Section,"Establishing
Purpose of Call",1.0,""
Question,"Reason for Call",1.0,""
Answer,"No",0,,,
Answer,"Yes",1,,,
Question,"Lead
Source",1.0,""
Answer,"No",0,,,
Answer,"Yes",4,,,
#
...