6 Recording of Utterances

VoiceObjects allows storing recordings of utterances made by the caller during normal speech recognition, e.g. in Input or Menu objects. This includes utterances that lead to successful recognitions (filling a slot in an Input object, selecting a Menu item, activating hyperlinks etc.), as well as those that trigger a No Match event on the media platform.

This chapter explains how this feature is set up and made use of in a voice application. It starts with Introducing Utterance Recording showing up some use cases and explaining how to quick start this feature.

The remainder of the chapter describes the full range of the utterance recording feature:

· Setting up Utterance Recording for a Service
explains how to configure utterance recording in your installation, on server, site and service level.

· Defining What to Record
describes how you define on dialog object level which recordings are to be stored.

· How the Recordings are Stored
explains the folder and file name structure of stored recordings, so you can easily find the recordings you are looking for.

· Collected Data in Infostore describes what kind of data about recorded utterances is stored in Infostore. Refer to the Analyzer Guide for a detailed description of reports available to analyze caller behavior through the recordings.

· Example Setups
provides a step-by-step description of sample configurations, which helps you in setting up utterance recording for your specific needs.

Introducing Utterance Recording

Use cases

Being able to listen to what a caller said at specific points in a voice application provides valuable insight into the usage of the application. It can show issues with grammar definitions, with misleading prompts, even with ill-designed menu or dialog flow structures in your application. Evaluating caller utterances is an essential part in tuning a voice application and assessing its overall functionality, i.e. making sure that it does what it is supposed to do.

A typical use case of analyzing the usage of an application is to look at input states that produce a significantly high number of No Match events. Listening to the recordings immediately tells you about bad grammar or prompt design.
But analyzing successful recognitions can also be worthwhile. An utterance string can only consist of tokens found in the grammar activated for a specific dialog step. E.g., if a grammar allows saying “yes” only, but the caller says “yes please”, it might happen that the recognizer matches this to “yes” and returns a confidence value above the confidence level (the threshold for successful recognition). In this case, the utterance string found in Infostore is “yes” and the confidence value suggests a successful recognition. This might lead to the assumption that the grammar is fine and does not need any change or refinement, whereas in fact it falls short of the actual usage of the application by the callers. By exploiting the utterance recording feature of VoiceObjects, you can easily detect input states that cause problems and listen to the user interaction that took place.

i8 Note: In pure DTMF applications, utterance recording is not available, as there are no spoken utterances to record. If utterance recording is activated in a mixed input mode application (Voice+DTMF), all DTMF inputs are ignored, while all voice inputs are recorded.

Quick start

This paragraph is a quick introduction to get you started on utterance recording with VoiceObjects.

i8 Note: Utterance recording only works on media platforms that are fully compliant with VoiceXML 2.1. Check Appendix A – Media Platform Drivers in the Deployment Guide to see whether your platform supports this feature. If utterance recording is not supported by the platform, switching it on has no effect.

To turn on utterance recording for all dialog objects of your application, perform the following steps:

1. On a Service object of your choice, select Enable utterance recording in the Logging Parameters section.

2. Enter an Utterance recording path that is valid on the machine that runs your VoiceObjects server instance.

3. Redeploy the service.

When calling the service through the media platform, the recordings of all utterances that lead to No Match events or to a successful recognition will be stored below the path you defined in the Service object. The recordings are stored in subfolders, starting with a folder for the service name.

Setting up Utterance Recording for a Service

Utterance recording can be switched on and off globally on Server and Service objects. Within an application, a developer can define for which objects recordings should be stored, and in which scope – for all recognized utterances, only for those that triggered a No Match event, or for both.
Since the number of recorded audio files stored for a service can be substantial, depending on the call volume, it makes sense for a Server or Site Administrator to be able to switch this off globally on a logical server, i.e. for all services hosted thereon, and on a service, i.e. for all objects defined in an application.

Server configuration file definition

Recordings of utterances are stored in a specific subfolder structure, including information on the exact date & time of the recording, the service name, etc. The base folder in which this structure is written can be defined by the user. In the VOServer_Configuration.xml file located in the Platform\WEB-INF\config directory of your VoiceObjects installation, define the base path in the element <utteranceRecordingBasePath>. This path can be pointing to a directory on the local file system of the machine that runs the VoiceObjects server instance, or to a shared network destination. The latter makes sense in a cluster setup. Each server instance stores the recordings separately, so make sure the base path is defined correctly, typically by setting it to the same value on all server instances.

