An overview of interactive voice response applications

Transcription

1 An overview of interactive voice response applications Suneetha Chittamuri Senior Software Engineer IBM India April, 2004 Copyright International Business Machines Corporation All rights reserved. This article is for developers who want an introduction to interactive voice response (IVR) application development. It describes a typical IVR application and introduces the environmental requirements required to build an IVR application. It explains the hardware and software prerequisites, such IBM WebSphere Voice products. You see how the telephone can be a thin client to applications traditionally available only from the desk top. Page 1 of 24

2 Table of contents Introduction...3 What are voice applications?...3 A typical voice application flow... 3 Speech recognition... 4 How does it work?... 4 Dialog types...5 Text-to-speech... 6 How does it work?... 6 Integrating speech recognition and TTS into voice applications... 7 Using JavaBeans...7 Using WebSphere Voice Response state tables... 7 Using VoiceXML... 7 What you need to build an IVR Application...9 Telephony hardware Switch options Public Switch Telephone Network...10 Private Branch Exchange...10 Telephone lines Analog lines Digital lines Determining the number of telephone lines Telephony interface cards Telephony software platforms IBM s support for voice applications IBM Websphere Voice Server Voice Toolkit for WebSphere Studio IBM WebSphere Voice Response What WebSphere Voice Response applications do...20 Adding voice interaction to existing Web applications Conclusion...22 Resources...22 About the author Appendix. Voice terminology Acronyms...24 Page 2 of 24

3 Introduction Thanks to voice-enabled technology, the telephone has become the ultimate thin client, providing many of the features and functions once found only on the desktop. An interactive voice response (IVR) application is one which accepts a combination of voice telephone input and touch-tone keypad selection and can provide appropriate responses in a variety of media, including voice, fax, callback, , and others. IVR is usually part of a larger application that includes database access. Common IVR applications include: Bank and stock account balances and transfers Surveys and polls Call center forwarding Simple order entry transactions What are voice applications? Voice applications are those in which input and output interactions come through a spoken user interface, instead of a graphical one. Business applications enabled for voice can be a powerful tool for users to browse-byvoice and to interact with Web based data, using speech instead of keyboard and mouse. Such applications are capable of exploiting an enterprise architecture comprising servlets, ASPs, JSPs, and JavaBeans. You can integrate a Web application with voice using VoiceXML, Java beans, or Websphere Voice Response state tables. Voice applications can reside on local or remote systems, and customers can access them from a telephony-capable device such as traditional wired phones, cordless phones, and mobile phones. A typical voice application flow A typical voice application call flow consists of the following steps: 1. The customer calls the contact center and the system answers the call and invokes the appropriate application, such as the one referenced by Dialed Number Identification Service (DNIS) often referred to as the called number or Automatic Number Identification (ANI) often called as calling number. 2. The application plays a greeting and prompts the customer for the necessary information. Page 3 of 24

4 3. The application waits for a response for a set period of time. The caller can respond by speaking or by pressing keys on a telephone keypad. 4. The application takes the appropriate action based on the customer s response. For example, it might update information in a database, retrieve information and play it back as audio, or play a help message. 5. The customer can terminate the call at any time, simply by hanging up the telephone or by speaking to indicate the interaction is complete (for example, by saying Stop or Exit ). The runtime components of the voice servers, such as Speech Works from Intel or WebSphere Voice Server from IBM, process the input using their speech recognition engines, and synthesize responses using their text-to-speech engines to perform the text synthesis. Recognition and synthesis engines can be distributed across multiple systems so that resources can be shared, and to provide redundancy. Speech recognition Speech recognition, the recognition of human speech by a computer, is a voice technology that translates spoken input into text. Just like using the keyboard or mouse or pressing a key on the telephone keypad to provide input, the user can simply talk to provide input. The speech recognition process is performed by a software component known as the speech recognition engine, whose primary function is to process speech input and translate it into text. The engine relies on statistics and software algorithms to analyze the incoming audio signal and to search for the best match, taking into consideration known words and phrases (the active grammars) and the environment (the acoustic model). When the most likely match is identified, the engine returns it as a text string. How does it work? Speech recognition translates speech data into a format that voice applications can understand and process. Figure 1. Converting speech into an application data format Page 4 of 24

