Tokens and events in call logs

The following list shows groups of standard Speech Server event codes. Production sites might encounter additional codes and tokens not described here.

Event records that detail recognizer executions, recognitions, special events (such as compilation and cache activities), and caller utterances. These records contain information such as:

• Timestamps of each event
• Recognition results with confidence scores
• Timing statistics of each recognition event
• Names of audio files containing caller utterances

The following list shows groups of standard recognition event codes. Production sites might encounter additional codes and tokens not described here.

These events are logged by Nuance Dialog Modules, and by applications that need the rich reporting. Every phone call to the system is a session that includes many of these events. See Application-defined logging events.

These events are based on Nuance Dialog Modules—which logs them automatically—and use the following terminology:

• Modules are voice application routines that collect one or more pieces of related information, such as an account number or address. Nuance Dialog Modules are building-blocks that automate many of these routines.
• Phases occur when a module collects multiple different, but related pieces of information. For example, an address module collects a street number and name, a city, and a postal code. These are each a different phase of the module. However, collecting different information of the same type typically happens in one phase, such as when collecting a first and last name.
• A Try is a set of one or more recognition steps attempting to get a piece of information, and consisting of a single collection step and zero or more confirmation steps. When a collection has a high confidence, the try usually ends without a confirmation. The try also completes when the collection is confirmed. Rejecting a confirmation ends a try and typically starts another one with the same module.
• A Step is single recognition request and result, which can include collecting an utterance or DTMF, or resulting in a time-out or hang-up.
• A Slot is a specific type of information collected from the module, such as a departure city. A multiple-slot module can collect more than one piece of information, such as the make, model, and year a car was made.

The following list shows groups of standard Vocalizer event codes.

Applications can define and log additional events, and Nuance speech products can show them in the call log for an individual call. When generating an event entry:

• Each token in the log is a name/value pair separated by an equal sign character (=). For example:

  APPSERV=127.0.0.1

• Each log entry must have an EVNT token that identifies the event. The event name can be any alphanumeric string except one of the Reserved events.

  EVNT=SWIsvst

• Additional tokens separated by vertical bar characters (|), like this:

  EVNT=SWIsvst|SVNM=MyApplicationName|APPSERV=127.0.0.1

Reserved events

These event names and prefixes are reserved and cannot be used for application-defined events.

Required application events

To merge the log with recognizer logs, the application must:

• Log the OSCL event and OSLE token sometime between the call start (SWIclst) and call end (SWIclnd) events.
• Generate at least these events, in this hierarchy:

  SWIclst—call start                 (one required)

      [dialog module block]          (one or more)

  SWIclnd—call end

  Where a dialog module block consists of:

  SWIdmst—Dialog Module start        (one or more)

    …

    SWIstst—step start event         (one for each step)

      SWIprst—Prompt Start           (one required)

      [recognition]                  (one per step)

    …

    SWIstnd—step end

    …

  SWIdmnd—Dialog Module end

  Where a recognition is a collection or a confirmation attempt that passes the session and step IDs to the recognizer when loading a grammar.

Recommended events

To generate the richest possible reports, applications log the following events in this hierarchical order:

SWIclst—call start                  (one required)

      [dialog module block]         (one or more)

SWIclnd—call end

Where a dialog module block consists of:

SWIdmst—Dialog Module start         (one or more)

    SWIphst—Phase Start             (none, one, or more)

    [try block]                     (one or more)

    SWIphnd—Phase End

SWIdmnd—Dialog Module end

Where a try block (a collection attempt) consists of:

SWItyst—try start                   (one required)

    SWIprst—Prompt Start            (none, one, or more)

    [recognition block]             (one or more)

    SWIprst—Prompt Start            (none, one, or more)

SWItynd—try end

Where a recognition block (a collection or a confirmation) consists of

SWIstst—step start event            (one required)

    SWIprst—Prompt Start            (none, one, or more)

    SWIrcst—recognition start

    SWIepst—endpointer start

    SWIendp—end pointer             (none, one, or more)

    SWIrcnd—recognition end

    SWIrslt—recognizer result       (For Nuance Recognizer logs)

    SWIendp—end pointer             (none, one, or more)

    SWIstop—recognizer stop event   (none or one)

    SWIdtmf—DTMF result             (none or one)

SWIstnd—step end

Note: Many of the application logging concepts (such as phase and try) and events are based on the technology of Nuance Dialog Modules. See Dialog Module logging events for terminology definitions.

Commonly logged events

Here are some of the non-required events that an application typically logs. They often have application-specific values.

Note: The content in this topic is for Dragon Voice in on-premise deployments.

The following list describes the standard events codes for the Krypton recognition engine.

The Speech Server is responsible for logging events related to:

• Start of speech endpointing (for example, SWIendp event), including the waveform captured (NUANwvfm event).
• A stop event due to hang-up or DTMF detection, in which case the Speech Server will log why the stop event occurred (SWIstop).
• Events related to DTMF processing (such as SWIdtmf).

Note: The content in this topic is for Dragon Voice in on-premise deployments.

The following list describes the standard Natural Language Engine events (and Nuance Text Processing Engine events, where appropriate).

This diagram illustrates how results are logged as a recognition result moves from the Krypton to the NLE/NTpE pipeline for interpretation. The NLP service is the component responsible for sending the recognition/interpretation results to the Speech Server as well as the call log events.

Along with the event codes, the Speech Server call log will contain the recognition result, the audio captured, speech endpointing results, any stop events due to hang-up, and any DTMF processing results.