Friday, 27 February 2015

Introduction To ICM Script

Introduction To ICM Scripting.


What is a Call Type?
A Call Type is the first-level category of a contact and is determined by data associated with the contact (DN). You associate a script with a Call Type. When a contact of a certain Call Type is received, the associated script runs on that contact.
What is a Default Call Type?
A default Call Type is the Call Type used when a contact does not map to a defined Call Type.
How Call Types and Scripts are related?
Ø  Scripts are scheduled by Call Type. In other words, when ICM software receives a request to route a contact, it determines the Call Type of that contact, then runs the associated script.
Ø  Call Types provide the first level of categorization of contacts, enabling you to write scripts to route contacts differently depending on their call type.
Ø  While other types of categorization take place within a script, Call Types enable you to provide contacts with different treatment by running different scripts to begin with.
Ø  Call Types enable categorization before a script begins to execute.
Call Type Qualifiers.
The Call Type is determined by the following data, which are referred to as Call Type qualifiers:
Ø  Dialed Number
Ø  Calling Line ID (CLID)
Ø  Caller-Entered Digits
You can also use the call type qualifiers for categorization within a script.
The Dialed Number is referred to as the Script Selector for media other than voice. Typically, a Dialed Number is associated with one or more Call Types. The Calling Line ID and Caller Entered Digits are used to further categorize the call and determine the Call Type.
Categorizing by Time and Date.
You schedule a script by associating it with a Call Type. When a contact of a certain Call Type is received, the associated script runs for that contact.
However, after the script executes, you can further categorize the contact based on the time and day of week; in effect, this refines the schedule.
The time and day of week are determined by the settings on the computer running the ICM Central Controller.
Go To Script node.
You use the Go To Script node (in the General tab of the Palette) to direct contact processing to another script without changing the call type. When ICM software encounters a Go To Script node, it stops executing the current script and starts the script indicated in the node.
Requalify Call node.
You can change the Call Type of a contact from within a script and execute a new script associated with the call type by using the Requalify Call node (in the Routing tab of the Palette).
If node.
You use the If node (in the General tab in the Palette) to direct script execution to one of two branches based on the result of an evaluation. You can use formulas to define the If node.
DB Lookup node.
You use the DB Lookup node (in the General tab of the Palette) to query a specific row of data from an external database. You can then reference columns from that row.
Application Gateway node.
You can categorize a contact based on data returned from an application external to ICM software by using the Application Gateway node (in the General tab of the Palette).
Send to VRU node.
You can send a call to a VRU for further processing by using the Send to VRU node (in the Queue tab of the Palette).
Run External Script node.
You can instruct a Network VRU to run a specific script by using the Run External Script node (in the Queue tab of the Palette).

Queue node.
You can place a call in queue at a VRU for one or more skill groups, enterprise skill group, or one or more scheduled targets using the Queue node (in the Queue tab of the Palette).
Queue Priority node.
You can override the priority of a call in queue set by the Queue node by using the Queue Priority node (in the Queue tab of the Palette).
Menu node.
You can have a script play a prompt and instruct the caller to select from a list of options using the Menu node (in the Queue tab of the Palette).
Play node.
You can instruct the VRU to play a series of media files and/or data to the caller by using the Play node (in the Queue tab of the Palette).
VRU Settings node.
You can override a default VRU setting on a call-by-call basis by using the VRU Settings node (in the Queue tab of the Palette).
Wait node.
You can halt script execution for a specified number of seconds by using the Wait node (in the Queue tab of the Palette).
What is a Routing Target?
A routing target is an entity to which ICM software can route a contact. The routing target receives the contact and processes it accordingly.
What is a Route?
A value returned by a routing script that maps to a target at a peripheral, such as a service, skill group, agent, or translation route to a label.