5 The voice model is responsible for keeping a set of parameters for the language to be recognized. The base forms maintain a description of what the words should sound like. Finally, the grammar contains a description of the words and multiple sequences of words (phrases) which are acceptable for the current recognition task. These features are all included when you install WebSphere Voice Server. An utterance of any length can be presented to the system, which then searches the currently loaded grammar for possible word matches. A voice application can contain up to 65,536 words and use more than one grammar. The overall response time can be affected by the length of the utterance and the size of the grammar. A grammar in a voice application uses a particular syntax, or set of rules, to define the words and phrases that can be recognized by the engine. A grammar can be as simple as a list of words, or it can be designed with more flexibility and variability so that a more natural language capability is achieved. Each new phrase, or utterance, is compared with the words and phrases in the active grammars, which can define several ways to say the same thing. The design of grammars is important to achieving accuracy. One big tradeoff is whether the grammar is designed for a few speakers using a large vocabulary or many speakers using a limited vocabulary, or some combination of the two. Speaker dependence describes the degree to which a voice recognition system depends on a speaker s individual voice characteristics. The recognition engine can be trained to an individual's voice in a speaker-dependent system, as in most desktop dictation applications. Server-based middleware applications are designed to service a wide variety of random callers, so they cannot be trained to each individual. It would not be practical to employ speaker-dependent models in the voice middleware environment. These are therefore known as speaker-independent systems. Dialog types Three types of dialogs are used in voice recognition applications: In directed dialogs, the application prompts the customer to perform a specific task while controlling the interaction. This menu-driven approach leads the user to complete a function by asking for information at each turn of the dialog, and expecting a specific reply each time. In mixed initiative dialogs, the user has more control. He or she can provide more input than what is requested and in a different order than expected. So the caller can anticipate the next prompt and act accordingly. Page 5 of 24

6 Natural Language Understanding grammars are designed to allow a more conversational interaction with an application, and to mirror the way people talk to each other. These grammars are more complex, and required significantly more application logic because the application needs to extract meaning and context from each spoken utterance. Text-to-speech Text-to-speech (TTS) is a voice technology that converts text into spoken output. It is performed by a specialized software component known as the TTS engine, whose primary function is to process text input and translate it into spoken output. Input can consist of text and, optionally, special tags (annotations) that can change the sound of the voice that is ultimately produced. The major types of TTS currently available in the marketplace include: Formant, which uses standard computer-generated, synthesized voice sounds Concatenative, which is based on joining small samples of actual voice recordings, resulting in a more natural voice sound. How does it work? The TTS engine analyzes the word, phrase, or sentence to vocalize. It expands abbreviations, handles contractions and numbers, and then it disambiguates the semantics of the sentence in order to know what words are really intended. Figure 2. Converting text to speech After the words have been analyzed, the system determines how to synthesize them into speech. Appropriate audio characteristics are applied (such as volume, pitch, and speed), and the speech output is produced. Both formant and concatenative TTS technologies use the same front-end system to analyze and process the input; the differences lie in how the output is synthesized. In a formant system, speech output is generated completely algorithmically using knowledge Page 6 of 24

7 of how the human vocal tract works (it has certain major resonant frequencies). The output produced is highly intelligible, although it may sound robotic or mechanical to some listeners. On the other hand, in a concatenative system, speech output is produced from recordings of units of actual human speech. These units (sounds, syllables, words, or phrases) are then combined, or concatenated, according to linguistic rules to produce the speech output, resulting in a natural, human-sounding speech. Integrating speech recognition and TTS into voice applications You can integrate speech recognition and TTS technologies into voice applications using three different methodologies: VoiceXML, Java Beans, and WebSphere voice response state tables. Using JavaBeans JavaBeans are an object-oriented presentation logic environment that uses common industry tools for Java development. JavaBeans can be integrated with business logic applications on an application server, and also with other JavaBeans-enabled products for database access and transaction processing. Using WebSphere Voice Response state tables A state table is a sequence of states, each of which performs a specific action, which can have one or more possible results. During a telephone call, the voice application progresses through the states, performing the actions in turn. The result of each action determines the next state to go to. State tables are defined for Websphere Voice Response for AIX. State tables offer low-level access to DTMF, prerecorded speech, speech recognition, fax, and Computer-Telephony Integration (CTI) products such as Genesys T-Server or CallPath. State table actions pass commands to a supplied custom server that manages all interactions. No understanding of speech recognition technology is required, because it is all handled by the software components supplied. Some specialized knowledge is required to develop new grammars. Using VoiceXML Using VoiceXML, the Voice Extensible Markup Language, you can create audio dialogs that feature synthesized speech, digitized audio, recognition of spoken, DTMF key input, recording of spoken input, telephony, and mixed initiative conversations. Page 7 of 24

