Cisco ICM Interface User’s Guide - Blueworx Voice Response for AIX with DirectTalk Technology...

WebSphere Voice Response for AIX with DirectTalk

Technology

Cisco ICM Interface User’s Guide

Version 4.2

SC34-6391-02

��

Note

Before using this information and the product it supports, read the general information under “Notices” on

page 161.

Third edition (August 2008)

This edition applies to Version 4, Release 2 of IBM WebSphere Voice Response for AIX with DirectTalk Technology

(program number 5724-I07), and to all subsequent releases and modifications until otherwise indicated in new

editions. Make sure you are using the correct edition for the level of the product.

© Copyright International Business Machines Corporation 1991, 2008.

US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract

with IBM Corp.

Contents

Figures . . . . . . . . . . . . . vii

Tables . . . . . . . . . . . . . . ix

About this book . . . . . . . . . . xi

Who should use this book . . . . . . . xi

How to use this book . . . . . . . . . xi

Terms used in this book . . . . . . . . xi

Following the procedures in this book . . . xii

Typographic conventions . . . . . . . xii

Accessibility . . . . . . . . . . . . xiii

Notes on terminology . . . . . . . . xiii

Where to find more information . . . . . xiv

Useful Web sites . . . . . . . . . xiv

Making comments on this book . . . . . xiv

Chapter 1. Introduction . . . . . . . . 1

Cisco ICM custom server overview . . . . . 1

Application development for Cisco ICM . . . 3

State tables . . . . . . . . . . . . 4

Java . . . . . . . . . . . . . . 4

Chapter 2. Installing and configuring the

Cisco ICM custom server . . . . . . . 5

Installation prerequisites . . . . . . . . 5

Installation procedure . . . . . . . . . 5

Configuring your Cisco licenses . . . . . . 6

Running the installation verification test . . . 6

Migration . . . . . . . . . . . . . 7

Coexistence . . . . . . . . . . . . 7

SSI and HACMP error handling . . . . . . 7

Configuring for Java . . . . . . . . . 8

dtjenv file . . . . . . . . . . . . 8

default.cff file . . . . . . . . . . . 9

Deconfiguring Java . . . . . . . . . . 9

Chapter 3. Starting the Cisco ICM custom

server . . . . . . . . . . . . . . 11

Starting the Cisco ICM custom server

automatically . . . . . . . . . . . . 11

The Cisco ICM simulator . . . . . . . . 12

Custom server parameters . . . . . . . 12

Examples . . . . . . . . . . . . 15

Running multiple instances of the Cisco ICM

custom server . . . . . . . . . . . 17

Service definition file . . . . . . . . . 19

If you have a problem . . . . . . . . 21

Chapter 4. Application development using

state tables . . . . . . . . . . . . 23

Call Routing Interface (CRI) . . . . . . . 23

CRI custom server functions for state tables 26

Call_Cleared_Event . . . . . . . . 26

Delivered_Event . . . . . . . . . 27

Diverted_Event . . . . . . . . . . 28

Get_CallID . . . . . . . . . . . 29

Get_Route . . . . . . . . . . . . 30

Get_ServiceID . . . . . . . . . . 32

New_Transaction_Event . . . . . . . 33

Originated_Event . . . . . . . . . 34

Route_End_Event . . . . . . . . . 35

Route_Request_Event . . . . . . . . 36

Set_Call_Variables_Event . . . . . . . 38

Set_Instance_Number . . . . . . . . 39

Set_VRU_Status_Variables . . . . . . 40

Event Data Feed and Call Routing Interface

Status Codes . . . . . . . . . . . . 41

Service Control Interface (SCI) . . . . . . 42

Service Control Interface usage overview 42

Expanded Call Context Variables . . . . 43

Service Control Interface using state tables 44

SCI custom server functions for state tables 45

Cancel . . . . . . . . . . . . . 45

Connect . . . . . . . . . . . . 46

Connect_To_Resource . . . . . . . . 48

Create_DialogueID . . . . . . . . . 50

Dialogue_Failure_Conf_Send . . . . . 51

Dialogue_Failure_Event_Send . . . . . 52

Dialogue_Failure_Event_Recv . . . . . 53

Event_Report . . . . . . . . . . 54

New_Call . . . . . . . . . . . . 55

New_Call_Extended . . . . . . . . 57

New_Dialogue . . . . . . . . . . 60

Register_Variables . . . . . . . . . 61

Release . . . . . . . . . . . . . 63

Release_DialogueID . . . . . . . . 64

Request_Instruction . . . . . . . . 65

Retrieve_Index_Value . . . . . . . . 66

© Copyright IBM Corp. 1991, 2008 iii

Resource_Connected . . . . . . . . 67

Run_Script_Request . . . . . . . . 68

Run_Script_Result . . . . . . . . . 70

Run_Script_Result_Extended . . . . . 71

Chapter 5. Application development using

Java . . . . . . . . . . . . . . 75

Service Control Interface (SCI) . . . . . . 75

Service Control Interface usage overview 75

Expanded Call Context Variables . . . . 76

Service Control Interface using Java . . . 76

The Java CTICisco Application Programming

Interface . . . . . . . . . . . . . 77

CTICiscoReturn object . . . . . . . 78

CTICiscoCallVars object . . . . . . . 79

SCI custom server functions for Java . . . . 82

cancel . . . . . . . . . . . . . 82

connect . . . . . . . . . . . . 83

connectToResource . . . . . . . . . 86

dialogueFailureConfSend . . . . . . . 89

dialogueFailureEventRecv . . . . . . 90

dialogueFailureEventSend . . . . . . 91

eventReport . . . . . . . . . . . 92

newCall . . . . . . . . . . . . 93

registerVariables . . . . . . . . . 97

release . . . . . . . . . . . . 100

requestInstruction . . . . . . . . . 101

resourceConnected . . . . . . . . 103

runScriptRequest . . . . . . . . . 104

runScriptResult . . . . . . . . . 107

waitForEvent . . . . . . . . . . 110

Chapter 6. Service Control Interface

scenarios and examples . . . . . . . 111

Call #1) Arriving call not under ICM script

control (for a state table application) . . . 112

Call #2) Arriving call already under ICM

script control (for a Java application) . . . 113

Call #3) Arriving call already under ICM

script control, and the script requested to be

run does not exist (for a state table

application) . . . . . . . . . . . . 114


control, and a Cancel request is received (for

a Java application) . . . . . . . . . 115


control, and a Failed Cancel request is

received (for a state table application) . . . 116


control and receives a Release Request (for a

Java application) . . . . . . . . . . 118

Call #7) TimeOut during dialog creation (for

a state table application) . . . . . . . 120


control, and a Cancel request is received,

VRU instructed to transfer call (for a Java

application) . . . . . . . . . . . . 121

Service Control Interface codes . . . . . 123

Call Cleared causes . . . . . . . . 123

Label types . . . . . . . . . . . 123

Status codes . . . . . . . . . . 123

Status codes for a Java application . . . 128

Event codes . . . . . . . . . . . 130

Unsolicited event codes . . . . . . . 131

Appendix A. Application launch file . . . 133

Appendix B. Cisco ICM simulator . . . . 135

Set_Simulation_Variables . . . . . . . 136

Set_Simulation_Variables Parameters . . . 137

Appendix C. Cisco ICM custom server

error messages . . . . . . . . . . 139

Appendix D. Format of status and trace

data . . . . . . . . . . . . . . 153

Status data . . . . . . . . . . . . 153

Trace data . . . . . . . . . . . . 156

Printable ICM messages . . . . . . . . 160

Notices . . . . . . . . . . . . . 161

Trademarks . . . . . . . . . . . . 163

Glossary . . . . . . . . . . . . 165

List of WebSphere Voice Response and

associated documentation . . . . . . 191

WebSphere Voice Response software . . . 191

IBM hardware for use with WebSphere Voice

Response . . . . . . . . . . . . 192

Withdrawn from marketing but still

supported . . . . . . . . . . . 192

WebSphere Voice Response related products 192

WebSphere Voice Server for

Multiplatforms . . . . . . . . . . 192

Unified Messaging for WebSphere Voice

Response . . . . . . . . . . . 193

iv Cisco ICM Interface User’s Guide

AIX and the IBM pSeries computer . . . 193

HACMP . . . . . . . . . . . . 193

SS7 . . . . . . . . . . . . . 193

Integrated Services Digital Network . . . 194

Bellcore Specifications for ADSI Telephones 195

Index . . . . . . . . . . . . . 197

Contents v

vi Cisco ICM Interface User’s Guide

Figures

1. WebSphere Voice Response and ICM 1

2. Routing calls using ICM . . . . . . 2

3. Arriving call not under ICM script

control (for a state table application) . . 112

4. Arriving call already under ICM script

control (for a Java application) . . . . 113

5. Arriving call already under ICM script

control, and the script requested to be

run does not exist (for a state table

application) . . . . . . . . . . 114

6. Call #4) Arriving call not under ICM

script control, and a Cancel request is

received (for a Java application) . . . 115

7. Arriving call not under ICM control

and Failed Cancel request received (for

a state table application) . . . . . . 117


control and receives a Release Request

(for a Java application) . . . . . . 119

9. TimeOut during dialog creation (for a

state table application) . . . . . . 120


control, Cancel request received, VRU

transfers call (for a Java application) . . 122

© Copyright IBM Corp. 1991, 2008 vii

viii Cisco ICM Interface User’s Guide

Tables

1. ICM application interfaces to voice

response systems . . . . . . . . . 3

2. Format of the service definition file 19

3. Sample definition file . . . . . . . 20

4. Summary of the custom server functions 25

5. Event Data Feed and Call Routing

Interface Status Codes . . . . . . . 41

6. get methods for the CTICiscoReturn

object . . . . . . . . . . . . 78

7. get and set methods for the

CTICiscoCallVars object . . . . . . 80

8. Call Cleared causes . . . . . . . 123

9. Label types . . . . . . . . . . 123

10. Status codes . . . . . . . . . . 123

11. Status codes for a Java application 128

12. Event codes . . . . . . . . . . 130

13. Unsolicited event codes . . . . . . 131

14. Application launch file used in the

installation verification test . . . . . 133

15. Format of an application launch file 133

16. Cisco ICM custom server error

messages . . . . . . . . . . . 139

© Copyright IBM Corp. 1991, 2008 ix

x Cisco ICM Interface User’s Guide

About this book

This book explains how to install and use the Cisco ICM custom server and

how to link your IBM® WebSphere® Voice Response for AIX® with DirectTalk®

Technology system to the Cisco ICM.

GeoTel is now owned by Cisco Systems, and is called Cisco Intelligent Contact

Management software (Cisco ICM). WebSphere Voice Response for AIX

supports Cisco ICM version 1.0 through 7.0. If you want information about

later versions, contact your IBM representative. For information on Cisco ICM

functions that are supported by WebSphere Voice Response, see “Cisco ICM

custom server overview” on page 1.

Who should use this book

This book is written for the person who wants to install the Cisco ICM

custom server, configure it, and write applications that use the custom server

functions.

You should be familiar with basic programming concepts, and how to use

WebSphere Voice Response state tables and custom servers.

How to use this book

Read this book to become familiar with the Cisco ICM custom server and its

functions.

The appendixes contain reference information.

Terms used in this book

GeoTel custom server is now called Cisco ICM custom server. In this book, the

name GeoTel custom server is only used where a direct reference to the

interface is being made, for example a desciption of an example window.

Throughout this book, Cisco Intelligent Contact Management (Cisco ICM) is

referred to as the ICM.

Reference is made to trunks and trunk groups. These are terms that are used by

Cisco in their specifications.

© Copyright IBM Corp. 1991, 2008 xi

A trunk is translated to a WebSphere Voice Response channel, which is similar

to a single telephone line. A trunk group is similar to a WebSphere Voice

Response channel group. It represents a collection of channels that are all

using the same signaling process.

This book uses the Cisco terminology.

Following the procedures in this book

The procedures assume that you are already familiar with using a mouse and

window environment and that you know how to use the common actions,

such as Save, to work with information. If you are new to WebSphere Voice

Response, refer to the WebSphere Voice Response for AIX: User Interface Guide,

which tells you how to log on and log off, and use the WebSphere Voice

Response windows well.

Typographic conventions

This book uses the following typographic conventions:

boldface

Identifies an item that is in a WebSphere Voice Response window. The

item might be a keyword, an action, a field label, or a pushbutton.

Whenever one of the steps in a procedure includes a word in

boldface, look in the window for an item that is labeled with that

word.

boldface italics

Are used for emphasis. Take extra care wherever you see bold italics.

italics Identify one of the following:

v New terms that describe WebSphere Voice Response components or

concepts. A term that is printed in italics is usually followed by its

definition.

v Parameters for which you supply the actual names or values.

v References to other books.

monospace

Identifies one of the following:

v Text that you type in an AIX window. Because AIX is case sensitive,

ensure that you type the uppercase and lowercase characters exactly

as shown.

v Names of files and directories (path names).

terms used in this book

xii Cisco ICM Interface User’s Guide

Accessibility

WebSphere Voice Response for AIX is a voice application enabler. The

applications that are developed to run on WebSphere Voice Response provide

telephone access to business data and services. In this way, WebSphere Voice

Response provides accessibility for people who cannot access the data and

services by using regular Web pages or traditional graphic interfaces. These

telephone user interfaces are fully accessible to people who are blind or have

low vision and, if speech recognition is used, to people with mobility

impairments or limited hand use. Speech recognition capability can be

provided by products such as IBM WebSphere Voice Server. In addition,

support for users of Telephony Devices for the Deaf (TDD) is provided as part

of the WebSphere Voice Response product.

With WebSphere Voice Response you can perform many application

development and system administration tasks with a text editor or line

commands—these are accessible if you use a screen reader product to

interface with them. Also, the default settings of the WebSphere Voice

Response graphical user interface can be changed to produce large fonts and

high contrast colors. Details of how to use these accessibility features can be

found in the WebSphere Voice Response for AIX: User Interface Guide.

Alternatively, application development can be done with Java™ or VoiceXML

development tools that are supplied by IBM and third parties.

You can also use a screen-reader product to access the WebSphere Voice

Response publications in HTML format (for details of their availability refer to

“List of WebSphere Voice Response and associated documentation” on page

191 at the back of this book).

Notes on terminology

v A glossary of commonly-used terms is at the end of this book.

v The full product name of WebSphere Voice Response for AIX with DirectTalk®

Technology is generally abbreviated in this book to WebSphere Voice Response.

v The term pSeries™ is generically used in this book to refer both to PCI-based

RS/6000® computers and to appropriate models of the System p5™ and

pSeries ranges. (Consult your IBM representative for details of models that

are supported for use with WebSphere Voice Response.) RS/6000 computers

with an MCA bus are not supported.

v The IBM Quad Digital Trunk Telephony PCI Adapter is generally referred to in

this book by its abbreviation DTTA. This adapter is a replacement for the

IBM ARTIC960RxD Quad Digital Trunk PCI Adapter, which is generally

referred to by the abbreviation DTXA.

v References made to the VoiceXML 2.1 specification are intended to include

VoiceXML 2.0 unless otherwise specified.

accessibility

About this book xiii

Where to find more information

The information provided in the WebSphere Voice Response library will help

you complete WebSphere Voice Response tasks more quickly. A complete list

of the available books and where you can obtain them is shown in “List of

WebSphere Voice Response and associated documentation” on page 191.

Useful Web sites

The following Web sites are useful sources of information about WebSphere

Voice Response and related products:

IBM WebSphere voice products

Select the Products link on the Pervasive Computing Software home

page at http://www.ibm.com/software/pervasive

IBM WebSphere developerWorks resources (including WebSphere Voice

products)

http://www.ibm.com/developerworks/websphere

VoiceXML Version 2.0 and 2.1 specifications

http://www.voicexml.org/spec.html

CCXML Version 1.0 specification

http://www.w3.org/TR/ccxml

CallPath

For more information on CallPath products go to the Genesys Web

site at http://www.genesyslab.com

Making comments on this book

If you especially like or dislike anything about this book, feel free to send us

your comments.

You can comment on what you regard as specific errors or omissions, and on

the accuracy, organization, subject matter, or completeness of this book. Please

limit your comments to the information that is in this book and to the way in

which the information is presented. Speak to your IBM representative if you

have suggestions about the product itself.

When you send us comments, you grant to IBM a nonexclusive right to use or

distribute the information in any way it believes appropriate without

incurring any obligation to you.

You can get your comments to us quickly by sending an e-mail to

[email protected]. Alternatively, you can mail your comments to:

User Technologies

IBM United Kingdom Laboratories,

where to find more information

xiv Cisco ICM Interface User’s Guide

Mail Point 095, Hursley Park,

Winchester, Hampshire, SO21 2JN, United Kingdom

Please ensure that you include the book title, order number, and edition date.

making comments on this book

About this book xv

making comments on this book

xvi Cisco ICM Interface User’s Guide

Chapter 1. Introduction

The Cisco ICM custom server is an integrated component of WebSphere Voice

Response for AIX. It allows you to use the ICM over a TCP/IP link (see

Figure 1.)

The ICM allows you to create an organization-wide virtual call center and

provide improved call distribution performance. For more information about

the ICM, see Cisco’s Web pages at http://www.cisco.com.

This chapter gives you a short summary of the Cisco ICM custom server. The

following chapters tell you about installing this component, checking the

installation, and writing applications to use the Cisco ICM custom server.

Cisco ICM custom server overview

The Cisco ICM custom server enables a WebSphere Voice Response system to

communicate with an ICM over a TCP/IP link. The ICM gathers information

about the state of the trunks on the WebSphere Voice Response system and

about the calls that are processed.

The ICM coordinates the delivery of voice and data to a targeted answering

resource across the organization, where the resource might be an Interactive

Voice Response (IVR) or a call center agent.

Cisco ICMcustom server

pSeries

Voiceprocessing

WebSphereVoice

ResponseCisco ICM

Call router

TCP/IP link

Figure 1. WebSphere Voice Response and ICM

© Copyright IBM Corp. 1991, 2008 1

Using network-provided data, caller-entered digits, and information obtained

from a customer-profile database, the ICM determines who is calling and why.

Real-time information is also gathered by the ICM from the call center

systems to track the resources available to meet the customer’s needs. This

combination of data is processed through user-defined routing scripts that

show a company’s business rules. This process enables the ICM to direct each

call and related data to the optimal resource anywhere in the organization.

This data can also be used to create historical reports of inbound calls,

outbound calls, abandoned calls, and the services that have been used.

Figure 2 Shows how ICM could route calls to the correct agents in an

organization.

The ICM provides five application interfaces that can be used to interface with

voice response systems. Table 1 on page 3 shows what these interfaces are, the

services that they provide, and their compatibility with WebSphere Voice

Response.

Transferringfunds Opening

accountFrench-speaking

enquiry

Call centersupervisor

Financialservicesexpert

Financialservicesexpert

French-speakingagent

Investing$50,000

CiscoICM

routingWebSphereVoiceResopnse

WebSphereVoice Responsewith Cisco ICMcustom server

Figure 2. Routing calls using ICM


2 Cisco ICM Interface User’s Guide

Table 1. ICM application interfaces to voice response systems

Application interface

name

Description of function

Compatible

with

WebSphere

Voice

Response?

Compatible

with state

table

applications?

Compatible

with Java

applications?

Event data feed

interface (EDFI)

Provides a means for the voice

response system to send status

information to the ICM for call

routing and monitoring

purposes.

Yes Yes No

Poll data feed Provides the same information

to the ICM as the event data

feed interface does, but the

real-time monitoring

information is limited.

This is offered as an interface

for voice response platforms

that cannot implement the event

data feed interface.

No, because

the event

data feed

interface is

used.

No No

Call routing interface

(CRI)

The voice response system uses

this interface to request routing

instructions for calls that must

be transferred.

Yes Yes No

Time synchronization

interface

This interface can be used to

synchronize the voice response

system clock with the ICM clock

to ensure that times are

reported consistently.

No No No

Service control

interface (SCI)

This interface is used to allow

the ICM to provide

call-handling instructions to a

voice response system.

Yes Yes Yes

The Cisco ICM custom server can be used in a standard PSTN telephony

network environment or in a Voice over IP environment and is compatible

with Cisco’s IPCC architecture.

Application development for Cisco ICM

The custom server supports input from one application programming

environment at a time. It must be started in either Java or state table mode.


Chapter 1. Introduction 3

State tables

A state table specifies the logic of the interaction of an application with callers

and contains a sequence of instructions (states) that perform the activities of a

voice application. Each state defines an action to be performed. The result of

each action controls which state is executed next. A state table can call a

custom server, invoke other state tables, and use prompts and voice segments.

The Cisco ICM application calls functions from the Cisco ICM custom server.

WebSphere Voice Response detects an incoming call and requests routing

instructions from the ICM. The ICM responds with routing instructions for the

calling application. A possible sequence of Cisco ICM custom server functions

in a routing dialog is:

v Get_CallID

v Route_Request_Event

v Get_Route

v Route_End_Event

The ability to call a custom server within an application greatly expands the

capabilities of WebSphere Voice Response.

Java

Java applications provide the same functionality as state tables do, but unlike

the proprietary state table programming environment, Java is an open

interface. Java is also very easy to integrate with other systems so call control

can be fully integrated with Cisco ICM.

WebSphere Voice Response needs to be running an instance of the Java and

VoiceXML environment to provide the interface between the Java application

and WebSphere Voice Response.

With WebSphere Voice Response for AIX, you can use Java as a wrapper layer

to integrate VoiceXML dialogs with existing state table applications. For

example, if you have state tables that provide standard dialogs or that invoke

custom servers to access databases, you can continue to use these with your

new VoiceXML applications.

A possible sequence of Java methods in a Service Control Interface dialog is:

v newCall

v waitForEvent

v runScriptRequest

v runScriptResult

application development for Cisco ICM


Chapter 2. Installing and configuring the Cisco ICM custom

server

The Cisco ICM custom server component is supplied as an installp image.

You use the smitty command of the System Management Interface Tool

(SMIT) to install it. When installing the Cisco ICM custom server, refer to the

“Installing the WebSphere Voice Response software” procedure in the

WebSphere Voice Response for AIX: Installation guide.

When you have installed the component, import the custom server and state

table. Run the installation verification test to ensure that the installation was

successful.

Installation prerequisites

Before you start installing the software:

v Ensure that you have a copy of WebSphere Voice Response for AIX:

Installation.

v Ensure that you have enough disk space for the components that you are

installing. Use the procedure described in “Ensuring you have enough

space for the new software” in WebSphere Voice Response for AIX: Installation.

Installation procedure

Install the package

1. Following the instructions that are given in “Installing the WebSphere

Voice Response software” in WebSphere Voice Response for AIX: Installation,

use SMIT to install the dirTalk.GEOTEL package.

Start WebSphere Voice Response

2. Start WebSphere Voice Response, and log in to the user account that you

use for WebSphere Voice Response administration.

Import the Cisco ICM custom server

3. From the WebSphere Voice Response Welcome window, click Applications

to open the Applications window, then click Application —> Import —>

Replace —> File to import /usr/lpp/dirTalk/sw/geotel/geotel.imp.

When the import is complete, click View —> Refresh to see the imported

objects.

The Cisco ICM custom server is put into the Cisco application.


Configuring your Cisco licenses

The Cisco ICM custom server is license-enabled software. Before you can use

the software, you must use the IBM License Use Management product to

enroll and to distribute your licenses. For instructions, see WebSphere Voice

Response for AIX: Installation.

Running the installation verification test

Run the installation verification test to check whether the Cisco ICM custom

server is correctly installed. This test uses a state table to run all the custom

server functions that are in simulation mode. The system uses the application

launch file to test the state table see Appendix A, “Application launch file,” on

page 133.

Before you run the installation verification test, ensure that WebSphere Voice

Response is running with telephony hardware enabled, and that the System

Monitor channels are “idle”.

Run the installation verification test as follows:

1. Change to the GeoTel_dir directory by entering, on a command line:

cd $CUR_DIR/ca/GeoTel_dir

2. Start the test by entering:

geotest

3. A series of messages from the Cisco ICM state table is written to the

terminal.

4. When you see the message "Exiting state table", end the test by keying

CTRL+C.

5. View the GeoTel.log file in the $OAM_LOG_PATH directory. Toward the

end of the file is the message:

All nn tests have completed successfully.

where n is a digit 0 through 9. The value of n can vary with the version of

the software.

The installation verification test has completed.

You are now ready to customize the Cisco ICM custom server. To do this see

“Custom server parameters” on page 12.

If you want to test whether the custom server works with WebSphere Voice

Response channel groups and WebSphere Voice Response channel numbering,

repeat the above instructions except for Step 2, where you must enter:

geotest -c

configuring Cisco licenses


Otherwise, physical WebSphere Voice Response trunk and channel numbers

are used.

Migration

The process for migration to this version of the custom server is the same as

the process for installation, except that the custom server must be stopped

from the Custom Server Manager window before installation.

You should backup the service definition file before you migrate to a new

version of WebSphere Voice Response or of the Cisco ICM custom server.

An automatic migration tool to move from a state table application to a Java

application is not provided as part of the WebSphere Voice Response product.

Coexistence

This upgrade to the Cisco ICM custom server replaces the old custom server

and cannot coexist with a previous version. In a cluster of WebSphere Voice

Response clients, which are not part of a single system image (SSI) cluster,

each client can have a different version of the custom server under the

following conditions:

v Each client must have a peripheral gateway (PG).

v The PG has the correct software for the version of the Cisco ICM custom

server that the client is running.

In a cluster of WebSphere Voice Response clients that are part of an SSI

cluster, the clients all run the same version of the Cisco ICM custom server.

Only one Cisco ICM custom server can be installed and run at any one time

on a single WebSphere Voice Response for AIX machine.

SSI and HACMP error handling

If a DB2® or NFS failure occur, WebSphere Voice Response client machines

handle an SSI cluster in the same way as they handle an SSI cluster that is

running HACMP.

This section relates only to the Cisco ICM custom server, not to the

application that might be accessing this custom server (the application

developer is responsible for this.) The developer is also responsible for the

handling of error conditions that occur in the application that are related to

DB2 and NFS failures.

If either a DB2 or an NFS failure occurs where an IBM WebSphere Voice

Response for AIX client is operating in an SSI cluster, the custom server

installation verification test

Chapter 2. Installing and configuring the Cisco ICM custom server 7

continues to function normally if the executable is not paged out. In this

condition, the operation is unpredictable and the custom server might fail. If it

fails, the custom server must be restarted.

When the Cisco ICM custom server informs the ICM of any change in VRU

status it does not refer to the WebSphere Voice Response run status. Therefore,

it is best that for WebSphere Voice Response clients that are running in an SSI

environment that has the Cisco component running, the ‘System Response

during Server outage’ configuration is set to ‘Busy-out all telephony channels’.

If an outage occurs, all channels are quiesced, and the Cisco ICM custom

server reports the condition to the ICM. The ICM, therefore, no longer routes

calls to that VRU if the ICM is configured so that it does not route calls to

that VRU (for example, all calls in this VRU might come from external

callers), this configuration can be set to the user’s choices. Such a use for the

configuration must be thought about when the network configuration is being

designed.

Configuring for Java

To configure Java for access to the Cisco ICM custom server, you need to edit

the dtjenv file and the configuration file default.cff. The dtjenv file is used to

initialize local environment variables in the Java environment. The default.cff

file contains definitions of all your nodes, and all your applications, and is

imported into the configuration database, config.cfd.

Full information on editing the default.cff file can be found in WebSphere Voice

Response for AIX: Developing Java applications.

This section gives information only about things that need to be specifically

configured to use the Cisco ICM custom server with Java.

dtjenv file

Note: If you have DTBE installed, you will need to edit the dtjenv file to

initialize local environment variables. If you have VRBE_XML installed,

you will not need to edit the dtjenv file.

The dtjenv file is in the following directory /usr/lpp/dirTalk/DTBE/native/aix/dtjenv. The dtjenv file contains a comment:

#

# Don’t change anything below this line

#

Directly above this commented text, you must type:

export DTJ_CLASSPATH=$DTJ_CLASSPATH:${DTBE_HOME:-/var/dirTalk/DTBE}/server/ibmcticisco.jar

SSI and HACMP error handling


This line will configure the file for use with a Java application.

default.cff file

The CTIService provides information on a plug-in factory for Computer

Telephony Integration services. To configure a service for access to the Cisco

ICM, add the following to the default.cff file:

CTIService=CiscoICM

Enabled=yes

CTIClass=com.ibm.telephony.wvr.ctiplugins.cisco.CTICiscoFactory

InitServiceString=xxxx

;

where xxxx is equal to the port number specified after the −J parameter

(information about this parameter can be found in “Custom server

parameters” on page 12.) However, defining InitServiceString is optional:

v If a port number is defined after the −J parameter (for example −J6969) then

the InitServiceString is not optional and should be InitServiceString=6969.

v If the −J parameter is used without a port, the default port number (7253)

will be used and InitServiceString does not need to be defined.

To define the voice response node for the custom server, add the following

line to the node section of the default.cff file:

CTIService=CiscoICM,default

This must be defined for the voice response node on which the custom server

is installed.

Deconfiguring Java

To deconfigure Java:

1. Remove the line of text that was added to the file dtjenv (see “dtjenv file”

on page 8.)

2. Remove the CTIService statements from the file default.cff (see “default.cff

file.”)

3. Edit the dtjenv file so that ibmcticisco.jar is referenced at the end of the

Java CLASSPATH. To do this, find the line that begins with the text:

export CLASSPATH=

and add

:${DTJ_HOME}/server/ibmcticisco.jar

to the end of the line. This step is necessary because the Java configuration

database file (config.cfd) will have had new classes from ibmcticisco.jar

configuring for Java

Chapter 2. Installing and configuring the Cisco ICM custom server 9

added as a result of configuring the CTIService for CiscoICM. These

remain in config.cfd until the next time the configuration database file is

rebuilt.

deconfiguring Java


Chapter 3. Starting the Cisco ICM custom server

Note: In this chapter, where a specific window is being referred to, the name

GeoTel custom server is used (instead of Cisco ICM custom server) as

this still appears on the product windows.

To start the Cisco ICM custom server from the WebSphere Voice Response

Welcome Window:

1. Click Operations —> Custom Server Manager.

2. Click Run Status of the GeoTel custom server.

3. Click Start.

The run status changes to ACTIVE. A process ID is filled in.

