Part 1: Installing PCCE 12 – The Core

Lately Cloverhound has been doing a lot of work on PCCE and with the introduction of version 12 things are quite different from UCCE. We figured it was time to write a blog as Cisco’s documentation on PCCE vs. UCCE for each of the versions is very tough to navigate. This will be one of our most in depth posts covering the entire install and initial configuration process step by step. We’ll assume you know some of the basic CCE terminology and concepts, read up on our CCE intro if you need a primer. Otherwise, let’s get started!

The Differences between PCCE and UCCE

PCCE (Packaged Contact Center Enterprise) is a variant of UCCE (Unified Contact Center Enterprise) that uses the same architecture in the backend. That means it has the same system components (Router, Logger, PG, CVP, etc..) and the same tools to use in troubleshooting the system. That being said, PCCE (especially v12) is quite different in the following ways:

• PCCE is extremely strict in what architectures are allowed. It can only be deployed following Cisco’s documented “reference designs.”
• Heavily automated installation process with strict requirement checks. This is drastically different from UCCE. If you’re coming in with experience installing UCCE, read the manual before you do anything!
• Administration of the platform. For several versions now PCCE has featured a web based administrator not fully available in UCCE. In version 12, this has been significantly enhanced and to include full system administration and features formerly part of the CVP Operations Console. The new administration app is known as the “SPOG” aka Single Pane of Glass. For the most part nothing is configured under the old “Configuration Manager” utility.
• Even components like ECE have a SPOG page add-on that allows central configuration. The SPOG page offers a ‘gadget’ like add-on and you too, can write third party administration tools and integrate them into the SPOG. I know your all dying to see it so it looks like this:

• Some optional components like Dialer still follow a somewhat hybrid process. You still need to manually deploy the PIM’s on the MRPG, however there is a MRPG pre-built that is auto deployed with PCCE now.

So as you can see above, there are a lot of differences and plenty that is familiar.

 

Important Requirements and Gotchas

 

DO NOT SKIP THIS SECTION! Especially if you have prior experience installing CCE, there are critical differences and gotchas in PCCE v12 that can cost you a lot of time if you ignore them.

 

• PCCE requires and actively validates that your server layout exactly matches the reference design, including which VM is placed on which UCS chassis and the presence of unsupported VMs on same (lab builds are lenient on VM placement but not OVA template usage). This means Router, Logger, PG, AW/HDS, CVP Finesse and CUIC all have explicit requirements with how many of each of these servers you need and whether the environment is simplex or duplex. You must choose on the reference layouts documented in the CCE design guide, supporting either 2000, 4000 or 12000 agent counts. If your VM layout doesn’t exactly match one of these reference designs, YOUR INSTALL WILL FAIL, NO EXCEPTIONS.
• The PCCE installer knows everything. It inspects the model of UCS chassis you are running, it knows every single VM on every chassis and what purpose it serves, and it knows exactly what OVAs are in use and whether they have been altered. Do not try and fool the installer or take shortcuts, it will punish you by failing to install.
• No CVP Operations Console as of PCCE v12. Don’t install it, all Operations Console functions have moved to the all-powerful SPOG.
• Once the core is deployed you can do things like deploy extra CVPs and VVBs at remote locations in order to keep call treatment local. PCCE refers to these locations as ‘sites’.
• Some components like Dialer and ECE are optional, however, Cisco has streamlined the process for adding them on. We will cover these in future posts as the core PCCE installation process does not include them.
• Don’t do ANYTHING manually that you would do in UCCE to install, unless explicitly outlined in the PCCE installation guide. Don’t even run ICMDBA on the logger. Literally do absolutely nothing after you install ICM and all the components. (You will run Domain Manager still but we cover that shortly). There is a special SQL Server database automatically created when you launch the installer called pcce_inventory tracks your inventory and installation progress. Manual changes will tend to freeze this database mid-progress and block you from proceeding. You’ll then get into an infinite loop of deleting all configuration on machines and deleting the ‘pcce_inventory’ DB until you hit that magic amount of reboots to get the PCCE installer running again. It’s like a trap specially designed to capture people who know a lot of UCCE already. Trust us on this: play dumb, read the install guide line by line, and touch NOTHING after running the PCCE installer that isn’t explicitly in the install guide or mentioned here.
• One more time: FOLLOW THE INSTALLATION GUIDE (and this post) to a T. We’ll include links to Cisco docs where appropriate.