What is a Translation Route?
A translation route is a target at a peripheral that does not map to a specific service, skill group, or agent. When a contact arrives with the trunk group and DNIS that correspond to a translation route, the Peripheral Gateway (PG) is responsible for determining the ultimate target. When ICM software routes a call to a translation route, it sends a message to the PG. This message contains the ultimate target and further instructions for the PG. For example, the PG might be instructed to coordinate with a host computer so that the callers account number is displayed on the teleset of the agent who picks up the call.
What is a Target Set?
A target set is a list of possible targets. During script processing, the actual target is chosen from the set by the preceding node on the script.
Skill Target.
A skill target is an entity at a peripheral or in the enterprise to which ICM software can route a contact. There are two types of skill targets:
Peripheral-level skill targets (Agents, Skill groups, Services).
Enterprise-level skill targets (Enterprise skill groups, Enterprise services).
What is a VRU?
A VRU, or Voice Response Unit, is a telecommunications device, also called an Interactive Voice Response Unit (IVR) that plays recorded announcements and responds to caller-entered touch-tone digits. A VRU can also be equipped with Automatic Speech Recognition (ASR) or Text-to-Speech (TTS) capabilities.
What is a Network VRU?
A Network VRU supports ICM software's service control interface. An ICM routing script can divert a call to a Network VRU and instruct the VRU to perform specific processing before ICM software determines the final destination for the call.




ICM Script Call Flow

1-      A logical / translated DN (45213) comes to ICM router via CVP Server.
2-      Router gets information about that DN from Logger.
3-      Logger matches the DN into its Database (CCDB).
4-      If the DN exists router will perform the following functions at script level:
·         Sets MRD (media routing domain).
·         Sets Call Type against that DN.
·         After scheduling call is landed over Script.
5-      Call comes in and hits START Node of Script.
6-      Some variables are set (HTTP Media Server IP Address, Directory Name for the stored media files, en-us locale, input type sets it digits ).
7-      After setting basic variables very next Node is SendToVRU which will do as follow:
·         The SendToVRU is what triggers ICM to transfer the call to the VXML GW (which is the VRU)
8-      ICM router returns VRU Label (number + correlation id) back to CVP Call Server.
9-      Now CVP Call Server will send this VRU Label to VXML GW.
10-   CVP stays in signaling path so that it can retain call control.
11-   ICM executes the script instruction called “RunExternalScript” (microapps). This basically tells CVP that IVR related instructions are coming.
12-   ICM then sends instructions like for example“Get4Digits”.
13-   CVP sends this instruction to VXML-GW to play the prompt to the caller.
14-   When caller enters the digit, ICM stores it in its variable [for example Call.CallerEnteredDigits variable].
15-   ICM Script then instructs CVP to play the prompts back to the user on the PSTN side.


Note:  *ICM uses “Correlation id” to identify or trace the call.


Basic Call Flow in IPCC

Basic Call Flow In IPCC Network

1.VG sends the call to the GK for ARQ.
2.GK response with IP address of CVP-VB.
3.VG sends the call to the VB using hH225 .
4.CVP transfer the call to the CVP-AS using HTTP.
5.AS Sends the new call event to the ICM using VRU and define the call as type 5
6.ICM returns label-7 and correlation ID to the AS.
7.The CVP application server sends the label with a correlation ID to the CVP-VB
8.CVP-VB ask GK for the IP address of the end-point of that label.
9.VB transfer the call to the specific VG .
10.VG transfer the call to the CSS.
11.CSS route the call to the appropriate AS.AS sends the type-7 information to the ICM.
12.ICM runs the script and tell the AS which media file should play.
13.The AS instructs the VG via http to play media file.
14.The PSTN GW sends a message to the CSS regarding media server.
15.The CSS redirect the request to Media server and caller hear the IVR.


IF CALLER PRESS-1

16.VG detects the response or CED and sent it to the CVP-AS. CVP-AS forward it to the ICM and ICM runs the script and call the stored to fetch data from ICM
17.CRM provides the data to the customer.
18.ICM runs the script and tells the CVP-AS play the media file.
19.CVP-AS tells the VG to play  data and media file.
20.GW sends the call to CSS regarding Media Server.

21.CSS redirect the request to media server and caller hear the data.

UCCE Components


The Unified CCE solution consists primarily of four Cisco software products:

• Unified Communications infrastructure: Cisco Unified CM
• Queuing and self-service: Cisco Unified IP Interactive Voice Response (Unified IP IVR) or Cisco Unified Customer Voice Portal (Unified CVP)
• Contact center routing and agent management: Unified CCE. The major components are CallRouter, Logger, Peripheral Gateway, and the Administration & Data Server/Administration Client.
• Agent desktop software: Cisco Agent Desktop, Cisco Toolkit Agent Desktop (CTI OS), or integrations with third-party customer relationship management (CRM) software through Cisco Unified CRM Connector.
The solution is built on the Cisco IP Telephony infrastructure, which includes:
• Cisco Unified IP Phones
• Cisco voice gateways
• Cisco LAN/WAN infrastructure


