2004 Avaya Inc. All Rights Reserved.

Transcription

1 Avaya Speech Applications Builder High Level Architecture May 15, 2004

2 2004 Avaya Inc. All Rights Reserved. Notice While reasonable efforts were made to ensure that the information in this document was complete and accurate at the time of printing, Avaya Inc. can assume no liability for any errors. Changes and corrections to the information in this document may be incorporated in future releases. Preventing toll fraud "Toll fraud" is the unauthorized use of your telecommunications system by an unauthorized party (for example, anyone who is not a corporate employee, agent, subcontractor, or person working on your company's behalf). Be aware that there may be a risk of toll fraud associated with your system and that, if toll fraud occurs, it can result in substantial additional charges for your telecommunications services. Avaya fraud intervention If you suspect that you are being victimized by toll fraud and you need technical assistance or support, call Technical Service Center Toll Fraud Intervention Hotline at for the United States and Canada. For additional support telephone numbers, see the Avaya Web site: Select Support, then select Escalation Lists. This Web site includes telephone numbers for escalation within the United States. For escalation telephone numbers outside the United States, select Global Escalation List. Providing telecommunications security Telecommunications security (of voice, data, and video communications) is the prevention of any type of intrusion to (that is, either unauthorized or malicious access to or use of) your company's telecommunications equipment by some party. Your company's "telecommunications equipment" includes both this Avaya product and any other voice/data/video equipment that could be accessed via this Avaya product (that is, "networked equipment"). An "outside party" is anyone who is not a corporate employee, agent, subcontractor, or person working on your company's behalf. Whereas, a "malicious party" is anyone (including someone who may be otherwise authorized) who accesses your telecommunications equipment with either malicious or mischievous intent. Such intrusions may be either to/through synchronous (timemultiplexed and/or circuit-based) or asynchronous (character-, message-, or packet-based) equipment or interfaces for reasons of: Use (of capabilities special to the accessed equipment) Theft (such as, of intellectual property, financial assets, or toll-facility access) Eavesdropping (privacy invasions to humans) Mischief (troubling, but apparently innocuous, tampering) Harm (such as harmful tampering, data loss or alteration, regardless of motive or intent) Be aware that there may be a risk of unauthorized intrusions associated with your system and/or its networked equipment. Also realize that, if such an intrusion should occur, it could result in a variety of losses to your company (including, but not limited to, human and data privacy, intellectual property, material assets, financial resources, labor costs, and legal costs). Your responsibility for your company's telecommunications security The final responsibility for securing both this system and its networked equipment rests with you, an Avaya customer's system administrator, your telecommunications peers, and your managers. Base the fulfillment of your responsibility on acquired knowledge and resources from a variety of sources, including, but not limited to: Installation documents System administration documents Security documents Hardware-/software-based security tools Shared information between you and your peers Telecommunications security experts To prevent intrusions to your telecommunications equipment, you and your peers should carefully program and configure: Your Avaya-provided telecommunications systems and their interfaces Your Avaya-provided software applications, as well as their underlying hardware/software platforms and interfaces Any other equipment networked to your Avaya products. Part 15: Class A Statement For the MCC1, SCC1, G600, and CMC1 Media Gateways: Note: This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to Part 15 of the FCC Rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses, and can radiate radio frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference, in which case the user will be required to correct the interference at his own expense. Part 15: Class B Statement For the G700 Media Gateway: Note: This equipment has been tested and found to comply with the limits for a Class B digital device, pursuant to Part 15 of the FCC Rules. These limits are designed to provide reasonable protection against harmful interference in a residential installation. This equipment generates, uses, and can radiate radio-frequency energy and, if not installed and used in accordance with the instructions, may cause harmful interference to radio communications. However, there is no guarantee that interference will not occur in a particular installation. If this equipment does cause harmful interference to radio or television reception, which can be determined by turning the equipment off and on, the user is encouraged to try to correct the interference by one or more of the following measures: Reorient the receiving television or radio antenna wherethis may be done safely. To the extent possible, relocate the receiver with respect to the telephone equipment. Where the telephone equipment requires AC power, plug the telephone into a different AC outlet so that the telephone equipment and receiver are on different branch circuits. Consult the Dealer or an experienced radio/tv technician for help. Speech Applications Builder High Level Architecture May 15, 2004 page 2 of 17

3 Canadian Department of Communications (DOC) Interference Information For MCC1, SCC1, G600, and CMC1 Media Gateways: This Class A digital apparatus complies with Canadian ICES Cet appareil numérique de la classe A est conforme à la norme NMB-003 du Canada. For the G700 Media Gateway: This Class B digital apparatus complies with Canadian ICES Cet appareil numérique de la classe B est conforme à la norme NMB-003 du Canada. This equipment meets the applicable Industry Canada Terminal Equipment Technical Specifications. This is confirmed by the registration number. The abbreviation, IC, before the registration number signifies that registration was performed based on a Declaration of Conformity indicating that Industry Canada technical specifications were met. It does not imply that Industry Canada approved the equipment. Japan For the MCC1, SCC1, G600, and CMC1 Media Gateways: This is a Class A product based on the standard of the Voluntary Control Council for Interference by Information Technology Equipment (VCCI). If this equipment is used in a domestic environment, radio disturbance may occur, in which case, the user may be required to take corrective actions. For the G700 Media Gateway: This is a Class B product based on the standard of the Voluntary Control Council for Interference by Information Technology Equipment (VCCI). If this equipment is used in a domestic environment, radio disturbance may occur, in which case, the user may be required to take corrective actions. Part 15: Personal Computer Statement This equipment has been certified to comply with the limits for a Class B computing device, pursuant to Subpart J of Part 15 of FCC Rules. Only peripherals (computing input/output devices, terminals, printers, etc.) certified to comply with the Class B limits may be attached to this computer. Operation with noncertified peripherals is likely to result in interference to radio and television reception. Part 68: Answer-Supervision Signaling Allowing this equipment to be operated in a manner that does not provide proper answer-supervision signaling is in violation of Part 68 rules. This equipment returns answer-supervision signals to the public switched network when: answered by the called station, answered by the attendant, or routed to a recorded announcement that can be administered by the CPE user. This equipment returns answer-supervision signals on all direct inward dialed (DID) calls forwarded back to the public switched telephone network. Permissible exceptions are: A call is unanswered. A busy tone is received. A reorder tone is received. DECLARATIONS OF CONFORMITY US FCC Part 68 Supplier s Declaration of Conformity (SDoC) Avaya Inc. in the United States of America hereby certifies that the Avaya switch equipment described in this document and bearing a TIA TSB-168 label identification number complies with the Federal Communications Commission s (FCC) Rules and Regulations 47 CFR Part 68, and the Administrative Council on Terminal Attachments (ACTA) adopted technical criteria. Avaya further asserts that Avaya handset equipped terminal equipment described in this document complies with Paragraph of the FCC Rules and Regulations defining Hearing Aid Compatibility and is deemed compatible with hearing aids. Copies of SDoCs signed by the Responsible Party in the US can be obtained by contacting your local sales representative and are available on the following Web site: All Avaya switch products are compliant with Part 68 of the FCC rules, but many have been registered with the FCC before the SDoC process was available. A list of all Avaya registered products may be found at: by conducting a search using "Avaya" as manufacturer. European Union Declarations of Conformity Avaya Inc. declares that the equipment specified in this document bearing the "CE" (Conformité Europeénne) mark conforms to the European Union Radio and Telecommunications Terminal Equipment Directive (1999/5/EC), including the Electromagnetic Compatibility Directive (89/336/EEC) and Low Voltage Directive (73/23/EEC). This equipment has been certified to meet CTR3 Basic Rate Interface (BRI) and CTR4 Primary Rate Interface (PRI) and subsets thereof in CTR12 and CTR13, as applicable. Copies of these Declarations of Conformity (DoCs) signed by the Vice President of R&D, Avaya Inc., can be obtained by contacting your local sales representative and are available on the following Web site: TCP/IP facilities Customers may experience differences in product performance, reliability, and security, depending upon network configurations/design and topologies, even when the product performs as warranted. Warranty Avaya Inc. provides a limited warranty on this product. Refer to your sales agreement to establish the terms of the limited warranty. In addition, Avaya s standard warranty language, as well as information regarding support for this product, while under warranty, is available through the following Web site: Link disclaimer Avaya Inc. is not responsible for the contents or reliability of any linked Web sites and does not necessarily endorse the products, services, or information described or offered within them. We cannot guarantee that these links will work all of the time and we have no control over the availability of the linked pages. Speech Applications Builder High Level Architecture May 15, 2004 page 3 of 17

4 Trademarks Avaya is a trademark of Avaya Inc. Insert all other Avaya Trademarks here, then delete this paragraph. DO NOT include other company s trademarks. All trademarks identified by the or are registered trademarks or trademarks, respectively, of Avaya Inc. All other trademarks are the property of their respective owners. Ordering information: Avaya Publications Center Voice: Write: Web: Order: (Toll-free, U.S. and Canada only) Fax: (Toll-free, U.S. and Canada only) Globalware Solutions 200 Ward Hill Avenue Haverhill, MA USA Attention: Avaya Account Manager totalware@gwsmail.com Avaya support Avaya provides a telephone number for you to use to report problems or to ask questions about your contact center. The support telephone number is in the United States. For additional support telephone numbers, see the Avaya Web site: Select Support, then select Escalation Lists. This Web site includes telephone numbers for escalation within the United States. For escalation telephone numbers outside the United States, select Global Escalation List. Comments To comment on this document, send to crminfodev@avaya.com. Acknowledgment This document was written by the CRM Information Development group. Speech Applications Builder High Level Architecture May 15, 2004 page 4 of 17

5 Contents Contents... 5 Introduction... 6 Further Reading 6 System Overview... 7 Context viewpoint... 8 The SAB Configurator 10 Physical Data viewpoint Loading components from the Repository 13 Deployment viewpoint ICM Integration System Use cases 16 High Level Class Diagram 17 Speech Applications Builder High Level Architecture May 15, 2004 page 5 of 17

6 Introduction This document provides an overview of the high-level architecture of the Avaya Speech Applications Builder (SAB) platform. Further Reading The following documentation is provided with SAB. Avaya SAB Configurator Guide Avaya SAB Component Guide Speech Applications Builder High Level Architecture May 15, 2004 page 6 of 17

7 System Overview Avaya Speech Applications Builder (SAB) provides: a development environment, which permits the building and tuning of voice-driven applications a J2EE-based environment for running voice-enabled applications abstraction from the underlying voice and telephony platform to enable deployment in a range of VoiceXML-based environments integration with Cisco ICM (offered as an optional subsystem to enable SAB to act as a part of the complex call control used in large telephony deployments) logging of call data with reports generation a basic SNMP-based monitoring capability for deployment in managed network infrastructures. Speech Applications Builder High Level Architecture May 15, 2004 page 7 of 17

8 Context viewpoint The users and external interfaces between Avaya Speech Applications Builder and the outside world are shown in Figure 1. Figure 1. SAB Context, showing dependencies Speech Applications Builder High Level Architecture May 15, 2004 page 8 of 17

9 The high level elements that make up a SAB deployment are described in the following table: Configurator User Configurator Reports User Reports Logging RDBMS Servlet Container Local Filesystem Configuration RDBMS Repository RDBMS Runtime SNMP Infrastructure JMS Messaging Provider ICM PG ICM Integration Portleaser A technical or non-technical user of the SAB Configurator GUI. Technical users can build dialog flows and, if necessary, design custom components to handle new functionality. Non-technical users can build simple new flows and configure existing flows. The SAB development and deployment tools; made available to the user via a GUI-driven application. For more detail see next diagram. (Typically) a non-technical user who accesses the Reports subsystem across the network, using a web browser. The subsystem that presents data from the Logging RDBMS in a variety of report formats. An SQL database to which the Runtime subsystem logs data for extraction by the Reports subsystem. A J2EE compliant servlet container used by both the Report and Runtime subsystems. Supported containers include JBOSS, JRUN and Websphere. The filesystem on the node containing the ServletContainer in which the Runtime subsystem is running. The Local Filesystem is used to cache versions of component jars. An SQL database used to store configuration data for the Runtime subsystem. An SQL database used by the Runtime and Configurator subsystems to store versioned dialog flows and components. The servlet-based subsystem that executes dialog flows stored in the Repository RDBMS. SNMP trap generators that can notify network management systems (NMS) of failures in the system. A standard JMS-compliant messaging provider used to provide communications channels between the Runtime subsystem and the ICM integration subsystem. Cisco Peripheral Gateway. The part of ICM that interfaces to telephony devices. The subsystem that communicates with the Cisco PG, and the Runtime subsystem (via JMS Messaging Provider) in order to support ICM control of SAB elements. A development tool that allows several developers to share a single voice platform by managing the fetching of VoiceXML documents from multiple web servers (development machines). Independent of the rest of the SAB platform. Speech Applications Builder High Level Architecture May 15, 2004 page 9 of 17

10 The SAB Configurator Avaya SAB Configurator <<Subsystem>> RUNTIME INTERFACE <<Subsystem>> REPOSITORY INTERFACE <<Subsystem>> VOICE CORE <<Subsystem>> DIALOG MODEL <<Subsystem>> U1 <<Subsystem>> DIALOGS <<Subsystem>> STEPS Figure 2. SAB Configurator subsystems, showing dependencies The SAB Configurator subsystems are described in the table below: UI Runtime Interface Repository Interface Voice Core Dialog Model Dialogs Steps The graphical interface for building dialog flows, importing prompts, etc. The interface to the servlet-based Runtime that executes dialog flows stored in the Repository RDBMS. The interface that handles interactions with the database that stores created dialog flows, prompts, processes, and all resources associated with an application. The low-level architecture responsible for interaction with the speech platform components. The component model used to create the dialog flows. The individual components that are used by the Runtime to handle speech interactions with the caller. Components that can be pieced together to make a dialog flow. Steps can be wrapped for dialogs or can be used for data manipulation and interactions with external systems. Speech Applications Builder High Level Architecture May 15, 2004 page 10 of 17

11 Physical Data viewpoint Flows <<External>> REPOSITORY RDBMS Environments Steps Prompts Rules Jars LOCAL FILESYSTEM Cached jars Cached classes <<External>> LOGGING RDBMS Activity records <<External>> CONFIGURATION RDBMS Figure 3. SAB Configurator Physical Data Speech Applications Builder High Level Architecture May 15, 2004 page 11 of 17

12 The following table describes the nature of the physical data. Repository The Repository is used by the Runtime and the Configurator subsystems to store : Flows Steps Rules Jars Prompts Linked steps that form an application. Individual interactions that are linked to form the application. Any decision-handling logic used in the application. The libraries required by the application. Pre-recorded audio files Local Filesystem The filesystem on the node containing the ServletContainer in which the Runtime subsystem is running is used to store: Cached jars Versions of the component jars are cached to prevent the Runtime having to fetch them from the Repository each time they are required. Logging RDBMS The Logging RDBMS is used by the Runtime subsystem to log data for extraction by the Reports subsystem Activity records Data logged includes: call start and end times, duration, session id, CLI, DDI, end type (hang up, etc), call journey (components called). Configuration RDBMS The Configuration RDBMS is used to store configuration data for the Runtime subsystem. Speech Applications Builder High Level Architecture May 15, 2004 page 12 of 17

13 Loading components from the Repository Figure 4. Loading components from the Repository The RepositoryComponentVersion component is responsible for classloading a versioned SAM component from the repository. Versions of binary jars containing both the SAM component and its dependents are persisted in the database, then extracted, saved to disk (in the {AVAYASAB_HOME}/cache directory) and loaded from this cache by a custom URLClassloader (see Figure 5. ). The persistent components in the repository are Agility BusinessObjects and are persisted using the Agility O/R Mapper. Speech Applications Builder High Level Architecture May 15, 2004 page 13 of 17

14 Figure 5. Repository Classloader Creation Interaction View Speech Applications Builder High Level Architecture May 15, 2004 page 14 of 17

15 Deployment viewpoint Text-To-Speech Server Example software: - Scansoft Speechify Speech Recognition Server Example software: - Scansoft OSR - Nuance NVP Avaya IR Database Server Application Server Example software: - JBOSS - JRUN - WAS Example Software: - MS SQL - DB2 Repository RDBMS Avaya SAB Runtime Configuration RDBMS Application Server Logging RDBMS Database Server Figure 6. Deployment viewpoint Speech Applications Builder High Level Architecture May 15, 2004 page 15 of 17

16 ICM Integration System Use cases The following diagram illustrates the use cases of this sub system Figure 7. System Use cases Communication between the application and the Peripheral Gateway (PG) by the SAM ICM Gateway. The high-level block diagram of the solution is illustrated in the following diagram. SAB ICM Gateway SAB APPLICATION JMS Backbone Encoder/ Decoder TCP Listener PG Figure 8. High level block diagram of ICM Gateway Speech Applications Builder High Level Architecture May 15, 2004 page 16 of 17

17 This layer converts (decodes) a TCP packet or a byte stream into a JMS message that wraps the actual ICM message and encodes an ICM message wrapped in a JMS message into a valid byte stream. High Level Class Diagram Figure 9. High Level Class Diagram The CallRouterClient reads bytes of a Socket Stream, uses a Translator to decode the message, then uses the MessageUtils class to push the message to a JMS queue. The response is obtained on another Queue. A SAB application uses the same JMS architecture to send messages to an ICM PG. Speech Applications Builder High Level Architecture May 15, 2004 page 17 of 17