VoiceXML changes for the AVvoicxml2-0 package that may affect customer applications

The following list describes how new VoiceXML capabilities for the AVvoicxml2-0 package may affect existing customer VoiceXML applications. All references to the VoiceXML 2.0 specification in the following list are referring to the specification dated March 16, 2004.

1. The event error.unsupported.object is now error.unsupported.objectname. Customers using error.unsupported.object in their applications will need to change their code.
2. In previous releases, the session variables session.connection.local.uri and session.connection.remote.uri were not being defined if a value was not available. Now, these variables will be set to an empty string if no value is offered by IRAPI.
3. In previous releases, the session variables session.connection.redirect and session.connection.aai were not defined. For the AVvoicxml2-0 package, these variables are defined, but have no explicit initial value. Existing applications that are checking for <var> != undefined, will have to be rewritten.
4. The session variable session.connection.aai is not supported by IR R1.3. For the AVvoicxml2-0 package, session.connection.aai is defined, but has no explicit initial value.
5. The following variable names, which were valid in previous releases, cannot be used in a VoiceXML application with the AVvoicxml2-0 package: Array, Boolean, Call, Date, Function, Math, Number, Object, RegExp, Script, String, constructor, eval, __parent__, __proto__, toSource, toString, toLocaleString, valueOf.
6. If caller input matches more than one active grammar with the same precedence, the precedence is determined using document order. For the AVvoicxml2-0 package, the first grammar in document order has the highest priority. For the AVvoicxml package and previous releases of IR, the last grammar in document order has the highest priority.
7. The Avaya Voice Browser will throw a badfetch if the xmlns attribute is not supplied or if it is set to something other than http://www.w3.org/2001/vxml
8. Input items (field, record, object, etc.) must have unique names within their local scope. The Avaya Voice Browser throws a badfetch in the context of the document containing the conflicting input items.
9. During a bridged transfer, if the originating caller hangs up first, a connection.disconnect.hangup event will be thrown and the item variable will remain undefined. In previous releases, the Avaya Voice Browser would return with the item variable set to near_end_disconnect.
10. If the connecttime for a bridged transfer is too short to complete an outbound call, a noanswer will be returned.
11. Transfer elements with illegal or badly formed URI sequences will now have the following behavior:
    1. If the destination does not start with tel:, then an error.unsupported.uri event will be thrown and the _message variable will be set to the message "The URI x is not a supported URI format", where x is the non-legal URI specification. The implication is that all telephone URIs must start with tel:
    2. If the destination is empty, then error.connection.baddestination will be thrown. In previous releases, the Avaya Voice Browser would have thrown error.transfer.
    3. In all other cases, if the destination is not a legal phone number, then error.connection.baddestination will be thrown. In previous releases, the Avaya Voice Browser would have thrown error.transfer.
12. An application that attempts a blind transfer that fails will receive an error.unsupported.transfer.blind event. In previous releases, the Avaya Voice Browser would have thrown error.transfer.
13. Undefined variables can not be used in <script> blocks or expressions. In previous releases, the Avaya Voice Browser would not flag these, but now it will generate an error.semantic event.
14. Root application documents can not specify a root application.
15. Enumerate elements can only be used in the presence of <menu> or <option> elements.
16. Form level filled items with no namelist attribute will be treated as if all input items were listed in a namelist.
17. The following changes have been made to the <throw> element and the semantics of event catch handling:
    1. In previous releases, if a <throw> element did not specify a message attribute, the _message variable would be defined for use in the <catch> block, but was set to an empty string. For the AVvoicxml2-0 package, if the message attribute is not present on the <throw> element, then _message is an undefined variable. For application developers, code must be changed to check for _message != undefined prior to using the _message variable, or they will get an error.semantic thrown if they attempt to reference _message when it is undefined.
    2. The rules for matching events to catch functions have changed. In previous releases, the event/catch algorithm would give preference to the longest matching catch. So, if there were catches for error, error.foo and error.foo.bar in the same document scope, and error.foo.bar was thrown, then the algorithm would have selected the error.foo.bar catch, regardless of the order of the catch blocks within the scope. Now, the event/catch algorithm will pick the first matching substring. So, in the previous example, if the catch for error occurs before the catch for error.foo.bar, then it will select the error catch block to process the event. Application writers should order their catch blocks starting with the most specific going to the least specific within each document scope. So, in the above example, error.foo.bar should come before error.foo and error.foo should come before error. Please note that throwing error will not match the catch handler for error.foo.bar, but throwing error.foo.bar will match a catch for error.
    3. The final issue has to do with the counters associated with catch handlers. In previous releases, if an event error.foo.bar were thrown and there were catches for error.foo.bar, error.foo and error, only the error.foo.bar catch counter would be incremented. For the AVvoicxml2-0 package, all matching catch counters are incremented when they match an event, even if they were not chosen in the selection process. So, throwing error.foo.bar will result in incrementing the counters for all three events. Additionally, the counters for a field will only be cleared if the field is specifically cleared with a <clear>, if the document containing the field is left, then re-entered, or if the form containing the field is <clear>'d. In previous releases, the field level event counters were cleared whenever the field was exited and re-entered. The counters associated with form level catch blocks will be reset only when the document containing the form has been exited and re-entered, or when the form is cleared via the <clear> element.

       Important:
       The counters associated with the default catch functions defined in defaults.xml can not be reset during the course of a call (They start at zero for every new call.). Therefore, it is highly recommended that applications provide their own handlers for default errors in either form or document scope so that they can be reset when needed.

