2004 Avaya Inc. All Rights Reserved.

Transcription

1 Avaya Speech Applications Builder Intelligent Contact Management (ICM) Gateway Configuration and Deployment Guide 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. Intelligent Contact Management Gateway Configuration and Deployment Guide May 15, 2004 page 2 of 23

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. Intelligent Contact Management Gateway Configuration and Deployment Guide May 15, 2004 page 3 of 23

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. Intelligent Contact Management Gateway Configuration and Deployment Guide May 15, 2004 page 4 of 23

5 Contents Contents... 5 Introduction... 6 Scope and Purpose 6 Targeted Audience 6 Related Documents 6 The Intelligent Contact Management (ICM) Gateway... 7 Overview 7 Dialog Flows Requiring ICM Components 7 System Requirements Hardware Requirements 11 Software Requirements 11 Application Environment Configuration Physical Architecture 12 Logical Architecture 13 Deployment Editing the Vru.properties File 14 Editing the PGMapping.xml File 14 Starting the ICM Gateway 15 Appendix A: Sample VRU.Properties File Appendix B: Sample PGMapping.xml File Appendix C: Frequently Asked Questions Intelligent Contact Management Gateway Configuration and Deployment Guide May 15, 2004 page 5 of 23

6 Introduction Scope and Purpose This manual describes the configuration and deployment process of the Intelligent Contact Management (ICM) Gateway. For instructions on deploying other components within the logical architecture, refer to their respective configuration guides. Targeted Audience This manual is intended for systems administrators, architects, and technical resources involved in the ICM Gateway deployment process. Related Documents Other documents to refer to are as follows: Intelligent Contact Management (ICM) Emulator Installation Guide Speech Applications Builder (SAB) Platform Configuration and Deployment Guide Speech Applications Builder (SAB) Configurator User Guide GED125V29 CISCO ICM Specification Component Developer s Guide Intelligent Contact Management Gateway Configuration and Deployment Guide May 15, 2004 page 6 of 23

7 The Intelligent Contact Management (ICM) Gateway Overview Intelligent Contact Management (ICM) is a Cisco system that implements enterprise-wide call distribution across call centres. ICM software provides Pre-Routing, Post-Routing, and performance monitoring capabilities. One or more Speech Applications Builder (SAB) applications can be deployed within a contact centre infrastructure for providing a variety of services. Within this context, a SAB application acts like a Voice Response Unit (VRU) where it must be able to interact with CISCO ICM so that it can receive call control instructions from the latter. This sort of communication is facilitated by pre-built ICM components that are bundled with the SAB platform. Dialog Flows Requiring ICM Components This section illustrates and describes sample dialog flows that use the ICM components. For details on the configuration of any of the components, please refer to the Component Developer s Guide. Logical View The SAB and Cisco ICM can be used to automate contact center operations. The illustration below shows a flow for an organization that has its own Peripheral Gateway, which contains routing scripts for all their trunks. A peripheral gateway can support up to 32 Peripheral Interface Managers (PIM) and each PIM can be configured to connect to a different ICM. This configuration enables an organization to achieve a very cost-effective solution against failure of JMS backbone or the ICM without using expensive clustering solutions. Figure 1. Sample Logical View Intelligent Contact Management Gateway Configuration and Deployment Guide May 15, 2004 page 7 of 23

8 Simple Flow Sending a NEW_CALL On a high level, this flow receives a call, sends the ICM a NEW_CALL message with a predetermined dialled number and receives a RUN_SCRIPT_REQ message that contains the Id of the script to be run. It then sends a RUN_SCRIPT_RESULT message and closes the dialog by sending an EVENT_REPORT message. Service Control Dialogues are not closed until an EVENT report is sent. In a real flow, you would use a Call Receive Dialog Step to receive information such as Called Number, Calling Number etc. You can then use this information to populate the fields in the Send New Call Message component. Also, in a real flow, you would do some processing such as running a sub dialog or flow once you have received a response to the NEW_CALL message. It is important to note that NEW_CALL is only one of the messages that can be sent to ICM. Between the time a response is received for NEW_CALL and a RUN_SCRIPT_RESULT, the SAB application is free to run or not run a dialog flow or execute a process. In normal conditions, SAB should execute some process or flow before the RUN_SCRIPT_RESULT is returned. However, if ICM returns a DIALOG_FAILURE_EVENT or an invalid script id, SAB may not execute any process and can immediately return a SUN_SCRIPT_RESULT message, followed by an EVENT_REPORT message. Refer to the GED125V29 CISCO ICM specification for more information on these messages and the context in which they are sent and received. Figure 2. Simple Flow Sending a NEW_CALL Intelligent Contact Management Gateway Configuration and Deployment Guide May 15, 2004 page 8 of 23

