UCCX

• Cisco Unified Contact Center Express (Unified CCX) delivers a highly secure, available,
virtual, and sophisticated customer interaction management solution for up to 400
agents.
• Sophisticated call routing and comprehensive contact management capabilities
• E-mail, Web Chat and social media integration
• Automatic call distributor features, including conditional routing, call-in-queue, and
expected-wait-time messages
• Workforce optimization, including workforce management and advanced quality
management
• Next-generation historical and real-time reports and dashboards with flexible
presentation options using Cisco Unified Intelligence Center
 Deployment
UCCX can have a maximum of two nodes in the setup .
• PUBLISHER/ Primary Subscriber/Secondary will be fixed
• Master and Slave are interchangeable based on which server is
processing the calls
Two Types of Deployment

• HAOWAN ( High availability over the WAN)

• HAOLAN ( High availability over the LAN)

 Deployment
LAN/WAN

Engine + Database + Engine + Database +

CAD Services + CAD Services +
VoIP Monitoring/Recording + Finesse VoIP Monitoring/Recording + Finesse
 Two server (master & standby)
 80ms RTT between the primary and secondary box
 Bandwidth:
 Between UCCX servers 1.2 MBps
 Between CUCM 800 Kbps
 Failover detection
 LAN: If the system misses 5 heartbeats (Interval = .5 sec)
 WAN: If the system misses 10 heartbeats (Interval = 1 sec)
 Sever Roles
 Publisher:
 First server installed in the cluster
 It host Historical store, and Repository Data store,
 Subscriber:
 Second server installed in the cluster
 It also host Historical Data store, Agent Data store, and Repository Data
store
 These roles cannot be changed.
 Server Roles
 Database Master:
 Data is always written from the database master and then it is replicated to the
standby database
 Engine Master:
 It is the server which actively takes call.
 From UCCX 8.x and above Database Master always follows Engine master
Installation
Installation
Installation
Installation ( Mandatory Config from
10.X)
Installation
Installation (Security Password)
Installation
Fresh Install
Fresh Install
Fresh Install
Fresh Install
Adding the Second Node
Pre-Requisites for Adding second node
Pre – Requisites
• Node 1 should be up and running.
• Warm standby feature should be present in the license.
• Two servers should be able to reach each other
through LAN or WAN.
• Make sure the first node is synchronized with NTP
server, Otherwise the secondary node installation will
fail
Pre-Requisites for Adding second node
Pre – Requisites
 Information of the secondary box
should be added in primary UCCX
server.
 Installation of Second node
Second server installation
 Installation prompts if it’s a first node ?
 System then checks to ensure that the second node can connect to the first
node .

1 2
3
 Installation of Second node
 System prompts to put in the first node IP/Hostname/security
password info.
 Installation of Second node
Post installation Task
• Type in the URL:
http://servernameIP
• First node IP should be
populated.
• Provide the UCCX admin
details used by first node.
Application Users
 Application Users
• AXL User – Created on both CUCM under application
User and then the same credentials are used on UCCX
as well
• CM Telephony User / JTAPI User – The user is created
on UCCX only and gets pushed over to CM all config
related changes are supposed to be done on UCCX
• RMCM USER - The user is created on UCCX only and
gets pushed over to CM all config related changes are
supposed to be done on UCCX
 AXL USER
• Cisco application programming interface (API) and web
service designed to give applications access to Cisco
CallManager configuration and provisioning service
• This access will allow certain methods (list, add,
update, get, remove) when those other applications in
this Case UCCX accesses the CUCM database.

• get read access to users, phones, features, settings,

permissions, etc. within the CUCM database.
 CM telephony User
• It is used to take control of the CTI route
points and CTI ports which are registered on
call manager.

• It is used to receive event information for

UCCX agents and calls From CTI manager.
 RMCM User
• The Resource Manager as the name suggests
is used to control agent states and monitor
agent phones.
• We need to manually select the phones or
Device profiles under the RMCM user on
application page for us to control the agent
Phones or device profiles.
 Login Access After Unified Sign-On