When the Cisco ICM custom server is started:

v The configuration parameters are verified.

v The service definition file is loaded and verified.

v The connection with the ICM is made. If the Cisco ICM custom server

cannot make the connection, it waits for a specified number of seconds,

then tries again.

v A snapshot of the state of the trunks and services that are available on

WebSphere Voice Response is sent to the ICM.

If any errors occur during the initialization of the Cisco ICM custom server,

the initialization ends and error messages are written to the WebSphere Voice

Response error log.

If the connection to the ICM is broken, an error is logged and the Cisco ICM

custom server tries to reconnect to the ICM. When the connection is broken, a

status code is returned to any application that is using the Cisco ICM custom

server. When the ICM is reconnected, a snapshot of the state of the trunks and

services is sent to the ICM, and an information message is logged.

Starting the Cisco ICM custom server automatically

To start the Cisco ICM custom server whenever the system is restarted:

1. Click Operations —> Custom Server Manager.

2. Click IPL Status of the GeoTel custom server.

3. Click AUTOEXEC.


The Cisco ICM simulator

By using the Cisco ICM simulator you can test your Cisco ICM custom server

and state tables when the server is not connected to an ICM. Details of the

simulator are in Appendix B, “Cisco ICM simulator,” on page 135.

Custom server parameters

For WebSphere Voice Response to communicate correctly with the ICM, you

must set some command line parameters for the Cisco ICM custom server.

The default is for the custom server to start in state table mode. Use the

following parameters to customize the behavior of the custom sever:

-A <application launch file>

Defines the name of an application launch file, which is used when

state tables are tested. See Appendix A, “Application launch file,” on

page 133.

-B <index number>

Defines the range of dialogue IDs for use by each VRU so that the

dialogue IDs that are used are unique across all VRUs in a VRU/VRU

PG pair. index number is an Integer in the range 1 through 200 that

must be unique across all VRUs in a VRU/VRU PG pair. This Integer

is used to calculate the range of dialogue IDs that each VRU uses; this

range is ((<index number> * 500000) +1) through ((<index number> +

1) * 500000).

-c Specifies that WebSphere Voice Response channel groups and logical

channel numbers are to be used for reporting data that relates to

telephony traffic to the ICM. If this parameter is not specified,

WebSphere Voice Response physical card numbers and physical

channel numbers are used when reporting telephony traffic to the

ICM.

Note: If the -J parameter is used, -c does not need to be specified as

channel groups and logical channel numbers will be used for

reporting data to the ICM by default.

-d <debug level>

Defines whether to run the custom server in debug mode.

The following values for debug level can be specified:

1 or blank

Prints the contents of messages that flow between the custom

server and the ICM.

2 Prints the following:

v The data that is printed when -d1 is specified

Cisco ICM simulator


v The contents of messages that flow between the processes

v The names of the procedures that are run

3 Prints the following:

v The data that is printed when -d2 is specified

v The contents of many of the variables

Debug information is written to the GeoTel.Log file.

-e <seconds>

Indicates that trunk group status messages should be sent every

<seconds> seconds. The time interval must be in the range 1–600

seconds; the default value is 60 seconds. Applying this parameter

modifies the behavior of the trunk group status message, such that

trunks are considered out of service if they are busy, in addition to

when they are actually out of service (blocked or unavailable). It also

allows the use of the parameter to modify the frequency at which this

check is made. This parameter should be used in environments where

trunk availability data is critical to the performance of the platform,

and where it is not possible to achieve the same results using data on

the Cisco ICM platform.

-f <service definition file name>

Defines the name of the service definition file that is described in

“Service definition file” on page 19.

-g <parameter definition file>

The fully qualified name of the parameter definition that you are

using as the configuration parameters for the custom server.

See“Running multiple instances of the Cisco ICM custom server” on

page 17 for more information.

-h <host machine name>

Defines the host (TCP/IP) name of the machine to which the Cisco

ICM simulator is to connect. It is stated as a name that is listed in the

/etc/hosts file, or as an IP address in dotted-quad notation. For

example, if the Cisco ICM custom server is on a machine called “leo”,

specify the parameter as -hleo.

-I Controls the debug informational messages that print to the

GeoTel.Log file. If this flag is provided on the command line or in the

properties window, these messages are printed. If the flag is not

provided, the messages are not printed. This parameter is useful

because it provides a level of debug that does not need such large file

sizes or use as much disk space as the -d flag does. This flag performs

this function only on Service Control Interface messages (that is, with

the -U parameter selected).

custom server parameters

Chapter 3. Starting the Cisco ICM custom server 13

-J <port number>

Instructs the custom server to start in Java mode. If you need to

change the port number of the socket connection to Java, specify a

number after the -J parameter. This number must match the

InitServiceString in the Java configuration file. If no port number is

specified, a default port number (7253) is used (and InitServiceString

will not need to be defined.) For further information see “Configuring

for Java” on page 8.

Note: If the custom server is started in Java mode, it cannot be used

with state table applications, and vice versa.

-K Indicates that the VRU supports the event data feed interface.

-L Indicates that the VRU supports the Call Routing Interface.

-l <log file name>

Defines the name of the log file into which status and trace data is

written. The default name is $OAM_LOG_PATH/GeoTel.Log. When

the simulator is running in stand-alone mode, the default name is

$OAM_LOG_PATH/GeoTel.Simulator.Log. The format of the status

and trace data is described in Appendix D, “Format of status and

trace data,” on page 153.

Each time the custom server is started, data is appended to the log

file. When the size of the log file reaches 500 000 bytes, it is renamed

by appending a date stamp to its name.

-n <number of instances>

The number of instances of the Cisco ICM custom server that you

want to run. Possible values are 1 to 5 inclusive. See “Running

multiple instances of the Cisco ICM custom server” on page 17 for

more information.

-p <port number>

Defines the TCP/IP port number that is to be used to communicate

with the ICM. The port number parameter is not required if the -s

parameter is specified. If the -s and -p parameters are both specified,

-p is used.

-s <service name>

Defines the name of the service that is held in the /etc/services file. It

is used to determine the port number that is to be used to

communicate with the ICM.

-T <test setup>

Defines how a test system is set up. To test the Cisco ICM custom

server when it is not connected to an ICM, you can use this parameter

to set up a test system. The test system can be set up either to run the

Cisco ICM simulator as an additional process of the custom server, or



to run the Cisco ICM simulator as a stand-alone process on a different

machine. See Appendix B, “Cisco ICM simulator,” on page 135. The

values for test setup can be:

1 or blank

To run the simulator as an additional process in the custom

server.

2 To run the simulator in stand-alone mode. If it is run on a

second machine, the Cisco executable must be installed on the

second machine.

-t <connection timeout>

Defines how long, in seconds, the custom server can try to connect to

the ICM before the custom server is stopped. If this parameter is

omitted, the custom server tries to connect until it succeeds, or is

stopped.

-U Indicates the VRU supports the Service Control Interface. This

parameter is ignored if the ICM is at a version that is lower than 4.

-V Indicates that the VRU supports the run script feature. This feature is

available only if the -U parameter is selected.

-W Indicates that the VRU supports the connect instruction to retarget

calls. This is available only if the -U parameter is selected.

-X Indicates that the VRU supports the release call operation. This is


-Y Indicates that the VRU supports the cancel request operation. This is


-Z Indicates that the VRU supports the blind transfer feature.

-z <time zone delta>

Defines the existing local time difference, in seconds, from UTC time

(coordinated universal time). If this parameter is not specified, the

system time zone delta is used.

Examples

In the following examples, where you are asked to enter a character string,

you can type it on the command line while in the $CUR_DIR/GeoTel_dir

directory for the GeoTel custom server (the GeoTel custom server is opened

from the Custom Server Manager window.)

1. To run the Cisco ICM custom server so that it communicates with an ICM

on host 192.9.200.2, use:

v port 44444

v A service definition called service.def

v The EDFI and CRI interfaces (enabled)



and enter the following:

GeoTel -K -h192.9.200.2 -p44444 -fservice.def


on host leo, and writes status data into my.log, use:

v Service dt6000




GeoTel -K -sdt6000 -fservice.def -lmy.log -hleo


on port 7001, and writes status data into the default log file, use:


v Channel groups and logical channel numbers for reporting telephony

traffic


and enter the following :

GeoTel -K -p7001 -fservice.def -c

4. To test a state table using the Cisco ICM simulator running on port 9000,

use:

v A service definition file called service.def



GeoTel -K -p9000 -fservice.def -T

Note: You must enter this example from the command line because you

need to be able to enter input to the Cisco ICM simulator.

5. To run the Cisco ICM custom server so that it communicates with host

192.9.200.2, and has the Run_Script, Connect, Release and Cancel

operations enabled, use:

v Port 7001


v The SCI interface (but not the EDFI or CRI interfaces enabled)


GeoTel -p7001 -h192.9.200.2 -fservice.def -U -V -W -X -Y

6. To run the Cisco ICM custom server so that it communicates with host

192.9.200.3 and has the Run_Script operation supported, use:

v Port 7001




v The SCI and EDFI interfaces enabled


GeoTel -p7001 -h192.9.200.3 -fservice.def -K -U -V

7. To test a state table using the Cisco ICM simulator running on port 8000,

that supports the Connect and Cancel operations, use:


v The SCI and EDFI interfaces enabled


GeoTel -p8000 -fservice.def -T -K -U -W -Y

Note: You must enter this example from the command line because you

need to be able to enter input to the Cisco ICM simulator.

8. To run the Cisco ICM custom server in Java mode so that it communicates

with host 192.9.200.3 and has the Run_Script operation supported, use:

v Port 7001


v The SCI interface enabled


GeoTel -p7001 -h192.9.200.3 -fservice.def -U -V -J

Running multiple instances of the Cisco ICM custom server

In some scenarios, you may want to run multiple instances of the Cisco ICM

custom server on the same WebSphere Voice Response system. In order to do

this, the system should be started with only the –n and –g parameters as

described in “Custom server parameters” on page 12. The parameter

definition file then contains all the attributes that are required for the different

custom server instances. Note that in a multi-instance environment only a

single instance may be configured to use the Java and VoiceXML

environment—multiple Java instances are not supported. The format of this

file is similar to the attributes that you specify on the command line, however

the instance number must also be specified for each parameter. For example,

to specify the debug level for an instance, the file would list –d <instance

number> <debug level>. Below is an example definition file:

-d11

-d20

-d31

-f1/home/dirTalk/current_dir/ca/GeoTel_dir/services1.def



-B11

-B22

-B33

-K1



-K2

-K3

-U1

-U2

-U3

-V1

-V2

-V3

-W1

-W2

-W3

-X1

-X2

-X3

-Y1

-Y2

-Y3

-Z1

-Z2

-Z3



Service definition file

The service definition file is used to define which services are available.

A service is a particular type of processing that a caller requires. For example,

in a software company’s call center, a caller with a question about installing

software would be directed to the Technical Support service; a caller wanting

to purchase software might be directed to the Sales service.

Assign a unique identifier for each service that you provide for your callers.

Each call that is received or started by WebSphere Voice Response is linked to

a service.

You assign a static identifier, a Service ID, to each service. The ICM uses the

Service ID to distinguish one service that is on the WebSphere Voice Response

system from another. The IDs are configured in the ICM central database and

should remain constant across WebSphere Voice Response restarts.

The ICM uses information about services to make call routing decisions. The

ICM also provides this information in real time monitor screens and historical

reports.

The format of the service definition file is as follows. The fields are separated

by one or more blanks.

Table 2. Format of the service definition file

Field name Value Data type Max size

ServiceID The number of the service STRING 9

ServiceAvailable "Y" indicates the service is

available. "N" or "n" indicate that

the service is not available

STRING 1

StateTable The name of the state table that

runs the service, ended by a blank

STRING 15

ServiceName Descriptive name of the service STRING 39

service definition file


Table 3 shows the service definition file that is used in the installation

verification test.

Table 3. Sample definition file

* Service Definition File *

ServiceID ServiceAvailable StateTable ServiceName

1 Y None General Info

2 Y GeoTel1 Problem Support

3 N GeoTel2 Not Available

4 Y GeoTel3 Account Enquiry

* The next entry is used to test outgoing calls

3001

Y S2 Number to Call

The service definition file is verified when the custom server is started or

when a request is made to obtain a ServiceID.

During verification of the file the following checks are made:

v If a record contains a non numerical value in the ServiceID field, it is

ignored. For example, in Table 3, records with "*" in the ServiceID field are

ignored.

v If the contents of the ServiceAvailable field is not "Y", the service is handled

as being unavailable.

v The ServiceName field value for a service must be unique in the file. An

error is reported if the field value is not unique.

v The StateTable field value for a service must be unique within the file. An


v The ServiceID field value for a service must be unique within the file. An


v There must be at least one available service. An error is reported if no

service is available.

v Blank lines are not permitted in the service definition file. If a blank line is

included in the file, it will cause a duplicated record error.

Each time a request is made to obtain a ServiceID, if the file has been

changed, it is reloaded and verified again. If an error is found during an

attempt to reload the file, reloading is ended and an error is logged. The Cisco

ICM custom server continues to operate with the previous version of the file.

Any errors that are in the service definition file must be corrected before the

Cisco ICM custom server can be restarted.



If you have a problem

If you have a problem that you need help to solve, gather the following

information before contacting your IBM support representative:

v The date your Cisco ICM custom server was built. You can find this in the

DTstatus.out file at the time the custom server was started.

v Trace data that is in the DTstatus.out file.

For more information on trace data, see Appendix D, “Format of status and

trace data,” on page 153.

if you have a problem


if you have a problem


Chapter 4. Application development using state tables

The state table application programming environment supports the Call

Routing Interface and the Service Control Interface. This chapter contains

information on both of these interfaces.

Call Routing Interface (CRI)

The Call Routing Interface enables WebSphere Voice Response to ask the ICM

for instructions on how to route (transfer) a call. WebSphere Voice Response

supplies information about the call that is to be routed, and the ICM returns a

label that specifies how the call is to be routed. The label is a character string

that encodes the instructions for routing the call. For example, a label might

consist of the digit-sequence that is needed to make the transfer; or it might

contain the name of a program that is to be run to make the transfer.

WebSphere Voice Response requests routing instructions by invoking the

Route_Request_Event custom server function. This function starts a dialog

between WebSphere Voice Response and the ICM that is identified by a cross

reference ID. The ICM responds with routing instructions that the calling

application obtains through the Get_Route custom server function. The

application ends the dialog by invoking the Route_End_Event custom server

function.

The sequence of custom server functions that are called in a routing dialog is:

v Get_CallID

v Route_Request_Event

v Get_Route

v Route_End_Event

WebSphere Voice Response can end the routing dialog before normal

completion. For example, the application can invoke Route_End_Event before

it invokes Get_Route in the event of a caller hanging up. If the ICM cannot

supply a route, a status code is returned from the Get_Route ReceiveData

action.

You must issue Route_End_Event to end each Call Routing dialog inside a set

time period, typically 10 seconds, from when you invoked Get_Route. The

ICM system administrator sets the time period.

To send the result of the routing dialog to the ICM, use the Route_End_Event

custom server function to set the status code to one of the following values:


0 If the routing transaction completed normally.

10 If the state table did not receive the routing data inside the specified

time.

14 If the label that the Get_Route custom server function gets is not

acceptable to the state table.

If the ICM ends the routing dialog, it specifies the result by setting the status

code (returned by the Get_Route custom server function) to one of the

following values:

5 If the dialed number that is provided in the Route_Request_Event

custom server function is not known to the ICM.

10 If the ICM times out while it waits for a Route_End_Event custom

server function to be run.

13 If the ICM cannot perform routing requests.

15 If the route request cannot be processed for any other reason.

The Call Routing Interface is also used when the ICM has routed the call to

WebSphere Voice Response by a translation route. In this condition, the ICM

has additional information that is associated with the call, and the ICM

arranges for the call to arrive at WebSphere Voice Response with a reserved

DNIS value. WebSphere Voice Response recognizes this reserved DNIS value

and uses Route_Request_Event to request the additional information that is

associated with the call; the ICM provides the additional information that it

gets by using the Get_Route custom server function.

The Cisco ICM custom server has several functions that you can call from a

state table by using SendData and ReceiveData actions. These functions are

summarized in Table 4 on page 25.

Some parameters are optional. If an optional parameter is not to be sent to the

ICM it must be coded in the state table as the null string. The maximum

length of a string (the number of allowable characters) is given in square

brackets after the data type.

The Call Routing Dialog column in Table 4 on page 25 indicates whether you

can invoke the function when a dialog is in progress. The EDFI/CRI column

in Table 4 on page 25 indicates the interface command set of which an event is

part of.

Call Routing Interface


Table 4. Summary of the custom server functions

Activity Function

Call

Routing

Dialog?

State of

trunk Page

EDFI

/CRI

A call has ended Call_Cleared_Event No ignored 26 EDFI

An inbound call has

been received

Delivered_Event Yes ignored 27 EDFI

A call has been

diverted to a new

service

Diverted_Event No busy 28 EDFI

Get an identification

for a call

Get_CallID Yes N/A 29 EDFI

Get the data to

enable the call to be

routed

Get_Route Yes busy 30 CRI

Get the number of a

service

Get_ServiceID Yes N/A 32 EDFI

The call is to be

handled as a new

call

New_Transaction_Event No busy 33 EDFI

An outbound call

has been made

Originated_Event No ignored 34 EDFI

A routing request

has ended

Route_End_Event Yes ignored 35 CRI

The call is to be

routed to another

number

Route_Request_Event No busy 36 CRI

Some variables

must be reported to

the ICM

Set_Call_Variables_Event Yes N/A 38 EDFI

Some status

information must be

reported to the ICM

Set_VRU_Status_Variables Yes N/A 40 EDFI

Call Routing Interface

Chapter 4. Application development using state tables 25

CRI custom server functions for state tables

Call_Cleared_Event

This function is invoked after the TerminateCall action or after a caller

hang-up has been detected to notify the ICM that the call has ended.

SendData

CallID (number)

Obtained using the Get_CallID custom server function.

Cause (number)

The reason for clearing the call (see Table 8 on page 123.)

ReceiveData

Status (number)

A value in the list of status codes that is given in “Event Data Feed

and Call Routing Interface Status Codes” on page 41.

CRI functions for state tables


Delivered_Event

This function is invoked after the AnswerCall action, to notify the ICM that an

inbound call has been received by WebSphere Voice Response.

SendData

CallID (number)


TrunkGroupID (number)

Set to SV177 (Current Channel Group) if the -c is specified as one of

the custom server parameters (see “Custom server parameters” on

page 12.) Otherwise set to SV166 (Physical Card Number).

TrunkNumber (number)

Set to SV165 (Logical Channel Number) if the -c is specified as one of

the custom server parameters (see “Custom server parameters” on

page 12.) Otherwise set to SV167 (Physical Channel Number).

ServiceID (number)

Obtained using the Get_ServiceID custom server function. When

ServiceID is set to -1 the DNIS must be supplied, and is used by the

ICM to derive the service attribution.

ANI (string[40]) (optional)

Set to SV186. If no ANI exists, SV186 contains ’?’ and is handled by

the custom server as an empty string.

UserToUserInfo (string[131]) (optional)

Set to SV188.

DNIS (string[32]) (optional)

Set to SV185.

ReceiveData

Status (number)



Related functions

Call_Cleared_Event notifies the ICM that the call has ended.



Diverted_Event

This function is invoked to notify the ICM that a new ServiceID is to be used

for the call.

SendData

CallID (number)


NewServiceID (number)

Obtained using the Get_ServiceID custom server function.

ReceiveData

Status (number)





Get_CallID

Get_CallID obtains a call identifier. A new number is issued each time the

function is used. This function is invoked at the start of the state table, before

a Delivered_Event, Originated_Event, or New_Transaction_Event.

SendData

No parameters.

ReceiveData

CallID (number)

The number that is assigned by WebSphere Voice Response to identify

the call.

Status (number)



Note: The CallID that is returned is an Integer in the range 1-64000. The

Get_CallID function wraps the CallID when it reaches this upper limit.



Get_Route

This function is invoked after a Route_Request_Event to obtain the data that

is sent from the ICM that relates to the route requested.

For more information on using ECC variables, see “Expanded Call Context

Variables” on page 43.

SendData

CallID (number)


CrossRefID (number)

Set by the user to identify routing dialog.

ReceiveData

LabelType (number)

The type of label:

1 Refers to the destination to which the call should be routed.

2 Indicates that the caller should receive a busy signal.

3 Indicates that the caller should receive ring-no-answer.

4 Indicates that further processing of the call is required.

5 Indicates that the default routing action should be taken.

Label (string[48])

The destination to which the call should be routed.

CallVariable1 (string[40])

Additional information relating to the call.

CallVariable... (string[40])


CallVariable10 (string[40])


Status (number)



ECCVarValueTag1 (number)(optional)

The numeric tag value by which this variable is identified.

ECCVarValueString1(string[210])(optional)

Call related data.

ECCVarValueTag... (number)(optional)




ECCVarValueString... (string[210])(optional)

Call related data.



ECCVarValueString5 (string[210])(optional)

Call related data.

ECCVarArrayTag1 (number)(optional)


ECCVarArrayIndex1 (number)(optional)

A numeric array index identifier.

ECCVarArrayString1(string[210])(optional)

Call related data.

ECCVarArrayTag... (number)(optional)


ECCVarArrayIndex (number)(optional)


ECCVarArrayString... (string[210])(optional)

Call related data.





ECCVarArrayString5 (string[210])(optional)

Call related data.

Note: If the Get_Route ReceiveData action times out, it is a good idea for the

state table to issue Route_End_Event. This causes the routing request to

be stopped and enables the state table to continue with normal call

processing. The timeout might occur, for example, when the Peripheral

Gateway (PG) does not retrieve the required call information from the

ICM inside the specified time. In this condition, the state table is most

likely to clean up the call and exit, having played the caller an

appropriate message, because it is not possible to route the call as the

caller has requested. Further attempts to retrieve the routing

information from the PG are permitted, but the likelihood of these

succeeding is low, given the initial failure.



Get_ServiceID

Get_ServiceID obtains the number that is associated with a Service. The

Service can be a state table name or a service name in the Service Definition

file (see page 19.)

SendData

CallID (number)


Service (string[40])

The service name for which a ServiceID is required.

ReceiveData

ServiceID (number)

The number that is assigned to identify the service. If a Service cannot

be found a ServiceID of zero is returned.

Status (number)





New_Transaction_Event

This function is invoked to change the CallID and ServiceID of an existing call

without disconnecting the caller.

SendData

CallID (number)


NewCallID (number)

Obtained using the Get_CallID custom server function again.

ServiceID (number)


ReceiveData

Status (number)





Originated_Event

This function is invoked after the MakeCall action, to notify the ICM that

WebSphere Voice Response has made an outbound call.

SendData

CallID (number)



Set to SV177 (Current Channel Group) if the -c is specified as one of

the custom server parameters else set to SV166 (Physical Card

Number).


Set to SV165 (Logical Channel Number) if the -c is specified as one of

the custom server parameters else set to SV167 (Physical Channel

Number).

ServiceID (number)


UsertoUserInfo (string[131]) (optional)

Set to SV188.

DigitsDialed (string[40]) (optional)

Set to the number used as the first parameter of the MakeCall action.

ReceiveData

Status (number)



Related functions

Call_Cleared_Event notifies the ICM that the call has ended.



Route_End_Event

This function is used to notify the ICM that a routing dialog has ended. Use

this function to end each routing dialog.

SendData

CallID (number)


CrossRefID (number)

Set by user to identify routing dialog.

Status (number)



ReceiveData

Status (number)





Route_Request_Event

This function is invoked to determine how to transfer a call. It is issued before

a TransferCall action.

For more information on using ECC variables, see “Expanded Call Context


SendData

CallID (number)

The ICM call variables that are associated with the call can be

updated in two ways depending on the value of CallID.

1. If a CallID that was obtained through Get_CallID is specified,

those ICM call variables that have new values specified in the

CallVariable arguments are updated.

2. If a CallID value of -1 is specified, those ICM call variables that

have new values specified in the CallVariable arguments are

updated, and the remaining ICM call variables are set to the null

string.

CrossRefID (number)

Set to identify the routing dialog. To avoid duplicate cross references

being used at the same time, use Get_CallID to generate a unique

cross reference.

DialedNumber (string[40])

Set to SV185.

ANI (string[40]) (optional)

Set to SV186. If there is no ANI, SV186 will contain ’?’ and will be

treated by the custom server as an empty string.

CED (string[40]) (optional)

Set to the caller-entered digits.

CallVariable1 (string[40]) (optional)

Set to a user-defined value.

CallVariable... (string[40]) (optional)






ECCVarValueString1 (string[210]))(optional)

Call related data.





ECCVarValueString... (string[210]))(optional)

Call related data.



ECCVarValueString5 (string[210]))(optional)

Call related data.






Call related data.



ECCVarArrayIndex... (number)(optional)



Call related data.






Call related data.

ReceiveData

Status (number)





Set_Call_Variables_Event

This function is invoked to set the values of a set of ten variables that are held

by the ICM and are associated with the call.

SendData

CallID (number)




CallVariable... (string[40]) (optional)




The following ECC variables are supported only with Service Control

Interface:




Call related data.




Call related data.




Call related data.






Call related data.








Call related data.






Call related data.

ReceiveData

Status (number)

A value in the list of status codes as listed in “Event Data Feed and

Call Routing Interface Status Codes” on page 41.

Set_Instance_Number

The Set_Instance_Number function should be issued by the state table at the

start of the application to specify with which GeoTel instance number this call

is to communicate. This function call is required only in a multi-instance

environment; calling this function when the -n parameter has not been

specified has no effect. This function call must be issued before issuing any

other function calls in a multi-instance environment.

SendData

InstanceNumber (number)

The GeoTel instance number with which this call will communicate.

ReceiveData

Status (number)

A return code of E_NO_ERROR is returned unless the instance

number is invalid, in which case E_INVALID_INSTANCE_NUMBER

is returned.



Set_VRU_Status_Variables

This function is invoked to set the values of a set of sixteen variables that are

associated with WebSphere Voice Response and are held by the ICM and are

visible to the ICM routing scripts.

SendData

CallID (number)

Obtained using the Get_CallID custom server function

StatusVariable1 (number)


StatusVariable... (number)


StatusVariable16 (number)


ReceiveData

Status (number)





Event Data Feed and Call Routing Interface Status Codes

Table 5. Event Data Feed and Call Routing Interface Status Codes

Code Description

0 No error occurred.

5 The dialed number specified is not known to the ICM.

10 A timeout has occurred.

11 The ICM is offline.

12 The request was refused because of a temporary condition.

13 The ICM routing service is not available.

14 WebSphere Voice Response did not accept the supplied route.

15 An unspecified error occurred.

100 The call ID is not valid.

101 The cause code is not valid.

102 A message transfer error has occurred.

103 An error has occurred while processing a queue.

104 The trunk group is not valid.

105 The trunk number is not valid.

106 The service ID is not available.

107 The CrossRefID is not valid. A Route_Request_Event might not have been

issued.

108 The status code is not valid.

109 The dialed number is not valid.

110 Service Definition File Error.

111 The state table name is too long.

112 The service name is too long.

113 Duplicate application name or service name.

114 Error with log file.

115 Error with input parameters.

116 Error with system management information.

117 The trunk is busy. The operation runs on an idle trunk.

118 The trunk is idle. The operation runs on a busy trunk.

119 A call routing sequence has not been ended, possibly because the

Route_End_Event custom server function has not been invoked.

120 The ICM has already ended the call routing sequence.

EDFI and CRI Status Codes


Service Control Interface (SCI)

The Service Control Interface (SCI) was introduced in version 4.1 of the ICM.

The SCI enables the ICM to determine the call handling steps that are

performed by a VRU for each call, by running a script on the ICM. This script

can exchange messages with the VRU enabling the ICM to start specific VRU

actions.

An enhancement in Cisco ICM V4.1 was the addition of the Expanded Call

Context variables. For further details of these, see “Expanded Call Context


Note: If a call is under event data feed interface (EDFI), and a SCI message is

issued against the call, the ICM fails the request. This failure is sent

back to the application by the custom server; it is the responsibility of

the application developer to handle this event.

Service Control Interface usage overview

The SCI enables an ICM Script to determine the call-handling steps that will

be performed by a VRU and to perform the requested action. The SCI must be

initialized before it is used. When initialized, the interface allows an ICM

Script to control calls that arrive at a VRU. The calls might have been

pre-routed to the VRU by the ICM, or routed to the VRU by other methods.

In either condition, a Service Control dialog must be started by the VRU for

each call that the ICM controls. The ICM Script starts the Service Control

transactions to the VRU by using a newly defined SCI message set. The VRU

processes request messages and performs the requested action.

Acknowledgment messages are sent by the VRU to indicate that a request has

been completed. The Service Control dialog ends when one of the following

conditions occurs:

v The ICM Script controlling the call has run to completion.

v The call ends.

v An unrecoverable error occurs.

The effect of this new method of call handling is that the ICM, which has

knowledge of the real time call load on a whole network, can instruct a VRU

to perform a specific task, then cancel that request at any point. For example,

this new method can be used to perform VRU queuing where a VRU is

instructed to play music to a caller while the ICM waits for a suitable agent to

become available. When an agent becomes available, the ICM can instruct the

VRU to stop playing music and transfer the call to the agent. In addition to

the request or response call control transactions, the VRU provides event

reports that indicate changes in call state. A Service Control dialog can be

defined as a conversation that is between the VRU and the ICM and consists

of one or more related call-control transactions. A Service Control dialog

Service Control Interface


provides the context under which the transactions are performed. When a

Service Control dialog has been made, the ICM controls the VRU call

handling with an ICM Script. When the ICM has taken control of a call, the

router keeps call control until the Service Control dialog is ended.

Expanded Call Context Variables

ICM version 4.1 onwards can support Expanded Call Context (ECC) Variables.

After opening a session, and before using any ECC variables, the VRU must

send a Register_Variables message to the ICM. The Register_Variables

message contains a flag for each of the ten standard call variables and an

optional list of ECC variable names.

The flags allow the VRU to select which call variables (CallVariable 1 through

CallVariable 10) it wants to receive from the ICM. The VRU is initially

assumed to have interest in all 10 standard call variables. The flags control

only the sending of the call variable values from the ICM to the VRU.