Cisco Unified Customer Voice Portal(CVP)
Unified Customer Voice Portal (Unified CVP) is a software application that runs on industry-standard servers such as Cisco Media Convergence Servers (MCS). It provides prompting, collecting, queuing, and call control services using standard web-based technologies. The Unified CVP architecture is distributed, fault tolerant, and highly scalable. With the Unified CVP system, voice is terminated on Cisco IOS gateways that interact with the Unified CVP application server using VoiceXML (speech) and H.323 or SIP (call control). 
Unified Intelligent Contact Manager
Unified CCE may be deployed with Unified ICM to form a complete enterprise call management system. Unified ICM interfaces with ACDs from various vendors (including Cisco Unified CCE), VRUs (including Cisco Unified IP-IVR and Unified CVP), and telephony network systems to efficiently and effectively treat customer contacts such as calls and emails regardless of where the resources are located in the enterprise.
Unified CCE may be deployed in a “hybrid” model with Unified ICM where the CallRouter, Logger, Administrative & Data Servers, and other components are shared between Unified ICM and Unified CCE. (See Unified CCE Software Components for a description of these components.)
Alternatively, Unified CCE may be deployed in a “parent/child” model where Unified ICM is the parent and Unified CCE is the child. This closely resembles the deployment model of Unified ICM with ACDs from other vendors. It is used for a highly scalable deployment because it provides CallRouters, data servers, and so forth for each product, although there are more components to manage and maintain. It is also used for a distributed model where isolation is needed between Unified ICM and Unified CCE, such as in an outsourced operation.


ICM Components and Processes

The principal ICM components are:

CallRouter
The component of the Central Controller that makes routing decisions and both
gathers and distributes data from remote sites; generally referred to in this document simply  as the Router. (Central Controller is the term used when discussing a CallRouter/Logger configuration.)
Logger
The database server that stores contact center configuration data and temporarily stores historical reporting data for distribution to the data servers.
CTI Object Server (CTI OS)
CTI interface for Agent Desktops. The (optional) component that allows an external CTI application to communicate with a Peripheral Gateway.
Peripheral Gateway (PG)
Interfaces to various ‘peripheral’ devices, specifically to Unified CM, VRU (Unified IP IVR or Unified CVP), or Multichannel products (EIM and WIM for email and chat). The PG includes one or more Peripheral Interface Managers (PIMs) for the specific device interfaces. or The interface between the ICM platform and third-party hardware in each contact center, such as an ACD. A Peripheral Gateway (PG) is typically located at the contact center.
Agent PG
PG that has a Unified CM PIM.
Unified CM Peripheral Interface Manager (PIM)
Part of a PG that interfaces to a Unified CM cluster by using the JTAPI protocol.
VRU PIM
Part of a PG that interfaces to the Unified IP IVR or Unified CVP through the Service Control Interface (SCI) protocol.
MR PIM
Part of a PG that interfaces to call center Multimedia products, specifically EIM and WIM for email and chat.
CTI Server
Part of the PG that interfaces to CTI OS and provides an open CTI interface, which is useful for some server-to-server communications.
Network Interface Controller (NIC)
Interfaces to the public switched telephone network (PSTN), which enables Unified CCE to control how the PSTN routes a call.
Administration & Data Server
Configuration interface and real-time and historical data storage (for example, for reporting). There are several different deployment models described later in this chapter.
Administration Client
Configuration interface. This component has a subset of the functionality of the Administration & Data Server. It is a “lighter weight” deployment because it does not require a local database and it is deployed to allow more places from which to configure the solution.
Cisco Unified Intelligence Center (Unified Intelligence Center)
Provides web browser-based real-time and historical reporting. Unified Intelligence Center also works with other Cisco Unified Communications products.

Admin Workstation.          The human interface to ICM software. An Admin Workstation (AW) can be                                                              located at any central or remote site. It allows users to monitor call handling within
                                                     the system and make changes to configuration data or routing scripts.
 WebView.                        The (optional) component that provides web-based contact center reporting.

The combination of CallRouter and Logger is called the Central Controller. When the CallRouter and Logger modules run on the same server, the server is referred to as a Rogger. When the CallRouter, Logger, and Peripheral Gateway modules run on the same server, the server is referred to as a Progger. In lab environments, the system Administration & Data Server can also be loaded onto the Progger to create a server known as a Sprawlerconfiguration; however, this configuration is approved only for lab use and is not supported in customer production environments.