A setting pointing to the local file system could look like this:

<utteranceRecordingBasePath>C:\VoiceObjects\Platform\Resources\<utteranceRecordingBasePath>

In addition to the physical path, a base URL can be defined in the element <utteranceRecordingBaseURL>. It will be used by VoiceObjects Analyzer to locate the files through its web interface, so that a report can allow listening to the recordings by simply clicking a hyperlink. To be able to retrieve the files, a web server must be setup to deliver them.

A setting pointing to a web server could look like this:

<utteranceRecordingBaseURL>http://myserver.com/Resources/<utteranceRecordingBaseURL>

Besides the definition of the base path and URL at server level, additional path and URL settings can be made for a site (in a User object), and in the Service object.
For more information on how and where recordings are stored, and on how these paths are connected, see the paragraph How the Recordings are Stored below.

Full duplex call recording

For selected media platforms it is possible to control full duplex call recording in combination with utterance recording. This is currently supported for all Voxeo drivers as well as for VoiceGenie 7.2 and Genesys Voice Platform 8.0. Linking call recording to utterance recording ensures that the same coverage filter is used in both cases.

Full duplex call recording is enabled by the following switch in the components_VOServer.xml file located in the Platform\WEB-INF\config directory of your VoiceObjects installation:

When enabled, each call that uses utterance recording automatically creates a full duplex call recording. For details on where the call recording files are stored, refer to the documentation of your media platform.

User object definition

If your installation is working with sites, you can define a base path for utterance recordings that gets prefixed to the path definitions of all services in a site (and is itself prefixed by the base path defined in the Server configuration file definition, if given). This base path is set in the User object of the root Site Administrator.

At the same place, you can define a base URL as described above.

VoiceObjects Desktop

In the Site Settings in the Security section of the User object, enter the path in the Utterance recording path field and the URL in the Utterance recording URL field:

Setting a path or URL is not required, if the server configuration file defines one. For more information on how and where recordings are stored, see the paragraph How the Recordings are Stored below.

VoiceObjectsXML

In the <user> element, use the attributes utteranceRecordingPath and utteranceRecordingURL to define the base path and URL, respectively. The default for both is the empty string.

Server object definition

The Server object allows controlling if recordings of utterances are generally allowed or not.

VoiceObjects Desktop

In the Configuration Parameters section of the Server object, select the check box Enable utterance recording to enable utterance recording. It is selected by default.

If you want to switch off utterance recording globally for all services hosted on that server, clear this check box.

Any change made to this setting is only activated after resetting the server. To do this, click Reset in the context menu of the logical server in the Control Center (note that this will terminate all current dialog sessions running on that server).

In Desktop for Web the current setting of Enable utterance recording is displayed in the info box of a server in the Control Center. It can be either Enabled or Disabled.

VoiceObjectsXML

In the <server> element, use the attribute enableUtteranceRecording to control utterance recording on server level. It can take the values true or false. The default is true.

Service object definition

The Service object offers options to switch utterance recording on and off, define a base path to store the recordings in, set a coverage filter to restrict the number of recordings made, and set initial values for the two dialog context settings RECORDUTTERANCES and RECORDINGSCOPE.

VoiceObjects Desktop

In the Logging Parameters section of the Service object there are four settings that control utterance recording on service level:

The check box Enable utterance recording controls if recordings of utterances are generally allowed for this service, or not. It is clear by default, so that utterance recording is not automatically turned on for new services. Note that this setting can be overridden by the server. If the corresponding setting on the Server object is disabled, the service setting is overridden. If the setting on the Server object is enabled, the Service object can decide to enable or disable it.

The text field Utterance recording path allows defining a path that gets prefixed to all stored recordings. You can leave this field empty, if the site and/or server settings provide paths. For more information on how and where recordings are stored, see the paragraph How the Recordings are Stored below.

The text field Utterance recording URL allows defining a URL that gets prefixed to all stored recordings within reports generated by VoiceObjects Analyzer, which offers to listen to the recordings from within a report. You can leave this field empty, if the site and/or server settings provide URLs. For more information on how and where recordings are stored, see the paragraph How the Recordings are Stored below.