Web Applications Application User CUCM End User (AXL Platform User (Linux OS
Administrator) User)

Cisco Unified CCX Application Administration Yes ( Permanently even after Initial Yes No
AppAdmin configuration)

Cisco Unified Serviceability Yes No No

Cisco Unified CCX Serviceability Yes Yes No

Cisco Desktop Administrator Yes Yes No

Green indicates New feature changes

Cisco OS Administration No No Yes

DRS No No Yes
Licensing In UCCX
 Licensing MAC Parameters
▪ Time zone
▪ NTP Server 1 (or ‘none’)
▪ NIC speed (or ‘auto’)
▪ Hostname
▪ IP Address
▪ IP Mask
▪ Gateway Address
▪ Primary DNS
▪ SMTP Server (or ‘none’)
▪ Certificate Information (Organization, Unit, Location, State, Country)

** If any of the above parameter is modified, the license needs to be re-hosted with new MAC-ID.
 License Categories
Active License – They make the system function.
• The feature lines of the license that is being currently in use. This includes Permanent licenses and
Temporary licenses that is yet to expire.

• Demo License is an Active License Until a Temporary/Permanent license is uploaded to the system.

In-Active License – They are proper licenses but don’t count for system functionality.
• The Temporary licenses that have expired already

• The Demo license is considered inactive after a permanent/temporary license is uploaded.

Invalid License – They are not proper licenses and don’t count for system functionality.
• A license with wrong Licensing Mac-Id

• Upon Re-hosting of a new licensing with a new Licensing MacId, based on any changes to the 14
parameters that determine the Licensing MacId, the Old License is deemed as Invalid License.

* The Demo and Re-hosted License has a Grace Period of 30 days.

 User Experience Enhancements
• Warning modified from Popup to a Static Message in login screen

• Very similar to CUCM login page experience.

• In addition to the warning message, a Hyperlink Link is added from login page
to the License Display page.
 Display License(s) Enhancements –
License Drop-Down Box
Dropdown box to List of all the Licenses applied to the system
(unless deleted).
 Display License(s) Enhancements -
Cumulative License Details
Cumulative License Information as part of the dropdown displays the Active Feature
Lines and corresponding counts (a cumulative of all active licenses).
Display License(s) Enhancements –
License Content Display
When a specific license is selected, the
content of that license will be displayed.
Call Flow and Components
 High Level Overview
Overview
Redirect
CTI Route Point/ Trigger CTI Port/ Virtual Phone
C
o
n
s
u
l
T
Agent
 Inbound call Flow
• Any call observer is used at the time of transition
• Cisco Media Termination (CMT) dialog groups that can be
used to handle simple Dual-Tone Multi-Frequency (DTMF)
based dialog interactions with customers.
• A dialog group is a pool of dialog channels in which each
channel is used to perform dialog interactions with a caller.
 1st Call Leg on the CTI route point
• Call Hits the CTI route point/Trigger

• New Call Event is encountered on the JTAPI layer.

• Redirect Request is sent from UCCX over the JTAPI for the
allocation of a CTI port ( random) managed by Subsystem
Telephony ------------ observed by the P1 Telephony provider
 2nd Call Leg From CTI Route Point to
Port
• Call Answer Request is sent meaning call state has changed to answered
after the accept step is hit in the script. ------------ observed by the P1
Telephony provider
• Device Call open logical connection for media negotiation happens between
the Source and the CTI port . basically sharing the media information of the
far end
• Device SetRTP for call request is sent over to the Call manager ( This would
have the Ip address and port number of the CTI port on which the call lands)

• If there is a codec mismatch between the Calling party and CTI port it will be
something that gets encountered here before any transmission and
reception of media can occur.
 Contd..
• After this if everything goes fine then media starts flowing between
source and CTI port as destination with Prompts being managed by the
prompt manager again a manager inside Engine component of UCCX and
all the call control actions are being taken care by the Contact manager
(CM)

• When the call hits the select resource step that is responsible for routing it
to the agent the media is torn down between the CTI port and the source.