Duplexed Components
To allow ICM software to continue operating when a single node fails, all major components
of the system can be duplicated on separate nodes, or duplexed. This allows the system to be
fault-tolerant; that is, to continue operating when a component fails.
For example, two computers can run the CallRouter software. If one of those computers fails
for any reason, the other computer continues to run and ICM software continues to operate
without interruption. The CallRouter and Logger processes are typically duplexed and Peripheral
Gateways may be duplexed.
The failure of a single Admin Workstation does not prevent the rest of the ICM system from
operating. Therefore, Admin Workstations are not duplexed.
In a fully duplexed configuration, one CallRouter and one Logger compose one side of the
Central Controller; the other CallRouter and Logger compose the other side. The sides are called
Side A and Side B.
The components of a single side must be located at a single site; that is, the CallRouter and
Logger for Side A must be collocated. For maximum fault-tolerance, the Side B components
may be at a different site than Side A.
If a Peripheral Gateway (PG) is duplexed, both PGs (A and B) are typically located at a single
site; usually, the same site that contains the contact center equipment. If a disaster causes the
entire site to fail, the contact center equipment itself is unavailable. Therefore, having a duplexed
PG at another site would provide little benefit.


ICM Components Processes
ICM ROGER
CSFS
ConfigLogger
HistLogger
Replication
Recovery
CCAgent
AppGW
DbAgent
DbWorker
MDS
Router
TestSync
Rtsvr

AW\HDS
ConfigLogger
RTclient
Replication
RTdist
Schman
UpdateAW

Peripheral Gateway
MDS
OPC
PGAgent

Testsync

ICM Process Description


Component
Process
Description
Router
* router.exe
[Critical] This is the primary Router process.

* rtsvr.exe
[Critical] Provides real-time data feed from the Router to the Administration & Data Server.

* mdsproc.exe
[Critical] Message Delivery Service

* ccagent.exe
[Critical] Router component that manages communication links between the Router and peripheral gateways.

* dbagent.exe
[Critical] Manages connections and transactions (configuration updates) from configuration tools.

* testsync.exe
[Non critical] Provides interface for component test tools.

* appgw.exe
[Optional/Critical] The process that provides an interface for the Router to communicate with external applications.

* dbworker.exe
[Optional/Critical] The process that provides the interface for the Router to query external databases.

* [NIC].exe
[Optional/Critical] A separate process is active for each Network Interface Controller (NIC) enabled during SETUP. The NIC process manages the interface to a telephony network.
The presence of a NIC process in a Unified CCE deployment is very rare.
NIC process names: attnic.exe, cainnic.exe, netwrkcic.exe, crspnic.exe, cwcnic.exe, gktmpnic.exe, incrpnic.exe, mcinic.exe, gennic.exe, ntnic.exe, ntlnic.exe, sprnic.exe, ss7innic.exe, stentornic.exe, timnic.exe, unisourcenic.exe
Logger
* configlogger.exe
[Critical] The process that manipulates configuration data.

* histlogger.exe
[Critical] The process that inserts historical data into TMP historical tables in the Logger database.

* recovery.exe
[Critical] This process bulk copies historical data from the TMP historical tables to the actual historical tables. Recovers and synchronizes historical data with its partner logger during failover if loggers are running duplex. In addition, it is responsible for historical data purges in the Logger database based on configured retention parameters.

* replication.exe
[Critical] The process that replicates data from the Logger to the Historical Data Server on an Administration & Data Server.

* csfs.exe
[Critical] The alarm/event processor. CSFS distributes alarms/events send via EMS to supported alarm/event feeds, for example, SNMP, syslog. CSFS stands for Customer Support Forwarding Service, which in Unified ICM’s infancy, forwarded events to a central monitoring location.

* cw2kfeed.exe
[Optional] The syslog event feed. This process acquires events from the CSFS process, formats them appropriately in accordance with the syslog protocol and sends the events to the configured collector.
If a syslog collector is not configured, this process does not execute.

* campaignmanager.exe
[Optional/Critical] Outbound Option Campaign Manager. This process manages customer lists: provides customer records for every Dialer in the enterprise; determines when customers should be called again; maintains the "Do Not Call" list in memory. The Campaign Manager also sends real time and historical data to the Router and distributes configuration information to Dialer and Import processes.
This process is installed and executes on the "A" side Logger only.

