UCCE Primer For Rookies

I hear all the time that UCCE is just a different skill set however all call center platforms do essentially the same stuff. This blog is an attempt to give people who have seen some type of call center, but never done anything with UCCE a basic understanding of the components, architecture and how it all fits together. This eventually should turn into a nice compliment to my CVP series, which is only one blog so far. So basically, a really crappy ‘series’ thus far.

Components and Terms of UCCE

UCCE is made up of a bunch of different components, which is why right off the bat its very confusing, so the first thing I am going to do is take some of the major components and just define them and describe a little bit about them.

SIDE A / SIDE B: UCCE has the ability to be fully redundant on every single component in it. These are referred to as sides A and B. In almost every component in UCCE there are active/standby sides, except a few. I will explain these after each description. When you a running a pair of UCCE servers, it is said to be duplexed.

Private and Public Networks: This is something you hear all the time, most components talk over 2 possible networks. The companies normal LAN/WAN is what we call the public network. The private network is either a cross over cable between a pair of machines (for example 2 Routers in the same datacenter.). If the UCCE is geographically redundant it would be a completely segregated network from the normal LAN/ WAN. This means that almost all UCCE servers are talking out of 2 NIC’s onto 2 separate networks. The term segregation for the private network should NOT be understated. In general we are talking their own dedicated switch and routers on each side of the WAN, going straight into the 2nd NIC on the UCCE boxes. The switch would only have a management VLAN on it other then that.

Logger: This is one of the 2 parts of the brain, referred to by us UCCE guys as the ‘Central Controllers’. Think of this guy as the brains memory. All UCCE runs on windows, and specifically normally Windows 2008 R2 Enterprise nowadays, and therefore the Logger is really just a big SQL Server 2008 instance.  (Note older systems (typically < v7.5 run windows and sql 2003.) — Active/Standby

Router: This is the nervous system side of the brain, and the other half of the Central Controller. This is the guy that controls all the other parts of the system that want to talk to the central controller, it runs the scripts we write on the admin workstation and overall is every other part of the brain other than the database itself. — Active/Standby

To re-iterate both components the Router and Logger combine to form the Central Controller. When these are services are installed on the same box you will usually here it reffered to as a ROGGER. This is a very common setup for sub 1000 agent systems. — Active/Standby

AW/HDS: This is separated by a slash because it is actually 2 components, but they almost are always seen paired together. The first component is the Admin Workstation.   This is where you actually configure things like agents, skills and scripts (In a product called Internet Script Editor). All these configs are pushed straight to the Logger where the Router reads the info.

The other part of this is the HDS or the Historical Datastrore. This is the big reporting database that all the reporting tools such as CUIC (Cisco Unified Intelligence Center) and Exony talk to. This typically keeps years worth of detailed data and is populated by the Logger. Except for a few tables, the Logger only holds 14 days worth of reporting information.

Peripheral Gateway: This is also know as the PG in UCCE land, the PG can best be though of as a connector. A PG For example is the link between CUCM and the UCCE. This is the box that has the JTAPI plugin installed, it is also typically the machine that the agents desktops are pointed to so they can login into CUCM. The PG always talks directly to the router and another endpoint. Examples of endpoints are CUCM, CVP, IP IVR, Outbound Dialer etc… That means if you install had a CUCM and the VRU was a CVP you would have 2 PG’s, one for the CUCM and one for the CVP. This can get a bit tricky because the next sections term, the PIM. — Active/Standby

This is a good start, I hit some major topics, now let’s get confusing.

What is a PG For Real

It is extremely important to note that a PG actually runs a bunch of UCCE components on it, and I would like to recap it in detail. In general the UCCE system could run all of these components I am about to list on separate machines, and some very huge environments do, that is why UCCE is a highly distributed environment depending on the load/volume that is expected.

PIM: Each PG has something called a PIM or Peripheral Interface Manager that runs under it. If you wanted to talk to one CM cluster you need one PIM, but if you wanted to talk to 3 CM’s cluster you would need 3 PIM’s. How many PIM’s run under a PG’s is all based on sizing and design. Typically you can’t mix and match types of PIM’s. So under a single PG instance it would need to be all CUCM or all CVP that it’s connecting with. The only exception is CUCM and CVP/IP IVR combination. These can be done under a single PG instance. — Active/Standby

So overall what it looks like is below:

CUCM <-> PG (running 1 or many PIMs)<-> ROUTER <-> LOGGER is how things connect to each other

In a design that has 4 CVP’s, 2 on each side of a WAN in different data centers, a common design would be to have 2 PG (Side A and B) running 4 PIMs each. One to each of the 4 CVP’s.   (Yes 2 of them will be active over the WAN, that is completely supported)

CTIOSServer:   This guy is the interface for UCCE agents events to the outside world. This is the actual component that all of the Agent Desktop software talks to, or softphones as they are referred to buy some folks. Cisco Agent Desktop, CTIOS Out of the client, Cisco Finesse, and CRM’s like Siebel, Salesforce and SAP all used the CTIOS Server as its interface. This is a well documented interface and any developer can make applications to interface with UCCE through this. — Active/Active

CTIServer: This component sites in between the CTIOS Server and the PG and is proprietary. Not much to do here other than install it, and debug it if cisco asks you too. — Active/Standby

This means the real connections flow is more like this.

Agent Desktop Applications <-> CTIOS Sever <-> CTI Server <-> PG <-> PIM <-> CUCM

What you will notice from my previous flow is the PG talks to the Router and the CUCM, that why this component is the magical link to actually get an agent logged into the system!

Fitting It Into a Real Life Scenario

Let’s say the customer had 1 CUCM Cluster, 2 CVP’s, 2 Datacenters, and 1000 agents. A typical design would be as follows.

  • A geographically redundant fully duplexed Side A and B running across 2 datacenters.
  • A Private network with 2 T1’s that is completely segregated.
  • A public network (LAN/WAN)
  • 2 ROGGERS (2 boxes that each have the Logger and Rogger service running on them) 1 in each data center.
  • 2 PGs (Each has 1 PG instance with 3 PIMs, 1 PIM for CUCM, and 1 PIM for each of the 2 CVP servers, to total 3 PIMs) . 1 of these PGs is in each of the data centers.
  • On each of the PG’s is running a CTI Server, a CTIOS Server and the PG instance with the PIM’s
  • 2 AW/HDS running, one in each data center

This was meant to get people who know what a UCCE is but don’t know anything about it a bit more of a starting point. I will be writing another post shortly on how to configure your own lab and get an agent taking calls. This will be in conjunction with the CVP Series.