• Call Setup transfer request over the JTAPI layer is sent to CTI manager. This
is very similar to when we press the transfer button on the phone for the
first time.
 3rd leg From CTI port to Agent Phone
• For the call setup transfer request CTI makes a transfer reply so that call could be
transferred to the phone so this marks the initiation of the 3rd call leg from CTI
port to the agent phone.

• Then various states on the JTAPI leg are encountered as if one phone is trying to
transfer a call.

• We would see Dialtone , proceeding , ringback and finally connected state.

• So the Contactmgr.offer Resource interface gets exposed to RM which is the

resource manager to notify CM about any ready or available resource
 Contd..
• After the proceeding state we would see the P2
provider that basically handles phones kicking in.

• Eventually for a successful transfer to take place Call

Direct transfer request is sent to Call manager and this
would be like pressing that transfer button for the
second time on the phone .
Detailed Over of how call is managed
in UCCX
 ICD Components
• Contact Manager
• Resource Manager
• CTI Server
• Historical Reporting Data Manager
• Real Time Reporting Data Manager
 Contact Manager
• Contact Manager in RMCMSubsystem manages
the contact such as queuing the call and
allocating it to agents based on priority.
• It listens to the APPFW's contact related events.
• It also receives contact related
CMEventReqMsg from resource manager(RM).
 Resource Manager
• RM is mainly responsible for managing the
Agents in the system.
• It mainly comprises of an observer to the
JTAPI events on agent devices and translates
these events to Session Messages that are
posted to the RMMsgQ and are then
processed by the RsrcMgrMsgProcessor.
 Components
Three main basic components
• Finesse
• CUIC
• Cisco Agent Desktop/Cisco Supervisor Desktop
Finesse
A next-generation agent and supervisor desktop starting Cisco Unified CCX 10.0(1)

Why Cisco Finesse?

• 100% browser-based desktop using Web 2.0 technologies – requires NO client installations
• A single container interface achieved through OpenSocial gadgets – plug and play multiple assets and information
sources

No. Cisco Agent Desktop and Cisco Supervisor Desktop continue to be available in CCX 10.0(1) in all capacity.
Cisco Finesse has been introduced to be used as a next-gen alternative to CAD/CSD.*

* More information in further slides

 Solution Architecture
Finesse Desktop Media
(Browser) V

XMPP CCX Notification

Finesse Server
Service
(Tomcat) (Openfire)
SIP/SCCP

XMPP

CUIC Server
(Tomcat)
CTI Server RmCm JTAPI CUCM

UCCX Engine UCCX Node

 UCCE

30,000 Foot View (UCCX)

Desktop Desktop
(Site A) (Site B)

Cisco Finesse Cisco Finesse

Site A

Site B
Tomcat Tomcat

UCCX UCCX
(Master) (Slave)

Active Connection Inactive Connection (for Failover) Various Communication

 UCCE

Desktop

Browser
Cisco Finesse Tomcat
20,000 Foot View (UCCX)
Cisco Unified
CCX Notification
Service
UCCX

A Cisco DB
(Informix)

Cisco Unified Other Services

CCX Engine

UCM

GED-188 Hibernate JTAPI AXL HTTP/S (Admin) HTTP/S (Agent) XMPP (BOSH) XMPP
 10,000 Foot View (UCCX)
UCCE

Cisco Finesse Cisco Finesse

Browser
Desktop
Administration (Agent & Supervisor
(Administrator Desktop) Desktop)

Shindig (Apache)
Cisco Finesse Tomcat

Cisco Unified
CCX Notification
CCX Realm
Service
UCCX

cfadmin 3rdpartygadget desktop finesse A Cisco DB

(Administrator WAR) (3rd Party Gadget WAR) (Agent Desktop WAR) (REST API WAR) (Informix)

3rdpartygadget
opt directory Cisco Unified Other Services
CCX Engine

UCM

GED-188 Hibernate JTAPI AXL HTTP/S (Admin) HTTP/S (Agent) XMPP (BOSH) XMPP
 Overlaying Real Scenario Over