* baimport.exe
[Optional/Critical] Outbound Option Import process. This process imports contact lists into the Outbound Option database; applies query rules to the contact table to build dialing lists; determines the GMT value for each phone based on the region prefix configuration.
This process is installed and executes on the "A" side Logger only.

sqlservr.exe
[Critical] Microsoft SQL server process

sqlmangr.exe
[Critical] Microsoft SQL server process

sqlagent.exe
[Critical] Microsoft SQL server process
PG
* opc.exe
[Critical] Open Peripheral Controller (OPC). This process acts as the brain for the peripheral gateway, including acting as a central collection and distribution point for all interaction with peripherals. OPC also ensures that all synchronization is accomplished with the other side. It also prepares and sends termination call detail (TCD) records as well as 5 minute and 30 minute reports.

* mdsproc.exe
[Critical] Message Delivery Service

* pgagent.exe
[Critical] MDS Peripheral Gateway component that manages the interface between the peripheral gateway and the central controller.

* testsync.exe
[Non critical] Provides interface for component test tools.

* eagtpim.exe
[Optional/Critical] The Cisco Unified CM peripheral interface manager process. This process manages the interface between OPC and the JTAPI Gateway. Multiple PIMs of the same type can be enabled for a PG. VRU PIMs and Unified CM PIMs may be coresident on a PG as well.
This is very common in Unified CCE deployments but may not be present on all PGs.
There may be multiple instances of this process running.

* acmipim.exe
[Optional/Critical] The process is expected on the Unified SCCE Gateway PG – this Peripheral Interface Manager is responsible for the communication interface between the parent instance and the child instance.

* vrupim.exe
[Optional/Critical] Peripheral Interface Manager process between OPC and a Voice Response Unit (VRU) or Interactive Voice Response (IVR).
There may be multiple instances of this process running.

* mrpim.exe
[Optional/Critical] The Media Routing Peripheral Interface Manager is the integration point for the Outbound Option Dialer, Cisco Email Manager (CEM), Cisco Collaboration Server (CCS) as well as the Email Interaction Manager (EIM) and Web Interaction Manager (WIM).
There may be multiple instances of this process running.

* msgis.exe
[Optional/Critical] Message Integration Service (MIS), which provides a mechanism to share call context data with a VRU. This process is only present on a PG with a VRU PIM.

* ctiosservernode.exe
[Critical] The CTI OS Server process that manages connections from CTI clients (agent desktops), retains (real-time) data about agents and acts as the conduit for events and control messaging between CTI Server and CTI clients.

* jtapigw.exe
[Critical] JTAPI Gateway that manages the interface to the Unified Communications Manager IP PBX via the JTAPI client to the CTI Manager on the Unified CM. On the other side, the JTAPI Gateway connects to the Unified CM PIM and translates JTAPI messages and events into a format expected by the PIM.

* ctisvr.exe
[Critical] CTI Gateway (CTI Server) process that processes (GED-188) messages between CTI OS and OPC.
Note: In legacy implementations, CTI Server manages connections to CTI desktops.

IPPASvr.exe
[Optional/Critical] Cisco Agent Desktop: Cisco Browser and IP Phone Agent Service

FCCServer.exe
[Optional] Cisco Agent Desktop: Cisco Chat Service

CTI Storage Server.exe
[Optional/Critical] Cisco Agent Desktop: Cisco Enterprise Service

LDAPmonSvr.exe
[Optional/Critical] Cisco Agent Desktop: Cisco LDAP Monitor Service

LRMServer.exe
[Optional/Critical] Cisco Agent Desktop: Cisco Licensing and Resource Manager Service

RPServer.exe
[Optional/Critical] Cisco Agent Desktop: Cisco Recording & Playback Service

FCRasSvr.exe
[Optional/Critical] Cisco Agent Desktop: Cisco Recording and Statistics Service

DirAccessSynSvr.exe
[Optional/Critical] Cisco Agent Desktop: Cisco Sync Service

FCVoIPMonSvr.exe
[Optional/Critical] Cisco Agent Desktop: Cisco VoIP Monitor Service

slurpd.exe
[Optional/Critical] Cisco Agent Desktop: Directory Replication Service

slapd.exe
[Optional/Critical] Cisco Agent Desktop: Directory Services