Server Layouts

In this post we will be deploying the Lab Only Duplex-mode model. Here is the link to Cisco that describes this layout: 

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/pcce/pcce_12_0_1/maintenance/Guide/pcce_b_admin-and-config-guide_120/pcce_b_admin-and-config-guide_120_chapter_01000011.html#concept_291514BD1360F5F537859669F2CBF0EB

The layout for our servers is as follows according to this doc.

• You are probably wondering what other layouts we can deploy and how they map to UCCE. Here is a table from Cisco’s design guide:

Here is a screenshot of all the server deployment options straight from the installer.

Remember, the Lab Only option does not enforce server model and VM placement requirements. If you’re installing one of the production reference designs, things will be even stricter than what you see in this post. Follow the reference guide exactly.

The Server and App installs

Let’s take a quick look at the Installation Guide for the 2,000 agent reference design just to hammer home that we only run the installer and do NO configuration. The link is here:

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/pcce/pcce_12_0_1/installation/Guide/pcce_b_pcce-install-upgrade-12-0/pcce_b_pcce-install-upgrade-12-0_chapter_01001.html

As you can see from the outline the steps they give are very high level:

If we dig down into say the Rogger here is what we get for the steps for installing the Rogger:

Effectively the steps are setup VM, install Windows and SQL Server, and run CCE installer. This is literally all we do to get it to the point the PCCE installer will run and do all of it’s magic. Install each server on this page to the exact place it says and STOP.

The exception is any component running on Cisco’s Linux platform – UCOS, such as UCM, CUIC, VVB, and Finesse. These are setup as before by running through the UCOS setup wizard. The exception is you do not configure the applications via their web UI unless stated otherwise.

Note: PCCE and UCCE v12 support changed from Windows 2012 to Windows 2016 in after initial release. New install ISOs were issued for the 2016 compatible version. PCCE 12 is ONLY supported on Windows 2016 now. Make sure you install Windows 2016. If the installer complains about not support it, you need to get the updated installer image. Here is the official communication from Cisco: https://community.cisco.com/t5/collaboration-voice-and-video/cce-12-0-now-supported-on-windows-server-2016/ta-p/3889014

Below is an outline of the steps we will follow in this post. You can find the CCE OVA templates here (needs a Cisco account with download access):

https://software.cisco.com/download/home/268439622/type/283914286/release/12.0(1)

1. Install 2 Roggers and 2 AW/HDSs (Side A and B)
   1. Create VM from OVA Templates.
   2. Install Windows 2016. (Make sure to license it as either Standard or Enterprise, the installer will not allow Windows 2016 Evaluation or Developer editions).
   3. Install SQL Server 2017. Make sure to follow the Cisco installation guide step by step: https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/pcce/pcce_12_0_1/installation/Guide/pcce_b_pcce-install-upgrade-12-0/pcce_b_pcce-install-upgrade-12-0_appendix_0100001.html#task_BFD5435B077F5DD844025A17F2B572DB
   4. Run PCCE 12.0(1) installer from the 2016 compatible ISO. (See Appendix A for screenshots and process to this installer).
   5. Install PCCE Mandatory update found on CCO here: https://software.cisco.com/download/home/268439622/type/280840583/release/12.0(1)

