ivr service
      Database Systems Corp. BBB Business Review
   IVR AND VOICE BROADCASTING SERVICES AND SYSTEMS Home  |   Contact Us  |   About Us  |   Sign Up  |   FAQ

ivr software applications


IVR Solutions
IVR Service
IVR Systems
IVR Development Systems
IVR Programming
IVR Design
Interactive Voice Response Solution
IVR Customer Satisfaction Surveys
IVR Supplier
Toll Free Services
Telephone Answering Service
800 Number Services
Voice Messaging Systems

ivr software applications

Website Information

IVR Software
Telephone Surveys
Hosted IVR
IVR Hosting

IVR systems interactive voice response

IVR Development

This section of our technical library presents information and documentation relating to IVR Development and custom IVR software and products. Business phone systems and toll free answering systems (generally 800 numbers and their equivalent) are very popular for service and sales organizations, allowing customers and prospects to call your organization anywhere in the country. The PACER and WIZARD IVR System is just one of many DSC call center phone system features..

What Is IVR?. An Interactive Voice Response (IVR) processes inbound phone calls, plays recorded messages including information extracted from databases and the internet, and potentially routes calls to either inhouse service agents or transfers the caller to an outside extension.

Contact DSC today. to learn more about our IVR services and IVR application development software.

Defining Voice XML

Voice XML is a new buzzword throughout the telecommunications industry. But what is Voice XML?

In the article "A Closer Look At Voice XML" by Mark Levinson, from tmcnet.com, Mr. Levinson states:

"Anyone familiar with current products and technology for automated telephone customer service or messaging applications has surely heard that Voice XML (Voice Extended Markup Language) is The Next Big Thing. It's supposed to leverage Web technology and make these applications, well... better! But what is it, exactly? What are its advantages and drawbacks? When does it make sense? And what skills and tools are needed to develop Voice XML applications?

Mr. Levinson further states:

"VXML is promoted by a non-profit industry group, the Voice XML Forum. Most current VXML-based commercial products support Version 1.0 of the specification. Voice XML Version 2.0 was accepted in January, 2003 as a candidate specification by the World Wide Web Consortium (W3C), and is rapidly being adopted by VXML product vendors.


VXML consists of software elements that are used to construct automated telephone-based voice applications. (It may also be applied, in principle, to non-telephone voice applications, but SALT may be a better choice in those cases.) It conforms to Web programming paradigms and is designed to fit the typical three-tier Web system architecture: Web servers contain business logic and "pages" of content; they exchange data with back-end data stores; and they serve content pages to browsers, which present it to end users.

VXML pages are downloaded from Web servers to "voice browsers." They contain code, in the form of tags in XML syntax with their associated attributes and data, that's interpreted by the voice browser to orchestrate audio dialogs with end users. It's analogous to HTML, where tags specify text and graphics to be displayed in desktop Web browsers. For example, the HTML tag

instructs Web browsers to render the indicated text as a paragraph; the VXML tag instructs voice browsers to render the indicated data as audio output. VXML browsers are typically located in data centers and accessed through the public telephone network.

Borrowing from HTML, the basic building block of VXML is the "form," each of which governs a bit of dialog between the caller and application. VXML forms, like HTML forms, contain "fields," each to be filled in by the caller with a particular piece of data. The dialog proceeds by prompts ("Please say your account number") and responses, either as speech, which is processed with speech recognition software, or touch-tones. Each field must have an assigned grammar, specifying the verbal phrases the speech recognition engine will understand and/or allowed touch-tone sequences. The various VXML elements allow developers to create forms and fields, specify prompts and grammars, define variables for storing various pieces of data, and perform other chores like handling cases where no response is heard or the caller's speech isn't recognized. As with the Web, the HTTP protocol is used for communication with the server.


VXML also offers a set of program logic elements, like "GO TO" and "IF-THEN-ELSE" constructs to control portions of dialogs from within VXML pages. Since VXML coexists with the normal Web infrastructure, other browser-side programming resources, such as JavaScript and ECMA Script, can be used in similar ways. As explained in the previous article, the introduction of program logic in VXML pages makes a lot of sense from a system design perspective. But it creates much greater complexity in program design, development, and testing than conventional voice application approaches, since application logic is split among various VXML pages and the Web server.