Each ECC variable name has an associated tag value, chosen by the VRU, that

is used to identify the variable in all later messages. Each ECC variable

supplied contains a tag number and a string name. The tag number identifies

the ECC variable in values to or from the VRU.

The Cisco ICM custom server allows you to register for to up to five ECC

scalar variables and five ECC arrays using the Set_Call_Variables event. Using

the Java interface, the custom server handles the sending and receiving of up

to five array indices that are members of the ECC arrays. Although you can

register for up to five arrays, you can choose how these five indices are

spread amongst the arrays. For instance you could have five arrays, each with

one index, or you might decide to have a single array with five indices.

Using the state table interface, the custom server handles the sending and

receiving of up to 30 array indices that are members of the ECC arrays. Again,

although you can register for up to 30 indices, it is your choice as to how they

are spread amongst the arrays. For example, you could have five arrays, each

with 6 indices, or you may choose to have a single array with 30 indices.

Having registered for these variables, you can then set and retrieve their

values using the functions defined in this book. Note that many of the

functions that send and retrieve data from the ICM interface allow the setting

or retrieving of up to five array indices at a time. In order to exceed this limit

for receiving data, and utilize a larger number of array indices, call the

Retrieve_Index_Value function the appropriate number of times to retrieve all

the required variables. In order to exceed the limit for sending data, utilize the

New_Call_Extended and Run_Script_Result_Extended function calls to send

the required array values.



Service Control Interface using state tables

The approach to the state table interface that supports SCI is through solicited

and unsolicited events. The solicited events are SendData and ReceiveData

actions that are issued by the state table during call processing. The

unsolicited events are SendData and ReceiveData actions that are issued by

the state table after it receives event notification from the Cisco ICM custom

server.

From the state table, the following SendData and ReceiveData actions can be

categorized accordingly:

Solicited

Create_DialogueID

Dialogue_Failure_Conf_Send

Dialogue_Failure_Event_Send

Event_Report

New_Call

New_Dialogue

Register_Variables

Release_DialogueID

Request_Instruction

Resource_Connected

Run_Script_Result

UnSolicited

Cancel

Connect

Connect_To_Resource

Dialogue_Failure_Event_Recv

Release

Run_Script_Request

The state table is responsible for periodic checking of arrived events from the

custom server. This is done through the use of the WaitEvent state table

action. This action allows the custom server to notify the state table that an

event has occurred that requires state table processing. The WaitEvent action

provides information (in SV234) that can be used in a Case state table action

to determine which SendData or ReceiveData state table action to issue to

receive the UnSolicited event. Further information on the WaitEvent action can



be found in WebSphere Voice Response for AIX: Application Development using

State Tables. Codes for UnSolicited events are in “Unsolicited event codes” on

page 131.

SCI custom server functions for state tables

Cancel

The Cancel is issued by the ICM to cancel a previously-requested operation

that is identified by its InvokeID.

The RequestID must match the InvokeID of the request that is to be canceled.

If they match and the operation is canceled, a Dialogue_Failure_Conf_Send

with a status of E_OPERATION_CANCELLED must be sent.

If they match and the operation cannot be canceled, a

Dialogue_Failure_Conf_Send with a status of

E_OPERATION_NOT_CANCELLED must be sent.

If the IDs do not match, or the ID is no longer active, a

Dialogue_Failure_Conf_Send with a status of E_INVALID_INVOKEID must

be sent.

SendData

DialogueID (number)

Obtained using the Create_DialogueID function.

ReceiveData

InvokeID (number)

An ID for this request that should be sent in the related

Dialogue_Failure_Conf_Send.

RequestID (number)

The InvokeID of the previously issued request that is to be canceled

as returned by the previous Run_Script_Request.

Status (number)

A value from the list of status codes that describes the result of this

request. See Table 10 on page 123.



Connect

The Connect is issued by the ICM to connect the call to the destination that is

identified explicitly by the label, or implicitly by the label type.

If the connect cannot be processed, a Dialogue_Failure_Event_Send with a

status of E_UNSPECIFIED_FAILURE must be sent.

SendData

DialogueID (number)


ReceiveData

LabelType (number)

The type of label that is returned in this field.

Label (string[40])

The destination to which the call must be routed.

TransferHint (number)

Only present if the VRU supports the blind transfer feature. If

Transfer Hint is present, and set to true, the VRU PG can send a

Connect or Connect_To_Resource message after this Connect.

CallVariable1 (string[40])(optional)

Additional information that is related to the call.

CallVariable... (string[40])(optional)







Call-related data.




Call-related data.




Call-related data.

SCI functions for state tables







Call-related data.






Call-related data.






Call-related data.

Status (number)





Connect_To_Resource

The Connect_To_Resource message is sent from the PG to the VRU to instruct

the VRU to disconnect the outgoing leg of an existing call (if there is an

outgoing leg) and to prepare to accept a possible Run_Script_Request. The

VRU must respond with a Resource_Connected message.

SendData

DialogueID (number)


ReceiveData

Label (string[40])











Call-related data.




Call-related data.




Call-related data.






Call-related data.








Call-related data.






Call-related data.

Status (number)





Create_DialogueID

Create_DialogueID creates a dialog identifier. A new ID is issued each time

the function is called. This function must be called before any Service Control

Interface requests are issued. The returned value is required for all later

Service Control Interface requests.

SendData

No Parameters.

ReceiveData

DialogueID (number)

The ID that is assigned by the VRU to identify the dialog.

Status (number)





Dialogue_Failure_Conf_Send

The Dialog_Failure_Conf_Send is be issued from the state table to report the

script that is requested to be run if the Run_Script_Request or Cancel finds a

problem.

It is sent in response to an operation that cannot be performed. After sending

this, the state table must receive more instruction from the ICM. If further

instruction does not arrive in a reasonable amount of time, a

Dialogue_Failure_Event_Send is sent with a status of E_TIMEOUT.

The InvokeID in the Dialogue_Failure_Conf_Send message must match the

InvokeID from the request message. If they do not match, the ICM fails the

request and causes the state table to be signaled to issue

Dialogue_Failure_Event_Recv. The return status is E_INVALID_INVOKE_ID.

SendData

DialogueID (number)


InvokeID (number)

Set to the InvokeID that is returned by Cancel or Run_Script_Request.

ErrorCode (number)

A value from the list of status codes that describes the reason for

failure of this request. See Table 10 on page 123.

ReceiveData

Status (number)






The Dialog_Failure_Event_Send is issued from the state table to report a

dialog failure that is in an unrecoverable state.

It can be sent from the state table to inform the ICM of an error, for example,

if the dialog has had a fatal failure. When the Dialog_Failure_Event_Send is

issued, the dialog is no longer active to the ICM. The dialog is still available

to the VRU so that any signaled events can be retrieved by the state table.

SendData

DialogueID (number)


ErrorCode (number)



ReceiveData

Status (number)





Dialogue_Failure_Event_Recv

The Dialog_Failure_Event_Recv is issued from the state table to receive the

ErrorCode when a dialog fails in an unrecoverable state.

It can be sent from the ICM to inform the state table of an error, for example,

if the dialog has had a fatal failure. When the Dialog_Failure_Event_Recv is

issued, the dialog is no longer active to the ICM. The dialog is still available

to the VRU so that any signaled events can be retrieved by the state table.

SendData

DialogueID (number)


ReceiveData

ErrorCode (number)



Status (number)





Event_Report

The Event_Report is issued to report that a call with a given dialog has

changed state. For more information on Event Codes, see “Event codes” on

page 130.

SendData

DialogueID (number)


EventCode (number)

The code that explains the detected event.

CauseCode (number)(optional)

The code that describes the cause of the event can be acknowledged

only if the event code is DISCONNECT or ABANDON.

ReceiveData

Status (number)





New_Call

New_Call is issued for calls arriving at the VRU that are not under ICM script

control. A Service Control dialog is created by this function. The successful

running of this function causes the received data to run a VRU based script.

New_Call is issued once during a call. If it is issued, then the

Request_Instruction is NOT issued.

If this request is successful, the ICM provides instructions in a reasonable

amount of time. If the instructions are not provided, a

Dialogue_Failure_Event_Send is sent with a status code of E_TIMEOUT.

The DialedNumber is required. If the DialedNumber is not provided, the ICM

fails the request and causes a signal to the state table to issue a

Dialogue_Failure_Event_Recv and the returned status code

E_INVALID_MESSAGE.

If the DialedNumber is not configured at the ICM, the state table is signaled

to issue a Dialogue_Failure_Event_Recv and the returned status code of

E_INVALID_DIALED_NUMBER.

If the ICM cannot provide instructions because a script is not active for the

given call type, the state table is signaled to issue a

Dialogue_Failure_Event_Recv and the returned status code E_NO_SCRIPT.

In all other fatal error conditions the state table is signaled to issue a


E_UNSPECIFIED_FAILURE.

SendData

DialogueID (number)



The ID of the trunk group on which the call arrived. Set to SV177

(Current Channel Group) if the -c is specified as one of the custom

server parameters. Otherwise set to SV166 (Physical Card Number).

When using SV177 as the TrunkGroupID, use the Assign Data state

table action to assign the value of SV177 to a numeric variable. This

variable should then be used as the value that is passed as

TrunkGroupID.


The number of the trunk on which the call arrived. Set to SV165



(Logical Channel Number) if the -c is specified as one of the custom

server parameters. Otherwise set to SV167 (Physical Channel

Number).

ServiceID (number)

The ID of the service to which this call is assigned.


The number that is used to determine the ICM call type.

ANI (string[40])(optional)

The Calling line ID of the caller.

UserToUserInfo (string[131])(optional)

The ISDN user-to-user information element.

CalledNumber (string[32])(optional)

The complete called number from the network.

DNIS (string[32])(optional)

The DNIS that is provided with the call.


Additional VRU information that is to be used when the ICM script is

run.



run.



run.




Call-related data.




Call-related data.




Call-related data.








Call-related data.






Call-related data.






Call-related data.

ReceiveData

Status (number)



New_Call_Extended

The New_Call_Extended function allows the state table interface to send up to

30 array values. The required parameters are the same as for New_Call (and

the resulting message to ICM is a New_Call) but with the ability to set more

ECC Array values.

SendData

DialogueID (number)





server parameters. Otherwise set to SV166 (Physical Card Number).

When using SV177 as the TrunkGroupID, use the AssignData state

table action to assign the value of SV177 to a numeric variable. Then

use this numeric variable as the value that is passed as

TrunkGroupID.






server parameters. Otherwise set to SV167 (Physical Channel

Number).

ServiceID (number)



The number that is used to determine the ICM call type











run.



run.



run.




Call-related data.




Call-related data.




Call-related data.








Call-related data.






Call-related data.






Call-related data.

ReceiveData

Status (number)





New_Dialogue

The New_Dialogue is issued to convert a call from Event Data Feed to a SCI

dialog. This can be issued only after an Event Data Feed Delivered_Event has

been sent for the call.

When successfully sent the call is converted to Service Control and can issue

only SCI messages. It cannot issue Event Data Feed or Call Routing Interface

messages.

This call can be issued only to an ICM of version 4.5 and above. Issuing this

call to versions below this level causes the ICM to return the error condition

E_INVALID_MESSAGE.

SendData

DialogueID (number)


CallID (number)

The CallID of the existing Event Data Feed call.

ServiceID(number)

The ID of the service for which the new call is assigned.

ReceiveData

Status (number)





Register_Variables

Register_Variables is issued to notify the ICM which Standard and Expanded

call variables the VRU is interested in for that call instance. This request is

necessary for support under ICM version 4 and above with SCI active.

SendData

DialogueID (number)


CallVarFlag1 (number)

Set to 1 if this variable is to be supplied by the ICM, or changed by

the VRU. Set to 0 if the VRU has no interest in the variable.

CallVarFlag... (number)



CallVarFlag10 (number)




A numeric tag value by which this variable is identified.


A string tag that is associated with this variable on the ICM.























ReceiveData

Status (number)





Release

The Release is issued by the ICM to release the specified call that is associated

with the specified dialog.

If the release cannot be processed, a Dialogue_Failure_Event_Send with a

status of E_UNSPECIFIED_FAILURE is sent.

SendData

DialogueID (number)


ReceiveData

Cause (number)

The reason for clearing the call (see Table 8 on page 123.)

Status (number)





Release_DialogueID

Release_DialogueID removes a dialog identifier that was previously allocated

by the Create_DialogueID function. This function must be called at the end of

the dialog or call. When this function is issued, you cannot use this

DialogueID to issue other SCI-related function calls.

SendData

DialogueID (number)

The ID that is assigned by the VRU to identify the dialog.

ReceiveData

Status (number)





Request_Instruction

Request_Instruction is issued for calls arriving at the VRU that are already

under ICM script control. The successful running of this function causes data

received to run a VRU based script.

Request_Instruction should be issued only once during a call. If it is issued,

then the New_Call should NOT be issued.


amount of time. If the Instructions are not provided, a

Dialogue_Failure_Event_Send is sent with a status code of E_TIMEOUT.


fails the request. This causes a signal to the state table to issue a


E_INVALID_MESSAGE.


given call type, the state table is signaled to issue a

Dialogue_Failure_Event_Recv and the returned status code E_NO_SCRIPT.

In all other fatal error conditions the state table is signaled to issue a



SendData

DialogueID (number)





server parameters. Otherwise, set to SV166 (Physical Card Number).

When using SV177 as the TrunkGroupID the value of SV177 should

be assigned to a numeric variable using the Assign Data state table

action. This variable should then be used as the value that is sent as

TrunkGroupID.




server parameters. Otherwise, set to SV167 (Physical Channel

Number).

ServiceID (number)

The ID of the service to which this call is attributed.



CorrelationID (string)(optional)

The Correlation ID that is provided by an INAP network.


The calling line ID of the caller.







ReceiveData

Status (number)



Retrieve_Index_Value

The Retrieve_Index_Value can be issued by the state table application to

retrieve the value of a specific array index that has been sent by the ICM. This

command must be issued by the application after the variables have been

received from the ICM (in a message that contains the ECC variables) and

before any other messages are picked up by the state table application. For

example, this could be issued directly after a Run_Script_Request has been

issued. This function can be called repeatedly to retrieve multiple index

values. If the value of the array index cannot be found then a null string is

returned. If the DialogueID cannot be found then E_INVALID_DIALOGUEID

is returned.

SendData

DialogueID (number)


ECCVarArrayTag (number)


ECCVarArrayIndex (number)

The numeric array index identifier, the value of which you wish to

retrieve.

ReceiveData

ECCVarArrayString(string[210])

The call related data stored in the specified tag and index.



Resource_Connected

The Resource_Connected message is sent from the VRU to the PG to indicate

that the VRU has finished processing a Connect_To_Resource message and to

show that it is ready to accept a Run_Script, Connect, or Connect_To_Resource

message.

SendData

DialogueID (number)


ReceiveData

Status (number)





Run_Script_Request

The Run_Script_Request is issued to receive the script and related call

information that the ICM wants run for this call instance.

If the script that is to be run cannot be found, the state table must send a

Dialogue_Failure_Conf_Send with a status of E_INVALID_SCRIPT.

If the script cannot be run because of an invalid call variable, the state table

must send a Dialogue_Failure_Conf_Send with a status of

E_CALL_VARIABLE1 ... E_CALL_VARIABLE10.

In any event, the state table must send a Run_Script_Result or

Dialogue_Failure_Conf_Send in response to the Run_Script_Request.

SendData

DialogueID (number)


ReceiveData

InvokeID (number)


Run_Script_Result or Dialog_Failure_Conf_Send.

ScriptID (string[40])

The ID of the script that is to run on the VRU.

ScriptConfiguration(string[40])

A configuration string that is configured in the ICM to select static

script options.



CallerEnteredDigits (string[40])

Digits that the caller enters.


Additional VRU information that is sent to the VRU to be used when

the script is run.



the script is run.



the script is run.






Call-related data.




Call-related data.




Call-related data.






Call-related data.






Call-related data.






Call-related data.

Status (number)





Run_Script_Result

The Run_Script_Result is issued to inform the ICM that the specified script,

requested to be run in the ReceiveData of the New_Call or

Request_Instruction, was successful.

SendData

DialogueID (number)


InvokeID (number)

Set to the InvokeID returned by Run_Script_Request.

ResultCode (number)

Set to true (1) if no errors were found actually running the script. Set

to false (0) if an error was found.



NewTransaction (number)

Set to true (1) if the VRU PIM should write a Call Termination record

into the database immediately after processing this message.










Call-related data.




Call-related data.




Call-related data.








Call-related data.






Call-related data.






Call-related data.

ReceiveData

Status (number)



Run_Script_Result_Extended

The Run_Script_Result_Extended function provides a way from the state table

interface to send up to 30 array values. The required parameters are the same

as for Run_Script_Request (and the resultant message to ICM is a

Run_Script_Request) but with the ability to set more ECC Array values.

SendData

DialogueID (number)


InvokeID (number)

Set to the InvokeID returned by Run_Script_Request.

ResultCode (number)

Set to true (1) if no errors were found when running the script. Set to

false (0) if an error was found.





NewTransaction (number)












Call-related data.




Call-related data.




Call-related data.






Call-related data.






Call-related data.








Call-related data.

ReceiveData

Status (number)





Chapter 5. Application development using Java

The Java application programming environment supports the Service Control

Interface.

Service Control Interface (SCI)

The Service Control Interface (SCI) was introduced in version 4.1 of the ICM.

The SCI enables the ICM to determine the call handling steps that are

performed by a VRU for each call, by running a script on the ICM. This script

can exchange messages with the VRU enabling the ICM to start specific VRU

actions.

An enhancement in Cisco ICM V4.1 was the addition of the Expanded Call

Context variables. For further details of these, see “Expanded Call Context



The SCI enables an ICM Script to determine the call-handling steps that will

be performed by a VRU and to perform the requested action. The SCI must be

initialized before it is used. When initialized, the interface allows an ICM

Script to control calls that arrive at a VRU. The calls might have been

pre-routed to the VRU by the ICM, or routed to the VRU by other methods.

In either condition, a Service Control dialog must be started by the VRU for

each call that the ICM controls. The ICM Script starts the Service Control

transactions to the VRU by using a newly defined SCI message set. The VRU

processes request messages and performs the requested action.

Acknowledgment messages are sent by the VRU to indicate that a request has

been completed. The Service Control dialog ends when one of the following

conditions occurs:

v The ICM Script controlling the call has run to completion.

v The call ends.

v An unrecoverable error occurs.

The effect of this new method of call handling is that the ICM, which has

knowledge of the real time call load on a whole network, can instruct a VRU

to perform a specific task, then cancel that request at any point. For example,

this new method can be used to perform VRU queuing where a VRU is

instructed to play music to a caller while the ICM waits for a suitable agent to

become available. When an agent becomes available, the ICM can instruct the

VRU to stop playing music and transfer the call to the agent. In addition to

the request or response call control transactions, the VRU provides event


reports that indicate changes in call state. A Service Control dialog can be

defined as a conversation that is between the VRU and the ICM and consists

of one or more related call-control transactions. A Service Control dialog

provides the context under which the transactions are performed. When a

Service Control dialog has been made, the ICM controls the VRU call

handling with an ICM Script. When the ICM has taken control of a call, the

router keeps call control until the Service Control dialog is ended.

Expanded Call Context Variables

ICM version 4.1 onwards can support Expanded Call Context (ECC) Variables.

After opening a session, and before using any ECC variables, the VRU must

send a Register_Variables message to the ICM. The Register_Variables

message contains a flag for each of the ten standard call variables and an

optional list of ECC variable names.

The flags allow the VRU to select which call variables (CallVariable 1 through

CallVariable 10) it wants to receive from the ICM. The VRU is initially

assumed to have interest in all 10 standard call variables. The flags control

only the sending of the call variable values from the ICM to the VRU.

Each ECC variable name has an associated tag value, chosen by the VRU, that

is used to identify the variable in all later messages. Each ECC variable

supplied contains a tag number and a string name. The tag number identifies

the ECC variable in values to or from the VRU.

Service Control Interface using Java

A Java application supporting SCI uses solicited and unsolicited events. The

solicited events are parameters and return values that are issued by the Java

application during call processing. The unsolicited events are parameters and

return values that are issued by the Java application after it receives event

notification from the Cisco ICM custom server.

From the Java application, the following methods can be categorized

accordingly:

Solicited

dialogueFailureConfSend

dialogueFailureEventSend

eventReport

newCall

registerVariables

requestInstruction

resourceConnected



runScriptResult

UnSolicited

cancel

connect

connectToResource

dialogueFailureEventRecv

release

runScriptRequest

The Java CTICisco Application Programming Interface

The Java CTICisco Application Programming Interface (API) is accessed

through the Java class CTICiscoICM. To access a Java environment from

which to call the methods, it is necessary to use the eventToCode bean. A

DTConnectionItem is needed for the call. By carrying out a

getConnectionItem() method on the actionStatusEvent object, this will return a

ConnectionItem object, which needs to be cast to a DTConnectionItem. The

DTConnectionItem is passed into this environment to create a new

CTICiscoICM object. The CTICiscoICM object is then used to call the required

methods. Here is some example code for a DTConnectionItem:

DTConnectionItem myConnectionItem = (DTConnectionItem) myActionStatusEvent.getConnectionItem();

Note: Unlike a state table application, it is not necessary to obtain a CallID or

DialogueID when interacting with the ICM.

Here is an example of how a new CiscoICM object is created:

CTICiscoICM icm = new CTICiscoICM (myConnectionItem);

CTICiscoReturn ret;

// Issue an ’eventReport’ to the ICM

Integer MyEventCode = New Integer(7); // An example eventCode to use

ret = icm.eventReport (MyEventCode, null);

// NOTE: Passing in ’null’ for optional parms if not required

// Check the returned status equals zero

Integer Status = ret.getStatus();

if (!(Status.equals (New Integer(0)))) {

// Something has gone wrong! Return the value of status

return Status;

}

// Continue with next Cisco method.....

Service Control Interface using Java

Chapter 5. Application development using Java 77

CTICiscoReturn object

The methods supported by the CTICiscoICM object all return a

CTICiscoReturn object. The CTICiscoReturn object has a get method for each

possible return property. The validity of a return property depends on which

CTICiscoICM method is invoked. The description of each of the CTICiscoICM

methods explains which return property (or properties) are valid. If a return

value is not set, the relevant get method will return null. Before a return value

is used it should be checked that the value is not equal to null.

Here is an example of how CTICiscoReturn is used:


CTICiscoReturn ret;

// Issue a ’release’ to the ICM

ret = icm.release();

// Firstly check that the Status is equal to zero


if (Status.intValue() != 0) {

// Status is non-zero. At this point an app would normally

// log this status value and return

return Status;

} else {

// Status is zero so we can pickup the CauseCode

Integer MyCauseCode = ret.getCause();

}

Each value that can be returned has a get method associated with it, for

example, getStatus will return the status from the CTICiscoReturn object. Here

is a table of the available get methods for the CTICiscoReturn object:

Table 6. get methods for the CTICiscoReturn object

Return values get method

ANI String getANI()

CallerEnteredDigits String getCallerEnteredDigits()

CallVars CTICiscoCallVars getCTICiscoCallVars()

Cause Integer getCause()

ErrorCode Integer getErrorCode()

Event Integer getEvent()

InvokeID Integer getInvokeID()

Label String getLabel()

LabelType Integer getLabelType()

RequestID Integer getRequestID()

ScriptConfiguration String getScriptConfiguration()

ScriptID String getScriptID()

Java CTICisco API


Table 6. get methods for the CTICiscoReturn object (continued)

ServiceID Integer getServiceID()

Status Integer getStatus()

TransferHint Integer getTransferHint()

CTICiscoCallVars object

One possible CTICiscoReturn property is a CTICiscoCallVars object which

supports get methods for each of the Cisco ICM call variables.

One possible CTICiscoReturn property is a CTICiscoCallVars object. Some

methods require various Call Variables to be passed to, or returned from, the

Cisco ICM. When passing Call Variables or ECC Variables in to the ICM, a

CTICiscoCallVariable object should be created and then each required value is

set by calling the appropriate set method. For example, to set the CallVariable1

value, use the method setCallVarFlag1(<value of flag to be set>).

When a Call Variable or an ECC Variable is returned, a CallVars object must

first be retrieved from the CTICiscoReturn object. The Call Variable or ECC

Variable can then be accessed using the relevant get method.

Here is an example of how CTICiscoCallVars is used:


CTICiscoReturn ret;

ret = icm.connect();

// Firstly check that the Status is equal to zero


if (Status.intValue() != 0) {

// Status is non-zero. At this point an app would normally

// log this status value and return

return Status;

} else {

// Status is zero so we can pickup the returned values

CallVars cv = ret.getCallVars();

// Check cv is not equal to null

// (something has gone wrong if this is the case)

if (cv == null) {

// Something has gone wrong. Return the value of Status

return Status;

} else {

// We have a call vars object so we can now pick up

// the values we are interested in

String CallVariable1 = cv.getCallVariable1();

String CallVariable2 = cv.getCallVariable2();

// And so on for all the variables the app is interested in

}

}

Java CTICisco API


Each value that can be returned has a get method associated with it. Here is a

table of the available get and set methods for the CTICiscoCallVars object:

Table 7. get and set methods for the CTICiscoCallVars object

Variable name get method set method

CallVarFlag1 Integer getCallVarFlag1() void setCallVarFlag1(Integer

CallVarFlag1)

CallVarFlag... Integer getCallVarFlag...() void setCallVarFlag...(Integer

CallVarFlag...)

CallVarFlag10 Integer getCallVarFlag10() void setCallVarFlag10(Integer

CallVarFlag10)

CallVariable1 String getCallVariable1() void setCallVariable1(String

CallVariable1)

CallVariable... String getCallVariable...() void setCallVariable...(String

CallVariable...)

CallVariable10 String getCallVariable10() void setCallVariable10(String

CallVariable10)

ECCVarArrayIndex1 Integer

getECCVarArrayIndex1()

void

setECCVarArrayIndex1(Integer)

ECCVarArrayIndex... Integer

getECCVarArrayIndex...()

void

setECCVarArrayIndex...(Integer

ECCVarArrayIndex1)

ECCVarArrayIndex5 Integer

getECCVarArrayIndex5()

void

setECCVarArrayIndex5(Integer

ECCVarArrayIndex5)

ECCVarArrayString1 String

getECCVarArrayString1()

void

setECCVarArrayString1(String)

ECCVarArrayString... String

getECCVarArrayString...()

void

setECCVarArrayString...(String

ECCVarArrayString1)

ECCVarArrayString5 String

getECCVarArrayString5()

void

setECCVarArrayString5(String

ECCVarArrayString5)

ECCVarArrayTag1 Integer

getECCVarArrayTag1

void

setECCVarArrayTag1(Integer)

ECCVarArrayTag... Integer

getECCVarArrayTag...

void

setECCVarArrayTag...(Integer

ECCVarArrayTag1)

ECCVarArrayTag5 Integer

getECCVarArrayTag5

void setECCVarArrayTag5(Integer

ECCVarArrayTag5)

Java CTICisco API


Table 7. get and set methods for the CTICiscoCallVars object (continued)

ECCVarValueString1 String

getECCVarValueString1()

void

setECCVarValueString1(String

ECCVarValueString1)

ECCVarValueString... String

getECCVarValueString...()

void

setECCVarValueString...(String

ECCVarValueString...)

ECCVarValueString5 String

getECCVarValueString5()

void

setECCVarValueString5(String

ECCVarValueString5)

ECCVarValueTag1 Integer

getECCVarValueTag1()

void setECCVarValueTag1(Integer

ECCVarValueTag1)

ECCVarValueTag... Integer

getECCVarValueTag...()

void

setECCVarValueTag...(Integer

ECCVarValueTag...)

ECCVarValueTag5 Integer

getECCVarValueTag5()

void setECCVarValueTag5(Integer

ECCVarValueTag5)

StatusVariable1 Integer getStatusVariable1() void setStatusVariable1(Integer)

StatusVariable... Integer

getStatusVariable...()

void setStatusVariable...(Integer

StatusVariable1)

StatusVariable16 Integer

getStatusVariable16()

void setStatusVariable16(Integer

StatusVariable16)

Java CTICisco API


SCI custom server functions for Java

cancel

The cancel method is issued by the Java application to cancel a

previously-requested operation that is identified by its InvokeID.

The RequestID must match the InvokeID of the request that is to be canceled.

If they match and the operation is canceled, a dialogueFailureConfSend with a

status of E_OPERATION_CANCELLED must be sent.

If they match and the operation cannot be canceled, a

dialogueFailureConfSend with a status of E_OPERATION_NOT_CANCELLED

must be sent.

If the IDs do not match, or the ID is no longer active, a

dialogueFailureConfSend with a status of E_INVALID_INVOKEID must be

sent.

Syntax

CTICiscoReturn cancel();

Parameters

There are no parameters for this method.

Return properties

Integer InvokeID


dialogueFailureConfSend. To extract this property, call the

getInvokeID method on the returned CTICiscoReturn object.

Integer RequestID

The InvokeID of the previously issued request that is to be canceled

as returned by the previous runScriptRequest. To extract this property,

call the getRequestID method on the returned CTICiscoReturn object.

Integer Status

Returns an Integer value from the list of status codes that describes

the result of this request (see Table 10 on page 123.) To extract this

property, call the getStatus method on the CTICiscoReturn object.

SCI functions for Java


connect

The connect method is issued by the Java application to connect the call to the

destination that is identified explicitly by the label, or implicitly by the label

type.

If the connect cannot be processed, a dialogueFailureEventSend with a status

of E_UNSPECIFIED_FAILURE must be sent.

Syntax

CTICiscoReturn connect();

Parameters

There are no parameters for this method.

Return properties

Integer LabelType

The type of label that is returned in this field. To extract this property,

call the getLabelType method on the returned CTICiscoReturn object.

String Label

The destination to which the call must be routed. To extract this

property, call the getLabel method on the returned CTICiscoReturn

object.

Integer TransferHint

Only present if the VRU supports the blind transfer feature. If

Transfer Hint is present, and set to true, the VRU PG can send a

connect or connectToResource message after this connect. To extract

this property, call the getTransferHint method on the returned

CTICiscoReturn object.

Integer Status



property, call the getStatus method on the returned CTICiscoReturn

object.

CTICiscoCallVars CallVariables

To extract this property call the getCallVars method on the returned