18. If no input item is matched, the input is ignored and the form interpretation algorithm will restart with field selection. In previous releases, a nomatch error was thrown when form level results could not be assigned to a field or slot.
19. Non-control items (<initial> and <block>) can not be used in the namelist attribute of a form level <filled>.
20. A NaN (Not a Number) is now correctly converted to Boolean. The ECMAscript special value NaN is supposed to be mapped to false when converted to Boolean. All other non-zero values are mapped to true. In previous releases, NaN was incorrectly mapped to true. All non-empty strings will be mapped to true and empty strings will be mapped to false. Previously, all strings were mapped to true.
21. Uri fragments (for example, #sub1) will be ignored on application root document URL's. Previously, if the application root URL contained a fragment (URL#frag), then the root document was not fetched and an error.badfetch was thrown.
22. In previous releases, the inet component automatically converted a POST with a null namelist into a GET. Now, a dummy argument "AvAyACoMpLiAnCeFiX=AsSeRtIoN539" is sent when there is no data for a POST. Applications that use this automatic conversion may need to be changed to ignore the dummy argument.
23. If the specified language for a prompt is unknown, an error.unsupported.language will be thrown. In previous releases, unknown languages would be silently re-mapped to U.S. English.
24. If a grammar has an unsupported type attribute, error.unsupported.format will be thrown. In previous releases, this would have been reported as error.grammar.inlined.
25. If the audio file specified in an <audio> element is not available, no error will be thrown. In previous releases, an error.badfetch would have been thrown.
26. For grammars in a application root document, if an xml:base is specified, the grammars with relative paths must be based on the specified xml:base. If a grammar is defined in the application root using an src attribute, and the specified URL is relative (does not start with a "/" or "http:"), and if the application root document defines an xml:base attribute, then the xml:base URL is pre-pended to the relative URL specified in the src attribute to construct the final URL for the grammar. Otherwise, if the xml:base is not specified, the URL base used to compute the complete URL will be the same as the one for the application root document. Previously, the xml:base attribute was ignored and the base URL was always the same as the application root document fetch. For example, if the application root document was fetched from http://anyserver.com/app/root.vxml, and the application root document contained an xml:base of http://anyserver.com/common, then any grammar defined in that document with a relative URL would be fetched from http://anyserver.com/common/<relative> path. Previously, it would have been fetched from http://anyserver.com/app/<relative> path.

    Note:
    If the URL from the src attribute is an absolute URL, then nothing changes.

27. In previous versions of the VoiceXML specification, an xmlns attribute on a <grammar> element would cause a parse error in the document. Now, the xmlns attribute is parsed and passed to the ASR engine.
28. Bargeable prompts can precede non-bargeable prompts. This is implemented by turning ASR/DTMF on/off depending on the prompt that is being played. In previous releases, if prompts for a field were queued as "bargeable->non-bargeable->bargeable", then all prompts queued before the last non-bargeable prompts were treated as non-bargeable. Now, the ASR and DTMF input will be turned on and off according to the barge-in status of the currently playing prompt.

    Note:
    Transitioning from bargeable prompts to non-bargeable prompts can confuse callers. There is a high likelihood that callers who begin speaking just prior to the transition from bargeable to non-bargeable will be mis-recognized or that their input will be ignored. Therefore, Avaya strongly recommends that application writers avoid using transitions from bargeable prompts to non-bargeable prompts in VoiceXML applications.

29. The platform handler for <record> has been rewritten to enable prompts to be bargeable, to allow for local grammars, and to allow for modal=false access to form and link grammars. According to the specification if the dtmfterm attribute is true, then it supersedes any local grammar. Also, local grammars have precedence over form, link or menu grammars. So, if dtmfterm is true, then it is equivalent to setting modal to true with a local grammar, which allows the entry of any single DTMF key to terminate the recording and the prompt if it is bargeable. If dtmfterm is not true, the recording will contain the DTMF keystrokes.
30. If <script> elements have both in-line context and the src attribute defined, an error.badfetch is thrown. In previous releases, the in-line content would be used if both the src attribute and in-line content were defined for a single <script> element.
31. If no grammars are specified for a <field> element, then error.semantic is thrown, In previous releases, the Avaya Voice Browser would throw error.recognition.nogrammars.
32. In previous release, prompts and grammars that did not have specific xml:lang attributes were not always getting the currently active language property setting. Now they do.
33. In previous releases, the Avaya Voice Browser required all audio files to be cacheable. This has been changed to read no cache audio files into in-memory audio objects. If fetchaudio prompts are no cache, they will be read and stored into a temporary file, one per channel. Customers should be aware that using memory to hold no-cache audio files may cause performance problems. This capability should be used sparingly and it should not be used for large files.
34. The Avaya Voice Browser has been updated to conform to the 18 December, 2003 candidate recommendation version of SSML. Specifically, <desc> was added and the <meta> and <metadata> elements can now be child elements of <prompt>. The missing attributes have been added (specifically, interpret-as). Also, interpret-as is a required attribute for the <say-as> element.
35. The DTMF attribute of the <choice> element can specify a sequence of DTMF digits with white spaces.
36. The Avaya Voice Browser will throw an error.unsupported.builtin when an application uses a built-in grammar that is not supported. Previously, the Avaya Voice Browser would quietly ignore such errors.
37. The Avaya Voice Browser will now throw an error.noresource.tts if the TTS resource is not available. The Avaya Voice Browser will not throw this event if the application has executed <exit> or if the dialog is exiting naturally with queued TTS prompts.
38. The Avaya Voice Browser now honors maxage and maxstale attributes for <script> elements that have an src attribute. Previously, these attributes were ignored and cache expiration was either what was sent by the web server, or the default of one day if the server did not provide any expiration.
39. If a <throw> statement does not have an event or eventexpr attribute specified, an error.badfetch is thrown. In previous releases, error.semantic.no_event_in_throw was thrown.

© 2006 Avaya Inc. All Rights Reserved.