The Coverage filter is used to restrict the amount of stored recordings, which can get quite high in high-call-volume deployments. It is a percentage filter that is applied across all dialog sessions for a given service. If it is left at 100%, the default value, then all calls are eligible for utterance recording. A value of 0% has the same effect as deselecting Enable utterance recording. Any other value will affect the given percentage of calls.

The coverage filter for utterance recording is closely related to the coverage filter for System DB logging, to support the scenario described in the paragraph on Use cases above. Listening to caller utterances is typically connected to looking at the recognition results, i.e. utterance strings, confidence values, the context of where the utterance was made, etc. This means that for all recordings stored, you want to have corresponding entries in the input state-related tables of Infostore. This is ensured by the server in the following way:

· If the option Enable Input State logging is selected, then the utterance recording coverage filter is applied after the System DB logging filter. This means that the server first applies the System DB logging filter to arrive at a subset of all calls, and then applies the utterance recording filter on that subset. The result of this is that for all recordings stored, there will be corresponding Infostore data.

· If the option Enable Input State logging is not selected, then the utterance recording filter is applied on its own, i.e. irrespective of the System DB logging filter. In that case, Infostore does not log any input state-related information, so a relation from the recordings to any other information from Infostore cannot be established anymore. As an example, if the filter is set to 50%, half of all calls are eligible for utterance recording.

i8 Note: The evaluation of Enable Input State logging actually relies on the option being selected or not. It does not rely on whether Input State logging is currently active for a session or not. So, if the option is selected, which means you actually intend to enable Input State logging, then even if some runtime problem prevents Input State logging (for instance due to DB failure), the two coverage filters are applied one after the other nonetheless. This avoids the effect in high-call-volume applications that due to a DB problem the amount of utterances recorded suddenly drastically increases (which would be the case if the filters were interpreted independently from each other again).

See some more examples on this in the paragraph Example Setups below.

In Desktop for Web the current setting of Enable utterance recording is displayed in the info box of a service in the Control Center. It can be Enabled, Disabled or Overridden. The Coverage filter percentage value is shown in parentheses behind that:

In the Default Parameters section of a Service object there are two settings that can control on object level if utterances should be recorded, and which utterances:

The setting Record utterances defines the initial value of the corresponding dialog context setting RECORDUTTERANCES, which will be applied on a dialog object if it has its Record utterances property set to Default. It can either be True or False. This setting can be overridden by the service URL parameter vsRecordUtterances. See Defining What to Record for more information on turning on recording for individual dialog objects.

The setting Recording scope defines the initial value of the corresponding dialog context setting RECORDINGSCOPE, which will be applied on a dialog object if it has its Recording scope property set to Default. It can be one of Recognition, No Match, or All. This setting can be overridden by the service URL parameter vsRecordingScope. Again, the paragraph Defining What to Record describes in more detail how recording works on individual dialog objects.

VoiceObjectsXML

In the <service> element, the following attributes can be used:

Attribute	Values	Default
enableUtteranceRecording	true, false	false
recordUtterances	true, false	true
recordingScope	noMatch, recognition, all	all
utteranceRecordingPath	CDATA
utteranceRecordingURL	CDATA
recordingCoverage	0 - 1.0	1.0

Defining What to Record

While you can control on server and service level if utterance recording is generally allowed or not, it is up to the developer of an individual application to define which utterances in which dialog objects should be recorded.

The following dialog objects that interact with the caller offer settings to switch on utterance recording:

· Input

· Menu

· Confirmation

· List

· Hyperlink (the autonomous object in the confirmed version, not the embedded object)

· Pause

These objects have two properties in their respective Options section, Record utterances and Recording scope (Example taken from Input object):

The property Record utterances defines whether utterances should be recorded for this object or not. It can have one of the four values True, False, Always, and Default (the default). The meaning of these values is as follows:

Record utterances	Description
True	Utterances made while processing this dialog object will always be recorded if utterance recording is enabled for the service and the dialog is eligible for utterance recording on the basis of the Coverage filter.
False	No utterances are recorded for this dialog object.
Always	Utterances made while processing this dialog object will always be recorded if utterance recording is enabled for the service regardless of whether the dialog is eligible for utterance recording on the basis of the Coverage filter or not. This option is very useful if you want to apply a Coverage filter to limit the amount of statistical data, but need recordings in a few specific objects for all calls e.g. for security purposes or for subsequent processing.
Default	The value of the dialog context setting RECORDUTTERANCES is taken (True or False). The initial value of this setting can be defined in the Service object or through the service URL parameter vsRecordUtterances; at call time, the value can be changed using the RECORDUTTERANCES function through an Expression object.