CTICiscoReturn object. The following CallVariables are available by

using get methods in this CTICiscoCallVars object.

String CallVariable1

Additional information that is related to the call. Extracted by

the getCallVariable1 method. The maximum length of

characters in the string is 40. This parameter is optional.



String CallVariable...


the getCallVariable... method. The maximum length of




the getCallVariable10 method. The maximum length of


Integer ECCVarValueTag1


Extracted by the getECCVarValueTag1 method. This parameter

is optional.

String ECCVarValueString1

Call-related data. Extracted by the getECCVarString1 method.

The maximum length of characters in the string is 210. This

parameter is optional.

Integer ECCVarValueTag...


Extracted by the getECCVarValueTag... method. This


String ECCVarValueString...

Call-related data. Extracted by the getECCVarValueString...

method. The maximum length of characters in the string is

210. This parameter is optional.




is optional.


Call-related data. Extracted by the getECCVarString5 method.



Integer ECCVarArrayTag1


Extracted by the getECCVarArrayTag1 method. This


Integer ECCVarArrayIndex1

A numeric array index identifier. Extracted by the

getECCVarArrayIndex1 method. This parameter is optional.

String ECCVarArrayString1

Call-related data. Extracted by the getECCVarArrayString1





Integer ECCVarArrayTag...


Extracted by the getECCVarArrayTag... method. This


Integer ECCVarArrayIndex...


getECCVarArrayIndex... method. This parameter is optional.

String ECCVarArrayString...

Call-related data. Extracted by the getECCVarArrayString...





Extracted by the getECCVarArrayIndex... method. This











connectToResource

The connectToResource method is sent from the Java application to instruct

the VRU to disconnect the outgoing leg of an existing call (if there is an

outgoing leg) and to prepare to accept a possible runScriptRequest. The VRU

must respond with a resourceConnected method.

Syntax

CTICiscoReturn connectToResource(String Label, CTICiscoCallVars

CallVariables);

Parameters

String Label



To set this property create a CTICiscoCallVars object and call the

relevant set method for the variables you wish to set.


Additional information that is related to the call. Set by the

setCallVariable1 method. The maximum length of characters

in the string is 40. This parameter is optional.



setCallVariable... method. The maximum length of characters







The numeric tag value by which this variable is identified. Set

by the setECCVarValueTag1 method. This parameter is

optional.


Call-related data. Set by the setECCVarValueString1 method.





by the setECCVarValueTag... method. This parameter is

optional.




Call-related data. Set by the setECCVarValueString... method.






optional.







by the setECCVarArrayTag1 method. This parameter is

optional.


A numeric array index identifier. Set by the

setECCVarArrayIndex1 method. This parameter is optional.


Call-related data. Set by the setECCVarArrayString1 method.





by the setECCVarArrayTag... method. This parameter is

optional.



setECCVarArrayIndex... method. This parameter is optional.


Call-related data. Set by the setECCVarArrayString... method.






optional.







Call-related data. Set by the setECCVarArraySring5 method.



Return properties

Integer Status




object.



dialogueFailureConfSend

The dialogueFailureConfSend is issued from the Java application to report the

script that is requested to be run if the runScriptRequest method finds a

problem.

It is sent in response to an operation that cannot be performed. After sending

this, the Java application must receive more instruction from the ICM. If

further instruction does not arrive in a reasonable amount of time, a

dialogueFailureEventSend is sent with a status of E_TIMEOUT.

The InvokeID in the dialogueFailureConfSend message must match the

InvokeID from the request message. If they do not match, the ICM fails the

request and causes the Java application to be signaled to issue

dialogueFailureEventRecv. The return status is E_INVALID_INVOKE_ID.

Syntax

CTICiscoReturn dialogueFailureConfSend(Integer InvokeID, Integer

ErrorCode);

Parameters

Integer InvokeID

Set to the InvokeID that is returned by cancel or runScriptRequest.

Integer ErrorCode

The status value that describes the failure. See Table 10 on page 123.

Return properties

Integer Status




object.



dialogueFailureEventRecv

The dialogueFailureEventRecv method is issued from the Java application to

receive the ErrorCode when a dialog fails in an unrecoverable state.

It can be sent from the ICM to inform the Java application of an error, for

example, if the dialog has had a fatal failure. When the

dialogueFailureEventRecv is issued, the dialog is no longer active to the ICM.

The dialog is still available to the VRU so that any signaled events can be

retrieved by the Java application.

Syntax

CTICiscoReturn dialogueFailureEventRecv();

Parameters

There are no input parameters for this method.

Return properties

Integer ErrorCode

The status value that describes the failure. To extract this property, call

the ErrorCode method on the returned CTICiscoReturn object. See

Table 10 on page 123.

Integer Status




object.



dialogueFailureEventSend

The dialogueFailureEventSend method is issued from the Java application to

report a dialog failure that is in an unrecoverable state.

It can be sent from the Java application to inform the ICM of an error, for

example, if the dialog has had a fatal failure. When the

dialogueFailureEventSend is issued, the dialog is no longer active to the ICM.

The dialog is still available to the VRU so that any signaled events can be

retrieved by the Java application.

Syntax

CTICiscoReturn dialogueFailureEventSend(Integer ErrorCode);

Parameters

Integer ErrorCode

The status value that describes the failure. See Table 10 on page 123.

Return properties

Integer Status




object.



eventReport

The eventReport method is issued to report that a call with a given dialog has

changed state. For more information on Event Codes, see “Event codes” on

page 130.

Syntax

CTICiscoReturn eventReport(Integer EventCode, Integer CauseCode);

Parameters

Integer EventCode

The code that explains the detected event.

Integer CauseCode (optional)

The code that describes the cause of the event can be acknowledged

only if the event code is DISCONNECT or ABANDON. See Table 12

on page 130.

Return properties

Integer Status




object.



newCall

The newCall method is issued for calls arriving at the VRU that are not under

ICM script control. A Service Control dialog is created by this function. The

successful running of this function causes the received data to run a VRU

based script.

The newCall method is issued once during a call. If it is issued, then the

requestInstruction method is not issued.


amount of time. If the instructions are not provided, a

dialogueFailureEventSend method is sent with a status code of E_TIMEOUT.


fails the request and causes a signal to the Java application to issue a

dialogueFailureEventRecv method and the returned status code

E_INVALID_MESSAGE.

If the DialedNumber is not configured at the ICM, the Java application is

signaled to issue a dialogueFailureEventRecv and the returned status code of

E_INVALID_DIALED_NUMBER.


given call type, the Java application is signaled to issue a

dialogueFailureEventRecv and the returned status code E_NO_SCRIPT.

In all other fatal error conditions the Java application is signaled to issue a

dialogueFailureEventRecv and the returned status code


Syntax

CTICiscoReturn newCall(Integer ServiceID, String DialedNumber, String ANI,

String UserToUserInfo, String CalledNumber, String DNIS, CTICiscoCallVars

CallVariables);

Parameters

Integer ServiceID


String DialedNumber

The number that is used to determine the ICM call type. The

maximum length of characters in the string is 32.

String ANI

The Calling line ID of the caller. The maximum length of characters in

the string is 40. This parameter is optional.



String UserToUserInfo

The ISDN user-to-user information element. The maximum length of


String CalledNumber

The complete called number from the network. The maximum length

of characters in the string is 32. This parameter is optional.

String DNIS

The DNIS that is provided with the call. The maximum length of






Additional VRU information that is to be used when the ICM

script is run. Set by the setCallVariable1 method. The

maximum length of characters in the string is 40. This




script is run. Set by the setCallVariable... method. The





script is run. Set by the setCallVariable10 method. The






optional.








optional.










optional.








optional.











optional.











optional.










Return properties

Integer Status




object.



registerVariables

The registerVariables method is issued to notify the ICM which standard and

expanded call variables the VRU is interested in for that call instance. This

request is necessary for support only under ICM version 4.1 with SCI active.

Syntax

CTICiscoReturn registerVariables(CTICiscoCallVars CallVariables);

Parameters




Integer CallVarFlag1

Set to 1 if this variable is to be supplied by the ICM, or

changed by the VRU. Set to 0 if the VRU has no interest in the

variable. Set by the setCallVarFlag1 method.

Integer CallVarFlag...



variable. Set by the setCallVarFlag... method.

Integer CallVarFlag10



variable. Set by the setCallVarFlag10 method.


A numeric tag value by which this variable is identified. Set


optional.



Set by the setECCVarValueString1 method. The maximum

length of characters in the string is 32. This parameter is

optional.




optional.





Set by the setECCVarValueString... method. The maximum


optional.




optional.



Set by the setECCVarValueString5 method. The maximum


optional.




optional.



Set by the setECCVarArrayString1 method. The maximum


optional.




optional.



Set by the setECCVarArrayString... method. The maximum


optional.




optional.



Set by the setECCVarArrayString5 method. The maximum


optional.



Return properties

Integer Status




object.



release

The release method is issued by the Java application to release the specified

call that is associated with the specified dialog.

If the release method cannot be processed, a dialogueFailureEventSend

method with a status of E_UNSPECIFIED_FAILURE is sent.

Syntax

CTICiscoReturn release();

Parameters


Return properties

Integer Cause

The reason for clearing the call (see Table 8 on page 123.) To extract

this property, call the getCause method on the returned

CTICiscoReturn object.

Integer Status




object.



requestInstruction

The requestInstruction method is issued for calls arriving at the VRU that are

already under ICM script control. The successful running of this function

causes data received to run a VRU based script.

The requestInstruction method should be issued only once during a call. If it

is issued, then the newCall should not be issued.


amount of time. If the Instructions are not provided, a

dialogueFailureEventSend is sent with a status code of E_TIMEOUT.


given call type, the Java application is signaled to issue a

dialogueFailureEventRecv and the returned status code E_NO_SCRIPT.

In all other fatal error conditions the Java application is signaled to issue a

dialogueFailureEventRecv and the returned status code


Syntax

CTICiscoReturn requestInstruction(Integer ServiceID, String CorrelationID,

String ANI, String UserToUserInfo, String CalledNumber, String DNIS);

Parameters

Integer ServiceID

The ID of the service to which this call is attributed.

String CorrelationID

The Correlation ID that is provided by an INAP network. This


String ANI

The calling line ID of the caller. The maximum length of characters in

the string is 40. This parameter is optional.

String UserToUserInfo

The ISDN user-to-user information element. The maximum length of


String CalledNumber

The complete called number from the network. The maximum length

of characters in the string is 32. This parameter is optional.

String DNIS

The DNIS that is provided with the call. The maximum length of




Return properties

Integer Status




object.



resourceConnected

The resourceConnected message is sent from the Java application to indicate

that the VRU has finished processing a connectToResource message and to

show that it is ready to accept a runScript, connect, or connectToResource

message.

Syntax

CTICiscoReturn resourceConnected();

Parameters


Return properties

Integer Status




object.



runScriptRequest

The runScriptRequest is issued to receive the script and related call

information that the ICM wants run for this call instance.

If the script that is to be run cannot be found, the Java application must send

a dialogueFailureConfSend with a status of E_INVALID_SCRIPT.

If the script cannot be run because of an invalid call variable, the Java

application must send a dialogueFailureConfSend with a status of

E_CALL_VARIABLE1 ... E_CALL_VARIABLE10.

In any event, the Java application must send a runScriptResult or

dialogueFailureConfSend in response to the runScriptRequest.

Syntax

CTICiscoReturn runScriptRequest();

Parameters


Return properties

Integer InvokeID


runScriptResult or dialogFailureConfSend. To extract this property, call

the getInvokeID method on the returned CTICiscoReturn object.

String ScriptID

The ID of the script that is to run on the VRU. To extract this

property, call the getScriptID method on the returned CTICiscoReturn

object. The maximum length of characters in the string is 40.

String ScriptConfiguration

A configuration string that is configured in the ICM to select static

script options. To extract this property, call the getScriptConfiguration

method on the returned CTICiscoReturn object. The maximum length

of characters in the string is 40.

String ANI

The Calling line ID of the caller. To extract this property, call the

getANI method on the returned CTICiscoReturn object. The maximum

length of characters in the string is 40. This parameter is optional.

String CallerEnteredDigits

Digits that the caller enters. To extract this property, call the

getCallerEnteredDigits method on the returned CTICiscoReturn object.

The maximum length of characters in the string is 40.




To extract this property call the getCallVars method on the returned

CTICiscoReturn object. The following CallVariables are available by

using get methods in this CTICiscoCallVars object.


Additional VRU information that is sent to the VRU to be

used when the script is run. Extracted by the getCallVariable1

method. The maximum length of characters in the string is 40.

This parameter is optional.



used when the script is run. Extracted by the getCallVariable...

method. The maximum length of characters in the string is 40.




used when the script is run. Extracted by the

getCallVariable10 method. The maximum length of characters





is optional.


Call-related data. Extracted by the getECCVarValueString1





Extracted by the getECCVarValueTag... method. This



Call-related data. Extracted by the getECCVarValueString...






is optional.


Call-related data. Extracted by the getECCVarValueString5



method on this object to retrieve ECCVarValueString5. The















The numeric tag value by which this variable is

identified.Extracted by the the getECCVarArrayTag... method.




getECCVarArrayIndex... method. This parameter is optional.


Call-related data. Extracted by the getECCVarArrayString...








A numeric array index identifier. Extracted by






Integer Status




object.



runScriptResult

The runScriptResult is issued to inform the ICM that the specified script,

requested to be run in the return property of the newCall or

requestInstruction, was successful or not.

Syntax

CTICiscoReturn runScriptResult(Integer InvokeID, Integer ResultCode, String

CallerEnteredDigits, Integer NewTransaction, CTICiscoCallVars CallVariables);

Parameters

Integer InvokeID

Set to the InvokeID returned by runScriptRequest.

Integer ResultCode

Set to true (1) if no errors were found actually running the script. Set

to false (0) if an error was found.

String CallerEnteredDigits

Digits that the caller enters. The maximum length of characters in the

string is 40.

Integer NewTransaction












setCallVariable... method. The maximum length of characters









optional.










optional.








optional.








optional.











optional.







Call-related data. Set by the setECCVarArrayString... method.






optional.








Return properties

Integer Status




object.



waitForEvent

The Java application is responsible for periodic checking of the events from

the custom server. By calling waitForEvent with a timeout (in seconds), the

application can pick up any events in the queue. If an event has already been

sent to the application from the custom server, waitForEvent will return

immediately and the event can be retrieved by calling getEvent on the

returned CTICiscoReturn object. The status (getStatus on the returned object)

should also be checked to confirm a successful status value of 0.

Syntax

CTICiscoReturn waitForEvent(Integer Timeout);

Parameters

Integer Timeout

Specify the timeout in seconds to wait for an event from the custom

server.

Return properties

Integer Status




object.

Integer Event

The unsolicited event sent from the custom server (see “Unsolicited

event codes” on page 131.)



Chapter 6. Service Control Interface scenarios and

examples

All examples in this section assume that the call has already been answered

by the application, and are intended to show only Cisco ICM custom server

activity.

The Peripheral Gateway that is shown in these examples is a Cisco provided

piece of hardware (an IBM-comaptible PC running Windows NT) that

interprets between the ICM and the VRU. For example, the PG takes messages

from the ICM and converts them into the format that the VRU can interpret.


Call #1) Arriving call not under ICM script control (for a state table application)

For example, a call that is arriving at a VRU directly from a public network

where, firstly, the VRU registers its interest in particular variables, then, the

ICM instructs the VRU to run a particular script that is completed successfully

before the call in ended.

StateTable

Create_DialogueID

Register_Variables

New_Call

Run_Script_Request

Run_Script_Result

Event_Report (Disconnect)

Release_DialogueID

Wait_Event

REGISTER_VARIABLES

RUN_SCRIPT_RESULT

EVENT_REPORT

NEW_CALL

RUN_SCRIPT_REQ

CustomServer

PeripheralGateway

RUN THE SCRIPT

Figure 3. Arriving call not under ICM script control (for a state table application)

Service Control Interface scenarios and examples


Call #2) Arriving call already under ICM script control (for a Java application)

For example, a call that has been routed to this VRU from another VRU so

that a particular script can be run. The ICM instructs the VRU to run a

particular script that is completed successfully before the call is ended.

registerVariables()

requestInstruction()

runScriptRequest()

runScriptResult()

eventReport() (Disconnect)

waitForEvent()

REGISTER_VARIABLES

RUN_SCRIPT_RESULT

EVENT_REPORT

REQUEST_INSTRUCTION

RUN_SCRIPT_REQ

CustomServer

PeripheralGateway

RUN THE SCRIPT

JavaApplication

Figure 4. Arriving call already under ICM script control (for a Java application)


Chapter 6. Service Control Interface scenarios and examples 113

Call #3) Arriving call already under ICM script control, and the script requested

to be run does not exist (for a state table application)

For example, a call that has been routed to this VRU from another VRU so

that a particular script can be run. The ICM instructs the VRU to run a

particular script that cannot be found by the VRU. The VRU then decides to

end the call.

StateTable

Create_DialogueID

Register_Variables

Request_Instruction

Run_Script_Request

Dialog_Failure_Conf_Send


Release_DialogueID

Wait_Event

REGISTER_VARIABLES

DIALOG_FAILURE_CONF

EVENT_REPORT

REQUEST_INSTRUCTION

RUN_SCRIPT_REQ

CustomServer

PeripheralGateway

(E_INVALID_SCRIPT)

Figure 5. Arriving call already under ICM script control, and the script requested to be run does not

exist (for a state table application)



Call #4) Arriving call not under ICM script control, and a Cancel request is

received (for a Java application)

For example, a call that arrives at a VRU direct from a public network where

the ICM instructs the VRU to run a particular script. The VRU starts running

the script until it is interrupted by the ICM canceling this request. The VRU

reports that the cancel was performed successfully, and the VRU then ends

the call.

newCall()

dialogFailureConfSend()

waitForEvent()

REGISTER_VARIABLES

DIALOG_FAILURE_CONF

EVENT_REPORT

NEW_CALL

RUN_SCRIPT_REQ

CANCEL

CustomServer

PeripheralGateway

(E_OPERATION_CANCELLED)

JavaApplication

registerVariables()

runScriptRequest()


waitForEvent()

Figure 6. Call #4) Arriving call not under ICM script control, and a Cancel request is received (for a

Java application)



Call #5) Arriving call not under ICM script control, and a Failed Cancel request is

received (for a state table application)

For example, a call that is arriving at a VRU direct from a public network.

The ICM instructs the VRU to run a particular script. The VRU starts running

the script until it is interrupted by the ICM canceling this request. The VRU

reports that the cancel operation could not be performed successfully and the

VRU then continues running the script. When the script has ended, the VRU

reports successful completion of the script, then ends the call.



StateTable

Create_DialogueID

Register_Variables

New_Call

Run_Script_Request

Dialog_Failure_Conf_Send


Release_DialogueID

Wait_Event

Wait_Event

REGISTER_VARIABLES

DIALOG_FAILURE_CONF

EVENT_REPORT

NEW_CALL

RUN_SCRIPT_REQ

CANCEL

CustomServer

PeripheralGateway

(E_OPERATION_NOT_CANCELLED)

Run_Script_Result

RUN_SCRIPT_RESULT

Figure 7. Arriving call not under ICM control and Failed Cancel request received (for a state table

application)



Call #6) Arriving call not under ICM script control and receives a Release

Request (for a Java application)

For example, a call that is arriving at a VRU direct from a public network

where the ICM instructs the VRU to run a particular script that is completed

successfully. The VRU then waits for further instruction at which point the

ICM instructs the VRU to release the call.



JavaApplication

newCall()

release()

REGISTER_VARIABLES

EVENT_REPORT

NEW_CALL

CustomServer

PeripheralGateway

RUN_SCRIPT_REQ

RELEASE

(RUN THE SCRIPT)

runScriptResult()

RUN_SCRIPT_RESULT

registerVariables()

runScriptRequest()


waitForEvent()

waitForEvent()

Figure 8. Arriving call not under ICM script control and receives a Release Request (for a Java

application)



Call #7) TimeOut during dialog creation (for a state table application)


where the VRU receives no response from the ICM in response to its

New_Call request in a timeout period. The VRU then attempts to receive a

reason for the failure from the ICM. Upon receiving nothing, the VRU runs its

default call logic (this could be to play the user a technical-difficulties

message) before it sends a failure message and releases the call.

StateTable

Create_DialogueID

Register_Variables

New_Call

REGISTER_VARIABLES

NEW_CALL

CustomServer

PeripheralGateway

Dialogue_Failure_Event_Recovery


DIALOGUE_FAILURE_EVENT

Release_DialogueID

Elapsed Time with no Response from PG

Wait_Event

(E_TIMEOUT)

(E_TIMEOUT)

(Default Call Logic)

Figure 9. TimeOut during dialog creation (for a state table application)



Call #8) Arriving call not under ICM script control, and a Cancel request is

received, VRU instructed to transfer call (for a Java application)


where the ICM instructs the VRU to play music to the caller before an agent

becomes available. When the agent comes available the VRU is instructed to

connect the call to a specific agent.



newCall()

dialogFailureConfSend()

REGISTER_VARIABLES

DIALOG_FAILURE_CONF

NEW_CALL

RUN_SCRIPT_REQ

CustomServer

PeripheralGateway

eventReport() (Transferred)

EVENT_REPORT

CANCEL

CONNECT

connect()

(E_OPERATION_CANCELLED)

JavaApplication

registerVariables()

runScriptRequest()

waitForEvent()

waitForEvent()

waitForEvent()

Figure 10. Arriving call not under ICM script control, Cancel request received, VRU transfers call

(for a Java application)



Service Control Interface codes

Call Cleared causes

Table 8 lists the Call Cleared causes and associated codes.

Table 8. Call Cleared causes

Code Cause

1 Normal completion

2 Call abandoned

3 Call Transferred

4 New Transaction

5 Busy

6 No answer

7 Maintenance

8 Net congestion

9 Net not obtainable

10 Reorder tone

11 Resources not available

12 Trunks busy

Label types

Table 9 lists the label types.

Table 9. Label types

Type Label

1 Normal

2 Busy

3 Ring

4 Not supported

5 Default

Status codes

Table 10 lists the status codes.

Table 10. Status codes

Status

code Status name Description

0 E_NO_ERROR No error occurred.



Table 10. Status codes (continued)

Status


1 E_INVALID_VERSION The version number that was

requested by the PG is not

supported by the VRU.

2 E_SESSION_ALREADY_ACTIVE The VRU already has an active

communication session with a PG.

3 E_VRU_OFFLINE The VRU is unavailable.

4 E_SESSION_NOT_ACTIVE No session is active.

5 E_INVALID_DIALED_NUMBER The dialed number that is

specified is not known to the ICM.

6 E_EVENTS_NOT_SUPPORTED The VRU does not support the

Event Data Feed.

7 E_POLLING_NOT_SUPPORTED The VRU does not support the

Polled Data Feed.

8 E_ROUTING_NOT_SUPPORTED The VRU does not support the

Call Routing Interface.

9 E_TIME_SYNCH_NOT_SUPPORTED The VRU does not support the

Time Synchronization Interface.

10 E_TIMEOUT A timeout has occurred.

11 E_PG_OFFLINE The Peripheral Gateway is offline.

12 E_REQUEST_REFUSED The request was refused because

of a temporary condition.

13 E_ROUTING_NOT_AVAILABLE The ICM routing service is not

available.

14 E_ROUTE_NOT_ACCEPTED The VRU did not accept the

supplied route.

15 E_UNSPECIFIED_FAILURE An unspecified error occurred.

16 E_INVALID_INVOKEID An invalid InvokeID has been

specified in a result or response

message.

17 E_SERVICE _CTRL_NOT_SUPPORTED A request was made to initialize

the Service Control Interface to a

VRU that does not support the

interface.

18 E_NO_SCRIPT An ICM Script has not been

scheduled for the call type that the

VRU is seeking instruction.

19 E_CALL_VARIABLE1 The VRU could not process a

request because of invalid value in

CallVariable1.



CallVariable2.




Status




CallVariable3.



CallVariable4.



CallVariable5.



CallVariable6.



CallVariable7.



CallVariable8.



CallVariable9.



CallVariable10.

29 E_INVALID_SCRIPT The Script ID specified in the

RUN_SCRIPT_REQ message was

invalid on the VRU.

30 E_INVALID_CALLID The CallID that was specified in a

Service Control request message is

not valid on the VRU.

31 E_DUPLICATE_DIALOGUEID The dialogue identifier that was

specified in either a NEW_CALL

or REQUEST_INSTRUCTION

message was not unique.

32 E_INVALID_MESSAGE This error code can be sent in

response to any message that is

received with missing required

floating fields.

33 E_INVALID_DIALOGUEID The DialogueID that was specified

in a request message is no longer

valid.

34 E_OPERATION_CANCELLED The specified operation was

successfully canceled by a cancel

request.




Status


35 E_OPERATION_NOT_CANCELLED The specified operation could not

be canceled by a cancel request.

121 E_NO_EVENTS_FOR_THIS_DIALOGUE The state table issued a call as if

the WaitEvent were successful and

there were no waiting events from

the view of the Custom Server.

122 E_REQUESTED_EVENT_DOES_NOT_MATCH The requested event is not the

next event to be delivered.

123 E_NEW_CALL_OR_REQ_INST_DUP The state table attempted to issue

more than one New_Call or

Request_Instruction in the same

call instance. Only one of the two

can be issued. Not both or

multiples of each.

124 E_DIALOGUE_NOT_ACTIVE In the view of the ICM, the

dialogue is no longer active.

125 E_NOT_IN_SIMULATION_MODE This is returned to the state table

when the Set Simulation Variables

is issued, but the Cisco ICM

custom server was loaded without

the -T flag. The service writer can

leave this call in the service and

branch when this return code is

received.

126 E_NON_SEQUENTIAL_SCRIPTS This is returned to the state table


call has provided non sequential

ScriptID fields. An example would

be that ScriptID_1 is supplied,

ScriptID_2 is left blank, and then

ScriptID_3 is supplied.

127 E_MISSING_CONFIG_FIELDS This is returned to the state table


has supplied a ScriptID but left

the associated Config entry blank.

Config entries are required when a

ScriptID is supplied.




Status


128 E_INVALID_SCRIPT_FLAGS This is returned to the state table


has supplied non valid script

flags.

The valid values of the script flags

are:

0 = No Action

1 = Cancel to be sent against the

associated script

2 = Release to be sent against the

associated script

3 = Connect to be sent against the

associated Script

4 = Dialog Failure Event is sent

against the associated script

129 E_INVALID_EVENT_CODE This is returned to the state table

when a non valid Event Code is

supplied in the Report Event

request.

130 E_NO_RUNSCRIPT This is returned to the state table

when a Run Script Request is

issued by the state table, but the

Cisco ICM custom server is not

loaded with the -V flag.

131 E_NO_CONNECT This is returned to the state table



Cisco ICM custom server was not

loaded with the -W flag.

132 E_NO_RELEASE This is returned to the state table


issued by the state table but the


loaded with the -X flag.

133 E_NO_CANCEL This is returned to the state table




loaded with the -Y flag.




Status


134 E_NO_BLIND This is returned to the state table

when the Connect_To_Resource

message is issued by the state

table, but the Cisco ICM custom

server is not loaded with the −Z

flag.

136 E_INVALID_INSTANCE_NUMBER The instance number associated

with the call or the instance

number specified in a

Set_Instance_Number function call

is invalid.

Status codes for a Java application

Table 11 lists the status codes for a Java application.

Table 11. Status codes for a Java application

Code Event Type Description

-70 UNKNOWN_ERROR There is an unknown error. If this

occurs, try stopping and restarting

WebSphere Voice Response and Cisco

ICM.

-71 MISSING_KEY A required key (parameter) is missing

from the request. If this occurs, try

stopping and restarting WebSphere

Voice Response and Cisco ICM.

-72 UNABLE_TO_GET_CALLID A CallID cannot be obtained for the

current application. If this occurs, try



-73 UNABLE_TO_GET_DIAGID DialogueID cannot be obtained for the

current application. If this occurs, try





Table 11. Status codes for a Java application (continued)

-74 SOCKET_WRITE_FAILURE The socket connection between the

Cisco ICM custom server and the Java

and VoiceXML environment has been

dropped. Try stopping and restarting

the Java voice response node and the

Cisco ICM custom server. If a port

other than the default port is being

used, check that the same port number

is specified in the Java configuration

files as is used by the -J parameter (see

“Custom server parameters” on page

12.)

-75 REQUEST_TIMED_OUT A Cisco ICM request has timed out. If

this error persists, try stopping and

restarting WebSphere Voice Response

and Cisco ICM.

-76 NO_SOCKET_CONNECTION The socket connection between the

Cisco ICM custom server and the Java

and VoiceXML environment has been

dropped. Try stopping and restarting

the Java voice response node and the

Cisco ICM custom server. If a port

other than the default port is being

used, check that the same port number

is specified in the Java configuration

files as is used by the -J parameter (see

“Custom server parameters” on page

12.)

-77 WAIT_FOR_EVENT_TIMED_OUT The timeout specified in the

waitForEvent method has expired

without any unsolicited messages

arriving from the Cisco ICM.

-78 UNABLE_TO_GET_OHSL Unable to open the custom server. Try

restarting WebSphere Voice Response.

-79 UNABLE_TO_GET_CHSL Unable to close the custom server. Try

restarting WebSphere Voice Response.

-80 INVALID_PARAMETER An incorrect parameter has been

passed in. Check that all required

parameters are specified and enter the

parameter again.



Event codes

Table 12 lists the event codes.

Table 12. Event codes


1 CONNECT_FAILURE Indicates that a network failure

occurred when attempting to connect

the call.

2 BUSY Indicates a BUSY condition at

intended call destination.

3 NO_ANSWER Indicates that a call was not

connected to the target destination in

the specified time-out or ring count.

4 ANSWER Indicates that a call has connected to

destination.

5 ABANDON Indicates that a call disconnected

after a NEW_CALL or

REQUEST_INSTRUCTION message,

but before receiving call handling

instructions.

6 DISCONNECT Indicates that a call has

disconnected.



Unsolicited event codes

Table 13 lists the unsolicited event codes.

Table 13. Unsolicited event codes


7 Run_Script_Request Indicates that the ICM has issued a

Run_Script_Request event in response to either a

New_Call, Request_Instruction or New_Dialogue

