The following diagram
shows how various applications in your Unified CCX system work together.
Figure 1. Typical Unified CCX call flow
The basic Unified CCX call flow process is identified below:
A call arrives at voice gateway.
The voice gateway routes the call based on direction from the
Unified CM (using H.323 or MGCP).
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 Unified
Based upon the dialed number, the Unified CCX server selects an
available CTI port and initiates the configured script. 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.
An appropriately skilled agent becomes available.
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.
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 chapter:
Task. Unified CCX receives the incoming contact (call) signal on a
trigger, which is then assigned an application. The application can be a script
application, a Java application, a routing application, or an post-routing
application. When Unified CCX 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
When a contact is received (inbound) or initiated (outbound),
Unified CCX 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, Unified CCX associates it with that session. If no
session already exists for the contact, Unified CCX 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, an email, or a web chat. 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.
Unified CM Telephony deployment considerations
The CTI route point associated with the user enables the
Unified CM to query the pertinent external application for routing instruction.
Different route point's can query different applications (Unified CCX, Unified
ICME, or third-party applications) through Unified CM Telephony. The trigger
(route point or dialed number) is mapped to a CTI port group in the Unified CCX
configuration. The Unified CCX system chooses an available CTI port in this
port group and returns that CTI Port number to the Unified CM so it can setup a
call to that CTI port. The Unified CM then makes a call to that CTI port making
it ring and the accept step at the beginning of the application answers the
call by taking the CTI port off hook. Until the accept step is executed, the
caller hears ringing. If no CTI port is available in that port group, then the
Unified CCX system answers the Unified CM with the all routes busy response,
which triggers the Unified CM to use its forward on busy logic configured for
that CTI route point.
When deploying your system, you must understand the following
about call flows and the Unified CM configuration dependencies that can impact
How is a call presented to the Unified CCX system?
An incoming call is given to the Unified CCX system on a trigger
(CTI Route Point, Caller > CTI Route Point). The trigger signals the Unified
CCX system through Unified CM Telephony that there is an incoming call.
Unified CCX rejects the call if the Max Session limit has been hit
for the trigger or the application to which the trigger is assigned.
If there are available sessions, based on the Call Control Group
assigned to the trigger, Unified CCX searches for an available CTI Port to
receive the call. If it finds an available port, it sends a request to the
Unified CM through Unified CM Telephony/CTI requesting that the caller be
rerouted from the CTI Route Point to the CTI Port.
This takes place as a Unified CM Telephony Redirect request. For
this to be successful, the Unified CMs Default setting for Calling Search Space
(CSS) must be able to place the call to the selected CTI Port (redirecting
party, or in this case, the CTI Route Point).
Why is the CTI Route Point associated with a Unified CM user?
For the Unified CCX system to know that a call is coming, it must
have control of the line carrying the call. This is done through a Unified CM
user. The Unified CM user is associated with the CTI Route Point as a device
that the Unified CM user controls.
When a trigger is assigned to an application in the Unified CCX
system, the Unified CM Telephony subsystem knows that it must take control of
that line using the Unified CM Telephony client installed on the Unified CCX
system. Once it has control of the line, Unified CM Telephony monitors that
line for events as well as performing call-control operations on that line.
How does the Unified CCX system determine which CTI Port to use?
A Unified CCX application requires a trigger. The trigger type
determines whether or not a port is required.
There are two types of triggers: Unified CM Telephony and HTTP.
If an application is started by dialing a phone number, it
must have a Unified CM Telephony trigger.
If an application is started by entering a URL, it must have
an HTTP trigger.
If an application is triggered by calling a Unified CM
The Unified CCX system looks for an available CTI Port in
the Unified CM Telephony Call Control Group assigned to the trigger.
Unified CCX then requests the Unified CM to redirect the
caller to the desired CTI Port.
The call is presented to the CTIport.
Unified CCX accepts the call on the CTI Port, the call
rings on the CTI Port, and a Unified CCX script decides how to handle the call.
Why does the Unified CM Telephony trigger need to have primary
and/or secondary dialog groups assigned to it?
For the Unified CCX system to establish a media connection to a
caller, Unified CCX must allocate a Media Channel for that call. When Unified
CCX accepts a call on a CTI port, it looks for an available Media Channel in
the primary dialog group. The primary dialog group may be an ASR channel. But
if none is available, then the secondary dialog group may be a normal Cisco
Media Channel (DTMF only).
If you do not use ASR/TTS, you will be using the Cisco Media Group
which does not have the secondary dialog group option.
What are the Unified CCX script call control choices?
The call control step choices are:
Accept. Answers the call and establishes a media connection.
This is based on the Primary and Secondary dialog groups assigned to the
trigger. It can be either the Cisco Media Dialog Group or ASR.
Reject. Rejects the call and returns it to the Unified CM
without answering it.
Terminate. Disconnects the Contact.
Redirect. Requests that the Unified CM reroute the caller to
How are Redirects done?
Redirects can be done in several ways:
When Unified CCX requests that a caller be rerouted from a CTI
Route Point to a CTI Port.
When a Unified CCX script executes a Call Redirect step.
Once the Unified CCX system requests a Redirect and the
Unified CM accepts it, the redirecting CTI Port is released and returned to the
idle port list.
HTTP contact flow
When an HTTP request is presented to Unified CCX:
The HTTP trigger is assigned to an application.
When the URL trigger is hit, an application task is started.
The application is assigned to a script and the script starts.
An HTTP control channel is allocated.
The script performs steps on the triggering contact.
Possible step choices are:
Get HTTP contact information. Obtain Header Information, Parameters, Cookies and Environment Attributes and assign them to local variables.
Send a response. Send a Document Object as a response to the calling browser.
Send a JSP reply. Send a response to the calling browser based on a JSP template. This step allows for the mapping of local variables to keywords in the template.
HTTP redirect. Allows a calling browser to be redirected to a different URL.
Web chat flow
See the following figure for a
typical Unified CCX web chat flow:
Figure 2. Unified CCX web chat flow
Configuration: This is a configuration step and is a percursor to the web chat flow depicted in the figure. The appadmin configures the chat parameters, making sure that the Unified CCX administrator has a SocialMiner, chat CSQ, and a chat widget with a problem statement defined and configured. The Unified CCX administrator also reviews and verifies other web chat configuration parameters.
The Unified CCX administrator preconfigures the customer widget form fields using the appadmin in the chat widget creation step. The configuration process generates the skeletal web code that the administrator passes over to the web developer for the customer website. The web developer formats the chat widget code and embeds it into an HTML page on the customer website.
Web chat request: A contact logs in to the customer website and initiates a web chat request by filling up the customer widget form and selecting an appropriate problem statement.
SocialMiner receives the request: SocialMiner receives the web chat request and opens the chat UI at the customer website. Also, the SocialMiner sends the new contact notification to the Unified CCX.
Contact queuing: After receiving the contact notification from SocialMiner, the Unified CCX matches the problem statement chosen by the contact, and queues the contact in a specific service queue.
A queue is a flow where the Unified CCX already has an agent waiting for a contact in that queue and the contact is immediately routed to the available agent.
Agent login: A web chat agent belonging to the service queue on which the contact was queued logs in from the Web Chat Agent desktop.
Agent becomes ready: An agent sends a request to the Unified CCX to make the agent ready to chat. This request triggers the Unified CCX to start an allocation process and find the appropriate contact for the agent from the service queues. The CSQ configuration decides the allocation logic (either most skilled or longest available).
After a contact is identified for the agent, the contact is allocated and the agent is moved to the Busy state and is prompted to accept the contact through a dialog event.
Agent accepts: An agent responds to the dialog event. If the agent does not accept during the configured accept time out, the contact is re-queued and is ready to be allocated to the other agent. After receiving a confirmation from the Unified CCX for the accept request, the Cisco Agent Desktop launches the chat reply template.
Chat session creation: When the SocialMiner gets the request to open the chat reply template from the Cisco Agent Desktop, the SocialMiner serves the template page to the Cisco Agent Desktop and connects the agent to the chat session.
Chat session complete: When an agent or a customer ends the chat session, the SocialMiner sends the event back to the Unified CCX to indicate the session ended.
Unified CCX receives session end message: After receiving the message, the Unified CCX updates the session records and moves the agent back to the Not Ready state.
Important Unified CM configuration dependencies
The Unified CCX software tells the Unified CM how to
distribute calls. For both products to work together correctly, you must
therefore understand how calls are set up when you configure Unified CM
You must be aware of the following:
Repository Datastore. The RDS resides on the Unified CCX server in
the Informix database. It holds the prompts, grammars, documents, and scripts
used by the system.
CTI Ports and Route Points. When configuring Unified CCX through
the Unified CCX Application Administration web page, you must enter and
configure the CTI Ports and Route Point information in the Unified CCX; this
information is updated automatically in the Unified CM by the Unified CCX. The
Unified CCX uses these ports and route points when a call is dialed to the
Route point trigger.
Unified CM Telephony User. When Unified CCX starts up, it
establishes it's Unified CM Telephony communication session with Unified
CM. The Unified CM Telephony user ID and password are used by Unified CM to
authenticate the request to begin a Unified CM Telephony communication session.
The Unified CM Telephony user ID and password are configured into Unified CM
automatically as part of the Unified CCX installation process.
Redirects. The Unified CCX can instruct Unified CM to redirect
calls to another destination. Redirects are essentially a blind transfer. When
a new call arrives at Unified CM and is routed to a CTI route point, the
Unified CCX selects an idle CTI port and implicitly instructs the Unified CM to
redirect the call from the CTI route point device to the selected CTI port
device. The redirect step in the application editor allows calls to be
explicitly redirected to another destination. In either scenario, the
destination needs to be in the same CSS as the CTI ports and CTI route points.
Destination. A redirect will fail if the redirecting device (CTI
Port) lacks a CSS that contains the partition bound to the destination.
Calling Search Space. Calling search spaces (CSS) determine the
partitions that calling devices, including Cisco Unified Communications phones
(SCCP or SIP), and gateways, can search when attempting to complete a call. A
collection of partitions are searched to determine how a dialed number must be
routed. The CSS for the device and the CSS for the directory number get used
together. The directory number CSS takes precedence over the device CSS.
Device Regions. The calling and the called devices' regions
determine the maximum amount of bandwidth that one call is allowed to consume.
While this indirectly affects what codec is used when media negotiation happens
between the two parties, the Region configuration simply dictates the highest
bandwidth codec permissible. Depending on the configuration of the two parties,
other lower-bandwidth codecs might be negotiated during media negotiation.
If you install Unified CCX with the default codec (G.711), your
region configuration must allow calls into the region assigned to the CTI Ports
at G.711. Otherwise, calls across the WAN are forced to G.729 in the region
configuration, which causes the call to fail.
Device Locations. In the event that one or more of the devices are
in a location, if sufficient bandwidth is not available, the requested
call-control operation will fail.
Location Configuration for more
Media Connections. Media connections to the Unified CCX system are
either all G.711 or all G.729. This means that the Unified CM region
configuration must allow for connections between devices and the Unified CCX
server's CTI Ports with the appropriate Codec. If not, then Transcoder
channels MUST be configured and available. You do this at the appropriate
matching Codec at Unified CCX installation time.
Connection path device (Codec). When you create a region, you
specify the codec that can be used for calls between devices within that
region, and between that region and other regions. The system uses regions also
for applications that only support a specific codec; for example, an
application that only uses G.711.
Outbound Dialer configuration properties
The Outbound Dialer feature provides Outbound dialing
functionality in addition to existing Unified CCX inbound capabilities. This
feature allows agents who are not busy with inbound calls to handle Outbound
calls. With the Outbound feature, customer calls are placed using the Cisco
Unified Communications by way of the Unified CM for call control.
Since Unified CCX 9.0(1), you can configure a campaign as an
Outbound IVR campaign if you have an Outbound IVR license in addition to the
existing Unified CCX Premium license. If you select the IVR based option for a
campaign, the outbound calls will be handled by the IVR scripts. Typical
applications include appointment and bill payment reminders.
You must be aware of the following:
License requirements. The outbound feature is available along with
the Unified CCX Premium license and not available with Standard and Enhanced
licenses. Since Unified CCX 9.0(1), you need to upload an Outbound IVR license
in addition to the existing Unified CCX Premium license if you want to create
Outbound IVR campaigns.
Deployment availability. The Outbound feature is only available
with Unified CM deployments.
Area code mapping. The system is pre-configured with the area code
and time zone mappings for only the area codes within North America. You must
manually enter the time zone mapping for international area codes into the
system using the Unified CCX Administration GUI.
Do Not Call list. The United States Do Not Call list is not
supported and must be filtered out manually before uploading. You must use your
own tools to expunge Do Not Call numbers from their Contact List table.
High availability requirements. For high availability deployments,
all Unified CCX and database nodes must already be in service.
IP Phone Agent. The IP Phone Agent is not supported
CAD workflows. CAD workflows will be disabled for outbound calls.
10,000 contacts. Contacts can only be uploaded in batches of
Time zone usage. The contact's time zone is used as an
indication of when the system can place an outbound call to that contact.