See Example Setups for examples of how to define time-dependent utterance recording by using this dialog context setting.
The Record utterances property can also be defined dynamically at call time by linking a Script, Variable, Expression, or Layer object.

The property Recording scope defines in which scope utterances should be recorded in this object. It can be set to one of Recognition, No Match, All, or Default. The meaning of these values is as follows:

Recording Scope	Description
Recognition	All utterances that led to a successful recognition are recorded and stored, i.e., utterances that filled slots in an Input object, selected a Menu item, confirmed or denied a summary in a Confirmation object, navigated in a List object, etc. Activating hyperlinks also falls into this category.
No Match	All utterances that triggered a No Match event are recorded and stored, and no others.
All	All utterances made by the caller are recorded and stored.
Default	The value of the dialog context setting RECORDINGSCOPE is taken (recognition, noMatch, or all). The initial value of this setting can be defined in the Service object or through the service URL parameter vsRecordingScope; at call time, the value can be changed using the RECORDINGSCOPE function through an Expression object. See Example Setups for examples of how to define time-dependent utterance recording by using this dialog context setting.

The Recording scope property can also be defined dynamically at call time by linking a Script, Variable, Expression, or Layer object.

Plug-in object

In a Plug-in object, utterance recording works automatically for all inherited No Match events, for inherited custom and standard navigation as well as for the last successful recognition that happened within the plug-in. In addition, you can write VoiceXML code that manually submits recordings to the server to get stored.

If you want to store the recording of a No Match utterance, put the following code in the corresponding <catch> element, before any other code of that handler:

If you want to store the recording of a recognized utterance, put the following code in the place where the recognition is handled (e.g. in the <filled> section of a field/form), before any other code:

The <data> element submits the recording to the server without leaving the processing context, i.e., processing continues with the next VoiceXML statement after the recording has been sent. The variables savebinaryonly, uttRecSample, returnURL dialogID, and shadow are automatically declared by the server, so you don’t need to declare them yourself.

In the Options section of the Plug-in object, the Record utterances property allows turning on utterance recording for the plug-in, and Recording scope sets the scope, which is applied only to the inherited No Match event handlers and standard and custom navigation, as well as the last successful recognition.

If Record utterances is set to True or Always, the server renders the necessary tuning parameters

and

In addition, it will accept all recordings submitted to it and store them. If the property is set to False, though, any requests to store a recording will be rejected, but processing will continue normally. Thus it is possible to leave the <data> element and all related code in the VoiceXML, but turn off utterance recording if desired.
Again, Default means taking the corresponding dialog context setting.

How the Recordings are Stored

The server stores the recordings in a subfolder structure that reflects the date & time of the session in which the recordings were stored, among other information. This folder structure is prefixed with a base path structure that you can flexibly define yourself on server, site and service level. This section talks about what these folder structures can look like.

Construct the base path

The paragraph Setting up Utterance Recording for a Service describes how to setup paths that get prefixed to the actual path used to store a recording.

The following rules are applied to put together the full path for a recorded utterance:

· The utterance recording path defined in the service always gets applied.

· If a service is run in the system site, the VOServer_Configuration.xml setting <utteranceRecordingBasePath> defines a base path that is put in front of what is defined as utterance recording path in the Service object:

Final base path: [ServerInstancePath] + [ServicePath]

· If the <utteranceRecordingBasePath> definition is left empty, the Service object setting needs to define a full and valid path. Vice versa, if the Service object setting is left empty, the <utteranceRecordingBasePath> must define a valid path.
Defining the <utteranceRecordingBasePath> is useful for installations that do not work with sites, where you might have many services running on the same server. The Service objects then don’t require an utterance recording path to be set.

· If a service is run in a non-system site and there is no utterance recording path defined in the site, the VOServer_Configuration.xml setting <utteranceRecordingBasePath> again defines a base path that is put in front of what is defined as utterance recording path in the Service object:

Final base path: [ServerInstancePath] + [ServicePath]