event. The state table should issue the

Run_Script_Request custom server event in

response to this to receive the data that has been

sent by the ICM.

9 Connect Indicates that the ICM has issued a CONNECT

event. The state table should issue the Connect

custom server event to receive the data that has

been sent by the ICM.

12 Dialogue_Failure_Event Indicates that the ICM has issued a

Dialogue_Failure_Event. The state table should

issue the Dialogue_Failure_Event_Recv in

response to this event, to find the cause of the

event.

19 Cancel Indicates that the ICM has issued the Cancel

event. The state table should issue the Cancel

custom server event in response to this.

20 Release Indicates that the ICM has issued the Release

event. The state table should issue the Release

custom server event in response to this.

22 Connect_To_Resource Indicates that the ICM has issued the Connect To

Resource event. The state table should issue the

Connect To Resource custom server event in

response to this.



Appendix A. Application launch file

The application launch file is used when the system is testing state tables. It

defines the state tables called by the custom server.

Table 14 shows the application launch file that is used in the installation

verification test.

Table 14. Application launch file used in the installation verification test

X Wait State Table EntryPoint Parameters

1 Y GeoTel start ,0,0,0,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22

The format of the application launch file is shown in Table 15. Each field in

the application launch file is separated by one or more blanks.

Table 15. Format of an application launch file

Field name Value Data type

Maximum

size

X (Operations) The number of times the state table is to be

run.

STRING 9

WaitForCompletion "Y" means that the state table completes

before the next one is started. "N" means that

the next state table is to be started

immediately after this one has been started.

STRING 1

StateTable The name of the state table to be run. STRING 15

EntryPoint The name of the state table entry point. STRING 15

Parameters The list of parameters that are sent to the

state table. The first character is used as a

separator for the remainder of the parameters

in the string.

STRING 255


Appendix B. Cisco ICM simulator

The Cisco ICM simulator is provided to enable you to test your applications

without having to be connected to an ICM processor.

To start the simulator, start the Cisco ICM custom server from the command

line. Use the -T parameter. You must start the custom server from the

command line because the simulator issues messages to which you must

reply.

You are presented with the following simulator options:

Enter O to Open, C - Close, I - Initialize, H - Heartbeat, Q - Quit, A - Auto

Enter one of these letters (in either uppercase or lowercase). If you press Enter

without keying a letter, the default is Q, to quit. The options mean:

O Opens the connection with the Cisco ICM custom server. The

IdleTimeout value is set to 30 seconds.

C Closes the connection with the Cisco ICM custom server. The text in

the message is “Goodbye”.

I Requests an initial snapshot of WebSphere Voice Response.

H Issues a heartbeat request to the Cisco ICM custom server.

Q Ends the simulator.

A Performs the following actions in autopilot mode.

1 Opens connection.

2 Requests a snapshot.

3 Issues heartbeats.

4 On receipt of a CLOSE_CONF message, it closes the

connection, waits 2 seconds, then reopens the connection.

When the simulator is in autopilot mode, enter CTRL+C to end it.

The simulator lists the messages that are returned from the Cisco ICM custom

server on the standard output.


For Call Routing the following is provided:

If you use a CrossRefID that is greater than 9999, the Get_Route custom

server function returns a status code of 12. For other values of CrossRefID the

Get_Route custom server function returns the following values:

1 The LabelType is set to the same value as the CrossRefID is.

2 The Label text is set to “a test label”.

3 CallVariable10 is set to “CallVariable10 has been set”.

Set_Simulation_Variables

An API called Set_Simulation_Variables has been included to enable complete

testing of state tables without the need for connection to an ICM. This new

API allows you to define information that you want the simulator to return to

an application during call flow. To have full simulation support, a call flow

such as one of those listed here is required:

Get_Call_ID

This is required to issue a Set_Call_Variables.

Get_Service_ID

This is required for some SCI API calls.

Get_Dialogue_ID

This is required for all SCI API calls.

Register_Variables

In EDFI, it was assumed that you wanted all 10 Call Variables

between the ICM and VRU at all times. Now that ECC variables can

be used, you must register those in which you are interested. Also,

you must register which of the 10 call variables you want. The

simulator discards this request, but it is needed in the real

environment.

Set_Call_Variables_Event

This is where you set the actual values of the Call and ECC variables.

These values are stored by the simulator, and they are returned in all

the messages that generated by the simulator during runtime. An

example of this is CONNECT. These values are returned to the VRU

when a CONNECT is sent by the simulator.

Before a Set_Call_Variables_Event can be issued, you must have ONCE

previously in the call issued one of the following:

Delivered_Event

Originated_Event

New_Transaction_Event


Set_Simulation_Variables Parameters

Script_ID_1 (string[40]) (optional)

The value that is returned as ScriptID in a Run_Script_Request

message. Script_ID_1 through Script_ID_5 are returned by the

simulator in sequence, when Script_ID_5 has been returned

Script_ID_1 is the next to be returned.

Script_ID_... (string[40]) (optional)



simulator in sequence, when Script_ID_5 has been returned

Script_ID_1 will be the next that is returned.

Script_ID_5 (string[40]) (optional)



simulator in sequence, once Script_ID_5 has been returned Script_ID_1

will be the next that is returned.

ScriptConfig_1 (string[40]) (optional)

The value that is returned as ScriptConfig in a Run_Script_Request

message. These values are associated with the corresponding

Script_ID as shown earlier.

This script information continues to be sent in sequence to the VRU

until:

v The dialog has ended at the ICM.

v A Dialogue_Failure_Event has been issued by the ICM or VRU.

v The caller state is OTHER than ABANDON or DISCONNECT. This

is because an Event Report has been issued by the VRU.

v The simulator has issued a Connect, Release or Cancel. When one

of these has been sent, no additional Scripts are sent by the

simulator.

When you issue a Run_Script_Result, the next script is sent in a

Run_Script_Request.

When you issue a Dialogue_Failure_Conf, the next script is sent in a

Run_Script_Request.

The first Run Script Request is sent after it receives a New_Call,

Request_Instruction or New_Dialogue.

Script_1_Flag (number) (optional)

Indicates whether the related script that is supplied will be

interrupted. The possible values are shown in 138.


Appendix B. Cisco ICM simulator 137

Script_..._Flag (number) (optional)

Indicates whether the related script supplied will be interrupted. The

possible values are shown in 138.

Script_5_Flag (number) (optional)

Indicates whether the related script supplied will be interrupted. The

possible values are shown in 138.

Possible values

0 The script will not be interrupted by the simulator.

1 The Simulator will send a Cancel Request after it has sent the

Run Script Request for that script.

2 The Simulator will send a Release Request after it has sent the

Run Script Request for that script.

3 The Simulator will send a Connect Request after it has sent

the Run Script Request for that script.

4 The Simulator will send a Dialogue_Failure_Event after it has

sent the Run_Script_Request for that script.


This value will be returned in the Run_Script_Request.


This value will be returned in the Run_Script_Request.

LabelType (number)

This value will be returned in the Connect request.

Label (string[40])

This value will be returned in the Connect request.

Cause (number)

This value will be returned in the Release request.

When you have issued these calls, you can issue a Request_Instruction,

New_Call, or New_Dialogue event. The successful result of these calls causes

the first script and its associated information to be returned in a

Run_Script_Request.

The possible events that you can receive and the values you should use in

your Case API are the same as those that exist if you had received these

messages from the ICM itself.



Appendix C. Cisco ICM custom server error messages

Table 16 shows the possible error messages that can be produced by the Cisco

ICM custom server. It also describes some of the conditions or causes that

might produce these messages. These messages are logged in the WebSphere

Voice Response errorlog.

Table 16. Cisco ICM custom server error messages

Error

number

Severity

of alarm Brief description Detailed description Possible causes

20504 Red ERROR: <service

definition file> has

been deleted.

Indicates that the


has been removed.

A user has moved or deleted the

service definition file.

20504 Red Cisco ICM custom

server ended.

Indicates that the

custom server has

ended.

The custom server might have

been ended manually or

abnormally. The custom server

must be restarted.

20504 Red Waited <number>

seconds for

connection to ICR

The custom server is

awaiting connection

from ICM.

Ensure that ICM is fully

functioning and configured

correctly for this IVR.

20504 Red ERROR: Reading

Sockets Process Queue

- return code <return

code>

An internal

inter-process

communication error

has occurred.

An internal communication

handle has become corrupt, a

process has terminated or an AIX

error has occurred. Contact IBM

Support for assistance in

resolving.

20504 Red ERROR: ICR Close

Request received -

Status <status

number>, Text ><text

string><.

ICM has requested

that the connection

be closed

ICM is shutting down.

20504 Red ERROR: Unable to get

number of available

channels.

The custom server

failed in an attempt

to retrieve channel

status information

from WebSphere

Voice Response.

The communication with

WebSphere Voice Response has

been broken. Possibly WebSphere

Voice Response terminated

unexpectedly. Follow the

instructions under the heading

System restart at the end of this

table.


Table 16. Cisco ICM custom server error messages (continued)

Error

number

Severity


20504 Red ERROR: Unable to get

state of channels

The custom server


to retrieve channel

status information

from WebSphere

Voice Response.

The communication between







table.

20504 Red ERROR: No entry in

Trunk Status Table for

CallID <Call ID

number>

A CallID cannot be

associated with the

requested function or

message.

Ensure application flow is correct

such that call ids are associated

with a call prior to messages

being exchanged with ICM.

20504 Red ERROR: Invalid

Service Definition file.

See Yellow Warnings

The service definition

file is invalid.

Correct the syntax errors within

the service definition file.

20504 Red ERROR: Unable to

determine status of

channels.

The custom server


to retrieve channel

status information

from WebSphere

Voice Response.

The communication between







table.

20504 Red ERROR: Reading VRU

Monitor Process

Queue - return code

<return code>

An internal

inter-process

communication error

has occurred.




error has occurred. Follow the


Custom server restart at the end of

this table.

20504 Red ERROR: Creating

socket, errno <error

number>

An internal

inter-process

communication error

has occurred.







table.

20504 Red ERROR: Getting Host

address for

<hostname>.

An AIX error

occurred while trying

to resolve the

hostname.

Ensure that the host name can be

correctly resolved on the

command line and retry. Follow

the instructions under the

heading System restart at the end

of this table.



Error

number

Severity


20504 Red ERROR: Getting Port

number for Service

<service name>

An error occurred

attaching to a port

for the specified

service.

Ensure that the port is not in use

by another process and retry.

20504 Red ERROR: Binding to

socket. <Error string>

errno X.

An internal

inter-process

communication error

has occurred.







table.

20504 Red ERROR: Waited

<number> seconds for

Socket connection to

complete.

An internal

inter-process

communication error

has occurred.







table.

20504 Red ERROR: Listening to

socket, errno <error

number>

An internal

inter-process

communication error

has occurred.







table.

20504 Red Failed to accept socket

after <number>

attempts, errno <error

number>.

An internal

inter-process

communication error

has occurred.






resolving. Follow the instructions

under the heading System restart

at the end of this table.

20504 Red ERROR: Writing to

socket. <socket name>

An internal

inter-process

communication error

has occurred.







table.

Appendix C. Cisco ICM custom server error messages 141


Error

number

Severity


20504 Red Attempting to read

<number> bytes from

socket, maximum

temporary buffer

<number>.

An internal

inter-process

communication error

has occurred.







table.

20504 Red ERROR: Reading from

socket. <socket name>

An internal

inter-process

communication error

has occurred.







table.

20504 Red Message too long:

length asked for

<number>, length

received <number>,

maximum length

<number>.

An internal

inter-process

communication error

has occurred.







table.

20504 Red ERROR:

CA_Execute_State

_Table failed-rc

<return code>,

CA_errno <error

number>.

An internal

inter-process

communication error

has occurred.







table.

20504 Red ERROR: Failed to

create Queue

<number> using

<path name>.

An internal

inter-process

communication error

has occurred.







table.


flush Queue

<number>.

An internal

inter-process

communication error

has occurred.







table.



Error

number

Severity


20504 Red ERROR: Queue Key is

invalid for Queue

<queue name>.

An internal

inter-process

communication error

has occurred.






resolving.

20504 Red ERROR: Failed to get

access to Queue

<number> using

<queue name>.

An internal

inter-process

communication error

has occurred.







table.

20504 Red ERROR: Enqueuing a

message - rc <return

code>, errno <error

number>.

An internal

inter-process

communication error

has occurred.







table.

20504 Red ERROR: Flush Queue

failed.

An internal

inter-process

communication error

has occurred.







table.

20504 Red ERROR: Poll was

interrupted:

CA_errno=<error

number>

;errno=<error number.

An internal

inter-process

communication error

has occurred.







this table.

20504 Red ERROR: In CA_Poll,

CA_errno=<error

number>;errno=<error

number>

An internal

inter-process

communication error

has occurred.






resolving.



Error

number

Severity



allocate memory for

service data, errno =

<error number>.

An internal memory

error has occurred.

An internal memory handle has

become corrupt, a process has

terminated or an AIX error has

occurred. Follow the instructions



20504 Red ERROR: Only

<number> entries

allowed in Service

Definition table.


file is invalid.

The service definition file is

invalid and should be modified

appropriately.

20504 Red ERROR: errno <error

number> in stat for

<service definition

file>.


file has been deleted,

locked or corrupted.

Ensure that a valid service

definition file exists and retry.

20504 Red ERROR: closing

Service Definition File

rc=<return code>


file has been deleted,

locked or corrupted.

Ensure that a valid service

definition file exists and retry.


MessageType (SCI) of

<message type>.

A message has been

received which

cannot be handled by

the custom server.

The message will be

discarded.

Verify the application design on

both the IVR and ICM. If the

problem continues, contact IBM

support for assistance in

resolving.


MessageType of

<message type>.

A message has been

received which


the custom server.

The message will be

discarded.





resolving.

20504 Red Unable to Unlock

shared memory,

reason: <error string>

An internal memory

error has occurred.







20504 Red Lock semaphore

non-zero!!

An internal memory

error has occurred.









Error

number

Severity


20504 Red Unable to Lock shared

memory, reason:

<error string>

An internal memory

error has occurred.







20504 Red Lock semaphore >1!! An internal memory

error has occurred.







20504 Red ERROR: Cannot open

shared resource file -

<resource file>

An internal memory

error has occurred.







20504 Red ERROR: creating

global shared memory

segment

An internal memory

error has occurred.







20504 Red Multiple instances

were configured, but

no parameter

definition file was

specified.

The custom server

parameters are

incorrect.

Ensure that the custom server

parameters are configured

correctly.

20504 Red ERROR: Must select at

least one: -K (EDFI) or

-U (SCI).

The custom server

parameters are

incorrect.



correctly.


create queues with rc

= <return code>, path

= <path name>

An internal

inter-process

communication error

has occurred.







table.



Error

number

Severity



attach to DirectTalk,

CA_errno=<error

number>

An internal

inter-process

communication error

has occurred.




error has occurred. Ensure WVR

is running. Follow the



table.


attach shared memory.

An internal memory

error has occurred.








create semaphore with

rc = <return code>.

An internal memory

error has occurred.








allocate shared

memory with rc =

<return code>.

Queue_Path [<queue

name>]

An internal memory

error has occurred.







20504 Red No pipe to custom

server process for

instance number

<instance number>

An internal

inter-process

communication error

has occurred.


parameters are correct. If

running in a multi-instance

environment ensure that the

Set_Instance_Number function

has been correctly invoked. If

application error is ruled out

then it is possible that an

internal communication handle

has become corrupt, a process

has terminated or an AIX error

has occurred. Follow the



this table.



Error

number

Severity


20504 Red Write() for instance

number <instance

number>failed, errno

<error

number>(<error

string>)

An internal

inter-process

communication error

has occurred.















this table.

20504 Red Write() for instance

number <instance

number> failed .

An internal

inter-process

communication error

has occurred.















this table.

20504 Red ECC Tag array

database full

An internal memory

error has occurred.




occurred. Contact IBM Support

for assistance in resolving.

20504 Red ERROR: No entry in

Call Table for CallID

<Callid>.

A CallID cannot be

associated with the

requested function or

message.

Ensure application flow is correct

such that call ids are associated

with a call prior to messages

being exchanged with ICM.



Error

number

Severity


20504 Red ERROR: Unknown

Message(<message

id>) read by Call

Process

A message has been

received which


the custom server.

The message will be

discarded.





resolving.

20504 Red ERROR: Reading Call

Process Queue -

return code <return

code>

An internal

inter-process

communication error

has occurred.







table.

20504 Red ERROR: Processing

Message - return code

<return code>

An internal

inter-process

communication error

has occurred.







this table.

20504 Red ERROR: Call Process

terminating -

Operational Status =

<return code>

Either the custom

server is terminating

or an internal

inter-process

communication error

has occurred.


handle may have become

corrupt, a process has terminated

or an AIX error has occurred.

Contact IBM Support for

assistance in resolving.

20504 Red ERROR: Poll was

interrupted:

errno=<error

number>

An internal

inter-process

communication error

has occurred.







this table.

20504 Red ERROR: In poll,

errno=<error

number>

An internal

inter-process

communication error

has occurred.







this table.



Error

number

Severity


20504 Red Activity was detected,

but could not be

allocated to a process.

Contact IBM Support

for further

information.

An internal

inter-process

communication error

has occurred.






resolving.

20504 Red read() failed, errno

<error

number>(<error

string>) - closing child

process for link_id

<link id>

An internal

inter-process

communication error

has occurred.







table.

20503 Yellow ERROR: Unknown

Function ID -

<function id>. The

message will be

discarded.

A message was

received from a state

table for a function

id which cannot be

processed by the

custom server.

Verify the application design. If

the problem continues, contact

IBM support for assistance in

resolving.

20503 Yellow An invalid number of

instances was

specified, defaulting

to 1

The custom server

parameters are

incorrect.



correctly.

20503 Yellow ERROR: Invalid

parameter(s) - Child

instance <instance

number> terminating

The custom server

parameters are

incorrect.



correctly.

20503 Yellow WARNING: -B

parameter was not

specified. Defaulting

Dialogue ID to

<number>

The custom server

parameters are

incorrect.



correctly.

20503 Yellow WARNING: -B<start

integer> was not in

the required range.

Defaulting Dialogue

ID to <number>

The custom server

parameters are

incorrect.



correctly.



Error

number

Severity


20503 Yellow ERROR: CallID <call

id number> on

TrunkGp <trunk

group number>Trunk

<trunk number> not

cleared.

Indicates that a

CallID associated

with a particular

trunk group and

trunk was not release

when the call ended.

The state table has failed to

identify a call event that caused

the call to end. The state table

must be changed to ensure that

its error handling capabilities

handle this call condition. This

error is not critical to

applications.

20503 Yellow Service Name

’<service name>’ is a

duplicate.

Indicates that two

service names in the


are identical.

A user has modified the service

definition file incorrectly while

the custom server was running.

20503 Yellow ERROR: From poll in

test_socket, errno =

<error number>

An internal

inter-process

communication error

has occurred.







this table.

20503 Yellow ERROR: No service is

available.

Indicates that no

services are available

in the service

definition file.


definition file to indicate that no

services are available on this

VRU.

20503 Yellow ERROR: The latest

version of the service

definition file has not

been loaded.

Indicates that the


is not valid and will

not be uploaded to

the ICM.



custom server was running.

20503 Yellow Service ID

“<number>” is a

duplicate.

Indicates that two

ServiceIDs in the


are identical.




20503 Yellow State table “<state

table name>” is a

duplicate.

Indicates that two

state table names in

the service definition

file are identical.




20503 Yellow Cisco ICM custom

server: No channels

are in service.

Indicates that no

channels on the VRU

are in service.

The WebSphere Voice Response

system has just initialized with

no channels in service, or a user

has quiesced or disabled the

channels.



Error

number

Severity


20503 Yellow ERROR: CallID

<CallID> on TrunkGp

<TrunkGp> Trunk

<Trunk> not cleared

by previous call

instance.

Indicates that a

CallID associated

with a particular

trunk group and

trunk was not release

when the call ended.

The state table has failed to

identify a call event that caused

the call to end. The state table

must be changed to ensure that

its error handling capabilities

handle this call condition. This

error is not critical to

applications.

20502 Green INFO: ICR

re-connection

#<connection

number> completed.

Connection with ICM

has been

reestablished after an

outage.

20502 Green Cisco ICM custom

server: No channels

are in service,

problem has

CLEARED.

Indicates that the

above error condition

has cleared.

n/a

20502 Green Cisco ICM custom

server: Loaded and

Initializing ICM/PG

Session.

Indicates that the

custom server has

initialized.

n/a

System restart:

1. Restart WebSphere Voice Response. If this fails to resolve the problem, proceed to step 2.

2. Restart the pSeries computer. If this fails to resolve the problem, contact IBM support for assistance

Custom server restart:

1. Restart the Cisco ICM custom server. If this fails to resolve the problem, contact IBM support for

assistance


Appendix D. Format of status and trace data

This section describes the format of the output of the Cisco ICM custom

server. It does not describe the messages that are sent to the ICM.

Three types of printable output are available from the Cisco ICM custom

server.

1. Color coded messages that are monitored by the WebSphere Voice

Response System Monitor and saved in the $OAM_LOG_PATH/errorlog

file.

2. Status and trace data that is saved in the specified log file by using the -l

flag as described in “Custom server parameters” on page 12, and also

displayed in the WebSphere Voice Response Status window.

Status data

The following example shows the format of data that is in the log file. Similar

data, though not so much of it, is stored in the DTstatus.out file.

Tue Jan 23 14:36:04 2001 Custom Server started. Built Build Date Time Built

Tue Jan 23 14:36:04 2001 The Log File name is /usr/lpp/dirTalk/db/current_dir/oamlog//GeoTel.Log.

Tue Jan 23 14:36:04 2001 This machine's name is ashlett.

Tue Jan 23 14:36:04 2001 The Host name is any.

Tue Jan 23 14:36:04 2001 The Port number is 7001.

Tue Jan 23 14:36:04 2001 The Service Definition File name is ./service.def.

Tue Jan 23 14:36:04 2001 The GeoTel ICR connection set-up will not timeout.

Tue Jan 23 14:36:04 2001 The Time Zone Delta is 0 seconds.

Tue Jan 23 14:36:04 2001 The Simulator will execute as a process within the custom server.

Tue Jan 23 14:36:04 2001 Simulator Process pid = 225992.

Tue Jan 23 14:36:04 2001 VRU Monitor Process pid = 22538.

Tue Jan 23 14:36:04 2001 The Service Definition file has been validated.

Tue Jan 23 14:36:04 2001 24 channels in service.

Tue Jan 23 14:36:04 2001 The VRU Monitor Process has started.

Tue Jan 23 14:36:04 2001 Call Process pid = 224488.

Tue Jan 23 14:36:04 2001 The Sockets Process has started.

Tue Jan 23 14:36:04 2001 Trying to connect to the GeoTel ICR.

Tue Jan 23 14:36:04 2001 Socket Process pid = 229088.

Tue Jan 23 14:36:04 2001 The Call Process has started.


Tue Jan 23 14:36:09 2001 A connection with the ICR has been opened.

Tue Jan 23 14:36:09 2001 Resetting Last_Message Variable For the NEW Connection.

Tue Jan 23 14:36:09 2001 Resetting Last_Message Variable For the NEW Connection.

Tue Jan 23 14:36:11 2001 =>OPEN_REQ InvokeID >143612< VersionNumber >4< IdleTimeout >20000<

Tue Jan 23 14:36:11 2001 <-OPEN_REQ InvokeID >143612< VersionNumber >4< IdleTimeout >20000<

Tue Jan 23 14:36:11 2001 ->OPEN_CONF InvokeID >143612< UseEventFeed >1< UsePolledFeed >0<

UseCallRouting >0< UseTimeSynch >0< SciUseServiceControl >1<

Tue Jan 23 14:36:11 2001 <=OPEN_CONF InvokeID >143612< UseEventFeed >1< UsePolledFeed >0<

UseCallRouting >0< UseTimeSynch >0< SciUseServiceControl >1<

Tue Jan 23 14:36:11 2001 =>SERVICE_CONTROL_DEFAULT SciMessageSubType >1< SciDialogueID

>4294967295< SciSendSeqNum >4294967295<

INIT_SERVICE_CTRL_REQ InvokeID >225992<

Tue Jan 23 14:36:12 2001 ->SERVICE_CONTROL_DEFAULT SciMessageSubType >2< SciDialogueID

>4294967295< SciSendSeqNum >4294967295<

INIT_SERVICE_CTRL_CONF InvokeID >29384<


>4294967295< SciSendSeqNum >4294967295<

INIT_SERVICE_CTRL_DATA InvokeID >29384< SciServiceFeatures >15<


>4294967295< SciSendSeqNum >4294967295<

INIT_SERVICE_CTRL_TRKGRP InvokeID >29384< TrunkGroupID >1< TrunkCount >24<

TrunkNumber[1] >1< TrunkStatus[1] >4< TrunkNumber[2] >2< TrunkStatus[2] >4<






TrunkNumber[13] >13< TrunkStatus[13] >4< TrunkNumber[14]>14< TrunkStatus[14] >4<






Tue Jan 23 14:36:12 2001 <-HEARTBEAT_REQ InvokeID >143614<

Tue Jan 23 14:36:12 2001 ->HEARTBEAT_CONF InvokeID >143614<






>4294967295< SciSendSeqNum >4294967295<

INIT_SERVICE_CTRL_SERVICE ServiceID >1< AvailableNow >1< CallsInNow >0< CallsOutNow >0<


>4294967295< SciSendSeqNum >4294967295<



>4294967295< SciSendSeqNum >4294967295<



>4294967295< SciSendSeqNum >4294967295<

status data


All error messages begin ERROR:.

INIT_SERVICE_CTRL_VRU InvokeID >29384< CurrentTime >980260572< TimeZoneDelta >0<

OperationalStatus >0< StatusVariable[1] >0< StatusVariable[2] >0< StatusVariable[3] >0<

StatusVariable[4] >0< StatusVariable[5] >0< StatusVariable[6] >0< StatusVariable[7] >0<


StatusVariable[12] >0< StatusVariable[13] >0< StatusVariable[14] >0<

StatusVariable[15] >0< StatusVariable[16] >0<


>4294967295< SciSendSeqNum >4294967295<

INIT_SERVICE_CTRL_END InvokeID >29384<

Tue Jan 23 14:36:12 2001 <=SERVICE_CONTROL_DEFAULT SciMessageSubType >14< SciDialogueID

>4294967295< SciSendSeqNum >4294967295<



>4294967295< SciSendSeqNum >4294967295<



>4294967295< SciSendSeqNum >4294967295<



>4294967295< SciSendSeqNum >4294967295<

INIT_SERVICE_CTRL_VRU InvokeID >29384< CurrentTime >980260572< TimeZoneDelta >0<

OperationalStatus >0< StatusVariable[1] >0< StatusVariable[2] >0<




StatusVariable[15] >0< StatusVariable[16] >0<


>4294967295< SciSendSeqNum >4294967295<

INIT_SERVICE_CTRL_END InvokeID >29384<









status data

Appendix D. Format of status and trace data 155

Trace data

The following example shows the format of data that is produced to help

debug problems.

GeoTel: m23 15:06:26 :I: ..** Into file_exists, initial.c **

GeoTel: :I: ..** Exit file_exists, initial.c, 0 **

GeoTel: :I: .** Exit Read_Parameters, initial.c, 0 **

GeoTel: :I: .** Into Log_Error, initial.c **

GeoTel: :I: Log-LOGONLY: Custom Server started. Built Build Date Time Built

GeoTel: :I: ..** Into file_toobig, initial.c **

GeoTel: :I: total 18602, file size 18525, addition 77

GeoTel: :I: ..** Exit file_toobig, initial.c, 0 **

GeoTel: :I: .** Exit Log_Error, initial.c, 0 **


GeoTel: :I: Log-LOGONLY: The Log File name is

/usr/lpp/dirTalk/db/current_dir/oamlog//GeoTel.Log.

GeoTel: m23 15:06:26 :I: ..** Into file_toobig, initial.c **





GeoTel: :I: Log-LOGONLY: This machine's name is ashlett.






GeoTel: m23 15:06:26 :I: Log-LOGONLY: The Host name is any.






GeoTel: :I: Log-LOGONLY: The Port number is 7001.





GeoTel: m23 15:06:26 :I: .** Into Log_Error, initial.c **

GeoTel: :I: Log-LOGONLY: The Service Definition File name is ./service.def.






GeoTel: :I: Log-LOGONLY: The GeoTel ICR connection set-up will not timeout.




GeoTel: m23 15:06:26 :I: .** Exit Log_Error, initial.c, 0 **


GeoTel: :I: Log-LOGONLY: The Time Zone Delta is 0 seconds.

trace data







GeoTel: :I: Log-LOGONLY: Debug is at level 3 -

Will trace ICR messages, Module names, Variables.



GeoTel: m23 15:06:26 :I: ..** Exit file_toobig, initial.c, 0 **



GeoTel: :I: Log-LOGONLY:

The Simulator will execute as a process within the custom server.





GeoTel: :I: Parameters have been validated

GeoTel: :I: .** Into Make_Lock, memory.c **

GeoTel: :I: .** Exit Make_Lock, memory.c, 917560 **

GeoTel: m23 15:06:26 :I: .** Into Create_Shared_Memory_Segment, memory.c **

GeoTel: :I: ..** Into create_segment, memory.c **

GeoTel: :I: ..** Exit create_segment, memory.c, 2097217 **

GeoTel: :I: Shared memory segment already exists: re-creating

GeoTel: :I: ..** Into destroy_segment, memory.c **

GeoTel: :I: ..** Exit destroy_segment, memory.c, 0 **

GeoTel: :I: ..** Into create_segment, memory.c **

GeoTel: :I: ..** Exit create_segment, memory.c, 2228289 **

GeoTel: :I: .** Exit Create_Shared_Memory_Segment, memory.c, 2228289 **

GeoTel: :I: .** Into Attach_Segment, memory.c **

GeoTel: :I: .** Exit Attach_Segment, memory.c, 1879048192 **

GeoTel: m23 15:06:26 :I: .** Into Create_Queues, queues.c **

GeoTel: :I: ..** Into Flush_Queue, queues.c **

GeoTel: :I: Queue 0 > Status is -1, errno is 35

GeoTel: :I: ..** Exit Flush_Queue, queues.c, 0 **