8 VoiceXML is an XML-based, industry-standard language for creating voice applications, much as HTML is a language for developing visual applications. VoiceXML was designed to create audio dialogs that feature text-to-speech, digitized as well as prerecorded audio, recognition of both spoken and dual-tone multi-frequency (DTMF) key input, recording of spoken input, telephony, and mixed-initiative conversations. Its goal is to provide voice access to Web-based content and applications. It enables the development of voice applications through the use of a familiar markup style and Web server-side logic to deliver applications over telephone lines. The resulting applications allow conversational access to Web-based data, and can also interact with existing back-end business data and logic. VoiceXML supports dialogs that feature: Recognition and scoping of spoken input Dual-tone multi-frequency (DTMF) input Recording of spoken input Synthesized speech output Prerecorded digitized audio output Dialog flow control ANI and DNIS A VoiceXML application is capable of retrieving information from a Web server and, by making use of scripts and appropriate grammars; the application can interact with the customer through spoken words. The role VoiceXML plays in accessing and presenting customer information and a parallel with HTML are illustrated in the figure below Figure 3. VoiceXML in an application Page 8 of 24

9 Using VoiceXML you can: Develop voice applications in a manner similar to using HTML to build visual applications. VoiceXML requires less speech expertise that developers than some of the other integration methods. Use the same existing back-end business logic as you use for visual applications. Minimize development and maintenance costs by leveraging existing Web design skills and infrastructure. What you need to build an IVR Application In order to build an IVR application, you need hardware which connects your telephone and to a computer, and you need software which connects the telephony platform to the application. Page 9 of 24

10 Telephony hardware Figure 1 shows the hardware connectivity to your software system, in this case, the IBM WebSphere Voice Response product. The following sections describe the various components in this diagram. Fig 4: Hardware connectivity to the software system Switch options Voice applications can flow over public network switch and through private telephone systems. If your business case does not justify the requirement of a PBX you may connect straight to the public network switch. If you already have an in-house PBX that can provide you with the telephone lines, use it. Public Switch Telephone Network The Public Switch Telephone Network (PSTN) is the world s collection of interconnected voice-oriented public telephone networks, both commercial and government owned. Private Branch Exchange A Private Branch Exchange (PBX) is a telephone system within an enterprise which switches calls among enterprise users on local lines, while allowing all users to share a fixed number of external phone lines. The main purpose of PBX is to save cost of requiring a line for each user to the telephone company s central office. PBX is owned and operated by the enterprise rather than the telephone company (which may be a supplier or service provider). A PBX includes: Telephone trunk lines that terminate at the PBX Page 10 of 24

11 A computer with memory that manages the switching of the calls with in the PBX Network of lines within PBX Usually a console or switch board for a human operator Telephone lines IVR applications can flow over various line types. Analog lines Analog technology refers to electronic transmission accompanied by adding signals of varying frequency or amplitude to carrier waves of a given frequency of alternating electromagnetic current. An analog line is designed to connect to a standard domestic telephone, sometimes referred to as Plain Old Telephone Service (POTS). An analog card is available to support 4 or 16 lines. Various types of analog cards are available, such as D/21H, D/41H, D/41 JCT, and VFX/41JCT-LS, to name a few. They are manufactured by IBM, Intel Dialogic, Aculab, and others. D/41 H and D/21H cards are 4-port and 2-port voice processing boards, respectively. D/21H, D/41H cards support the following types of voice applications: Voice messaging Automated attendant Interactive voice response Inbound and outbound telemarketing Small call centers VFX/40ESC is an international 4-PORT voice/ FAX BOARD with caller ID, which supports these types of applications: Unified messaging Fax mail Integrated voice mail and fax mail Integrated voice/fax response Single call fax-on-demand Remote database transactions Fax confirmation Fax store-and-forward Fax broadcast Fax notification Page 11 of 24

