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"
- Bad fetch "_message"
- Disconnect-Hangup "_message"
- Unsupported URI "_message"

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