9 Simple Flow that Receives Two RUN_SCRIPT_REQ Messages This flow is the same as the Simple Flow Sending A NEW_CALL, except that a RUN_SCRIPT_RESULT message results in the application receiving a second RUN_SCRIPT_REQ. This happens if the result code in the RUN_SCRIPT_RESULT is set to true. You might run different dialogs based on the ScriptID returned by the ICM in the respective RUN_SCRIPT_REQ messages. Figure 3. Simple Flow That Receives Two RUN_SCRIPT_REQ Messages Intelligent Contact Management Gateway Configuration and Deployment Guide May 15, 2004 page 9 of 23

10 Flow Based on a Response to a REQUEST_INSTRUCTION The illustration below is an example of how application steering is implemented based on a ScriptID returned by the ICM in response to a REQUEST_INSTRUCTION message. The flow branches to execute either of the sub dialogues Run VR App 1 or Run VR App 2, based on the scriptid. Other process steps include Send Request Instruction, Run VR App 1, Run VR App 2, Send Run Script Result and Send Event Report. Figure 4. Sample Flow Based on a REQUEST_INSTRUCTION Response Intelligent Contact Management Gateway Configuration and Deployment Guide May 15, 2004 page 10 of 23

11 System Requirements Hardware Requirements Item Operating system Processor Available hard disk space RAM Network Card Requirement Win2k Server/ Win2k professional, Windows NT with service pack 5.0+k/ Linux/ Solaris (Sun sparc and X386 versions Intel Pentium III 1.3 GHz or higher or similar processor. 1GB free HDD space 1 GB RAM or more Yes Software Requirements Item J2EE 1.3 compliant application server Requirement Preferred Vendors: JBOSS 3.0 with Tomcat Websphere 4.0+ Weblogic 6.1 sp2 J2EE 1.3 version or above Java 2 Platform, Standard Edition J2SE Operating Systems Any of the following: Windows NT service pack 5.0+, Win2k professional or Win2k server Linux Unix Solaris (Sun sparc and X86 versions) Intelligent Contact Management Gateway Configuration and Deployment Guide May 15, 2004 page 11 of 23

12 Application Environment Configuration Physical Architecture The following software must be installed and running for any dialog flow that uses Intelligent Contact Management (ICM) components: ICM or ICM emulator software At least one Peripheral Gateway configured to communicate with the SAB ICM Gateway Speech Applications Builder (SAB) ICM Gateway A JMS provider such as the JBOSSMQ Figure 5. Complex Application Scenario with ICM Support Intelligent Contact Management Gateway Configuration and Deployment Guide May 15, 2004 page 12 of 23

13 Logical Architecture The figure below illustrates the logical architecture of SAB with the ICM Gateway. Figure 6. Logical Architecture of SAB with ICM Support Intelligent Contact Management Gateway Configuration and Deployment Guide May 15, 2004 page 13 of 23

14 Deployment To begin deployment of the ICM, you must install it on your server, and then make a few minor configuration changes as needed. Start by editing the Vru.properties file, and then the PGMapping.xml file. The following sections describe the procedures for installing and editing these files. 1. Unpack vur-icm-adaptor.zip to a directory of your choice. 2. Proceed with editing the Vru.properties file. Editing the Vru.properties File The Vru.properties file contains default settings that do not require change but can be modified if necessary. Appendix A provides a sample properties file for reference. If your setup requires configuration changes, edit the properties file as follows: 1. Navigate to the conf folder located in the directory where you unpacked vur-icm-adaptor.zip. 2. Open the vru.properties file in a text editor such as Notepad. 3. The LISTEN_PORT property contains a setting that can remain unchanged or be modified if necessary. When running multiple instances, each instance should have a different port number. 4. The LOCALHOST_IP property contains an IP address that can remain unchanged or be modified if you are running the SAB on a different IP address. All other properties can remain at the default settings. 5. Ensure that the settings for the JMS provider point to the node on which the JMS is running. Edit the properties to suit your JMS provider, e.g., JBoss, MQ Series. The default vru.properties file contains property settings for JBoss and also assumes that it runs on the same node as the ICM Gateway. 6. When you finish making changes, save the file and close it. Editing the PGMapping.xml File ICM uses the PGMapping.xml file to determine the JMS destinations that it should initialise with. The pgaddress-main attribute is a concatenation of the Local Host IP and Local Host Port values listed in the vru.properties file. Using this string as the key, the Queue and Topic names are read from the PGMapping.xml file. When using multiple instances of ICM, you can have mappings corresponding to all instances in one file. Refer to Appendix C Frequently Asked Questions, for more information on running multiple instances. For more detailed information on ECC variables, please refer to the GED125 specification. Edit the PGMapping.xml file, which is located in the conf directory. Table 1 below identifies and describes those mappings in the file that need to be reviewed. To view a sample PGMapping.xml file, see Appendix B. Intelligent Contact Management Gateway Configuration and Deployment Guide May 15, 2004 page 14 of 23

15 Mapping pgaddress-main pgaddress-aux receivingqueue sendingtopic ecc-var Description This is obtained by concatenating the LOCALHOST_IP address and the LISTEN_PORT value located in the vru.properties file to form a string in the following format: LOCALHOST_IP:LISTEN_PORT Can be the same as pgaddres-main. The name of the JMS queue that is set up in a JMS provider (JBOSS for example) to receive messages from a remote SAB application. For JBOSS, this can be done by adding entries to the jbossmq-destinations-service.xml file found within your JBOSS installation, typically located in: %JBOSS_HOME%/server/default/deploy The JMS destination where the ICM Gateway will send messages received from ICM. Extended Call Control variables. Your deployment may or may not use these variables. If you do use these variables, you must specify them in this file using the ecc-var element. If you do not use them, you can delete this element from the pgmapping.xml. For further details on ECC variables, please refer to the GED125 specification. Table 1: PG Mappings Starting the ICM Gateway Once you have edited the vru.properties and PGMapping.xml files, you can start the ICM Gateway by double-clicking on the RunServer.bat batch file located in the conf folder. A console window will open and display status. The runtime log for the ICM Gateway can be found in the ICMAdaptor.log file, which is located in the log directory. Refer to Appendix C Frequently Asked Questions for troubleshooting tips. Intelligent Contact Management Gateway Configuration and Deployment Guide May 15, 2004 page 15 of 23

16 Appendix A: Sample VRU.Properties File # Sample properties file MAX_CLIENTS=50 # When running multiple instances, each instance should have a different port number LISTEN_PORT=28090 #Local Host IP of the machine running the ICM. Normally LOCALHOST_IP= # Unimplemented - Multiple PIM support # # This will determine if the ICM supports single PIM or multiple PIMs. # If multiple PIMs are supported, the IP address in the PGMapping.xml # file should point to remote PG. If single PIM is supported, which also # means that a node might host multiple ICM instances, the pg-ip property in # PGMapping.xml should point to hostname and port number of this ICM # # MULTIPLE_PIM_SUPPORTED=false # Test mode # # Should be false for live deployments FAKE_MESSAGE=false # Initialisation class. Do not edit this INIT_IMPL_CLASS=com.fluencyvoice.callrouter.common.util.MessageController Intelligent Contact Management Gateway Configuration and Deployment Guide May 15, 2004 page 16 of 23

17 # JMS related settings. Edit this depending upon the JMS provider. This one is for JBOSS JMS_HOST= JMS_PORT=1099 JMS_CONTEXT_FACTORY=org.jnp.interfaces.NamingContextFactory JMS_URL_PKG_PREFIXES=org.jboss.naming:org.jnp.interfaces CONNECTION_FACTORY=ConnectionFactory # Application Level Interface - enable service control # # By default all are set to false # # The following table indicate interfaces that can be enabled together # More details are available in the GED125 specification from CISCO # # Event Data Feed Service Control Call Routing Time Sync # # X X X # X X # X # X X # X # X X # X # X USE_EVENT_FEED= USE_CALL_ROUTING= USE_TIME_SYNC= USE_SERVICE_CONTROL=true # Service Control Initialization message FEATURE_RUN_SCRIPT=true FEATURE_CONNECT=false FEATURE_CANCEL=false Intelligent Contact Management Gateway Configuration and Deployment Guide May 15, 2004 page 17 of 23

18 FEATURE_RELEASE=false FEATURE_BLIND_TRANSFER=false FEATURE_NEED_RELEASE=false # Implementing class. This class should implement the IsInitializable interface. #IMPLEMENTING_CLASS=com.energis.monitoring.HeartbeatController IMPLEMENTING_CLASS=com.fluencyvoice.callrouter.servlet.DefaultImplementingC lass # Listener count for Queue Listeners # JBoss MQ requires a connection pool much larger than this value, e.g. 4 times MAX_LISTENER_COUNT=100 # Time in seconds to wait for RUN_SCRIPT_RESULT return # -1 returns immediately RUN_SCRIPT_RESULT_WAIT_TIME=-1 # Message batching. Messages from VoiceRunner will be dispatched to ICM PG every MESSAGE_INTERVAL #milliseconds.1000 milliseconds have been found to offer good performance for moderate to #high load/soak tests MESSAGE_INTERVAL=1000 #The name of the factory to be used for obtaining a Translator instance. The default factory #that is bundled with the ICM will create a Translator Instance for translating CISCO ICM #messages confirming to GED125 version 2.9.Please consult API documentation for information on #how to implement the Factory and Translator TRANSLATOR_FACTORY_CLASS= #Under heavy load, ICM might fail to receive a HEARTBEAT_REQ from ICM. Setting the following Intelligent Contact Management Gateway Configuration and Deployment Guide May 15, 2004 page 18 of 23

19 #property to true will ensure that ICM will interpolate HEARTBEAT_CONF for missed #HEARTBEAT_REQ messages DEBUG_INTERPOLATE_HEARTBEAT=true Intelligent Contact Management Gateway Configuration and Deployment Guide May 15, 2004 page 19 of 23

20 Appendix B: Sample PGMapping.xml File <mappings> <mapping pgaddress-main=" :28090" pgaddressaux=" :28090" receivingqueue="vrutogatewayqueue" sendingtopic="vrtopic"> <ecc> <ecc-var tag="200" name="user.userecc_scalar1"/> <ecc-var tag="202" name="user.shape"/> </ecc> </mapping> <mapping pgaddress-main=" :28090" pgaddressaux=" :28090" receivingqueue="receivingqueue" sendingtopic="vrtopic" > </mapping> </mappings> Intelligent Contact Management Gateway Configuration and Deployment Guide May 15, 2004 page 20 of 23

21 Appendix C: Frequently Asked Questions How do I know if the Speech Applications Builder (SAB) ICM Gateway is running? If the ICM Gateway is: Running; Waiting for a PG to connect; In a session maintenance state facilitating exchange of heartbeats between VoiceRunner and the PG; or, Attempting to obtain a heartbeat from SAB, but not succeeding; it opens a console window which will indicate the state the ICM is in. How do I deploy multiple ICM instances on the same node? This is done by making ICM s TCP listener listen to a different port. To do this: 1. Edit the vru.properties file in %VIG_HOME%\conf. 2. Change the LISTEN_PORT to a different value. 3. Execute runserver. How many ICM instances can I run per node? This is restricted by the memory available. The ICM has a very small footprint (less than 100 KB/instance). A ballpark figure would be four instances per node. When I have multiple instances of ICM, each communicating with a separate PG-PIM, how do I configure the PGMapping file on JBOSS? There is only one PGMapping.xml file on JBOSS. It contains all the mappings for all the individual ICM instances. The PGMapping.xml file on the ICM side must contain only its own mapping. It does not matter if you use the consolidated PGMapping.xml file for all ICM instances. The ICM starts and a PG tries to connect. The ICM then throws a Runtime Exception which says PGMapping file is not configured properly. Why? This is because the PGMapping file is not edited according to the instructions in the %VIG_HOME%\doc\ Installation and startup instructions for ICM.doc. Intelligent Contact Management Gateway Configuration and Deployment Guide May 15, 2004 page 21 of 23

22 The ICM tries to locate a Queue to post messages by using the LOCALHOST_IP and LISTEN_PORT as the key. It concatenates the two string values as follows. LOCALHOST_IP:LISTEN_PORT This will result in a string such as : In the PGMapping.xml file, there must be a mapping that will tie this string to the Queues. If this string is not found in the PGMapping.xml file, the above exception results. My PGMapping.xml is configured properly, but the ICM is closing the connection with this error Message received is null. This could mean that the remote PG has closed its connection or there is some network problem. In either case there is no point in keeping our side of the connection open. So we will break out of this loop and close the ICM connection. What is happening here? (This is the most difficult of all ICM errors to debug.) To begin, identify when the error occurred: If the error occurs after you received an OPEN_REQ (i.e., the ICM has actually decoded this message - you can search for the string OPEN_REQ in the log file), after the ICM has started exchanging heartbeat messages, even before the OPEN_REQ is decoded by the ICM, Then check if the JMS infrastructure has been set up properly. The ICM must be posting messages to a Queue which is not consumed by the ICMServlet (This could also mean that the war file containing ICMServlet is not deployed). Check the PGMapping file in JBOSS deployment. This should match the one used by the ICM. check the network connection, PG installation or even the ICM software for proper functioning. the bytes read off the TCP connection are incorrect. Check the ICMAdaptor.log file, located in the log folder of the ICM distribution for any signs of incorrect IP resolution. Then use the following procedures to debug: 1. Edit the vru.properties file and set the FAKE_MESSAGE property to true. By default this is set to false. 2. Ensure that the LOCALHOST_IP and LISTEN_PORT properties are set to correct values and match the settings on the PG-PIM connecting to this host. 3. Restart the ICM. You should see exchange of Heartbeats. 4. Once you eliminate any connectivity issue, stop the ICM, edit the vru.properties file, and set the FAKE_MESSAGE property to false. Follow the instructions in the ICM installation document located in the doc folder of the ICM distribution to start JBOSS and ICM. If the above procedure does not resolve the problem, and you receive the same error, try using a TCP proxy such as the Advanced TCP Logger, which can be downloaded from to debug the problem. The key point is to ensure that the second byte read from the stream is 3, which is how ICM encodes an OPEN_REQ. Any other value could mean that the PG is not set up to communicate with the correct peripheral (which is VRU). Intelligent Contact Management Gateway Configuration and Deployment Guide May 15, 2004 page 22 of 23

23 Why do I need the JMSMapping file? While each VoiceRunner installation has an ICMServlet deployed for maintaining a session with all configured PGs for that node, a VoiceRunner application may want to receive call control messages from a PG, which is not initialized by its own ICMServlet. This means that VoiceRunner will need to resolve the IP address of a JMS provider at run time. It does this by accepting the IP address of the ICM that listens to the remote Queue and then looking up the JMS provider s IP address and port from the JMSmapping.xml file. The system throws a Runtime Exception which says JMSMapping file not configured properly. when trying to send a call control message (NEW_CALL, REQUEST_INSTRUCTION) etc. Why? You must edit the JMS mapping file, which contains mappings for all the ICM instances running in a given site (not just the local ICM instances) so that a VoiceRunner application can send a message to any PG-PIM (not just its own). Therefore, the JMSMapping.xml file must contain the mappings for all ICM IPs. Ensure that there is a mapping for the ICM IP address you are trying to use. Intelligent Contact Management Gateway Configuration and Deployment Guide May 15, 2004 page 23 of 23