12 There are many other cards available. In summary, analog lines support: Call transfer, but not Automatic Number Identification/Calling Line Identification (ANI/CLID), often referred to as the calling number Analog Display Services Interface (ADSI) telephones, which have an area of read/write memory, a screen, navigation keys, and soft keys. The soft keys can be programmed to perform specific functions, such as a number sequence. Fax Dual Tone Multiple Frequency (DTMF), a signaling device that generates the pulses or tone required to identify the called number and billing information Digital lines Digital describes electronic technology that generates, stores, and processes data in terms of 2 states: positive and negative. Positive is expressed as 1 and negatives are expressed as 0. T1 T1 services use Digital signals to allow two pairs of wires to carry 24 voice or data transmission. This is primarily used in North America and some Asian countries. It provides 24 lines/channels on a single four-wire circuit at a transmission rate of megabits per second (Mbps). Signaling is imbedded in the voice channel transmission. E1 E1 services are the European equivalent of T1 services. This is also used in Australia and Asia. It provides 30 channels on a single circuit at a transmission rate of megabits per second (Mbps). Each channel of 64 kbps can carry voice and data. Determining the number of telephone lines Before you start building your IVR application, you need to decide the required number of telephone lines that will deliver your business objectives. Determining traffic You can determine the number of lines required by using past telephony traffic data. If historical traffic data is not available, estimate the telephone lines requirement by estimating the: Number of calls expected during peak hours Average call duration The acceptable percentage of blockage: the percentage of callers that receive busy tones during your peak hours. To the caller, this equates to the average time that they must wait before their call is answered. You can use the number of peak-hour calls and the average call hold time to calculate the telephone traffic in units known as erlangs. Page 12 of 24

13 With the projected telephone call traffic, calculate the telephone traffic in erlangs by this equation: Traffic (erlangs) = (Number of call during peak hours)*(average call time)/3600 Determining the blockage rate Traffic in erlangs cannot be translated directly into number of telephone lines. To determine how many lines you need, you must also know what blockage rate which will acceptable to your callers. Blockage rate indicates what percentage of callers will not be connected right away. For example, a blockage rate of 1% means that if 500 people call during peak hours, five of them will receive busy tones or have to wait in the switch queue. If you are already operating with a high blockage rate, you may be losing a lot of the calls you would be getting with a lower blockage rate. So, if you assume a lower blockage rate when you calculate the number of lines, you should also perhaps assume a higher erlang number. After you have determined the traffic in erlangs, you can look up the telephone traffic table as shown below for the required number of lines with the assumed acceptable percentage of blockage. Table 1. Number of lines required according to traffic and blockage rate Acceptable Blockage Rate 0.1% 0.5% 1% 2% 5% Traffic in Erlangs Number of Lines Required Page 13 of 24

14 After you have determined the number of telephone lines, you then need to know how these lines are connected. They could be connected to a Central Office (CO) switch, the switch point where all the telephone lines are connected, or to a private automatic branch exchange (PABX), which is a telephone system which switches calls among enterprise users on local lines, while allowing all users to share a certain number of external phone lines. The connection can be analog or digital. Telephony interface cards Telephone interface cards are used to connect the telephone system to the software voice server. They are installed by a hardware person on the server that runs the voice server. Websphere Voice Server with Websphere Voice Response supports these cards: Dialogic Board Locator Technology (BLT ) Hardware Configurable Antares PCI is a local bus standard. A bus is a channel used to transfer data to (input) and from (output) a computer and to or from a peripheral device. Most PCs have a PCI bus usually implemented at 32-bits providing a 33 MHz clock speed with a throughput rate of 133 MBps. PCI cards were developed by Intel, Industry standard architecture (ISA) cards are the most common bus architecture on the motherboard of MS-DOS computers. The ISA cards come in an 8-bit and 16-bit version. The 16-bit version is the most common and carries data up to 5 megabytes per second. The boards are connected like this, as shown in Figure 5: ISA cards are connected using a System Computer Bus (SCbus) cable. PCI cards are connected using a Computer Telephony Bus (CTbus) cable. A mixture of ISA and PCI cards needs to be connected using a CTbus-to-SCbus adapter cable. Page 14 of 24

15 Figure 5. Cable and card connections Telephony software platforms Next, consider the telephony software to support the cards (hardware). There are different telephony software platforms available in the market, including IBM s WebSphere Voice products, Dailogic, and Cisco products. This article focuses on the IBM offerings. IBM s support for voice applications IBM offers products to help you build and deploy voice applications. Let s look at several of these products: 1. Websphere Voice Server, shown in Figure 5, provides the various engines to drive the voice application. 2. WebSphere Voice Response, which enables business enterprises and service providers to give callers access to their business applications and data, anytime, anyplace, from any telephone. 3. Voice Toolkit for WebSphere Studio, provides a voice application development environment Page 15 of 24

