If there doesn’t appear to be any recent CUBE CDR data visible (via Call History searches, reports or dashboard widgets) in Variphy, for the current or previous day(s), there could be a few possible causes:
Step 1) Confirm that Variphy CDR Processing is enabled for the CUCM Cluster
Login to Variphy and select CUBE/IOS from the Clusters section in the Setup menu.
Confirm that Enabled appears within the CDR Processing section for the appropriate Cluster – this indicates that CDR Process is enabled for the CUBE Cluster.
If CDR Processing does not show as Enabled, enable CDR processing by clicking the settings Gear on the right and toggle the ‘Enable Database Processing’ button. Follow the steps in the modal dialog that appears.
Step 2) Confirm that Variphy is receiving CDR data files from CUBE into the proper directory on the server to be processed
For the CUBE Cluster, identify the Directory location for which Variphy is expecting CDR data files to be delivered by CUBE.
Navigate to the directory to view the folder contents:
On Windows – open Windows Explorer and navigate to the appropriate directory location
On OVA/Linux – open an SSH session via CLI or an sFTP client and navigate to the appropriate directory location
cd /opt/variphy/data/cisco2901
Since the CUBE FTP cdr delivery is set to run hourly, there may be no files present. However, check the ‘Last Modified’ date on the Progress and Processed directories. If it is not the current day, CUBE cdr files are not being delivered to the Variphy server’s expected data directory.
If running Variphy on Windows, check the FTP server logs on the application server.
If running the Variphy Linux OVA, check the VSFTPD (FTP server) logs on the application server using a CLI or an sFTP client (WinSCP, FileZilla, etc.)
sudo cat /var/log/vsftpd.log
There could be an FTP failure being logged (account credentials, home directory paths, etc.), but more than likely the logging of CUBE’s hourly connections have ceased; meaning CUBE is not attempting to deliver CDR files using the built FTP configuration for Variphy.
At this time, you should disable cdr processing on the CUBE cluster within Variphy. That will allow you to check the data directories on the application server to confirm CUBE is delivering cdr files to Variphy, without the application processor ingesting the data on its routine.
Step 3) Knowing CUBE cdr is not being sent/delivered to Variphy, you will need to access the CUBE via an SSH session with a CLI.
You will need to run some checks and redefine the cdr delivery configuration, as well as bulk copy and delete the cdr files in CUBE Flash.
Check the CUBE flash directory for cdr* files…With the existing FTP connection not functioning properly, cdr* data files will start to pile up in CUBE flash.
show flash:
Check the configuration of the cdr delivery job in CUBE
sh run | begin gw-accounting file
Run a ‘push now’ command from CUBE to Variphy
file-acct flush with-close
Check the corresponding home data directory on the application server.
If a file shows up, you have successfully validated that the CUBE and Variphy Server can communicate.
Let’s restart the FTP push to run on it’s schedule timeframe by executing a “file-acct reset”. (This does not reset the configurations, only rests the automatic push of files)
file-acct reset
the hourly job will now resume on its own – check Variphy in 1hr for confirmation of newer data delivered for today.
If no files have shown up within 1 – 2 minutes, it may be necessary to remove the cdr FTP job (GW-Accounting File) in CUBE and redefine.
config t
no gw-accounting file This will remove the hourly cdr FTP job
exit
sh run | begin gw-accounting file Confirms the job has been removed by returning no results
Redefine the cdr FTP job in CUBE (CUBE Cluster Configuration)
CUBE Analytics Setup and Configuration
enable
configure t
gw-accounting file
primary ftp 10.20.30.180/cdr username cisco2901 password Variphy!!
maximum cdrflush-timer 55
maximum fileclose-timer 60
cdr-format detailed
acct-template callhistory-detail
end
wr mem
Once the configuration is finished building, check the application data directory for a delivered cdr file; this should be quick. (If no cdr file shows up in the data directory, there may be a firewall or some security measures preventing delivery – FTP port 21)
Now that cdr files are being delivered again, the hourly job/routine will take over moving forward.
However, we still need to copy/delete the cdr files in CUBE’s flash over to Variphy. Certainly do not want the CUBE flash filling up due to cdr files.
At this point, you will want to use the TCL (Tool Command Language) shell that is built into CUBE.
This will allow the bulk copy of cdr* files ONLY, and not all of flash.
config t
file prompt quiet
exit
tclsh
set fileList [glob -directory flash: -nocomplain "cdr*"] creates a bulk list of cdr* files only
foreach file $fileList {copy $file ftp://cisco2901:Variphy!!@10.20.30.180} copy command delivers the cdr files from CUBE flash to Variphy’s FTP server
Re-enable file prompting protection in the global configuration:
config t
file prompt alert
exit
wr mem
OPTIONAL – if you want to copy the files to a TFTP server, and then upload to Variphy
foreach file $fileList {copy $file tftp://10.20.50.228}
exit
CUBE cdr* files from flash should have been copied over FTP to the data directory in the application server.
Optional (TFTP Server copy)
Now that you have copied all the cdr* files from CUBE flash over to Variphy, you will have to delete those files from CUBE flash.
delete /force flash:/cdr*
Confirm all the cdr* files that were copied over to Variphy are no longer in CUBE flash
show flash:
Lastly, re-enable the cdr processing on the CUBE cluster in Variphy
Give the application a few minutes to process those missing files, then refresh your Variphy history searches, reports and/or dashboard widgets. All missing data should be present now.