Architecture 5) Dialog Created/Update (ALERTING)
Cisco Finesse Notification Service

12) Dialog Update (ACTIVE)

Finesse
4) Dialog Created/Update (ALERTING)
11) Dialog Update (ACTIVE)

Cisco Finesse Tomcat

Rest API WAR
6) Dialog PUT (Answer)

3) Begin Call/Call Delivered Events 7) Answer Call Request

10) Call Established Event

UCCX
1) Customer places Call 2) UCCX/UCM “Magic”
UCM 8) More “Magic”
Engine (CTI Server)
9) Call gets connected

Various GED-188 HTTP/S XMPP (BOSH) XMPP

Agent login Process Finesse
 Login Process in Finesse
• Finesse uses Tomcat as the web server. When you launch your web browser, the request is made
to Finesse to present the agent desktop to you. The Cisco Tomcat localhost_access_log command
shows the request to load the agent desktop.

• Now that the agent desktop has been presented, you enter your login credentials. Before Finesse
can send the login request to the CTI Server, the client needs to establish a Bidirectional-streams
Over Synchronous HTTP (BOSH) Connection. In order to establish the BOSH Connection, the client
first requests System Information from the Finesse Server.

• The client's desktop made a Representational State Transfer (REST) Application Programming
Interface (API) request to this URL: /finesse/api/SystemInfo. Take note of the nocache=. This
unique ID is used in order to trace this request through the system. Returned with status=200
indicates that the request was successfully received.
 Contd.
• Tomcat sends this API request to the Finesse REST API Web Application Repository (WAR). In
order to find the Finesse REST API logs, search the Finesse webservices log either by timestamp or
the nocache ID in order to locate the API_REQUEST. This log shows the REQUEST_START, the
REQUEST_URL, the REQUEST_END, and the elapsed_time the system took to complete the
request.

• Establish the BOSH Connection

• The SystemInfo shows the Primary and Secondary Finesse servers, the status of Finesse as
IN_SERVICE, the xmppDomain, and the xmppPubSubDomain. The client now has enough
information in order to establish a BOSH connection.

• The client is successfully subscribed to the Finesse Object (node) once the BOSH connection is
established.
 Contd.
• When the client's BOSH connection is established, the webservices log recieves a
PRESENCE_NOTIFICATION message from the client. This PRESENCE_TYPE only indicates that the
client is available to recieve XMPP Events and has nothing to do with the agent availability in
Unified Contact Center Express (UCCX). Remember that the agent is not signed in yet.

• Note: You only see the PRESENCE_TYPE messages when a client establishes a BOSH connection or
when a client's BOSH connection is disconnected. When the client's BOSH connection is
disconnected, the PRESENCE_TYPE displays as unavailable.

• Now that the client has established the BOSH connection, the sign-in process begins. The client
makes another REST API request in order to obtain current user information. In order to make
this request, navigate to this URL: /finesse/api/User/RAGHAV and enter method=GET.
 Contd.
• XMPP Event, which is agent RAGHAV in this example, is sent to all subscription clients.

• Perform Login

• Now the client is ready to perform login. Notice the RequestID. The RequestID is sent in the body
of the request. You use this RequestID in order to follow the login request to the REST API > CTI >
REST API > Notification Service > Response back to the client. This request is a PUT, which means
that the client is requesting an UPDATE or a change to its current state.

• The Finesse REST WAR receives this request from the client. Then, the API sends a
SetAgentStateReq to the CTI Server.
 Contd.
• The CTI Server receives the request.

• Once the agent is logged in with a status of NOT_READY, the CTI Server sends AGENT_STATE-
EVENT to Finesse.

• Now that Finesse received the AgentStateEvent from the CTI server, the event needs to be
Published to the Notification Service so that the client receives the UPDATE. The only way for the
agent to know that his/her state has changed is by receiving this XMPP Event. Finesse converts
the AgentStateEvent to XMPP and sends the XMPP to the Notification Service. Notice that the
Event is a PUT, and the RequestID is in the Payload.

• Here, the Notification Service receives the UPDATE. Now the client is successfully logged in.
Failover
 Failover