16 Figure 6. WebSphere Voice Server environment IBM Websphere Voice Server The WebSphere Voice Server is a platform that enables creation of voice applications using industry standards such as VoiceXML and Java. It provides server-based voice technologies that enable speech access to information, allowing anyone with a telephone to access e-business applications and data simply by speaking. Specifically, it provides the base speech recognition, text-to-speech, and telephony connector support for within the supported telephony platforms as shown in Figure 5. You can connect Websphere Voice Server to any of other telephony platforms: With WebSphere Voice Response for AIX, you can develop environment, voice applications can be developed in any of the programming languages supported by WebSphere Voice Response for AIX (VoiceXML, Java, or State Tables). Page 16 of 24

17 Cisco telephony platform. WebSphere Voice Server provides the speech technologies for customers wanting to implement VoiceXML applications within a Cisco Voice over IP (VoIP) environment on Windows In this environment, a separate Cisco VoIP gateway is required, which converts the incoming voice data to IP packets that can be transferred over the data network to the Voice Server. WebSphere Voice Server connects to the Intel Dialogic telephony platform. This solution provides the speech technologies for customers wanting to implement VoiceXML applications within an Intel Dialogic-based telephony environment on Windows WebSphere Voice Server includes these components: A VoiceXML browser, which is the implementation of the interpreter context as defined in the VoiceXML 1.0 specification. The VoiceXML Browser handles telephone calls and manages the interaction between the caller and the VoiceXML application. It processes the calls and, fetches VoiceXML documents from a location specified by the application (for example, a URI in WebSphere Application Server or local disk), parses and interprets the documents, manages the dialog by playing audio prompts, accepts user voice and DTMF input, and acts on this input. The VoiceXML Browser is a Java application. It uses HTTP over a LAN or the Internet to fetch VoiceXML application pages from a Web application server. The Java console provides information on the prompts played, resource files fetched, and user input recognized. The VoiceXML Browser contains a DTMF Simulator that enables you to simulate DTMF input (for example, PIN codes or passwords) on your desktop. The DTMF Simulator takes the place of a telephone and lets you perform desktop debugging of voice applications without having to connect to telephony hardware and the PSTN. The DTMF Simulator and the Java console are the only visual interfaces provided by the VoiceXML Browser. A Telephony connector manages telephone calls, routing call information, and exchanging audio data with the telephony platform. A Speech recognition engine recognizes voice input from a customer responding to prompts generated by a VoiceXML application. The recognition results are used within the VoiceXML application to fill in form items or select among menu items. The engine uses telephony acoustic models for accurate speech recognition over telephone lines to accept voice input and generate synthesized speech output. A TTS engine converts text to synthesized speech. The text source may come from prompts within a VoiceXML application or from data that is retrieved from a database. Page 17 of 24

18 Figure 7 shows the role the WebSphere Voice Server plays in the context of enabling business applications for voice. The diagram depicts a multi-channel access scenario, either telephony or Web-based, where Voice Server plays a key role in bridging the gap between the telephony environment and the enterprise s information processing infrastructure. Voice Server complements the combined capabilities offered by the enterprise s WebSphere Application Server and CTI server, enhancing the quality of service and efficiency of the contact center. CTI stands for Computer and Telephony Integration, which is the exchange of information between computers and telephone systems. For example, when a call comes in, it could pass to the computer the telephone number of the person calling, which could be used to perform a look-up in the customer database and display the caller's record before the call is answered. Page 18 of 24

19 Figure 7: Voice Server and in the enterprise environment Voice Toolkit for WebSphere Studio To assist in the development and deployment of voice applications, IBM provides a Voice Toolkit that plugs into WebSphere Studio. You can use it to develop VoiceXML applications which can be deployed on Voice Server. WebSphere Voice Toolkit provides an editor, grammar, a VoiceXML editor, pronunciation builder, a testing simulator, Voice portlet tools, reusable dialog components, and other tools to help application developers create voice applications in a minimal amount of time. You can download the Voice Toolkit for free from ibm.com/software/pervasive/ products/voice/voice_toolkit.shtml. IBM WebSphere Voice Response WebSphere Voice Response for AIX and for Windows enables business enterprises and service providers to give callers access to their business applications and data, anytime, anyplace, from any telephone. WebSphere Voice Response is a highly-scalable voice-processing platform with interactive voice response capability. You use WebSphere Voice Response to enable multiple, concurrent voice applications, such as self-service access and updating of information, voice messaging, and fax. Customers and employees have direct access to services and information 24 hours a day, 7 days a week, by telephone or through the Web. Page 19 of 24

