TeleFlow VXML
From TeleFlow
TeleFlow, an application development and service creation environment for telecommunication, was created in 1993 to help developers efficiently create and deploy voice applications for a range of hardware environments (including Dialogic, NMS Communications, Ai-Logix) by utilizing a flowchart approach to voice application development.
At the time, there was no obvious standard file structure for expressing voice applications in a non-compiled environment. Accordingly, the TeleFlow project developed its own proprietary Tap/Tam linked-list file structure to encapsulate and express all aspects of a voice system. In the following years, the VoiceXML (or VXML) file structure system became a strong standard employed in telecommunications, and has been widely adopted as an open standard.
Contents |
TeleFlow-VXML
This application has been created in order to harmonize the Tap/Tam file structure with VXML, and ensure that developers are creating code that will not become a dead-end. TeleFlow-VXML is a standalone, open source application which enables a developer to convert TeleFlow's flowchart files (Tap/Tam) to VXML. The project will realize the following benefits:
- Past TeleFlow developers will be able to ensure their source code is transportable to other VXML deployment environments.
- Current TeleFlow developers will be able to use the TeleFlow products and have some assurance that the applications they create will run on other VXML deployment environments.
- New TeleFlow developers will be able to use the TeleFlow Designer to create VXML applications
- TeleFlow-VXML becomes a training tool to show new VXML developers how to express application flow in VXML.
- Greater adoption of VXML, the prevalent standard.
- Developers may be able to adapt TeleFlow-VXML to convert other linked-list file structures to save projects developed in TeleFlow like environments to VXML.
Development Plan
PHASE 1: VXML OUTPUT COMPLETED TO BETA
TeleFlow-VXML has been created in order to harmonize the Tap/Tam file structure with VXML, and ensure that developers are creating code that will always be operable in any circumstance. TeleFlow-VXML is a standalone, open source application which enables a developer to convert TeleFlow's flowchart files (Tap/Tam) to VXML. This application realizes the following benefits:
- TeleFlow developers are ensured their source code is always transportable (note: VXML does not cover all features TeleFlow offers)
- Current TeleFlow developers will be able to use the TeleFlow products and have some assurance that the applications they create will run on other VXML deployment environments.
- New TeleFlow developers will be able to use the TeleFlow Designer to create VXML applications
- TeleFlow-VXML becomes a training tool to show new VXML developers how to express application flow in VXML.
- Developers may be able to adapt TeleFlow-VXML to convert other linked-list file structures to save projects developed in TeleFlow like environments to VXML.
We are pleased with the results that TeleFlow Designer creates. TeleFlow was developed entirely independently of the VXML standard, and yet the output TeleFlow Designer (via TeleFlow-VXML) creates proper VXML.
PHASE 2: Q1 2008 - PHP/VXML
TeleFlow is a fully multithreaded media service environment, is stable, and includes support for TCPIP protocols including HTTP. The environment was intended to make the task of prototyping voice applications easy, and then enable a developer to rapidly develop and deploy the service. In this regard, TeleFlow has been successful, and for prototyping nothing beats the development environment. However, at the development and integration stages, developers are generally more comfortable with script environments.
PHP is possibly the Internet's most used programming versatile programming and scripting environment. TeleFlow Server is now generally deployed along either an Apache or IIS web server with PHP installed. This is done as request/responses are generally encapsulated in XML, which is easily parsed in PHP.
An example of this is where reminder call is requested by a remote application. That remote application might be a scheduling application that has determined a patient scheduled for an appointment in the near future needs a reminder to make sure they are still intending to show. The request would be an HTTP post with XML tagged information about the telephone number, date and time etc. That XML request would be sent to the PHP service near the TeleFlow service. The PHP would break up the XML and then post an HTTP request to TeleFlow, and an application running on TeleFlow would process the request, and respond accordingly. This is currently how many TeleFlow applications are developed, and is an effective way to off load much of the XML processing to PHP, which is ideal because of rich classed programming environment.
As VXML is fully structured XML, PHP is an ideal parser to destruct the language into discrete elements. The elements can then be identified for processing in either the same PHP application or in TeleFlow. Most of the logical processing and variable handling can be managed within PHP, whereas the all voice and telephone related functionality will be managed by TeleFlow. HTTP Posts and Gets will manage the passing of process requests between the two servers.
Aside from providing support for VXML, having a PHP server resident with TeleFlow provides a means to distribute applications widely, and provide a means to automatically update them en-mass to various hosts. The means of publishing will enable developers who created applications that mean TeleFlow Marketplace standards, will be able to deploy them widely, and possibly realize advertising based revenues.
This approach of adding VXML via PHP processing will not break the current functionality of TeleFlow in anyway. The environment will only benefit from having a second means to define applications by. Because TeleFlow Designer would be the primary means to develop the VXML, engenic and its community will align TeleFlow-VXML (Designer) and TeleFlow-PHP/VXML (Server) in subsequent releases. In addition, the PHP language itself, running beside TeleFlow, will open the TeleFlow environment to a much wider audience.
Software Conponents
TeleFlow VXML uses the following components:
- Stefan Heymann's great XML parser system
- DeMime - excellent for Mime
Revision History
- 0.01 - 2007/07/20 Basic output of VXML good for a starting point for VXML developers
- most functionally guessed at just to get output looking real
- 0.02 - 2007/08/20 Clean up, and first release to SourceForge
Requested Improvements
- Convert Standard 16b 8Khz Wav (and Mp3) voice files to XML/VXML format
- Continue development of VXML output
- Proper variable definitions (Session / Application etc)
- Menu structures linked to voice files (requires minor
Release Document
Program: TFVXMLConverter
Version: 0.02 (alpha)
Authors: various (engenic)
Date: 2007
License: GPL
PURPOSE
As of 0.01 this program is intended for VXML developers who want to jump start
creating a VXML application by using TeleFlow Designer. TeleFlow Designer has
all the requirements programmed within it to be able to create full VXML
code from its flowchart development environment. This was a bit of a surprise
as TeleFlow was initially created in 1993... well before XML and VXML.
This program does the following:
1) Load TeleFlow application XML (Tap, Tam, dbf) files
2) Write its all out to VXML
FILES
Uses the following components:
- Stefan Heymann's great XML parser system
http://www.destructor.de/xmlparser/index.htm
- DeMime - excellent for Mime
Revision History
0.01 - 2007/07/20 Basic output of VXML good for a starting point for VXML developers
- most functionally guessed at just to get output looking real
0.02 - 2007/08/20 Clean up, and first release to SourceForge
Next
- Convert Standard 16b 8Khz Wav (and Mp3) voice files to XML/VXML format
- Continue development of VXML output
- Proper variable definitions (Session / Application etc)
- Menu structures linked to voice files (requires minor changes in TF Designer)
- Couple with HTTP for real time requests
CONTRIBUTORS
The intention is to start with Delphi to build out the converter. It might
just stay in Delphi as it is a fabulous language for this kind of thing.
Eventually, I could see a PHP engine converting and sending back out VXML.
Note: The files that comprise this environment will ALWAYS be "Open Source"
If you do wish to add code to this environment we will happily add it to the
code set, and provide it for others to build with. If you do decide to
contribute code, it will also be included in the source.
Contributed code must be assigned to engenic in order to ensure viability of
the project. Should a new open source license be selected, all assigned code
will also remain open source.
VXMLConvertStep is the function you will want to work with for the most part
EXPECTATIONS
The TF Designer will need adds and improvements in order to accommodate aspects
of VXML. We are willing to do this. Currently TF Designer is closed source.
There are several reasons for this, but mostly due to the complexity of the
application. We are externalizing aspects of its functions, but if you need
something to move ahead with a related project, we have always been
accommodating to our users.
CONVENTIONS
"@@@" (spoken "atatat" by the developers) is engenic's way of saying
"this is incomplete, broken, incorrect, needs improvement or just plain sucks."
History
VXML --- TAP / TAM - TeleFlow
Phillipe Roy had attempted to support VXML in TeleFlow by creating a Tam to VXML converter. This effort was ultimately a failure, however, some useful information may have been compiled below.
After reading on VoiceXML and acknowleding TeleFlow and VoiceXML's strengths, here are some final recommendations on implementation steps to seriously consider.
1) VoiceXML can't be ignored. This is a strong standard that will not go away, nor be replaced by another standard, and people evolving in the IVR market (clients as well as developers) will expect some VoiceXML related features to be implemented in modern products.
2) TeleFlow's implementation of VoiceXML feature must respect VoiceXML's goals, which are documented to be:
"VoiceXML's main goal is to bring the full power of Web development and content delivery to voice response applications, and to free the authors of such applications from low-level programming and resource management. It enables integration of voice services with data services using the familiar client-server paradigm."
Portability and standardization of coding practices is central to the venue of VoiceXML. Portability can be divided in two. Incoming portability (TeleFlow's good reaction to provided VoiceXML created outside of TeleFlow), and outgoing portability (Third-party's good reaction to VoiceXML created by TeleFlow).
a) Incoming VoiceXML protability. TeleFlow should include a VoiceXML script step. TeleFlow should be 100% compatible with VoiceXML 2.1 and stay up-to-date while the VoiceXML specifications evolve to later versions of the standard. TeleFlow should use a third party VoiceXML parser in its implementation. While looking for freely available VoiceXML parser, two of them seems to be worth serious considerations. (1) OpenVXI and (2) JVoiceXML. My recommendation would be to go with JVoiceXML for the following reasons:
a. JVoiceXML is java based, making our code base more portable to Linux when we will want TeleFlow server to become available on Linux. Since there is no GUI on TeleFlow server, porting it to Linux is, to this day, an effort that is limited. But, as we add third-party components that are platform specific, we increase the effort of the port. JNI could easily be used in order to bridge from C++ to java.
b. OpenVXI, although respected in the community, has a lot of dependencies for its install. The list of dependencies for the Windows version include Xerces Version 2.3.0, SpiderMonkey 1.5rc5, OpenSSL 0.9.7b, Perl 5.6 or later and a third party STL library (MSVC's STL has known robustness and threading problems, we do not recommend using that STL library). OpenVXI also has a Linux version available with the following dependencies: gcc version 3.2.2 or later, Xerces Version 2.3.0, SpiderMonkey 1.5rc5, Perl 5.6 or later.
Adapting to an XML parser is documented to be of four steps:
1. Document acquisition (Internet + File I/O)
2. Audio output
3. Audio input
4. Transfer
At a first glance, it appears that adapting to an XML parser is a limited effort. Given that TeleFlow already implements the required functionalities, it becomes only a matter of hooking it to the XML Parser of our choice.
It is then recommended to add the option of reading .xml files from TFDesigner from the "Open application" menu option in the File menu. If a .xml file would be opened from there, a single step application would be created with the VoiceXML content in the unique step (linked from the "Start" and to "Finish"). Users could then optionally add other steps to the VoiceXML and save the resulting TAP, or leave the VoiceXML untouched. Consequently, TFServer would also need to become able to open .xml extensions by default and create a single step TAP.
b) Outgoing portability is more complex. TeleFlow does more and performs things differently than VoiceXML. For TeleFlow to export VoiceXML while including every subtlety of its decision-making is a challenge. Nevertheless, a subset of this is accessible. TeleFlow could easily generate VoiceXML as a journal of events that have occurred during a session. For example, TeleFlow will continue to use its current implementation in the same manner, but, as VoiceXML compatible events occur, it would log them into an xml file accordingly. Speaking is a VoiceXML compatible event. Even though the decision-making to get to a "speak" event is complex to export into VoiceXML, we can easily log the "speak" event into the VoiceXML file. Recognizing is also a VoiceXML event that can be exported to a VoiceXML file. It is important to note that the xml file generated would be more of a log than a complete xml file that would encapsulate all the subtleties TeleFlow's internal decision-making. Creating such xml content would be relatively easy, but that doesn't mean that it would be perceived as a useful feature from our clients. The limited use from our generated xml would be to playback a single session from another vendor's VoiceXML compatible application.
I must admit that to correctly evaluate the consideration for a more complete export of VoiceXML from TeleFlow that would encapsulate all, or most, of TeleFlow's process, I do not have the right knowledge on the nature of each potential step. One thing is a certainty, if it would be possible for us to do that, it would not be possible for us to cover all possible steps. For example, the "Run QuickBasic step" could not be expressed as VoiceXML.
It is also recommended to consider adding some step-triggering mechanism into TeleFlow. For example, an early step into TeleFlow could register itself as a "transfer step". TeleFlow would then continue with its normal behavior and, when a transfer is required, the registered "transfer" step would be called instead of the default TeleFlow transfer behavior. That would allow us to add transfer behavior through VoiceXML content, leaving more control to the user. Now, only the "transfer" appears to be relevant, but while getting deeper into VoiceXML and TeleFlow, it may become obvious that other steps are also to be considered.
For VoiceXML steps to be well integrated within VoiceXML, it is also recommended to add a VoiceXML interface for TeleFlow variables. VoiceXML steps would be able to read and write TeleFlow variables. That would ensure that users choosing to use a VoiceXML step would not lose anything from the ones that stayed limited to TeleFlow steps. Although the VoiceXML produced that refers to TeleFlow variables would not be as pure as straight VoiceXML, it would still be VoiceXML content.
