The Anonymous "_message" Variable

When an event is thrown, the anonymous _message variable contains the message string from the corresponding <throw>, <choice>, <link>, or <return> element, or a platform defined value for events raised by the platform. If no message is specified, the value of this variable is ECMAScript undefined. The _message variable is available within the scope of the <catch> element and its shortforms (<error>, <help>, <noinput>, and <nomatch>). This document describes the format and/or values of the following:

ASR-related events "_message"

The following chart documents the _message strings that are possible for some ASR-related events.

Event	Possible `_message` Strings
`nomatch`	- REJECTED(ASR) - Invalid value for BuiltinDateSlot - ASR TIMEOUT - DTMF pressed when no grammar or VOICE only - nomatch for all dtmf grammar
`maxspeechtimeout`	- REJECTED(MAX SPEECH TIMED OUT)
`noinput`	- TIMEOUT
`error.asr`	(This will depend on the ASR engine being used.) With ASR engines that follow the MRCP Standard, the message string should be one of the following error codes: - 004_Grammar_Load_Failure - 005_Grammar_Compilation_Failure - 006_recognition_error_has_occured - 009_URI_Failure - 010_Language_Unsupported

Example

If the following page is executed and the caller says something that's not defined in "grammar.xml":

<?xml version="1.0"?>
<vxml version="2.0">
   <catch event="nomatch">
      <log> <value expr="_message"/> </log>
      <exit/>
   </catch>
   <form>
      <field name="field1">
         <grammar src="grammar.xml"/>
      </field>
   </form>
</vxml>

something like the following might be logged:

"log :REJECTED(ASR)"

Bad fetch "_message"

When either of the events error.badfetch or error.badfetch.<protocol>.<response code> are thrown, specific information is stored in the _message variable, to allow the developer to differentiate between the different types of bad fetch. This information has the following format:

<resource type> fetch failed; <fetch type> ###; <uri>[; info]

<resource type> = Audio | JavaScript | Grammar | VoiceXML
<fetch type> = http | https | file | builtin
### is HTTP status code; 0 if not applicable
<uri> is the full uri which caused the bad fetch event
[info] is optional, and could contain specific detail, for example "fetch timeout" or other specific error returned by IPROXY.

Example

If "no_audio.vox" does not exist, the following page is executed:

<?xml version="1.0"?>
<vxml version="2.0">
   <catch event="error.badfetch">
      <log> <value expr="_message"/> </log>
      <exit/>
   </catch>
   <form>
      <block>
         <audio src="no_audio.vox"/>
      </block>
   </form>
</vxml>

something like the following will be logged:

"log :Audio fetch failed; http 404; http://123.123.12.12/audio/no_audio.vox"

Disconnect-Hangup "_message"

Here is a list of possible messages for the event connection.disconnect.hangup (or telephone.disconnect.hangup). Some of these states can be mapped to an application tag(s). However, others refer to internal states (specific to the implementation).

Note: All of the following messages indicate what state the vxml interpreter is at when the caller hangs up, except for "<disconnect> tag executed".

`_message` Strings	Explanation
<disconnect> tag executed	The disconnect/hangup was caused by <disconnect> in the page, rather than the caller hanging up.
Call hang up during Disconnect
originating call hang up during aborting
Call hang up during FileWaiter	The vxml interpreter (vxmli) is in a "FileWaiter" state whenever it's fetching external dependencies for a scope. External dependencies are external scripts, external grammars (if the vxmli is configured to fetch them), XML data referenced by `<data>` (VG7.0+ only), audio files, and root documents. If the vxmli has just entered a page, a dialog, a form item, or executable content that reference external dependencies and the call is hung up while the fetches are pending, this message is logged.
quitting on hangup after followLink failed
Call dropped in followlink
Call disconnected during initial fetch process
Disconnect during root page fetch
formsubmit failure and call drop
Call dropped in formsubmit	The caller hung up while a new page was being fetched with a <submit>.
Call hang up during JoinResource
origniating call hang up during call
FAILURE(HANGUP)	The caller hung up while platform was collecting user input.
call dropped in promptonly	The caller hung up in a PromptOnly state (i.e. when queued prompts are played, without collecting input, before an <exit>/<transfer>/<record>, or before a <submit>/<goto>/<subdialog> using fetchaudio).
User hangup while recording
Recoding: FAILURE(HANGUP)
origniating call hang up during transfer
Received a hangup while loading the document

Unsupported URI "_message"

There is an event error.unsupported.uri, which will be thrown if either a blind or bridge transfer is attempted, but the platform does not support the URI format of the transfer's dest or destexpr attribute (ex. fax://...).

If this event is thrown, the _message variable will contain information with the following format:

The URI <uri> is not a supported URI format

<uri> = the value of the dest or destexpr attribute of the transfer