Specialized applications
December 2008 © 2008 Avaya Inc. applicable license agreements, such as "shrinkwrap" or "clickwrap" license accompanying or applicable to the Software ("Shrinkwrap All Rights Reserved. License"). The text of the Shrinkwrap License will be available from Avaya upon End User’s request (see “Third-party Components" for Notice more information).
While reasonable efforts were made to ensure that the information in Copyright this document was complete and accurate at the time of printing, Avaya Inc. can assume no liability for any errors. Changes and corrections to Except where expressly stated otherwise, the Product is protected by the information in this document might be incorporated in future copyright and other laws respecting proprietary rights. Unauthorized releases. reproduction, transfer, and or use can be a criminal, as well as a civil, offense under the applicable law. Documentation disclaimer Third-party components Avaya Inc. is not responsible for any modifications, additions, or deletions to the original published version of this documentation unless Certain software programs or portions thereof included in the Product such modifications, additions, or deletions were performed by Avaya. may contain software distributed under third party agreements ("Third Customer and/or End User agree to indemnify and hold harmless Party Components"), which may contain terms that expand or limit Avaya, Avaya's agents, servants and employees against all claims, rights to use certain portions of the Product ("Third Party Terms"). lawsuits, demands and judgments arising out of, or in connection with, Information identifying Third Party Components and the Third Party subsequent modifications, additions or deletions to this documentation Terms that apply to them is available on the Avaya Support Web site: to the extent made by the Customer or End User. http://support.avaya.com/ThirdPartyLicense/
Link disclaimer Preventing toll fraud Avaya Inc. is not responsible for the contents or reliability of any linked "Toll fraud" is the unauthorized use of your telecommunications system Web sites referenced elsewhere within this documentation, and Avaya by an unauthorized party (for example, a person who is not a corporate does not necessarily endorse the products, services, or information employee, agent, subcontractor, or is not working on your company's described or offered within them. We cannot guarantee that these links behalf). Be aware that there can be a risk of toll fraud associated with will work all the time and we have no control over the availability of the your system and that, if toll fraud occurs, it can result in substantial linked pages. additional charges for your telecommunications services.
Warranty Avaya fraud intervention Avaya Inc. provides a limited warranty on this product. Refer to your If you suspect that you are being victimized by toll fraud and you need sales agreement to establish the terms of the limited warranty. In technical assistance or support, call Technical Service Center Toll addition, Avaya’s standard warranty language, as well as information Fraud Intervention Hotline at +1-800-643-2353 for the United States regarding support for this product, while under warranty, is available and Canada. For additional support telephone numbers, see the Avaya through the Avaya Support Web site: http://www.avaya.com/support Support Web site: http://support.avaya.com
Licenses Suspected security vulnerabilities with Avaya Products should be reported to Avaya by sending mail to: [email protected]. USE OR INSTALLATION OF THE PRODUCT INDICATES THE END USER'S ACCEPTANCE OF THE TERMS SET FORTH HEREIN AND Trademarks THE GENERAL LICENSE TERMS AVAILABLE ON THE AVAYA WEB SITE http://support.avaya.com/LicenseInfo/ ("GENERAL LICENSE Avaya, the Avaya logo, Avaya Interactive Response, Avaya IVR TERMS"). IF YOU DO NOT WISH TO BE BOUND BY THESE TERMS, Designer, Avaya Communication Manager, CONVERSANT, and Avaya YOU MUST RETURN THE PRODUCT(S) TO THE POINT OF Dialog Designer are either registered trademarks or trademarks of PURCHASE WITHIN TEN (10) DAYS OF DELIVERY FOR A REFUND Avaya Inc. in the United States of America and/or other jurisdictions. OR CREDIT. All other trademarks are the property of their respective owners. Avaya grants End User a license within the scope of the license types described below. The applicable number of licenses and units of Downloading documents capacity for which the license is granted will be one (1), unless a different number of licenses or units of capacity is specified in the For the most current versions of documentation, see the Avaya Support Documentation or other materials available to End User. "Designated Web site: http://www.avaya.com/support Processor" means a single stand-alone computing device. "Server" Contact Avaya Support means a Designated Processor that hosts a software application to be accessed by multiple users. "Software" means the computer programs Avaya Inc. provides a telephone number for you to use to report in object code, originally licensed by Avaya and ultimately utilized by problems or to ask questions about your product. The support End User, whether as stand-alone Products or pre-installed on telephone number is 1-800-242-2121 in the United States. For Hardware. "Hardware" means the standard hardware Products, additional support telephone numbers, see the Avaya Web site: http:// originally sold by Avaya and ultimately utilized by End User. www.avaya.com/support License types Concurrent User License (CU). End User may install and use the Software on multiple Designated Processors or one or more Servers, so long as only the licensed number of Units are accessing and using the Software at any given time. A "Unit" means the unit on which Avaya, at its sole discretion, bases the pricing of its licenses and can be, without limitation, an agent, port or user, an e-mail or voice mail account in the name of a person or corporate function (e.g., webmaster or helpdesk), or a directory entry in the administrative database utilized by the Product that permits one user to interface with the Software. Units may be linked to a specific, identified Server.
Shrinkwrap License (SR). With respect to Software that contains elements provided by third party suppliers, End User may install and use the Software in accordance with the terms and conditions of the
2 Specialized applications December 2008 Contents
Chapter 1: Speech applications...... 7 Speech file system...... 7 Speech development tools and features...... 9 Developing speech...... 11 Determining the transaction...... 12 Planning the voice script...... 12 Writing the voice script...... 13 Selecting a speech development method...... 15 Editing speech...... 18 Using NLSR in voice applications...... 18 Barge-in and NLSR...... 18 Using NLSR external functions in an IVR Designer application...... 19 Putting it together...... 21 Using NLSR with other features...... 21 Using Text-to-Speech and prerecorded speech together...... 21 Comparison of recognition types...... 22 Enhanced basic speech formats...... 22 Languages available...... 22 Background information...... 24 EBS formats...... 27 Developing language implementations and custom formats...... 79 Chapter 2: ASAI applications...... 85 ASAI application types...... 85 ASAI versus the converse vector step...... 89 ASAI application design...... 90 Using ASAI in a call center...... 96 Call-flow design...... 98 Host application planning and design...... 105 Call flow examples...... 108 Call to an agent via an ACD split...... 109 Call to an agent via VDNs with Call Prompting...... 110 Call to a VDN and abandoned in queue...... 112 Call to a VDN and abandoned after agent selection...... 113 Agent-to-agent transfer via a VDN and blind transfer...... 114 Agent-to-agent transfer to a station via blind transfer...... 117 Agent-to-agent transfer via a VDN and consult transfer...... 120 Agent-to-agent transfer to a station via a consult transfer...... 122 Avaya IR system-to-agent transfer via an ACD split...... 125 Chapter 3: CTI applications...... 129 ctiCallInfo...... 129 ctiCallState...... 130 ctiConfer...... 131 ctiDial...... 132 ctiDiscon...... 132 ctiHold...... 133 ctiNotify...... 134 ctiPrivData...... 135
Specialized applications December 2008 3 Contents
ctiRetrieve...... 136 ctiTransfer...... 136 Chapter 4: Avaya Interaction Center applications...... 139 Overview of Vesp_dip...... 139 Rules for integrating with IC applications...... 139 Using the Vesp_dip functions...... 140 Overview of Vesp_dip functions...... 140 Creating requests to the VOX server...... 141 Vesp_dip...... 142 +create...... 142 +getarg...... 143 +send...... 144 +setarg...... 144 newcall...... 146 pseudo_ani...... 147 getvdu...... 148 getvox...... 149 setvdu...... 150 tr
4 Specialized applications December 2008 Contents
Interpreting DTDs...... 175 Creating the template...... 177 Queries and updates...... 178 The Vonetix interface...... 178 Index...... 181
Specialized applications December 2008 5 Contents
6 Specialized applications December 2008 Chapter 1: Speech applications
Speech file system
All speech to be played as part of an application resides in a mounted file system. By default, speech file systems reside in /voice1, which is linked to /home2. These two file systems can be used interchangeably. With the Avaya IR system, you can define where in /voice1 or /home2 speech files are stored. Speech encoding and storage Each speech phrase requires a minimum of 8 KB of space. Default speech directory The default speech directory is designated as /voice1/vfs/talkfiles. It is organized into 8-KB blocks, which allows for quick and efficient retrieval of speech files. Specifying a speech directory Use the following procedure to change the directory in which speech files are stored from the default (/voice1/vfs/talkfiles ): 1. Stop the voice system. 2. Access the /vs/data/irAPI.rc file. 3. Add the following entry, where directory is the full path of the new directory where you want to store speech files: SPEECHDIR= directory The SPEECHDIR variable specifies the new directory. 4. Restart the voice system. The speech administration tools (for example, add, copy, and erase) are available for use only with speech files stored in the speech directory defined by the SPEECHDIR variable in the irAPI.rc file. Saving and restoring speech files Speech files are backed up when a system backup is performed. Adding a second speech disk If you require speech-intensive applications, or if your system has 72 or more channels (telephone network connections), it is recommended that you add a second disk specifically for storing speech. Defining phrases A phrase is a unit of speech, such as a letter, number, word, sentence, or paragraph, that a speech application script speaks to a caller. Examples of phrases include a welcome message, Specialized applications December 2008 7 Speech applications
a bank balance, or the name of a month. Every phrase in a speech application script is identified by a phrase tag or phrase number. The application speaks a phrase to callers by referencing either the phrase tag or the phrase number in the application. See "Defining phrase tags" and "Defining phrase numbers" for more information. Defining phrase tags A phrase tag is a string of up to 50 characters that identifies the contents of a phrase used by an application script. In other words, a phrase tag identifies a specific phrase. When you define a message to be played during a transaction, you specify a given phrase by its phrase tag (as opposed to its content). The two types of phrase tags are as follows: • Enhanced Basic Speech (EBS): - Currency (such as dollars and cents) - Time – hours, minutes, and seconds on the 12-hour (a.m./p.m.) or 24-hour clock - Days of the week - Months - Numbers - Characters The EBS package includes prerecorded speech formats corresponding to the above types of phrases for all supported languages. For a list of these formats, see EBS format tables. IVR Designer uses predefined EBS phrase tags for spoken output, such as digits and letters in various inflections. For more information about IVR Designer, see the EBS-related topics in the Avaya IVR Designer Help.
Note: Predefined EBS phrase tags begin with a colon (:). Therefore, do not use a colon as the first character in any custom phrase tag.
• Custom speech Custom phrase tags are designed specifically for the application you are developing and are usually more than one word in length. Examples: - "Your account balance is" - "Please enter your account number" - "The current interest rate is" Defining phrase numbers A phrase number is a number that identifies the contents of a phrase used by an application script. A script speaks a phrase to callers by referencing either the phrase tag or the phrase number. A phrase number is assigned to a phrase when you add the phrase to an application
8 Specialized applications December 2008 Speech development tools and features
(for example, when you add a phrase through a Prompt and Collect node in a IVR Designer application). Defining talkfiles A talkfile is a list of phrases usually associated with an application script. Talkfiles are stored under the directory /speech/talk. All of these files have a .pl extension. The first line in the file shows the talkfile number. The rest of the file displays the phrases (as they were entered in the application) preceded by their phrase numbers. The actual phrases are located in the speech file system. Each talkfile can contain as many as 65,535 phrases. The talkfile number and phrase tag or phrase number together uniquely identify a phrase. Defining speech files A speech file is a file containing an encoded speech phrase. Speech files can be stored anywhere, although the default speech file system is located in the /voice1/vfs/talkfiles directory. Defining the speech file system A speech file system is a file system where speech resides and is defined in the irAPI.rc file. Only one speech file system can be active at a given time.
Speech development tools and features
Most applications involve playing speech to a caller. The following speech development tools and features are available for the creation, editing, recognition, and inclusion of speech in an application. • Avaya IVR Designer • Proxy Text-to-Speech feature • Speech Recognition features Avaya IVR Designer The Avaya IVR Designer application development tool enables you to design applications that specify every detail of the interaction between the Avaya IR system and its callers. For example, the greeting heard by the caller when connecting with the service, the menu of options offered, the way callers are prompted for credit card numbers and other pertinent information, how long to wait for caller responses, and the relevant databases that need to be accessed are all parts of an application that you can define and implement using the Avaya IVR Designer application development tool. Once an application is designed, you can use IVR Designer to test, generate, transfer, and install it. You can also record and edit Speech phrases with IVR Designer. IVR Designer applications are developed on a Windows-based PC and then installed on the Avaya IR system.
Specialized applications December 2008 9 Speech applications
For more information about IVR Designer, see the Avaya IVR Designer Help. Proxy Text-to-Speech (PTTS) feature The Avaya IR system has a number of features available that can greatly enhance your ability to use it effectively. Among these is the Proxy Text-to-Speech (PTTS) feature that lets you convert text input to spoken output. Text-to-speech processing must be done using one or more auxiliary computers connected to the Avaya IR system in a client/server configuration. The current release of the PTTS feature supports two basic classes of languages: • Japanese • Microsoft Speech Application Programming Interface (SAPI)-compliant languages, which typically include English and most western European and Latin American languages With the open architecture provided by this feature, you can also add other customized languages, possibly with the assistance of an independent software vendor (ISV). The PTTS feature consists of software that is installed on a Avaya IR client system and on one or more customer-provided servers running the Windows operating system. These computers communicate through socket interface connections, called PTTS connections, over an Ethernet Local Area Network (LAN). Multiple Avaya IR clients and their associated PTTS servers can be placed on a single LAN. The Avaya IR client establishes the PTTS connections and submits text to a PTTS server for conversion. The PTTS feature supports multiple languages, and even the use of multiple languages within a single IVR application. Characteristics of the PTTS speaking voice, such as gender, rate of speech, volume, pitch, and intonation, can be customized. Barge-in (talkoff) can also be enabled to allow a caller to interrupt speech playback. PTTS is licensed on a per-connection basis. The PTTS and TTS features share the same licensing. This means that if you already have TTS licenses, you can also use them for PTTS. Speech recognition features Speech recognition is a Avaya IR system feature that allows the system to recognize and respond to spoken responses from the caller. Natural Language Speech Recognition Natural Language Speech Recognition (NLSR) provides a natural conversational interface with IVR systems. NLSR can be used to recognize particular words and phrases and to interpret and assign meaning to the speech it recognizes. For example, under the more basic forms of speech recognition, a caller can respond only to specific prompts, such as "Say `one' if you want information about..." or "Say `yes' if this is correct." NLSR enables you to write applications that ask the caller more open-ended questions, such as a banking application that presents the caller with a list of options and then asks "What would you like to do?" Then, when the caller responds "I'd like to know the balance of my checking account, please," the system can recognize what kind of information the caller is asking for (the balance in a checking account ) and can automatically direct the call to a new prompt that asks for the caller's checking account number. This new technology provides a more natural way of interacting with callers. It is worth noting that NLSR is also able to take into account grammatical structures. This allows it, for instance, to recognize and deal appropriately with differences in statements like the following caller responses:
10 Specialized applications December 2008 Developing speech
"I would like to fly from Chicago to LAX." "I need to get from LAX to Chicago." NLSR is also capable of understanding natural numbers ("seventy-six" instead of "seven six"), natural dates ("July 26th" instead of "zero seven two six") and natural currency ("25 dollars" instead of "two five zero zero"). The NLSR offer assumes you are using one or more Avaya IR systems in conjunction with one or more NLSR computers in a client/server configuration. This setup assumes that the Avaya IR is the client and the NLSR computer is the server. Beyond that, the exact NLSR system architecture is dependent on what other components you are using in conjunction with this offer. All computers in the system communicate using an Ethernet PCI local area network (LAN) connection.
Developing speech
Developing speech provides background information for the process of creating speech on the Avaya IR system. Speech processing begins with the creation of encoded and digitized speech files for disk storage. The content of each speech file is a single speech phrase that is spoken at some point in an application dialog. A speech phrase can consist of any of the following elements: • A complete sentence • A single word • A silence period of specified duration • Music • A tone (for example, a "beep") Speech phrases are typically specific to a single application. You determine the speech phrase content based on the application requirements. However, some speech phrases, such as generic greetings or prompts, may be used in multiple applications. During a call, the individual speech phrases specified in the application are downloaded by the system from a hard disk drive to the speech resource. The speech resource actually plays the speech.
Specialized applications December 2008 11 Speech applications
Determining the transaction Background The application provides the automated version of the communication between the caller and the agent. The transaction is one component of the application that involves the actual exchanges between the caller and the agent. The transaction is also referred to as the call flow. Before you can begin speech development, you must determine the transaction for the application. It is also a good idea to develop an outline of the application, as well as a general idea of what speech phrases and prompts are necessary. For example, you must decide what type of service you are going to provide, as well as the language and the gender in which the speech will be recorded. Reference For information on: • Planning a voice response application, see Planning voice response applications. • Developing an application using IVR Designer, see the topics for Creating an Application in the Avaya IVR Designer Help. • Developing an application using Response Application Programming Interface (IRAPI), the Transaction Assembler Script (TAS) language, or C language, see Developing voice applications.
Planning the voice script
The voice script includes the exact phrases to be recorded, based on the transaction you determine. The following are suggestions to consider while writing the voice script: • Track the contents of the voice script by using phrase numbers. Number each phrase in the written voice script. (Note that this is done for you automatically in IVR Designer applications.) • Write out every word you expect to be spoken. Edit the voice script to change any poorly written or repetitive phrases. The voice script should be as clear as possible so that a speaker can use it to record phrases. • Ensure that changes are written into the voice script if changes are made during recording. • Make all commands short and easy to understand. Also, users tend to remember only the ends of phrases, so place the needed caller action at the end of a phrase, for example, "For account information, press one." • Make prompts clear, but courteous. Remember to welcome users to your company and the system. Thank them at the end.
12 Specialized applications December 2008 Writing the voice script
• Use vocabulary that is understandable and not beyond the scope of your users. For example, do not use computer or programming terminology unless it is familiar to all of your users. • Use the following types of phrases in your voice script: - Long phrases that stand alone, for example, "Welcome to the XYZ order entry system." Long phrases are easier to speak for a recording because they stand alone. - Short phrases that you plan to concatenate, for example, "Your balance is" "Press 1" Typically, short phrases include phrases that you will use repeatedly. • Anticipate the environment in which the phrases will be used. That is, whether the phrase will be used at the beginning, in the middle, or at the end of a sentence. The following example shows each use of the word "enter." "Enter your account number." (phrase at the beginning of the sentence) "You must enter your account number." (phrase in the middle of the sentence) "Please press enter." (phrase at the end of the sentence) If your application contains a phrase that is used in more than one environment, you must record the phrase separately for each one. In the above example, you would need three recordings of the phrase "enter" – one phrase with rising inflection for use at the beginning of a sentence, one with medial inflection for use in the middle of a sentence, and one with falling inflection for use at the end of a sentence. Recording words with the proper emphasis is discussed in Writing the voice script. • Avoid a long string of adjectives. The following is an example of a poorly designed instruction: "Check the 5-digit class schedule number, listed to the left of the specific course, in the course offering schedule book." The following is a better example of how to word this instruction: "In the schedule book for course offerings, find the specific course you are interested in. To the left of the title is a 5-digit number used for class scheduling. Press the keys or say that number now." • Review the voice script to verify that the prompts and responses make sense.
Writing the voice script
In writing the voice script to be recorded by a professional speaker, prepare a document that produces the best recordings possible. Mark the target phrases in a way that is easy for the
Specialized applications December 2008 13 Speech applications
speaker to recognize. Placing quotation marks around the important phrases is helpful. This is called framing. Using framing in voice scripts Human speech is a continuous, uninterrupted signal. It should not be assumed that you can remove a word from one phrase and place that same word in another phrase that is being recorded for a different use. Individual words that you plan to concatenate must be carefully recorded with the proper inflections and sounds framing them. To achieve a better recording of short words and phrases, use quotation marks to frame those words you want to emphasize. For example, to achieve accurate recordings of the word "enter," use quotation marks in your voice script as follows so that the speaker concentrates on the word "enter:" "Enter" the pound sign. Please press "enter." The following are examples from a well-prepared voice script that uses framing. The information in quotation marks is the information that the professional speaker should focus on, while the remaining information is the framework. To learn more about our investment opportunities, press the "star key." "This amount represents" the total balance. "Please enter" two or one. You have "a balance of" two hundred dollars. You can deposit "up to" five hundred dollars. Analyzing speech inflections Three types of inflection exist with speech phrases: • Rising inflection Rising inflection is usually used in questions and at the beginning of some words. For example, when you ask, "Can I help you?", the word "you" is spoken with rising inflection. • Medial inflection Medial inflection is usually used in the middle of a word or statement. For example, when you speak the number "302" (as "three oh two"), the "0" is spoken with medial inflection. • Falling inflection Falling inflection is usually used at the end of a word or statement. For example, when you speak "2.0", the "0" is spoken with falling inflection.
Note: Enhanced Basic Speech formats are available for speaking phrases with rising, medial, and falling inflections. See EBS formats. Placing frame words Place words or phrases before and after the word or phrase that you need recorded, if possible. These phrases should be familiar phrases that guide the speaker into speaking the word or
14 Specialized applications December 2008 Selecting a speech development method
phrase with the correct inflection. For example, if you want an accurate recording of the word "and" with medial inflection, you could record the word "and" in both of the following frames: Installing "and" verifying Cutting "and" pasting You can remove the words that frame "and" later since they are not needed. These frame words are important, though, because the frame words enable a speaker to speak the word "and" in the context necessary to ensure that it is concatenated properly when used in a phrase.
Note: The word "and" is part of the Avaya Enhanced Basic Speech package. Selecting speech sounds for framing Words that end with the r or l sounds do not make good framing words because those sounds carry over to the next word. In this example, December "eighth" "December" is not a good frame word because it ends in an r sound, which affects the vowel quality of "eighth." A better frame word is "August," as follows: August "eighth" Including voiceless speech sounds By contrast, placing a voiceless stop before and after your target word will help achieve an accurate recording. Voiceless stops are sounds like p, t, and k. When a voiceless stop is spoken, the stream of air is blocked and the vocal cords do not vibrate, resulting in a momentary silence. In the example above, the final t of "August" provides a silence that makes it easy to isolate "eighth." Other voiceless sounds useful to end or begin a frame or space are f and s.
Selecting a speech development method
As an application developer, you have several options from which to choose for including speech in your application. The following options require you to record speech: • Hiring a professional speaker • Purchasing an Avaya custom speech package • Producing self-recorded custom speech with the IVR Designer development tool The following options do not require you to record speech: • Purchasing the EBS (Enhanced Basic Speech) package • Using TTS (Text-to-Speech)
Specialized applications December 2008 15 Speech applications
• Sharing speech already recorded in another application • Importing speech from another application Hiring a professional speaker Hiring a professional speaker, such as an actor or an announcer, gives you recorded speech of high quality. Consider the following when choosing a professional speaker: • Have all phrases prepared for the speaker to read in advance of the recording session. See Planning the voice script and Writing the voice script on page 13 for guidelines. • Audition several speakers of both sexes. Record their voices to evaluate the encoded quality. • Ensure that the speaker is able to maintain the following: - Constant speaking rhythm and general intonation throughout the recording session (this ensures that phrases spoken early in the session result in normal-sounding speech when they are concatenated with phrases spoken later in the session) - Constant acceptable level of volume - Clear pronunciation - Constant orientation and distance from the microphone • Ensure that alphabetic and numeric characters that are to be recorded with rising, medial, and falling inflections are spoken with the appropriate inflections. • Use the same speaker for all speech associated with a specific application. If you hire a professional speaker, you can edit the speech phrases for the application script. See Editing speech, for more information about editing speech. Purchasing an Avaya custom speech package You can purchase a professionally recorded custom speech package from Avaya. You write out the script and Avaya records and digitizes the speech. Custom speech packages are available with both male and female voices. Custom speech contains phrases designed specifically for the application you are developing. For example, "Thank you for calling Avaya," is a custom speech phrase. An advantage of purchasing a custom speech package from Avaya is that the speakers who record the custom speech phrases are often the same speakers who record the EBS (Enhanced Basic Speech) phrases. Therefore, a continuity can exist among scripts that use both custom and enhanced basic speech. Producing self-recorded custom speech IVR Designer allows you to record speech and store it yourself. You may want to begin with the Enhanced Basic Speech phrases mentioned previously. The standard set includes letters and digits in different speaking inflections and many commonly used phrases, such as the words used to speak dates, times, dollar amounts, etc. You can then use the recording capabilities provided with IVR Designer to record your own speech for phrases unique to your application. Speech recorded with IVR Designer default speech editor is saved in .wav files. However, when these speech files are installed on the Avaya IR system through IVR Designer, they are converted to G.711 coding.
16 Specialized applications December 2008 Selecting a speech development method
Note: The quality of speech recorded through IVR Designer is not as high as the quality produced from professionally recorded speech. Reference For information on recording speech with IVR Designer, see the Phrase Editor and Audio recording tips topics in the Avaya IVR Designer Help. Purchasing the EBS (Enhanced Basic Speech) package You can purchase the professionally recorded EBS (Enhanced Basic Speech) package from Avaya. The EBS package provides the following: • The most commonly used words and phrases, including the letters of the alphabet, pronounced and recorded in rising, falling, and medial inflections • Essential numbers ("zero" through "twenty," "thirty," "forty," "fifty," "sixty," "seventy," "eighty," "ninety," "hundred," "thousand," and "million") • Days of the week • Months of the year • Ordinal numbers 1 through 31 (that is, "1st" through "31st") • The words "dollars" and "cents" The EBS package speaks information using a variety of built-in speech formats. For example, if you want the system to speak a number using a money format, you might use number phrases followed by the phrase "dollars and," then the number of cents and the phrase "cents." For a complete listing of the available EBS formats, see EBS formats. Using PTTS (Proxy Text-to-Speech) The PTTS package is an option that eliminates the need for recording speech. You enter the phrases to be spoken, and PTTS synthesizes the speech. PTTS functionality is supported through the IVR Designer application development interfaces as well as through TAS script instructions. The talkoff function and other system features for voice response work with PTTS as they work with other speech files. PTTS, Enhanced Basic Speech, and prerecorded phrases can be used in the same application. Sharing speech Sharing speech allows two or more applications to share common speech phrases, only one copy of which exists on your hard disk. If you have more than one application on a system, it will probably be more convenient for you to use the shared speech feature. Sharing speech provides a performance advantage in that shared speech phrases need to be: • Administered and recorded only once • Stored only once, allowing you to conserve disk space Importing speech You can import speech phrases from other applications and edit them.
Specialized applications December 2008 17 Speech applications
For IVR Designer applications, you can use the Phrase Editor to import the .wav file corresponding to the phrase you want. Then you can edit the phrase with the audio editing application installed on your PC.
Editing speech
Typically, IVR Designer is used to remove unwanted silence from the beginnings and endings of recorded speech phrases. However, the audio application provided with the IVR Designer package can be used to cut and paste segments of speech within the body of a phrase. You can also edit speech files using a customer-provided audio application installed on your IVR Designer PC. To edit speech files with the IVR Designer audio application, see information about the Phrase Editor in the Avaya IVR Designer Help.
Using NLSR in voice applications
Natural Language Speech Recognition (NLSR) lets you create IVR applications that offer the caller a more natural way of interacting with the software. NLSR uses a client/server configuration in which the Avaya IR system uses one or more external NLSR servers to process speech data collected from callers during Prompt and Collect actions. NLSR is a flexible new way to take advantage of external vendor NLSR engines within IVR applications. NLSR grammars A prerequisite to creating and deploying NLSR applications is creating the required NLSR grammars. Check with your NLSR vendor for the specifics on how to create and install the required grammars. In addition to creating the actual NLSR grammars, you must also create corresponding "stub grammars" for each NLSR grammar you intend to use in your application. For information about how to create stub grammars, see Creating Stub Grammars in the Avaya IVR Designer help system.
Barge-in and NLSR
Barge-in is a capability provided by some speech recognition technologies, including NLSR, that allows callers to speak or enter their responses during a prompt and have those responses recognized and acted upon immediately without having to play the entire prompt (similar to the Speak with Interrupt capability for Announce nodes).
18 Specialized applications December 2008 Using NLSR in voice applications
Note: In the following discussion of Avaya IR applications, the use of the term "node" refers to elements used in IVR Designer applications. Barge-in is not exactly the same as the Speak with Interrupt feature used for Announce nodes. The Speak with Interrupt feature works only with touchtone input. Barge-in, which works with WholeWord and NLSR input, can accept either touchtone or spoken response inputs. Thus, the Announce node cannot use spoken responses to interrupt the Announce prompt, only touchtone input. By contrast, the Prompt and Collect node, the Menu node, and the Automenu node prompts can all be interrupted using either touchtone or spoken input from the caller.
Note: You can restrict barge-in to touchtone-only input in these nodes by selecting Touchtones as the only Input ASR Mode. However, if you select a WholeWord or NLSR grammar as the Input ASR Mode, the system also accepts touchtone input, so you effectively get both types of barge-in. To use barge-in, you must use an SR_Prompt external function in IVR Designer.
Note: When creating NLSR applications in IVR Designer that use barge-in, you should use Touchtone for all Input ASR Mode settings and make sure that you do not set "Reserve ASR Resource Before Playing Prompt" to True on the Response tab (Prompt and Collect and Automenu nodes). You can, if you want, treat different types of inputs from the caller differently in your application. When a response to a prompt is received from a caller, the system sets the $CI_RECOG system variable to identify the type of recognizer that performed the recognition. For example, if the caller responds using touchtone input, the system sets the $CI_RECOG variable to 0 (zero). If the caller responds with a spoken reply, the system sets the $CI_RECOG variable to 4. So, you can have the application look at the value stored in the $CI_RECOG variable after a caller responds to a prompt and take different actions according to whether the caller responded with touchtone or spoken input.
Using NLSR external functions in an IVR Designer application
In a typical IVR Designer application that uses NLSR, external functions are used to: • Allocate NLSR resources on the NLSR server (allocPROXY) and release NLSR resources when the application is finished with them (deallocPROXY) • Exchange command and response strings with the NLSR server (requestPROXY) The following figure shows how these external functions might be used in a typical application. Note that this is only one example of a typical call flow.
Specialized applications December 2008 19 Speech applications
These external functions allow you to incorporate natural language speech recognition into your IVR Designer applications. For more information about using external functions, see the Avaya IVR Designer Help.
20 Specialized applications December 2008 Putting it together
Putting it together
Using NLSR with other features
Natural Language Speech Recognition (NLSR) allows you to create a more natural, conversational style of interacting with the Avaya IR system. Depending on the external vendor's speech recognition engine and its capabilities, you may not need any other speech recognition technologies in your system. There may, however, be times when it is more advantageous to use a variety of speech recognition technologies, depending on what kind of speech you need to recognize at each prompt. NLSR can be used in combination with other recognition technologies such as WholeWord. If, for example, you are looking for a simple "yes" or "no" response from a caller, it may be more efficient to use WholeWord speech recognition rather than tying up your NLSR resources. In the end, however, a great deal depends on your NLSR engine and its capabilities, when trying to answer the question of whether to use other speech recognition technologies in conjunction with NLSR.
Using Text-to-Speech and prerecorded speech together
An IVR Designer application can speak prompts and announcements in prerecorded speech only, TTS only, or a combination of prerecorded speech and TTS. For example, in one application, recorded speech is used for all phrases except the customer's name. TTS allows the system to speak the contents of a "cust_name" variable, which contains the customer's name as a character string. To have this name spoken without TTS, you would have to record every possible customer name, save the phrase tag numbers of each, and associate the phrase tag number with the customer account number. Then the system would speak the phrase tag number corresponding to the customer's account number. Furthermore, each time you add a customer's name to the list, you would have to update your application, record the new name, recompile your application, transfer, and reinstall it on the Avaya IR. Obviously, this would involve a huge amount of work just to maintain the names in the system. In cases like this, it might make more sense to use TTS to speak the customer's name.
Specialized applications December 2008 21 Speech applications
Comparison of recognition types
The following table summarizes the similarities and differences between WholeWord speech recognition and NLSR.
WholeWord Recognition Natural Language Speech Recognition
Word-based Depends on external vendor NLSR engine
Requires data collection in model Depends on external vendor NLSR building for vocabulary words other than engine digits 0 through 9, "oh", and the words "yes" and "no"
Single or connected digits Single or connected digits, single word or phrase
Standard and custom grammars Custom or standard external vendor NLSR grammars
Barge-in supported Depends on external vendor NLSR engine
Phrase screening supported Phrase screening supported
Limited vocabulary Vocabulary limited by external vendor NLSR engine
Word spotting supported Depends on external vendor NLSR engine, but word spotting usually supported
Enhanced basic speech formats
Languages available
The following table lists the languages for which EBS is available and, for each language, shows the gender of the speaking voice (female or male), the abbreviation, and the phrase pool name.
22 Specialized applications December 2008 Enhanced basic speech formats
EBS Version 6.0 Speaking Voice Abbreviation Phrase Pool Name
Australian English Female ebsAE AU_English
Brazilian Female ebsBP BR_Portug Portuguese
Canadian French Female ebsCF Can_French
Cantonese Female ebsCT Cantonese Chinese
Castilian Spanish Female ebsCS Cast_Span
Czech Female ebsCZ Czech
Dutch Female ebsDT Dutch
French Female ebsFR French
German Female ebsGR German
Greek Female ebsGK Greek
Hebrew Female ebsHB Hebrew
Hindi Female ebsHD Hindi
Hungarian Female ebsHU Hungarian
Indonesian Female ebsIN Indonesian
Italian Female ebsIT Italian
Japanese Female ebsJP Japanese
Korean Female ebsKO Korean
Latin-American Female ebsLS LA_Spanish Spanish
Malay Female ebsMA Malay
Mandarin Chinese Female ebsMD Mandarin
Polish Female ebsPL Polish
Slovak Female ebsSQ Slovak
Thai Female ebsTH Thai
Specialized applications December 2008 23 Speech applications
EBS Version 6.0 Speaking Voice Abbreviation Phrase Pool Name
United Kingdom Female ebsUK UK_English (UK) English
United States Female ebsUS US_English (US) English
United States Male ebsUSM US_English (US) English
Background information Common formats The EBS package for each language contains the following common formats: • D (date) • T (time) • N (numbers) • N$ (currency) • C (characters) While common to all languages, these formats may be defined differently from language to language, as appropriate to the conventions of usage in each language. For example, T (time) is spoken as THMAM in some languages, but as TH24M in others, depending on the language specification (see "Variations on the common formats"). The definition reflects the most normal or customary manner of speaking the phrase in the language. Variations on the common formats The common EBS formats may be enhanced to include different ways to be spoken, depending on the language specification. The most frequently occurring variations on the common formats are listed below. However, some languages also contain other variations. (For information on inflections used in the formats, see "Inflections.") • Date formats always start with D, and these modifiers may follow: - YY – year spoken with four digits - Y – year spoken with two digits - M – month spoken as a number (rather than as a word) - SP – month spoken as a word (rather than as a number) - D – day (number)
24 Specialized applications December 2008 Enhanced basic speech formats
- W – weekday (name) - f – falling inflection • Time formats always start with T, and these modifiers may follow: - H – hour - 24 – 24-hour clock - M – minutes - AM – 12-hour clock (AM/PM) - f – falling inflection • Number formats always start with N, and these modifiers may follow: - M – male form - F – female form - N – neutral form - m (or mmm) – medial inflection - f (or mmf) – falling inflection - r (or rmm)-- rising inflection - rmf – total inflection • Decimal number formats always start with ND, and the number that follows indicates the number of decimal places after the decimal point. The input string is assumed not to have a decimal point in it. For example, if 12345678 is input with format ND4, the number 1234.5678 is spoken. • Currency formats always start with N$, and these modifiers may follow: - Dx – where x indicates the number of decimal places - f – falling inflection • Character formats always start with C, and these modifiers may follow: - m (or mmm) – medial inflection - f (or mmf) – falling inflection - r (or rmm) – total inflection - rmf – total inflection
Note: When you select a variable Type in the Spoken As column in the IVR Designer Variables Manager, by default IVR Designer automatically assigns the variable a common format (D, C, T, N, or N$). You can either accept the default or change it to one of the variations available for that common format. For example, when you select the character Type, the character variable defaults to the C format. You can then select another character format, if one is available in the language you have selected. For US English, you could select Crmf, Crmm, Cmmf, or Cmmm. See the section on variables in Avaya IVR Designer Help, for more information on defaults for formats. Inflections Inflection is a change in voice intonation appropriate to the context in which a speech phrase occurs. For example, typically in natural speech, rising inflection occurs in questions, medial
Specialized applications December 2008 25 Speech applications
inflection (no inflection) occurs in the middle of words and phrases, and falling inflection occurs at the end of words and phrases. The EBS package includes formats for inflections. The EBS format tables use the following terminology to describe inflections: • Rising inflection – The first character or number is spoken with rising inflection and all other others with medial inflection. • Falling inflection – The last character or number is spoken with falling inflection and all others with medial inflection. • Total inflection – The first character or number is spoken with rising inflection, the last with falling inflection, and all others with medial inflection.
Note: Unless otherwise specified, formats use medial inflection. Grammatical gender Words in some languages are spoken differently depending on whether they are grammatically male, female, or neutral. The EBS format tables use the terminology male form, female form, and neutral form to describe gender-specific formats. Converting applications to other languages An application containing EBS formats can have the formats converted to another language by changing the language option. However if the original application uses formats not available for the new language, then the converted application will not be identical. Therefore, advance planning is advisable for applications that may be converted to other languages. A recommended strategy is to create the original application using only the common formats available in all languages, create duplicate applications for the target languages, and adjust the formats on a per-application basis, if needed. (For more information, see "Common formats.") Maximum values for numbers and currency A variable defined as a number or as currency on the Avaya IR system has 4 bytes and can support a numeric value up to 2,147,483,647. To support larger numbers, for some languages the number and currency formats also accept inputs as characters. These character variables can handle values up to 15 digits (999,999,999,999,999) plus a decimal point and can be preceded by a minus sign (-) to indicate a negative number. The following table distinguishes the languages that receive only number variable support from EBS for number and currency formats from the languages that also receive character variable support.
Number Variable Support Only Character Variable Support
Australian English Brazilian Portuguese Cantonese Chinese Canadian French Castilian Spanish Czech Dutch French German Hungarian Hindi Italian Indonesian Japanese Korean Latin-American Spanish Malay Polish
26 Specialized applications December 2008 Enhanced basic speech formats
Mandarin Chinese Slovak Thai UK English US English
Speaking phrase numbers and packed talkfile numbers The NX format is a Avaya IR system feature used to speak: • A phrase with a specified phrase tag number • Packed talkfile numbers and phrase numbers The NX format is included in the EBS tables for all supported languages.
EBS formats
Australian English EBS formats
Format Description
D Date – spoken month, 2-digit day, 2-digit year
DMDYY Date – 2-digit month, day, 4-digit year
DMDY Date – 2-digit month, day, year
DMD Date – 2-digit month, day, no year
DMSPDYY Date – spoken month, 2-digit day, 4-digit year
DMSPDY Date – spoken month, 2-digit day, 2-digit year
DMSPD Date – spoken month, 2-digit day, no year
T Time – hour, minute, AM/PM
TH24M Time – hour, minute, 24-hour clock
THMAM Time – hour, minute, AM/PM
N Number – medial inflection
Nrmf Number – total inflection
Nmmf Number – falling inflection
Nrmm Number – rising inflection
Nmmm Number – medial inflection
ND Decimal number – no decimal places
Specialized applications December 2008 27 Speech applications
Format Description This format may not be valid for IVR Designer. See the topic on variables in Avaya IVR Designer Help for specific information.
ND0 Decimal number – no decimal places This format may not be valid for IVR Designer. See the topic on variables in Avaya IVR Designer Help for specific information.
ND1 Decimal number – 1 decimal place
ND2 Decimal number – 2 decimal places
ND3 Decimal number – 3 decimal places
ND4 Decimal number – 4 decimal places
ND5 Decimal number – 5 decimal places
ND6 Decimal number – 6 decimal places
ND7 Decimal number – 7 decimal places
ND8 Decimal number – 8 decimal places
ND9 Decimal number – 9 decimal places
N$ Currency – whole dollars
N$D0 Currency – whole dollars
N$D2 Currency – dollars and cents
N$D1 Currency – dollars with 1 decimal place
N$D3 Currency – dollars with 3 decimal places
N$D4 Currency – dollars with 4 decimal places
N$D5 Currency – dollars with 5 decimal places
N$D6 Currency – dollars with 6 decimal places
N$D7 Currency – dollars with 7 decimal places
N$D8 Currency – dollars with 8 decimal places
N$D9 Currency – dollars with 9 decimal places
C Characters – spoken individually, medial inflection
Crmf Characters – spoken individually, total inflection
Crmm Characters – spoken individually, rising inflection
28 Specialized applications December 2008 Enhanced basic speech formats
Format Description
Cmmf Characters – spoken individually, falling inflection
Cmmm Characters – spoken individually, medial inflection
NX The NX format is used to speak a phrase with a specified phrase tag number, or packed talkfile numbers and phrase numbers.
Brazilian Portuguese EBS formats
Format Description
D Date – spoken month, 2-digit day, 4-digit year
DMSPDYY Date – spoken month, 2-digit day, 4-digit year
DMSPDY Date – spoken month, 2-digit day, year
DMSPD Date – spoken month, 2-digit day, no year
DMSPfYY Date – same as DMSPDYY but with falling inflection
DMSPfY Date – same as DMSPDY but with falling inflection
DMSPf Date – same as DMSPD but with falling inflection
T Time – hour, minute, AM/PM
THMAM Time – hour, minute, AM/PM
TH24M Time – hour, minute, 24-hour clock
THMAMf Time – hour, minute, AM/PM, falling inflection
TH24Mf Time – hour, minute, 24-hour clock, falling inflection
N Number – total inflection
Nmf Number – falling inflection
Nrm Number – rising inflection
Nrmf Number – total inflection
NM Number – male form
NF Number – female form
Specialized applications December 2008 29 Speech applications
Format Description
NN Number – neutral form
ND0 Decimal number – no decimal places
ND1 Decimal number – 1 decimal place
ND2 Decimal number – 2 decimal places
ND3 Decimal number – 3 decimal places
ND4 Decimal number – 4 decimal places
ND5 Decimal number – 5 decimal places
ND6 Decimal number – 6 decimal places
ND7 Decimal number – 7 decimal places
ND8 Decimal number – 8 decimal places
ND9 Decimal number – 9 decimal places
N$ Currency – reais and centavos
N$D2 Currency – reais and centavos
C Characters – spoken individually, medial inflection
Crmf Characters – spoken individually, total inflection
Crmm Characters – spoken individually, rising inflection
Cmmf Characters – spoken individually, falling inflection
Cmmm Characters – spoken individually, medial inflection
NX The NX format is used to speak a phrase with a specified phrase tag number, or packed talkfile numbers and phrase numbers.
Canadian French EBS formats
Format Description
D Date – spoken month, 2-digit day, 4-digit year
DMSPDYY Date – spoken month, 2-digit day, 4-digit year
DMSPDY Date – spoken month, 2-digit day and year
30 Specialized applications December 2008 Enhanced basic speech formats
Format Description
DMSPD Date – spoken month, 2-digit day, no year
DMSPfYY Date – same as DMSPDYY, but with falling inflection
DMSPfY Date – same as DMSPDY, but with falling inflection
DMSPf Date – same as DMSPD, but with falling inflection
T Time – hour, minute, 24-hour clock
THMAM Time – hour, minute, AM/PM
THMAMf Time – hour, minute, AM/PM, falling inflection
TH24M Time – hour, minute, 24-hour clock
TH24Mf Time – hour, minute, 24-hour clock, falling inflection
TPD Time – hour, minute, 24-hour clock
THMAMPD Time – PDT (Pacific Daylight Saving Time), hour, minute, AM/PM
TH24MPD Time – PDT, hour, minute, 24-hour clock
THMAMPDf Time – PDT, hour, minute, AM/PM, falling inflection
TH24MPDf Time – PDT, 24-hour clock, falling inflection
TPS Time – hour, minute, 24-hour clock
THMAMPS Time – PST (Pacific Standard Time), hour, minute, AM/PM
TH24MPS Time – PST, hour, minute, 24-hour clock
THMAMPSf Time – PST, hour, minute AM/PM, falling inflection
TH24MPSf Time – PST, hour, minute, 24-hour clock, falling inflection
TMD Time – hour, minute, 24-hour clock
THMAMMD Time – MDT (Mountain Daylight Saving Time), hour, minute, AM/PM
N Number – total inflection
Nmf Number – falling inflection
Specialized applications December 2008 31 Speech applications
Format Description
Nrm Number – rising inflection
Nrmf Number – total inflection
NM Number – male form
NF Number – female form
NN Number – neutral form
ND0 Decimal number – no decimal places, "virgule zero"
ND1 Decimal number – 1 decimal place
ND2 Decimal number – 2 decimal places
ND3 Decimal number – 3 decimal places
ND4 Decimal number – 4 decimal places
ND5 Decimal number – 5 decimal places
ND6 Decimal number – 6 decimal places
ND7 Decimal number – 7 decimal places
ND8 Decimal number – 8 decimal places
ND9 Decimal number – 9 decimal places
NDF6 Decimal number – 6 decimal places, decimal part spoken as number
NDF7 Decimal number – 7 decimal places, decimal part spoken as number
NDF8 Decimal number – 8 decimal places, decimal part spoken as number
NDF9 Decimal number – 9 decimal places, decimal part spoken as number
N$ Currency – same as N$D2
N$D2 Number – dollars and cents
C Characters – spoken individually, medial inflection
Crmf Characters – spoken individually, total inflection
Crmm Characters – spoken individually, rising inflection
Cmmf Characters – spoken individually, falling inflection
32 Specialized applications December 2008 Enhanced basic speech formats
Format Description
Cmmm Characters – spoken individually, medial inflection
NX The NX format is used to speak a phrase with a specified phrase tag number, or packed talkfile numbers and phrase numbers.
Cantonese Chinese EBS formats
Format Description
D Date – 4-digit year, 2-digit month and day
DYMDD Date – 4-digit year, 2-digit month and day
DMD Date – month followed by day
T Time – time, period followed by time
THMAM Time – time, period followed by time
N Number – integer, medial inflection
ND0 Decimal number – no decimal places
ND1 Decimal number – 1 decimal place
ND2 Decimal number – 2 decimal places
ND3 Decimal number – 3 decimal places
ND4 Decimal number – 4 decimal places
ND5 Decimal number – 5 decimal places
ND6 Decimal number – 6 decimal places
ND7 Decimal number – 7 decimal places
ND8 Decimal number – 8 decimal places
ND9 Decimal number – 9 decimal places
N$ Currency – whole dollars
N$D0 Currency – whole dollars
N$D2 Currency – dollars and cents
N$D1 Currency – dollars with 1 decimal place
Specialized applications December 2008 33 Speech applications
Format Description
N$D3 Currency – dollars with 3 decimal places
N$D4 Currency – dollars with 4 decimal places
N$D5 Currency – dollars with 5 decimal places
N$D6 Currency – dollars with 6 decimal places
N$D7 Currency – dollars with 7 decimal places
N$D8 Currency – dollars with 8 decimal places
N$D9 Currency – dollars with 9 decimal places
NYD0 Currency – whole yuan
NYD1 Currency – yuan with 1 decimal place
NYD2 Currency – yuan, miao, and seen
NYD3 Currency – yuan with 3 decimal places
NYD4 Currency – yuan with 4 decimal places
NYD5 Currency – yuan with 5 decimal places
NYD6 Currency – yuan with 6 decimal places
NYD7 Currency – yuan with 7 decimal places
NYD8 Currency – yuan with 8 decimal places
NYD9 Currency – yuan with 9 decimal places
C Characters – spoken individually, medial inflection
Cmmm Characters – spoken individually, medial inflection
NX The NX format is used to speak a phrase with a specified phrase tag number, or packed talkfile numbers and phrase numbers.
Castilian Spanish EBS formats
Format Description
D Date – spoken month, 2-digit day, 4-digit year
DMSPDYY Date – spoken month, 2-digit day, 4-digit year
34 Specialized applications December 2008 Enhanced basic speech formats
Format Description
DMSPDY Date – spoken month, 2-digit day and year
DMSPD Date – spoken month, 2-digit day, no year
T Time – hour, minute, AM/PM
THMAM Time – hour, minute, AM/PM
TH24M Time – hour, minute, 24-hour clock
N Number – neutral form
NM Number – male form
NF Number – female form
NN Number – neutral form
ND0 Decimal number – no decimal places
ND1 Decimal number – 1 decimal place
ND2 Decimal number – 2 decimal places
ND3 Decimal number – 3 decimal places
ND4 Decimal number – 4 decimal places
ND5 Decimal number – 5 decimal places
ND6 Decimal number – 6 decimal places
ND7 Decimal number – 7 decimal places
ND8 Decimal number – 8 decimal places
ND9 Decimal number – 9 decimal places
N$ Currency – whole pesetas
N$D0 Currency – whole pesetas
N$D2 Currency – pesetas and centimos
N$EU Currency – whole Euros
N$D0EU Currency – whole Euros
N$D2EU Currency – Euros and cents
C Characters – spoken individually, medial inflection
Crmf Characters – spoken individually, total inflection
Crmm Characters – spoken individually, rising inflection
Specialized applications December 2008 35 Speech applications
Format Description
Cmmf Characters – spoken individually, falling inflection
Cmmm Characters – spoken individually, medial inflection
NX The NX format is used to speak a phrase with a specified phrase tag number, or packed talkfile numbers and phrase numbers.
Czech EBS formats
Format Description
D Date – day, spoken month, 4-digit year
DDMSPYY Date – day, spoken month, 4-digit year
DDMYY Date – day, month, 4-digit year
DMMSP Date – day, spoken month, no year
DDM Date – day, month, no year
DDMSPYYf Date – day, spoken month, 4-digit year, falling inflection
DDMYYf Date – day, month, 4-digit year, falling inflection
DMMSPf Date – day, spoken month, no year, falling inflection
DDMf Date – day, month, no year, falling inflection
T Time – hour, minute, 24-hour clock
TH24M Time – hour, minute, 24-hour clock
TH24MS Time – hour, minute, second, 24-hour clock
TH24Mf Time – hour, minute, falling inflection
TH24MSf Time – hour, minute, second, falling inflection
N Number – male form, medial inflection
NMm Number – male form, medial inflection
NMf Number – male form, falling inflection
NFm Number – female form, medial inflection
36 Specialized applications December 2008 Enhanced basic speech formats
Format Description
NFf Number – female form, falling inflection
NNm Number – neutral form, medial inflection
NNf Number – neutral form, falling inflection
ND0 Decimal number – whole number spoken as "number comma 0", no decimal places
ND1 Decimal number – 1 decimal place
ND2 Decimal number – 2 decimal places
ND3 Decimal number – 3 decimal places
ND4 Decimal number – 4 decimal places
ND5 Decimal number – 5 decimal places
ND6 Decimal number – 6 decimal places
ND7 Decimal number – 7 decimal places
ND8 Decimal number – 8 decimal places
ND9 Decimal number – 9 decimal places
NDX Decimal number – variable number of decimal places, decimal separator in argument Note: A number passed to a function can contain either a period (.) or a comma (,) to identify a number of decimal digits spoken for that number.
NDX1 Decimal number – 1 decimal place, spoken as a fraction
NDX2 Decimal number – 2 decimal places, spoken as a fraction
NDX3 Decimal number – 3 decimal places, spoken as a fraction
NDXS Decimal number – up to 3 decimal places, spoken as a fraction; otherwise NDX
NDX0S Decimal number – up to 3 decimal places, spoken as number with leading zeros; otherwise NDX
ND0f Decimal number – whole number, spoken as "number comma 0", falling inflection
ND1f Decimal number --1 decimal place, falling inflection
Specialized applications December 2008 37 Speech applications
Format Description
ND2f Decimal number --2 decimal places, falling inflection
ND3f Decimal number --3 decimal places, falling inflection
ND4f Decimal number --4 decimal places, falling inflection
ND5f Decimal number --5 decimal places, falling inflection
ND6f Decimal number --6 decimal places, falling inflection
ND7f Decimal number --7 decimal places, falling inflection
ND8f Decimal number – 8 decimal places, falling inflection
ND9f Decimal number – 9 decimal places, falling inflection
NDXf Decimal number – variable number of decimal places, falling inflection, decimal separator in argument
NDX1f Decimal number --1 decimal place, spoken as a fraction, falling inflection
NDX2f Decimal number – 2 decimal places, falling inflection
NDX3f Decimal number – 3 decimal places, spoken as a fraction, falling inflection
NDX0Sf Decimal number – up to 3 decimal places, spoken as a number with leading zeros; otherwise NDX
NDXSf Decimal number – up to 3 decimal places, spoken as a fraction, falling inflection; otherwise NDX
N$ Currency – whole crowns
N$D0 Currency – whole crowns
N$D2 Currency – crowns and hellers
N$DX Currency – crowns, spoken as a decimal number with a variable number of decimal places, decimal separator in argument
38 Specialized applications December 2008 Enhanced basic speech formats
Format Description
N$D2f Currency – crowns and hellers, falling inflection
N$EU Currency – whole Euros
N$D0EU Currency – whole Euros
N$D2EU Currency – Euros and cents
N$DXEU Currency – Euros, spoken as a decimal number with a variable number of decimal places, decimal separator in argument
N$D2fEU Currency – Euros and cents, falling inflection
C Characters – spoken individually, medial inflection
Cspd Characters – spoken individually, variable pace
Cmf Characters – spoken individually, falling inflection
Cmm Characters – spoken individually, medial inflection
NX The NX format is used to speak a phrase with a specified phrase tag number, or packed talkfile numbers and phrase numbers.
Dutch EBS formats
Format Description
D Date – spoken month, 2-digit day, 2-digit year
DMSPD Date – spoken month, 2-digit day, 4-digit year
DMSPD Date – spoken month, 2-digit day, 2-digit year
DMSPD Date – spoken month, 2-digit day, no year
T Time – hour, minute, 24-hour clock
TH24M Time – hour, minute, 24-hour clock
N Number – same as NN
ND0 Decimal number – no decimal places
ND1 Decimal number – 1 decimal place
ND2 Decimal number – 2 decimal places
Specialized applications December 2008 39 Speech applications
Format Description
ND3 Decimal number – 3 decimal places
ND4 Decimal number – 4 decimal places
ND5 Decimal number – 5 decimal places
ND6 Decimal number – 6 decimal places
ND7 Decimal number – 7 decimal places
ND8 Decimal number – 8 decimal places
ND9 Decimal number – 9 decimal places
N$ Currency – whole gulden
N$D0 Currency – whole gulden
N$D2 Currency – gulden and cents
N$EU Currency – whole Euros
N$D0EU Currency – whole Euros
N$D2EU Currency – Euros and cents
C Characters – spoken individually, medial inflection
Crmf Characters – spoken individually, total inflection
Crmm Characters – spoken individually, rising inflection
Cmmf Characters – spoken individually, falling inflection
Cmmm Characters – spoken individually, medial inflection
NX The NX format is used to speak a phrase with a specified phrase tag number, or packed talkfile numbers and phrase numbers.
French EBS formats
Format Description
D Date – spoken month, 2-digit day, 4-digit year
DMSPDYY Date – spoken month, 2-digit day, 4-digit year
DMSPDY Date --spoken month, 2-digit day and year
40 Specialized applications December 2008 Enhanced basic speech formats
Format Description
DMSPD Date – spoken month, 2-digit day, no year
DMSPfYY Date – same as DMSPDYY but with falling inflection
DMSPfY Date – same as DMSPDY but with falling inflection
DMSPf Date – same as DMSPD but with falling inflection
DMSPlYY Date – same as DMSPDYY but preceded by "le"
DMSPlY Date – same as DMSPDY but preceded by "le"
DMSPl Date – same as DMSPD but preceded by "le"
T Time – hour, minute, 24-hour clock
TH24M Time – hour, minute, 24-hour clock
TH24Mf Time – hour, minute, 24-hour clock, falling inflection
N Number – total inflection
Nmf Number – falling inflection
Nrm Number – rising inflection
Nrmf Number – total inflection
NN Number – neutral form
NF Number – female form
NM Number – male form
ND0 Decimal number – no decimal places, "virgule zero"
ND1 Decimal number – 1 decimal place
ND2 Decimal number – 2 decimal places
ND3 Decimal number – 3 decimal places
ND4 Decimal number – 4 decimal places
ND5 Decimal number – 5 decimal places
ND6 Decimal number – 6 decimal places
ND7 Decimal number – 7 decimal places
ND8 Decimal number – 8 decimal places
Specialized applications December 2008 41 Speech applications
Format Description
ND9 Decimal number – 9 decimal places
NDF0 Decimal number – no decimal place
NDF1 Decimal number – 1 decimal place, decimal part spoken as number
NDF2 Decimal number – 2 decimal places, decimal part spoken as number
NDF3 Decimal number – 3 decimal places, decimal part spoken as number
NDF4 Decimal number – 4 decimal places, decimal part spoken as number
NDF5 Decimal number – 5 decimal places, decimal part spoken as number
NDF6 Decimal number – 6 decimal places, decimal part spoken as number
NDF7 Decimal number – 7 decimal places, decimal part spoken as number
NDF8 Decimal number – 8 decimal places, decimal part spoken as number
NDF9 Decimal number – 9 decimal places, decimal part spoken as number
N$ Currency – francs and centimes
N$D2 Currency – francs and centimes
N$F Currency – whole francs
N$F0 Currency – francs with no decimal places
N$F1 Currency – francs with 1 decimal place
N$F2 Currency – francs with 2 decimal places
N$F3 Currency – francs with 3 decimal places
N$F4 Currency – francs with 4 decimal places
N$F5 Currency – francs with 5 decimal places
N$F6 Currency – francs with 6 decimal places
N$F7 Currency – francs with 7 decimal places
N$F8 Currency – francs with 8 decimal places
42 Specialized applications December 2008 Enhanced basic speech formats
Format Description
N$F9 Currency – francs with 9 decimal places
N$EU Currency – Euros and centimes
N$D2EU Currency – Euros and centimes
N$FEU Currency – whole Euros
N$F0EU Currency – whole Euros
N$F1EU Currency – Euros with 1 decimal place
N$F2EU Currency – Euros with 2 decimal places
N$F3EU Currency – Euros with 3 decimal places
N$F4EU Currency – Euros with 4 decimal places
N$F5EU Currency – Euros with 5 decimal places
N$F6EU Currency – Euros with 6 decimal places
N$F7EU Currency – Euros with 7 decimal places
N$F8EU Currency – Euros with 8 decimal places
N$F9EU Currency – Euros with 9 decimal places
C Characters – spoken individually, medial inflection
Crmf Characters – spoken individually, total inflection
Crmm Characters – spoken individually, rising inflection
Cmmf Characters – spoken individually, falling inflection
Cmmm Characters – spoken individually, medial inflection
NX The NX format is used to speak a phrase with a specified phrase tag number, or packed talkfile numbers and phrase numbers.
German EBS formats
Format Description
D Date – spoken month, 2-digit day, 4-digit year
DMSPDYY Date – spoken month, 2-digit day, 4-digit year
Specialized applications December 2008 43 Speech applications
Format Description
DMSPDY Date – spoken month, 2-digit day and year
DMSPD Date – spoken month, 2-digit day
T Time – 24-hour clock, no seconds
TH24M Time – 24-hour clock, no seconds
N Number – neutral form
NM Number – male form
NF Number – female form
NN Number – neutral form
ND0 Decimal number – no decimal places
ND1 Decimal number – 1 decimal place
ND2 Decimal number – 2 decimal places
ND3 Decimal number – 3 decimal places
ND4 Decimal number – 4 decimal places
ND5 Decimal number – 5 decimal places
ND6 Decimal number – 6 decimal places
ND7 Decimal number – 7 decimal places
ND8 Decimal number – 8 decimal places
ND9 Decimal number – 9 decimal places
N$ Currency – whole marks
N$D0 Currency – whole marks
N$D2 Currency – marks and pfennig
N$DM Currency – whole Deutsch marks
N$DM0 Currency – whole Deutsch marks
N$DM2 Currency – Deutsch marks and pfennig
N$EU Currency – whole Euros
N$D0EU Currency – whole Euros
N$D2EU Currency – Euros and cents
C Characters – spoken individually, medial inflection
44 Specialized applications December 2008 Enhanced basic speech formats
Format Description
Crmf Characters – spoken individually, total inflection
Crmm Characters – spoken individually, rising inflection
Cmmf Characters – spoken individually, falling inflection
Cmmm Characters – spoken individually, medial inflection
NX The NX format is used to speak a phrase with a specified phrase tag number, or packed talkfile numbers and phrase numbers.
Greek EBS formats
Format Description
N Number - male, normal intonation
NMm Number - same as N, male, normal intonation
NMf Number - male, falling intonation
NFm Number - female, normal intonation
NFf Number - female, falling intonation
NNm Number - neutral, normal intonation
NNf Number - neutral, falling intonation
D Date - day, spoken month and 4 digit year
DDMSPYY Date - same as D, day, spoken month and 4 digit year
DDMYY Date - day, month and 4 digit year
DMMSP Date - day, month spoken, no year
DDM Date - day, month, no year
DDMSPYYf Date - day, spoken month and 4 digit falling year
DDMYYf Date - day, month and 4 digit year, falling form
Specialized applications December 2008 45 Speech applications
Format Description
DMMSPf Date - day, month spoken, no year, falling form
DDMf Date - day, month, no year, falling form
T Time - hours and minutes
TH24M Time - same as T, hours and minutes
TH24MS Time - hours, minutes and seconds
TH24Mf Time - hours and falling minutes
TH24MSf Time - hours, minutes and falling seconds
N$ Currency – whole drachmas
N$D0 Currency – same as N$, whole drachmas
N$D0f Currency – whole drachmas, falling
N$EU Currency – whole Euro
N$D0EU Currency – same as N$EU, whole Euro
N$D2EU Currency – Euro and cents
N$DXEU Currency – Euro as decimal number with variable decimal places
N$D0fEU Currency – whole Euro, falling
N$D2fEU Currency – Euro and cents, falling
N$DxfEU Currency - Euro-falling as decimal number with variable decimal places
ND0 Decimal number – no decimal places, spoken as "number comma 0"
ND1 Decimal number – 1 decimal place
ND2 Decimal number – 2 decimal places
ND3 Decimal number – 3 decimal places
ND4 Decimal number – 4 decimal places
ND5 Decimal number – 5 decimal places
ND6 Decimal number – 6 decimal places
46 Specialized applications December 2008 Enhanced basic speech formats
Format Description
ND7 Decimal number – 7 decimal places
ND8 Decimal number – 8 decimal places
ND9 Decimal number – 9 decimal places
NDX Decimal number – variable number of decimal places, separator provided in argument
ND0f Decimal number – no decimal places, spoken as "number comma 0", falling
ND1f Decimal number – 1 decimal place, falling
ND2f Decimal number – 2 decimal places, falling
ND3f Decimal number – 3 decimal places, falling
ND4f Decimal number – 4 decimal places, falling
ND5f Decimal number – 5 decimal places, falling
ND6f Decimal number – 6 decimal places, falling
ND7f Decimal number – 7 decimal places, falling
ND8f Decimal number – 8 decimal places, falling
ND9f Decimal number – 9 decimal places, falling
NDXf Decimal number – variable number of decimal places, falling, separator provided in argument
C Characters - spoken individually, no inflection
Cspd Characters - spoken individually, with variable pace
Cmf Characters - spoken individually, falling inflection
Specialized applications December 2008 47 Speech applications
Format Description
Cmm Characters – same as C, characters spoken individually, no inflection
NX The NX format is used to speak a phrase with a specified phrase tag number, or packed talkfile numbers and phrase numbers.
Hebrew EBS formats
Format Description
N Number - spoken using feminine number set
NF Number - same as N, numbers spoken using feminine number set
NM Number - spoken using masculine number set
D Date - day and month name spoken, followed by year spoken out in full
DMSPDYY Date - same as D, day and month name spoken, followed by year spoken out in full
DMSPDY Date - day and month name spoken, followed by last 2 digits of year spoken out
DMSPD Date - day and month name spoken
DMDYY Date - date spoken as day number, month number and full year spoken out
DMDY Date - date spoken as day number, month number and last 2 digits of year spoken out
DMD Date - date spoken as day number followed by month number
T Time - speaks time using the hour, minute and the time period of the day (using 6 different phrases based on time of day)
48 Specialized applications December 2008 Enhanced basic speech formats
Format Description
THMAM Time - same as T
N$ Currency – whole dollars
N$D0 Currency – whole dollars
N$D1 Currency - dollars with 1 decimal place
N$D2 Currency – dollars and cents
N$D3 Currency - dollars with 3 decimal places
N$D4 Currency - dollars with 4 decimal places
N$D5 Currency - dollars with 5 decimal places
N$D6 Currency - dollars with 6 decimal places
N$D7 Currency - dollars with 7 decimal places
N$D8 Currency - dollars with 8 decimal places
N$D9 Currency - dollars with 9 decimal places
NS Currency – whole shekels
NSD0 Currency – whole shekels
NSD1 Currency - shekels with 1 decimal place
NSD2 Currency – shekels and agoroth
NSD3 Currency - shekels with 3 decimal places
NSD4 Currency - shekels with 4 decimal places
NSD5 Currency - shekels with 5 decimal places
NSD6 Currency - shekels with 6 decimal places
NSD7 Currency - shekels with 7 decimal places
NSD8 Currency - shekels with 8 decimal places
NSD9 Currency - shekels with 9 decimal places
NE Currency – whole euros
Specialized applications December 2008 49 Speech applications
Format Description
NED0 Currency – whole euros
NED1 Currency - euros with 1 decimal place
NED2 Currency – euros and cents
NED3 Currency - euros with 3 decimal places
NED4 Currency - euros with 4 decimal places
NED5 Currency - euros with 5 decimal places
NED6 Currency - euros with 6 decimal places
NED7 Currency - euros with 7 decimal places
NED8 Currency - euros with 8 decimal places
NED9 Currency - euros with 9 decimal places
ND0 Decimal number – no decimal places
ND1 Decimal number – 1 decimal place
ND2 Decimal number – 2 decimal places
ND3 Decimal number – 3 decimal places
ND4 Decimal number – 4 decimal places
ND5 Decimal number – 5 decimal places
ND6 Decimal number – 6 decimal places
ND7 Decimal number – 7 decimal places
ND8 Decimal number – 8 decimal places
ND9 Decimal number – 9 decimal places
C Default format for characters, speak characters with medial inflection
NX The NX format is used to speak a phrase with a specified phrase tag number, or packed talkfile numbers and phrase numbers.
50 Specialized applications December 2008 Enhanced basic speech formats
Hindi EBS formats
Format Description
D Date – same as DDMSPYY
DDMSP Date – 2-digit day, spoken month
DDMSPY Date – 2-digit day, spoken month, 4-digit year
T Time – time period followed by time
THMAM Time – time period followed by time
N Number – integer, medial inflection (default)
ND0 Decimal number – no decimal place
ND1 Decimal number – 1 decimal place
ND2 Decimal number – 2 decimal places
ND3 Decimal number – 3 decimal places
ND4 Decimal number – 4 decimal places
ND5 Decimal number – 5 decimal places
ND6 Decimal number – 6 decimal places
ND7 Decimal number – 7 decimal places
ND8 Decimal number – 8 decimal places
ND9 Decimal number – 9 decimal places
N$ Currency – dollars and cents
N$D0 Currency – whole dollars
N$D1 Currency – dollars with 1 decimal place
N$D2 Currency – dollars and cents
N$D3 Currency – dollars with 3 decimal places
N$D4 Currency – dollars with 4 digits decimal places
N$D5 Currency – dollars with 5 digits decimal places
N$D6 Currency – dollars with 6 digits decimal places
N$D7 Currency – dollars with 7 digits decimal places
Specialized applications December 2008 51 Speech applications
Format Description
N$D8 Currency – dollars with 8 decimal places
N$D9 Currency – dollars with 9 with decimal places
NRD0 Currency – whole rupees
NRD1 Currency – rupees with 1 decimal place
NRD2 Currency – rupees with 2 decimal places
NRD3 Currency – rupees with 3 decimal places
NDR4 Currency – rupees with 4 decimal places
NDR5 Currency – rupees with 5 decimal places
NDR6 Currency – rupees with 6 decimal places
NDR7 Currency – rupees with 7 decimal places
NDR8 Currency – rupees with 8 decimal places
NDR9 Currency – rupees with 9 decimal places
C Characters – spoken individually, medial inflection
Cmmm Characters – spoken individually, medial inflection
NX The NX format is used to speak a phrase with a specified phrase tag number, or packed talkfile numbers and phrase numbers.
Hungarian EBS formats
Format Description
D Date – 4-digit year, spoken month and day
YYMSPDD Date – 4-digit year, spoken month and day
MSPDD Date – no year, spoken month and day
YYMSPDDf Date – 4-digit year, spoken month and day, falling inflection
MSPDDf Date – no year, spoken month and day, falling inflection
T Time – hour, minute, 24-hour clock
52 Specialized applications December 2008 Enhanced basic speech formats
Format Description
TH24M Time – hour, minute, 24-hour clock
TH24MS Time – hour, minute, second, 24-hour clock
TH24Mf Time – hour, minute, 24-hour clock, falling inflection
TH24MSf Time – hour, minute, second, 24-hour clock, falling inflection
N Number – alternate NMm format, medial inflection
NMm Number – medial inflection
NMf Number – falling inflection
NM2m Number – alternate NMm format, medial inflection
NM2f Number – alternate NMf format, falling inflection
ND0 Decimal number – whole number spoken as "number comma 0", no decimal places
ND1 Decimal number – 1 decimal place
ND2 Decimal number – 2 decimal places
ND3 Decimal number – 3 decimal places
ND4 Decimal number – 4 decimal places
ND5 Decimal number – 5 decimal places
ND6 Decimal number – 6 decimal places
ND7 Decimal number – 7 decimal places
ND8 Decimal number – 8 decimal places
ND9 Decimal number – 9 decimal places
NDX Decimal number – variable number of decimal places, decimal separator in argument Note: A number passed to a function can contain either a period (.) or a comma (,) to identify a number of decimal digits spoken for that number.
NDX1 Decimal number – 1 decimal place, spoken as a fraction
NDX2 Decimal number – 2 decimal places, spoken as a fraction
Specialized applications December 2008 53 Speech applications
Format Description
NDX3 Decimal number – 3 decimal places, spoken as a fraction
NDX0S Decimal number – 3 or fewer decimal places, spoken as a whole number with padding zeros
NDXS Decimal number – 3 or fewer decimal places, spoken as a fraction; otherwise NDX
ND0f Number – whole number, spoken as "number comma 0", falling inflection
ND1f Decimal number – 1 decimal place, falling inflection
ND2f Decimal number – 2 decimal places, falling inflection
ND3f Decimal number – 3 decimal places, falling inflection
ND4f Decimal number – 4 decimal places, falling inflection
ND5f Decimal number – 5 decimal places, falling inflection
ND6f Decimal number – 6 decimal places, falling inflection
ND7f Decimal number – 7 decimal places, falling inflection
ND8f Decimal number – 8 decimal places, falling inflection
ND9f Decimal number – 9 decimal places, falling inflection
NDXf Decimal number – variable number of decimal places, spoken as a whole number with padding zeros, falling inflection
NDX1f Decimal number – 1 decimal place, spoken as a fraction, falling inflection
NDX2f Decimal number – 2 decimal places, spoken as a fraction, falling inflection
NDX3f Decimal number – 3 decimal places, spoken as a fraction, falling inflection
54 Specialized applications December 2008 Enhanced basic speech formats
Format Description
NDXSf Decimal number – 3 or fewer decimal places, spoken as a fraction, falling inflection; otherwise NDX
NDX0Sf Decimal number – 3 or fewer decimal places, spoken as a fraction, falling inflection; otherwise NDX
N$ Currency – whole forints
N$D0 Currency – whole forints
N$D2 Currency – forints and filers
N$DX Currency – forints as a decimal number, variable number of decimal places
C Characters – spoken individually, medial inflection
Cspd Characters – spoken individually, variable pace
Cmf Characters – spoken individually, falling inflection
Cmm Characters – spoken individually, medial inflection
NX The NX format is used to speak a phrase with a specified phrase tag number, or packed talkfile numbers and phrase numbers.
Indonesian EBS formats
Format Description
N Number – integer, medial inflection (default)
ND0 Decimal number – no decimal place
ND1 Decimal number – 1 decimal place
ND2 Decimal number – 2 decimal places, numbers after decimal point spoken digit-by-digit
ND2W Decimal number – 2 digits after decimal point spoken as number
ND3 Decimal number – 3 decimal places
ND4 Decimal number – 4 decimal places
Specialized applications December 2008 55 Speech applications
Format Description
ND5 Decimal number – 5 decimal places
ND6 Decimal number – 6 decimal places
ND7 Decimal number – 7 decimal places
ND8 Decimal number – 8 decimal places
ND9 Decimal number – 9 decimal places
D Date – spoken month, 2-digit day, 4-digit year
DMSPDYY Date – spoken month, 2-digit day, 4-digit year
T Time – hour, minute, AM/PM
THMAM Time – hour, minute, AM/PM
TH24M Time – hour, minute, 24 hour clocks
N$ Currency – whole Indonesian rupiah
N$R Currency – whole Indonesian rupiah
N$D0 Currency – whole US dollars
N$D2 Currency – US dollars and cents
C Characters – Indonesian, spoken individually, medial inflection
Cm Characters – English, spoken individually, medial inflection
Cf Characters – English, spoken individually, falling inflection
Cr Characters – English, spoken individually, rising inflection
CIm Characters – Indonesian, spoken individually, medial inflection
CIf Characters – Indonesian, spoken individually, falling inflection
CIr Characters – Indonesian, spoken individually, rising inflection
NX The NX format is used to speak a phrase with a specified phrase tag number, or packed talkfile numbers and phrase numbers.
56 Specialized applications December 2008 Enhanced basic speech formats
Italian EBS formats
Format Description
D Date – same as DDMSPYY but with falling inflection
DDMSPYY Date – day, spoken month, 4-digit year
DDMSPY Date – day, spoken month, 2-digit year
DDMSP Date – spoken month, 2-digit day, no year
DDMSPYYf Date – same as DDMSPYY but with falling inflection
DDMSPYf Date – same as DDMSPY but with falling inflection
DDMSPf Date – same as DDMSP but with falling inflection
T Time – hour, minute, 24-hour clock, falling inflection
THMAM Time – hour, minute, AM/PM
TH24M Time – hour, minute, 24-hour clock
THMAMf Time – hour, minute, AM/PM, falling inflection
TH24Mf Time – hour, minute, 24-hour clock, falling inflection
N Number – rising inflection
Nmf Number – falling inflection
Nrm Number – rising inflection
Nrmf Number – total inflection
NN Number – "uno"
NF Number – "una"
NM Number – "un"
ND0 Decimal number – no decimal places
ND1 Decimal number – 1 decimal place
ND2 Decimal number – 2 decimal places
ND3 Decimal number – 3 decimal places
Specialized applications December 2008 57 Speech applications
Format Description
ND4 Decimal number – 4 decimal places
ND5 Decimal number – 5 decimal places
ND6 Decimal number – 6 decimal places
ND7 Decimal number – 7 decimal places
ND8 Decimal number – 8 decimal places
ND9 Decimal number – 9 decimal places
N$ Currency – lire, medial inflection (default)
N$f Currency – lire, falling inflection
N$EU Currency – Euros and cents, medial inflection
N$fEU Currency – Euros and cents, falling inflection
C Characters – spoken individually, medial inflection
Crmf Characters – spoken individually, total inflection
Crmm Characters – spoken individually, rising inflection
Cmmf Characters – spoken individually, falling inflection
Cmmm Characters – spoken individually, medial inflection
NX The NX format is used to speak a phrase with a specified phrase tag number, or packed talkfile numbers and phrase numbers.
Japanese EBS formats
Format Description
D Date – spoken 4-digit year, month, and day
DSPYYMD Date – spoken 4-digit year, month, and day
DSPYYMDW Date – spoken 4-digit year, month, day, and day of the week
DSPYMD Date – last 2 digits of year spoken, month, and day
DSPYMDW Date – last 2 digits of year spoken, month, day, and day of the week
58 Specialized applications December 2008 Enhanced basic speech formats
Format Description
DSPMD Date – spoken month and day
DSPMDW Date – spoken month, day, and day of the week
T Time – hour, minute, AM/PM
THMAM Time – hour, minute, AM/PM
N Number – integer, total inflection (default)
ND0 Decimal number – no decimal places
ND1 Decimal number – 1 decimal place
ND2 Decimal number – 2 decimal places
ND3 Decimal number – 3 decimal places
ND4 Decimal number – 4 decimal places
ND5 Decimal number – 5 decimal places
ND6 Decimal number – 6 decimal places
ND7 Decimal number – 7 decimal places
ND8 Decimal number – 8 decimal places
ND9 Decimal number – 9 decimal places
N$ Currency – whole yen (default)
N$D2 Currency – yen, 2 decimal places
C Characters – spoken individually, medial inflection
NX The NX format is used to speak a phrase with a specified phrase tag number, or packed talkfile numbers and phrase numbers.
Korean EBS formats
Format Description
D Date – 4-digit year, month, day
DYYMD Date – 4-digit year, month, day
DMD Date – month followed by day
Specialized applications December 2008 59 Speech applications
Format Description
T Time – time period followed by time
TAMHM Time – time period followed by time
N Number – integer, cardinal number (default)
NT Number – ordinal
ND0 Decimal number – no decimal places
ND1 Decimal number – 1 decimal place
ND2 Decimal number – 2 decimal places
ND3 Decimal number – 3 decimal places
ND4 Decimal number – 4 decimal places
ND5 Decimal number – 5 decimal places
ND6 Decimal number – 6 decimal places
ND7 Decimal number – 7 decimal places
ND8 Decimal number – 8 decimal places
ND9 Decimal number – 9 decimal places
N$ Currency – whole dollars
N$D0 Currency – whole dollars
N$D2 Currency – dollars and cents
N$D1 Currency – dollars with 1 decimal place
N$D3 Currency – dollars with 3 decimal places
N$D4 Currency – dollars with 4 decimal places
N$D5 Currency – dollars with 5 decimal places
N$D6 Currency – dollars with 6 decimal places
N$D7 Currency – dollars with 7 decimal places
N$D8 Currency – dollars with 8 decimal places
N$D9 Currency – dollars with 9 decimal places
NW Currency – whole won
C Characters – spoken individually, medial inflection
Cmmm Characters – spoken individually, medial inflection
60 Specialized applications December 2008 Enhanced basic speech formats
Format Description
NX The NX format is used to speak a phrase with a specified phrase tag number, or packed talkfile numbers and phrase numbers.
Latin-American Spanish EBS formats
Format Description
D Date – spoken month, 2-digit day, 4-digit year
DMSPDYY Date – spoken month, 2-digit day, 4-digit year
DMSPDY Date – spoken month, 2-digit day, 2-digit year
DMSPD Date – spoken month, 2-digit day
T Time – hour, minute, AM/PM
THMAM Time – hour, minute, AM/PM
TH24M Time --hour, minute, 24-hour clock
N Number – neutral form
NM Number – male form
NF Number – female form
NN Number – neutral form
ND0 Decimal number – no decimal places
ND1 Decimal number – 1 decimal place
ND2 Decimal number – 2 decimal places
ND3 Decimal number – 3 decimal places
ND4 Decimal number – 4 decimal places
ND5 Decimal number – 5 decimal places
ND6 Decimal number – 6 decimal places
ND7 Decimal number – 7 decimal places
ND8 Decimal number – 8 decimal places
ND9 Decimal number – 9 decimal places
Specialized applications December 2008 61 Speech applications
Format Description
C Character – spoken individually (default)
N$ Currency – whole pesos
N$D0 Currency – whole pesos
N$D2 Currency – pesos and centavos
NDOL$ Currency – whole dollars
NDOL$D0 Currency – whole dollars
NDOL$D2 Currency – dollars and centavos
NPN$ Currency – whole pesos nuevos
NPN$D0 Currency – whole pesos nuevos
NPN$D2 Currency – pesos nuevos and centavos
NCOL$ Currency – whole colones
NCOL$D0 Currency – whole colones
NCOL$D2 Currency – colones and centavos
NSUC$ Currency – whole sucres
NSUC$D0 Currency – whole sucres
NSUC$D2 Currency – sucres and centavos
NQUE$ Currency – whole quetzales
NQUE$D0 Currency – whole quetzales
NQUE$D2 Currency – quetzales and centavos
NLEM$ Currency – whole lempiras
NLEM$D0 Currency – whole lempiras
NLEM$D2 Currency – lempiras and centavos
NCOR$ Currency – whole cordobas
NCOR$D0 Currency – whole cordobas
NCOR$D2 Currency – cordobas and centavos
NGUA$ Currency – whole guaranis
NGUA$D0 Currency – whole guaranis
NGUA$D2 Currency – guaranis and centimos
62 Specialized applications December 2008 Enhanced basic speech formats
Format Description
NSOL$ Currency – whole soles
NSOL$D0 Currency – whole soles
NSOL$D2 Currency – soles and centavos
NBOL$ Currency – whole bolivares
NBOL$D0 Currency – whole bolivares
NBOL$D2 Currency – bolivares and centimos
NPTA$ Currency – whole pesetas
NPTA$D0 Currency – whole pesetas
NPTA$D2 Currency – pesetas and centimos
NX The NX format is used to speak a phrase with a specified phrase tag number, or packed talkfile numbers and phrase numbers.
Malay EBS formats
Format Description
D Date – spoken month, 2-digit day, 4-digit year
DMSPDYY Date – spoken month, 2-digit day, 4-digit year
T Time – hour, minute, AM/PM
THMAM Time – hour, minute, AM/PM
TH24M Time – hour, minute, 24-hour clock
N Number – integer (default)
ND0 Decimal number – no decimal places
ND1 Decimal number – 1 decimal place
ND2 Decimal number – 2 decimal places
ND2W Decimal number – 2 digits after decimal point spoken as number
ND3 Decimal number – 3 decimal places
ND4 Decimal number – 4 decimal places
Specialized applications December 2008 63 Speech applications
Format Description
ND5 Decimal number – 5 decimal places
ND6 Decimal number – 6 decimal places
ND7 Decimal number – 7 decimal places
ND8 Decimal number – 8 decimal places
ND9 Decimal number – 9 decimal places
N$ Currency – whole Malaysian ringgits
N$R Currency – whole Malaysian ringgits
N$R2 Currency – Malaysian ringgits and cents
N$D0 Currency – whole US dollars
N$D2 Currency – US dollars and cents
C Characters – English, spoken individually, medial inflection
Cm Characters – English, spoken individually, medial inflection
Cf Characters – English, spoken individually, falling inflection
Cr Characters – English, spoken individually, rising inflection
CIm Characters – English, spoken individually, medial inflection
NX The NX format is used to speak a phrase with a specified phrase tag number, or packed talkfile numbers and phrase numbers.
Mandarin Chinese EBS formats
Format Description
D Date – 4-digit year, month and day
DYYMD Date – 4-digit year, month and day
DMD Date – month followed by day
64 Specialized applications December 2008 Enhanced basic speech formats
Format Description
DTWYYMD Date – 4-digit year per Taiwanese Republic calendar, month, day
T Time – hour, minute, 24-hour clock
THMAM Time – hour, minute, 24-hour clock
N Number – integer, with digit 2 spoken as "ur" (default)
N2 Number – integer, with digit 2 spoken as "lyang"
ND0 Decimal number – no decimal places
ND1 Decimal number – 1 decimal place
ND2 Decimal number – 2 decimal places
ND3 Decimal number – 3 decimal places
ND4 Decimal number – 4 decimal places
ND5 Decimal number – 5 decimal places
ND6 Decimal number – 6 decimal places
ND7 Decimal number – 7 decimal places
ND8 Decimal number – 8 decimal places
ND9 Decimal number – 9 decimal places
N$ Currency – whole yuan
N$D0 Currency – whole dollars
N$D1 Currency – dollars with 1 decimal place
N$D2 Currency – dollars and cents
N$D3 Currency – dollars with 3 decimal places
N$D4 Currency – dollars with 4 decimal places
N$D5 Currency – dollars with 5 decimal places
N$D6 Currency – dollars with 6 decimal places
N$D7 Currency – dollars with 7 decimal places
N$D8 Currency – dollars with 8 decimal places
N$D9 Currency – dollars with 9 decimal places
NYD0 Currency – whole yuan
Specialized applications December 2008 65 Speech applications
Format Description
NYD1 Currency – yuan with 1 decimal place
NYD2 Currency – yuan, chiao, and fun
NYD3 Currency – yuan with 3 decimal places
NYD4 Currency – yuan with 4 decimal places
NYD5 Currency – yuan with 5 decimal places
NYD6 Currency – yuan with 6 decimal places
NYD7 Currency – yuan with 7 decimal places
NYD8 Currency – yuan with 8 decimal places
NYD9 Currency – yuan with 9 decimal places
NQD0 Currency – whole quai
NQD1 Currency – quai with 1 decimal place
NQD2 Currency – quai with 2 decimal places
NQD3 Currency – quai with 3 decimal places
NQD4 Currency – quai with 4 decimal places
NQD5 Currency – quai with 5 decimal places
NQD6 Currency – quai with 6 decimal places
NQD7 Currency – quai with 7 decimal places
NQD8 Currency – quai with 8 decimal places
NQD9 Currency – quai with 9 decimal places
C Characters – spoken individually
Cmmm Characters – spoken individually
NX The NX format is used to speak a phrase with a specified phrase tag number, or packed talkfile numbers and phrase numbers.
66 Specialized applications December 2008 Enhanced basic speech formats
Polish EBS formats
Format Description
D Date – day, spoken month, 4-digit year
DDMSPYY Date – day, spoken month, 4-digit year
DMMSP Date – day, spoken month, no year
DDMSPYYf Date – day, spoken month, 4-digit year, falling inflection
DMMSPf Date – day and month, no year, falling inflection
T Time – hour and minute as numbers, 24-hour clock
TH24M Time – hour and minute as numbers, 24-hour clock
TSPH24M Time – spoken hour and minute, 24-hour clock
TSPH24MS Time – spoken hour, minute, and second, 24- hour clock
TOH24M Time – hour and minute in form "at time"
TH24Mf Time – hour and minute as numbers, falling inflection
TSPH24Mf Time – spoken hour and minute, falling inflection
TSPH24MSf Time – spoken hour, minute, and second, falling inflection
TOH24Mf Time – hour and minute in form "at time," falling inflection
N Number – up to 1 billion, male form, medial inflection
NMm Number – up to 1 billion, male form, medial inflection
NMf Number – up to 1 billion, male form, falling inflection
NFm Number – up to 1 billion, female form, medial inflection
NFf Number – up to 1 billion, female form, falling inflection
Specialized applications December 2008 67 Speech applications
Format Description
NNm Number – up to 1 billion, neutral form, medial inflection
NNf Number – up to 1 billion, neutral form, falling inflection
ND0 Decimal number – whole number spoken as "number comma 0"
ND1 Decimal number – 1 decimal place
ND2 Decimal number – 2 decimal places
ND3 Decimal number – 3 decimal places
ND4 Decimal number – 4 decimal places
ND5 Decimal number – 5 decimal places
ND6 Decimal number – 6 decimal places
ND7 Decimal number – 7 decimal places
ND8 Decimal number – 8 decimal places
ND9 Decimal number – 9 decimal places
NDX1 Decimal number – 1 decimal place, spoken as a fraction
NDX2 Decimal number – 2 decimal places, spoken as a fraction
NDX3 Decimal number – 3 decimal places, spoken as a fraction
NDX Decimal number – variable number of decimal places, decimal separator in argument Note: A number passed to a function can contain either a period (.) or a comma (,) to identify a number of decimal digits spoken for that number.
NDX0S Decimal number – 3 or fewer decimal places, spoken as a number with leading zeros; otherwise NDX
NDXS Decimal number – 3 or fewer decimal places, spoken as a fraction; otherwise NDX
ND0f Decimal number – whole number spoken as "number comma 0", falling inflection
ND1f Decimal number – 1 decimal place, falling inflection
68 Specialized applications December 2008 Enhanced basic speech formats
Format Description
ND2f Decimal number --- 2 decimal places, falling inflection
ND3f Decimal number – 3 decimal places, falling inflection
ND4f Decimal number – 4 decimal places, falling inflection
ND5f Decimal number – 5 decimal places, falling inflection
ND6f Decimal number – 6 decimal places, falling inflection
ND7f Decimal number – 7 decimal places, falling inflection
ND8f Decimal number – 8 decimal places, falling inflection
ND9f Decimal number – 9 decimal places, falling inflection
NDX1f Decimal number – 1 decimal place, spoken as a fraction, falling inflection
NDX2f Decimal number – 2 decimal places, spoken as a fraction, falling inflection
NDX3f Number – 3 decimal places, spoken as a fraction, falling inflection
NDXf Decimal number – variable number of decimal places, falling inflection, decimal separator in argument Note: A number passed to a function can contain either a period (.) or a comma (,) to identify a number of decimal digits spoken for that number)
NDX0Sf Decimal number – 3 or fewer decimal places, spoken as number with leading zeros; otherwise NDX
NDXSf Decimal number – 3 or fewer decimal places, spoken as a fraction, falling inflection; otherwise NDX
N$ Currency – zlote and grosze, up to 1 billion, falling inflection
N$D0 Currency – whole zlote, up to 1 billion, medial inflection)
Specialized applications December 2008 69 Speech applications
Format Description
N$D2 Currency – zlote and grosze, up to 1 billion, medial inflection
N$D2f Currency – zlote and grosze, up to 1 billion, falling inflection
N$DX Currency – zlote, up to 1 billion, decimal form
N$EU Currency – Euros and cents, up to 1 billion, falling inflection
N$D0EU Currency – Euros, up to 1 billion, medial inflection
N$D2EU Currency – Euros and cents, up to 1 billion, medial inflection
N$D2fEU Currency – Euros and cents, up to 1 billion, falling inflection
N$DXEU Currency – Euros, up to 1 billion, decimal form
C Characters – spoken individually, falling inflection
Cspd Characters – spoken individually, variable pace, medial inflection
Cmf Characters – spoken individually, falling inflection
Cmm Characters – spoken individually, medial inflection
NX The NX format is used to speak a phrase with a specified phrase tag number, or packed talkfile numbers and phrase numbers.
Slovak EBS formats
Format Description
D Date – day, spoken month, 4-digit year
DDMSPYY Date – day, spoken month, 4-digit year
DDMYY Date – day, month, 4-digit year
DMMSP Date – day, spoken month, no year
DDM Date – day, month, no year
70 Specialized applications December 2008 Enhanced basic speech formats
Format Description
DDMSPYYf Date – day, spoken month, 4-digit year, falling inflection
DDMYYf Date – day, month, 4-digit year, falling inflection
DMMSPf Date – day, spoken month, falling inflection
DDMf Date – day, month, falling inflection
T Time – hour, minute, 24-hour clock
TH24M Time – hour, minute, 24-hour clock
TH24MS Time – hour, minute, second, 24-hour clock
TH24Mf Time – hour, minute, falling inflection
TH24MSf Time – hour, minute, second, falling inflection
N Number – male form, medial inflection
NMm Number – male form, medial inflection
NMLm Number – male form, for animate subjects, medial inflection
NMf Number – male form, falling inflection
NMLf Number – male form, for animate subjects, falling inflection
NFm Number – female form, medial inflection
NFf Number – female form, falling inflection
NNm Number – neutral form, medial inflection
NNf Number – neutral form, falling inflection
ND0 Decimal number – whole number spoken as "number comma 0"
ND1 Decimal number – 1 decimal place
ND2 Decimal number – 2 decimal places
ND3 Decimal number – 3 decimal places
ND4 Decimal number – 4 decimal places
ND5 Decimal number – 5 decimal places
ND6 Decimal number – 6 decimal places
ND7 Decimal number – 7 decimal places
Specialized applications December 2008 71 Speech applications
Format Description
ND8 Decimal number – 8 decimal place
ND9 Decimal number – 9 decimal place
NDX1 Decimal number-- 1 decimal place, spoken as a fraction
NDX2 Decimal number – 2 decimal places, spoken as a fraction
NDX3 Decimal number – 3 decimal places, spoken as a fraction
NDX Decimal number – variable number of decimal places, decimal separator in argument Note: A number passed to a function can contain either a period (.) or a comma (,) to identify a number of decimal digits spoken for that number.
NDXS Decimal number – 3 or fewer decimal places spoken as fraction, falling inflection; otherwise NDX
ND0f Decimal number – whole number spoken as "number comma 0", falling inflection
ND1f Decimal number – 1 decimal place, falling inflection
ND2f Decimal number – 2 decimal places, falling inflection
ND3f Decimal number – 3 decimal places, falling inflection
ND4f Decimal number – 4 decimal places, falling inflection
ND5f Decimal number – 5 decimal places, falling inflection
ND6f Decimal number – 6 decimal places, falling inflection
ND7f Decimal number – 7 decimal places, falling inflection
ND8f Decimal number – 8 decimal places, falling inflection
ND9f Decimal number – 9 decimal places, falling inflection
72 Specialized applications December 2008 Enhanced basic speech formats
Format Description
NDX1f Decimal number – 1 decimal place, spoken as a fraction, falling inflection
NDX2f Decimal number – 2 decimal places, spoken as a fraction, falling inflection
NDX3f Decimal number – 3 decimal places, spoken as a fraction, falling inflection
NDXf Decimal number – variable number of decimal places, falling inflection, decimal separator in argument Note: A number passed to a function can contain either a period (.) or a comma (,) to identify a number of decimal digits spoken for that number.
NDXSf Decimal number – 3 or fewer decimal places, spoken as a fraction, falling inflection; otherwise NDX
N$ Currency – whole crowns
N$D0 Currency – whole crowns
N$D2 Currency – crowns and hellers
N$DX Currency – crowns spoken as a decimal number, variable number of decimal places
N$EU Currency – whole Euros
N$D0EU Currency – whole Euros
N$D2EU Currency – Euros and cents
N$DXEU Currency – Euros as decimal number with a variable number of decimal places
C Characters – spoken individually, medial inflection
Cmf Characters – spoken individually, falling inflection
Cmm Characters – spoken individually, medial inflection
NX The NX format is used to speak a phrase with a specified phrase tag number, or packed talkfile numbers and phrase numbers.
Specialized applications December 2008 73 Speech applications
Thai EBS formats
Format Description
D Date – Buddha year, spoken as a whole number
DWY Date – Western year, spoken as a whole number
DWYD Date – Western year, spoken digit by digit
DWYS Date – Western year, spoken in short form
DBY Date – Buddha year, spoken as a whole number
DBYD Date – Buddha year, spoken digit by digit
DBYS Date – Buddha year, spoken in short form
T Time – hour, minute, AM/PM
THMAM Time – hour, minute, AM/PM
TH24M Time – hour, minute, 24-hour clock
N Number – integer (default)
ND0 Decimal number – no decimal places
ND1 Decimal number – 1 decimal place
ND2 Decimal number – 2 decimal places
ND3 Decimal number – 3 decimal places
ND4 Decimal number – 4 decimal places
ND5 Decimal number – 5 decimal places
ND6 Decimal number – 6 decimal places
ND7 Decimal number – 7 decimal places
ND8 Decimal number – 8 decimal places
ND9 Decimal number – 9 decimal places
N$ Currency – whole Thai baht
N$T0 Currency – whole Thai baht
N$T2 Currency – Thai baht and satang
N$D0 Currency – whole US dollars
74 Specialized applications December 2008 Enhanced basic speech formats
Format Description
N$D2 Currency – US dollars and cents
C Characters – English, spoken individually, medial inflection
Cm Characters – English, spoken individually, medial inflection
Cf Characters – English, spoken individually, falling inflection
Cr Characters – English, spoken individually, rising inflection
NX The NX format is used to speak a phrase with a specified phrase tag number, or packed talkfile numbers and phrase numbers.
UK English EBS format
Format Description
D Date – day, month, 4-digit year
DDMSP Date – day and month
DDMSPY Date – day, month, 2-digit year
DDMSPYY Date – day, month, 4-digit year
DDMSPf Date – day and month, falling inflection
DDMSPYf Date – day, month, 2-digit year, falling inflection
DDMSPYYf Date – day, month, 4-digit year, falling inflection
DDMSPO Date – "on" day, month
DDMSPYO Date – "on" day, month, 2-digit year
DDMSPYYO Date – "on" day, month, 4-digit year
DDMSPOf Date – "on" day, month, falling inflection
DDMSPYOf Date – "on" day, month, 2-digit year, falling inflection
DDMSPYYOf Date – "on" day, month, 4-digit year, falling inflection
Specialized applications December 2008 75 Speech applications
Format Description
DMDYY Date – same as DDMSPYY
DMDY Date – same as DDMSPY
DMD Date – same as DDMSP
DMSPDYY Date – same as DDMSPYY
DMSPDY Date – same as DDMSPY
DMSPD Date – same as DDMSP
T Time – hour, minute, 24-hour clock
THMAM Time – hour, minute, AM/PM
THMAMf Time – hour, minute, AM/PM, falling inflection
THM24 Time – hour, minute, 24-hour clock
THM24f Time – hour, minute, 24-hour clock, falling inflection
N Number – integer, rising inflection
Nrmf Number – integer, total inflection
Nrmm Number – integer, rising inflection
Nmmf Number – integer, rising inflection
Nmmm Number – integer, rising inflection
ND Decimal number – no decimal places
ND0 Decimal number – no decimal places
ND1 Decimal number – one decimal place
ND2 Decimal number – two decimal places
ND3 Decimal number – three decimal places
ND4 Decimal number – four decimal places
ND5 Decimal number – five decimal places
ND6 Decimal number – six decimal places
ND7 Decimal number – seven decimal places
ND8 Decimal number – eight decimal places
ND9 Decimal number – nine decimal places
76 Specialized applications December 2008 Enhanced basic speech formats
Format Description
N$ Currency – pounds and pence, medial inflection
N$f Currency – pounds and pence, falling inflection
N$EU Currency – Euros and cents, medial inflection
N$fEU Currency – Euros and cents, falling inflection
N$D0 Currency – pounds
N$D1 Currency – pounds with one decimal place
N$D2 Currency – pounds with two decimal places
N$D3 Currency – pounds with three decimal places
N$D4 Currency – pounds with four decimal places
N$D5 Currency – pounds with five decimal places
N$D6 Currency – pounds with six decimal places
N$D7 Currency – pounds with seven decimal places
N$D8 Currency – pounds with eight decimal places
N$D9 Currency – pounds with nine decimal places
C Characters – spoken individually, medial inflection
Cmmm Characters – spoken individually, medial inflection
Cmmf Characters – spoken individually, falling inflection
Crmf Characters – spoken individually, falling inflection
Crmm Characters – spoken individually, medial inflection
US English EBS formats
Format Description
D Date – spoken month, ordinal day, 2-digit year
DMDY Date – 2-digit month, day, year
DMDYY Date – 2-digit month, day, 4-digit year
DMD Date – 2-digit month, day
Specialized applications December 2008 77 Speech applications
Format Description
DMSPDYY Date – spoken month, ordinal day, 4-digit year
DMSPDY Date – spoken month, ordinal day, 2-digit year
DMSPD Date – spoken month, ordinal day
T Time – hour, minute, AM/PM
THMAM Time – hour, minute, AM/PM
N Number – same as Nmmm
Nrmf Number – total inflection
Nmmf Number – falling inflection
Nrmm Number – rising inflection
Nmmm Number – medial inflection
ND Decimal number – no decimal place
ND0 Decimal number – no decimal place
ND1 Decimal number – 1 decimal place
ND2 Decimal number – 2 decimal places
ND3 Decimal number – 3 decimal places
ND4 Decimal number – 4 decimal places
ND5 Decimal number – 5 decimal places
ND6 Decimal number – 6 decimal places
ND7 Decimal number – 7 decimal places,
ND8 Decimal number – 8 decimal places,
ND9 Decimal number – 9 decimal places,
N$ Currency – whole dollars
N$D0 Currency – whole dollars
N$D1 Currency – dollars with 1 decimal place
N$D2 Currency – dollars "and" cents
N$D3 Currency – dollars with 3 decimal places
N$D4 Currency – dollars with 4 decimal places
N$D5 Currency – dollars with 5 decimal places
78 Specialized applications December 2008 Enhanced basic speech formats
Format Description
N$D6 Currency – dollars with 6 decimal places
N$D7 Currency – dollars with 7 decimal places
N$D8 Currency – dollars with 8 decimal places
N$D9 Currency – dollars with 9 decimal places
C Characters – spoken individually, medial inflection
Crmf Characters – spoken individually, total inflection
Crmm Characters – spoken individually, rising inflection
Cmmf Characters – spoken individually, falling inflection
Cmmm Characters – spoken individually, medial inflection
NX The NX format is used to speak a phrase with a specified phrase tag number, or packed talkfile numbers and phrase numbers.
Developing language implementations and custom formats
Overview of developing language implementations
Developing language implementations involves the following steps: • Defining the directory in which the language implementations reside (for example, / vs/bin/ag/formats/Dutch). • Identifying needed phrases and recording those phrases. • Creating a talkfile and loading the recorded phrases onto the system. • Developing functions (subroutines) in transaction assembler script (TAS) language that use the recorded phrases to speak the desired format. For more information about writing TAS language subroutines, see Using TAS script instructions. • Creating the speech format tables to support the developed script functions and recorded speech. • Applying common conventions to maximize the feasibility of multilingual applications. • Verifying format and consistency of language definition files.
Specialized applications December 2008 79 Speech applications
Defining the language file and directory
Create a directory under /vs/bin/ag/formats with the same name as the language that you want to support. For example, the default language, US_English, is defined in the following directory: / vs/bin/ag/formats/US_English Language names can consist of uppercase or lowercase alphanumeric characters and "." and "_". The name can be up to 14 characters. No spaces are allowed.
Defining the speech tables
The language directory contains four tables that define the speech playback capability, two optional tables that define the text-to-speech (TTS) option, and a collection of TSM script routines that implement the various speech playback and TTS formats. The format_tag file The format_tag file lists the speech formats supported and the phrase tags required for each format. When a speech format is used by an application, all of the speech phrases listed in the format_tag file are added to the application. Phrase tags can be listed directly or a group name can be listed to refer to a collection of phrase tags. Phrase tag groups represent a collection of phrase tags, such as digits with rising inflection, and are defined in the tag_groups file (see tag_groups). Each format is defined as shown in the following example: format (description of format) = {category1 phrase tag1 tag2 category2 "quoted tag" etc} Each format definition must begin on a new line. The description of format argument is a description of the speech playback format. This argument should be less than 60 characters, but sufficient to identify the intended use of the format. The description of the format should be placed in parentheses immediately following the format name. Within the second set of brackets ("{" and "}") you should include the list of phrase tags and phrase tag groups that may be required to speak the format. Separate each phrase tag, phrase tag group, or both with white space, including blanks, tabs, and new lines; commas are not allowed. If you have a phrase tag that consists of multiple words with embedded white space, surround the phrase tag with quotes as shown in the format_tag example. The tag_groups file The tag_groups file lists groups of phrase tags and phrases in each group. Group names can consist of uppercase or lowercase alphanumeric characters and the characters "-," "_," "."
80 Specialized applications December 2008 Enhanced basic speech formats
Group names cannot have embedded white space. Each group is defined as shown in the following example: groupname (description of group) = {tag1 tag2 tag3 "quoted tag" etc} Each group must begin on a new line. The description of group is optional. You can add the groupname to the application before using the formats that might reference that group. Otherwise, the phrasegroup is not visible to you, and it is simply used to specify phrases for the format_tag file. The phrase tags within the second set of brackets are the phrase tags that are included in the phrase group. If you have a phrase tag that consists of multiple words with embedded white space, surround the phrase tag with quotes as shown in the tag_groups example. The format_code file The format_code file lists the supported formats and the code to be generated by the system for each format. Each format code description includes four fields as shown in the following example: format code_for_numeric_args code_for_char_args script_file The format is identical to the format described in the format_tag file. The second field, code_for_numeric_args, contains the script code to be generated when a numeric field is being spoken. The third field, code_for_char_args, contains the code to be generated when a character, date, or time field is being spoken. The last field, script_file, contains the name of the script file containing the subroutines that must be included with the application, if any. If the code generated contains a call of a subroutine, then this field must list the file containing that subroutine. The file name, with no directories, is specified. The system automatically generates the directory name. Only one line per format is allowed, even if the line wraps when displayed, as shown in the following example: N$D2 "L__sp_dolc2 ($field) ""L__csp_dolc2 ($field) "_sp_ dolc2.t Each field is separated by white space. If the code generated contains white space (spaces or tabs), the code must be surrounded by quotes. Parameter substitution occurs as follows: • The string, $field, is replaced with the field name of the data to be spoken. The field name is prepended with the TAS syntax, ch., int., or im., as appropriate for the script instruction. • The string, $format, is replaced by the current format as a string. To accommodate TAS conventions, the format is copied into a temporary variable, and the address of that variable is passed in place of $format. Multiple script instructions can be included in one of the entries by separating them with a semicolon (;). Within the field, a backslash ( \ ) is used as an escape for quotes (or white space). Unused fields can have a "-" (dash) as a placeholder. The last two fields are optional. If a numeric field is to be spoken with a format for which no numeric code is provided, the system generates code to convert the field to ASCII format (an itoa script instruction), and generates the code for character fields. Likewise, if a character field is to be spoken, but only
Specialized applications December 2008 81 Speech applications
numeric code has been provided, the system generates code to convert the numeric code and generates the specified numeric code. The proto.pl file The proto.pl file specifies the enhanced basic speech (EBS) phrase tags and their corresponding phrase numbers. The proto.pl file has the same format as a .pl file. See Phrase list file for EBS for more information about a .pl file. The first field in each line of the proto.pl file is ignored. The first 999 phrase numbers (1-999) are reserved for standard phrases with fixed phrase number assignments. If a standard phrase does not need to be assigned a specific phrase number, then the proto.pl file can show phrase number 0 for the phrase. This causes the system to assign any available phrase number greater than 999 to the phrase and place it in the primary pool for the application. It is an error for a phrase to be listed in the format_tag or tag_group file and not be listed in the proto.pl file. However, phrases can be contained in the proto.pl file that are not currently referenced in the other files.
Defining the TTS tables
Two optional tables define the Text-to-Speech (TTS) capability. TTS can be supported in the same way US English TTS is provided. Specific TTS formats are provided to tell the system to speak field data in the various formats. The formats are named the same as the non-TTS equivalents, but with a letter "A" preceding them.
Note: The TTS formats are only available to the user if the TTS package is loaded on the system. The TTS format files The TTS formats are defined in the following files: • The TTSformat_tfile file is used to define TTS formats that are supported for a particular language. If TTS is not available for a language, this file is not provided. The file has the same format as the format_tag file (see Defining the speech tables), but there are no tags or tag groups listed within the curly brackets. • The TTSformat_cfile file is used to specify the code to be generated for TTS formats for a particular language. It is only provided if TTS is available for the language. The format of the file is the same as the format_code file (see Defining the speech tables).
Phrase list file for EBS
A language implementation normally includes an EBS package with all the necessary prerecorded phrases in a female voice a (male voice is available for US English only). A phrase list (.pl) file defines the phrase names and phrase numbers for all the phrases in the EBS package. The first line of the .pl file must have the language listed at the end in brackets. The
82 Specialized applications December 2008 Enhanced basic speech formats
language name must be the same as used in the language package (the same as the subdirectory name in the /vs/bin/ag/formats directory). An example of the first line of a .pl file is: 225 Standard speech in male voice [US_English] The purpose of identifying the EBS language is to prevent its inadvertent use for the wrong language.
Conventions for Language Implementations
Phrase tags Standard phrases should be labeled using the following conventions: • The colon (:) can be used as the first character of a phrase to indicate that a phrase is a standard phrase. Custom phrases may not start with a colon. • The letters of the alphabet, digits, the minus sign ("-"), and the touchtone symbols ( * )and ( # ), will normally be allocated fixed phrase numbers and have phrase numbers starting with a colon. • Additional numbers and phrase fragments, such as the teens, the tens through 90, hundred, and thousand, as necessary to speak numbers in a natural style for a particular language are also denoted with a colon, and assigned fixed phrase numbers. Some languages may have to augment these with different phrases to allow speaking a number with the appropriate gender, or to include additional phrase fragments such as the numbers through 99. • If a language implementation supports multiple inflections, then the standard phrases would be recorded with a rising and falling inflection, in addition to the medial inflection. The inflection is normally denoted by adding a period ( . ) for falling inflection or a question mark ( ? ) for rising inflection to the end of the phrase tag. For example, for US English, the phrase tag ":100?" refers to the fragment "hundred" spoken with a rising inflection: • Other standard phrases necessary to speak money in the correct currency for a language, to speak dates and times, etc., must be defined. These can start with a colon and can be available in multiple inflections, but this is not required. • All standard phrases must be included in the proto.pl file, whether or not they start with a colon. Format names It is desirable that an application be easily modified to support different languages. This requires that as many of the formats as possible follow a standard naming convention, so the formats will be available in all languages. The current naming convention is based on the US English implementation. Thus, it is desirable that each language support the same formats as US English using the same format name. Examples are THMAM (time: hour, minute, AM/ PM), and DMSPDYY (date: with month spoken as a word -- for example, January -- day, and year as four digits). Currency is denoted with the dollar sign "$" (such as N$D2 -- number spoken as dollars and 2-digit cents). In particular, the most standard way of speaking numbers, characters, dates, currency, and times should be assigned the default format for the language (N, C, D, N$, and T, respectively.)
Specialized applications December 2008 83 Speech applications
Additional formats and names for formats can be specified to support natural spoken data according to each language's grammar. For example, the Spanish formats for numbers referring to a masculine, feminine, or neutral noun are "NM," "NF," and "NN," respectively. If TTS is provided for a language, the TTS formats should be the same as the formats for prerecorded phrases, except that the format is preceded by the letter A (for example, "AN" and "ATHMAM"). Thus non-TTS formats should not start with the letter A. Phrase numbers The proto.pl file is used to define phrase numbers for the standard phrases. The phrase numbers 1-999 are reserved for standard phrases. It is desirable, but not necessary that all standard phrases be allocated specific phrase numbers within this range. The phrases that must be allocated in this range are those that must be allocated a specific number or allocated contiguously for the implementation. Examples are the letters of the alphabet, numbers, months, and ordinal numbers if needed. The implementation will typically compute the phrase numbers for these by adding an offset to a base phrase number of a contiguous set of phrases for the set. In cases where standard phrases are referenced only by their phrase tag, such a "dollars and" for US English, it is not necessary that a fixed phrase number be assigned. These can be assigned phrase number 0, in the proto.pl file. Rules for creating script subroutine source files A language package should include a set of script subroutine source (.t) files, necessary to implement the various formats, as well as the specific files listed previously. The rules for these files are based on the rules for external functions with the following differences: • The files are installed in the same language directory as the language definition files, / vs/bin/ag/formats/language, rather than in the directory for external functions. • The file names should start with an underscore ("_"), and use a .t suffix. • The file names should include a language identifier, such as "CS" for Castilian Spanish ( _CSsp_dol.t). • Labels within the file should be of the following format: L_ fileprefix _ uniquesuffix For example, labels within the above file could include L__CSsp_dol, L__CSsp_dolErr, L__CSsp_dol2, L__CSsp_dol_rtn, etc.
84 Specialized applications December 2008 Chapter 2: ASAI applications
Access to ASAI capabilities is provided through IVR Designer external functions. Subsets of the Notification, Third Party Call Control, and Routing capabilities of ASAI are integrated into these external functions.
Note: The Avaya IR system ASAI feature does not provide access to the Set Value, Value Query, Request Feature, and Third Party Domain Control capabilities of ASAI. The Request Feature capability, however, is used internally by the Avaya IR system ASAI feature to log channels in and out of an ACD split on the DEFINITY G3 switch.
ASAI application types
The capabilities provided by the ASAI feature support three classes of applications: • Voice response applications • Routing applications • Data screen delivery applications These classes of applications can all run simultaneously on a Avaya IR system. This implies that a Avaya IR ASAI system provides coresident voice response and DEFINITY G3 switch- to-host gateway capabilities. A single call, for instance, can first be routed by the Avaya IR system, handled with a voice response application on the Avaya IR system, and then be monitored by the same system as the call is ultimately delivered to a live agent. Furthermore, integration of the voice response and gateway capabilities allows agents to interact with callers based on the data collected in a voice response application through a host screen. The delivery of a data screen to an operator that contains information about the incoming caller is called a screen pop. ASAI voice response applications In voice response applications using the ASAI feature, incoming calls can be routed to the Avaya IR system over telephony channels via an ACD split on the DEFINITY G3 switch. As a call is delivered to the Avaya IR system, it receives ASAI information related to the call through the Ethernet LAN circuit card in the Avaya IR system. ASAI allows it to receive the DNIS and/or ANI information of an incoming call to a telephony line over this D-channel. The DNIS and ANI information can be used to control the voice application used for the call. The ASAI information related to the call is made available to the specific voice application that interacts with the caller. In addition, the call control capabilities of ASAI can be used to transfer
Specialized applications December 2008 85 ASAI applications
the call away from the Avaya IR system if the caller needs to speak to a live agent. The ASAI feature provides the following for voice response applications: • Channel sharing – The DNIS and/or ANI information associated with the incoming call is used to select a particular IVR Designer application to service the call. This allows telephony ports to be shared across many applications. With port sharing, the same number of ports can handle more calls while maintaining the same grade of service. Alternatively, the same number of calls can be handled at a higher grade of service. • ANI service – Providing this service allows applications to be customized according to the calling party number or a range of numbers, for example, an area code. • Call information – Once the call is answered by the Avaya IR system, the ASAI information related to the call (such as ANI and DNIS) can be retrieved for use in the voice application that is handling the call. • Enhanced transfer – The use of ASAI call control capabilities allows the transfer to be faster, quieter from the caller's perspective, and more reliable. In addition, the G3 ASAI feature of direct agent calling can be used to transfer the call. This allows the call to be delivered to a specific agent while maintaining accurate ACD split statistics. Calls placed to specific agents without the direct agent calling feature do not count as ACD calls in calculating and reporting ACD split statistics. Finally, data that is captured in the voice application can be saved and associated with the transferred call. This enables a host application to deliver data screens to agents that are based on data collected by the voice application that previously serviced the caller and any combination of ANI and/or DNIS information. See "Data screen delivery applications" for more information. The availability of ANI for application selection or within the voice application permits the design of unique voice response applications. Examples include: - Locator service. A local or host database can be used to determine the closest car dealers, ATMs, stores, and so on. - Weather reports. A weather report for the caller's area can be provided. - Pay-per-view. A cable company can use ANI to automate customer selection and billing of pay-per-view programs. - Caller-dependent transfers. The full 10-digit ANI can be used to identify callers and determine where they should be transferred if they need to speak to a live agent. This is desirable if, for instance, the caller is a preferred customer or is usually handled by a specific agent. - Geographically based call transfers. The area code and/or exchange can be used to determine where callers should be transferred if they need to speak to a live agent. This is desirable if, for instance, agents handle calls from specific geographic regions. Routing applications In routing applications using the ASAI feature, the Avaya IR system is used as a routing server to support the routing capabilities of ASAI and the call vectoring feature on the DEFINITY G3
86 Specialized applications December 2008 ASAI application types
switch. The DEFINITY G3 switch generates these call-routing requests when a call is processed by specific call vectors on the switch. Information as to where to route calls can reside on the Avaya IR system in a local database or can be provided by a host to which the Avaya IR system is connected. Call routing is typically based on ANI or call-prompting data collected by the DEFINITY G3 switch. The use of routing capabilities can significantly improve the efficiency of a call center as shown in the following examples: • Priority service – Important or priority callers such as major clients can be routed to a common agent group but queued at a higher priority so that they are serviced faster. These callers can also be routed to the specific agent who normally handles their transactions. • Call redirection – Callers dialing into a particular call center application can be redirected to other call center applications. For example, callers who have delinquent accounts can be redirected to a collections department when they call a sales department. • Call screening – Fraudulent callers can be disconnected before being connected to an agent so that no network costs are incurred and no agent time is wasted. • Geographically-based service – Where service is provided on a regional basis, callers can be routed to the agent group that is responsible for their region. Data screen delivery applications In data screen delivery applications, an application that resides on the host delivers a specified data screen related to a caller or dialed number to an agent at the same time that a voice call is delivered to the agent's telephone. This reduces both the agent time and network time required to service the caller. Note that the delivery of data screens is not a function of the Avaya IR system itself. The system acts only as a communications gateway between the DEFINITY G3 switch and the host computer. A monitoring application on the Avaya IR system provides the ability to track the status of calls on the switch. This monitoring application receives information about calls delivered to live agents and forwards this information to the application on the host. The host application in turn uses this information to deliver a data screen to the agent receiving the call. The information made available to the host includes which agent receives a particular call and the ASAI information associated with the call, such as ANI, DNIS, and any DEFINITY G3 switch call-prompting information collected from the caller. In addition, the call may have been serviced by a Avaya IR system voice application and then transferred to a live agent. In this case, information collected in the voice application can be saved and passed to the host at the time the call is delivered to the agent. Monitoring applications on the Avaya IR system can therefore be used to support data screen delivery for three different call-flow scenarios: • Avaya IR system-to-agent transfers – In this scenario, calls are delivered to the system and then transferred to a live agent. As described previously, data screens delivered to agents in this scenario can be based on information collected in a voice application in addition to ASAI information such as ANI and DNIS and call-prompting information collected by the DEFINITY G3 switch. • Incoming call directly to agent – In this scenario, incoming trunk calls are delivered directly to live agents. Data screens delivered to agents are based primarily on ANI and DNIS and/or call-prompting information. Data screens are not based on data
Specialized applications December 2008 87 ASAI applications
collected in a voice application, since a voice application is not used to collect data from the caller. • Agent-to-agent transfers – In this scenario, calls are transferred between live agents. Here, for example, "screening" agents can be used to collect information from the caller and handle simple transactions. The call can subsequently be transferred to "specialized" agents to handle more complex or detailed transactions. In these scenarios, data screens can be based on information keyed in to the host application by live agents. The host application can save data collected and entered by a screening agent and then use this data as the basis for data screens delivered to specialized agents who can receive the call. Note that the information available for the other two scenarios (that is, ANI, DNIS, call-prompting information, and voice- application data) is also available in this scenario. This information can be used in conjunction with data entered by a live agent to provide the basis for data screens.
Note: You must plan your call flows carefully if you are using multiple ASAI adjuncts with the same DEFINITY G3 switch. Once a call is monitored by a particular Avaya IR system, the call cannot be redirected or transferred to a domain that is monitored by another system or ASAI adjunct. This is a consideration primarily for data screen delivery applications. For example, if you have agent-to-agent transfers for data screen delivery applications, agents must restrict transfers to domains monitored by the same Avaya IR system that monitors calls delivered to them. Also, for example, you might have Avaya IR system-to-agent transfers to support data screen delivery based on data collected by the Avaya IR system. In this case, you should configure multiple Avaya IR systems to "front end" mutually exclusive sets of live agents. These considerations do not apply if you are using only one Avaya IR ASAI system and it is the only ASAI adjunct. The Avaya IR system-to-agent transfer scenario described above is supported using the enhanced-transfer capability provided for ASAI voice-response applications. The enhanced- transfer capability allows data collected in the voice application to be saved and associated with the transferred call. Data saved in this fashion can be included in the call-event information that is passed to the host at the time the transferred call is delivered to an agent. The ability to save voice application data is useful in many ways. A voice application can be used to collect a variety of information such as account number, social security number, personal identification number, desired service, and so on. In many cases, this type of information is more useful than ASAI information such as ANI to both the host application and the live agents handling calls. The ability to save voice application data with the enhanced transfer capability provides a useful bridge between voice response and data screen delivery applications. It provides true integration (in addition to coresidency) of the voice response and switch-to-host gateway capabilities offered with the Avaya IR system's ASAI feature. This mechanism for embedding voice application data in call event information for the transferred call can significantly reduce the complexity of the host application. Without this mechanism, the host application is typically required to associate information from two different physical interfaces (one interface from the voice response unit to receive data collected from the caller and another interface from the monitoring device over which call events are received). Also, the host application is typically required to track and associate multiple events for multiple calls (the initial incoming call to the voice response unit and the second, transferred call that is delivered to an agent). With the ASAI feature, a single message to the host over a single interface provides all the information needed to deliver a data screen based on data collected in a voice application.
88 Specialized applications December 2008 ASAI versus the converse vector step
ASAI versus the converse vector step
The Converse Vector Step (CVS) allows the switch to maintain control of a call while capabilities of the Avaya IR system are being used. Whether to use ASAI or the CVS depends on several factors, including cost, traffic, and desired functionality. For example, the CVS feature, used in an application, could support a low-cost ANI routing application. Large volumes of traffic may require an ASAI-based solution due to the more efficient ASAI adjunct routing. See Converse vector step routing, for more information about the CVS. The following provides a list of the capabilities and limitations of using the two features on telephony lines. Both ASAI and CVS provide the delivery of ANI, DNIS, and switch call prompting digits for calls. The CVS provides this information on an in-band basis while ASAI makes the data available on an out-of-band basis. The ASAI out-of-band exchange of data is faster.
Note: CVS allows a maximum of two parameters to be delivered.
The Avaya IR system ASAI external functions A_Event and A_RouteSel can be used in monitoring and routing applications even if the calls are delivered via the CVS. In addition, both ASAI and the CVS have some unique properties that may influence the decision as to which feature to use: • ASAI properties - When the Avaya IR system is used as a gateway for switch-to-host applications, the A_Tran external function simplifies call-flow development using screen pops based on data collected by the Avaya IR system. - Dynamic port allocation is simpler because ANI and DNIS service administration is supported. • CVS properties - CVS allows a call to remain in a live agent queue while interacting with the Avaya IR system. - Queue position and administered digit string can be passed to the Avaya IR system using the CVS. Queue position could be used as the basis for an anticipated delay announcement. An administered digit string could be used to identify specific announcements to be played to callers.
Specialized applications December 2008 89 ASAI applications
ASAI application design
The ASAI feature provides four IVR Designer external functions that can be used to access ASAI capabilities. The following table describes the ASAI external functions.
ASAI external Description function
A_Callinfo This external function is used within a voice response application to retrieve ASAI information about a call delivered to a telephony channel. This external function can retrieve the following ASAI information: calling number (ANI), called number (DNIS), switch-collected touch-tone digits, Universal Call Identification (UCID), User-to-User Information (UUI), ANI Information Indicator (ANI II) digits, and network (ISDN) Redirecting Number. This external function therefore provides access to the Notification capability of ASAI for calls delivered to the Avaya IR system.
A_Event This external function is used within routing applications to receive information about call routing requests sent by the DEFINITY G3 switch. This external function can retrieve the following ASAI information: calling number (ANI), called number (DNIS), switch-collected touch-tone digits, Universal Call Identification (UCID), and network (ISDN) Redirecting Number. This external function is also used in monitoring applications to receive information about calls delivered to an ACD agent. This external function therefore serves a dual role by providing access to both the Routing and Notification capabilities of ASAI.
A_RouteSel This external function is used within routing applications to respond to call-routing requests previously received via the use of the A_Event external function. This external function therefore provides access to the Routing capability of ASAI and allows the Avaya IR system to send ASAI call routing information to the switch.
A_Tran This external function is used within a voice response application to transfer a call away from a telephony channel on the Avaya IR system. This external function makes use
90 Specialized applications December 2008 ASAI application design
ASAI external Description function of the Third Party Call Control capability of ASAI to effect the transfer.
ASAI voice application design ASAI voice response applications are designed using the A_Callinfo and A_Tran external functions within voice response applications. Other standard IVR Designer nodes are also used in the voice application to answer the call, greet the caller, collect data, and so on. The A_Callinfo and A_Tran external functions are used only in applications that handle calls delivered to an Avaya IR system telephony channel. These two external functions are not used in routing and monitoring applications where, in contrast to voice applications, a call is not present at a telephony channel. For ASAI voice response applications, incoming calls are routed to the Avaya IR system over telephony channels configured either as extensions in an ACD split or as agent ID's under a VDN in an EAS environment on the DEFINITY G3 switch. The Avaya IR system uses the Notification capability of ASAI to monitor the ACD split or VDN. As a call is offered, the Avaya IR system receives event reports indicating the status of the call, for example, call offered, queued, alerting, and connected event reports. The Avaya IR system uses the information contained in these event reports to provide the following capabilities: • DNIS and ANI service – The DNIS or ANI information associated with the incoming call is used to select a particular IVR Designer application to service the call. A unique dialed number can be provided for each unique voice response application. Each dialed number is typically represented by a unique VDN on the DEFINITY G3 switch. Calls to these different VDNs can be routed to the same Avaya IR system. The DNIS and/or ANI information associated with an incoming call is then used to select a particular application. An administrative screen on the Avaya IR system allows the different dialed numbers to be associated with a specific voice response application. This allows telephony channels to be shared across many applications. Prior to this capability, channels had to be dedicated to specific IVR Designer applications. • Call information – Once the Avaya IR system answers the call, the ASAI information related to the call can be retrieved for use in the voice application that is handling the call. In particular, the A_Callinfo external function can be used to obtain ANI, DNIS, switch-collected user data (touch-tone digits), call ID, Universal Call Identification (UCID), User-to-User Information (UUI), ANI II digits, network (ISDN) Redirecting Number, and incoming trunk group ID if ANI is not available. A user designing a voice application need not be concerned with processing the individual, lower-level ASAI event reports for incoming calls to the Avaya IR system. Rather, special software is provided as part of the ASAI feature. This software processes the event reports and stores the information contained in these reports on a per-call basis. The DNIS or ANI information associated with a call is used to start a specific voice application on the channel that receives the call. The A_Callinfo external function can then be used within the application to retrieve this information and use it in subsequent IVR Designer nodes. A subset of the Third Party Call Control capability of ASAI is also supported for ASAI voice response applications. In particular, the A_Tran external function uses Third Party Call Control to transfer a call away from the telephony channel. The use of the A_Tran external function within a voice response application invokes the Third Party Call Control operations of third-party take control, third-party hold, third-party make call,
Specialized applications December 2008 91 ASAI applications
and third-party merge. This sequence of ASAI operations invoked with A_Tran effects a transfer of the incoming call to the destination specified with the Destination Number field in A_Tran. Hence, the application designer is not required to program many individual ASAI operations. The use of a single external function effects the transfer. Standard switch-hook-flash transfers are still possible when the ASAI feature is used. The use of A_Tran, however, provides three significant enhancements over existing transfer mechanisms: • Transfers are faster, quieter from the caller's perspective, and more reliable since third-party call control is used rather than the standard switch-hook-flash mechanism. • The transfer can be completed using direct agent calling. This is done by setting the Destination Number field in A_Tran to the desired agent extension and by setting the Split Extension field to the ACD split logged into by the agent. Direct agent calling allows the transfer to be completed to a specific agent while maintaining accurate ACD split measurements. The DEFINITY G3 switch direct agent calling feature can only be invoked via ASAI. • Information captured in the voice application can be saved for subsequent use in a data screen delivery application. Information assigned to the Avaya IR system Data field of A_Tran is saved by the Avaya IR system even after the voice application terminates. The Avaya IR system associates this data with the transferred call and makes this data available in call events passed to the monitoring application that monitors the transferred call. The third enhancement is very useful for data screen delivery applications where the screens delivered to agents are based on data collected by the Avaya IR system. Since data collected in a voice application can be saved and is included in call events that are made available to the monitoring application, the host application is simplified. For instance, a CONNECT event (described later) that is made available to the monitoring application contains both the extension of the agent receiving the transferred call and the Avaya IR system data that was saved from the voice application that previously serviced the caller. This single event is then passed to the host, thereby providing all information needed by the host application in a single message. Routing application design Routing applications make use of the routing capability supported by ASAI and the call- vectoring feature on the DEFINITY G3 switch. In routing scenarios, calls are not physically delivered to telephony channels on the Avaya IR system. Instead, incoming calls to the DEFINITY G3 switch are directed to a vector containing an adjunct route step. The adjunct route step causes a route request message to be sent to the Avaya IR system. The route request message contains information pertaining to the call, for example, ANI or network (ISDN) redirecting number. The Avaya IR system uses this information to determine where to route the call. After the Avaya IR system determines where to route the call, a route select message is sent back to the DEFINITY G3 switch. The route select message contains a destination address provided by the Avaya IR system that the DEFINITY G3 switch uses to further direct the call. In routing scenarios, the Avaya IR system can be viewed as a routing server which the DEFINITY G3 switch calls upon to route calls processed with a routing vector. Note that as a result of routing, the call might be directed to an Avaya IR system to collect more information from the caller. This would be the case, for example, if the information contained in the route request is not sufficient to identify the caller, for example, ANI not recognized. Routing applications on the Avaya IR system are supported through the use of routing applications that are designed using the A_Event and A_RouteSel external functions. The 92 Specialized applications December 2008 ASAI application design
A_Event external function is used to bring information contained in a route-request message that is sent by the DEFINITY G3 switch up to the application level. The A_Event external function returns a ROUTE REQUEST event when the DEFINITY G3 switch sends such a message. If no route-request messages are sent, the A_Event external function waits until it receives one. When a ROUTE REQUEST event is made available to the application, it reflects information in an ASAI route-request message sent by the DEFINITY G3 switch. Note that the A_Event external function is also used within monitoring applications to retrieve other types of events as discussed later. Once a ROUTE REQUEST event is received in a application and the application determines where the call should be routed, the A_RouteSel external function is used to cause a route- select message to be passed back to the DEFINITY G3 switch. This in turn causes the call to be routed to the desired destination. Unlike voice response applications, routing applications are not associated with a particular call. A single routing application handles route requests for many calls. A routing application is designed to receive and process ROUTE REQUEST events. Because these events are controlled by vector processing on the DEFINITY G3 switch, they can arrive at any point in time. Hence, the primary difference between routing applications and voice response applications is that once they are activated, routing applications run continuously. Routing applications, therefore, have the following general structure: 1. An A_Event external function to wait for and retrieve a ROUTE REQUEST event from lower-level ASAI software on the Avaya IR system. Once the A_Event external function retrieves a ROUTE REQUEST event, the actions below are executed. 2. Other IVR Designer nodes that make use of the data made available in the ROUTE REQUEST event to determine where to route the call. Examples include read table and get/send host screen nodes to retrieve routing information from a local or host database. 3. An A_RouteSel external function to pass the routing information (that is, desired destination) from the application to lower-level ASAI software on the Avaya IR system. This causes an ASAI route-select message containing the routing information to be sent to the DEFINITY G3 switch. A routing application can use any of the information returned in the ROUTE REQUEST event. Examples include the called-party number (for example, DNIS), calling party number (for example, ANI), and switch data (that is, touch-tone digits collected using the Call Prompting feature). Any one or combination of the data items returned in a ROUTE REQUEST event can be used as the basis for a routing decision. The call is routed to the destination that is supplied in the Destination Number field of A_RouteSel. The destination can be on-switch (for example, station, ACD split, or VDN) or off- switch (for example, Direct Distance Dialing [DDD] number). Also, the call can be routed to a specific agent within an ACD split (direct agent routing). To do this, set the Destination Number field in A_RouteSel to the desired agent extension and the Split Extension field to the split logged into by the agent. Direct-agent routing is the preferred way to route calls to specific ACD agents since direct-agent calls are included in the calculations for ACD split statistics, for example, average speed of answer. Monitoring application design Monitoring applications on the Avaya IR system are used to support data screen delivery applications. The Notification capability of ASAI is used to track the progress of calls that are delivered to agents. A monitoring application on the Avaya IR system receives information about these calls and forwards this information to a host application. The host application in
Specialized applications December 2008 93 ASAI applications
turn uses the information to format a data screen that is presented to agents receiving calls. Note, therefore, that the delivery of data screens is not a function of the Avaya IR system itself. In data screen delivery applications, calls are not physically delivered to a telephony channel on the Avaya IR system. Rather, calls are delivered to ACD agents on the DEFINITY G3 switch. Note, however, that a call may have previously been delivered to a telephony channel to collect information from the caller. Events Use the A_Event external function to design a monitoring application. When used in monitoring applications, the A_Event external function returns the types of call events described in the following table.
Call event Description
CONNECT Indicates that a monitored call is being delivered to an agent. Event
ABANDON Indicates that a monitored call has been abandoned. Event ABANDON events are passed to a application whenever a caller hangs up before being connected to an agent.
END Event Indicates that a monitored call has ended normally, that is, not abandoned.
The three call event types passed to a monitoring application reflect information contained in ASAI event reports for the call. General structure Unlike voice response applications, monitoring applications are not associated with a particular call. A single monitoring application handles call events for all of the calls that are delivered to a particular domain. A monitoring application is designed to receive and process call events that can arrive at any point in time as determined by how and when calls progress on the DEFINITY G3 switch. Hence, the primary difference between monitoring applications and voice response applications is that once activated, monitoring applications run continuously. Monitoring applications, therefore, have the following general structure: 1. An A_Event external function to wait for and retrieve a call event from lower-level ASAI software on the Avaya IR system. Once the A_Event external function retrieves a call event, the actions below are executed. 2. Other IVR Designer nodes are used to pass data to a host. Examples include get/ send host screen nodes to send the data to an IBM host via the standard 3270 interface and a custom external function to pass the data to a custom DIP supporting an asynchronous interface. A monitoring application can pass any combination of call-event types to a host. In addition, any combination of the data elements returned in a specific call event can be passed to a host. Examples include the called party number (for example, DNIS), calling party number (for example, ANI), and switch data (that is, call prompting information). If you make changes to an existing monitoring application or add a new monitoring application, you must do one of the following:
94 Specialized applications December 2008 ASAI application design
1. Disable and then reenable the domain. 2. Stop and restart the voice system to activate the new application. Call-flow scenarios Monitoring applications on the Avaya IR system can be used to support data screen delivery for the following three different call-flow scenarios: • Avaya IR system-to-agent transfers – In this scenario, calls are initially delivered to the system and then transferred from the Avaya IR system to a live agent. The transferred call can be monitored with a VDN type or ACD type of monitoring application if the call is transferred to a monitored VDN or ACD split domain. The transferred call can also be monitored with a CTL type of monitoring application that allows the call to be transferred to a nonmonitored domain or individual station. If the Data field of A_Tran was used to save voice application data, this data is made available in the Avaya IR system Data field of call events that are sent to the monitoring application. Hence, data screens that are delivered to agents in this scenario can be based on information that is collected in a voice application in addition to ASAI information such as ANI, DNIS, and call-prompting information that is collected by the DEFINITY G3 switch. • Incoming call directly to agent – In this scenario, monitored VDNs or ACD splits deliver incoming trunk calls directly to live agents. Here, call events are passed to a VDN type or ACD type of monitoring application and contain ASAI-related information such as ANI, DNIS, and/or call-prompting information. Data screens are not based on data that is collected in a voice application since a Avaya IR system voice application is not used to collect data from the caller. Since the Avaya IR system does not service calls in this scenario, no data is present in the Avaya IR system Data field of call events. • Agent-to-agent transfers – In this scenario, calls are transferred between live agents. For example, screening agents can be used to collect information from the caller and handle simple transactions. The call can subsequently be transferred to specialized agents who can handle more complex or detailed transactions. In these scenarios, data screens can be based on information that is keyed in to the host application by live agents. The host application can save the data that is collected and entered by a screening agent and then use this data as the basis for data screens that are delivered to other, specialized agents who can receive the call. The agent-to-agent transfer can be placed to a monitored domain or to an individual station and monitored with a VDN type or ACD type of monitoring application. Note that the call might have first been delivered to the Avaya IR system and then transferred to an agent prior to the live agent-to-agent transfer. Hence, call events passed to the monitoring application in this scenario can contain the same information that is available for the other two call- flow scenarios. ASAI-related information such as ANI, DNIS, and call-prompting information and Avaya IR system data can be present in call events. This information can be used in conjunction with data that is entered by a live agent to provide the basis for data screens.
Specialized applications December 2008 95 ASAI applications
Using ASAI in a call center
ASAI can significantly improve the operations in a call center. This feature provides the following benefits: • Enhanced customer service Caller-dependent and region-dependent treatment for incoming calls is possible in routing and voice response applications. In addition, the direct agent calling feature that is available with these applications allows calls to be delivered to specific agents while maintaining accurate split measurements. These capabilities help to ensure that calls are quickly and reliably directed to the call center resource that is best suited to handle them. This minimizes the number of transfers that a caller experiences and allows callers to be serviced in a rapid, consistent, and personalized fashion. In data screen delivery applications, information associated with a given call is available to each agent who receives the call. This eliminates the need for callers to repeat information to each agent. For example, a caller may be directed initially to a Avaya IR system telephony channel where the caller is prompted through an automated voice response application. At some point the caller may request to be transferred to a live agent to discuss a topic in more detail. With the Avaya IR system's ASAI feature, the identity of the caller and additional information collected from the caller by the voice-response application can be saved and presented in a data screen to the live agent receiving the transferred call. This eliminates the need for the caller to repeat information already collected when calls are transferred multiple times or are transferred between live agents. Thus, call holding time is reduced. • Improved price and performance The coresidency of voice response and switch-to-host gateway applications with the ASAI feature eliminates the need for multiple boxes with multiple interfaces to the host computer, thereby simplifying host application development. Access to ASAI capabilities using IVR Designer minimizes the effort required to implement the Avaya IR system's piece of the overall Avaya IR system/host application. In addition, the use of DNIS in voice response applications to enable telephony channel sharing means that the same number of Avaya IR system channels can service more calls. • Reduced cost of doing business Because the host screen application is ready to provide or accept information at the same time that the agent begins to speak with the caller, the use of data screen delivery applications reduces the time needed to service calls. Because calls are shorter, network charges are lower. The same number of agents can handle an increase in call volume since per-call service time is reduced. Also, certain calls can be eliminated entirely via the use of routing applications, for example, call screening for the identification of fraudulent calls. Specific agent tasks might change when you add an ASAI application such as data screen delivery to the call center. You should determine what agent training is needed before the new service begins. Agents should be trained on what new information will appear on their data
96 Specialized applications December 2008 Using ASAI in a call center
terminal screens and how to use that information to interact with calling customers. Before implementing a data screen delivery application with the entire agent population, conduct a trial to compare old call center operations with the new call center operations using a data screen delivery application. Be sure to explain the benefits of the application so that agents can take advantage of them. If data screen delivery is performed for agent-to-agent transfers, carefully read the information on Agent-to-Agent Transfers. Agents must be trained to perform transfers properly so that the desired call events are passed to the host application. More specifically, for blind transfers, agents must transfer calls as follows: 1. Place the original call on hold by pressing the Transfer button once. This also causes a new call appearance to become active (dial tone is heard on this call appearance). 2. Dial the desired extension while hearing dial tone on the new, active call appearance. 3. Immediately press the Transfer button again after dialing the desired extension to complete the transfer. In consult transfer scenarios, the agent may wait to talk to the second agent before completing the transfer. However, the agent must make sure that the original call is on transfer hold before completing the transfer. A call is said to be on transfer hold when the call is placed on hold by pressing the Transfer button. This is as opposed to regular hold where the call is placed on hold by pressing the Hold button. For example, the agent may decide to return to the original caller before completing the transfer (for example, to say, "Please wait while I transfer you to Bill who can handle your question"). The agent must be sure to place the original call on transfer hold (not regular hold) before completing the transfer. If the agent used regular hold, the agent would be unable to return to the original caller. Use the following procedure for consult transfer situations where the screening agent wants to go back and talk to the original caller before completing the transfer. In this procedure, Agent 1 is the screening agent who receives the original call from the calling customer. Agent 2 is the specialized agent who receives the transferred call. Although this procedure may seem cumbersome initially, it is the most natural set of steps to take in consult transfer scenarios where the screening agent wants to announce the transfer to the original caller after having talked to the specialized agent. This procedure also ensures that the Avaya IR system can properly identify the original call when the two calls are merged. If agents do not follow this procedure, inaccurate call events are reported to the host application. 1. Agent 1 places the original caller on hold by pressing the Transfer button once. This also causes a new call appearance to become active (dial tone is heard on this call appearance). 2. Agent 1 dials Agent 2 while hearing dial tone on the new, active call appearance. 3. Agent 1 places the call to Agent 2 on regular hold by pressing the Hold button while the call to Agent 2 is still the active call. 4. Agent 1 returns to the original caller by pressing the call appearance for the original call. This makes the original call active once again. Agent 1 can now talk to the original caller.
Specialized applications December 2008 97 ASAI applications
5. After talking to the original caller for the second time, Agent 1 places the original caller on transfer hold again by pressing the Transfer button again. This is the second time Agent 1 has pressed the Transfer button. This causes a third, as yet unused, call appearance to become active. (Dial tone is heard on this call appearance, but this call appearance is not used for anything. Agent 1 goes to the next step and ignores the dial tone). 6. Agent 1 makes the call to Agent 2, which is currently on regular hold, the active call by pressing the call appearance for this call. At this point Agent 1 and Agent 2 are connected again and Agent 1 can inform Agent 2 that the transfer is about to be completed. 7. Agent 1 completes the transfer by pressing the Transfer button again. This is the third time Agent 1 has pressed the Transfer button.
Call-flow design Avaya IR system-to-agent transfers Avaya IR system-to-agent transfers are accomplished by using the A_Tran external function within a voice application that is servicing a caller. The use of A_Tran invokes ASAI Third Party Call Control operations to transfer a call away from the telephony channel to which the caller is connected. The caller is transferred to the destination that is identified in the Destination Number field of the A_Tran external function. The transferred call can be monitored by a monitoring application so that data screen delivery applications can be supported for Avaya IR system-to-agent transfers. The transferred call can be monitored in two different ways: • The call can be transferred to a VDN or ACD split domain that is monitored by the Avaya IR system with a monitoring application. Call events for the transferred call are passed to the application that is monitoring the domain to which the call is transferred. • The call can be monitored using a CTL type monitoring application. In this case, the call can be transferred to nonmonitored domains and individual stations. Here, only call events for calls that are transferred from the Avaya IR system to agents are passed to monitoring applications. Other direct calls to an ACD split, for example, are not monitored. Therefore, no call events for the direct calls are passed to monitoring applications. You can use a combination of the above two monitoring mechanisms on the same Avaya IR system. In addition to monitoring the transferred call, the application developer can save data that is collected in the voice application for subsequent use in the data screen delivery application. To do this, use the Avaya IR system Data field of A_Tran. Any data saved that is in this field when the transfer is initiated from the voice application is presented in call events that are passed to the monitoring application that monitors the transferred call. The Avaya IR system Data field provides storage for 20 characters. Note that multiple data items can be stored in this field. A social security number and PIN number, for example, can be collected in the voice application, concatenated, and then saved in the Avaya IR system Data field. The monitoring
98 Specialized applications December 2008 Call-flow design
application that receives this data in call events can then unbundle the information for use in data screen delivery when the transferred call is delivered to an agent. Typical call flow for Avaya IR system-to-agent transfers The following is a typical call flow for a Avaya IR system-to-agent transfer: 1. A call arrives at a telephony channel on the Avaya IR system. The caller is prompted through a voice response application. 2. The caller decides to speak to a live agent after entering an account number. The voice application transfers the call to a live agent group using the A_Tran external function. The account number that the caller input is saved by using the Avaya IR system Data field of A_Tran. The voice application terminates after the transfer is complete and the telephony channel is free to handle another call. 3. The transferred call is queued for an available agent. When the call is eventually delivered to an agent, a monitoring application on the Avaya IR system receives a CONNECT event for the call. The Avaya IR system Data field of this CONNECT event contains the account number that was previously saved by the voice application. The monitoring application passes the account number along with the connected agent information from the CONNECT event to the host. 4. The host application uses the account number to format a data screen concerning the caller and presents this data screen to the agent who receives the call. The host application does not need to associate multiple calls since all the necessary information for the transferred call is provided in a single CONNECT event. One CONNECT event is generated for the entire scenario. This is the CONNECT event for the transferred call as it is delivered to the live agent. This CONNECT event contains the Avaya IR system Data information in addition to ASAI information that is related to the original call to the Avaya IR system. The ANI and DNIS for the original call prior to the transfer, for example, are reported in this CONNECT event. Also, the Other Call ID field contains the call ID of the call that was originally delivered to the Avaya IR system's telephony channel. Call events for calls to telephony channels on the Avaya IR system are not passed to monitoring applications. Also, one END event is generated when the call eventually terminates. As with the CONNECT event, the END event contains data that is pertinent to the original call. See Call flow examples for a detailed call flow example. Considerations for Avaya IR system-to-agent transfers Additional considerations for Avaya IR system-to-agent transfers are as follows: • In some cases, you might want to collect more data in a voice application than can be stored in the Avaya IR system Data field. The recommended method for handling this is to save the data collected by the voice application in the host application. Use A_Callinfo to retrieve the call ID of the call that is delivered to the telephony channel. Pass the call ID along with the data to the host from the voice application itself. The host application must buffer the data until the CONNECT event for the transferred call is received. The call ID in the Other Call ID field of the CONNECT event can be used to correlate the two calls. • The call can be transferred again after having been serviced by the live agent. In this case, an END event is not reported until all transferring is complete and the call terminates normally. As in the case of a single transfer, the END event contains information pertinent to the original call. Rules for how subsequent call events are reported are discussed in Agent-to-Agent Transfers.
Specialized applications December 2008 99 ASAI applications
• The discussions on blind and consult transfers do not apply to Avaya IR system-to- agent transfers completed using the A_Tran external function. Also, the delay needed for agent-to-agent transfers discussed later does not apply to Avaya IR system-to- agent transfers completed using the A_Tran external function. • Transfers away from the Avaya IR system can still be accomplished by using standard flash transfer mechanisms. This type of transfer, however, precludes the ability to use the Avaya IR system Data field of the A_Tran screen to save voice application data for later use in data screen delivery applications. Also, the host application must view this type of transfer as an agent-to-agent transfer. Hence, the discussions on blind transfer versus consult transfer and the need to introduce delay for blind transfers from the Avaya IR system apply. Agent-to-agent transfers There are two options for call transfer in an agent-to-agent transfer scenario: blind transfer and consult transfer. These two options differ as to when the screening agent (the agent transferring the call) completes the transfer to the specialized agent (the agent receiving the transferred call) by pressing the Transfer button a second time. • With a blind transfer, the screening agent presses the Transfer button a second time immediately after dialing. The screening agent does not talk to the specialized agent before completing the transfer. In addition, a delay is built into call handling so that the call is distributed to a specialized agent after the screening agent presses the Transfer button the second time. • With a consulttransfer, the screening agent waits until the specialized agent answers before pressing the Transfer button a second time.This allows the screening agent to talk to the specialized agent before completing the transfer. Both of these call-transfer options are described in more detail later. To set up either a blind transfer or a consult transfer, it is important to understand two key concepts of how transferred calls are handled on the DEFINITY G3 switch. Call monitoring in transfer scenarios The Avaya IR system monitors VDN or ACD split domains by assigning monitoring applications. A call becomes monitored once it enters one of these monitored domains. The Avaya IR system must also monitor all domains to which this call can be directed. Once monitored, therefore, a call remains monitored for the duration of the call even though it can be transferred several times. Once a call becomes monitored, call events are passed to the monitoring application that is assigned to the domain the call entered. A CONNECT event, for example, is passed to a monitoring application when a specific agent is selected to receive the call. The screening agent may transfer calls to other monitored VDN and ACD splits or to individual stations. The original call to the screening agent must be monitored and therefore delivered to the screening agent via a monitored VDN or ACD split. Call ID management in transfer scenarios The DEFINITY G3 switch assigns a call ID to each call. The call ID is provided in the Call ID field of call events for the call. In agent-to-agent transfer scenarios, there are multiple calls and, therefore, multiple call IDs as described in the following transfer scenario:
100 Specialized applications December 2008 Call-flow design
1. The original call is delivered to an agent and is assigned a unique call ID. The agent talks with the caller and decides that the call needs to be transferred to another agent. 2. The first press of a Transfer button places the original call on hold and allows another call to be placed from the transferring telephone. 3. A second call, temporarily independent of the first call, is placed from the transferring telephone. This call is assigned a call ID that is different from that of the original call. If this second call is placed to a monitored domain, the call immediately becomes monitored by the Avaya IR system and call events can be passed to a monitoring application. If this second call is placed to an individual station, the call does not become monitored until the transfer is complete as described in Step 4. 4. The second press of the Transfer button merges the original call which is on hold with the second call and drops the transferring telephone from the resultant call. The Avaya IR system is informed about the completed transfer immediately after the merge that occurs in Step 4. It is only after this merge, therefore, that the Avaya IR system has the ability to associate the two calls. With a blind transfer, this merge takes place before the merged call is delivered to the second, specialized agent. Hence, with blind transfer calls, the Avaya IR system can include information in the CONNECT event for the merged call that relates to the original call. In particular, the Avaya IR system retains the call ID of the original call and reports it in the Other Call ID field of the call events for the transferred call. This mechanism allows the host application to use call ID to associate the transferred call with the original call. With a consult transfer, the merge takes place after the second call is delivered to the second, specialized agent. In this case, the original call is still on hold at the first agent's telephone when the second call is delivered to the second agent. Hence, for consult transfers, the Avaya IR system can only provide information that is related to the second call in the CONNECT event for the second call. In particular, the call ID of the original call is not reported in the Other Call ID field of the CONNECT event for the second call. The host application must use a mechanism other than call ID to associate the original call with the second call. The alternate mechanism is the CPN information as discussed below. Blind transfer With a blind transfer, the screening agent does not talk to the specialized agent before completing the transfer. With this type of transfer, the Avaya IR system retains the call ID of the original call and reports it in the Other Call ID field of call events for the transferred call. Also, other ASAI information such as ANI and DNIS that is related to the original call is reported in the call events for the transferred call. A typical call flow for blind transfers is described below. In this call flow, Agent 1 is a live agent in a screening split who transfers calls to specialized agents. Agent 2 is a specialized agent who can either receive calls via a monitored VDN or ACD split or via a regular extension. Calls to Agent 1 in the screening split must be delivered via a monitored VDN or ACD split. 1. A call arrives for Agent 1. 2. Agent 1 answers the call and enters pertinent information about the caller. 3. Agent 1 transfers the call to Agent 2 by pressing the transfer button, dialing the VDN, ACD split, or individual extension and pressing the transfer button again.
Specialized applications December 2008 101 ASAI applications
4. Agent 1 is finished with the call. 5. The host application uses call ID information reported in CONNECT events to determine which data to display on Agent 2's data-terminal screen. The call ID from the Call ID field of the CONNECT event for the original call matches the call ID provided in the Other Call ID field of the CONNECT event for the transferred call. Two CONNECT events are passed to monitoring applications for the entire scenario, that is, one for the original call to the screening agent and one for the transfer to the specialized agent. One END event is generated when the call eventually terminates. See Call flow examples for detailed examples that include complete descriptions of call flows and call-event contents. The following conditions should be noted for blind transfers: • The domain that receives the original call and any domains that receive the transferred call must be monitored. • Calls can be transferred either to a monitored domain or to a station. For a blind transfer to a monitored domain, the following must be considered: - The agent must complete the transfer immediately after initiating it by pressing the Transfer button a second time. - A delay must be built into the flow of the transfer so that the communications system can recognize the completion of the transfer before the receiving agent is selected for the call. You can create this built-in delay by transferring calls to a VDN. This VDN is associated with a vector that has a wait step in it. The vector directs the call to the desired split with a route to or queue to step. For blind transfer to a station, the following must be considered: - When an agent in a monitored domain completes a transfer to a station rather than to an ACD split, a CONNECT event is passed to a monitoring application. The agent must initiate and complete the transfer by pressing the Transfer button a second time for the CONNECT event to be passed to the application. The CONNECT event therefore only becomes available to the host application when the agent pushes the Transfer button the second time. • In call-center operations that use blind transfer, the host application can tag current call data by call ID. The call ID allows the application to determine which data is associated with the call as the call is transferred to a monitored domain or station. • If for some reason calls are transferred to nonmonitored domains, unexpected operation can result. When the call placed by Agent 1 is not initially monitored, the Avaya IR system assumes that a transfer to a station is taking place. Hence, two CONNECT events for the transferred call are generated. One CONNECT event is generated when the transfer is completed by Agent 1 and another is generated when the call is actually delivered to Agent 2. Also, the Connected Party Number field of the first CONNECT event for the transferred call identifies the ACD split or VDN extension that was dialed by Agent 1, rather than identifying the extension of Agent 2. Note that the Connected Party Number field of the second CONNECT event for the transferred call identifies the extension of Agent 2. • The END event that is reported for the transferred call contains information pertinent to the original call. For example, the original ANI for the caller is reported in the Calling Party Number field and the call ID for the original call is reported in the Other Call ID
102 Specialized applications December 2008 Call-flow design
field. Also, an END event is reported for a call only when the call ultimately terminates. An END event is not reported when a call is transferred. • The call can be transferred again after it is serviced by Agent 2. In this case, an END event is not reported until all transferring is completed and the call terminates normally. As in the case of a single transfer, the END event contains information that is pertinent to the original call. Rules for how subsequent CONNECT events are reported are as described in this section and depend on whether the call is transferred to a monitored domain or to a station and whether consult or blind transfer operation is used. Consult transfer With a consult transfer, the screening agent talks to the specialized agent before completing the transfer. With this type of transfer, the call ID for the original call is not retained by the Avaya IR system and is not reported in the Other Call ID field of call events for the transferred call. A typical call flow for consult transfers is described below. In this call flow, Agent 1 is a live agent in a screening split who transfers calls to specialized agents. Agent 2 is a specialized agent who can receive calls via a monitored VDN or ACD split or via an individual station. Calls to Agent 1 in the screening split must be delivered via a monitored VDN or ACD split. 1. A call arrives for Agent 1. 2. Agent 1 answers the call and enters pertinent information about the caller. 3. Agent 1 presses the Transfer button. 4. Agent 1 dials the extension of the monitored domain or station to which the call will be transferred. 5. Agent 1 waits for Agent 2 to answer. 6. Agent 1 and Agent 2 consult privately about the caller. 7. Agent 1 presses the Transfer button again to complete the transfer. 8. Agent 1 is finished with the call. 9. The host application uses calling party information to determine which data to display on Agent 2's data terminal screen. The extension for Agent 1 is reported in the Calling Party Number field of the CONNECT event for the second call. Two CONNECT events are passed to monitoring applications for the entire scenario, one for the original call to the screening agent and one for the call to the specialized agent. One END event is generated when the call eventually terminates. See Call flow examples for detailed examples that include complete descriptions of call flows and call-event contents. The following conditions should be noted for consult transfers: • With a consult transfer, Agent 1 and Agent 2 generally both view the call data in a private consultation while the caller is on soft hold. • Calls can be transferred either to a monitored domain or to an individual station. For a consult transfer to a monitored domain, the following must be considered: - When Agent 2 is selected to receive the call from Agent 1, a CONNECT event is made available to a monitoring application. Since Agent 1 stays on the line until Agent 2 answers, the two calls have not yet been merged. This implies that the CONNECT event for the second call does not contain information that is pertinent to the first call. The Other Call ID field for the second CONNECT event, for example, is NULL and does not contain the call ID of
Specialized applications December 2008 103 ASAI applications
the first call. Also, for example, the Calling Party Number field contains the extension for Agent 1 and not the ANI for the caller. This is because the second call is viewed as a new, direct call to Agent 2 from Agent 1. The Avaya IR system cannot assume that the two calls will eventually be merged since in some cases, they will not be. Hence, the two calls cannot be correlated by using call ID from CONNECT events. - In this case, the Calling Party Number field of the second CONNECT event should be used to correlate the two calls. This field contains the extension for Agent 1. The host application can assume that Agent 1 is performing a consult transfer. The host application can then retrieve the appropriate data from Agent 1's data-terminal screen and deliver it to Agent 2's data-terminal screen. After the two agents consult, Agent 1 can complete the transfer by pressing the Transfer button a second time. No additional CONNECT event is passed to a monitoring application when the transfer is completed. For consult transfer to a station, the following must be considered: - A CONNECT event for the second call is passed to a monitoring application only after the transfer is completed when Agent 1 presses the Transfer button the second time. This means that when Agent 1 and Agent 2 are talking privately, the host application will not have been notified about the second call to Agent 2. This is because the second call is placed to a station and not to a monitored domain. The Avaya IR system, therefore, does not receive events for the second call until the two calls are merged. The host application can be programmed to allow the receiving station to query for the data. After the transfer is complete, a CONNECT event is passed to a monitoring application. This CONNECT event contains information that is pertinent to the first call. The Other Call ID field of this CONNECT event, for example, contains the call ID of the original call that was delivered to Agent 1. Also, for example, the Calling Party Number field of this CONNECT event contains the ANI of the original caller. • If calls are transferred to nonmonitored domains, an unexpected operation can result. When the call to Agent 2 from Agent 1 is not initially monitored, the Avaya IR system assumes that a transfer to a station is taking place. Hence, the Connected Party Number field of the CONNECT event generated when the transfer is completed by Agent 1 identifies the ACD split or VDN extension dialed by Agent 1, rather than the extension of Agent 2. • The END event reported for the transferred call contains information that is pertinent to the original call. For example, the original ANI for the caller is reported in the Calling Party Number field and the call ID for the original call is reported in the Other Call ID field. This is true even though the second CONNECT event for consult transfers to monitored domains does not contain information that is pertinent to the original call. This is because the END event is reported after consult transfers to monitored domains are completed; that is, after the two calls are merged and can be associated by the internal software on the Avaya IR system. Also, an END event is reported for a call only when the call ultimately terminates (that is, an END event is not reported when a call is transferred). These properties for END events allow the host application to consistently use the Other Call ID field of END events to identify when and which calls have left the DEFINITY G3 switch entirely. • The call can be transferred again after it is serviced by Agent 2. In this case, an END event is not reported until all transferring is completed and the call terminates normally. As in the case of a single transfer, the END event contains information that is pertinent to the original call. Rules for how subsequent CONNECT events are reported are as
104 Specialized applications December 2008 Host application planning and design
described in this section and depend on whether the call is transferred to a monitored domain or to a station and whether consult or blind transfer operation is used.
Host application planning and design
In certain call center environments, the Avaya IR ASAI system is integrated with a host computer. An application must be provided on the host that works with the Avaya IR ASAI system. This host software application is not part of the Avaya IR ASAI product. The host application can use the information it receives from the Avaya IR ASAI system to do certain functions such as display call information on agent screens or route calls. The host application can also be called upon to provide the basis for an automated voice response application. In some cases, particularly for voice response applications, the Avaya IR ASAI system integrates well with an embedded application and hence no changes are required. For routing and data screen delivery applications, however, you will probably have to modify an existing application or provide a new one to accommodate new functionality. You may have several options for providing this host application. For example, you can develop your own application or modify an existing application to work with the Avaya IR ASAI system. This is typically done by the customer's data processing or information systems department. Alternatively, you can purchase a third-party software vendor application that is designed to work with the Avaya IR ASAI system. Application development may require significant planning and coordination between different organizations within your company. The telecommunications, call center operations, and data processing organizations are all typically involved in the planning process. Schedules for application development or customization must be coordinated closely with plans to implement the Avaya IR ASAI system, ISDN services, and any additional communications system ACD features. The voice response, routing, and data screen delivery applications enabled by a Avaya IR ASAI system can all potentially make use of ANI information delivered by the network. Keep the following considerations in mind when using ANI: • You should allow for the possibility that the same caller will call from different telephone numbers. The same person, for example, might sometimes call from home and sometimes call from the office. The same database record should be used in both cases. Calls generated from a switch will probably have more than one ANI
Specialized applications December 2008 105 ASAI applications
assignment. This is based on the different trunk groups used to generate the call and the fact that individual trunk circuits sometimes carry different ANI identities. • You should allow for situations when ANI information is not delivered for a call. - In voice response applications, the voice application should provide some sort of default call handling for cases where no ANI is available. - In routing applications, the caller could be routed to an Avaya IR system so that additional information can be collected. - In data screen delivery applications, an agent can ask the caller for this information. • You might want to write an ANI learning module to automatically associate new ANI information with existing customer records. Agents and voice response applications can verify ANI information that is passed by the DEFINITY G3 switch to the Avaya IR system. • You should allow for situations where a single ANI is associated with multiple calling customers. More than one customer, for example, can call from the same switch. Examples of how to handle such situations include bringing up a menu from which the agent can choose the appropriate customer and switching to traditional methods for bringing up customer data. ASAI voice response application considerations Voice response applications can make use of direct agent calling. Calls can be transferred to specific agents within ACD splits after being serviced by a voice response application. In this case, your database must maintain the ACD split extensions that agents are logged into as well as the extensions for the agents themselves. Routing application considerations Unlike data screen delivery applications, routing applications make use of the host application in an inquiry and response fashion. This implies that the addition of a Avaya IR ASAI routing application to your call center may have little or no impact on the high-level operation of the application. The most significant change to the host application will probably be the information stored in the database. Information as to how calls should be routed must be added to the database if it is not already present. An example is ANI-to-agent and/or ACD split mappings. If feasible, consider using a local Avaya IR system database to store routing information. Routing applications can make use of direct-agent calling. Calls can be routed to specific agents within ACD splits. In this case, your database must maintain the ACD split extensions that agents are logged into as well as the extensions for the agents themselves. Data screen delivery application considerations Prior to the use of data screen delivery applications, a host application typically waits for input from agents before it performs an operation. Thus, the agent's input generally controls the application. With data screen delivery applications, a new input to the application is provided. While this input enables agents to work more quickly, it means that the host application must be modified. In particular, the host must use the call events provided by a monitoring application on the Avaya IR system to drive the screens on the agents' terminals. The interface to the system serves as a control link while the interface to the agent operates traditionally as an
106 Specialized applications December 2008 Host application planning and design
inquiry and response link. The interactions between these two properties of the application must be considered carefully. Suppose, for example, that a call arrives for an agent before that agent is finished entering data from the previous call. This scenario can be handled in one of the following ways: • Agents can be trained to use Aux Work or After Call Work feature buttons on their telephones to make themselves unavailable for calls until they are finished entering data from the previous call. • There is typically a point in the application's sequence of operations (for example, base transaction screen) where the agent is waiting for a new call and begins interaction with the application. The application could look for information from the Avaya IR system only at this point. The agent's telephone will alert the agent to the new call, and the agent can quickly finish work on the previous call. You may want to provide a quick way for the agent to move to this place in the interactions with the application. In data screen delivery applications, telephone extensions are used to identify agents who are receiving calls. The host application must therefore be able to associate extensions with particular data terminals. The following are possible ways to do this: • The agent can be queried for the telephone extension when the application is started. This is the most flexible arrangement and handles the situation where data terminals and terminal IDs are not permanently associated with the same telephone. Agents do make mistakes in providing the telephone extension to the system. You should plan for these occasional mistakes and make sure that agents understand how to use the system properly. Discuss this issue with the person responsible for the company's agent operations. • If an agent is always assigned to the same work position and hence, to the same extension, the extension information could be added to an agent profile. • If the relationship between data terminals, terminal IDs, and telephones is relatively stable, administration of the host application can maintain a fixed mapping between telephones and terminals. The agent screen application should be able to operate even if the Avaya IR system is not delivering call events. If call information is not being delivered, the appropriate person or the application itself should notify agents that there is a problem and that they should operate in manual mode. The DEFINITY G3 switch continues to deliver calls to agents even if the ASAI link to the Avaya IR system is down. Your application should be able to accommodate cases where multiple CONNECT events are received for the same call. This can occur, for example, where direct-agent calling is used. A call might first ring at the initial agent's telephone and then at the telephone of a covering agent if the call is not answered by the initial agent. In this case, two CONNECT events are sent to a monitoring application when CONNECT events are triggered on an ASAI-alerting event report. Your application should be able to accommodate cases where the connected party identified in call events is not a known ACD agent. Depending on switch administration and the design of call vectors, calls can be redirected to domains (VDNs or ACD splits) other than the domain to which the call is originally offered. If calls cover or are redirected from a live-agent split to an AUDIX split, for example, call events can identify an AUDIX channel extension as the connected party.
Specialized applications December 2008 107 ASAI applications
Call flow examples
The topics in this section provide the following examples of data screen delivery call flows and the contents of the call events that result from these call flows: • Call to agent via ACD split • Call to agent via VDNs with call prompting • Call to VDN and abandoned in queue • Call to VDN and abandoned after agent selection • Agent-to-agent transfer via VDN and blind transfer • Agent-to-agent transfer to a station via blind transfer • Agent-to-agent transfer via VDN and consult transfer • Agent-to-agent transfer to a station via consult transfer • Avaya IR system-to-agent transfer via an ACD split In all call-flow scenarios, it is assumed that CONNECT events are triggered on ASAI alerting event reports. Hence, as shown in the scenarios, a CONNECT event is passed to a monitoring application when an agent is selected for a monitored call. An agent is considered to be selected for a call when the agent's telephone begins ringing or the agent hears a zip tone. CONNECT events can also be triggered on ASAI connected event reports. In this case, CONNECT events are passed to monitoring applications when agents actually answer monitored calls. In all call-flow scenarios, it is assumed that the incoming call is delivered via an ISDN facility. This implies that the ANI is available in the ISDN SETUP message for the incoming call. If ANI is available, it is reported in call events as depicted in the call-flow scenarios. If ANI is not available, the incoming trunk group ID is reported instead. Also, since it is assumed that incoming calls are delivered via an ISDN facility, a 10-digit called party number (CPN) is reported in call events. This number corresponds to the CPN that is provided in the ISDN SETUP message for the incoming call. Note that, as depicted in the call- flow scenarios, this number identifies a billing number and not the 800 number that is dialed by the caller. The use of switch administration to modify DNIS digits does not affect the reporting of the CPN for incoming ISDN calls. Incoming calls can also be delivered via non-ISDN facilities. In this case, ANI is not available, so the trunk group ID is always reported instead. Also, for non-ISDN calls, the CPN identifies the ACD split or VDN extension to which the call is initially directed. Hence, for non-ISDN calls, the use of switch administration to modify DNIS digits can affect the reporting of the CPN. If modified by switch administration, the DNIS digits, as provided by the network, are not reported
108 Specialized applications December 2008 Call flow examples
in the CPN. Rather, the ACD split or VDN extension that results from the modification is provided in the CPN. For agent-to-agent transfer calls. Note that the call events generated for agent-to-agent conference calls are the same as described in the transfer scenarios. The three functional differences for conference calls are: • The screening agent uses the Conference button instead of the Transfer button. • The screening agent stays on the call instead of being dropped off. • The END event for the call is not generated until all parties disconnect from the call.
Call to an agent via an ACD split
A call arrives at the DEFINITY G3 switch and is delivered directly to a monitored ACD split (no vector processing takes place for the call). An agent is assigned to the call, interacts with the caller, and then terminates the call. Example:
1. A caller calling from the telephone number 303-555-1726 calls a toll-free 800 number that is associated with customer service. Calls to that 800 number are presented to a monitored ACD split with the extension 7777. 2. The call is queued to the monitored ACD split 7777. 3. The call is assigned to an agent in that split with the extension 1234. 4. A CONNECT event is passed to the monitoring application for ACD split 7777 with the following information:
Connected Party Number 1234
Calling Party Number 3035551726
Called Party Number 9085557777
Switch Data
Call Id 101
Other Call Id
LAI Display Info
VIS Data
Routing ID
Ucid
Uui
Specialized applications December 2008 109 ASAI applications
Ani II Digits
Redirecting Number
Return Field C
5. When the selected agent completes and disconnects the call, an END event is passed to the monitoring application for ACD split 7777 with the following information:
Connected Party Number 1234
Calling Party Number 3035551726
Called Party Number 9085557777
Switch Data
Trunk Group Id
Call Id 101
Other Call Id
LAI Display Info
VIS Data
Routing ID
Ucid
Uui
Ani II Digits
Redirecting Number
Return Field E
Call to an agent via VDNs with Call Prompting
A call arrives at the DEFINITY G3 switch and is handled with call vectoring. The initial VDN or vector that processes the call makes use of the call-prompting feature on the DEFINITY G3 switch to collect information from the caller. In particular, the caller is asked to request a service, for example, "press 1 for gizmo service or press 2 for widget service." The call is then routed unconditionally to a second VDN that is monitored. The vector that is associated with the second VDN queues the call to an ACD split. Agents in this split can handle service calls for both products. The call-prompting information that is collected on the DEFINITY G3 switch can
110 Specialized applications December 2008 Call flow examples
be used to determine which application to start up when the call is delivered to an agent in the common agent group. This allows a single 800 number to be advertised for both products. Example:
1. A caller calling from the telephone number 303-555-1726 calls a toll-free 800 number that is associated with customer service. Calls to that 800 number are initially handled with a vector that is associated with VDN 7771. VDN 7771 is not monitored. This vector prompts the user to enter a 1 or 2 and then routes the call to VDN 7772 with a "route to" step. In this example, it is assumed that the caller inputs a 1. 2. The call is routed to the monitored VDN 7772. The vector that is associated with VDN 7772 queues the call to an ACD split with a "queue to" step. 3. The call is assigned to an agent in the split with the extension 1234. 4. A CONNECT event is passed to the monitoring application for VDN 7772 with the following information:
Connected Party Number 1234
Calling Party Number 3035551726
Called Party Number 9085557771
Switch Data 1
Trunk Group Id
Call Id 101
Other Call Id
LAI Display Info
VIS Data
Routing ID
Ucid
Uui
Ani II Digits
Redirecting Number
Return Field C
5. When the selected agent completes and disconnects the call, an END event is passed to the monitoring application for VDN 7772 with the following information:
Connected Party Number 1234
Calling Party Number 3035551726
Specialized applications December 2008 111 ASAI applications
Called Party Number 9085557771
Switch Data 1
Trunk Group Id
Call Id 101
Other Call Id
LAI Display Info
VIS Data
Routing ID
Ucid
Uui
Ani II Digits
Redirecting Number
Return Field E
Call to a VDN and abandoned in queue
A call arrives at the DEFINITY G3 switch and is handled with a VDN or vector. The vector queues the call to an ACD split. The caller abandons the call while it is in the queue and before it is assigned to an agent. Example:
1. A caller calling from the telephone number 303-555-1726 calls a toll-free 800 number that is associated with customer service. Calls to that 800 number are processed by a vector that is associated with VDN 7771. VDN 7771 is monitored. 2. The vector that is associated with VDN 7771 queues the call to a vector- controlled split with a "queue to" step. 3. The caller abandons the call before an agent is assigned to the call. 4. An ABANDON event is passed to the monitoring application for VDN 7771 with the following information:
Connected Party Number
Calling Party Number 3035551726
Called Party Number 9085557771
Switch Data
112 Specialized applications December 2008 Call flow examples
Trunk Group Id
Call Id 101
Other Call Id
LAI Display Info
VIS Data
Routing ID
Ucid
Uui
Ani II Digits
Redirecting Number
Return Field A
Call to a VDN and abandoned after agent selection
A call arrives at the DEFINITY G3 switch and is handled with a VDN or vector. The vector queues the call to an ACD split. The caller abandons the call after is was assigned to an agent but before the agent could answer it. Example:
1. A caller calling from the telephone number 303-555-1726 calls a toll-free 800 number that is associated with customer service. Calls to that 800 number are processed by a vector that is associated with VDN 7771. VDN 7771 is monitored. 2. The vector that is associated with VDN 7771 queues the call to an ACD split with a "queue to" step. 3. An agent at extension 1234 is selected for the call. 4. The caller abandons the call before the agent at extension 1234 can answer. 5. An ABANDON event is passed to the monitoring application for VDN 7771 with the following information:
Connected Party Number 1234
Calling Party Number 3035551726
Called Party Number 9085557771
Switch Data
Trunk Group Id
Specialized applications December 2008 113 ASAI applications
Call Id 101
Other Call Id
LAI Display Info
VIS Data
Routing ID
Ucid
Uui
Ani II Digits
Redirecting Number
Return Field A
Note that this is different from the previous scenario where the caller abandons the call while in the queue. Since an agent was selected for the call before it was abandoned, a CONNECT event is passed to the monitoring application. In the previous case where the caller abandons the call while it is in the queue, no agent was selected for the call; therefore, no CONNECT event is passed to the monitoring application before the ABANDON event. In this scenario, where the caller abandons the call after agent selection, the ABANDON event contains the extension of the agent who was selected for the call. This information can be used to cancel the CONNECT event for the call to the agent since the call terminates before the agent can interact with the caller. Alternatively, the host application could simply let the next CONNECT event for the same agent "overwrite" the previous CONNECT event for the call that was abandoned. The next CONNECT event comes when the next call is delivered to the agent. Note also that this scenario only applies when CONNECT events are triggered on ASAI alerting event reports. If CONNECT events are triggered on ASAI CONNECT event reports, CONNECT events are passed to monitoring applications only when agents actually answer calls. Consequently, for cases where CONNECT events are triggered on ASAI CONNECT event reports, only an abandon while in the queue situation is possible. An abandon after agent selection situation will never occur or be reported.
Agent-to-agent transfer via a VDN and blind transfer
A call is delivered to an agent within a screening split. The screening agent transfers the call using a blind transfer to a group of specialized agents. A delay is built into the transfer by having the screening agent place the transfer call to a VDN. The vector associated with this VDN
114 Specialized applications December 2008 Call flow examples
queues the call to the specialized agent group after delaying the call. This delay allows the transfer to be completed before the transfer call is delivered to a specialized agent. Example
1. A caller calling from the telephone number 303-555-1726 calls a toll-free 800 number that is associated with customer service. Calls to that 800 number are processed with a vector that is associated with VDN 7771. VDN 7771 is monitored. 2. The vector that is associated with VDN 7771 queues the call to the split of screening agents. 3. The call is assigned to an agent in the screening split with the extension 1234. 4. A CONNECT event is passed to the monitoring application for VDN 7771 with the following information:
Connected Party Number 1234
Calling Party Number 3035551726
Called Party Number 9085557771
Switch Data
Trunk Group Id
Call Id 101
Other Call Id
LAI Display Info
VIS Data
Routing ID
Ucid
Uui
Ani II Digits
Redirecting Number
Return Field C
5. The screening agent talks with the caller and determines that a transfer is necessary. 6. The screening agent at extension 1234 presses the Transfer button and dials 7770, which is the extension of a monitored VDN. 7. The vector associated with VDN 7770 delays the call placed by the agent at extension 1234 for 2 seconds with a "wait" step.
Specialized applications December 2008 115 ASAI applications
8. The screening agent at extension 1234 then presses the Transfer button again. This merges the two calls at the screening agent's telephone and drops the screening agent from the resultant call. Note that no END event is reported at this time. 9. The vector associated with VDN 7770 queues the resultant call to the group of specialized agents with a "queue to" step. 10. A specialized agent at extension 4681 is selected for the transferred call. 11. A CONNECT event is passed to the monitoring application for VDN 7770 with the following information:
Connected Party Number 4681
Calling Party Number 3035551726
Called Party Number 9085557771
Switch Data
Trunk Group Id
Call Id 105
Other Call Id 101
LAI Display Info
VIS Data
Routing ID
Ucid
Uui
Ani II Digits
Redirecting Number
Return Field C
12. The specialized agent at 4681 completes the call and disconnects. 13. An END event is passed to the monitoring application for VDN 7770 with the following information:
Connected Party Number 4681
Calling Party Number 3035551726
Called Party Number 9085557771
Switch Data
Trunk Group Id
116 Specialized applications December 2008 Call flow examples
Call Id 105
Other Call Id 101
LAI Display Info
VIS Data
Routing ID
Ucid
Uui
Ani II Digits
Redirecting Number
Return Field E
Note that for blind transfers to monitored domains as described in this scenario, the second CONNECT event identifies the original call in the Other Call Id field. Note also that this CONNECT event contains ASAI information that pertains to the original call, for example, original ANI and DNIS in the Calling Party Number and Called Party Number fields, respectively. Any LAI display information, VIS data, or switch data associated with the original call is also carried forward.
Agent-to-agent transfer to a station via blind transfer
A call is delivered to an agent within a screening split. The screening agent transfers the call using blind transfer to a specialized agent at an individual station. Example
1. A caller calling from the telephone number 303-555-1726 calls a toll-free 800 number that is associated with customer service. Calls to that 800 number are processed with a vector that is associated with VDN 7771. VDN 7771 is monitored. 2. The vector that is associated with VDN 7771 queues the call to the split of screening agents. 3. The call is assigned to an agent in the screening split with the extension 1234. 4. A CONNECT event is passed to the monitoring application for VDN 7771 with the following information:
Connected Party Number 1234
Calling Party Number 3035551726
Called Party Number 9085557771
Switch Data
Specialized applications December 2008 117 ASAI applications
Trunk Group Id
Call Id 101
Other Call Id
LAI Display Info
VIS Data
Routing ID
Ucid
Uui
Ani II Digits
Redirecting Number
Return Field C
5. The screening agent talks with the caller and determines that a transfer is necessary. 6. The screening agent at extension 1234 presses the Transfer button and dials 2022. Extension 2022 identifies an individual station that is associated with a single, specialized agent. 7. The call initiated by the agent at extension 1234 begins ringing at station 2022. Note that no CONNECT event is reported for this call at this time since the Avaya IR system is not yet monitoring this call. 8. The screening agent at extension 1234 then presses the Transfer button again. This merges the two calls at the screening agent's telephone and drops the screening agent from the resultant call. Note that no END event is reported at this time. 9. A CONNECT event is passed to the monitoring application for VDN 7771 with the following information:
Connected Party Number 2022
Calling Party Number 3035551726
Called Party Number 9085557771
Switch Data
Trunk Group Id
Call Id 105
Other Call Id 101
LAI Display Info
VIS Data
118 Specialized applications December 2008 Call flow examples
Routing ID
Ucid
Uui
Ani II Digits
Redirecting Number
Return Field C
Note that this CONNECT event for blind transfers to stations is not passed to a monitoring application until the screening agent completes the transfer by pressing the Transfer button a second time. 10. The specialized agent at 2022 answers the transferred call and begins interacting with the original caller. 11. The specialized agent at 2022 completes the call and disconnects. 12. An END event is passed to the monitoring application for VDN 7771 with the following information:
Connected Party Number 2022
Calling Party Number 3035551726
Called Party Number 9085557771
Switch Data
Trunk Group Id
Call Id 105
Other Call Id 101
LAI Display Info
VIS Data
Routing ID
Ucid
Uui
Ani II Digits
Redirecting Number
Return Field E
Note that for blind transfers to stations as described in this scenario, the second CONNECT event identifies the original call in the Other Call Id field. Note also that this CONNECT event contains ASAI information that pertains to the original call, for example, original ANI and DNIS in the Calling Party Number and Called Party Number fields, respectively. Any LAI display
Specialized applications December 2008 119 ASAI applications
information, VIS data, or switch data that is associated with the original call is also carried forward.
Agent-to-agent transfer via a VDN and consult transfer
A call is delivered to an agent within a screening split. The screening agent transfers the call using consult transfer to a group of specialized agents. Example
1. A caller calling from the telephone number 303-555-1726 calls a toll-free 800 number that is associated with customer service. Calls to that 800 number are processed with a vector that is associated with VDN 7771. VDN 7771 is monitored. 2. The vector that is associated with VDN 7771 queues the call to the split of screening agents. 3. The call is assigned to an agent in the screening split with the extension 1234. 4. A CONNECT event is passed to the monitoring application for VDN 7771 with the following information:
Connected Party Number 1234
Calling Party Number 3035551726
Called Party Number 9085557771
Switch Data
Trunk Group Id
Call Id 101
Other Call Id
LAI Display Info
VIS Data
Routing ID
Ucid
Uui
Ani II Digits
Redirecting Number
Return Field C
5. The screening agent talks with the caller and determines that a transfer is necessary.
120 Specialized applications December 2008 Call flow examples
6. The screening agent at extension 1234 presses the Transfer button and dials 7772, which is the extension of a monitored VDN. 7. The vector associated with VDN 7772 queues the call to the group of specialized agents. 8. A specialized agent at extension 4440 is selected for the call that was placed by the agent at extension 1234. 9. A CONNECT event is passed to the monitoring application for VDN 7772 with the following information:
Connected Party Number 4440
Calling Party Number 1234
Called Party Number 7772
Switch Data
Trunk Group Id
Call Id 105
Other Call Id
LAI Display Info
VIS Data
Routing ID
Ucid
Uui
Ani II Digits
Redirecting Number
Return Field C
10. The screening agent and the specialized agent talk privately while the original caller is on hold. 11. The screening agent at extension 1234 then presses the Transfer button again. This merges the two calls at the screening agent's telephone and drops the screening agent from the resultant call. The original caller is now connected to the specialized agent at extension 4440. Note that no END event is reported at this time. 12. The specialized agent at extension 4440 interacts with the original caller. 13. The specialized agent at 4440 completes the call and disconnects. 14. An END event is passed to the monitoring application for VDN 7772 with the following information:
Connected Party Number 4440
Specialized applications December 2008 121 ASAI applications
Calling Party Number 3035551726
Called Party Number 9085557771
Switch Data
Trunk Group Id
Call Id 105
Other Call Id 101
LAI Display Info
VIS Data
Routing ID
Ucid
Uui
Ani II Digits
Redirecting Number
Return Field E
Note that for consult transfers to monitored domains as described in this scenario, the second CONNECT event does not identify the original call in the Other Call Id field. Note also that this CONNECT event does not contain ASAI information that pertains to the original call. Only call events passed to a monitoring application after the transfer is completed contain this information, for example, the END event or a CONNECT event for a subsequent blind transfer. Any LAI display information, Avaya IR system data, or switch data that is associated with the original call is also carried forward and reported in call events that are reported after the transfer is complete.
Agent-to-agent transfer to a station via a consult transfer
A call is delivered to an agent within a screening split. The screening agent transfers the call using consult transfer to a specialized agent at an individual station. Example
1. A caller calling from the telephone number 303-555-1726 calls a toll-free 800 number that is associated with customer service. Calls to that 800 number are processed with a vector that is associated with VDN 7771. VDN 7771 is monitored. 2. The vector that is associated with VDN 7771 queues the call to the split of screening agents. 3. The call is assigned to an agent in the screening split with the extension 1234. 4. A CONNECT event is passed to the monitoring application for VDN 7771 with the following information:
122 Specialized applications December 2008 Call flow examples
Connected Party Number 1234
Calling Party Number 3035551726
Called Party Number 9085557771
Switch Data
Trunk Group Id
Call Id 101
Other Call Id
LAI Display Info
VIS Data
Routing ID
Ucid
Uui
Ani II Digits
Redirecting Number
Return Field C
5. The screening agent talks with the caller and determines that a transfer is necessary. 6. The screening agent at extension 1234 presses the Transfer button and dials 2022. Extension 2022 identifies an individual station that is associated with a single, specialized agent. 7. The second call that was initiated by the agent at extension 1234 begins ringing at station 2022. Note that no CONNECT event is reported for this call at this time since the Avaya IR system is not yet monitoring this call. 8. The specialized agent at extension 2022 answers the call from the screening agent at extension 1234. 9. The screening agent and the specialized agent talk privately while the original caller is on hold. 10. The screening agent at extension 1234 then presses the Transfer button again. This merges the two calls at the screening agent's telephone and drops the screening agent from the resultant call. The original caller is now connected to the specialized agent at extension 2022. Note that no END event is reported at this time. 11. A CONNECT event is passed to the monitoring application for VDN 7771 with the following information:
Connected Party Number 2022
Specialized applications December 2008 123 ASAI applications
Calling Party Number 3035551726
Called Party Number 9085557771
Switch Data
Trunk Group Id
Call Id 105
Other Call Id 101
LAI Display Info
VIS Data
Routing ID
Ucid
Uui
Ani II Digits
Redirecting Number
Return Field C
Note that this CONNECT event for consult transfers to stations is not passed to a monitoring application until the screening agent completes the transfer by pressing the Transfer button a second time. 12. The specialized agent at 2022 interacts with the original caller. 13. The specialized agent at 2022 completes the call and disconnects. 14. An END event is passed to the monitoring application for VDN 7771 with the following information:
Connected Party Number 2022
Calling Party Number 3035551726
Called Party Number 9085557771
Switch Data
Trunk Group Id
Call Id 105
Other Call Id 101
LAI Display Info
VIS Data
124 Specialized applications December 2008 Call flow examples
Routing ID
Ucid
Uui
Ani II Digits
Redirecting Number
Return Field E
Note that for consult transfers to stations as described in this scenario, the second CONNECT event identifies the original call in the Other Call Id field. Note also that this CONNECT event contains ASAI information that pertains to the original call, for example, original ANI and DNIS in the Calling Party Number and Called Party Number fields, respectively. Any LAI display information, Avaya IR system data, or switch data that is associated with the original call is also carried forward.
Avaya IR system-to-agent transfer via an ACD split
A call is delivered to a Avaya IR system telephony channel and serviced by an ASAI voice response application. An account number is collected in the voice application in preparation for a data screen delivery application based on this account number. The call is then transferred to a live agent group. Example:
1. A caller calling from the telephone number 303-555-1726 calls a toll-free 800 number that is associated with customer service. Calls to that 800 number are processed with a vector that is associated with VDN 7771. VDN 7771 is not monitored. 2. The vector that is associated with VDN 7771 routes the call to the Avaya IR system split with a "route to" step. Note that this split is monitored, but not by a monitoring application used to retrieve call events. This split is monitored internally by the Avaya IR system to support ASAI voice response applications that make use of the A_Callinfo and A_Tran external functions. 3. The call is answered by a telephony channel and serviced by a voice response application. No CONNECT event is passed to a monitoring application for the call at this point. Assume, however, that this call is assigned call ID 101. This call ID would be available within the voice application by using the A_Callinfo external function. 4. The voice application collects an account number from the caller. In this example, it is assumed that the account number is 987654321. 5. The A_Tran external function is used within the voice application to transfer the call to the monitored ACD split 7777. The Destination Number field of A_Tran is set to 7777 and the Avaya IR system Data field of A_Tran is set to 987654321. 6. When the transfer is executed, the voice application terminates. This allows the telephony channel to service additional calls.
Specialized applications December 2008 125 ASAI applications
7. The call queues to the monitored ACD split 7777. 8. An agent at extension 1234 within ACD split 7777 is selected for the call. 9. A CONNECT event is passed to the monitoring application for ACD split 7777 with the following information:
Connected Party Number 1234
Calling Party Number 3035551726
Called Party Number 9085557771
Switch Data
Trunk Group Id
Call Id 105
Other Call Id 101
LAI Display Info
VIS Data 987654321
Routing ID
Ucid
Uui
Ani II Digits
Redirecting Number
Return Field C
10. The agent at extension 1234 answers the call and interacts with the caller. 11. The agent at extension 1234 completes the call and disconnects. 12. An END event is passed to the monitoring application for ACD split 7777 with the following information:
Connected Party Number 1234
Calling Party Number 3035551726
Called Party Number 9085557771
Switch Data
Trunk Group Id
Call Id 105
Other Call Id 101
126 Specialized applications December 2008 Call flow examples
LAI Display Info
VIS Data 987654321
Routing ID
Ucid
Uui
Ani II Digits
Redirecting Number
Return Field E
Note that for Avaya IR system-to-agent transfers as described in this scenario, only one CONNECT event is reported to a monitoring application. This CONNECT event is reported when a live agent answers the transferred call. Not also that this CONNECT event contains data in the Avaya IR system Data field if such data was saved in the voice application by the use of the A_Tran external function. The CONNECT event also identifies the original call in the Other Call Id field and contains ASAI information that pertains to the original call, for example, original ANI and DNIS in the Calling Party Number and Called Party Number fields, respectively. Any LAI display information or switch data that is associated with the original call is also carried forward. Note that the call can also be transferred from the Avaya IR system to a nonmonitored domain or individual station. In this case, the call events are the same as those described in this scenario. The call events, however, are passed to a CTL-type of monitoring application instead of a VDN-type or ACD-split-type of monitoring application. Also, A_Tran must be used to ensure that the CTL-type monitoring application receives the call events for the transferred call.
Specialized applications December 2008 127 ASAI applications
128 Specialized applications December 2008 Chapter 3: CTI applications
You must invoke CTI Computer Telephony Integration external functions to either change the state of a call or to move information about a call. The following external functions are available for application development using IVR Designer: • ctiCallInfo • ctiCallState • ctiConfer • ctiDial • ctiDiscon • ctiHold • ctiNotify • ctiPrivData • ctiRetrieve • ctiTransfer See the appropriate topic for details about a particular external function. For more information on applications that integrate with Avaya Interaction Center, see Avaya Interaction Center applications on page 139. ctiCallInfo Description The ctiCallInfo external function provides the call ID, ANI, called number, and Avaya IR port extension associated with an active call at the Avaya IR. Output
• Call ID – Variable where the call ID will be stored. (Type: num) • ANI – Variable where the ANI of the call will be stored. (Type: char, Size: 16) • Called Number – Variable where the Called Number or DNIS will be stored. (Type: char, Size: 16)
Specialized applications December 2008 129 CTI applications
• Station Extension – Variable where the Avaya IR Port extension will be populated. (Type: char, Size: 7) • Skill – Variable where the skill/split hunt-group number will be stored. (Type: char, Size: 7) Return values The return code indicates whether the CTI DIP can find any call present at the Avaya IR port. If successful, the result is > 0. On failure, the result is <=0. Usage notes The ctiCallInfo function is often the first external function that is called in an application. It identifies the call ID of the call that has reached the Avaya IR. This is useful for any controlling function that might be used later in the application, such as placing the call on hold (ctiHold). It also identifies the number that was dialed by the caller. If the call was inbound from an ISDN trunk group, it also identifies the DNIS associated with the call. This feature is most useful in applications that dynamically assign a Avaya IR application on DNIS. If there is more than one call present at a Avaya IR port, ctiCallInfo reports the latest call. For example, if one call is on hold while another call is active, ctiCallInfo reports only on the most recent call to arrive at the Avaya IR port, regardless of whether this call is on hold or not. ctiCallState Description ctiCallState provides the state of all the calls present at the Avaya IR port extension. Output
• Call ID of Call #2 - Variable where the call ID of call #2 will be populated. (Type: num) • Call ID of Call #3 - Variable where the call ID of call #3 will be populated. (Type: num) • State of Call #1 - Variable where the state of call #1 will be populated. See "Usage notes" (Type: num) • State of Call #2 - Variable where the state of call #2 will be populated. See "Usage notes" (Type: num) • State of Call #3 - Variable where the state of call #3 will be populated. See "Usage notes"
130 Specialized applications December 2008 ctiConfer
(Type: num) Return values The return code indicates whether the CTI DIP can find a call present at the Avaya IR port. If successful, the result is the call ID of call #1. On failure, the result is -1. Usage notes An Avaya IR port can support up to 3 simultaneous calls. This external function can be used to determine the call ID and associated state (ALERTING, HELD, ESTABLISHED) of the calls present at the port. The states are represented by the following values:
Value State
0 None
1 Delivered
2 Established
3 Held
4 Conferenced
5 Transferred
6 Initiated
7 Originated
Note: The ordering of the calls is determined by the arrival order. Call #1 is most likely the first call received by the Avaya IR. ctiConfer Description ctiConfer requests that two calls present at an Avaya IR port be conferenced together. Input
• Call ID of held call - Call ID of held call. (Type: num) • Call ID of active call - Call ID of active call.
Specialized applications December 2008 131 CTI applications
(Type: num) Return values The return code indicates whether the two calls were conferenced. If successful, the result is >0. On failure, the result is <=0. Usage notes ctiConfer requires one of the calls involved in the transfer be on hold at the Avaya IR port prior to execution. ctiDial Description ctiDial requests a call be placed from the Avaya IR port to a destination. Input
• Phone number - The destination number to be dialed. (Type: char, Size: 64) • User-user-information - Up to 96 bytes of user-provided data. (Type: char, Size: 96) Return values The return code indicates whether the call was successfully placed. If successful, the result is >0. On failure, the result is <=0. ctiDiscon Description ctiDiscon requests a call be placed from the Avaya IR port to disconnect a call. Input
Call ID - The call ID to be disconnected. (Type: num) Return values The return code indicates whether the call was successfully disconnected.
132 Specialized applications December 2008 ctiHold
If successful, the result is >0. On failure, the result is <=0. Usage notes ctiDiscon is best used in conjunction with the ctiCallState function to determine the state of a call before it is disconnected. Also, the Avaya IR port itself will not detect any dial tone on the line after the call is disconnected. If the application needs to terminate before the call is disconnected, it must explicitly do so after a successful return. ctiHold Description ctiHold requests that a call that is active at the Avaya IR port be placed on hold. Input
Call ID - The ID of the call to be placed on hold. (Type: num) Output
Error Code - Variable that is populated with an error code if the operation fails. (Type: num) Return values The return code indicates whether the call was successfully placed on hold. If successful, the result is >0. On failure, the result is <=0. Usage notes ctiHold is best used in conjunction with the ctiCallState function to determine the state of a call before it is placed on hold. If an error is encountered, the CTI DIP will populate the Error Code field. The value will be of type CSTA_Universal_Failure_t.
Specialized applications December 2008 133 CTI applications
ctiNotify Description ctiNotify provides answer notification to a voice application that has launched a call. Input None. Return values The return code indicates whether a tracked call has been answered. If successful, the result is the call ID of the established call, which means that the tracked call is answered. On failure, the result is -1, which means that the CTI DIP found no call at the Avaya IR port to track. Usage notes ctiNotify is most useful in outbound calling when used in conjunction with ctiDial. The function is solely dependent on receiving answer supervision on a timely basis from the network. Therefore, if the call is sent over a non-ISDN trunk to a destination, the function may return several seconds after the call is actually connected. When the ctiNotify request is made, a message is sent to the CTI DIP. The CTI DIP checks the status of the calls that are currently at the Avaya IR port. If a call is found to be either in the DELIVERED or ORIGINATED state, the CTI DIP: • Tags this call to receive answer notification. • Tracks the call that has been tagged. • When the tracked call is answered, sends the call ID of the answered call to the application. If no call is currently in either the DELIVERED or ORIGINATED state, the CTI DIP returns a -1 to ctiNotify. If ctiNotify receives a -1, it tries up to three times to find a call at the Avaya IR port that is in either the DELIVERED or ORIGINATED state. There is a 500-millisecond pause between attempts.
134 Specialized applications December 2008 ctiPrivData
ctiPrivData Description ctiPrivData requests that any private data associated with the call at the Avaya IR port be provided. Currently this function supports User-to-User Information (UUI) and Universal Call ID (UCID). Output
Private Data - A buffer that the CTI DIP will populate with private data associated with a call. (Type: char, size: up to 96 characters) Input
• Type - A constant that represents the type of private data that is requested (Type: num) 0 = UUI 1 = II DIGITS (not currently implemented) 2 = UCID • Call ID - The call ID of the current call at the Avaya IR port. (Type: num) • Vendor - The PBX vendor (for example, Lucent). (Type: char, size: 32) Return values The return code indicates whether the CTI DIP successfully processed the message. If successful, the result is 1. On failure, the result is <=0, which indicates that no private data exists. Usage notes The information provided by this function is vendor specific. Currently, the only vendor private data that is implemented is per Lucent Technologies. Universal Call ID (UCID) requires DEFINITY 6.3 or later and CentreVu CT 3.10 Version 2.0 or later.
Specialized applications December 2008 135 CTI applications
ctiRetrieve Description ctiRetrieve requests that a held call at the Avaya IR port be retrieved. Input
Call ID - Call ID of the held call (Type: num) Output
Error Code - Variable where the error code from the CSTA_UNIVERSAL_FAILURE_CONF event will be populated (only if the operation fails) (Type: num) Return values The return code indicates whether the call was successfully retrieved. If successful, the result is > 0, which indicates that the CTI DIP received a CSTA_RETRIEVE_CALL_ CONF event. On failure, the result is <=0, which indicates that the call was not successfully retrieved. Usage notes This function is typically used only to recover from an error, for example, if the Avaya IR dials a busy number and the application needs to reconnect to the held party to inform them of the busy party. ctiTransfer Description ctiTransfer requests that two calls present at a Avaya IR port be connected. Input
• Call ID of held call - Call ID of held call (Type: num) • Call ID of active call - Call ID of active call (Type: num) Return values The return code indicates whether the transfer occurred.
136 Specialized applications December 2008 ctiTransfer
If successful, the result is >0, which indicates that the CTI DIP received a CSTA_TRANSFERRED_CALL_ CONF event. On failure, the result is <=0, which indicates that the transfer failed to occur. Usage notes ctiTransfer requires that one of the calls involved in the transfer be on hold at the Avaya IR port prior to the execution of this function.
Specialized applications December 2008 137 CTI applications
138 Specialized applications December 2008 Chapter 4: Avaya Interaction Center applications
The Avaya Computer Telephony DIP installed on the Avaya IR system provides a transparent interface to Avaya Computer Telephony on the Avaya Interaction Center. It is accessed through a single external function, named Vesp_dip. Applications invoke DIP functions to communicate with the VOX Server, the entry point into the Avaya Computer Telephony environment. The VOX Server, which can communicate with both environments, interprets these functions and provides all subsequent processing required to interact with Avaya Computer Telephony.
Overview of Vesp_dip
The Vesp_dip program interchanges data between the Avaya IR system and the VOX Server. The Vesp_dip program consists of the following files: • vesp_dip • vesp_dip.t • vesp_dip.h • vespdipi.h • trap.t • untrap.t The trap.t and untrap.t files are used only by Script Builder applications.
Rules for integrating with IC applications
There are a few rules you must follow to ensure proper communication between the Avaya IR system and the Avaya Computer Telephony software: • A caller might hang up at any time. The application must be prepared to handle this. Therefore, be sure to insert an asynchronous event at the very beginning of the
Specialized applications December 2008 139 Avaya Interaction Center applications
application. It must be the first node, placed even before the Answer Call node. You also need to add a call flow which runs if the caller hangs up. • As soon as the call is accepted by the application through the Answer Call node, the application must immediately invoke the newcall function. If it does not, the call is not handled properly and subsequent calls could be affected. • When the call ends, regardless of the reason, the application must immediately invoke the gone function of the DIP. If not, both that call and all subsequent calls on that line may be lost or otherwise improperly handled by the system. Do not handle new calls on that line until the gone function returns a response.
Using the Vesp_dip functions
Applications for the Avaya IR system are constructed using the IVR Designer tool. To insert an Avaya Computer Telephony command, add a Vesp_dip external function node. Then define the parameters in the node inspector. The node inspector requires you to enter the function name and 4 arguments to define the function. You must enter values in all five fields. Enter empty fields if there is no parameter associated with that argument. • The function name is always Vesp_dip. • The first argument parameter is always the name of one of the Vesp_dip functions. • The meanings of the other four arguments vary with each function.
Overview of Vesp_dip functions
The following table lists the Vesp_dip functions:
Function Description
+create Create a request.
+getarg Get the desired argument.
+send Send the assembled request.
+setarg Set the value of the specified argument.
newcall Notify Avaya Computer Telephony that a new call has arrived and ask for its EDUID.
pseudo_ani Return a pseudo_ANI to a network IVR.
140 Specialized applications December 2008 Creating requests to the VOX server
Function Description
getvdu Retrieve a single field value from the database via the call's EDU.
getvox Retrieve a single field value from the VOX Server's value cache.
setvdu Set or overwrite a single value in the telephone call's EDU.
tr
transfer The transfer function transfers a call from the VRU to an agent at the specified extension.
gone Notify Avaya Computer Telephony that a call has ended.
alarm Raise an Avaya Computer Telephony alarm, which is an indication of an exceptional condition or error.
For more information, see the appropriate function description, or refer to the Avaya Interaction Center Programmer's Guide.
Creating requests to the VOX server
It is possible to construct functions with more than four parameters. This is done in several steps. Up to 62 parameters can be added to a function (allowing for up to 30 names and values to be set or read in a request). Commands associated with creating and sending requests in steps begin with +, so they do not overlap with actual VOX command names. These commands are: • +create • +getarg • +send • +setarg Arguments in the constructed functions must be placed in positions in accordance with the definitions for the VOX Server commands. Replies to requests are preserved until the next +create command, or until any request not beginning with a + is used. It is permissible to use +getarg to read responses from commands that were not built with +create. Any request that does not begin with + uses the +create, +setarg and +getarg mechanism internally.
Specialized applications December 2008 141 Avaya Interaction Center applications
Note: The + commands should not be used to construct requests that cannot accept a variable number of arguments.
Vesp_dip
+create
The +create function creates a request.
Note: The +create function does not take effect until it is sent to the VOX Server by a +send function. Use the Node Inspector to assign and edit the following attributes.
Attribute Value Description
Put Return Code In Select the variable in which to store the return code.
VESP Function Name +create Creates a request.
Arg 1 Select the variable in which to store an allowed VOX Server command name ("VOX.setvdu", "VOX.getvdu", "VOX.getvox", "VOX.tr1XXX", or "VOX.tr2XXX"). The variable must have Length set to 34 and Type set to character.
Arg 2 Select the variable in which to store a string containing the total number of arguments. The variable must have Length set to 256 and Type set to character.
Arg 3 Select a Dummy variable. The variable must have
142 Specialized applications December 2008 Vesp_dip
Length set to 256 and Type set to character.
Arg 4 Select a Dummy variable. The variable must have Length set to 256 and Type set to character.
+getarg
The +getarg function gets the desired argument. The string value "0" (or empty) obtains any error string (exception) the VOX Server returns on the request. This will be an empty string if the Vesp_dip request did not return an error. The string is useful for debugging and logging; it is not intended that an Avaya IR application attempt to analyze it. An exception string from any Avaya Interaction Engine Server may be returned (especially the EDU, Telephony, Workflow, and VOX servers). Use the Node Inspector to assign and edit the following attributes.
Attribute Value Description
Put Return Code In Select the variable in which to store the return code.
VESP Function Name +getarg Gets the desired argument.
Arg 1 Select the variable in which to store a string representing the argument to be fetched ("0", "1", ..., "62"). The variable must have Length set to 34 and Type set to character.
Arg 2 Select the variable in which to store the result. The variable must have Length set to 256 and Type set to character.
Arg 3 Select a Dummy variable. The variable must have Length set to 256 and Type set to character.
Arg 4 Select a Dummy variable. The variable must have
Specialized applications December 2008 143 Avaya Interaction Center applications
Length set to 256 and Type set to character.
+send
The +send function sends the assembled request. This function does not return until the VOX Server has responded, or the request has timed out. The return code represents the VOX Server's reply. Use the Node Inspector to assign and edit the following attributes.
Attribute Value Description
Put Return Code In Select the variable in which to store the return code.
VESP Function Name +send Sends the assembled request.
Arg 1 Select a Dummy variable. The variable must have Length set to 34 and Type set to character.
Arg 2 Select a Dummy variable. The variable must have Length set to 256 and Type set to character.
Arg 3 Select a Dummy variable. The variable must have Length set to 256 and Type set to character.
Arg 4 Select a Dummy variable. The variable must have Length set to 256 and Type set to character.
+setarg
The +setarg function sets the value of the specified argument. Any arguments that are not specified are left blank.
144 Specialized applications December 2008 Vesp_dip
Note: The +setarg function does not take effect until it is sent to the VOX Server by a +send function. Use the Node Inspector to assign and edit the following attributes.
Attribute Value Description
Put Return Code In Select the variable in which to store the return code.
VESP Function Name +setarg Sets the value of the specified argument.
Arg 1 Select the variable in which to store a string indicating the argument you are setting ("1", "2", ..., "62"). The variable must have Length set to 34 and Type set to character.
Arg 2 Select the variable in which to store a string containing the value of the argument. The variable must have Length set to 256 and Type set to character.
Arg 3 Select a Dummy variable. The variable must have Length set to 256 and Type set to character.
Arg 4 Select a Dummy variable. The variable must have Length set to 256 and Type set to character.
Example The following example shows how to fetch two values (A and B) from the EDU.
+create "VOX.getvdu" "5" Create a 5 parameter request.
+setarg "1" Set the value of the EDUID. "2df5d9e6003b0000780002a1f4300 02"
Specialized applications December 2008 145 Avaya Interaction Center applications
+setarg "2" "A" Set the value of the second argument to A.
+setarg "4" "B" Skip argument 3, which is where A's result will go, and set the value of the fourth argument to B.
+send Send the request and wait for a response.
+getarg "3" valueA Get A's value.
+getarg "5" valueB Get B's value.
newcall
The newcall function notifies Avaya Computer Telephony when a call arrives, and asks Avaya Computer Telephony to pass back an EDUID for that call. The newcall function must be placed immediately after an Answer node.
Note: The EDUID identifies the call within Avaya Computer Telephony. It is unique to a particular call, and it is essential for all Avaya Computer Telephony requests. Use the Node Inspector to assign and edit the following attributes.
Attribute Value Description
Put Return Code In Select the variable in which to store the return code.
VESP Function Name newcall Notifies Avaya Computer Telephony that a new call arrived on the IVR.
Arg 1 Select the variable in which to store the EDUID received from Avaya Computer Telephony, which identifies the new call. The variable must have Length set to 34 and Type set to character.
Arg 2 Select a Dummy variable. The variable must have Length set to 256 and Type set to character.
146 Specialized applications December 2008 Vesp_dip
Arg 3 Select a Dummy variable. The variable must have Length set to 256 and Type set to character.
Arg 4 Select a Dummy variable. The variable must have Length set to 256 and Type set to character.
pseudo_ani
The pseudo_ani function should be used only with a network IVR, an IVR not associated with an Avaya Computer Telephony Server, to transfer a call to an Avaya Computer Telephony- enabled site. This function takes a pseudo-ANI from the list provided by the configuration parameter pseudo_ani, associates it with the given EDUID, and returns the pseudo-ANI in the response. For information about the pseudo-ANI and the VOX Server's interaction with a network IVR, see the VOX Server Programmer's Guide. Use the Node Inspector to assign and edit the following attributes.
Attribute Value Description
Put Return Code In Select the variable in which to store the return code.
VESP Function Name pseudo_ani Select the variable in which to store the returned pseudo-ANI.
Arg 1 Select the variable in which to store the EDUID, which is passed to Avaya Computer Telephony to identify the call. The variable must have Length set to 34 and Type set to character.
Arg 2 Select the variable that contains the pseudo-ANI associated with the call. The variable must have Length set to 256 and Type set to character.
Specialized applications December 2008 147 Avaya Interaction Center applications
Arg 3 Select a Dummy variable. The variable must have Length set to 256 and Type set to character.
Arg 4 Select a Dummy variable. The variable must have Length set to 256 and Type set to character.
getvdu
The getvdu function retrieves a single value from the call's EDU. For example, a customer's account information can be looked up in the database and stored in an EDU on the EDU Server. The EDU Server passes the requested information to the VOX Server, which in turn passes the value to the VRU. This function also updates the name/value pair stored in the VOX Server's value cache. For information about getvdu and the value cache, see the VOX Server Programmer's Guide.
Note: Always issue the getvdu function instead of getvox if there is any risk of other software running in parallel with your CONVERSANT or Avaya IR application; otherwise, pertinent EDU values may differ. Use the Node Inspector to assign and edit the following attributes.
Attribute Value Description
Put Return Code In Select the variable in which to store the return code.
VESP Function Name getvdu Gets a value from the EDU.
Arg 1 Select the variable in which to store the EDUID, which is passed to Avaya Computer Telephony to identify the call. The variable must have Length set to 34 and Type set to character.
Arg 2 Select the variable that contains the name of the database field to query. The variable must have
148 Specialized applications December 2008 Vesp_dip
Length set to 256 and Type set to character.
Arg 3 Select the variable in which to store the returned value of the database field; empty if the field does not exist. The variable must have Length set to 256 and Type set to character.
Arg 4 Select a Dummy variable. The variable must have Length set to 256 and Type set to character.
getvox
The getvox function retrieves a single value from the EDU's name/value pair stored in the VOX Server's value cache. Because getvox retrieves the information from the VOX Server's value cache rather than from the EDU Server, it results in faster response time and less network traffic than using getvdu. Use getvox only when you are certain that the cache holds the field's most recent value. This will always be the case if only the CONVERSANT or Avaya IR application can cause the EDU's value to change. For example, if a field can be set only by the tr2setaccnt function and not by any other Avaya Computer Telephony software, both the VOX Server cache and the EDU will contain the same field values. getvox is best suited for accessing stable information such as account numbers and ANI (Automatic Number Identification). For information about getvox and the value cache, see the VOX Server Programmer's Guide.
Note: Always issue the getvdu function instead of getvox if there is any risk of other software running in parallel with your CONVERSANT or Avaya IR application; otherwise, pertinent EDU values may differ. Use the Node Inspector to assign and edit the following attributes.
Attribute Value Description
Put Return Code In Select the variable in which to store the return code.
VESP Function Name getvox Gets a value from the VOX Server value cache.
Specialized applications December 2008 149 Avaya Interaction Center applications
Arg 1 Select the variable in which to store the EDUID, which is passed to Avaya Computer Telephony to identify the call. The variable must have Length set to 34 and Type set to character.
Arg 2 Select the variable that contains the name of the database field to query. The variable must have Length set to 256 and Type set to character.
Arg 3 Select the variable in which to store the returned value of the database field; empty if the field does not exist. The variable must have Length set to 256 and Type set to character.
Arg 4 Select a Dummy variable. The variable must have Length set to 256 and Type set to character.
setvdu
The setvdu function sets or overwrites a single value in the customer's account information. The VRU passes the name/value pair information to the VOX Server, which in turn passes it to the EDU Server. Use the Node Inspector to assign and edit the following attributes.
Attribute Value Description
Put Return Code In Select the variable in which to store the return code.
VESP Function Name setvdu Sets a value in the EDU.
Arg 1 Select the variable in which to store the EDUID, which is passed to Avaya Computer Telephony to
150 Specialized applications December 2008 Vesp_dip
identify the call. The variable must have Length set to 34 and Type set to character.
Arg 2 Select the variable that contains the name of the database field to overwrite. The variable must have Length set to 256 and Type set to character.
Arg 3 Select the variable that contains the new value of the field. The variable must have Length set to 256 and Type set to character.
Arg 4 Select a Dummy variable. The variable must have Length set to 256 and Type set to character.
tr
Transaction operation commands communicate with the Workflow Designer. Workflow Designer features are customized for each customer, either by Avaya or by the customer.
Note: Transaction operation commands are custom designed for your site. If desired, you could execute tr
Attribute Value Description
Put Return Code In Select the variable in which to store the return code.
VESP Function Name tr
Arg 1 Select the variable in which to store the EDUID, which is passed to Avaya Computer Telephony to
Specialized applications December 2008 151 Avaya Interaction Center applications
identify the call. The variable must have Length set to 34 and Type set to character.
Arg 2 Select the variable that contains the value of the database field. The variable must have Length set to 256 and Type set to character.
Arg 3 Select a Dummy variable. The variable must have Length set to 256 and Type set to character.
Arg 4 Select a Dummy variable. The variable must have Length set to 256 and Type set to character.
transfer
The transfer function transfers a call from the VRU to an agent at the specified extension. Transferring the call does not terminate the EDU. The CONVERSANT or Avaya IR application continues to access the EDU and cache until the gone function is called. Use the Node Inspector to assign and edit the following attributes.
Attribute Value Description
Put Return Code In Select the variable in which to store the return code.
VESP Function Name transfer Transfers the call to an agent.
Arg 1 Select the variable in which to store the EDUID, which is passed to Avaya Computer Telephony to identify the call. The variable must have Length set to 34 and Type set to character.
Arg 2 Select the variable that contains the PBX
152 Specialized applications December 2008 Vesp_dip
extension to which the call will be transferred. The variable must have Length set to 256 and Type set to character.
Arg 3 Select a Dummy variable. The variable must have Length set to 256 and Type set to character.
Arg 4 Select a Dummy variable. The variable must have Length set to 256 and Type set to character.
gone
The gone function notifies the Avaya Computer Telephony software that the call has ended, and releases the EDUID. The gone function must always be issued when a call ends.
Note: Be sure to issue the gone function before the application ends; if you do not, subsequent calls on the same channel could be lost or otherwise improperly handled. Use the Node Inspector to assign and edit the following attributes.
Attribute Value Description
Put Return Code In Select the variable in which to store the return code.
VESP Function Name gone Notifies Avaya Computer Telephony software that the call has ended.
Arg 1 Select the variable in which to store the EDUID, which is passed to Avaya Computer Telephony to identify the call. The variable must have Length set to 34 and Type set to character.
Arg 2 Select the variable that contains the reason for ending the call, or leave this argument blank. The
Specialized applications December 2008 153 Avaya Interaction Center applications
variable must have Length set to 256 and Type set to character.
Arg 3 Select a Dummy variable. The variable must have Length set to 256 and Type set to character.
Arg 4 Select a Dummy variable. The variable must have Length set to 256 and Type set to character.
alarm
The alarm function raises an Avaya Computer Telephony alarm through the VOX Server to indicate some exceptional condition or error. This function is useful for debugging. Use the Node Inspector to assign and edit the following attributes.
Attribute Value Description
Put Return Code In Select the variable in which to store the return code.
VESP Function Name alarm Raises an Avaya Computer Telephony alarm.
Arg 1 Select the variable that contains the alarm's name (one word). The variable must have Length set to 34 and Type set to character.
Arg 2 Select the variable that contains the alarm's priority code: Low, High, Info, or EMERGENCY. The variable must have Length set to 256 and Type set to character.
Arg 3 Select the variable that contains the text that describes the problem. The variable must have
154 Specialized applications December 2008 Vesp_dip
Length set to 256 and Type set to character.
Arg 4 Select a Dummy variable. The variable must have Length set to 256 and Type set to character.
Vesp_dip return codes
All Vesp_dip functions can return the following values.
Return Code Value Description
-100 ERROR_NO_VESP Avaya Computer Telephony is not available. The VOX Server is not connected to Vesp_dip. May indicate a network error that separates the VOX Server and Vesp_dip. May mean that the VOX Server was not started.
-101 ERROR_BAD_REQ The command is not known to the UEST Vesp_dip. Probably indicates a misspelled command in the CONVERSANT or Avaya IR application.
-102 ERROR_VESP_EXC Avaya Computer Telephony raised an EPTION exception on this request, this is, the request failed. The VOX Server log will have more information. May indicate the passing of an invalid (badly formatted or terminated) EDUID, or an attempt to use a workflow transaction improperly, or an error in a Contact Engine Server's configuration.
Creating custom variables
Many of the functions described in this section return information that should be stored in custom variables. For information about how to create a custom variable, see Creating new (custom) variables in the Avaya IVR Designer Help. Some function attributes require a Dummy variable. A Dummy variable is a custom variable with Length set to 256 and Type set to character. Use this variable only for external function
Specialized applications December 2008 155 Avaya Interaction Center applications
attributes that require a Dummy variable. Do not use the Dummy variable in any other part of the application. You can name the Dummy variable whatever you want. The name Dummy is used here as an example only.
156 Specialized applications December 2008 Chapter 5: Avaya Predictive Dialing System applications
Avaya PDS/IVR Integration overview The Avaya Predictive Dialing System (PDS) The Avaya Predictive Dialing System (PDS), also called the Dialer, makes outbound calls and, upon caller contact, connects the called party to an available agent for job-related activities. The Avaya IR system The Avaya IR system is an interactive voice response system (IVR) that allows for either full or partial automation of telephone transactions that would otherwise be performed by an operator or attendant. When an incoming call is connected to the system, the system prompts the caller with synthesized or prerecorded speech. The caller responds by entering touchtones or by speaking into the telephone. The dialog between the system and the caller is determined by the particular IVR Designer application. The Avaya PDS/IVR Integration software Avaya PDS/IVR Integration is software that integrates the functionality of the Avaya IR and the Dialer. PDS/IVR Integration provides a subset of PDS commands for the Avaya IR system, which allows the Avaya IR to act as agents attached to the Dialer. These commands can be used as external functions in IVR Designer applications to add outbound functionality to the Avaya IR system. This integration allows the PDS to make an outbound call and pass that voice and data to the Avaya IR. The Avaya IR then processes that call as it would any other inbound call. The flexibility of the Avaya IR allows the IVR Designer application to provide a high level of complexity to the subsequent caller interaction. When the call is complete, certain information related to the call is passed back to the PDS so the record in the calling list is updated. The following figure shows how the Dialer and Avaya IR are physically configured with other system components, such as a PBX, to provide the PDS/IVR Integration functionality.
Specialized applications December 2008 157 Avaya Predictive Dialing System applications
IVR/PDS interface processes
The Dialer and the Avaya IR communicate with each other on an administrative level through a socket connection between a process on each machine. On the Avaya IR, dialer_conn acts as the server, and on the Dialer, ivr_conn acts as the client. Through this interface, initial connections are set up and administrative commands are processed. The Dialer and the Avaya IR also communicate with each other on an individual agent level through a socket connection between another process on each machine. On the Avaya IR, sim_agt acts as the client, and on the Dialer, agent acts as the server. Through this interface, the Dialer commands required by the Virtual Agent script are processed. The sim_agt process uses the Dialer's Agent API to send and receive commands to and from the Dialer. There is one other process on the Dialer that serves as the interface between the character- based (CUI) menus on the Dialer and the ivr_conn process. This process, called ivr_supr, acts as a client and ivr_conn acts as the server. The following figure shows how these processes interact.
158 Specialized applications December 2008 Avaya PDS/IVR Integration overview
The dialer_conn process
The dialer_conn process is a permanent process on the Avaya IR that is started when the Voice System starts. It listens to a specific port and waits for a socket connection to be established by the ivr_conn process on a Dialer. When a connection is established, the dialer_conn process sends a list of scripts to the Dialer. Then, in response to a command from the Dialer, it starts a sim_agt process for each channel configured as an agent. The dialer_conn process, in response to a command from the Dialer, will also stop each sim_agt process.
The ivr_conn process
The ivr_conn process is a permanent process on the Dialer that is started when the Dialer system starts. It listens to a specific port waiting for a socket connection to be established by the command interface process, ivr_supr. When a connection is established, the ivr_conn process acts according to the commands given. If the command is a CONNECT command, a socket connection to the dialer_conn process on the specified Avaya IR is established. This initiates the download of script names from the Avaya IR, the starting of a job on the Dialer and the logging in of virtual agents from the Avaya IR (sim_agt processes). If the command is a DISCONNECT command, the agents are logged off, the job is shut down and the socket connection disconnected. If the command is a GET_SCRIPTS command, a request for an updated list of scripts is sent to the dialer_conn process.
The ivr_supr process
The ivr_supr process is invoked from the CUI menus on the Dialer to send commands to the ivr_conn process. When invoked, the ivr_supr process establishes a socket connection to a specific port being listened to by the ivr_conn process. Once established, it sends the specified
Specialized applications December 2008 159 Avaya Predictive Dialing System applications
command, disconnects and then terminates. The possible commands are CONNECT, DISCONNECT and GET_SCRIPTS (see The ivr_conn process on page 159).
The agent process
The agent process serves as the command interface between the Dialer and any Agent API application such as sim_agt. This process is started on the Dialer when the system is started and runs as a permanent process. In its permanent state, the agent process simply listens to a specific port waiting for a socket connection to be established in this case by sim_agt. When a connection is established, the agent process creates a copy of itself. This copy becomes the individual agent process associated with the particular copy of sim_agt that established the connection. The individual agent process handles all interaction between the Dialer and the Virtual Agent script. When the sim_agt process executes a logout command, the socket connection between the agent process and the sim_agt process is dropped and the associated individual agent process is terminated.
The sim_agt process
The sim_agt process is the Agent API application that serves as the interface between the agent process on the Dialer and the Virtual Agent script on the Avaya IR. It is started and stopped by the dialer_conn process in response to commands from the Dialer.
PDS/IVR Integration scenarios
There are three scenarios supported by the PDS/IVR Integration solution. In all three, the Dialer first makes a call to a customer on the calling list. After that, one of these three general call flows occurs: • The call is passed to a Virtual Agent on the Avaya IR and is completely handled there. • The call is first passed to a live agent on the Dialer who then passes it to the Virtual Agent on the Avaya IR. The call is completed on the Avaya IR. • The call is first passed to a Virtual Agent on the Avaya IR and is then transferred to a live agent on the Dialer. The call is completed on the Dialer. The following examples illustrate each of the three scenarios. Example 1: Blood Bank ABC uses Virtual Agent to call customers that have a particular blood type for which there is an urgent need. The PDS places the outbound call and uses the Avaya IR to request customers come in and donate blood at their earliest convenience. Example 2: Car Dealer ABC uses Virtual Agent to have customers take a satisfaction survey after purchasing a new car. The PDS places the outbound call and passes the call to a live agent on the Dialer. The agent congratulates them on their purchase and asks them to take a survey on their experience. If they agree, the agent transfers the call to the Avaya IR to use Virtual Agent for conducting the survey.
160 Specialized applications December 2008 Scripting with the PDS/IVR Integration
Example 3: Bank ABC uses Virtual Agent to contact customers who are slightly past due in paying their low balance accounts. The PDS places the outbound call and uses the IVR system to first verify their identity. Once verified, customers listen to the account balance information and then have the options to enter checking account information for automatic payment or to speak to an agent about payment arrangements.
Scripting with the PDS/IVR Integration
DoNotCall external function
The DoNotCall external function identifies a customer record as "do not call" (DNC). All matching records on other calling lists are also marked DNC. The DNC feature ensures that records appearing in multiple calling lists will not be recalled. Use the Node Inspector to assign and edit the following attributes.
Attribute Description
Put Return Code In Select or name the variable in which to store the return code if Avaya IR does not execute this external function. The return codes are: -1 = a failure of the DIP -2 = a timeout condition
Error Code Select or name the variable in which to store the 6-character error code from Dialer for this external function.
For more information, see "AGTDoNotCall" in Chapter 6, "Commands and Notification Events," in the Avaya PDS Agent API Reference Guide.
End_softdisc external function
The End_softdisc external function ends handling a soft disconnect and re-executes the agt_chl application for the next call. See the descriptions for the Handle_disc and Set_Softdisc external functions. Use the Node Inspector to assign and edit the following attributes.
Attribute Description
Specialized applications December 2008 161 Avaya Predictive Dialing System applications
Put Return Code In Select or name the variable in which to store the return code if this external function does not get executed.
This external function uses the Avaya IR soft disconnect (soft_disc) command. For information about soft disconnect, see the Avaya IR System Help.
FinishedItem external function
The FinishedItem external function releases a customer record and inserts a call completion code into the record. This must be the last activity performed by the script, since the Dialer sends another call after receiving it. Use the Node Inspector to assign and edit the following attributes.
Attribute Description
Put Return Code In Select or name the variable in which to store the return code if Avaya IR does not execute this external function. The return codes are: -1 = a failure of the DIP -2 = a timeout condition
Completion Code The two-digit numeric code to place in the customer record that indicates the results of the telephone call. This completion code is customer-specific, but you must be consistent with the completion codes on the Dialer.
Error Code Select or name the variable in which to store the 6-character error code from Dialer for this external function.
For more information, see AGTFinishedItem in Chapter 6, "Commands and Notification Events," in the Avaya PDS Agent API Reference Guide.
Handle_disc external function
The Handle_disc external function sets the label for handling a soft disconnect. This function marks the beginning of the event-handling code. Between Handle_disc and End_softdisc, place whatever code you think is necessary to clean up the call, for example, updating the completing code on the Dialer system. See the descriptions for the End_softdisc and Set_Softdisc external functions. Use the Node Inspector to assign and edit the following attributes.
162 Specialized applications December 2008 Scripting with the PDS/IVR Integration
Attribute Description
Put Return Code In Select or name the variable in which to store the return code if Avaya IR does not execute this external function.
This external function uses the Avaya IR soft disconnect (soft_disc) command. For information about soft disconnect, see the Avaya IR System Help.
HookflashLine external function
The HookflashLine external function transfers the current call by way of a switch that accepts hookflash-initiated transfers. This external function disconnects the transferring application before transferring the call. Use the Node Inspector to assign and edit the following attributes.
Attribute Description
Put Return Code In Select or name the variable in which to store the return code if Avaya IR does not execute this external function. The return codes are: -1 = a failure of the DIP -2 = a timeout condition
smsg The number to transfer the call to.
Error Code Select or name the variable in which to store the 6-digit error code from Dialer for this external function.
For more information, see AGTHookflashLine in Chapter 6, "Commands and Notification Events," in the Avaya PDS Agent API Reference Guide.
ListCbackFmt external function
The ListCbackFmt external function returns the date format from the caller record. It also lists the number of telephone numbers in the customer record. Use the Node Inspector to assign and edit the following attributes.
Attribute Description
Put Return Code In Select or name the variable in which to store the return code if Avaya IR does not execute this external function.
Specialized applications December 2008 163 Avaya Predictive Dialing System applications
The return codes are: -1 = a failure of the DIP -2 = a timeout condition
Date Format Select or name the variable in which to store the date format that Dialer will return. The date format returned will be one of the following: • CCYY/MM/DD • MM/DD/CCYY • DD/MM/CCYY
Number of Phones Select or name the variable in which to store the number of phones listed in the customer record.
Error Code Select or name the variable in which to store the 6-character error code from Dialer for this external function.
For more information, see AGTListCallbackFmt in Chapter 6, "Commands and Notification Events," in the Avaya PDS Agent API Reference Guide.
LogIoStart external function
The LogIoStart external function turns on message-logging on the dialer to trace call transactions. Creates a file on the Dialer named /tmp/ AgentName _API.trans. It contains all the messages between the agent application and the Dialer. Use this file to verify message content and to track the agent application session. See the description for the LogIoStop external function. Use the Node Inspector to assign and edit the following attributes.
Attribute Description
Put Return Code In Select or name the variable in which to store the return code if Avaya IR does not execute this external function. The return codes are: -1 = a failure of the DIP -2 = a timeout condition
Error Code Select or name the variable in which to store the 6-digit error code from Dialer for this external function. The error code is: M00000 - Complete
164 Specialized applications December 2008 Scripting with the PDS/IVR Integration
For more information, see AGTLogIoStart in Chapter 6, "Commands and Notification Events," in the Avaya PDS Agent API Reference Guide.
LogIoStop external function
The LogIoStop external function turns off message-logging on the dialer. Stops the agent binary from writing to the /tmp/ AgentName _API.trans. Use this external function to terminate the log file. See the description for the LogIoStart external function. Use the Node Inspector to assign and edit the following attributes.
Attribute Description
Put Return Code In Select or name the variable in which to store the return code if Avaya IR does not execute this external function. The return codes are: -1 = a failure of the DIP -2 = a timeout condition
Error Code Select or name the variable in which to store the 6-digit error code from Dialer for this external function. The error code is: M00000 - Complete
For more information, see AGTLogIoStop in Chapter 6, "Commands and Notification Events," in the Avaya PDS Agent API Reference Guide.
MoFlashBlind external function
The MoFlashBlind external function transfers the current call and data record to another job on the Dialer. This external function disconnects the transferring application before transferring the call and customer record. The Dialer places the customer call in the queue for the new job or connects the customer to an available agent. If the Dialer uses ANI/DNIS information, the transferred call carries the outbound number the Dialer dials as the ANI and the original outbound job name as the DNIS. The inbound or blend job receiving the call sees the call as an inbound call. Use the Node Inspector to assign and edit the following attributes.
Attribute Description
Put Return Code In Select or name the variable in which to store the return code if Avaya IR does not execute this external function. The return codes are: -1 = a failure of the DIP
Specialized applications December 2008 165 Avaya Predictive Dialing System applications
-2 = a timeout condition
Error Code Select or name the variable in which to store the 6-digit error code from Dialer for this external function.
For more information, see AGTMoFlashBlind in Chapter 6, "Commands and Notification Events," in the Avaya PDS Agent API Reference Guide.
ReadField external function
The ReadField external function reads a field from the Dialer customer record. Use the Node Inspector to assign and edit the following attributes.
Attribute Description
Put Return Code In Select or name the variable in which to store the return code if Avaya IR does not execute this external function. The return codes are: -1 = a failure of the DIP -2 = a timeout condition
Field Name Enter the name of the field in the Dialer calling list from which you want to receive the field format and the field value. Get the field name from the Dialer administrator.
Field Value Select or name the variable in which to store the field value returned by the Dialer.
Error Code Select or name the variable in which to store the 6-character error code from Dialer for this external function.
For more information, see AGTReadField in Chapter 6, "Commands and Notification Events," in the Avaya PDS Agent API Reference Guide.
ReleaseLine external function
The ReleaseLine external function releases the telephone line but allows further updating of the customer record. Use the Node Inspector to assign and edit the following attributes.
166 Specialized applications December 2008 Scripting with the PDS/IVR Integration
Attribute Description
Put Return Code In Select or name the variable in which to store the return code if Avaya IR does not execute this external function. The return codes are: -1 = a failure of the DIP -2 = a timeout condition
Script Label This is an optional attribute. This attribute refers to a label in the /opt/ avaya/pds/scripts/telephony.spt file.
Message Number This is an optional attribute. This attribute refers to a message number configured in the /opt/avaya/pds/config/ voicemsg.cfg file.
Error Code Select or name the variable in which to store the 6-character error code from Dialer for this external function.
For more information, see AGTReleaseLine in Chapter 6, "Commands and Notification Events," in the Avaya PDS Agent API Reference Guide.
SendMessage external function
The SendMessage external function sends a message to the Dialer supervisor's screen. Use the Node Inspector to assign and edit the following attributes.
Attribute Description
Put Return Code In Select or name the variable in which to store the return code if Avaya IR does not execute this external function. The return codes are: -1 = a failure of the DIP -2 = a timeout condition
Message Enter the message (or select the variable that contains the message) to send to the Dialer supervisor. The maximum message length is 79 characters.
Error Code Select or name the variable in which to store the 6-character error code from Dialer for this external function. The error code is: M00000 - Complete
Specialized applications December 2008 167 Avaya Predictive Dialing System applications
For more information, see AGTSendMessage in Chapter 6, "Commands and Notification Events," in the Avaya PDS Agent API Reference Guide.
SetCallback external function
The SetCallback external function sets the time on the Dialer to schedule a customer callback. Use the Node Inspector to assign and edit the following attributes.
Attribute Description
Put Return Code In Select or name the variable in which to store the return code if Avaya IR does not execute this external function. The return codes are: -1 = a failure of the DIP -2 = a timeout condition
Callback Date Enter the callback date or select the variable in which you have stored it. The format must match the format returned by the ListCbackFmt external function. The date can be in one of the following formats: • CCYY/MM/DD • MM/DD/CCYY • DD/MM/CCYY
Callback Time Enter the callback time or select the variable in which you have stored it. The time can be in any of the following formats: • HHMM (24-hour clock) • HHMM[A|P] (12-hour clock) • HHMM+ (incremental time from current time)
Phone Index Index of the Dialer phone field to use for the recall. This information can be obtained from the Dialer administrator and must fall in the range returned by the ListCbackFmt external function.
Optional Fields Specify a customer name and telephone number (separated by a comma) to contact during the recall.
168 Specialized applications December 2008 Scripting with the PDS/IVR Integration
Error Code Select or name the variable in which to store the 6-character error code from Dialer for this external function.
For more information, see AGTSetCallback in Chapter 6, "Commands and Notification Events," in the Avaya PDS Agent API Reference Guide.
Set_early_hu external function
The Set_early_hu external function prepares the application for an early hangup. The sim_agt DIP posts a hangup event to the application when the Dialer detects a hangup. The application must define an L_EARLYHANGUP label. The code associated with the L_EARLYHANGUP label should perform the processing that is required when an early hangup event is received. Use the Node Inspector to assign and edit the following attributes.
Attribute Description
Put Return Code In Select or name the variable in which to store the return code if Avaya IR does not execute this external function.
This external function uses the Avaya IR soft disconnect (soft_disc) command. For information about soft disconnect, see the Avaya IR System Help.
SetNotifyFld external function
The SetNotifyFld external function sets the system to pass the value of a specified key field from the Dialer calling list with the CallNotification message.
Note: The SetNotifyFld function should be used only in an initial application to be run when an agent joins a job. Use the Node Inspector to assign and edit the following attributes.
Attribute Description
Put Return Code In Select or name the variable in which to store the return code if Avaya IR does not execute this external function. The return codes are: -1 = a failure of the DIP -2 = a timeout condition
Specialized applications December 2008 169 Avaya Predictive Dialing System applications
Field Name Enter the name of the field in the Dialer calling list from which you want to receive the field value as part of each CallNotify message. Get the field name from the Dialer administrator.
Error Code Select or name the variable in which to store the 6-character error code from Dialer for this external function.
For more information, see AGTSetNotifyKeyField in Chapter 6, "Commands and Notification Events," in the Avaya PDS Agent API Reference Guide.
Set_Softdisc external function
The Set_Softdisc external function prepares the application for a soft disconnect. This function catches the dipterm event and runs the handler. This should be the first external function in the application. See the descriptions for the Handle_disc and End_Softdisc external functions. Use the Node Inspector to assign and edit the following attributes.
Attribute Description
Put Return Code In Select or name the variable in which to store the return code if Avaya IR does not execute this external function.
This external function uses the Avaya IR soft disconnect (soft_disc) command. For information about soft disconnect, see the Avaya IR System Help.
UpdateField external function
The UpdateField external function updates a data field on the Dialer customer record. Use the Node Inspector to assign and edit the following attributes.
Attribute Description
Put Return Code In Select or name the variable in which to store the return code if Avaya IR does not execute this external function. The return codes are: -1 = a failure of the DIP -2 = a timeout condition
170 Specialized applications December 2008 Scripting with the PDS/IVR Integration
Field Name Enter the name of the field in the Dialer calling list to update, or select the variable in which you have stored the field name.
Field Value Enter the new value to insert into the field.
Error Code Select or name the variable in which to store the 6-character error code from Dialer for this external function.
For more information, see AGTUpdateField in Chapter 6, "Commands and Notification Events," in the Avaya PDS Agent API Reference Guide.
Specialized applications December 2008 171 Avaya Predictive Dialing System applications
172 Specialized applications December 2008 Chapter 6: Siebel eBusiness applications
Introduction to Siebel eBusiness Integration
Introduction to Siebel eBusiness Integration describes how to create applications for Avaya IR that can exchange data with Siebel eBusiness products. The descriptions in this section assume: • Familiarity with Siebel eBusiness (setup, administration, and use). • Familiarity with Avaya IR application development, preferably using IVR Designer. • Familiarity with the Extensible Markup Language (XML). Any Avaya IR system running an application to interface with Siebel eBusiness needs to have Gold Systems Vonetix version 2.1 or higher loaded on the system. Basic concepts Applications on Avaya IR exchange information with Siebel eBusiness databases using XML documents. This is facilitated by Vonetix middleware on Avaya IR and the Business Integration Manager on Siebel eBusiness. Vonetix enables the application to read, create, and send XML documents from Avaya IR. The Business Integration Manager manages the translation and transfer of XML documents within Siebel eBusiness, and accesses Siebel eBusiness databases using abstract objects that encapsulate the data of interest. If the Computer Telephony Integration (CTI) feature is being used, then a call can be passed to the Siebel operator from Avaya IR. Information inserted by the application into the UUI field will then automatically be transferred to the Siebel eBusiness Desktop (as a "screen pop"). Creating an application There are several basic steps involved in creating an application on Avaya IR to access and/ or send data to a Siebel eBusiness database. These steps provide the basic organization of this guide for application developers: 1. Identify which data will be transferred from Siebel eBusiness to Avaya IR. 2. Identify which data will be transferred from Avaya IR to Siebel eBusiness. 3. Create a Siebel integration object that represents the data of interest. 4. Create a workflow within Siebel eBusiness that manages the exchange of information between Siebel eBusiness and Avaya IR. 5. Use Siebel eBusiness to generate a document type definition (DTD) for each integration object.
Specialized applications December 2008 173 Siebel eBusiness applications
6. Use the DTD to generate a document type definition (DTD) for each integration object. 7. Create the Avaya IR application using IVR Designer. The application uses the XML template to generate an XML document which is sent to Siebel eBusiness.
Identifying data to be transferred
An application on Avaya IR will be doing one or both of the following: • Querying Siebel eBusiness for information in a Siebel database (retrieve data from Siebel eBusiness). • Updating a Siebel eBusiness database (send data from Avaya IR to Siebel eBusiness). The first task for the application developer is to decide what data is of interest, and where it is. Data on Siebel eBusiness Data on Siebel eBusiness resides in standard database files, organized according to what Siebel calls the "Siebel Data Model". The data is accessible through object-oriented software. The software enables a user to group related data from various parts of the database into a "business object" which can be treated as a unit. Example: Names, occupations, and ages could be manipulated together as a "People" object. To get someone's name, the application would need to access the People object. Data of interest may reside in several business objects. When creating an application, it is important to identify the business object(s) that have data that will be queried and data that will be updated. Data on Avaya Interactive Response Data on Avaya IR can be: • Collected directly from a caller (in a "prompt and collect" operation). • Associated with the call (such as ANI or DNIS). • Stored in a database. • In a file.
Setting up Siebel
To access business objects, Siebel's Business Integration Manager uses a Siebel eAI (eBusiness Application Interface) Adapter, which translates business objects or some of their components into "integration objects" that can be used to create XML documents. Information can also go the other way: integration objects can be translated into business objects or some of their components through the eAI Adapter. Note that parts of several different business objects can be included in a single integration object.
174 Specialized applications December 2008 XML templates
The management of data within Siebel eBusiness is done using "workflows", which are customizable processes and rules. They control access, assembly, and distribution of integration objects. A workflow can deal with queries, updates, or both. XML documents are exchanged with external applications (on a Avaya IR) via HTTP using the Business Integration Manager's XML Gateway and HTTP Gateway. See the Siebel 2000 Bookshelf for more information.
XML templates
XML documents sent from Avaya IR to Siebel eBusiness, whether they be for queries or updates, can be constructed using XML templates that derive from the DTDs supplied by Siebel eBusiness for the related integration objects. As mentioned in Setting up Siebel, a DTD provides the application developer with the structure of the XML document that Siebel eBusiness expects. Of principal importance are: • Element names. • Element order. • Data types. A template has two main features: • A header, which tells Siebel eBusiness which integration object is being addressed. • A body of tag pairs, each having either no content or reusable content.
Interpreting DTDs
Following is a brief discussion of how to interpret DTDs. The structure of a DTD can be seen by example:
Specialized applications December 2008 175 Siebel eBusiness applications
TransactionId?, SRNumber?)> The first two lines are the header. The Siebel header will not be used in the XML template. The remainder of the DTD defines the elements expected in the body of the XML document. Each line is called an "element declaration", as identified by the !ELEMENT label. An element declaration typically has two parts: 1. The name of the element, identified by a tag. 2. A description of the element's contents (enclosed in perentheses). In the example, SRNumber is the element name, and #PCDATA describes the contents as parsed character data. Slightly more complicated is the line In this case, the contents of the element are a set of child elements, where each child's name is separated by a comma. Note that a "?", "*", or "+" following a child name indicates the number of
176 Specialized applications December 2008 XML templates
instances of the element that are allowed (zero or more instances can be present between tags for "?" or "*"; zero or more instances must be present for "+").
Creating the template
The XML template will need to be created and stored as a file on the Avaya IR. A header naming the integration object will need to be added to the tag pairs (start and end tags) derived from the DTD. The header takes the form
Specialized applications December 2008 177 Siebel eBusiness applications
Queries and updates
Avaya IR communicates with Siebel eBusiness using a plug-in that is part of the Vonetix middleware by Gold Systems. An application on Avaya IR can make function calls to Vonetix that: • Prepare and send outgoing XML documents. • Receive and process incoming XML documents. What Siebel eBusiness actually receives from Avaya IR is a set of "form data" that includes the original XML document on Avaya IR along with special information that tells Siebel eBusiness what to do.
The Vonetix interface
Information flow between an application and Siebel eBusiness is facilitated by specialized Vonetix functionality. The Vonetix interface consists of the following parts: • Java Gateway DIP. Applications communicate directly with this data interface process, which uses TCP/ IP to pass information to the Vonetix Gateway. • Vonetix Gateway. This gateway sends requests to the Mini-Browser based upon information received from the DIP. • Mini-Browser. The Mini-Browser is where XML documents are interrogated and modified, and HTTP requests are sent to the Base Servlet. • Base Servlet. The Base Servlet receives HTTP requests from the Mini-Browser via the Web Server and Tomcat Servlet, then relays them to the Document Plug-In, tracking them by unique session names and cookies. • Document Plug-In. The Document Plug-In relays HTTP requests and XML documents between the Base Servlet and Siebel eBusiness. Vonetix provides TAS functions to support the Document Plug-In, the "Generic TAS Functions" and "Utilities TAS Functions." See the latest Vonetix Technical Training Guide or Data Channel Guide for a detailed listing with descriptions and code examples.
178 Specialized applications December 2008 Queries and updates
Note: Vonetix is supported only on Avaya IR systems installed in root directory (that is, using Classic mode installation).
Specialized applications December 2008 179 Siebel eBusiness applications
180 Specialized applications December 2008 Index
Special Characters requests to the VOX server ...... 141 XML template ...... 177 +create ...... 142 CTI +getarg ...... 143 applications ...... 129 +send ...... 144 ctiCallInfo ...... 129 +setarg ...... 144 ctiCallState ...... 130 ctiConfer ...... 131 ctiDial ...... 132 A ctiDiscon ...... 132 ctiHold ...... 133 Agent-to-agent transfer ctiNotify ...... 134 to a station via a consult transfer ...... 122 ctiPrivData ...... 135 to a station via blind transfer ...... 117 ctiRetrieve ...... 136 via a VDN and blind transfer ...... 114 ctiTransfer ...... 136 via a VDN and consult transfer ...... 120 Czech EBS formats ...... 36 alarm ...... 154 ASAI application design ...... 90 D application types ...... 85 applications ...... 85 defining versus the converse vector step ...... 89 speech tables ...... 80 Australian English EBS formats ...... 27 the language file and directory ...... 80 Avaya Interaction Center applications ...... 139 TTS tables ...... 82 Avaya IR system-to-agent transfer via an ACD split .... Determining the transaction ...... 12 125 Developing speech ...... 11 Avaya PDS/IVR Integration overview ...... 157 DoNotCall external function ...... 161 Dutch EBS formats ...... 39 B E Background information ...... 24 Barge-in and NLSR ...... 18 Editing speech ...... 18 Brazilian Portuguese EBS formats ...... 29 End_softdisc external function ...... 161
C F FinishedItem external function ...... 162 Call flow examples ...... 108 French EBS formats ...... 40 Call to a VDN and abandoned after agent selection .... 113 Call to a VDN and abandoned in queue ...... 112 G Call to an agent via an ACD split ...... 109 Call to an agent via VDNs with Call Prompting ...... 110 German EBS formats ...... 43 Call-flow design ...... 98 getvdu ...... 148 Canadian French EBS formats ...... 30 getvox ...... 149 Cantonese Chinese EBS formats ...... 33 gone ...... 153 Castilian Spanish EBS formats ...... 34 Greek EBS formats ...... 45 Comparison of recognition types ...... 22 Conventions for Language Implementations ...... 83 H creating custom variables ...... 155 Handle_disc external function ...... 162
Specialized applications December 2008 181 Index
Hebrew EBS formats ...... 48 Phrase list file for EBS ...... 82 Hindi EBS formats ...... 51 Planning the voice script ...... 12 HookflashLine external function ...... 163 Polish EBS formats ...... 67 Host application planning and design ...... 105 pseudo_ani ...... 147 Hungarian EBS formats ...... 52 Q I Queries and updates ...... 178 Identifying data to be transferred ...... 174 Indonesian EBS formats ...... 55 Interpreting DTDs ...... 175 R Introduction to Siebel eBusiness Integration ...... 173 ReadField external function ...... 166 Italian EBS formats ...... 57 ReleaseLine external function ...... 166 IVR/PDS interface processes ...... 158 Rules for integrating with IC applications ...... 139
J S Japanese EBS formats ...... 58 Selecting a speech development method ...... 15 SendMessage external function ...... 167 K Set_early_hu external function ...... 169 Set_Softdisc external function ...... 170 Korean EBS formats ...... 59 SetCallback external function ...... 168 SetNotifyFld external function ...... 169 Setting up Siebel ...... 174 L setvdu ...... 150 Languages available ...... 22 Slovak EBS formats ...... 70 Latin-American Spanish EBS formats ...... 61 Speech development tools and features ...... 9 legal notices ...... 2 Speech file system ...... 7 ListCbackFmt external function ...... 163 LogIoStart external function ...... 164 T LogIoStop external function ...... 165 Thai EBS formats ...... 74 The agent process ...... 160 M The dialer_conn process ...... 159 Malay EBS formats ...... 63 The ivr_conn process ...... 159 Mandarin Chinese EBS formats ...... 64 The ivr_supr process ...... 159 MoFlashBlind external function ...... 165 The sim_agt process ...... 160 The Vonetix interface ...... 178 tr ...... 151 N transfer ...... 152 newcall ...... 146 notices, legal ...... 2 U
UK English EBS format ...... 75 O UpdateField external function ...... 170 US English EBS formats ...... 77 Overview of developing language implementations .... using 79 ASAI in a call center ...... 96 NLSR external functions in an IVR Designer P application ...... 19 NLSR in voice applications ...... 18 PDS/IVR Integration scenarios ...... 160 NLSR with other features ...... 21
182 Specialized applications December 2008 Index
Text-to-Speech and prerecorded speech together ... Vesp_dip return codes ...... 155 21 Vesp_dip functions ...... 140 W
V Writing the voice script ...... 13 Vesp_dip overview ...... 139 X Vesp_dip functions overview ...... 140 XML templates ...... 175
Specialized applications December 2008 183 Index
184 Specialized applications December 2008