VoiceXML 2.1 Development Guide

| TOC

Debugger Features

You have the debugger open, but you can't decipher those funky messages that it is outputting? You can use the below guide as your Japanese interpreter, and help you figure out what the heck is going on with your application. First off, let's take a look at the debugger itself, shall we?

Send Results

At the top left of our window, you will notice that we have the option to send the logs to support for clinical analysis. Feeling wordy? Please give us some commentary about how your application is behaving, such as a simple walk-through describing how we can recreate your errors.

If you include all 30,000+ lines of your log results to us, or if you have a slow connection, chances are good that this feature will time out on you. Try to send in only log files for one call, not the previous 20 attempts at testing the app.

Filters

Through this tab in the logger, we have the option to filter out CallXML or VoiceXML logging that might be running in your account at the same time as your testing. To further simplify things, we can click on the sessionID value in the output itself so that only log results for that session are displayed. We also have the option to show the full-bore output of the logs, through the 'show verbose logging' checkbox.....we currently have logging levels turned way down so as to minimize the extraneous output, but in some cases you may wish to see the complete, unfiltered output.

Debugger Command Bar

When testing a VoiceXML, CallXML, or Call Control XML application and using the debugger, we have even more features that we can utilize to make our lives easier. Notice that when you place a call with the debugger window open, a value will appear in the upper left pane for each active call we have. We can then select these calls on a per-session basis by clicking on this section, and utilize the debugger command console to interact with your application and debug mid-call.

We can pause, start, and stop your application mid-call, or we can also use the controls to send a specific event to a CCXML application, or grab the current document that is being processed by using the specific buttons detailed below:

"Stop" Clicking this button while a call is active allows you to stop the session specified, (i.e. remotely hang up the call). This is useful if you code yourself into a looping application.

"Pause" Clicking this command button allows to you pause application execution on an active call. This is useful for hunting down a particular debugger message, and is even more handy for coffee/cigarette breaks. Just don't let the Boss catch you.

"Play" This button only comes into action when we have a call session that is paused. Clicking this button allows you to continue with a formerly paused call session, resuming from the point in which it was last interrupted.

"Step" After pausing an application, you may wish to allow it to run 'step-by-step' so that you can watch the application's behavior more closely. Using this debugger command button will allow you to 'un-pause' the application so you may give it a single input, or allow it to execute the very next prompt or recognition state before pausing again.

"Get Variables" Possibly the most useful of all the command buttons, clicking this button will bring up a new window which shows any and all session, application, and user-defined variables that are available in the current call session.

"Get Current Document" This command button allows you to view the current XML document as the interpreter sees it. This is especially useful when attempting to view the XML output by the target of a POST, for instance.

"Send Event" This somewhat specialized button is only applicable when running a CCXML or a CallXML application. Clicking on this button will open a pop-up that allows you to specify a particular event to send to the application. For instance, if a CCXML application is running, one could pause the call, and then specify that an 'error.dialog.notstarted' event be thrown to the application in order to check that the appropriate event handlers are working correctly.

Are You Authorized?

If you decide to take a coffee break, or you simply want to check out the season finale of 'Fresh Prince Of Bel Aire', be advised that your debugger session, as well as your Voxeo Account Manager session might well time out, and you will see the ominous message "you must be authorized to view logging". If this happens, you will have to re-enter your username and password to resume your application testing.

Not Getting Any?

You do have the ability to programmatically turn the debugger output on and off within your code. If you have sensitive information being passed within your app that you would just as soon keep secret, you can turn the output off to protect this data from prying eyes. Simply add the below snippet to your code to turn the logger off:



<voxeo:logcontrol mode="disable"/>

And to turn it back on again within your code, add this command:



<voxeo:logcontrol mode="enable"/>

Note:

The <voxeo:logcontrol> extension element requires that one specify the "xmlns:voxeo" attribute of the <vxml> element
The <voxeo:logcontrol> element can only be enabled/disabled within either a <block> or a <filled> element.

"Error 'xxx'" messages

When dialing into a failing application, you will undoubtedly get an error message in the real-Time Logger. In addition, you will hear a Voxeo specific error message stating the internal failure code. Do not be fooled, the truly helpful debugging messages are contained in the Logger output itself. However, for the curious, we list the auditory error messages and what they translate to here for your convenience.

Audible CCXML Error Messages:

Error 6 0 1. the application U R L could not be located.
Error 6 0 2. the primary and secondary application U R ells could not be located.
Error 6 0 3. the primary, secondary, and tertiary application U R ells could not be located.
Error 7 0 7. The application start-up could not be completed.
Error 3 0 4: the application you are trying to reach is not available at this time.