GeoTel: :I: Queue 1 > Status is 16, errno is 35

GeoTel: :I: Status is -1, errno is 35

GeoTel: :I: ..** Exit Flush_Queue, queues.c, 0 **


GeoTel: :I: Queue 2 > Status is 16, errno is 35

GeoTel: :I: Status is -1, errno is 35

GeoTel: m23 15:06:26 :V: ...** Exit Attach_Segment, memory.c, -2147483648 **

GeoTel: m23 15:06:26 :I: total 19378, file size 19319, addition 59

GeoTel: :V: ...** Into Load_Service_Data, service.c **


trace data


GeoTel: :V: file: >./service.def<

GeoTel: :V: ....** Into Service_Definition_Time, service.c **

GeoTel: :V: ....** Exit Service_Definition_Time, service.c, 980179341 **


GeoTel: :V: filedata 1: >* Service Definition File<

GeoTel: :V: ....** Into Add_Service_Data, service.c **

GeoTel: :V: ServiceID is non-numeric >*< (errno 35) - record is ignored

GeoTel: :V: ....** Exit Add_Service_Data, service.c, 0 **

GeoTel: :V: rc: 0 for entry 0 @ 536918788 :- >* Service Definition File<

GeoTel: :V: ....** Into List_Service_Data, service.c **

GeoTel: m23 15:06:26 :V: pService_Data is @ 0

...

GeoTel: m23 15:06:26 :V: ....** Exit List_Service_Data, service.c, 0 **

GeoTel: :V: filedata 4: >2 y GeoTel1 Problem Support<

GeoTel: :V: ....** Into Add_Service_Data, service.c **

GeoTel: :V: ServiceAvailable set to 1

GeoTel: :V: ServiceName = >Problem Support<

GeoTel: :V: Service: 2 ServiceAvailable: 1 StateTable:

>GeoTel1< ServiceName: >Problem Support<

GeoTel: :V: *ppService_Data 564417848

GeoTel: :V: ServiceName: >Problem Support< key >General Info<

GeoTel: :V: StateTable: >GeoTel1< key >None<

GeoTel: :V: Added Entry 2 @ 564417928

GeoTel: :V: ....** Exit Add_Service_Data, service.c, 0 **

GeoTel: m23 15:06:26 :V: rc: 0 for entry 2 @ 536918788 :- >2

y GeoTel1 Problem Support<

...

GeoTel: m23 15:06:31 :T: Creating Socket.

GeoTel: :T: SO_DEBUG 00 00 00 01 SO_REUSEADDR 00 00 00 04

SO_KEEPALIVE 00 00 00 08 TCP_NODELAY 00 00 00 01 TCP_RFC1323 00 00 00 04

SO_LINGER 00 00 00 80 00 00 00 00

SO_SNDBUF 00 00 40 00 SO_TYPE 00 00 00 01

GeoTel: :T: Finished Creating Socket 4 (Options 1).

GeoTel: :T: .....** Exit Create_Socket, sockets.c, 0 **

GeoTel: :T: Connecting to the Socket ...id = 4

GeoTel: :T: Connected to the socket

GeoTel: :T: ....** Exit Connect_Socket, sockets.c, 0 **

GeoTel: m23 15:06:31 :S: Socket file desc. received from accept is 5, errno = 35

GeoTel: :T: *pSocket_FD <4>

GeoTel: :S: ....** Exit Accept_Socket, sockets.c, 0 **

GeoTel: :T: ...** Exit Open_Socket, sockets.c, 0 **

GeoTel: :T: The return code from open of ICR socket is 0

GeoTel: :S: *pSocket_FD <5>

GeoTel: :S: ...** Exit Open_Socket, sockets.c, 0 **

GeoTel: :T: ...** Into Log_Error, initial.c **

GeoTel: :S: The return code from open of ICR socket is 0

GeoTel: m23 15:06:31 :T: Log-LOGONLY: Resetting Last_Message Variable For the NEW Connection.

GeoTel: :S: ...** Into Log_Error, initial.c **

GeoTel: :S: Log-LOGONLY: A connection with the ICR has been opened.

GeoTel: :T: ....** Into file_toobig, initial.c **

GeoTel: :S: ....** Into file_toobig, initial.c **

GeoTel: m23 15:06:31 :V: ...** Exit Poll_Queue, queues.c, 0 **

trace data


Notes that help you to understand the trace:

v The time stamp is printed only when it changes, or every 20 lines.

v The process that issued the messages is shown between colons after the

time stamp:

C Call Process

I Initialization

S Socket Process

T Simulator Process

V VRU Monitor Processv An entry into a subroutine is shown by a messages that begin ** Into.

...

GeoTel: :T: ->OPEN_REQ @0 InvokeID:4 >15633< @4 VersionNumber:4 >4< @8

IdleTimeout:4 >20000<

GeoTel: :T: .....** Exit Message, messages.c, 3 **

GeoTel: :T: S02 L12 T3 >00 00 3d 11 00 00 00 04 00 00 4e 20<

GeoTel: :T: ....** Exit Read_File, simulate.c, 20 **

GeoTel: :T: MsgSize: 20

GeoTel: :T: S01 L12 T3 >00 00 3d 11 00 00 00 04 00 00 4e 20<

GeoTel: :T: ....** Into Process_Sockets_Msg, sockproc.c **

GeoTel: :T: Simulator 1, Source 2

GeoTel: :T: .....** Into Process_Msg, simulate.c **

GeoTel: m23 15:06:32 :T: Source of Message = Simulator File

GeoTel: :T: S00 L12 T3 >00 00 3d 11 00 00 00 04 00 00 4e 20<

GeoTel: :T: ......** Into Message, messages.c **

GeoTel: :T: msg: 3 ToMSG: 0 Log: 0

GeoTel: :T: <-OPEN_REQ @0 InvokeID:4 >15633< @4 VersionNumber:4 >4< @8


GeoTel: :T: ......** Exit Message, messages.c, 3 **

GeoTel: :T: S01 L12 T3 >00 00 3d 11 00 00 00 04 00 00 4e 20<

GeoTel: :T: ......** Into Put_Message, sockproc.c **

GeoTel: :T: .......** Into Message, messages.c **

GeoTel: :T: msg: 3 ToMSG: 1 Log: 0

GeoTel: :T: ->OPEN_REQ @0 InvokeID:4 >15633< @4 VersionNumber:4 >4< @8


GeoTel: m23 15:06:32 :T: .......** Exit Message, messages.c, 3 **

GeoTel: :T: .......** Into Monitor, messages.c **

GeoTel: :T: Monitor operation = 1

GeoTel: :T: .......** Exit Monitor, messages.c, 0 **

GeoTel: :T: .......** Into Put_Socket, sockproc.c **

GeoTel: :T: ........** Into Write_Socket, sockets.c **

GeoTel: :T: Writing to socket 4 size 20.

GeoTel: :T: ........** Exit Write_Socket, sockets.c, 20 **

GeoTel: :T: ........** Into Log_Message, messages.c **

GeoTel: :T: .........** Into Message, messages.c **

GeoTel: :T: mtype -999

...

trace data


v An exit from a subroutine is shown by messages that begin ** Exit. The

return code goes before the final **.

v Because all the processes write to the standard output, interrupted print

lines might occur.

Printable ICM messages

A printable form of an ICM message might appear in the log and trace files.

The format of a message is as follows:

v An indication of the flow of the message, as follows:

<- The message is received by the Cisco ICM custom server.

-> The message is sent from the Cisco ICM custom server.

<= The message is received by the simulator.

=> The message is sent from the simulator.v The name of the message

v The contents of the message shown in pairs of:

– Field name

– Field content delimited by > and <

Empty STRING data is not shown.

In a trace file, a message appears with the additional data of:

v Offset of field from start of message shown following @

v Length of field shown following : at the end of a field name

You can use an example of a message in “Status data” on page 153.

trace data


Notices

This information was developed for products and services offered in the

U.S.A.

IBM® may not offer the products, services, or features discussed in this

document in other countries. Consult your local IBM representative for

information on the products and services currently available in your area. Any

reference to an IBM product, program, or service is not intended to state or

imply that only that IBM product, program, or service may be used. Any

functionally equivalent product, program, or service that does not infringe

any IBM intellectual property right may be used instead. However, it is the

user’s responsibility to evaluate and verify the operation of any non-IBM

product, program, or service.

IBM may have patents or pending patent applications covering subject matter

described in this document. The furnishing of this document does not give

you any license to these patents. You can send license inquiries, in writing, to:

The IBM Director of Licensing, IBM Corporation, North Castle Drive,

Armonk, NY 10504-1785, U.S.A.

For license inquiries regarding double-byte (DBCS) information, contact the

IBM Intellectual Property Department in your country or send inquiries, in

writing, to:

IBM World Trade Asia Corporation Licensing, 2-31 Roppongi 3-chome

Minato-ku, Tokyo 106, Japan

The following paragraph does not apply to the United Kingdom or any

other country where such provisions are inconsistent with local law:

INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS

PUBLICATION ″AS IS″ WITHOUT WARRANTY OF ANY KIND, EITHER

EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE

IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY

OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow

disclaimer of express or implied warranties in certain transactions, therefore,

this statement may not apply to you.

This information could include technical inaccuracies or typographical errors.

Changes are periodically made to the information herein; these changes will

be incorporated in new editions of the publication. IBM may make


improvements and/or changes in the product(s) and/or the program(s)

described in this publication at any time without notice.

Any references in this information to non-IBM Web sites are provided for

convenience only and do not in any manner serve as an endorsement of those

Web sites. The materials at those Web sites are not part of the materials for

this IBM product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it

believes appropriate without incurring any obligation to you.

Licensees of this program who wish to have information about it for the

purpose of enabling: (i) the exchange of information between independently

created programs and other programs (including this one) and (ii) the mutual

use of the information which has been exchanged, should contact: IBM UK

Limited, Department 88013, 4NW, 76/78 Upper Ground, London, SE1 9PZ,

England. Such information may be available, subject to appropriate terms and

conditions, including in some cases, payment of a fee.

The licensed program described in this document and all licensed material

available for it are provided by IBM under terms of the IBM Customer

Agreement, IBM International Programming License Agreement, or any

equivalent agreement between us.

Information concerning non-IBM products was obtained from the suppliers of

those products, their published announcements or other publicly available

sources. IBM has not tested those products and cannot confirm the accuracy

of performance, compatibility or any other claims related to non-IBM

products. Questions on the capabilities of non-IBM products should be

addressed to the suppliers of those products.

COPYRIGHT LICENSE: This information contains sample application

programs in source language, which illustrate programming techniques on

various operating platforms. You may copy, modify, and distribute these

sample programs in any form without payment to IBM, for the purposes of

developing, using, marketing or distributing application programs conforming

to the application programming interface for the operating platform for which

the sample programs are written. These examples have not been thoroughly

tested under all conditions. IBM, therefore, cannot guarantee or imply

reliability, serviceability, or function of these programs.

This information contains examples or data and reports used in daily business

operations. To illustrate them as completely as possible, the examples include

the name of individuals, companies, brands and products. All of these names

are fictitious and any similarity to the names and addresses used by an actual

business enterprise is entirely coincidental.


For country-specific notes on the use of WebSphere Voice Response, refer to

the README file located in the directory /usr/lpp/dirTalk/homologation.

The file name is in the format README_homologation.xxxx, where xxxx is

the country/region identifier.

Trademarks

The following terms are trademarks of IBM Corporation in the United States

or other countries or both:

AIX IBM WebSphere

DB2 pSeries

DirectTalk RS/6000

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of

Microsoft Corporation in the United States, other countries, or both.

Java and all Java-based trademarks and logos are trademarks of Sun

Microsystems, Inc. in the United States, other countries, or both.

Other company, product or service names may be trademarks or service

marks of others.

Notices 163

Glossary

The following terms and abbreviations are defined as they are used in the context of

WebSphere Voice Response. If you do not find the term or abbreviation you are looking for,

see IBM Dictionary of Computing, McGraw-Hill, 1994 or the AIX: Topic Index and Glossary,

SC23–2513.

Special Characters

µ-law. The companding algorithm that is used

primarily in North America and Japan when

converting from analog to digital speech data.

(Compand is a contraction of compress and

expand.) Contrast with A-law.

Numerics

2 B-channel transfer feature. See Integrated

Services Digital Network (ISDN) two B-channel

transfer.

3270 host application. An application on the

IBM System/370™ System/390®, or AS/400® that

interacts with terminals that support the 3270

data stream.

3270 script language. See script language.

3270 server. A function of WebSphere Voice

Response that provides a software interface

between WebSphere Voice Response and IBM

System/370, System/390, or AS/400 architecture

business applications that interact with terminals

that support the 3270 data stream. Contrast with

custom server.

5ESS. (1) A Lucent Technologies switch. (2) The

ISDN protocol that is used on the 5ESS switch. It

provides 23 B-channels and a D-channel over a

T1 trunk.

6309 Digital Trunk Quad Adapter. See Digital

Trunk Quad Adapter.

6310 Digital Trunk Extended Adapter (DTXA).

See Digital Trunk Extended Adapter.

6312 Digital Trunk Telephony Adapter

(DTTA). See Digital Trunk Telephony Adapter.

6313 Digital Trunk Telephony Adapter (DTTA)

with Blind Swap Cassette (BSC). See Digital

Trunk Telephony Adapter with Blind Swap

Cassette.

A

A-law. The companding algorithm that is used

in Europe, Latin America, and other countries

when converting from analog to digital speech

data. (Compand is a contraction of compress and

expand.) Contrast with µ-law.

access protocol. A protocol that is used between

an external subscriber and a switch in a

telephone network.

ACD. See automatic call distributor.

ACL. See application connectivity link.

action. See state table action.

Action Palette. An area that contains folders

and icons that can be selected to create state

table actions.

Address Resolution Protocol (ARP). In

HACMP, the Internet communication protocol

that dynamically maps Internet addresses to

physical (hardware) addresses on local area

networks. Limited to networks that support

hardware broadcast.

The usr/sbin/cluster/etc/clinfo.rc script, which is

invoked by the clinfo daemon whenever a

network or node event occurs, updates the

system ARP cache. This ensures that the IP


addresses of all cluster nodes are updated after

an IP address takeover. The script can be further

customized to handle site-specific needs.

administrator profile. Data that describes a

WebSphere Voice Response user. Information that

is in an administrator profile includes ID,

password, language preference, and access

privileges.

ADSI. See analog display services interface.

ADSI telephone. A “smart” telephone that can

interpret and return ADSI data.

advanced intelligent network (AIN). A

telephone network that expands the idea of the

intelligent network (IN) to provide special services

more efficiently; for example, by giving users the

ability to program many of the services

themselves.

AIN. See advanced intelligent network.

alarm. Any condition that WebSphere Voice

Response thinks worthy of documenting with an

error message. Strictly, the term alarm should

include only red (immediate attention) and

yellow (problem condition), but it is also used to

refer to green (a red or yellow message has been

cleared) and white (information) conditions.

Contrast with alert.

alert. A message that is sent to a central

monitoring station, as the result of an alarm.

Contrast with alarm.

alternate mark inversion (AMI). A T1 line

coding scheme in which binary 1 bits are

represented by alternate positive and negative

pulses and binary 0 bits by spaces (no pulse).

The purpose is to make the average dc level on

the line equal to zero.

AMI. See alternate mark inversion.

analog. Data in the form of continuously

variable signals, such as voice or light signals.

analog display services interface (ADSI). A

Bellcore signaling protocol that is used with

existing voice networks. ADSI supports analog

transmission of voice and text-based information

between a host or switch, voice mail system,

service bureau, or similar, and a subscriber’s

ADSI-compatible screen telephone. A single

voice-grade telephony channel is shared between

voice and data, using a technique by which the

channel is taken over for the transmission of

modem-encoded data.

ANI. See automatic number identification.

annotation. In speech recognition, an

alphanumeric string that is used to mark a

grammar when it is defined. When the grammar

is used in an application, both the word and the

alphanumeric string are returned to the

application.

announcement-only greeting. In voice mail, a

greeting that does not give the caller a chance to

leave a voice message.

application. A (usually) customer-written

program or set of programs that might consist of

one or more state tables or custom servers that

are running on WebSphere Voice Response, with

associated voice segments. See voice application.

application connectivity link (ACL). A service

that transmits out-of-band information between

WebSphere Voice Response and the Siemens

Hicom 300 switch.

application profile. Data that describes initial

actions that are to be performed when the

telephone is answered. Information in an

application profile indicates to the channel

process which state table to load.

application server interface (ASI). The

principal software component of WebSphere

Voice Response that manages the real-time

channel processing.

application server platform (ASP). A platform

that is used for Web and voice applications for

e-business.

ARTIC960RxD Quad Digital Trunk PCI

Adapter. See Digital Trunk Extended Adapter.

ASI. See application server interface.

glossary


ASP. See application server platform.

audio name. The audible name that relates to a

specific application profile ID and mailbox.

auto-attendant. Automated attendant. A voice

application that answers incoming calls and asks

callers which number or other service they

would like.

automatic call distributor (ACD). A telephone

system feature that automatically queues and

processes inbound calls according to predefined

rules. For example, a call might be routed to the

agent whose line has been idle longest.

automatic number identification (ANI). A

service available in the U.S. that provides the

telephone number of the calling party. It is

generated by the caller’s originating central office

switch, sent to a telephone network carrier if

required, then sent directly either to a switch or

to a voice processing system.

autostubbing. A state table icon view utility

that automatically converts lines into stubs when

they cross a specified number of columns.

B

B8ZS. Bipolar with 8-zero substitution. A T1

line code that is required for 64Kb channels such

as ISDN.

B-channel. See bearer channel. See also Integrated

Services Digital Network (ISDN) .

background music. Any audio data that is to be

played on a music channel.

barge-in. The capability that allows a prompt to

be interrupted by an utterance that is then

passed to a speech recognizer. See also

cut-through channel.

baseforms. The set of phonetic pronunciations

that are associated with a grammar. In

WebSphere Voice Server, the IBM dictionary of

pronunciations is used.

basic rate interface (BRI). The means of ISDN

access that is normally used by private

subscribers. It provides two B-channels of 64 Kb

per second and one D-channel of 16 Kb per

second for signaling. This is often known as

2B+D. Contrast with primary rate interface (PRI).

beans. Java beans with which you can build

voice applications to use the services of

WebSphere Voice Response on any platform.

bearer channel. In an ISDN interface, a duplex

channel for transmitting data or digital voice

between the terminal and the network. The

B-channel operates at 64 Kb per second.

bearer service. The type of service that defines

how an ISDN connection will be used. Typical

bearer services are speech telephony, 64 Kb per

second data, and high-quality speech.

blind transfer. A type of call transfer in which

the call is routed to another extension and the

original call is ended. No check is made to

determine whether the transferred call is

answered or if the number is busy. Contrast with

screened transfer.

bnf. Abbreviation for Backus-Naur Form, which

is used to describe the syntax of a given

language and its notation. In speech recognition,

a special adaptation of grammar representation

that is specified by Speech Recognition Control

Language (SRCL) (pronounced “circle”).

bos. Base Operating System.

bps. bits per second.

BRI. See basic rate interface.

bridge. See DVT bridge.

British Approvals Board for

Telecommunications. The British standards

organization that is responsible for approval of

equipment that is to be attached to the PSTN.

C

cadence. The modulated and rhythmic

recurrence of an audio signal. For example, a

series of beeps or a series of rings.

glossary

Glossary 167

call. Telephone call. Often used to mean a single

run-time instance of a voice application.

call center. A central point at which all inbound

calls are handled by a group of individuals in a

controlled sequential way. Call centers are

usually a front end to a business such as airline

ticketing or mail order.

Call Control eXtensible Markup Language

(CCXML). Language designed to provide

telephony call control support for VoiceXML or

other dialog systems. Refer to the CCXML forum

web site at http://www.w3.org/TR/ccxml

call forwarding. The process of sending

incoming calls to a different number.

called party. Any person, device, or system that

receives a telephone call. Contrast with caller.

caller. (1) Any person, device, or system that

makes a telephone call. (2) Often used to refer to

any user of a voice application, although

WebSphere Voice Response might have made an

outbound call and the user is really the called

party. (3) In voice mail, any person who makes a

telephone call to a subscriber. Contrast with user.

calling line identification presentation (CLIP).

An ISDN supplementary service that advises the

called party of the caller’s number; for example,

by displaying it on a telephone display panel.

CallPath. Software that provides basic

computer-telephony integration (CTI) enablement

and comprehensive CTI functionality. This

includes access to, and management of, inbound

and outbound telecommunications.

call session. The sequence of events that occurs

from the time a call is started to the time all

activities related to answering and processing the

call are completed.

call transfer. A series of actions that directs a

call to another telephone number. See also

dual-line call transfer.

CAS. See channel associated signaling.

cascading resources. Resources that can be

taken over by more than one node. A takeover

priority is assigned to each configured cluster

resource group in a per-node way. In the event of

a takeover, the node with the highest priority

gets the resource group. If that node is

unavailable, the node with the next-highest

priority gets the resource group, and so on.

CAS tone. Customer Premise Equipment

Alerting Signal tone. In ADSI, this tone is sent to

the ADSI telephone to switch the phone to data

mode.

CBX. See computerized branch exchange.

CCH. See Comité de Coordination de

l’Harmonisation.

CCITT. See Comité Consultatif International

Télégraphique et Téléphonique.

CCS. See common channel signaling (CCS).

central office (CO). A telephone switching

system that resides in the telephone service

provider’s network. Different types of central

office switches exist, depending upon the role of

the switch in the telephone network. Commonly,

a central office switch connects customer lines to

other customer lines or trunks, and is the point

at which local subscriber lines end for switching

to other lines or trunks.

central registry. A component of the Licence

Use Management network topology. A server’s

database that logs requests for licenses, upgrades

for licenses, and journals all license activity in a

tamper-proof auditable file.

CEPT. See Conference Européenne des

Administrations des Postes et Télécommunications.

CGI. See Common Gateway Interface.

channel. One of the 24 channels that are on a

T1 trunk, or one of the 30 channels that are on

an E1 trunk. See also speech recognition session,

music channel.

channel-associated signaling (CAS). A method

of communicating telephony supervisory or line

glossary


signaling (on-hook and off-hook) and address

signaling on T1 and E1 digital links. The

signaling information for each traffic (voice)

channel is transmitted in a signaling channel that

is permanently associated with the traffic

channel. On T1 links, supervisory signaling is

sent in the traffic channel by using robbed-bit

signaling (RBS). On E1 links, a separate channel is

used to send signaling. Address signaling can be

transmitted either in the signaling channel

(out-of-band) or in the traffic channel (in-band).

Contrast with common channel signaling (CCS).

channel bank. A device that converts an analog

line signal to a digital trunk signal.

channel number. The identifying number that is

assigned to a licensed channel on the T1 or E1

trunk that connects WebSphere Voice Response to

the switch, channel bank, or channel service unit.

channel process (CHP). The AIX process that

runs the logic of the state table; each active caller

session has one active channel process.

channel service unit (CSU). A device that is

used to connect a digital phone line to a

multiplexer, a channel bank, or directly to

another device that generates a digital signal. A

CSU performs specific line-conditioning and

equalization functions, and responds to loopback

commands that are sent from the CO.

CHP. See channel process.

CIC. See circuit identification code.

CICS. See customer information control system.

circuit identification code (CIC). A 12-bit

number that identifies a trunk and channel on

which a call is carried.

clear message. A message that is displayed by

WebSphere Voice Response to tell the operator

that a red or yellow error message has been

cleared.

client node. In a single system image (SSI), a

WebSphere Voice Response system that handles

interactions with callers. A client node must have

a telephony connection. It does not store

application or voice data; it gets data from the

server node of the SSI.

CLIP. See calling line identification presentation.

cluster. Loosely-coupled collection of

independent systems (nodes) that are organized

into a network to share resources and to

communicate with each other. HACMP defines

relationships among cooperating systems where

peer cluster nodes provide the services that a

cluster node offers if that node cannot do so.

cluster configuration. User definition of all

cluster components. Component information is

stored in the Object Data Manager. Components

include cluster name and ID, and information

about member nodes, adapters, and network

modules.

CO. See central office.

codec. Refers to adapters that compress and

decompress video files. The letters ″codec″

represent ″compression/decompression″; in the

past, they represented ″coder/decoder.″

Comité de Coordination de l’Harmonization.

The CEPT committee responsible for standards.

Comitato Elettrotechnico Italiano. The Italian

standards organization responsible for signaling

protocols.

Comité Consultatif International Télégraphique

et Téléphonique (CCITT). This organization

has been renamed and is now known as the

International Telecommunications Union -

Telecommunication Standardization Sector

(ITU-T).

common channel signaling (CCS). A method of

communicating telephony information and line

signaling events (for example, call setup and call

clearing) on a dedicated signaling channel. The

signaling channel is either a predefined channel

on an E1 or T1 digital link, or a completely

separate link between the switch and WebSphere

Voice Response. For data integrity and reliability,

the information is usually communicated using a

data link protocol. The telephone information

glossary

Glossary 169

and line signaling events are sent as data

packets. SS7 and ISDN are common-channel

signaling protocols. Contrast with channel

associated signaling.

Common Gateway Interface (CGI). An

interface to programs that provide services on

the world wide Web.

compiled grammar file. A grammar in binary

format that was built by the WebSphere Voice

Server grammar development tools.

compound license. In License Use

Management, a type of license that allows a

system administrator to generate license

passwords for a given number of licenses. A

compound license can generate either

nodelocked or non-nodelocked licenses, but not

both

computer-telephony integration (CTI). The use

of a general-purpose computer to issue

commands to a telephone switch to transfer calls

and provide other services. Typically, CTI is used

in call centers.

computerized branch exchange (CBX). A

computer-driven, digital communications

controller that provides telephone

communication between internal stations and

external networks.

Conférence Européenne des Administrations

des Postes et Télécommunications (CEPT).

European Conference of Postal and

Telecommunications Administrations.

configuration file. See parameter file.

configuration parameter. A variable that controls

the behavior of the system or the behavior of all

applications that are running on the system. See

parameter file, system parameter.

container window. A window that lists the

names of all existing objects of the same type.

context. A set of one or more grammars that is

enabled and used during a recognition action.

The grammars are specified by a FILELIST file.

Parameters that influence the recognition, such as

the maximum initial silence period and the

ending silence period, are also defined by the

context. More than one context can be enabled

for a recognition.

context name. The name given to a context in a

context profile that is used for WebSphere Voice

Server.

context profile. Describes to the WebSphere

Voice Server process which contexts should be

loaded into an engine. A WebSphere Voice

Response for Windows application specifies

which context profiles to load into the engine it

has reserved.

context type. Indicates to the recognition engine

how to interpret the grammar file. Possible types

are: VOCAB_FILE, GRAMMAR_FILE, TEXT,

MNR_FILE, MNR, PERSONAL_FILE,

PERSONAL_WDS, BASEFORM_FILE.

continuous speech recognition. Recognition of

words that are spoken in a continuous stream.

Unlike isolated or discrete word recognition,

users do not have to pause between words.

conversation. See speech recognition session.

CPE. See customer premises equipment.

CSU. See channel service unit .

CTI. See computer-telephony integration.

customer information control system (CICS). A

licensed program that enables transactions that

are entered at remote workstations to be

processed concurrently by user-written

application programs. It includes facilities for

building, using, and maintaining databases.

custom server. A C language or C++ language

program that provides data manipulation and

local or remote data stream, database, or other

services that are additional to those that the state

table interface provides. Custom servers provide

an interface between WebSphere Voice Response

and business applications, functions, or other

processes to give callers access to business

information and voice processing functions such

as speech recognition.

glossary


customer premises equipment (CPE).

Telephony equipment that is on the premises of a

business or domestic customer of the telephone

company. An example is a private branch

exchange (PBX).

cut-through channel. A channel of voice data

that has been passed through echo-cancellation

algorithms. The channel provides echo-canceled

voice data that can then be used by the engine in

a recognition attempt. This is similar to barge-in.

D

daemon. In the AIX operating system, a

program that runs unattended to perform a

standard service.

database server node. In a single system image

(SSI), a WebSphere Voice Response system that

contains the WebSphere Voice Response DB2®

database. This is usually the same node as the

voice server node.

DBIM. The internal database manager of

WebSphere Voice Response.

DBS. The database server of WebSphere Voice

Response.

DCBU. See D-channel backup.

D-channel. See delta channel.

D-channel backup (DCBU). An ISDN NFAS

configuration where two of the T1 facilities have

a D-channel, one of which is used for signaling,

and the other as a backup if the other fails. See

also non-facility associated signaling.

DDI. See direct inward dialing.

DDS. See production system.

delay start. A procedure that is used with some

channel-associated signaling protocols to indicate

when a switch or PABX is ready to accept

address signaling. After seizure, the switch sends

off-hook until it is ready to accept address

signaling, at which time it sends on-hook.

Contrast with immediate start and wink start.

delta channel. In an ISDN interface, the

D-channel or delta channel carries the signaling

between the terminal and the network. In a basic

rate interface, the D-channel operates at 16 Kb

per second. In a primary rate interface, the

D-channel operates at 64 Kb per second.

destination point code (DPC). A code that

identifies the signaling point to which an MTP

signal unit is to be sent. Unique in a particular

network.

development system. A WebSphere Voice

Response system that is not used to respond to,

or make, “live” calls; it is used only to develop

and test applications. Contrast with production

system.

dial. To start a telephone call. In

telecommunication, this action is performed to

make a connection between a terminal and a

telecommunication device over a switched line.

dial by name. To press the keys that are related

to subscribers’ names instead of to their

telephone numbers or extensions.

dialed number identification service (DNIS). A

number that is supplied by the public telephone

network to identify a logical called party. For

example, two toll-free numbers might both be

translated to a single real number. The DNIS

information distinguishes which of the two

toll-free numbers was dialed.

dialog box. A secondary window that presents

information or requests data for a selected action.

dial tone. An audible signal (call progress tone)

that indicates that a device such as a PABX or

central office switch is ready to accept address

information (DTMF or dial pulses).

DID. See direct inward dialing.

digital signal processing (DSP). A set of

algorithms and procedures that processes

electronic signals after their conversion to digital

format. Because of the specific mathematical

models that are required to perform this

processing, specialized processors are generally

used.

glossary

Glossary 171

Digital Subscriber signaling System Number 1

