Enabling CUBE or vCUBE Data

Cisco Contact Center gives you great visibility for Contact Center, and products like ours give you great visibility into CallManager…

…but have you noticed there’s a CUBE-sized blind spot in your picture of overall call flow?

Lucky for you, we can make sense of this data now. All the H.323 and SIP traffic, media streams (both RTP and RTPC), all the handoffs to DTMF and all the other things that CUBE and vCUBE can do – we shine a flashlight into that darkness and let you start using that data as part of the overall picture you can get from our Cisco CDR Reporting and Analytics app.

Prerequisite information and notes

We are going to assume that:

• you have set up our product already following our install docs and you have an SFTP server running on a Splunk Universal Forwarder (UF).
• that this UF is on a Linux box of some sort and that you some basic comfort with a *nix command line,
• that your existing UF configuration is indexing the CallManager CDR and CMR using a sinkhole input,
• that you can install software on that system,
• that you will use your existing SFTP user account on that system for the new CUBE CDR data
• and that you have admin access to your CUBE system or can find someone who does to run a half dozen commands for you.

The steps that we will perform to enable ingesting CUBE CDR data are:

• Install an FTP server on the existing *nix UF
• Configure vCUBE/​CUBE to save CDR data to that FTP server
• Reconfigure the existing UF to pick up that new data.

Step 1, Setting up an FTP server

CUBE/​vCUBE (from now on I’m just going to write CUBE since it covers both products) only supports FTP as far as we can tell. This means that the standard and recommended method we use for collecting CDR data from CallManager – SFTP – can’t be used with CUBE.

There are many FTP packages that you could use and practically any of them should work fine. If you don’t have one installed already, then follow along below to get some guidance on getting FTP up and running.

Find which distribution you are using:

If you already know the Linux distribution installed on your UF (Red Hat Enterprise Linux, Ubuntu, Slackware, etc…) you can skip this step.

1. Log into an SSH session on the existing UF.
2. Run the one line command cat /etc/*-release
3. In the output, you’ll see either a release name like ​“Red Hat Enterprise Linux”, or somewhere in the output may be a ​“Description” field that says ​“Ubuntu 16.04 LTS”. Yours may say something completely different, like Debian or Slackware. Just note what it says.

Install the FTP server software

This step is distribution specific, so if you don’t know which distribution you are using please see the section immediately above this one, then come back here.

For Ubuntu, follow setting up an FTP server on Ubuntu. You’ll only want the steps vsftpd – FTP Server Installation and User Authenticated FTP Configuration – DO NOT set up Anonymous FTP! Also be very careful to not accidentally set the anon_upload_enable=YES flag, which for some reason is stuck in the middle of the Authenticated FTP configuration section.

For Red Hat and its various versions you can follow these instructions on setting up an FTP server on Red Hat.

Other Linuxes (Linuxen? Linuxii?) – just search the internet for “<my distribution> FTP server” and try to find the most ​“official” looking instructions you can to enable non-anonymous FTP. If you check out the two directions linked above you can get a feel for what that might look like.

Also, if you have a preference for an FTP server you are comfortable with, by all means use it instead of our instructions. It won’t hurt our feelings.

Confirm the FTP server works

You can use any ftp client you have available to confirm this. Preferably one on a different system so you can confirm there’s no firewall on the local system blocking you.

We recommend creating a temporary file with any content you want and confirming

1. You can upload that file using the username and password for the existing SFTP user
2. That the file ends up where you expect it to be

If you have any problems at this point, review the installation steps you used to install and also confirm there’s no firewall either between you and the FTP server or on the local FTP server itself. If so, adjust the firewall settings to allow FTP traffic.

Step 2, Configuring CUBE to save CDR data to our FTP server

Log into the server used for file accounting (e.g. your CUBE server) with an account with administrative permissions. Then run the below listed commands to set up gw-accounting to file, change the cdr-format to ​“detailed”, configure the ftp server information, and tell the system to flush new data to file once per minute. Finally, we make sure this configuration gets saved.

1. enable
2. configure terminal
3. gw-accounting file
4. cdr-format detailed
5. primary ftp <em>10.0.0.100</em>/cube_ username <em>cdr_user </em>password <em>cdr_user_passwd</em>
6. maximum cdrflush-timer 1
7. end
8. copy running-config startup-config

Step 5 is the one to pay attention to! In step 5 be sure to change the information for your server IP, username and password. Also notice that in step 5 the cube_​in 10.0.0.100/cube_ is the file prefix. The FTP software will put the file into the right place in the directory structure, the cube_​piece here tells it to prepend the word ​“cube_​” to the front of the filename it creates. This is later how we’ll tell the UF to pick up that data specifically.

To confirm, from that same SSH session to your CUBE server run the command file-acct flush with-close. You should see a new file nearly immediately appear in your FTP folder. This file might be nearly empty with only a timestamp in it if there were no phone calls in the short period involved, but in any case it should be there.

Step 3, Tell the UF to index this data

The UF needs only a few tiny pieces of configuration. There should already be a working configuration for indexing the Cisco CDR data via the TA_​cisco_​cdr app and its inputs.conf file. We will now edit that to get our new data files to be sent in as well

1. Edit your $SPLUNK_HOME/etc/apps/TA_cisco_cdr/local/inputs.conf file
2. You’ll see two stanzas already for your existing CDR data, with sourcetypes of cisco_​cdr. (If you do not see those two stanzas, you are in the wrong place. Check other inputs.conf files on that system. )
3. Go to the end of the file and add a third entry that looks like:

   [batch://<b>/path/to/files/cube_</b>*] 
   index = <b>cisco_cdr</b> 
   sourcetype = cube_cdr 
   move_policy = sinkhole 
   

4. Save the file
5. Restart the UF.

Finalizing

Now that you have this data in, for all CallManager calls where we recognize the matching CUBE record(s), the fields from those CUBE events will be available in the field picker popup, in ​“Browse Calls”. To talk about desired functionality in other parts of the app (notably General Report), and about your needs in general give us call. We can help in the short term even if it’s a bit manual for now, and we’ll be very interested to hear all the messy details to help guide our next few releases as we flesh this out. It’ll be fun!