· If a service is run in a non-system site and there is an utterance recording path defined for the site, then the VOServer_Configuration.xml setting will be ignored and the utterance recording path will be used instead and put in front of the Service object setting (if there is any).

Final base path: [SitePath] + [ServicePath]

This is useful in particular in managed service provider installations that work with sites, where it must be possible to define separate utterance recording base locations for each site.

i8 Note: The path resulting from these concatenations must be a valid path that the server can write to, and it must end with a back-slash. If the path is not valid, no recordings will be stored by the server instance running your service.

The same rules apply when putting together the Utterance recording URL, which is used by VoiceObjects Analyzer to provide hyperlinks to the recordings, that the user can click to listen to them.

The subfolder structure

Since the number of recordings can be substantial for a high call volume application, the server stores the recordings in a predefined subfolder structure, reflecting the date & time of the session in which the recordings were made.

This folder structure looks as follows:

Base/VSN/YEAR/MONTH/DAY/HOUR/MINUTE/SESSION/

All time-related parts correspond to the timestamp of when a session was started, which is the same timestamp used in Infostore. This enables you to relate the utterances to a record in Infostore.

The following table describes what each part of the folder structure is about:

Folder Part	Description
Base	The base path constructed on the basis of the server, site, and service settings described in the paragraph Construct the base path above
VSN	The VSN (=reference ID) of the service for which the utterances are stored
YEAR	A four-digit number reflecting the year part of the timestamp
MONTH	A two-digit number reflecting the month part of the timestamp
DAY	A two-digit number reflecting the day part of the timestamp
HOUR	A two-digit number reflecting the hour part of the timestamp, in 24h format
MINUTE	A two-digit number reflecting the minute part of the timestamp
SESSION	The dialog ID of the session the utterances are stored for

The filename structure

A recording gets stored under a filename that follows a clear naming convention covering details on the dialog object in which the recording was made.

The filename will always look as follows:

RecCount_ObjectType_ObjectName_Phase_RecScope_OccCount.Extension

Filename Part	Description
RecCount	A counter from 1 to N over all recordings made for a dialog session. This allows following the order of the recordings according to the actual dialog flow. The counter includes recordings made by Recording objects. The files generated by Recording objects are typically located somewhere else, so that gaps in the numbering may occur here.
ObjectType	The type of the object in which the recording was made (e.g. “Input”).
ObjectName	The name of the object in which the recording was made. The name will be cut off after 20 characters and any character other than [a-z] \| [A-Z] \| [0-9] \| “_” \| “-“ will be removed.
Phase	The “phase” of the object in which the recording was made, independent of whether it was a recognition or a No Match recording · for Input objects, this is always "Request" · for Confirmation objects, this is either "Conf " or "Corr", depending on whether the recording was made during the confirmation or the correction phase of the object · for Menu objects, this is always "Selection" · for List objects, this is always "Navigation" · for Pause objects, this is always "Wakeup" · for Plug-in objects, this is always "Request" · for confirmed Hyperlink objects, this is always “Conf”
RecScope	The recording scope information. Can be either Reco, for all successfully recognized utterances, or NM, for all utterances that activated the No Match event. In Plug-in objects, this will be Unknown, as the server cannot know the scope.
OccCount	The occurrence count for the object in the current session.
Extension	The file extension of the recording, which is platform-dependent.

A typical filename, together with the full path definition, could look like this:

C:\VoiceObjects\Platform\RecoLogs\PrimeInsurance\2007\02\08\10\53\OVAPac16172d0000000000001c8300000107fa50e2d6\3_Confirmation_PresentSummary_Corr_Reco_1.wav

This would be the recording of a recognized utterance made in the correction phase of the first occurrence of a Confirmation object called Present Summary, in a session that started at 10:53 A.M. on February 2nd 2007.

Using the Expression function LASTRESULT with the argument recordingpath the physical path of the last recorded utterance can be retrieved during the dialog. The use case for this is to be able to submit the recording (through its path information) to a backend for tasks such as speaker verification or identification. With the argument recordingurl the corresponding URL can be retrieved, usable for playback during a call. Note that for this the coverage filter must be set to 100% in order to have all recordings of all sessions available.

Failure to store a recording