tomcat5.exe
[Optional/Critical] Cisco Agent Desktop: Tomcat Service

* badialer_ip.exe
[Optional/Critical] Outbound Option: This is the Dialer process that implements a dialing algorithm and places calls to customers during an outbound campaign. The Dialer monitors skill groups for agent availability and reserves agents via the MR PG. The Dialer then informs the Campaign Manager of the result of each attempt to contact a customer.
Administration & Data Server (AW/HDS)
* configlogger.exe
[Critical] Processes inbound configuration data.

* updateaw.exe
[Critical] Updates the local configuration database with configuration data from the central controller.

* rtclient.exe
[Critical] Receives a real-time data feed (from a real-time distributor) and updates the local database.

* rtdist.exe
[Critical] Manages inbound real-time data from the real time server on the Router and distributes it to real-time clients.

* replication.exe
[Critical] Manages replicated historical data received from the Logger (HDS only) and inserts historical data in the HDS database. In addition, it is responsible for historical data purges in the HDS database based upon configured retention parameters.

* cmsnode.exe
[Optional] Configuration Management System (CMS). Manages configuration data for the ConAPI interface. This is a necessary interface (process) for the System CCE web configuration and the Agent Reskilling Tool. Thus, for System Unified CCE, this is an important process. Also, if the customer has purchased the Cisco Unified Contact Center Management Portal (Unified CCMP), CONAPI is also used. However, for a Unified CCE deployment without Unified CCMP, this process is not critical.
In a recent version of Unified CCE, cmsnode.exe runs by default but it is difficult for a management station to know whether it is necessary. Therefore, this is listed as Optional.

* cms_jserver.exe
[Optional] Configuration Management System (CMS) Jaguar Server. This process works with cmsnode.exe for CMS to provide Java interfaces for ConAPI.
In a recent version of Unified CCE, cms_jserver.exe runs by default but it is difficult for a management station to know whether it is necessary. Therefore, this is listed as Optional.

tomcat5.exe
[Optional/Critical] Apache Tomcat servlet engine for SCCE web config.

* iseman.exe
[Optional] Internet Script Editor

sqlservr.exe
[Critical] Microsoft SQL server process

sqlmangr.exe
[Critical] Microsoft SQL server process

sqlagent.exe
[Optional] Microsoft SQL server process
All Nodes
nodeman.exe
[Critical] Node Manager. This process monitors the status of all Unified ICM/Unified CCE processes on the server; should a process terminate unexpectedly, the Node Manager automatically restarts that process.

nmm.exe
[Critical] Node Manager Manager. This process monitors the primary Node Manager (nodeman.exe) process; should the primary Node Manager (nodeman.exe) process terminate unexpectedly, the Node Manager Manager restarts it.

snmpdm.exe
[Important] SNMP master agent

cccsnmpmgmt.exe
[Important] SNMP agent management service – this service manages the SNMP agent infrastructure and restarts any agents that may terminate unexpectedly. It also ensures that the agent processes run at a reduced priority so as to not adversely impact server performance.

msnsaagt.exe
[Important] Microsoft native subagent adapter

hostagt.exe
[Important] HOST-RESOURCES-MIB subagent

sappagt.exe
[Important] SYSAPPL-MIB subagent

cccaagent.exe
[Important] CISCO-CONTACT-CENTER-APPS-MIB subagent


ICM Processes and Description

 Router Processes
Prefix
Process  Name
Description
ccag
CCAGENT
Central Controller DMP Agent. Device Management Protocol Agent that session layer communications with ICM nodes.
dba
DBAGENT
Central Controller Database Agent. Communications process that validates access to the central database.
dbw
DBWORKER
Host Database Lookup. Process that queries external databases and uses resulting data in call routing.
mds
MDSPROC
Message Delivery Service. Process that provides reliable message delivery between ICM processes.
nm
NODEMAN
Node Manager. Process that manages, restarts, and initializes processes on each ICM
nmm
NMM
Node Manager Manager. Process that manages, restarts, and initializes the Node Manager process on each ICM Node.
rtr
Router
Call Router. Process that receives call routing requests, determines call destinations,and collects information about the entire system.
agi
APPGW
Application Gateway. Allows a routing script to pass data to an external application and receive data in return which can be used in routing decisions
rts
RTSERVER
Real Time Server. Process that takes real-time data retrieved from PGs and forwards it to Admin Workstations client CTI applications