1. Install 2 PGs (Side A and B)
   1. Create VM from OVA Templates.
   2. Install Windows 2016.
   3. Run PCCE 12.0(1) installer from the 2016 compatible ISO. (See Appendix A for screenshots and process to this installer).
   4. Install PCCE Mandatory update found on CCO here: https://software.cisco.com/download/home/268439622/type/280840583/release/12.0(1)
2. Install 2 CVP Call/VXML servers.
   1. Create VM from OVA Templates.
   2. Install Windows 2016.
   3. Download CVP Software from Cisco.com: https://software.cisco.com/download/home/270563413/type/280840592/release/12.0(1)
   4. Install CVP 12.0(1) ISO for Windows 2016. (See Appendix B for screenshots and process to this installer)
3. Install 3 CUCM Servers (1 Publisher, 2 Subscribers). For the purposes of this lab we’ll install 12.5(1), which is supported with PCCE 12.0.
   1. Create VM from OVA Template. https://software.cisco.com/download/home/286322286/type/283088407/release/12.5(1)
   2. Install CUCM Pub
   3. Install CUCM Sub 1
   4. Install CUCM Sub 2
   5. Patch CUCM Primary to ES1 (Software here: https://software.cisco.com/download/home/286322286/type/286319236/release/12.5(1)SU1)
   6. Patch CUCM Subscribers to ES1
4. Install 2 Finesse servers (Primary and Secondary). The process is similar to installing a CUCM Cluster.
   1. Create VM from OVA Template. https://software.cisco.com/download/home/283613135/type/284236523/release/12.0(1)
   2. Download Software off Cisco.com https://software.cisco.com/download/home/283613135/type/284259728/release/12.0(1)
   3. Install Finesse Primary
   4. Install Finesse Secondary
   5. Patch Finesse Primary to ES2 (Software here: https://software.cisco.com/download/home/283613135/type/284259728/release/12.0(1)ES2)
   6. Patch Finesse Secondary to ES2
5. Install 2 CUIC (Publisher and Subscriber). The process is similar to installing a CUCM Cluster.
   1. Create VM from OVA Template:
   2. Download Software off Cisco.com: https://software.cisco.com/download/home/282163829/type/282377062/release/12.0(1)

  

1. 1. Install CUIC Publisher
   2. Install CUIC Subscriber

 

You can find the detailed processes for installing each in the appendix.

Running Domain Manager

The steps as documented by Cisco are a little confusing, but once all the servers are built and installed exactly as Cisco lays out for your reference design we are going to follow the Post-Installation section of the following guide:

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/pcce/pcce_12_0_1/maintenance/Guide/pcce_b_admin-and-config-guide_120/pcce_b_admin-and-config-guide_120_chapter_01000011.html#concept_291514BD1360F5F537859669F2CBF0EB

This will show us how to get PCCE installed and configured. The first thing we need to do is log into our AW and run Domain Manager to create the appropriate OU within Active Directory to support CCE. This step is exactly the same as in UCCE. Nothing has changed here. To run the tool, you will need a domain account that has admin permissions on the parent OU that will house the OU generated by CCE. The Domain Manager tool will create this OU based on an instance name you select, as well as a couple child OUs and several security groups – all contained within the generated OU. CCE will not make any schema changes or any changes at all outside of this OU.

To run the tool: Open up the ‘Unified CCE Tools’ on the AW desktop and look for Domain Manager. Alternatively, open up the search toolbar in Windows and start typing “Domain Manager”.

When you run the tool, it will automatically load your domain information. If you’re not seeing this, you probably haven’t added the machines to a domain. Make sure to join every PCCE or CVP Windows server to your domain.

Once open, select the domain, then click Add under Cisco Root in the toolbar on the right. This will add the magic OU named “Cisco_ICM” to the domain where PCCE will house its domain accounts and security groups. The user using Domain Manager does necessarily need to be a Domain Admin, but does need admin rights to the parent OU in which you are creating the ‘Cisco_ICM’ OU. For lab purposes, its easiest to just use a Domain Admin.
After clicking ‘Add’ you’ll have to confirm where the in domain you want the ‘Cisco_ICM’ OU to live. For our lab, we’ll just have it live under the root of cloverhoundlabs.com. In production, you may want to place this within a separate OU (this is the OU to which you need admin rights).

Press ‘OK’ and we’ll see this next screen where we can add a ‘Facility’, which is used to group permissions for multiple PCCE instances (for example: prod, lab and test).

Click add. We’ll just create a Facility named ‘lab’ for our lab:

Click OK and we’ll see this … almost there.

Finally click ‘Add’ under ‘Instance’. This will add an instance which corresponds to a single installation of PCCE. Whatever we enter here will also be the naming convention for our databases, as well as various command line tools. Typically this is a short 3-5 character abbreviation for your company name. For our lab we are going to abbreviate “Cloverhound” and name our instance: ‘clv’.

Click ‘OK’ and we are done! Here is the finished product.

Note on Facility and Instance naming: You can only backup and restore PCCE databases if they have the exact same instance name. If you plan on restoring data from prod to lab or vice versa, then you should name all your instances the same and separate by Facility name (i.e. Facilities named “lab”, “test”, “prod”). This way you can transfer data seamlessly between environments. If however you won’t be transferring databases directly between environments (you can still transfer scripts and import/export configuration via bulk admin tools), then it may be better to name your instances differently (i.e. Instances named “clv”, “clvdev”, “clvtest”) to avoid accidentally applying changes to the wrong environment.

Running the PCCE Installer

After finishing with Domain Manager, the next step is to browse to https://<AW Side A IP>/cceadmin to launch the installer. Note that you do not run the Web Setup tool and add the instance as you do in UCCE.

This brings up a login screen that looks like this:

For setup, you’ll need to use a domain account belonging to the ‘Setup’ security group within the PCCE OU, and with admin privileges on the Windows servers. The username format needs to be entered as: yourusername@yourdomain.com.

In our example, we created an account named ‘ucceadmin’ in the ‘cloverhoundlabs.com’ domain so our username is entered as ‘ucceadmin@cloverhoundlabs.com’. No other format will work. A local Windows account will not work.

Once logged in for the first time you should see a blank ‘Overview’ screen:

Next click the Infrastructure tab and you’ll hopefully see the ‘Deployment Type’ screen. Notice that the Deployment Type dropdown is white and can be selected. This is good!

Every once in awhile you’ll get the exact same screen but the ‘Deployment Type’ is greyed out. This is not so good. It means the installer thinks an install has already been initiated.  It looks like this:

If this happens you’ll need to log into SQL Manager on the AW and find the ‘pcceInventory’ database, delete it entirely, and restart the server. Likely this happens due to accidentally running some install steps manually (see our earlier warnings about not doing this) but in our experience it wasn’t always clear why and we tend to run into this at least once every time. Maybe you will have better luck. If you have run install steps manually make sure to undo them, delete anything you’ve configured that you shouldn’t have, then delete the ‘pcceInventory’ database and restart.

The ‘pcceInventory’ database visible in SQL Studio:

Once working, click the ‘Deployment Type’ dropdown and select your deployment type, then select the instance you setup in Domain Manager:

For this post we’ll be installing the ‘Packaged CCE: Lab Mode’ deployment type.

Building the System Inventory

This step varies significantly between production deployments (2000, 4000, or 12000) agents and lab. At present we only have screenshots here for Lab Mode, but fortunately inventory setup is simpler in production than in Lab Mode.

A production deploy pretty much configures itself. After selecting your Deployment Type, you’ll be asked for your ESXi addresses and root logins. Once provided, the installer will auto-magically discover and configure your entire core inventory (optional components are still added later). From here, it will ask you to enter credentials for the various components.

This is mostly straightforward, except note that when it asks for “Service Account”. If you don’t auto create, you can provide an existing domain account that will be used to run the Logger and Distributor (part of the AW/HDS) Windows services. This account should be created before entering here, and made part of the ‘Service’ security group in the PCCE OU.

Details can be found in the PCCE Administration guide, here:

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/pcce/pcce_12_0_1/maintenance/Guide/pcce_b_admin-and-config-guide_120/pcce_b_admin-and-config-guide_120_chapter_01000011.html#PCCE_TK_CE3C4C26_00

Since a lab build does not require strict VM placement, it cannot auto-discover all your components via ESXi. Instead, it will ask you to upload an inventory spreadsheet, as seen in the screen below. You can configure this by providing an csv file – a template for which can be downloaded from the Inventory page. Note there is a bug (CSCv040197) with the example being wrong for CVP credentials.

Notice that the Download box is greyed out. This is a lie, ignore it and click anyways to download the template file.

Here’s a screenshot of the template example file to give an idea what it’s looking for:

You will need to include one line for each mandatory machine in your environment. Optional components can be added later via the UI.

Most of the fields are self explanatory other than the ‘publicAddressServices’ field. You can find a detailed description of the inventory template format in the PCCE admin guide here: https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/pcce/pcce_12_0_1/maintenance/Guide/pcce_b_admin-and-config-guide_120/pcce_b_admin-and-config-guide_120_chapter_01000011.html

This is the contents of the final file we used in our lab with all the correct formats ( passwords are not real). We saved this as a file named ‘inventory.csv’.

operation,name,machineType,publicAddress,publicAddressServices,privateAddress,side

CREATE,sideA,VM_HOST,172.16.53.127,,,sideACREATE,sideB,VM_HOST,172.16.53.128,,,sideB

CREATE,PCCEROGGERA,CCE_ROGGER,172.16.54.166,,172.16.54.176,sideA

CREATE,PCCEAWHDSDDSA,CCE_AW,172.16.54.162,type=DIAGNOSTIC_PORTAL&userName=ucceadmin@cloverhoundlabs.com&password=cisco,,sideA

CREATE,PCCEAGENTPGA,CCE_PG,172.16.54.160,,172.16.54.170,sideA

CREATE,PCCECVPA,CVP,172.16.54.164,type=CVP_WSM&userName=ucceadmin@cloverhoundlabs.com&password=cisco,,sideA

CREATE,cm1,CM_PUBLISHER,172.16.54.60,type=AXL&userName=admin&password=cisco,,sideA

CREATE,cm1sub1,CM_SUBSCRIBER,172.16.54.68,,,sideA

CREATE,CUICPUB,CUIC_PUBLISHER,172.16.54.64,type=DIAGNOSTIC_PORTAL&userName=admin&password=cisco; type=IDS&userName=admin&password=cisco,,sideA

CREATE,FinessePUb,FINESSE,172.16.54.62,type=DIAGNOSTIC_PORTAL&userName=admin&password=cisco,,sideA

CREATE,PCCEROGGERB,CCE_ROGGER,172.16.54.167,,172.16.54.177,sideB

CREATE,PCCEAWHDSDDSB,CCE_AW,172.16.54.163,,,sideB

CREATE,PCCEAGENTPGB,CCE_PG,172.16.54.161,,172.16.54.171,sideB

CREATE,PCCECVPB,CVP,172.16.54.165,type=CVP_WSM&userName=ucceadmin@cloverhoundlabs.com&password=cisco,,sideB

CREATE,cm1sub2,CM_SUBSCRIBER,172.16.54.69,,,sideB

CREATE,CUICSUB,CUIC_SUBSCRIBER,172.16.54.65,,,sideB

CREATE,FinesseSUB,FINESSE,172.16.54.63,,,sideB

After you upload your file the installer will validate line by line to make sure everything is in the correct format. Fix any errors that appear. Here is what it looks like with errors:

Finishing the PCCE Install

Once the file is validated, the installer will ask you for a domain service account. This is the same as the one described earlier in this section for production builds. For a lab, you can just use your administrator domain account.

Finally from here it’s time to initialize the install. For the duplex install it will run through 33 steps to be completed. If any step fails it will make you revert the changes (it automates this), fix the error and try it again. You can run into a lot of different issues if you don’t follow the steps exactly, or have the right passwords or have enough storage, or breath on it too hard. Also be sure you don’t make any sudden movements or look it directly in the eyes, as it is easily spooked.

It will look like this as it runs through its steps:

If you have any issues the screen will look like this below. In this case, one of the AWs was still turned off.

Once all 33 steps complete successfully you will see this:

Congratulations! The installer has accepted you and allowed the installation to complete. Next you can click ‘Done’ and if you click ‘Overview’, you will see a completely different menu system!

The core PCCE install is complete, but we still have some work to do to get call routing functioning completely. The next step is to add a VVB to so it can process IVR instructions from CVP.

Initializing the VVB

The first thing you’re going to want to do is go to your VVB administrator web page and initialize it. This will happen automatically the first time you log into it. 

DO NOT try to add VVB to the PCCE inventory before doing this, or else it will never initialize properly and you’ll need to reinstall VVB from scratch. You were warned. (Also, keep in mind that VVB does not allow admin usernames to start with “vvb”, you’ll run into problems if you do)

To initialize the VVB, browse to the VVB address in your browser and login, after which you will see this screen:

Wait for all the services to activate and then click ‘Next’. You will see the following screen:

The default settings are typically what you want here. Click ‘Next’ again. From here it will tell you configuration is complete and the VVB Service is restarting. Give it about 10 minutes then continue on with the next step.

Adding the VVB to the PCCE Inventory

One of the nice things about the PCCE SPOG is it has a basic monitoring view, although we’ve found that it isn’t always accurate. To reach the inventory status page, from the SPOG navigate to Infrastructure -> Inventory:

From here you can view your inventory and its status, as well as add optional external components like VVB, CVP Reporting Server, and ECE. Our lab inventory looks like this:

Most of the alerts in our setup are related to the ICM Diagnostic Framework and aren’t particularly important for our lab. However, if I click on Unified CM Publisher the alerts are very useful. We’ll see they are warning us we have no trunks built to CVP, which is needed to deliver calls to agents:

This is because the auto-configuration only adds the “pguser” jtapi user for UCM and nothing else. Everything else in UCM needs to be configured by hand the traditional way. We’ll build these trunks in a later section, but wanted to show that many of these alerts are a useful indication of what’s broken and how it should be fixed. Cisco did a really good job here.

Getting back to the task at hand, back on the main inventory page, scroll down to the bottom where it says ‘External Machines’ with a small “plus” icon. Here you can add VVB servers and other external components.

Click on the “plus” icon to add an external component. This brings up a pop-up asking what type of machine to add. The following choices are available in our lab environment:

To install a VVB (aka Virtualized Voice Browser) you select the ‘Virtualized Voice Browser’ option (surprise, surprise), then enter in the hostname or IP Address of the VVB, and the application username and password, then click save.

After this the VVB is added to the inventory and hopefully everything shows ‘in sync’.

The settings for the VVB can be found in the CCE Admin page at ‘Overview’ -> ‘Infrastructure Settings’ -> ‘Device Configuration’, as shown below:

After selecting Device Configuration you will see the VVB configuration. This is where you configure all your VVBs instead of going to the standard VVB admin page. This is also where you configure CVP as you would have previously done in the CVP Ops Console. We did mention there was no Ops Console in PCCE 12.0 right? Well we’re mentioning it again because its import: there is no Ops Console in PCCE 12.0, do not install one.

In most cases, the default VVB settings are fine. For a simple lab build nothing needs to be changed here, but if you do need to make changes now you know where to go.

Configure SIP Trunks in CUCM

We need to configure SIP trunks in CUCM for the CVPs so that we can deliver calls to agents which are logged in to phones managed by CUCM.

First, from the CUCM admin web page, browse to ‘Device’ -> ‘Trunks’:

Next add a new SIP Trunk:

You need create a separate CUCM trunks for each CVP Server – do not make a single trunk with two destinations. In our case we’ll create two trunks for our two CVP servers. Make sure to set the inbound CSS on the trunks to a CSS that can see the agents’ Line partitions.

A few other tips:

• You’ll also want to make sure you reset the trunks after adding them. If you don’t they won’t work. You have to reset them at least once to put them into service.
• Always check ‘run on all nodes’. This is especially helpful if you have a 5 server or larger CUCM deployment.

We can now see in the PCCE dashboard that we have resolved the missing trunk alert:

Configure CUCM to support internal transfers back to PCCE

Almost every call center is going to want to be able to transfer to agent’s from CUCM back to a queue on PCCE. These are what are known as CUCM PG originated calls. Since they are not CVP originated calls from CUBE we need to program the Network VRU label on CUCM to point back to CVP so it can finish it’s route correlation.

The first thing we need to know is how to find what our Network VRU labels are. They are kind of hidden in PCCE. We are going to go to the SPOG homepage and browse to Overview->Call Settings->Miscellaneous->Main Site. This will show us our Network VRU Labels.

For CUCM it is 8881111000. That means we need to make a corresponding Route Pattern in CUCM in the Agent Partition that points to CVP. This will allow us to get past the Send to VRU node in PCCE scripts and open an RTP channel with CVP.

First we are going to add our CVP SIP Trunks we just made to a Route Group and a Route List so we can reference them in a Route Pattern.

Make sure to reset the route list after creating it and we suggest checking ‘Run on all nodes’ for the Route List’s as well.

Lastly we need to create a route pattern that will allow us to do internal transfers. The 4 X’s represent the 4 digit correlation ID that PCCE prepends by default.

Configure CUCM to actually work

When you go to route calls to agents it’s going to use a sip server group in PCCE which requires you to use the format of an FQDN. It’s a made up FQDN but none the less CUCM needs to be programmed to use it. If you don’t set what is basically a whitelist, CUCM will reject calls. Your going to want to go to CUCM and browse to System -> Enterprise Parameters -> Clusterwide Domain Configuration and set the following to your domain.

Configuring CVP Route plan within PCCE

Since CVP is our call control we need to give it a dial-plan. This previously was done in the CVP Ops Console, but as I mentioned this is no more. We are going to create two routes in PCCE. One for our network VRU label and another for our Agent Extensions.

First we are going to browse our PCCE SPOG page to Route Settings -> SIP Server Groups and create Server Groups for our VVBs and for our CUCMs.

We need to use a FQDN so we will use VVB.cloverhoundlabs.com. Make sure to choose the type of ‘VRU’.

Add your VVB members to the SIP Server Group.

We need to do the exact the same thing for CUCM.cloverhoundlabs.com but this time we use a Type of ‘Agent’.

And for simplicity we will add all our CUCMs to it.

The next step is to create the correct routes for our PCCE/CVP install. Click on the ‘Routing Patterns’ menu option.  Click ‘New’.

First, we are going to create a 77777777> pattern which is the default Network VRU label shipping with PCCE 12. Make sure to choose Pattern Type ‘VRU’ as well. Our only choice will be the VVB.cloverhoundlabs.com SIP Server group we just created.

We’ll also want to add a route for 91919191 and 92929292. CVP dials these numbers to play the ringtone and standard error message. 

Repeat the process for our agent extensions. For our lab we will be using 70XX extensions.

Ingress Gateway Configuration to bring in calls to CVP

The next step is to configure our ingress gateway to send calls to CVP. 

For this config we are using a standard CUBE w/ a SIP trunk from Twilio. Our number for this config is +19802017899. CVP Doesn’t like the + sign on the DNIS numbers so we are going to strip it down to 9802017899. We will make a dial-peer to each CVP server for redundancy.

Confirming the number is reaching PCCE

The best way to check at this point you’ve gotten the number into PCCE through CVP and everything is communicating as it should be is to check the ICM Router Log Viewer Tool.

You can find it in the path of the following screenshot.

If you open the tool you should see your test calls hitting the error section of the tool as shown here.

We are almost there! This means we are good to configure PCCE to treat a call.

Configuring PCCE

The first step is too configure a Call_Type to be the entry point of our script.

We’ll go to the PCCE Web Admin->Overview and choose ‘Route Settings’ in the following box (green):

From here we’ll browse the top right menu to ‘Call Types’ and select ‘New’. We’ll make the following Call Type.

Next we need to create a ‘Dialed Number’ which will match our DNIS of 9802017899 that we are sending too PCCE. Browse to ‘Dialed Number’ and click ‘New’.

Important notes on Dialed Number creation:

• External Voice is for CVP originated calls and Internal Voice is for CUCM originated Calls.
• Make sure to select a call type.
• The Dialed Number String should match the DNIS value you send from CUBE.

Creating a test Script

We are going to use Script Editor to create our first test script in PCCE. We’ll reference the Built In CVP Studio Script ‘HelloWorld’ that ships out of the box for testing your install. You can find the Script Editor utility in the same exact folder you found the Router Log Viewer tool we just used.

Once we get into the utility we are going to want to click the New Script icon. You can also go to File->New.

From here it will ask us if we want to create a ‘Routing’ script or an ‘Administrative’ script. Choose Routing.

The script we are going to create will look like this

Here is a close up of the Set Variable node for our HelloWorld step.

Scheduling our Script

The final step is using Script Editor to map our ‘CVP_Demo’ Call Type to a Script in PCCE. In Script Editor we are going to go to Script -> Call Type Manager.

From here we’ll want to select our ‘CVP_Demo’ call type and map it to the script we just created by clicking the ‘Add’ button.

Give it a test call, it should work!

Let’s configure a few more things to make the install more complete.

Testing calls to agents

In order to test agent functionality we’ll need to configure a few things. The first thing we need to do is create an agent. You can do this by going to Users->Agents and clicking ‘New’ in the SPOG page.

Next, we need to create a Skill Group and assign our Agent. Browse to Organization->Skills and click on ‘New’. Add a skill and make sure to assign your agent as a member. We’ll name our skill ‘Demo_Skill’.

Next, you’ll want to create an agent team. You can find this at Organization->Teams. We’ll name our team ‘Demo’. Make sure to assign your agent as a member.

Finally we’ll want to go edit our script to look like this so we can deliver calls to our new skill and use our HelloWorld app like Music On Hold if an agent isn’t ready.

That’s it. Login in to Finesse and give it a test call. You should recieve the call!

Testing Internal Transfers from CUCM to CVP

As a final bonus we will configure and test an internal transfer point from PCCE.

First we need to create a new Call Type for the transfer. We’ll make a Call Type named ‘Internal_Transfer’.

Next, we need to create a new Dialed Number but this time the type should be ‘Internal Voice’. We’ll use the DNIS 8888 for this.

Now we need to associate the ‘Internal_Transfer’ Call Type to the script we created before.

The last step is to create a CTI Route point in CUCM with the extension 8888 and associate that CTI Route Point to our pguser.

If everything worked out well you should see your CTI Route Point registered to the IP Address of your PG. If it’s isn’t showing registered, it isn’t correct.

That’s it! Call 8888 from your IP phone and you should reach your agent. 

Congrats you’ve installed PCCE v12!

Thanks to Ed Umansky and Clay Scott for helping to build the lab and review this document!