What they mean:

Errors 601 through 603 are self-explanatory. The initial URL of the application could not be fetched for some reason. The application thus fails.
Error 707 is the generic "catch-all" error for the CallXML Router. It can mean something is failing on the CallXML browser itself or the redirect number failed to transfer, etc. Often there will be no logging visible in the logging stream when this error is tossed.
The 304 error has traditionally been worded differently, but is essentially a message that crops up when someone has called a phone number that is mapped as "CCXML" in the database, but has no actual application attached to it. Again, no logging will be visible.

Audible VXML Error Messages:

Error 6 2 6: the application URL could not be located.
Error 6 2 7: the primary and secondary application URLs could not be located.
Error 6 2 8: the primary, secondary, and tertiary application URLs could not be located.
Error 6 3 0: Application URL could not be reached and Redirection failed.
Error 3 0 6: the application you are trying to reach is not available at this time.

What they mean:

Errors 626 through 628 are self-explanatory. The initial URL of the application could not be fetched for some reason. The application thus fails.
The 306 error has traditionally been worded differently, but is essentially a message that crops up when someone has called a phone number that is mapped as "VoiceXML" in the database, but has no actual application attached to it.

Stay tuned, and we will dissect even more logger messages in the very near future!

ANNOTATIONS: EXISTING POSTS

mheadd

12/23/2008 12:00 PM (EST)

Regarding the <voxeo:logcontrol/> element, is this the equivalent of using:

<log expr="'VOXEO:Logging.disable'" label="trace:?level=ERROR"/>

What is the difference between the two?

Does this prevent log statements from appearing in the log files, or just from appearing in the log viewer?

VoxeoDante

12/23/2008 1:00 PM (EST)

Hello,

Using the;

<log expr="'VOXEO:Logging.disable'" label="trace:?level=ERROR"/>

method is the old way of turning off logging at the CCXML level and should no longer work on our platform. We are working to get the documentation updated to reflect these changes.

The newer method, <voxeo:logcontrol/>, should still work and will turn off logging at a very high level. This means that there will be no logs available to the log viewer or to be written to disk.

Additionally in the newest builds of the platform, those after 8.0.250.0 contain the workings for a new property to control logging.

This new property will be aptly named com.voxeo.logcontrol.mode. It shall have three settings.

- disable -- all logging will be turned off.
- enable -- this is the default and is the same as not setting the property.
- sensitive -- sensitive material should be suppressed from the logs. And will not limit logging in the MRCP server.

I hope this helps.

Regards,
Dante Vitulano

mheadd

3/3/2009 11:39 AM (EST)

Dante:

What is the status of the new "com.voxeo.logcontrol.mode" property?

Is it active? Can we use it in our applications? Is there any information aavailalbe in the documentation on its use?

Thanks!

Mark

jdyer

3/3/2009 1:50 PM (EST)

Hi Mark,

The Voxeo logger's feature of really simple and certainly still active, to use them you simply include the Voxeo namespace at the [url=http://docs.voxeo.com/voicexml/2.0/vxml.htm]<vxml>[/url] scope of your application, then simply add the below snippet to your code to turn the logger off:

[code]<voxeo:logcontrol mode="disable"/>[/code]

And to turn it back on again within your code, add this command:

[code]<voxeo:logcontrol mode="enable"/>[/code]

I do hope that's helps, and please let us know if there are any additional questions as we are most certainly here to help!

Regards,

John Dyer
Customer Engineer
Voxeo Support

SSA_NCH

3/9/2009 1:35 PM (EDT)

It's probably worth noting that this tool/technique is NOT available in a Production environment. Apparently Voxeo prefers any problems/issues to be reproduced in the staging area (where this tool/technique is applicable and available).

FWIW, I wish that I could use this to monitor/troubleshoot a Production issue (instead of having to reproduce it elsewhere to get this debugger working).

voxeoblehn

3/9/2009 2:46 PM (EDT)

Hello Mark,

We certainly understand that having to move your applications to our development platform does in fact limit the option of "real time scenario" troubleshooting. However, we limit the ability to debug in production as a best practice rule in order to reduce the possibility of any issue which may impact the flow of production traffic. Wit this in place we significantly reduce the instances of run away sessions, looping, and code issues which may have the potential to disrupt resources.

Having said that, persistent logging is available to all customers as well as Support assistance for troubleshooting and detailed log analysis if required. Please let us know if you have any additional questions or concerns with regards to logging.

Best Regards,

Brian Lehnen
Voxeo Support

The Motorola Meta Element

| TOC

| Prophecy Debugger Key