If a server instance cannot write to the directory where the recordings are to be stored, it writes a corresponding WARN log message and also sends a notification, if enabled. In addition, it switches off utterance recording for all concurrent sessions on the same service as well as for all future sessions coming in on this service. This will last 5 minutes, after which the server tries again. If writing the recording works again, utterance recording will be switched back on.

The server first stores the recorded file in a temporary directory and then moves this file to the final path. The temporary directory can be set by adding the parameter -Djava.io.tmpdir within the start script of a VoiceObjects server instance. Alternatively, you can set the parameter TempDir within the configuration file of the selected Web application server (e.g. Jetty). When using a SUN JDK this is automatically done by the installer during the installation of the VoiceObjects platform.
If this directory cannot be written to, the server also writes a WARN log message, sends a notification, and turns off utterance recording as described above.

Collected Data in Infostore

If Input State logging is enabled for a dialog session, Infostore writes information about all recorded utterances, so that the recordings can easily be associated with dialog steps of a specific application.

The recordings itself are not stored in the Infostore database. They are only persisted on the hard drive as described under How the Recordings are Stored. Instead, the complete path and file name information of the recording as well as the utterance recording URL are written to a dedicated table.

As the server where the recordings are stored, the VoiceObjects server instances, and the reporting environment might not be in the same (sub-)network, the recording URL should be used to retrieve the recordings.

The following information is stored for each recording:

· The size of the recording in bytes.

· The duration of the recording in milliseconds.

· The recording category (Utterance Recording or Recording Object).

· The recording type (Recognition, Hyperlink, Nomatch 1-4, Audio or Video recording).

· The recording URL, path and filename.

In addition more detailed information about the session and the input state can be retrieved by combining the utterance recording table with the other Infostore tables.

For a more in-depth description of the table structure refer to Chapter 3 – The Physical Data Model in the Infostore Guide.

Refer to the Analyzer Guide for a detailed description of reports available to analyze caller behavior through the recordings.

i8Note: VoiceObjects Infostore does not delete any records from the table storing the utterance recordings. Thus, when manually deleting recording files associated entries in Infostore might still point to files that no longer exist.

Example Setups

This paragraph describes some scenarios of enabled utterance recording that might help you in setting this feature up in your environment.

Static, unfiltered utterance recording in a single-tenant environment

Scenario

You run your services in the system site of a single server instance setup and do not have any custom sites in your environment. You want to enable utterance recording by default for your main Menu object and for all calls coming in, to find out what callers say when activating Menu items. Input State logging is switched on, so you see the corresponding entries for application usage in Infostore. The files shall be stored below a path of the local file system of the machine that runs VoiceObjects Server.

Setup

1. In the server configuration file of your single server instance, leave the <utteranceRecordingBasePath> definition undefined, as you want to define different base paths for your different services.

2. In your Server object, make sure Enable utterance recording is selected. If not, select it, save the object and reset the server.

3. In your Service object, set Utterance recording path to C:\VoiceObjects\UtteranceRecordings\ to instruct the server to store all recordings below this path for this service. Switch utterance recording on by selecting Enable utterance recording. Set the Coverage filter to 100%. Set Record utterances to False, so that all dialog objects that have this setting at Default have utterance recording turned off, and set Recording scope to All.

4. In the dialog object where you want to have the utterances recorded (the main Menu object), set Record utterances to True, to always activate the recording for this object. Set Recording scope to Default, if you want to be able to control the scope through the dialog context setting RECORDINGSCOPE, otherwise to All, if you know you always want recordings for all utterances.

Redeploy your service, and all utterances made in the main Menu object should be recorded below the C:\VoiceObjects\UtteranceRecordings\ folder, starting with a subfolder for the service.

In case you want to switch off utterance recording temporarily for that service, e.g. for maintenance purposes, deselect Enable utterance recording on the Service object and save it. After having redeployed the service, no utterances are stored anymore, even though the Menu object has Record utterances set to True, since the Service object is a general switch that overrules individual dialog objects.

Static, filtered utterance recording in a multi-tenant environment

Scenario

You have an environment with sites in a clustered server setup. In a given site “Site1”, you want to enable utterance recording for No Match utterances, in order to find out what goes wrong when the ASR engine cannot recognize a caller input. You want that for all objects of a specific service, but since your service is called by more than 200,000 callers a day, you want to store recordings only for 50% of the calls, to reduce the amount of data. Input State logging is switched on, so you see the corresponding entries for application usage in Infostore. It is set to 80%, also to reduce the amount of data stored. The files are to be stored in a shared network path.