(DSS1). A signaling protocol that is used

between ISDN subscriber equipment and the

network. It is carried on the ISDN D-channel.

ITU-T recommendations Q.920 to Q.940 describe

this protocol.

Digital Trunk Ethernet Adapter (DTEA). A

Radysis adapter card that provides the audio

streaming (RTP) interface between the

WebSphere Voice Response internal H.100 bus

and Ethernet for a maximum of 120 channels

using uncompressed (G.711) voice, and

compressed G.723.2 and G.729A compressed

voice.

Digital Trunk Extended Adapter (DTXA). The

IBM ARTIC960RxD Quad Digital Trunk PCI

Adapter. In WebSphere Voice Response, this

adapter is known as a DTXA. It allows you to

connect directly to the telephony network from a

pSeries computer without the need for an

external pack.

Digital Trunk No Adapter (DTNA). A software

implementation of the DTEA that only supports

uncompressed (G.711) voice.

Digital Trunk Telephony Adapter (DTTA). The

IBM Quad Digital Trunk Telephony PCI Adapter.

In WebSphere Voice Response, this adapter is

known as a DTTA. It allows you to connect

directly to the telephony network from a pSeries

computer without the need for an external pack.

The DTTA supersedes the DTXA.

Digital Trunk Telephony Adapter (DTTA) with

Blind Swap Cassette (BSC). The IBM Quad

Digital Trunk Telephony PCI Adapter. In

WebSphere Voice Response, this adapter is

known as a DTTA. It allows you to connect

directly to the telephony network from a pSeries

computer without the need for an external pack.

This DTTA includes a short Blind Swap Cassette

(BSC) which is required for installing the DTTA

in machines that use the BSC (for example, the

pSeries 650–6M2).

Digital Trunk Quad Adapter (DTQA). (Feature

code 6309) An adapter that completes the

connection to four packs in a Multiple Digital

Trunk Processor.

diphone. A transitional phase from one sound

to the next that is used as a building block for

speech synthesis. Typically, between one

thousand and two thousand diphones exist in

any national language.

direct dial in (DDI). See direct inward dialing.

direct inward dialing (DID). A service that

allows outside parties to call directly to an

extension of a PABX. Known in Europe as direct

dial in (DDI).

direct speech recognition. Identification of

words from spoken input that are read directly

from the telephony channel. Contrast with

indirect speech recognition.

DirectTalk bean. One of the beans that is

provided with WebSphere Voice Response. It

provides access from a voice application to

simple call control functions: waiting for a call,

making an outgoing call, handing a call over to

another application, and returning a call when

finished.

discrete word recognition. Identification of

spoken words that are separated by periods of

silence, or input one at a time. Contrast with

continuous speech recognition.

disconnect. To hang up or terminate a call.

Distributed Voice Technologies (DVT). A

component of WebSphere Voice Response that

provides an interface to allow you to integrate

your own voice technology (such as a speech

recognizer) with your WebSphere Voice Response

system.

distribution list. In voice mail, a list of

subscribers to whom the same message can be

sent.

DMS100. (1) A Northern Telecom switch. (2)

The custom ISDN protocol that is run on the

glossary


DMS100 switch, providing 23 B-channels and a

D-channel over a T1 trunk.

DNIS. See dialed number identification service.

double-trunking. See trombone.

down. The condition in which a device is

unusable as a result of an internal fault or of an

external condition, such as loss of power.

downstream physical unit (DSPU). Any remote

physical unit (data link, storage, or input/output

device) that is attached to a single network host

system.

DPC. See destination point code.

drop-in grammar. A set of precompiled

grammar rules that can be used by an

application-specific grammar to improve the

recognition performance.

DSP. See digital signal processing.

DSPU. See downstream physical unit.

DSS1. See Digital Subscriber signaling System

Number 1.

DTMF. See dual-tone multifrequency.

DTEA. See Digital Trunk Ethernet Adapter.

DTNA. See Digital Trunk No Adapter.

DTQA. See Digital Trunk Quad Adapter.

dtuser. The name of the AIX account that is set

up during the installation process for the use of

all users of WebSphere Voice Response.

DTTA. See Digital Trunk Telephony Adapter.

DTXA. See Digital Trunk Extended Adapter.

dual-line call transfer. A call transfer method in

which the primary and secondary lines remain

bridged until a call is completed. (Also known as

tromboning: see trombone).

dual-tone multifrequency (DTMF). The signals

are sent when one of the telephone keys is

pressed. Each signal is composed of two different

tones.

DVT. See Distributed Voice Technologies.

DVT bridge. The interface between a voice

technology component (such as a speech

recognizer) and the DVT server. A bridge must

exist for each technology that you want to

integrate with DVT.

DVT_Client2. A WebSphere Voice Response

custom server that passes commands and data to

DVT_Server.

DVT interface. A WebSphere Voice Response

programming interface that is used by a DVT

bridge. It enables integration of voice

applications with Distributed Voice Technologies to

provide functions such as speech recognition.

DVT_Server. A component of DVT that

allocates and manages system resources in

response to requests from DVT_Client2.

DVT service. The combination of a voice

application, a DVT bridge, and a voice

technology that allows a caller to interact with

your business.

dynamic vocabulary. A vocabulary that is

defined while an application is running.

E

E&M. A channel-associated signaling protocol

in which signaling is done using two leads: an

M-lead that transmits battery or ground and an

E-lead that receives open or ground.

E1. A digital trunking facility standard that is

used in Europe and elsewhere. It can transmit

and receive 30 digitized voice or data channels.

Two additional channels are used for

synchronization, framing, and signaling. The

transmission rate is 2048 Kb per second. Contrast

with T1.

glossary

Glossary 173

echo cancelation. A filter algorithm that

compares a copy of the voice data that is being

sent to a caller, with the voice data being that is

received from the caller. Any echo of the sent

data is removed before the received data is sent

on, for example, to a speech recognizer.

edge. See result.

EDL. See exchange data link.

emulation. The imitation of all or part of one

computer system by another, so that the

imitating system accepts the same data, runs the

same programs, and gets the same results as the

imitated computer system does.

endpoint. In Voice over Internet Protocol, a place

where calls are originated and ended.

engine. A speech recognition process that

accepts voice data as input and returns the text

of what was said as output. It is the process that

performs the recognition.

engine type. Each engine must be configured

with a specific type. The type is a textual tag that

is associated with a specific engine and does not

change the operation or functionality of the

engine.

error message. Any message that is displayed

by WebSphere Voice Response in the System

Monitor as an alarm and optionally written to the

WebSphere Voice Response error log, or to the

AIX error log (as an alert). Strictly, the term error

message should include only red (immediate

attention) and yellow (problem situation)

messages, but it is also used to refer to green (a

red or yellow message has been cleared) and

white (informational) messages.

Ethernet. A 10/100 network connection between

the VoIP gateway and the Speech Server that

supports VoIP.

ETS. European Telecommunications Standard or

European Telecommunication Specification.

ETSI. European Telecommunications Standards

Institute.

Euro-ISDN. The common European ISDN

standard, agreed in 1993, that provides a basic

range of services and supplementary services

using 30 B-channels plus a D-channel over an E1

trunk.

exchange data link. A serial connection that

carries messaging information between

WebSphere Voice Response and the Lucent

Technologies 1AESS, Northern Telecom DMS100,

Ericsson MD110 switch, or Siemens Hicom 300.

exit. A point in a supplied application from

which control can be passed to another

custom-written application. On completion, the

custom-written application passes control back to

the supplied application.

F

fade in. To gradually increase the volume of

sounds, such as background music.

fade out. To gradually decrease the volume of

sounds, such as background music.

failover. A transparent operation that, in the

event of a system failure, switches responsibility

for managing resources to a redundant or

standby system. Also known as fallover.

FDM. See Feature Download Management.

Feature Download Management (FDM). An

ADSI protocol that enables several alternative

key and screen overlays to be stored in an ADSI

telephone, and to be selected by predetermined

events at the telephone.

Federal Communication Commission (FCC).

The standard body in the United States that is

responsible for communication.

field. An identifiable area in a window that is

used to enter or display data.

FILELIST. A WebSphere Voice Server Telephony

runtime file that defines which files to load into

a WebSphere Voice Server engine. It contains a

list in the form:

context type grammar filename

glossary


... ...

Recursion is not permitted; that is, no contexts of

type FILELIST can be specified in a FILELIST.

When a FILELIST is loaded, all the grammars

that are specified in it are loaded into the engine.

From then on, the grammars that are loaded

when the FILELIST is specified are regarded as a

single context.

Foreign Exchange Subscriber (FXS). A

signaling protocol that links a user’s location to a

remote exchange that would not normally be

serving that user, to provide, for example, calls

to outside the local area at the local rate.

frame. A group of data bits that is surrounded

by a beginning sequence and an ending

sequence.

fsg. Abbreviation for finite state grammar. In

WebSphere Voice Server, the extension of a file

that contains grammar specifications in compiled,

binary form. It is generated from a .bnf file and

is called a .fsg file.

function. In ADSI, an ADSI instruction or group

of instructions.

FXS. See Foreign Exchange Subscriber.

G

gatekeeper. A component of a Voice over Internet

Protocol that provides services such as admission

to the network and address translation.

gateway. A component of Voice over Internet

Protocolthat provides a bridge between VoIP and

circuit-switched environments.

G.711. Specification for uncompressed voice for

PSTN and Voice over Internet Protocol access.

G.723.1. Compressed audio codecs that are used

on Voice over Internet Protocol connection for

voice.

G.729A. Compressed audio codecs that are used

on Voice over Internet Protocol connection for

voice.

glare. A condition that occurs when both ends

of a telephone line or trunk are seized at the

same time.

grammar. A structured collection of words and

phrases that are bound together by rules. A

grammar defines the set of all words, phrases,

and sentences that might be spoken by a caller

and are recognized by the engine. A grammar

differs from a vocabulary in that it provides rules

that govern the sequence in which words and

phrases can be joined together.

greeting. In voice mail, the recording that is

heard by a caller on reaching subscriber’s

mailbox. See also announcement-only greeting.

Contrast with voice message.

greeting header. In voice mail, a recording that

is made by a subscriber and played to callers

either before or instead of a personal greeting.

Groupe Special Mobile (GSM). A CEPT/CCH

standard for mobile telephony.

H

HACMP (High-Availability Cluster

Multi-Processing) for AIX. Licensed Program

Product (LPP) that provides custom software that

recognizes changes in a cluster and coordinates

the use of AIX features to create a

highly-available environment for critical data and

applications.

HACMP/ES. Licensed Program Product (LPP)

that provides Enhanced Scalability to the

HACMP for AIX LPP. An HACMP/ES cluster

can include up to 32 nodes.

hang up. To end a call. See also disconnect.

HDB3. High-density bipolar of order 3. An E1

line coding method in which each block of four

successive zeros is replaced by 000V or B00V, so

that the number of B pulses between consecutive

V pulses is odd. Therefore, successive V pulses

are of alternate polarity so that no dc component

is introduced. Note: B represents an inserted

pulse that observes the alternate mark inversion

glossary

Glossary 175

(AMI) rule and V represents an AMI violation.

HDB3 is similar to B8ZS that is used with T1.

HDLC. See high-level data link control.

high-level data link control. An X.25 protocol.

homologation. The process of getting a

telephony product approved and certified by a

country’s telecommunications authority.

hook flash. A signal that is sent to a switch to

request a switch feature (such as call transfer).

host application. An application residing on the

host computer.

hunt group. A set of telephone lines from which

a non-busy line is found to handle, for example,

an incoming call.

I

immediate start. A procedure that is used with

some channel-associated signaling protocols,

when the address signaling is sent within 65

milliseconds of going off-hook. Contrast with

delay start and wink start.

IN. See intelligent network.

in-band. In the telephony voice channel, signals

are said to be carried in-band. Contrast with

out-of-band.

indirect speech recognition. Identification of

words from spoken input that are read from a

file. Contrast with direct speech recognition.

initialize. To prepare a system, device, or

program for operation; for example, to initialize

a diskette.

input parameter. Data that is received by a

program such as a prompt, 3270 script, custom

server, or state table from the program that

called it. Contrast with local variable and system

variable.

integrated messaging. A messaging system in

which more than one copy of a single message is

stored, the copies being kept synchronized by the

applications that are used to access them.

Contrast with unified messaging.

Integrated Services Digital Network (ISDN). A

digital end-to-end telecommunication network

that supports multiple services including, but not

limited to, voice and data.

Integrated Services Digital Network (ISDN) call

transfer. In WebSphere Voice Response, an

application that allows you to transfer calls on

Nortel DMS-100 switches using Integrated Services

Digital Network (ISDN) two B-channel transfer, and

on Nortel DMS-100 and DMS-250 switches using

Nortel’s proprietary Release Link Trunk (RLT)

call transfer protocol.

Integrated Services Digital Network (ISDN)

two B-channel transfer. A call transfer feature

that is defined by Bellcore GR-2865-CORE

specification, and used on Nortel and Lucent

switches.

Integrated Services Digital Network user part

(ISUP). Part of the SS7 protocol that supports

telephony signaling applications. The ISDN user

part is defined to carry signaling information

that relates to digital telephones, terminals, and

PABXs in customer premises.

intelligent network (IN). A telephone network

that includes programmable software that is not

resident on the switch. It allows the service

provider to provide special services, such as

special call-handling, that are not dependent on

the capabilities of the switch. See also advanced

intelligent network.

intelligent peripheral (IP). A voice processing

system (such as WebSphere Voice Response) that

provides enhanced services such as voice

response, speech recognition, text-to-speech,

voice messaging, and database access in an

advanced intelligent network.

interactive voice response (IVR). A computer

application that communicates information and

interacts with the caller via the telephone voice

channel.

International Telecommunications Union –

Telecommunication Standardization Sector

glossary


(ITU-T). The name of the organization that was

previously known as the CCITT.

IP. See intelligent peripheral.

ISDN. See Integrated Services Digital Network

(ISDN) .

ISDN two B-channel transfer. See Integrated

Services Digital Network (ISDN) two B-channel

transfer.

ISDN-UP. See Integrated Services Digital Network

user part.

ISUP. See Integrated Services Digital Network user

part.

ITU-T. See International Telecommunications

Union – Telecommunication Standardization Sector.

IVR. See interactive voice response.

J

Java Bean. A reusable Java component. See

beans.

jump out. See call transfer.

K

key. (1) One of the pushbuttons on the

telephone handset; sometimes referred to as a

DTMF key. (2) A component of the keyboard that

is attached to the computer system.

key pad. The part of the telephone that contains

the pushbutton keys.

key pad mapping. The process of assigning

special alphanumeric characters to the keys that

are on a telephone key pad, so that the telephone

can be used as a computer-terminal keyboard.

L

LAN. See local area network.

language model. For speech recognition, a set

of acoustic shapes (in binary format) for a given

set of words, in which word-to-word differences

are maximized, but speaker-to-speaker

differences are minimized. See also vocabulary.

LAPD. See link access protocol for the D-channel.

licensed program product (LPP). A

separately-priced program and its associated

materials that bear an IBM copyright and are

offered under the terms and conditions of a

licensing agreement.

license server. A machine on a network that

holds licenses and distributes them on request to

other machines on the network.

line error. An error on the telephone line that

causes the signal to be impaired.

link access protocol for the D-channel. An

HDLC protocol used in ISDN that ensures a

reliable connection between the network and the

user. Often used as another name for Q.921.

local area network (LAN). A network in which

computers are connected to one another in a

limited geographical area. WebSphere Voice

Response communication with WebSphere Voice

Server speech recognition, text-to-speech, and

single system image (SSI) requires a LAN that is

dedicated to that purpose (unless both are

installed on the same system). A token-ring

network is a type of LAN.

local variable. A user-defined temporary

variable that can be accessed only by the

program (state table, prompt, or 3270 script) for

which it is defined. Contrast with input parameter,

system variable.

M

macro. See system prompt.

MAP. See mobile application part.

MB. See megabyte.

megabyte. (1) For processor storage and real

and virtual memory, 1 048 576 bytes. (2) For disk

storage capacity and transmission rates, 1 000

000 bytes.

glossary

Glossary 177

Message Center. See Unified Messaging

message delivery preference. The subscriber’s

choice of whether voice mail is stored as voice

mail only, as e-mail only, or as both voice mail

and e-mail.

message delivery type. The format in which a

voice message is delivered.

message signal unit (MSU). An MTP packet

that contains data.

message transfer part (MTP). Part of the SS7

protocol that is normally used to provide a

connectionless service that is roughly similar to

levels one through three of the OSI reference

model.

message waiting indicator (MWI). A visible or

audible indication (such as a light or a stutter

tone) that a voice message is waiting to be

retrieved.

MFR1. An in-band address signaling system

that uses six tone frequencies, two at a time.

MFR1 is used principally in North America and

is described in ITU-T recommendations Q.310

through Q.332.

MIME. See multipurpose Internet mail extensions.

mobile application part (MAP). Optional layer

7 application for SS7 that runs on top of TCAP

for use with mobile network applications.

MP. See multiprocessor.

MSU. See message signal unit.

MTP. See message transfer part.

mu(µ)-law. The companding algorithm that is

used primarily in North America and Japan

when converting from analog to digital speech

data. (Compand is a contraction of compress and

expand.) Contrast with A-law.

multiprocessor (MP). A computer that includes

two or more processing units that can access a

common main storage.

multipurpose Internet mail extensions

(MIME). A protocol that is used on Internet for

extending e-mail capability and merging it with

other forms of communication, such as voice

mail and fax.

mumble. Non speech noise that a user interjects

while speaking.

music channel. A channel on which sounds can

be broadcast to one or more telephony (voice)

channels.

music title. The name by which WebSphere

Voice Response knows a tune.

MWI. See message waiting indicator.

N

National ISDN. A common ISDN standard that

was developed for use in the U.S.

NAU. See network addressable unit.

N-Best. The ability to return more than one

speech recognition result. Typically, an array of

results is available in the application in sequence

of descending probability.

NCP. See network control program.

NET. Norme Européenne de

Télécommunication.

Net 5. The test specification for conformance to

the Euro-ISDN standard for primary rate access

to ISDN.

network addressable unit (NAU). Any network

component that can be addressed separately by

other members of the network.

network control program (NCP). Used for

requests and responses that are exchanged

between physical units in a network for data

flow control.

Network File System (NFS). A protocol,

developed by Sun Microsystems, Incorporated,

that allows any host in a network to gain access

to another host or netgroup and their file

glossary


directories. In a single system image (SSI), NFS is

used to attach the WebSphere Voice Response

DB2 database.

network termination. See NT mode.

NFAS. See non-facility associated signaling.

NFS. See Network File System.

node. In a single system image (SSI), one of the

WebSphere Voice Response systems that are in

the cluster.

non-facility associated signaling (NFAS). An

ISDN configuration where several T1 facilities

can be controlled by a single D-channel, instead

of the normal T1 configuration where each T1

facility has 23 B-channels and a D-channel

(23B+D). With NFAS, all 24 timeslots of the non

signaling trunks are available for voice, whereas

only 23 channels can be used on the trunk that

carries signaling traffic (23B+D+n24B).

NT mode. Attachment to the ISDN network is

asymmetric. The network side of the connection

operates in network termination, or NT, mode.

User equipment operates in terminal equipment,

or TE, mode.

O

ODM. See Object Data Manager.

Object Data Manager (ODM). A data manager

intended for the storage of system data. The

ODM is used for many system management

functions. Information that is used in many

commands and SMIT functions is stored and

maintained in the ODM as objects with

associated characteristics.

off-hook. A telephone line state, usually

induced by lifting a receiver, in which the line is

ready to make a call.

offline. Not attached or known to the existing

system configuration, and therefore not in active

operation.

on-hook. A telephone line state, usually

induced by hanging up a receiver, in which the

line is ready to receive a call.

online. In active operation.

OPC. See originating point code.

Open Systems Interconnection (OSI). (1.) The

interconnection of open systems as specified in

particular ISO standards. (2.) The use of

standardized procedures to enable the

interconnection of data processing systems.

Open Systems Interconnection (OSI)

architecture. Network architecture that observes

the particular set of ISO standards that relate to

Open Systems Interconnection.

Open Systems Interconnection (OSI) Reference

Model. A conceptual model composed of seven

layers, each specifying particular network

functions. Developed by the International

Organization for Standardization (ISO) in 1984, it

is considered to be the primary architectural

model for intercomputer communications

originating point code (OPC). A code that

identifies the signaling Point that originated an

MTP signal unit. Unique in a particular network.

OSI. See Open Systems Interconnection.

outgoing mail. In voice mail, messages that are

sent by a subscriber to another subscriber on the

same system, and have not yet been listened to

by the addressee.

out-of-band. In the telephony signaling channel,

as opposed to the voice channel. Signals are said

to be carried out-of-band. Contrast with in-band.

P

PABX. See private automatic branch exchange .

pack. Each DTTA or DTXA contains the

equivalent of four packs. The pack is a digital

trunk processor built into the digital trunk

adapter, so there is no need for external

hardware. See also XPACK.

glossary

Glossary 179

parameter file. An ASCII file that sets

configuration parameters.

password. A unique string of characters that is

known to a computer system and to a user. The

user must specify the character string to gain

access to the system and to the information that

is stored in it.

PBX. See private branch exchange.

PCI. See peripheral component interconnect.

PCM. See Pulse Code Modulation.

PCM fault condition. A fault, such as power

supply failure, or loss of incoming signal, in T1

or E1 equipment. (ITU-T G.732 and G.733.)

peripheral component interconnect (PCI). A

computer busing architecture that defines

electrical and physical standards for electronic

interconnection.

personal greeting. In voice mail, a greeting that

is recorded by a subscriber. Contrast with system

greeting.

phone recognition. Communicating with a

computer using voice via a telephone, over a

telephone line. The computer application

recognizes what was said and takes suitable

action.

port. In time-slot management, one end of a 64

Kbps unidirectional stream that can be attached

to the TDM bus.

port set. In time-slot management, a collection

of ports that can be connected using a single

CA_TDM_Connect() API call to a complementary

collection of ports.

PRA. Primary rate access (PRA). Used as

another name for primary rate interface (PRI).

PRI. See primary rate interface.

primary rate access (PRA). See primary rate

interface.

primary rate interface (PRI). The means of

ISDN access that is normally used by large sites.

It provides 30 (E1) or 23 (T1) B-channels of 64 Kb

per second and one D-channel for signaling. This

is often known as 30B+D or 23B+D. Contrast

with basic rate interface.

primary rate ISDN (PRI). See primary rate

interface.

primitive. A message that is sent from one

process to another.

private automatic branch exchange (PABX). An

automatic private switching system that services

an organization and is usually located on a

customer’s premises. Often used as another

name for private branch exchange (PBX) .

private branch exchange (PBX). A switch inside

a private business that concentrates the number

of inside lines into a smaller number of outside

lines (trunks). Many PBXs also provide advanced

voice and data communication features. Often

used as another name for private automatic branch

exchange .

process a call. To answer the telephone and

perform the correct tasks.

Process Manager. In WebSphere Voice Server,

the process that manages the interaction of all

telephony system processes; for example, starting

and stopping text-to-speech or speech recognition

sessions.

production system. A WebSphere Voice

Response system that responds to or makes

“live” calls. A production system can also be

used to develop new applications. Contrast with

development system.

program temporary fix (PTF). An update to

IBM software.

program data. Application-specific data that can

be associated with a call transfer from CallPath

to WebSphere Voice Response, or in the opposite

direction. This is equivalent to CallPath program

data, but WebSphere Voice Response imposes the

restriction that the data must be a printable

ASCII character string, with a maximum length

of 512 bytes.

glossary


prompt. (1) A message that requests input or

provides information. Prompts are seen on the

computer display screen and heard over the

telephone. (2) In WebSphere Voice Response, a

program that uses logic to determine

dynamically the voice segments that are to be

played as a voice prompt.

prompt directory. A list of all the prompts that

are used in a particular voice application. Used

by the state table to play the requested voice

prompts.

pronunciation. The possible phonetic

representations of a word. A word can have

multiple pronunciations; for example, “the” has

at least two pronunciations, “thee” and “thuh”.

pronunciation dictionary. A file that contains

the phonetic representation of all of the words,

phrases, and sentences for an application

grammar.

pronunciation pool. A WebSphere Voice Server

resource that contains the set of all

pronunciations.

protocol. A set of semantic and syntactic rules

that determines the behavior of functional units

when they get communication. Examples of

WebSphere Voice Response protocols are FXS,

RE, and R2.

PSTN. An ITU-T abbreviation for public

switched telephone network.

PTF. See program temporary fix.

Pulse Code Modulation (PCM). Variation of a

digital signal to represent information.

pushbutton. (1) A key that is on a telephone

key pad. (2) A component in a window that

allows the user to start a specific action.

pushbutton telephone. A type of telephone that

has pushbuttons. It might or might not send tone

signals. If it does, each number and symbol on

the key pad has its own specific tone.

Q

Q.921. The ITU-T (formerly CCITT)

recommendation that defines the link layer of the

DSS1 protocol. Q.921 defines an HDLC protocol

that ensures a reliable connection between the

network and the user. Often used as another

name for LAPD.

Q.931. The ITU-T recommendation that defines

the network layer of the DSS1 protocol. This

layer carries the ISDN messages that control the

making and clearing of calls.

quiesce. To shut down a channel, a trunk line,

or the whole system after allowing normal

completion of any active operations. The

shutdown is performed channel-by-channel.

Channels that are in an idle state are shut down

immediately. Channels that are processing calls

are shut down at call completion.

R

RAI. See remote alarm indication.

RBS. See robbed-bit signaling.

RE. See remote extension.

Recognition Engine server. In WebSphere Voice

Server, the software that performs the speech

recognition and sends the results to the client.

This consists of one ‘Tsm router’ and at least one

‘tsmp’ and one ‘engine’.

reduced instruction set computer (RISC). A

computer that uses a small, simplified set of

frequently-used instructions to improve

processing speed.

referral number. The phone number to which

calls are routed, when call forwarding is active.

rejection. The identification of an utterance as

one that is not allowed by a grammar.

release link trunk (RLT). A custom specification

from Nortel for ISDN call transfer.

glossary

Glossary 181

remote alarm indication (RAI). A remote alarm

(also referred to as a yellow alarm) indicates that

the far-end of a T1 connection has lost frame

synchronization. The Send RAI system parameter

can be set to prevent WebSphere Voice Response

from sending RAI.

remote extension (RE). An E1 signaling

protocol that is similar to FXS loop start.

resource element. A component of an

Intelligent Network. The resource element

contains specialized resources such as speech

recognizers or text-to-speech converters.

response. In speech recognition, the character

string that is returned by the recognizer, through

DVT_Client, to the state table. The string

represents the result of a recognition attempt.

This is the word or words that the recognizer

considers to be the best match with the speech

input.

result. An indicator of the success or failure of a

state table action. It is returned by WebSphere

Voice Response to the state table. Also known as

an edge.

result state. The state that follows each of the

possible results of an action.

return code. A code that indicates the status of

an application action when it completes.

RISC. See reduced instruction set computer.

RLT. See release link trunk.

robbed-bit signaling (RBS). The T1 channel

-associated signaling scheme that uses the least

significant bit (bit 8) of each information channel

byte for signaling every sixth frame. This is

known as 7-5/6-bit coding rather than 8-bit

coding. The signaling bit in each channel is

associated only with the channel in which it is

contained.

S

SAP. See service access point.

SAS. A T1 signaling protocol that is similar to

FXS.

SCbus. See Signal Computing bus.

SCCP. See signaling connection control part.

SCP. See service control point.

screened transfer. A type of call transfer in

which the transfer of the held party to the third

party is completed only if the third party

answers the call. Contrast with blind transfer.

script. The logical flow of actions for a 3270

server program.

script language. A high-level,

application-specific scripting language, which

consists of statements that are used to develop

3270 scripts. These scripts are part of the

interface between a state table and a 3270-based

host business application.

SCSA. See Signal Computing System Architecture.

SDC. See Server Display Control.

SDLC. See Synchronous Data Link Control.

segment ID number. One or more numbers that

are used to identify a voice or prompt segment.

Server Display Control (SDC). An ADSI

control mode in which the ADSI telephone is

controlled through a dialog with a voice

response system.

server node. In a single system image (SSI), a

WebSphere Voice Response system that contains

either the WebSphere Voice Response DB2

database, or the voice data, or both.

service access point (SAP). An OSI term for the

port through which a service user (layer N+1)

accesses the services of a service provider (layer

N).

service control point (SCP). A component of

the intelligent network that provides

transactional services, such as translation of

toll-free numbers to subscriber numbers.

glossary


service information octet (SIO). A field that is

in an MTP message signal unit. It identifies a

higher layer user of MTP, and whether the

message relates to a national or international

network.

service node. An element of an Intelligent

Network. The service node contains the service

logic that controls an intelligent network

application and resources.

service provider. Any company that provides

services for a fee to its customers, such as

telecommunication companies, application

service providers, enterprise IT, and Internet

service providers.

service provider equipment (SPE). The

switching equipment that is owned by the

telephone company.

session. See speech recognition session.

Session Initiation Protocol. A signaling

protocol used for internet conferencing,

telephony, presence, events notification and

instant messaging.

short message service center (SMSC). A

component of the mobile telephony network,

specified by the GSM group of standards, that

provides for exchange of alphanumeric messages

of less than 160 bytes. Messages can be

exchanged between different types of system

such as mobile telephone, alphanumeric pager,

terminal, e-mail, telex, or DTMF telephone.

SIF. See signaling information field.

Signal Computing System Architecture

(SCSA). An architecture that was defined by

Dialogic to support interoperability of software

and hardware components that are developed by

different vendors in the computer telephony

industry.

Signal Computing bus (SCbus). A time

division multiplexed (TDM) hardware bus that

was originated by Dialogic to interconnect

different vendors’ computer telephony adapters.

Specified as part of Signal Computing System

Architecture (SCSA).

signaling. The exchange of control information

between functional parts of the system in a

telecommunications network.

signaling connection control part (SCCP). A

layer 3 protocol that observes OSI.

signaling information field (SIF). The user data

portion of an MTP message signal unit.

signaling link code (SLC). A code that

identifies a particular signaling link that connects

the destination and originating signaling points.

This is used in MTP signaling network

management messages to indicate the signaling

link to which the message relates.

signaling link selection (SLS). A field that is

used to distribute MTP signal units across

