Cisco Cisco Unified IP Interactive Voice Response (IVR) 8.0(1) Quick Setup Guide

Page of 100
4-2
Getting Started with Cisco Unified Contact Center Express, Release 6.0(1)
Chapter 4      Basic Contact Flow Concepts
  Relationships Between Tasks, Sessions, Contacts, and Channels
The basic Unified CCX call flow process is identified below:
1.
A call arrives at voice gateway. 
2.
The voice gateway routes the call based on direction from the Unified CM (using H.323 or MGCP). 
3.
The Unified CM is configured for the dialed number to be routed by Unified CCX so a route request 
is sent to the Unified CCX server (using JTAPI). 
4.
Based upon the dialed number, Unified CCX selects an available CTI port and initiates the 
configured workflow. The first step in the work flow (accept) initiates the establishment of an 
Real-time Transport Protocol (RTP) VoIP data stream between the CTI port on the Unified CCX 
server and the VG port. In this scenario, we are assuming no appropriately skilled agents are 
available, so the application flow executes the queue loop logic until an agent becomes available.
5.
 An appropriately skilled agent becomes available. 
6.
The agent is selected/reserved by the Unified CCX server and this triggers the call to be transferred 
to the agent's phone and subsequently causes the agent's phone to ring (using Unified CM signaling). 
In addition, the Unified CCX server delivers a screen pop to the selected agent's desktop and enables 
the answer button on the agent's desktop. 
7.
The agent answers the call, which initiates the establishment of an RTP VoIP data stream between 
the agent's phone and the voice gateway port. 
Relationships Between Tasks, Sessions, Contacts, and 
Channels
When installing and configuring Unified CCX, you must understand the concepts, call flows, and 
configuration dependencies explained in this section:
  •
Task. Cisco CRS receives the incoming contact (call) signal on a trigger, which is then assigned an 
application. The application can be a workflow application, a Java application, a routing 
application, or an post-routing application. When Cisco CRS accepts the contact, the application 
starts an application task. The application task in turn invokes an instance of a script associated with 
the application. 
  •
Session. A session tracks contacts as they move around the system. This enables information to be 
shared among contacts that are related to the same session.
When a contact is received (inbound) or initiated (outbound), Cisco CRS checks to see if an existing 
session already exists with that contact's Implementation ID. The Implementation ID is the Unified 
CM Global Call ID plus the Unified CM node (GCID/<node>). If a session already exists for the 
contact, Cisco CRS associates it with that session. If no session already exists for the contact, Cisco 
CRS automatically creates one.
After the contact ends, the session remains idle in memory for a default period of 30 minutes before 
being automatically deleted.
  •
Contact. A contact can be a Call, an HTTP request, or an e-mail. A contact carries attributes such 
as creation time, state, language, and so on.
  •
Channel. Each type of contact has its own channel. Channels are allocated and associated with 
contacts as needed and are used to perform actions on contacts.
These dependencies are illustrated in 
.