The Web execution paradigm creates further intricacies. When, during a dialog, some data must be submitted to the server (say, a request for the caller's account balance), execution of the VXML page stops. The server processes the request and, keeping track of the current state of the dialog, sends a new VXML page back to the browser, which then executes it to continue the dialog. As with Web applications, technologies like Java Server Pages (JSP), Active Server Pages (ASP), and Java Servlets enable servers to generate VXML pages on the fly, customizing them based on business logic and data specific to the user session. But even so, VXML pages have their program logic and data fixed when they're created. Then they're on their own. Any further interactions with the server will require new pages to be generated.

For example, a voice mail application allows callers to browse through their voice mail messages. When a caller logs in, the server creates and downloads a VXML "message browsing dialog" page. It accepts commands for navigating among the messages, and has a variable array containing the locations of the audio files where each message is stored, so they can be retrieved and played. When the caller wants to delete a message, a request must be submitted back to the server. Execution of the "message browsing dialog" page stops, and the server deletes the indicated message file. To allow message browsing to continue, the server must then generate a new page with the same program logic, but where the variable array is now initialized with the remaining message files.

Organizing these various bits of logic and data on the server and different VXML pages presents new challenges for application design and testing. Clearly, care is needed so that the server, static VXML pages, and dynamic VXML pages work together in a clean and maintainable way.


What kinds of knowledge, tools, and equipment are needed for VXML application development? The convergence in VXML of formerly distinct Web and voice technologies means that VXML application development demands development teams with an uncommon set of disparate skills: Telephony hardware and software, voice user-interface design, speech recognition and text-to-speech technology (grammars, pronunciations), and audio editing, together with Web technologies like HTTP, scripting languages, Java, servlets, JSP, ASP, and Web server configuration. In the last couple of years, many companies have rushed to narrow this gap with VXML development tools and services.

As with most software development aids, VXML tools aspire to yield good results without requiring in-depth knowledge of the underlying technologies and programming languages. However, as with all such tools, there are trade-offs between power and ease-of-use. And successful voice application development demands some knowledge of telephony and speech technologies that development tools can't provide.

Most VXML development tools feature graphical interfaces for drag-and-drop editing. Some also allow direct editing of the VXML code, so those with sufficient knowledge can create functionality beyond those features supported by the graphical editor. To further simplify development, many tools come with libraries of canned dialogs that perform common tasks, like collecting spoken telephone numbers or times and dates. While these pre-form dialogs can be very useful, most are implemented in proprietary code, so they can't be easily modified or extended, and they aren't portable to other tools.

Testing and debugging voice and touch-tone-based telephone applications presents unique requirements. Testers must call, listen to, and speak to the application, and perhaps use touch-tone keys. Some development tools use the desktop computer's audio card as an interface to the voice browser and simulate a telephone environment, including a graphical telephone keypad. Others rely on actual telephone interfaces, requiring the installation of telephone line cards in the test machines. Line cards can be tricky to get working right, especially for the "barge-in" functionality, which is crucial to most voice applications.

A third approach is offered by hosting service providers. Customers develop their VXML applications remotely via the Web using the service provider's development tools. The applications then run in the service providers' data centers. Testing is done by simply calling the application using a designated telephone number. This approach is very simple, with virtually no up-front investment in equipment or software. But the application may be limited to features offered by the host, and is locked-in to the host's development and run-time environment.

The voice browser itself also has some influence on application development. At present, not all voice browsers support every VXML feature. And most offer proprietary extensions and other features to differentiate their products. The most important concern is that VXML doesn't address call control functions: Answer, transfer, conference, etc. The W3C is in the process of formulating a Call Control XML (CCXML) standard, but for the moment, voice browsers implement these functions in proprietary ways."

Mark Levinson is president of VoxMedia Consulting. He has over 15 years of telecom industry experience, including more than five years managing the design, development, and deployment of real-world speech applications. He can be reached at 781-259-0404 or mark@voxmediaconsulting.com.

Contact DSC today. to learn more about our IVR services and IVR application development software.