20 WebSphere Voice Response connects callers to Customer Relationship Management (CRM) applications to enable affordable self-service transactions by telephone. You can use it to provide new or out-of-hours services, and to reduce call center waiting times and costs. It is used by network service providers, CRM service providers such as banks, and by business support functions such as human resources, registration or appointment management. Voice recognition can be combined with WebSphere Voice Response for more comprehensive and flexible IVR solutions. IBM WebSphere Voice Response supports open standards, including JavaBeans. VoiceXML, and VoIP support are also available. What WebSphere Voice Response applications do WebSphere Voice Response application interacts with a calling or a called party. Typically, a voice application either handles inbound calls or makes outbound calls. Inbound calls WebSphere Voice Response automatically answers each inbound call, and uses information about the call to pass to the appropriate voice application. WebSphere Voice Response can run many different applications simultaneously. The application then plays a recorded greeting to the caller, and then prompts the caller to indicate what information they want. The caller can interrupt the prompt if they already know what they want to do. The application can be designed to play greetings in different languages depending on information such as the number that the caller dialed, or the caller s own number. Outbound calls A voice application could be triggered to make an outbound call. The application would make the telephone call, to a telephone number which is stored in a database. If WebSphere Voice Response makes the call, it can determine whether the call is answered or if the line is busy. WebSphere Voice Response can play a recorded greeting. It can then prompt the called party to tell it what to do next. After the initial greeting, an outbound call follows much the same sequence as an inbound call. The called party should have the opportunity to ask for other actions to be taken. Again, just as with an inbound call, either the called party or the WebSphere Voice Response application may end the interaction. The called party may either hang up, or tell the application not to take any further action, in which case the application must disconnect. Transferring calls An application can transfer either an inbound or outbound call to another extension. Page 20 of 24

21 Adding voice interaction to existing Web applications For many businesses today, the company Web site is the primary, sometimes the only, customer interface. As they grow, they would like to continue to develop and expand on this interface, while minimizing the number and types of IT architectures. You can add voice access to existing Web sites without replacing or making major renovations to them. To enable an existing Web application for voice interaction, you need: IBM Websphere Voice Server IBM Websphere Voice Response An application development tool, such as Voice Toolkit for WebSphere Studio Here's how a voice-enabled Web site works. 1. Telephone calls come in on an ordinary telephone line to a connection environment as in Figure 6. The primary purpose of the connection environment is to transfer the telephone voice data to a WebSphere Voice Server. The connection environment can be WebSphere Voice Response, Cisco, or Intel Dialogic (with more to come). 2. Next it is received by the WebSphere Voice Server. The server runs the voice recognition and text-to-speech software, multiple instances of the voice browser, and call management software that stacks and controls the incoming calls as they go through the system. 3. The recognition engine analyzes the audio stream and converts it to digitized text. The digitized text is then sent to the voice browser, which creates HTTP requests as necessary, and accesses the target information over the network. This is analogous to a visual browser, except that speech-enabled requests look for Web pages written in VoiceXML code, not HTML. 4. The application resides on a Web application server such as WebSphere Application Server, which contains pages of both visual HTML and VoiceXML code. Data is accessed from various databases as needed. As each HTTP request is received, information is returned to the requesting server in the form of VoiceXML pages, which the IBM Text-To-Speech engine reads back to the caller. The Voice Browser extends this paradigm by presenting the same Web information through a different media. Now, instead of displaying it visually (through HTML, graphics and text), the Voice Browser plays it to the caller audibly using VoiceXML. When the caller speaks a response -- the voice equivalent of clicking on a visual link -- the Voice Browser sends an HTTP request to the Web server, which may access the same back-end infrastructure, to return information, only this time it is VoiceXML instead of HTML. Page 21 of 24