Browser

Browser
Desktop

Desktop
Cisco Unified Cisco Unified

Cisco Tomcat

Cisco Tomcat
CCX Notification CCX Notification
Service Service

Cisco Unified Cisco Unified

CCX Engine CCX Engine
OUT_OF_SERVICE
IN_SERVICE IN_SERVICE
OUT_OF_SERVICE
UCCX Maste UCCX Maste
Side A Secondary Side B Secondary
r r

Failure Scenario Failover? What happens What Happens to What happens to Finesse Client Recovery
to UCCX? Finesse Site A? Finesse Site B? Behavior?
After Site B comes to After Site A comes back
Site B becomes IN_SERVICE after a IN_SERVICE, clients are up and Finesse on Site A
CCX Engine Failure YES OUT_OF_SERVICE
master few minutes redirected there and goes IN_SERVICE, clients
automatically login are redirected to Site A
 Failover

Browser

Browser
Desktop

Desktop
Cisco Unified Cisco Unified

Cisco Tomcat

Cisco Tomcat
CCX Notification CCX Notification
Service Service

Cisco Unified Cisco Unified

CCX Engine CCX Engine
OUT_OF_SERVICE
IN_SERVICE OUT_OF_SERVICE
UCCX Maste UCCX
Side A Side B Secondary
r

Failure Scenario Failover? What happens What Happens to What happens to Finesse Client Recovery
to UCCX? Finesse Site A? Finesse Site B? Behavior?
After Finesse Tomcat
Finesse Tomcat Site A remains Sessions will be stuck. comes back up, stuck
NO OUT_OF_SERVICE OUT_OF_SERVICE
crash master Nothing can be done. client sessions resume
automatically
 Failover

Browser

Browser
Desktop

Desktop
Cisco Unified Cisco Unified

Cisco Tomcat

Cisco Tomcat
CCX Notification CCX Notification
Service Service

Cisco Unified Cisco Unified

CCX Engine CCX Engine
OUT_OF_SERVICE
IN_SERVICE OUT_OF_SERVICE
UCCX Maste UCCX
Side A Side B Secondary
r

Failure Scenario Failover? What happens What Happens to What happens to Finesse Client Recovery
to UCCX? Finesse Site A? Finesse Site B? Behavior?
After CCX Notification
CCX Notification Site A remains Service comes back to
NO OUT_OF_SERVICE OUT_OF_SERVICE Sessions will be closed.
Service crashes master IN_SERVICE, all client
sessions have to re-login
 Failover

Browser

Browser
Desktop

Desktop
Cisco Unified Cisco Unified

Cisco Tomcat

Cisco Tomcat
CCX Notification CCX Notification
Service Service

Cisco Unified Cisco Unified

CCX Engine CCX Engine
IN_SERVICE OUT_OF_SERVICE
UCCX Maste UCCX
OUT_OF_SERVICE Secondary
Side A r Side B

Failure Scenario Failover? What happens What Happens to What happens to Finesse Client Recovery
to UCCX? Finesse Site A? Finesse Site B? Behavior?
After Finesse status
Finesse Tomcat is
comes back to
IN SERVICE but Site A remains Sessions will be stuck.
NO OUT_OF_SERVICE OUT_OF_SERVICE IN_SERVICE, stuck client
Finesse status is master Nothing can be done.
sessions resume
OUT_OF_SERVICE
automatically
 Live Data Reports : JMS Topic
JMS Topics Mapping
Live Data Reports
AgentStateDetailStats • Agent State Log

VoiceIAQStats • Voice CSQ Summary*

• Agent Statistics
• Agent Team Summary
ResourceIAQStats
• Team State Report*
• Team Summary Report*

AgentCSQStats • Agent CSQ Statistics

VoiceCSQDetailsStats • Voice CSQ Detail*

* Supervisor Report
Troubleshooting tools - Desktop Logs
https://<CCX URL>:8445/desktop/locallog
 Troubleshooting tools – Developer tool
F12 on your browser will launch developer tool which will help in
tracking message exchange between client and server