multiple signaling links.

signaling mode. The type of signaling protocol,

either channel-associated signaling, or

common-channel signaling.

signaling point. A node in a signaling network

that either originates and receives signaling

messages, or transfers signaling messages from

one signaling link to another, or both.

signaling process. A WebSphere Voice Response

component that controls signaling for an

exchange data link or common-channel signaling

protocol. Some signaling processes are supplied

with WebSphere Voice Response, and others can

be custom-written.

signaling System Number 7 (SS7). The

international high-speed signaling backbone used

for the public-switched telephone network.

silence. A short pause between utterances.

simple mail transfer protocol (SMTP). An

Ethernet protocol that is related to TCP/IP.

simple network management protocol (SNMP).

In the Internet suite of protocols, a network

management protocol that is used to monitor

routers and attached networks. SNMP is an

application layer protocol. Information on

devices managed is defined and stored in the

glossary

Glossary 183

application’s Management Information Base

(MIB). SNMP provides a means of monitoring

WebSphere Voice Response resources remotely.

Simplified Message Desk Interface (SMDI). A

Northern Telecom service that transmits

out-of-band information between WebSphere

Voice Response and particular switches.

Simplified Message Service Interface (SMSI).

A Lucent Technologies service that transmits

out-of-band information between WebSphere

Voice Response and particular switches.

single system image (SSI). A cluster of

WebSphere Voice Response systems that are

connected together using a local area network.

Each system (known as a node) in the cluster is

configured as either a client or a server. A single

system image typically consists of one server

node and multiple client nodes. The client nodes

retrieve applications and voice data from the

server. A second server can be configured for

redundancy.

sink. A port that takes voice data from the

TDM bus. Contrast with source.

SIO. See service information octet.

SIP. See Session Initiation Protocol.

SLC. See signaling link code.

SLS. See signaling link selection.

SMDI. See Simplified Message Desk Interface.

SMIT. See System Management Interface Tool.

SMP. See symmetric multiprocessor.

SMSC. See short message service center.

SMSI. See Simplified Message Service Interface.

SMTP. See simple mail transfer protocol.

SNA. Systems Network Architecture.

SNMP. See simple network management protocol .

source. A port that puts voice data on to the

TDM bus. Contrast with sink.

SPACK. A logical component that consists of a

base card, which connects to the digital trunk

adapter in the pSeries computer, and a trunk

interface card (TIC), which manages the trunk

connection to the switch. Contrast with VPACK

and XPACK.

SPE. See service provider equipment.

speaker-dependent speech recognition.

Identification of spoken words that is related to

knowledge of the speech characteristics of one

speaker. Contrast with speaker-independent speech

recognition.

speaker-independent speech recognition.

Identification of spoken words that is related to

collected knowledge of the speech characteristics

of a population of speakers. Contrast with

speaker-dependent speech recognition.

special character. A character that is not

alphabetic, numeric, or blank. For example, a

comma (,) or an asterisk (*).

speech recognition. The process of identifying

spoken words. See discrete word recognition,

continuous speech recognition, speaker-dependent

speech recognition, speaker-independent speech

recognition.

Speech Recognition Control Language (SRCL).

In WebSphere Voice Server, a structured syntax

and notation that defines speech grammars,

annotations, repetitions, words, phrases, and

associated rules.

speech recognition session. In WebSphere Voice

Server, a sequence of recognition commands that

allocate a recognition engine, and return a

unique identifier to identify the engine.

speech synthesis. The creation of an

approximation to human speech by a computer

that concatenates basic speech parts together. See

also text-to-speech.

SRCL. See Speech Recognition Control Language

(SRCL).

glossary


SS7. See signaling System Number 7.

SSI. See single system image.

SSI-compliant custom server. A custom server

that runs correctly in a single system image. The

custom server observes all the guidelines for the

operation of custom servers in an SSI

environment.

SSI-tolerant custom server. A custom server

that runs in a single system image, but with only

some restrictions.

standalone system. A WebSphere Voice

Response system that is not part of a single

system image (SSI). A standalone system is not

connected to other WebSphere Voice Response

systems, so it contains its own application and

voice data.

state. One step in the logical sequence of actions

that makes a WebSphere Voice Response voice

application.

state table. A list of all the actions that are used

in a particular voice application. A component of

WebSphere Voice Response.

state table action. One instruction in a set of

instructions that is in a WebSphere Voice

Response state table that controls how

WebSphere Voice Response processes various

operations such as playing voice prompts or

recording voice messages. See also state.

stub. A line in a state table that is only partially

displayed.

subscriber. In voice mail, any person who owns

a mailbox.

subscriber class. A named set of variables that

defines a specific level of service available to

telephone subscribers, such as maximum number

of messages per mailbox and maximum number

of members per mailbox distribution list.

subvocabulary. A vocabulary that is called by

another vocabulary.

supplementary service. In Euro-ISDN, a service

outside the minimum service offering that each

signatory is obliged to provide. For example,

calling line identification presentation (CLIP) and

call session.

switch. A generic term that describes a

telecommunications system that provides

connections between telephone lines and trunks.

symmetric multiprocessor (SMP). A system in

which functionally-identical multiple processors

are used in parallel, providing simple and

efficient load-balancing.

Synchronous Data Link Control (SDLC). A

discipline for managing synchronous,

code-transparent, serial-by-bit information

transfer over a link connection. Transmission

exchanges can be duplex or half-duplex over

switched or nonswitched links.

system administrator. The person who controls

and manages the WebSphere Voice Response

system by adding users, assigning account

numbers, and changing authorizations.

system greeting. In voice mail, a default greeting

that is heard by callers to the mailboxes of

subscribers who have not recorded a personal

greeting or who have selected the system

greeting. Contrast with personal greeting.

System Management Interface Tool (SMIT). A

set of utilities that can be used for various

purposes, such as loading WebSphere Voice

Response software, installing the exchange data

link, and configuring SNA.

Systems Network Architecture (SNA). An

architecture that describes the logical structure,

formats, protocols, and operational sequences for

transmitting information units through the

networks and also the operational sequences for

controlling the configuration and operation of

networks.

system parameter. A variable that controls some

of the behavior of WebSphere Voice Response or

applications that are running under WebSphere

Voice Response. System parameters are set

through System Configuration or Pack

glossary

Glossary 185

Configuration options on the Configuration

menu. Some system parameter values are

assigned to system variables when an application

is initialized. Contrast with input parameter, local

variable, system variable.

system prompt. The symbol that appears at the

command line of an operating system, indicating

that the operating system is ready for the user to

enter a command.

system variable. A permanent global variable

that is defined by WebSphere Voice Response for

use by state tables. Many system variables are

loaded with values when the state table is

initialized. Some values are taken from system

parameters. Contrast with input parameter, local

variable, system parameter.

T

T1. A digital trunking facility standard that is

used in the United States and elsewhere. It can

transmit and receive 24 digitized voice or data

channels. Signaling can be imbedded in the voice

channel transmission when robbed-bit signaling

is used. The transmission rate is 1544 kilobits per

second. Contrast with E1.

T1/D3. A framing format that is used in T1

transmission.

T1/D4. A framing format that is used in T1

transmission.

tag. A text string that is attached to any instance

of a word in a grammar. A tag can be used (1) to

distinguish two occurrences of the same word in

a grammar or (2) to identify more than one word

in a grammar as having the same meaning.

Tag Image File Format-Fax (TIFF-F). A graphic

file format that is used to store and exchange

scanned fax images.

TCAP. See transaction capabilities application part.

TCP/IP. See Transmission Control Protocol/Internet

Protocol.

TDD. See Telecommunications Device for the Deaf.

TDM. See time-division multiplex bus.

technology. A program, external to WebSphere

Voice Response, that provides processing for

functions such as text-to-speech or speech

recognition.

Telecommunications Device for the Deaf

(TDD). A telephony device that has a QWERTY

keyboard and a small display and, optionally, a

printer.

telephone input field. A field type that contains

information that is entered by a caller who is

using pushbutton signals. See also field.

terminal. (1) A point in a system or

communication network at which data can enter

or leave. (2) In data communication, a device,

usually equipped with a keyboard and display

device, that can send and receive information.

termination character. A character that defines

the end of a telephone data entry.

text-to-speech (TTS). The process by which

ASCII text data is converted into synthesized

speech. See also speech synthesis.

TIC. See trunk interface card.

time-division multiplex bus (TDM). A method

of transmitting many channels of data over a

smaller number of physical connections by

multiplexing the data into timeslots, and

demultiplexing at the receiving end. In this

document, one such channel can be considered to

be a half-duplex unidirectional stream of 64 Kb

per second.

TIFF-F. See Tag Image File Format-Fax

timeslot. The smallest switchable data unit on a

data bus. It consists of eight consecutive bits of

data. One timeslot is similar to a data path with

a bandwidth of 64 Kb per second.

token. A particular message or bit pattern that

indicates permission or temporary control to

transmit.

glossary


token-ring network. A local area network that

connects devices in a ring topology and allows

unidirectional data transmission between devices

by a token-passing procedure. A device must

receive a token before it can transmit data.

tone. An audible signal that is sent across a

telephone network. Single (one-frequency) tones,

tritones (three sequential tones at different

frequencies), dual tones (two simultaneous tones

at different frequencies), and dual sequential

tones exist. Each has a different meaning.

transaction. A specific, related set of tasks in an

application that retrieve information from a file

or database. For example, a request for the

account balance or the available credit limit.

transaction capabilities application part

(TCAP). Part of the SS7 protocol that provides

transactions in the signaling network. A typical

use of TCAP is to verify a card number, for the

credit card calling service.

transaction messaging. The ability to associate

an item of data, such as a transaction identifier,

with a voice message. The voice message can

later be retrieved by referencing the data value.

transfer. See call transfer.

Transmission Control Protocol/Internet Protocol

(TCP/IP). A communication subsystem that is

used to create local area and wide area networks.

trombone. A connected voice path that enters

an IVR from a switch on one circuit, then returns

to the same switch on a parallel circuit. Two IVR

ports and two circuits are consumed, but in some

circumstances this might be the only way to

make a connection between two callers if the

attached switch does not support a Call Transfer

function. Also known as double-trunking.

trunk. A telephone connection between two

central offices or switching devices. In

WebSphere Voice Response, a trunk refers to 24

or 30 channels that are carried on the same T1 or

E1 digital interface.

trunk interface card (TIC). The component of

the pack that manages the trunk connection to

the switch.

Tsm Router. In WebSphere Voice Server, a

process that controls which engine processes are

in use at any time. Requests for an engine by a

WebSphere Voice Server Client are accepted or

rejected depending on whether an engine that

meets the Tsm Client’s requirements is available.

tsmp. In WebSphere Voice Server, a process that

is running on the Recognition engine server

machine that passes messages between an engine

and a Tsm Client. One tsmp exists for every

engine.

TTS. See text-to-speech.

tune. A piece of music or other audio data that

is intended to be played as background music.

U

underrun. To run out of audio data to play,

causing voice or music to be audibly broken up

or cut off.

unified messaging. A messaging system in

which a single copy of a message is stored and

accessed by multiple applications (for example,

voice mail and e-mail). Contrast with integrated

messaging.

Unified Messaging. An IBM product that uses

WebSphere Voice Response’s voice processing

capabilities to provide a wide range of voice

mail, fax, and e-mail functions. Previously

known as Message Center.

user. Someone who uses WebSphere Voice

Response as a system administrator, application

developer, or similar. Contrast with caller.

utterance. A spoken word, phrase, or sentence

that can be preceded and followed by silence.

V

variable. A system or user-defined element that

contains data values that are used by WebSphere

glossary

Glossary 187

Voice Response voice applications. See input

parameter, local variable, system parameter, system

variable.

VMS. See Voice Message Service.

vocabulary. A list of words with which

WebSphere Voice Response matches input that is

spoken by a caller. See also language model.

voice application. A WebSphere Voice Response

application that answers or makes calls, plays

recorded voice segments to callers, and responds

to the caller’s input.

voice directory. A list of voice segments that is

identified by a group ID. Voice directories can be

referenced by prompts and state tables. Contrast

with voice table.

voice mail. The capability to record, play back,

distribute, and route voice messages.

voice mailbox. The notional hard disk space

where the incoming messages for a voice mail

subscriber are stored.

voice message. In voice mail, a recording that is

made by a caller for later retrieval by a subscriber.

Voice Message Service (VMS). An Ericsson

service that transmits information between

WebSphere Voice Response and particular

switches.

voice messaging. The capability to record, play

back, distribute, route, and manage voice

recordings of telephone calls through the use of a

processor, without the intervention of agents

other than the callers and those who receive

messages.

voice model. A file that contains parameters

that describe the sounds of the language that are

to be recognized on behalf of an application. In

WebSphere Voice Server, this is a bnf file. See also

grammar.

Voice over Internet Protocol (VoIP). The

sending of telephony voice over Internet Protocol

(IP) data connections instead of over existing

dedicated voice networks, switching and

transmission equipment. See also gatekeeper and

gateway.

voice port library. A library that manages a

socket connection from the client to the voice

technology. The library uses entry points that are

provided by DVT.

Voice Protocol for Internet Messaging (VPIM).

The standard for digital exchange of voice

messages between different voice mail systems,

as defined in Internet Request For Comments

(RFC) 1911.

voice response unit (VRU). A telephony device

that uses prerecorded voice responses to provide

information in response to DTMF or voice input

from a telephone caller.

voice segment. The spoken words or sounds

that make recorded voice prompts. Each segment

in an application is identified by a group ID and

a segment ID and usually includes text.

voice server node. In a single system image

(SSI), a server node that contains the voice data.

This is usually the same node as the database

server node.

voice table. A grouping of voice segments that is

used for organizational purposes. Voice tables

can be referenced by prompts, but not by state

tables. Contrast with voice directory.

voice technology. See technology.

VoiceXML. VoiceXtensible Markup Language.

An XML-based markup language for creating

distributed voice applications. Refer to the

VoiceXML forum web site at www.voicexml.org

VoIP. See Voice over Internet Protocol.

VPACK. A component consisting of a base card,

which connects to the digital trunk adapter in

the pSeries computer, and a trunk interface card

(TIC), which manages the trunk connection to

the switch. The single digital trunk processor

contains one VPACK, and the multiple digital

trunk processor contains slots for up to five

VPACKs. Contrast with SPACK and XPACK.

glossary


VPIM. See Voice Protocol for Internet Messaging.

VRU. See voice response unit.

W

World Wide Web Consortium (W3C). An

organization that develops interoperable

technologies (specifications, guidelines, software,

and tools) to lead the Web to its full potential.

W3C is a forum for information, commerce,

communication, and collective understanding.

Refer to the web site at http://www.w3.org

WebSphere Voice Response. A voice processing

system, that combines telephone and data

communications networks to use, directly from a

telephone, information that is stored in

databases.

wink start. A procedure that is used with some

channel-associated signaling protocols to indicate

when a switch or PABX is ready to accept

address signaling. After seizure, the switch sends

a short off-hook signal (wink) when it is ready to

accept address information. Contrast with delay

start and immediate start.

word spotting. In speech recognition, the ability

to recognize a single word in a stream of words.

wrap. In ADSI, the concatenation of two

columns of display data to form a single column.

X

XPACK. A digital trunk processor that is

implemented using DSP technology on the

digital trunk adapter without the need for

external hardware. One digital trunk adapter

(DTTA or DTXA) provides up to four XPACKs

on a PCI card.

Y

yellow alarm. See remote alarm indication.

Z

zero code suppression (ZCS). A coding method

that is used with alternate mark inversion to

prevent sending eight successive zeros. If eight

successive zeros occur, the second-least

significant bit (bit 7, with the bits labeled 1

through 8 from the most significant to the least

significant) is changed from a 0 to a 1. AMI with

ZCS does not support clear channel operation.

glossary

Glossary 189

glossary


List of WebSphere Voice Response and associated

documentation

Here is a list of the documentation for WebSphere Voice Response for AIX and

associated products. PDF and HTML versions of the documentation are

available from the IBM Publications Center at http://www.ibm.com/shop/publications/order. Hardcopy books, where available, can be ordered through

your IBM representative or at this Web site.

WebSphere Voice Response for AIX documentation can also be found by going

to the IBM Pervasive software Web site at http://www.ibm.com/software/pervasive, selecting the WebSphere Voice products link, and then selecting

the library link from the WebSphere Voice Response page.

PDF and HTML versions of the WebSphere Voice Response for AIX

publications are available on the CD-ROM supplied with the product. In

addition, WebSphere Voice Response for AIX, WebSphere Voice Response for

Windows, Unified Messaging, and other WebSphere Voice publications are

available together in PDF and HTML formats on a separately-orderable

CD-ROM (order number SK2T-1787).

Note: To read PDF versions of books you need to have the Adobe Acrobat

Reader (it can also be installed as a plug-in to a Web browser). It is

available from Adobe Systems at http://www.adobe.com .

WebSphere Voice Response software

v WebSphere Voice Response for AIX: General Information and Planning,

GC34-6379

v WebSphere Voice Response for AIX: Installation, GC34-6380

v WebSphere Voice Response for AIX: User Interface Guide, SC34-6386

v WebSphere Voice Response for AIX: Configuring the System, SC34-6381

v WebSphere Voice Response for AIX: Managing and Monitoring the System,

SC34–6384

v WebSphere Voice Response for AIX: Designing and Managing State Table

Applications, SC34–6388

v WebSphere Voice Response for AIX: Application Development using State Tables,

SC34–6387

v WebSphere Voice Response for AIX: Developing Java applications, GC34-6377


v WebSphere Voice Response for AIX: Deploying and Managing VoiceXML and Java

Applications, GC34–6378

v WebSphere Voice Response for AIX: Custom Servers, SC34–6389

v WebSphere Voice Response for AIX: 3270 Servers, SC34–6390

v WebSphere Voice Response for AIX: Problem Determination, GC34–6382

v WebSphere Voice Response for AIX: Fax using Brooktrout, GC34–6385

v WebSphere Voice Response for AIX: Cisco ICM Interface User’s Guide, SC34–6391

v WebSphere Voice Response for AIX: Programming for the ADSI Feature,

SC34–6393

v WebSphere Voice Response for AIX: Programming for the Signaling Interface,

SC34–6392

v WebSphere Voice Response for AIX: Voice over IP using Session Initiation

Protocol, GC34–6383

v WebSphere Voice Response for AIX: Using the CCXML Browser, GC34–6368

IBM hardware for use with WebSphere Voice Response

v IBM Quad Digital Trunk Telephony PCI Adapter (DTTA): Installation and User’s

Guide, part number 00P3119 (DTTA card)

Withdrawn from marketing but still supported

v IBM ARTIC960RxD Quad Digital Trunk PCI Adapter: Installation and User’s

Guide, part number 41L5825 (DTXA card)

WebSphere Voice Response related products

WebSphere Voice Server for Multiplatforms

For Version 4.2 of WebSphere Voice Server, the following documentation is

provided in softcopy with the product, or can be downloaded from the IBM

Publications Center:

v IBM WebSphere Voice Server: General Information

v WebSphere Voice Server for Multiplatforms: Administrator’s Guide

v WebSphere Voice Server for Multiplatforms: Application Development using State

Tables

v WebSphere Voice Server for Multiplatforms: VoiceXML Programmer’s Guide

The WebSphere Voice Server for Multiplatforms: VoiceXML Programmer’s Guide is

also provided as a PDF with the Voice Toolkit for WebSphere Studio Release

4.2.


The documentation for Version 5.1 of WebSphere Voice Server is provided in

the form of an HTML-based information center, and can be found at:

http://publib.boulder.ibm.com/pvc/wvs/51/en/infocenter/index.html

Unified Messaging for WebSphere Voice Response

v Unified Messaging: General Information and Planning, GC34-6398

v Unified Messaging: Subscriber’s Guide (Types 0, 1, 2, 3, 4 and 9), SC34-6403

v Unified Messaging: Subscriber’s Guide (Types 5, 6, 7 and 8), SC34-6400

v Unified Messaging: Administrator’s Guide, SC34-6399

v Unified Messaging: Voice Interface, GC34-6401

v Unified Messaging: Web Services Voicemail API, SC34-6975

Unified Messaging publications can be found by going to the IBM Pervasive

software Web site at http://www.ibm.com/software/pervasive, selecting the

products link, and then selecting the library link from the Unified Messaging

page.

AIX and the IBM pSeries computer

v AIX: Installation Guide, SC23-4112

v AIX: Quick Beginnings, SC23-4114

v AIX: System User’s Guide; Operating System and Devices, SC23-4121

v AIX: System Management Guide; Operating System and Devices, SC23-4126

v AIX: System User’s Guide; Communications and Networks, SC23-4122

v AIX: System Management Guide; Communications and Networks, SC23-4127

v AIX: Topic Index and Glossary, SC23-2513

v RS/6000 and pSeries: Site and Hardware and Planning Information, SA38-0508

HACMP

v HACMP for AIX: Concepts and Facilities, SC23-4864

v HACMP for AIX: Planning Guide, SC23-4277

v HACMP for AIX: Planning and Installation Guide, SC23-4861

v HACMP for AIX: HACMP 5.3 Administration Guide, SC23-4862

v HACMP for AIX: HACMP 5.3 Smart Assist for DB2, SC23-5179

v HACMP for AIX: Enhanced Scalability Installation and Administration Guide,

SC23-4279

SS7

v SS7 Support for WebSphere Voice Response: SS7 User’s Guide, GC34-6613

IBM SS7 Support for WebSphere Voice Response observes the applicable parts

of the following specifications for ISUP:

v CCITT Blue book (1988) Q.701 - Q.707

List of WebSphere Voice Response and associated documentation 193

v ITU-T (formerly CCITT) Recommendations Q.700 - Q.716, Volume VI Fascicle

VI.7


v ITU-T White book (1993) Q.711 - Q.714


v ITU-T (formerly CCITT) Recommendations Q.721 - Q.725, Volume VI Fascicle

VI.8

v ITU-T White book (1992) Q.730 group


v ITU-T White book (1992) Q.761 - Q.764


v ITU-T (formerly CCITT) Recommendations Q.771 - Q.775, Q.791, Volume VI

Fascicle VI.9

ADC

v ADC NewNet AccessMANAGER™: Installation and Maintenance

Manual

v ADC NewNet AccessMANAGER™: User Manual

Integrated Services Digital Network

WebSphere Voice Response ISDN support observes the applicable parts of the

following standards for User Side protocol:

Custom ISDN Standards:

v Northern Telecom DMS/250 Primary Rate Interface NIS A211-4 Release

8, July 1995. (IEC05 level)

v Northern Telecom DMS/100 Primary Rate Interface NIS A211-1 Release

7.05, May 1998. (NA007 & RLT)

v AT&T 5ESS Switch. ISDN Primary Rate Interface Specification. 5E7 and

5E8 Software Release AT&T 235-900-332. Issue 2.00 December 1991

v AT&T 5ESS Switch. ISDN Primary Rate Interface Specification. 5E9

Software Release AT&T 235-900-342. Issue 1.00 November 1993

(National ISDN only)

v Lucent 5ESS-2000 Switch ISDN Primary Rate Interface, Interface

Specification, 5E9(2) and Later Software Releases, 235-900-342. Issue

5.00 January 1997 (National ISDN only)

v AT&T ISDN Primary Rate Specification TR41449 July 1989

v AT&T ISDN Primary Rate Specification TR41459 August 1996

Euro-ISDN

The following documents refer to the specifications required for

observing ISDN:

v TBR4-ISDN; Attachment Requirements For Terminal Equipment To

Connect To An ISDN Using ISDN Primary Rate Access, Edition 1, Nov.

95, English


v CTR 4 - European Communities Commission Decision 94/796/EC

published in the Official Journal of the European Communities L

329, 20 December 94 (ISDN PRA)

National ISDN

National ISDN is described in the following publications:

v National ISDN, SR-NWT-002006, Issue 1, August 1991, published by

Bellcore

v National ISDN-1, SR-NWT-001937, Issue 1, February 1991, published

by Bellcore

v National ISDN-2, SR-NWT-002120, Issue 1, May 1992, published by

Bellcore

INS Net Service 1500

INS Net Service is described in the following publications:

v Interface for the INS Net Service Volume 1 (Outline), 7th Edition,

published by Nippon Telegraph and Telephone Corporation

v Interface for the INS Net Service Volume 2 (Layer 1 & 2 Specifications),

4th Edition, published by Nippon Telegraph and Telephone

Corporation

v Interface for the INS Net Service Volume 3 (Layer 3 Circuit Switching),

5th Edition, published by Nippon Telegraph and Telephone

Corporation

Bellcore Specifications for ADSI Telephones

The following Bellcore specification documents contain technical details of the

requirements for ADSI telephones, and the interface to voice response systems

such as WebSphere Voice Response:

v SR-INS-002461: CustomerPremises Equipment Compatibility Considerations for

the Analog Display Services Interface

v TR-NWT-001273: Generic Requirements for an SPCS to Customer Premises

Equipment Data Interface for Analog Display Services

List of WebSphere Voice Response and associated documentation 195

Index

Aaccessibility xiii

APIJava 77

application developmentCisco ICM 3

Java 4

state tables 4

Application development using Java 75

Application development using state tables 23

application interfacecall routing interface (CRI) 3

compatibility with WebSphere Voice Response 2

event data feed interface (EDFI) 3

poll data feed 3

service control interface (SCI) 3

time synchronization interface 3

application launch filedefining name 12

definition 133

BBellcore specifications for ADSI telephones 195

Ccall routing interface (CRI), application interface 3

call routing interface, see CRIstate tables 23

Ciscolicenses, configuring 6

Cisco ICMapplication development 3

Cisco ICM custom servercoexistence 7

customizing 12

functions 25, 26

import 5

Installation prerequisites 5

Installation procedure 5

installing 5

messages 160

overview 1

parameters 12

problem 21

running in debug mode 12

running in simulated mode 14

starting 11

status codes 41

status data 153

Cisco ICM custom server (continued)trace data 153

Cisco ICM custom server functionCRI 25, 26

Cisco ICM simulator 12, 135

Cisco Intelligent Contact Management (ICM) 1

coexistenceCisco ICM custom server 7

configurationJava 8

CRICustom Server Functions

Call_Cleared_Event 26

Delivered_Event 27

Diverted_Event 28

Get_CallID 29

Get_Route 30

Get_ServiceID 32

New_Transaction_Event 33

Originated_Event 34

Route_End_Event 35

Route_Request_Event 36

Set_Call_Variables_Event 38

Set_VRU_Status_Variables 40

state tables 26

status codes 41

CTICisco APIJava 77

custom server parameterexamples 15

customizingCisco ICM custom server 12

Ddeconfigure

Java 9

default.cffJava 9

defining, name of application launch file 12

dtjenvJava 8

EEDFI, event data feed interface 3

error handlingHACMP 7

SSI 7

Event Data Feedstatus codes 41


event data feed interface (EDFI), application

interface 3

Expanded Call Context VariableService Control Interface 43, 76

Expanded Call Context Variables 75

HHACMP

error handling 7

Iinstallation

import Cisco ICM custom server 5

install package 5

prerequisites 5

procedure 5

start WebSphere Voice Response 5

verification test 6

Installation prerequisitesCisco ICM custom server 5

Installation procedureCisco ICM custom server 5

installingCisco ICM custom server 5

JJava

application development 4

configuration 8

CTICisco API 77

CTICiscoCallVars 79

CTICiscoReturn 78

Custom Server Functions 82

deconfigure 9

default.cff 9

dtjenv 8

Service Control Interface 75, 76

Llicenses, configuring

Cisco 6

Mmessages

Cisco ICM custom server 160

migration 7

Ooverview, Cisco ICM custom server 1

Pparameters

-A 12

-B 12

-c 12

-d 12

parameters (continued)-f 13

-h 13

-I 13

-J 14

-K 14

-l 14

-L 14

-p 14

-s 14

-t 15

-T 14

-U 15

-V 15

-W 15

-X 15

-Y 15

-z 15

-Z 15

Cisco ICM custom server 12

Peripheral Gateway (PG) 111

poll data feed, application interface 3

problems with Cisco ICM custom server 21

SService Control Interface

Examples 111

Expanded Call Context Variables 43, 76

Java 75, 76

overview 42, 75

state table 44

state tables 42

usage 42, 75

service control interface (SCI), application interface 3

Service Control Interface, JavaCustom Server Functions

cancel 82

connect 83

connectToResource 86

dialogueFailureConfSend 89

dialogueFailureEventRecv 90

dialogueFailureEventSend 91

eventReport 92

newCall 93

registerVariables 97

release 100

requestInstruction 101

resourceConnected 103

runScriptRequest 104

runScriptResult 107

waitForEvent 110

Service Control Interface, state tablesCustom Server Functions

Cancel 45

Connect 46


Service Control Interface, state tables (continued)Custom Server Functions (continued)

Connect_To_Resource 48

Create_DialogueID 50

Dialogue_Failure_Conf_Send 51

Dialogue_Failure_Event_Recv 53

Dialogue_Failure_Event_Send 52

Event_Report 54

New_Call 55

New_Dialogue 60

Register_Variables 61

Release 63

Release_DialogueID 64

Request_Instruction 65

Resource_Connected 67

Run_Script_Request 68

Run_Script_Result 70

service definition file 19

example 20

Service ID 19

Service ID in service definition file 19

Sevice Control InterfaceCustom Server Functions 45, 82

simulator 135

SMITSee System Management Interface Tool (SMIT) 5

smitty command 5

SR-INS-002461 Bellcore specification 195

SSIerror handling 7

startingCisco ICM custom server 11

state tableCustom Server Functions 45

Service Control Interface 44

state tablesapplication development 4

CRI 23

Service Control Interface 42

statuscodes 41

data, Cisco ICM custom server 153

status codesCRI 41

Event Data Feed 41

System Management Interface Tool (SMIT) 5

Tterminology

trunk xii

trunk group xii

terminology used in this book xi

time synchronization interface, application interface 3

TR-NWT-001273 Bellcore specification 195

trace data, Cisco ICM custom server 153

Trademarks 163

Vverification test

run 6

Index 199

��

Program Number: 5724-I07

SC34-6391-02

Cisco ICM Interface User’s Guide - Blueworx Voice Response for AIX with DirectTalk Technology...

Documents

Transcript of Cisco ICM Interface User’s Guide - Blueworx Voice Response for AIX with DirectTalk Technology...