Events

An event occurs when the platform or voice browser service experiences some sort of problem or incident. Some examples of events are a platform error, or disconnection of the telephone.

  • A noinput event occurs if the user does not respond within a specified time.

  • A nomatch event occurs when the user does not respond intelligibly; that is, when the user’s utterance does not match any active grammar.

  • A help event occurs when the user requests help.

  • An error event occurs when there is any kind of error.

When the voice browser service detects such an occurrence, it is said to throw the event, meaning that it generates an internal notification. An application can then catch the thrown event and take the appropriate response. An element that catches an event and carries out an action is called an event handler.

Event handlers

VoiceXML offers several event handlers:

The <catch> element is a general-purpose event handler that can be used to catch a specified type of event. For example, <catch event=”nomatch”> will carry out specified actions when a nomatch event is thrown.

The <noinput>, <nomatch>, <help>, and <error> elements each catch one type of event indicated by the element name. They serve as shorthand for a <catch> element catching the specified type of event.

For example, a <nomatch> element catches no-match events, acting as the equivalent of a <catch event=”nomatch”> element.

Custom events

In addition to the standard types of events, an application can define its own kinds of events by using a <throw> element to throw an event. A <throw> can also throw one of the predefined events, but its principal use is to create customized events that are specific to an application.

When an event is thrown, the associated event handler, if it exists, is invoked. If the handler did not cause the application to terminate, execution resumes in the element that was being executed when the event was thrown.

For your own applications, Nuance recommends that you develop your own handlers for all event types, including those for which NVP provides a default.

For a full discussion of the events used in NVP, see Event types.

Event count

The voice browser service keeps a count of each type of event. This makes it possible to react differently to each occurrence of the event. For example, a first nomatch event can result in a reprompt saying only “Sorry, say that again”, while subsequent nomatch reprompts list the possible choices.

Example

The pizza.vxml document contains several universal event handlers that assign a different value to the entry variable:

<!-- global noinput, nomatch behavior -->
  <catch event="noinput">
    <assign name="entry" expr="'nst'"/>
    <reprompt/>
  </catch>
  <catch event="nomatch">
    <assign name="entry" expr="'rej'"/>
    <reprompt/>
  </catch>
  <!-- universals -->
  <catch event="help">
    <assign name="entry" expr="'help'"/>
    <reprompt/>
  </catch>

The value of the entry variable is then used in other documents. For example, it determines which prompt is to be played in the GetPizzaSize.vxml document (see Example of a form for the full code). Each prerecorded audio file says something appropriate to the context.

The prompt played the first time a caller enters the form (entry==’init’) simply asks “So, what size pizza would you like?” while the prompt played after a nomatch event (entry == ‘rej’) lists the sizes available. This means that if the caller’s first answer is rejected, the next prompt avoids a second rejection by explaining exactly what he or she can say.

Note that the same prompts could be invoked by an individual <nomatch> element within each form or field instead:

<nomatch>
  <audio expr="PromptPath + 'GetPizzaSize_rej.wav'"/>
</nomatch>

The approach used in pizza.vxml simply represents an alternative strategy for achieving the same result.