Setup

1. Since you want to be able to define different base paths for your sites leave the <utteranceRecordingBasePath> empty in the server configuration files of all your server instances.

2. In your Server object, make sure Enable utterance recording is selected. If not, select it, save the object and reset the server.

3. In the User object of the root Site Administrator of your site, set Utterance recording path to \\UttRecServer\UttRecordings\site1\ to instruct the server to store all recordings below this path for any service in this site.

4. In the specific Service object associated with your application, you do not need any utterance recording path definition, as the corresponding site definition already takes care of the path. Switch utterance recording on by selecting Enable utterance recording. Set the Coverage filter to 50%. Set Record utterances to True, so that all dialog objects have utterance recording turned on by default, and set Recording scope to No Match.

5. In all dialog objects, make sure that both Record utterances and Recording scope are set to Default.

Redeploy your service. Now the server applies the Input State logging filter of 80%, i.e. it ignores 20% of all calls. For these 80%, Infostore writes detailed data on application usage. Now the server applies the utterance recording filter, so that 50% of the 80% of dialog sessions will have utterance recording enabled, and from these remaining sessions all utterances that activate the No Match event will be recorded and stored below the \\UttRecServer\UttRecordings\site1\ folder. All in all you’ll have the No Match utterances of 40% of all calls coming in on your service.

Time-dependent, filtered utterance recording in a single-tenant environment

Scenario

You run your services in the system site of a single server instance setup and do not have any custom sites in your environment. You want to enable utterance recording depending on the time of day. Each morning from 8 A.M. to 9 A.M., when a certain part of your customer base calls in, you want to activate utterance recording for No Match utterances in a specific Input object of your application for 75% of all calls coming in. Input State logging is switched off, as you are not interested in the general logs for application usage in Infostore. The files shall be stored below a path of the local file system of the machine that runs VoiceObjects Server.

Setup

1. In the server configuration file of your server instance, set <utteranceRecordingBasePath> to C:\VoiceObjects\UtteranceRecordings\ to be used as the base path for the utterance recordings of all of your services.

2. In your Server object, make sure Enable utterance recording is selected. If not, select it, save the object and reset the server.

3. In your Service object, leave Utterance recording path empty, since the server configuration file definition takes care of the base path. Switch utterance recording on by selecting Enable utterance recording. Set the Coverage filter to 75%. Set Record utterances to False, so that all dialog objects that have this setting at Default have utterance recording turned off, and set Recording scope to No Match.

4. In the dialog object where you want to have the utterances recorded (the affected Input object), set Record utterances to Default, to be able to turn it on and off dynamically. Set the Recording scope to No Match.

5. Create an Expression object called Current Hours. As the function select NOW and as the first argument enter HH. This Expression object will always return the current hours, in a 24h time format, and will be needed to detect the current time of day.

6. Create an Expression object called Set RECORDUTTERANCES to True. As the function select RECORDUTTERANCES and as the first argument enter true.

7. Create an Expression object called Set RECORDUTTERANCES to False. As the function select RECORDUTTERANCES and as the first argument enter false.

8. Create an If object called Time is between 8am and 9am. As the function of the embedded expression select “=”; as the first argument link the Expression object Current Hours, and as the second argument enter “8”. In the THEN section, link the Expression object Set RECORDUTTERANCES to True. In the ELSE section, link the Expression object Set RECORDUTTERANCES to False.

9. Put the new If object at the beginning of your dialog flow (e.g. in the preprocessing of your root Module object).

Redeploy your service. When a call comes in, the server will first check the current time and set the RECORDUTTERANCES dialog context setting accordingly. When it comes to the Input object, utterance recording is turned on if the call comes in between 8 A.M. and 9 A.M. and turned off at all other times. For 75% of all calls in that time frame, all No Match utterances made in the Input object will be recorded below the C:\VoiceObjects\UtteranceRecordings\ folder, starting with a subfolder for the service. Since Input State logging has been turned off, the full 75% filter is applied (even if the filter of System DB logging is set to something other than 100%). The effect of having Input State logging turned off is that none of the recordings stored will have corresponding entries on application usage in the Infostore tables.