22 The Voice Browser and VoiceXML are not just providing a way of reading Web pages to a caller over the phone. Because a VoiceXML application is providing an audio-only interface, it needs to change the way information is presented. The point is that it changes the presentation of the information, not the information itself or the way it is generated by the Web server or the back-end system. VoiceXML provides a whole new way of accessing the same Web information, by providing voice access to Web data and services. Conclusion This article provided an introduction into IVR application development. It discussed the basic requirements, including hardware and software, for building IVR applications. Resources Websphere Voice Response for Windows Websphere Voice Response for AIX WebSphere Voice Server Websphere Voice Server Support Websphere Voice Server for Websphere Voice Response Voice Toolkit for WebSphere Studio Free download from products/voice/voice_toolkit.shtml IBM Redbooks: WebSphere Voice Systems Solutions VoiceXML About the author Suneetha Chittamuri is a Senior Software Engineer in the Financial Service Sector department in IBM India. She is the project technical lead on a voice-enabled Web application development project. Page 22 of 24

23 Appendix. Voice terminology The following are some of the terms commonly associated with telephony and voice technologies: Acceptance/Rejection - The two states of recognition results that can be returned by the TTS engine: recognized text and confidence score. Accuracy - A quantitative measure of a speech recognition system's performance. Annotation - Alphanumeric tags embedded within the text sent to the TTS engine. They are applied to change some TTS characteristics, for example the gender, speed, and emphasis of the spoken voice. Automatic Number Identification (ANI) - Often known as the calling number, ANI is an optional feature that the central office (CO) telephony switch or PBX provides at call setup time. ANI can be used to personalize the experience by coding an application to determine whether the customer is using the system for the first time or to greet the customer by name. Barge-in - The ability to interrupt a playing prompt by saying something or by pressing a key on the telephone keypad. Dictionary - A collection of pronunciations or phonetic representations of words. The TTS engine uses a dictionary along with the knowledge of the language it is synthesizing to pronounce words from the input text. Typically, there is a default dictionary, and there are also exception dictionaries into which custom pronunciations of words can be added. The search order is exception dictionaries first, and then the default dictionary. Dialed Number Identification Service (DNIS) - Also referred to as the called number, DNIS is another optional feature that the CO or PBX provides when the call is established. DNIS can be used to distribute incoming calls among different voice applications. Grammar - A specification of the spoken words, phrases, and sentences that the system can process and convert to text. Phoneme - The basic unit of speech in a given language. It represents a unique sound, not necessarily equivalent to a letter of the alphabet. For example, there are different phonemes for the a sound in the words place, cat, and ball. Prompt -The audio played during a telephone call. Pronunciation - The phonetic representation of a word. For example, the word schedule can be pronounced as skehduwl in US English or as shehdyuwl in UK English. Prosody - How well the output shows the speech rhythm, patterns, and even its irregularities. Utterance - A single stream of speech between two periods of silence. Vocabulary - Total set of words that the TTS engine can pronounce. Theoretically, the vocabulary of TTS is unlimited; that is, the engine should be able to pronounce any given text string. Dual-Tone Multi-Frequency Pad (DTMF) or Rotary Dial - Signaling device that generates the pulses or tone required to identify the called number and billing information erlang - Unit of the telephone traffic. Page 23 of 24

24 blockage rate - Rate at which callers receive busy tones during your peak hours. To the caller, this equates to the average time that they must wait before their call is answered. POTS - It is traditional phone Service (some times called POTS for plain old Telephone Service) connects your home or small business to a telephone company office over copper wires that are wound around each other and are called twisted pair. POTS was created to let you exchange voice information with other phone users and analog signal was used for this kind of transmission. IVR - interactive voice response. A software application which accepts a combination of voice telephone input and touch-tone keypad selection and can provide appropriate responses in a variety of media, including voice, fax, callback, , and others. IVR is usually part of a larger application that includes database access. Acronyms IVR POTS ADSI ANI CLID DTMF PSTN PBX BLT ISA PCI DNIS TTS WVR Interactive Voice Response Plain Old Telephone Service Analog Display Services Interface Automatic Number Identification Calling Line Identification Dual Tone Multiple Frequency Public Switch Telephone Network Private Branch Exchange Board Locator Technology Industry Standard Architecture Peripheral Component Interface Dialed Number Identification Service Text To Speech Websphere Voice Response Trademarks DB2, IBM, and WebSphere are trademarks or registered trademarks of IBM Corporation in the United States, other countries, or both. Windows and Windows NT are registered trademarks of Microsoft Corporation in the United States, other countries, or both. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Other company, product, and service names may be trademarks or service marks of others. IBM copyright and trademark information: Page 24 of 24