|
|
|
|
|
Existing IVR installations have significant investments in older proprietary solutions that use the TAS instruction set. The Avaya IR system provides an interface to allow VoiceXML scripts to transfer control to a TAS script and back. The TAS script segment can be used to access features of the Avaya IR platform that can not be reached using Web technology. It can also serve as a method of allowing the customers to migrate from TAS script to VoiceXML more slowly by allowing for hybrid VoiceXML/TAS applications.
This interface permits a developer to create a stub IVR Designer program that gets called from VoiceXML, and then immediately turns around and calls any one of the legacy DIPs or beyond-VoiceXML features of the Avaya IR system.
Some examples include:
The <object> element
The VoiceXML specification describes the <object> element as a method for exposing platform-specific functionality. In this case, it is used to transfer parameters and control to a TAS script via the IRAPI irSubProg() function. The TAS script can then perform actions on behalf of the VoiceXML script and return data to the VoiceXML script.
The following is an example <object> that is calling a TAS script called vxmlSubprog. It demonstrates passing parameters into the script and receiving information back from the script.
The custom Avaya <object> element uses a classid attribute of com.avaya.subprog to specify the subprog action. The name attribute will be the returned data variable. Additionally, the subprog action requires an application name for the script to transfer control to. The <object> element uses param elements to pass information into the object. To get the application name, there must be a param element with the name application_name and a value string that is the name of an existing script/service to transfer control to. An error will be thrown in VoiceXML if the application_name parameter is missing.
Optionally, additional arguments can be passed in using additional param elements. To ensure the correct order of evaluation, the additional parameters must use a name of argN, where N will be the argument number in the range of 2 to 10. Argument 1, containing the name of the Avaya VXI process, is sent by the VoiceXML Interpreter. The com.avaya.subprog object will automatically translate non-string arguments into strings for transmission to the script.
Ret2vxml external function
The child script must return to the parent at some point. If the script does not have any data other than a return value integer, then the script may call the quit instruction directly. If this is done, the objectname.retVal will contain the returned value. If the script needs to return data to the VoiceXML script, then it will need to call the external function Ret2vxml.t. The Ret2vxml accepts the following parameters:
Ret2vxml(VoiceXMLname, returnvalue, returnstring1, �, returnstring10)
Where:
Note that a return code of -1 will be sent to the VoiceXML application and the VoiceXML Interpreter will disconnect the call if the call is terminated (the caller hangs up) during the execution of the script.
Example VoiceXML script
Example ScriptBuilder script
CallScript node
The CallScript node can also be used in an IVR Designer VoiceXML application to call and transfer data to a TAS application, which uses the Ret2vxml external function to return values to the VoiceXML application.
Reset charset for TAS application that uses TTS
When a VoiceXML <object> tag calls a TAS application that uses TTS, the TAS application must reset the charset to either ISO-8859-1 or ASCII using the Proxylang external function. The TAS application must reset the charset because the VoiceXML application sets the charset to UTF-16 and does not reset the charset before it calls the TAS application.