Router Startup


1.  All processes start and wait for MDS to go “In Service”

2.  MDS initializes and goes “In Service”

3.  Router loads state from its peer if available. Otherwise router requests config from logger

4.  ccagent accepts connections from DMP devices (PG’s and NIC’s)

5.  Router responds to requests for configuration from PG’s andNIC’s

6. rtsvr accepts connections from real time distributors






Logger Process
Prefix
Process  Name
Description
clgr
CONFIGLOGGER
Configuration Database Logger. Process that stores configuration data in the central database.
hlgr 
HISTLOGGER
Historical Database Logger. Process that stores historical data in the central database.
dtp
DTP
Customer Support Data Transfer Process. Transfers events from the Logger to your ICM support provider.
csfs
CSFS
Customer Support Forwarding Service. Receives, filters, and saves appropriate events for delivery to your ICM support provider.
rcv
RECOVERY
Central Database Recovery. Recovers central database historical data.
rpl
REPLICATION
Replicates data from the Logger historical database to the HDS


Logger Startup

1.  Logger and Recovery processes start and connect to the database

2.  Logger connects to MDS on the same side Router and waits for MDS “In Service”

3.  Recovery attempts to connect to its peer if available and synchronizes Historical Data

4.  Logger loads state from its peer if available, otherwise waits for instructions from the Router








PG Processes
Prefix
Process  Name
Description
opc
OPC
Open Peripheral Controller. Interface between the PIM and the Router. Supplies the Router with uniform message sets from different PG types.
pgag
PGAGENT
Peripheral Gateway DMP Agent. The Device Management Protocol Agent that manages session layer communications between the PG and CallRouter.
pim
Peripheral Interface Manager
Peripheral Interface Manager. The proprietary interface between a peripheral and the PG
mds
MDSPROC
Message Delivery Service. Process that provides reliable message delivery between ICM processes.
nm
NODEMAN
Node Manager. Process that manages, restarts, and initializes processes on each ICM
nmm
NMM
Node Manager Manager. Process that manages, restarts, and initializes the Node Manager process on each ICM Node.
ctisvr
CTILINK
 Computer Telephony Integration server. A PG process that serves as an interface between ICM software and client CTI applications






PG Startup

1.  All processes start and wait for MDS to go “In Service”

2.  MDS initializes and goes “In Service”

3.  OPC loads state from its peer if available. Otherwise OPC sends initialize request to one pgagent

4.  pgagent attempts to establish an active path to one side of the central controller (and an idle path to the other side).

5.  Once active path to central controller is established, OPC sends request to the router asking to be told its configuration information.

6.  Once OPC successfully receives its config from the router it attempts to activate the configured PIMs. This causes the PIMs to connect to the ACDs. If this is successful the PG reports “Peripheral Online” to the router.

AW Processes
Prefix
Process  Name
Description
edt
SCRIPTED
ICM Script Editor. Tool used to create and schedule call routing scripts.
rtc
 RTCLIENT
rtc RTCLIENT Real Time Feed Client. A Distributor AW process that receives real-time data from the
rtd
RTDIST
Real Time Feed Distributor. A Distributor AW process that distributes real-time data to client-only Admin Workstations.
nm
NODEMAN
Node Manager. Process that manages, restarts, and initializes processes on each ICM
nmm
NMM
Node Manager Manager. Process that manages, restarts, and initializes the Node Manager process on each ICM Node.
ise
ISEMAN
Internet Script Editor Manager. Process that manages the Internet Script Editor connections to the Admin Workstation
rpl
 REPLICATION
Replicates historical data from the Logger to the HDS
clgr
CONFIGLOGGER
Configuration Database Logger. Process that stores configuration data in the AW database.
upcc
 UPDATECC
Update ICM Central Database tool. Copies data from the local database to the central databases
AW Startup

1.  Real Time Client (AW Startup rtc) connects to its Distributor and sends a registration request

2.  Real Time Distributor (rtd) accepts the connection from client and attempts to connect to its preferred Real Time Server (rts)

3.  Real Time Server accepts the connection request from the distributor and forwards the initial state of all real time tables

4.  UpdateAW service waits for real time feed to become active and then brings the local DB up-to-date according to config sequence number.

5.  Update AW reports “Waiting for new work…”

6.  Replication will connect to the CC Logger’s replication process and  the CC Logger’s replication process will push Historical Data to the HDS