Avaya Speech Applications Builder Intelligent … Speech Applications Builder Intelligent Contact...

Avaya Speech Applications BuilderIntelligent Contact Management (ICM) GatewayConfiguration and Deployment GuideMay 15, 2004

Intelligent Contact Management Gateway Configuration and Deployment Guide • May 15, 2004 • page 2 of 23

© 2004 Avaya Inc.

All Rights Reserved.

Notice

While reasonable efforts were made to ensure that theinformation in this document was complete and accurate at thetime of printing, Avaya Inc. can assume no liability for any errors.Changes and corrections to the information in this documentmay be incorporated in future releases.

Preventing toll fraud

"Toll fraud" is the unauthorized use of your telecommunicationssystem by an unauthorized party (for example, anyone who isnot a corporate employee, agent, subcontractor, or personworking on your company's behalf). Be aware that there may bea risk of toll fraud associated with your system and that, if tollfraud occurs, it can result in substantial additional charges foryour telecommunications services.

Avaya fraud intervention

If you suspect that you are being victimized by toll fraud and youneed technical assistance or support, call Technical ServiceCenter Toll Fraud Intervention Hotline at +1-800-643-2353 forthe United States and Canada. For additional support telephonenumbers, see the Avaya Web site:

http://www.avaya.com

Select Support, then select Escalation Lists. This Web siteincludes telephone numbers for escalation within the UnitedStates. For escalation telephone numbers outside the UnitedStates, select Global Escalation List.

Providing telecommunications security

Telecommunications security (of voice, data, and videocommunications) 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 boththis Avaya product and any other voice/data/video equipmentthat 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'sbehalf. Whereas, a "malicious party" is anyone (includingsomeone who may be otherwise authorized) who accesses yourtelecommunications equipment with either malicious ormischievous intent.

Such intrusions may be either to/through synchronous (time-multiplexed and/or circuit-based) or asynchronous (character-,message-, or packet-based) equipment or interfaces for reasonsof:

• Use (of capabilities special to the accessedequipment)

• Theft (such as, of intellectual property, financialassets, or toll-facility access)

• Eavesdropping (privacy invasions to humans)

• Mischief (troubling, but apparently innocuous,tampering)

• Harm (such as harmful tampering, data loss oralteration, regardless of motive or intent)

Be aware that there may be a risk of unauthorized intrusionsassociated with your system and/or its networked equipment.Also realize that, if such an intrusion should occur, it could resultin a variety of losses to your company (including, but not limitedto, human and data privacy, intellectual property, materialassets, financial resources, labor costs, and legal costs).

Your responsibility for your company's telecommunicationssecurity

The final responsibility for securing both this system and itsnetworked equipment rests with you, an Avaya customer'ssystem administrator, your telecommunications peers, and yourmanagers. Base the fulfillment of your responsibility on acquiredknowledge 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 systemsand their interfaces

• Your Avaya-provided software applications, as well astheir underlying hardware/software platforms andinterfaces

• Any other equipment networked to your Avayaproducts.

Part 15: Class A Statement

For the MCC1, SCC1, G600, and CMC1 Media Gateways:

Note: This equipment has been tested and found to comply withthe limits for a Class A digital device, pursuant to Part 15 of theFCC Rules. These limits are designed to provide reasonableprotection against harmful interference when the equipment isoperated in a commercial environment. This equipmentgenerates, uses, and can radiate radio frequency energy and, ifnot 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 tocause harmful interference, in which case the user will berequired 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 withthe limits for a Class B digital device, pursuant to Part 15 of theFCC Rules. These limits are designed to provide reasonableprotection against harmful interference in a residentialinstallation. This equipment generates, uses, and can radiateradio-frequency energy and, if not installed and used inaccordance with the instructions, may cause harmful interferenceto radio communications. However, there is no guarantee thatinterference will not occur in a particular installation. If thisequipment does cause harmful interference to radio or televisionreception, which can be determined by turning the equipment offand on, the user is encouraged to try to correct the interferenceby one or more of the following measures:

• Reorient the receiving television or radio antennawherethis may be done safely.

• To the extent possible, relocate the receiver withrespect to the telephone equipment.

• Where the telephone equipment requires AC power,plug the telephone into a different AC outlet so that thetelephone equipment and receiver are on differentbranch circuits.

• Consult the Dealer or an experienced radio/TVtechnician for help.


Canadian Department of Communications (DOC)Interference Information

For MCC1, SCC1, G600, and CMC1 Media Gateways:

This Class A digital apparatus complies with Canadian ICES-003.

Cet appareil numérique de la classe A est conforme à la normeNMB-003 du Canada.


This Class B digital apparatus complies with Canadian ICES-003.

Cet appareil numérique de la classe B est conforme à la normeNMB-003 du Canada.

This equipment meets the applicable Industry Canada Terminal

Equipment Technical Specifications. This is confirmed by theregistration number. The abbreviation, IC, before the registrationnumber signifies that registration was performed based on aDeclaration of Conformity indicating that Industry Canadatechnical specifications were met. It does not imply that IndustryCanada 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 VoluntaryControl Council for Interference by Information TechnologyEquipment (VCCI). If this equipment is used in a domesticenvironment, radio disturbance may occur, in which case, theuser may be required to take corrective actions.


This is a Class B product based on the standard of the VoluntaryControl Council for Interference by Information TechnologyEquipment (VCCI). If this equipment is used in a domesticenvironment, radio disturbance may occur, in which case, theuser may be required to take corrective actions.

Part 15: Personal Computer Statement

This equipment has been certified to comply with the limits for aClass B computing device, pursuant to Subpart J of Part 15 ofFCC Rules. Only peripherals (computing input/output devices,terminals, printers, etc.) certified to comply with the Class B limitsmay be attached to this computer. Operation with noncertifiedperipherals is likely to result in interference to radio andtelevision reception.

Part 68: Answer-Supervision Signaling

Allowing this equipment to be operated in a manner that doesnot provide proper answer-supervision signaling is in violation ofPart 68 rules. This equipment returns answer-supervision signalsto the public switched network when:

• answered by the called station,

• answered by the attendant, or

• routed to a recorded announcement that can beadministered by the CPE user.

This equipment returns answer-supervision signals on all directinward dialed (DID) calls forwarded back to the public switchedtelephone 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 thatthe Avaya switch equipment described in this document andbearing a TIA TSB-168 label identification number complies withthe Federal Communications Commission’s (FCC) Rules andRegulations 47 CFR Part 68, and the Administrative Council onTerminal Attachments (ACTA) adopted technical criteria.

Avaya further asserts that Avaya handset equipped terminalequipment described in this document complies with Paragraph68.316 of the FCC Rules and Regulations defining Hearing AidCompatibility and is deemed compatible with hearing aids.Copies of SDoCs signed by the Responsible Party in the US canbe obtained by contacting your local sales representative andare available on the following Web site:

http://www.avaya.com/support

All Avaya switch products are compliant with Part 68 of the FCCrules, but many have been registered with the FCC before theSDoC process was available. A list of all Avaya registeredproducts may be found at:

http://www.part68.org/

by conducting a search using "Avaya" as manufacturer.

European Union Declarations of Conformity

Avaya Inc. declares that the equipment specified in thisdocument bearing the "CE" (Conformité Europeénne) markconforms to the European Union Radio and TelecommunicationsTerminal Equipment Directive (1999/5/EC), including theElectromagnetic Compatibility Directive (89/336/EEC) and LowVoltage Directive (73/23/EEC). This equipment has beencertified to meet CTR3 Basic Rate Interface (BRI) and CTR4Primary Rate Interface (PRI) and subsets thereof in CTR12 andCTR13, as applicable. Copies of these Declarations ofConformity (DoCs) signed by the Vice President of R&D, AvayaInc., can be obtained by contacting your local salesrepresentative and are available on the following Web site:


TCP/IP facilities

Customers may experience differences in product performance,reliability, and security, depending upon networkconfigurations/design and topologies, even when the productperforms as warranted.

Warranty

Avaya Inc. provides a limited warranty on this product. Refer toyour sales agreement to establish the terms of the limitedwarranty. In addition, Avaya’s standard warranty language, aswell as information regarding support for this product, whileunder warranty, is available through the following Web site:


Link disclaimer

Avaya Inc. is not responsible for the contents or reliability of anylinked Web sites and does not necessarily endorse the products,services, or information described or offered within them. Wecannot guarantee that these links will work all of the time and wehave no control over the availability of the linked pages.


Trademarks

Avaya is a trademark of Avaya Inc.

Insert all other Avaya Trademarks here, then delete thisparagraph. DO NOT include other company’s trademarks.

All trademarks identified by the ® or ™ are registeredtrademarks or trademarks, respectively, of Avaya Inc. All othertrademarks are the property of their respective owners.

Ordering information: Avaya Publications Center

Voice: +1-207-866-6701

1-800-457-1764 (Toll-free, U.S. and Canada only)

Fax: +1-207-626-7269

1-800-457-1764 (Toll-free, U.S. and Canada only)

Write: Globalware Solutions

200 Ward Hill Avenue

Haverhill, MA 01835 USA

Attention: Avaya Account Manager

Web: http://www.avayadocs.com

E-mail: [email protected]

Order:

Avaya support

Avaya provides a telephone number for you to use to reportproblems or to ask questions about your contact center. Thesupport telephone number is1-800-242-2121 in the UnitedStates. For additional support telephone numbers, see the AvayaWeb site:

http://www.avaya.com

Select Support, then select Escalation Lists. This Web siteincludes telephone numbers for escalation within the UnitedStates. For escalation telephone numbers outside the UnitedStates, select Global Escalation List.

Comments

To comment on this document, send e-mail [email protected].

Acknowledgment

This document was written by the CRM InformationDevelopment group.


Contents

Contents ............................................................................................................................................. 5Introduction........................................................................................................................................ 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...................................................................................................................... 11

Hardware Requirements 11

Software Requirements 11

Application Environment Configuration ......................................................................................... 12

Physical Architecture 12

Logical Architecture 13

Deployment ...................................................................................................................................... 14

Editing the Vru.properties File 14

Editing the PGMapping.xml File 14

Starting the ICM Gateway 15

Appendix A: Sample VRU.Properties File ....................................................................................... 16Appendix B: Sample PGMapping.xml File ...................................................................................... 20Appendix C: Frequently Asked Questions...................................................................................... 21


Introduction

Scope and Purpose

This manual describes the configuration and deployment process of the Intelligent ContactManagement (ICM) Gateway. For instructions on deploying other components within the logicalarchitecture, refer to their respective configuration guides.

Targeted Audience

This manual is intended for systems administrators, architects, and technical resources involved in theICM 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


The Intelligent Contact Management (ICM) Gateway

Overview

Intelligent Contact Management (ICM) is a Cisco system that implements enterprise-wide calldistribution across call centres. ICM software provides Pre-Routing, Post-Routing, and performancemonitoring capabilities.

One or more Speech Applications Builder (SAB) applications can be deployed within a contact centreinfrastructure for providing a variety of services. Within this context, a SAB application acts like aVoice Response Unit (VRU) where it must be able to interact with CISCO ICM so that it can receivecall control instructions from the latter. This sort of communication is facilitated by pre-built ICMcomponents 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 detailson 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 belowshows a flow for an organization that has its own Peripheral Gateway, which contains routing scriptsfor all their trunks.

A peripheral gateway can support up to 32 Peripheral Interface Managers (PIM) and each PIM can beconfigured to connect to a different ICM. This configuration enables an organization to achieve a verycost-effective solution against failure of JMS backbone or the ICM without using expensive clusteringsolutions.

Figure 1. Sample Logical View


Simple Flow Sending a NEW_CALL

On a high level, this flow receives a call, sends the ICM a NEW_CALL message with a pre-determined dialled number and receives a RUN_SCRIPT_REQ message that contains the Id of thescript to be run. It then sends a RUN_SCRIPT_RESULT message and closes the dialog by sendingan EVENT_REPORT message. Service Control Dialogues are not closed until an EVENT report issent.

In a real flow, you would use a Call Receive Dialog Step to receive information such as CalledNumber, Calling Number etc. You can then use this information to populate the fields in the Send NewCall Message component. Also, in a real flow, you would do some processing such as running a subdialog or flow once you have received a response to the NEW_CALL message. It is important to notethat 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 SABapplication is free to run or not run a dialog flow or execute a process. In normal conditions, SABshould execute some process or flow before the RUN_SCRIPT_RESULT is returned. However, if ICMreturns a DIALOG_FAILURE_EVENT or an invalid script id, SAB may not execute any process andcan immediately return a SUN_SCRIPT_RESULT message, followed by an EVENT_REPORTmessage. Refer to the GED125V29 CISCO ICM specification for more information on thesemessages and the context in which they are sent and received.

Figure 2. Simple Flow Sending a NEW_CALL


Simple Flow that Receives Two RUN_SCRIPT_REQ Messages

This flow is the same as the Simple Flow Sending A NEW_CALL, except that aRUN_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 differentdialogs 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


Flow Based on a Response to a REQUEST_INSTRUCTION

The illustration below is an example of how application steering is implemented based on a ScriptIDreturned by the ICM in response to a REQUEST_INSTRUCTION message. The flow branches toexecute either of the sub dialogues Run VR App 1 or Run VR App 2, based on the scriptID. Otherprocess steps include Send Request Instruction, Run VR App 1, Run VR App 2, Send Run ScriptResult and Send Event Report.

Figure 4. Sample Flow Based on a REQUEST_INSTRUCTION Response


System Requirements

Hardware Requirements

Item Requirement

Operating system Win2k Server/ Win2k professional, Windows NT with servicepack 5.0+k/ Linux/ Solaris (Sun sparc and X386 versions

Processor Intel Pentium III 1.3 GHz or higher or similar processor.

Available hard disk space 1GB free HDD space

RAM 1 GB RAM or more

Network Card Yes

Software Requirements

Item Requirement

J2EE 1.3 compliant applicationserver

Preferred Vendors:

• JBOSS 3.0 with Tomcat 4.1.1.2+

• Websphere 4.0+

• Weblogic 6.1 sp2 J2EE 1.3 version or above

Java 2 Platform, Standard Edition J2SE 1.3.1

Operating Systems Any of the following:

• Windows NT service pack 5.0+, Win2k professional orWin2k server

• Linux

• Unix

• Solaris (Sun sparc and X86 versions)


Application Environment Configuration

Physical Architecture

The following software must be installed and running for any dialog flow that uses Intelligent ContactManagement (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


Logical Architecture

The figure below illustrates the logical architecture of SAB with the ICM Gateway.

Figure 6. Logical Architecture of SAB with ICM Support


Deployment

To begin deployment of the ICM, you must install it on your server, and then make a few minorconfiguration changes as needed. Start by editing the Vru.properties file, and then thePGMapping.xml file. The following sections describe the procedures for installing and editing thesefiles.

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 ifnecessary. Appendix A provides a sample properties file for reference. If your setup requiresconfiguration 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 ifnecessary. When running multiple instances, each instance should have a different portnumber.

4. The LOCALHOST_IP property contains an IP address that can remain unchanged or bemodified 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 defaultvru.properties file contains property settings for JBoss and also assumes that it runs on thesame 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. ThepgAddress-main attribute is a concatenation of the Local Host IP and Local Host Port values listed inthe vru.properties file. Using this string as the key, the Queue and Topic names are read from thePGMapping.xml file. When using multiple instances of ICM, you can have mappings corresponding toall instances in one file. Refer to Appendix C – Frequently Asked Questions, for more information onrunning multiple instances. For more detailed information on ECC variables, please refer to theGED125 specification.

Edit the PGMapping.xml file, which is located in the conf directory. Table 1 below identifies anddescribes those mappings in the file that need to be reviewed. To view a sample PGMapping.xml file,see Appendix B.


Mapping Description

pgAddress-main This is obtained by concatenating the LOCALHOST_IP address and theLISTEN_PORT value located in the vru.properties file to form a string in thefollowing format:

LOCALHOST_IP:LISTEN_PORT

pgAddress-aux Can be the same as pgAddres-main.

receivingQueue The name of the JMS queue that is set up in a JMS provider (JBOSS forexample) to receive messages from a remote SAB application. For JBOSS, thiscan be done by adding entries to the jbossmq-destinations-service.xml file foundwithin your JBOSS installation, typically located in:%JBOSS_HOME%/server/default/deploy

sendingTopic The JMS destination where the ICM Gateway will send messages received fromICM.

ecc-var Extended Call Control variables. Your deployment may or may not use thesevariables. If you do use these variables, you must specify them in this file usingthe ecc-var element. If you do not use them, you can delete this element from thepgMapping.xml. For further details on ECC variables, please refer to the GED125specification.

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 bydouble-clicking on the RunServer.bat batch file located in the conf folder. A console window will openand 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 fortroubleshooting tips.


Appendix A: Sample VRU.Properties File

# Sample properties file

MAX_CLIENTS=50

# When running multiple instances, each instance should have a differentport number

LISTEN_PORT=28090

#Local Host IP of the machine running the ICM. Normally 127.0.0.1

LOCALHOST_IP=127.0.0.1

# 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 propertyin

# 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


# JMS related settings. Edit this depending upon the JMS provider. This oneis for JBOSS

JMS_HOST=127.0.0.1

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


FEATURE_RELEASE=false

FEATURE_BLIND_TRANSFER=false

FEATURE_NEED_RELEASE=false

# Implementing class. This class should implement the IsInitializableinterface.

#IMPLEMENTING_CLASS=com.energis.monitoring.HeartbeatController

IMPLEMENTING_CLASS=com.fluencyvoice.callrouter.servlet.DefaultImplementingClass

# Listener count for Queue Listeners

# JBoss MQ requires a connection pool much larger than this value, e.g. 4times

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 PGevery MESSAGE_INTERVAL

#milliseconds.1000 milliseconds have been found to offer good performancefor 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 fortranslating CISCO ICM

#messages confirming to GED125 version 2.9.Please consult API documentationfor 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


#property to true will ensure that ICM will interpolate HEARTBEAT_CONF formissed #HEARTBEAT_REQ messages

DEBUG_INTERPOLATE_HEARTBEAT=true


Appendix B: Sample PGMapping.xml File

<mappings> <mapping pgAddress-main="10.9.66.171:28090" pgAddress-aux="10.9.66.172: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="10.9.66.134:28090" pgAddress-aux="10.9.66.1:28090" receivingQueue="receivingQueue"sendingTopic="VRTopic" > </mapping>

</mappings>


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 andthe 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 100KB/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 individualICM instances. The PGMapping.xml file on the ICM side must contain only its own mapping. It doesnot 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 Exceptionwhich 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.


The ICM tries to locate a Queue to post messages by using the LOCALHOST_IP and LISTEN_PORTas the key. It concatenates the two string values as follows.

LOCALHOST_IP:LISTEN_PORT

This will result in a string such as 10.10.10.10:28909. In the PGMapping.xml file, there must be amapping that will tie this string to the Queues. If this string is not found in the PGMapping.xml file, theabove exception results.

My PGMapping.xml is configured properly, but the ICM is closing the connection withthis error “Message received is null. This could mean that the remote PG has closed itsconnection or there is some network problem. In either case there is no point in keepingour side of the connection open. So we will break out of this loop and close the ICMconnection”. 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… Then…

after you received anOPEN_REQ (i.e., the ICM hasactually decoded this message -you can search for the stringOPEN_REQ in the log file),

check if the JMS infrastructure has been set up properly. The ICMmust be posting messages to a Queue which is not consumed bythe ICMServlet (This could also mean that the war file containingICMServlet is not deployed). Check the PGMapping file in JBOSSdeployment. This should match the one used by the ICM.

after the ICM has startedexchanging heartbeat messages,

check the network connection, PG installation or even the ICMsoftware for proper functioning.

even before the OPEN_REQ isdecoded by the ICM,

the bytes read off the TCP connection are incorrect. Check theICMAdaptor.log file, located in the log folder of the ICMdistribution 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 tofalse.

2. Ensure that the LOCALHOST_IP and LISTEN_PORT properties are set to correct values andmatch 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 theFAKE_MESSAGE property to false. Follow the instructions in the ICM installation documentlocated 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 TCPproxy such as the Advanced TCP Logger, which can be downloaded fromhttp://www.kmint21.com/atcp2log/atcp2log.zip to debug the problem. The key point is to ensure thatthe second byte read from the stream is 3, which is how ICM encodes an OPEN_REQ. Any othervalue could mean that the PG is not set up to communicate with the correct peripheral (which is VRU).


Why do I need the JMSMapping file?

While each VoiceRunner installation has an ICMServlet deployed for maintaining a session with allconfigured PGs for that node, a VoiceRunner application may want to receive call control messagesfrom a PG, which is not initialized by its own ICMServlet. This means that VoiceRunner will need toresolve the IP address of a JMS provider at run time. It does this by accepting the IP address of theICM that listens to the remote Queue and then looking up the JMS provider’s IP address and portfrom the JMSmapping.xml file.

The system throws a Runtime Exception which says “JMSMapping file not configuredproperly.” 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 agiven site (not just the local ICM instances) so that a VoiceRunner application can send a message toany PG-PIM (not just its own). Therefore, the JMSMapping.xml file must contain the mappings for allICM IPs. Ensure that there is a mapping for the ICM IP address you are trying to use.

Date post:	18-Mar-2018
Category:	Documents
Upload:	trantuong
View:	228 times
Download:	3 times