This article covers how to troubleshoot a call that is not showing in the call logs inside Cradle to Grave and/or Call Detail View for CDR data.
Various issues can cause a call to not be logged properly. If Chronicall is displaying an error logging, there will not be any calls captured for that timeframe. Chronicall requires uninterrupted communications between all PBX (phone) servers handling the calls. Also, if there are any missed packets on the network or other networks issues present, that will also lead to a gap of missing data.
Verify Chronicall Version
- First verify Chronicall is up to date, and then follow the below steps to troubleshoot. If you need to update (steps here) be sure to perform a backup first.
- Ensure Chronicall is connected and logging without error as shown below. In some rare instances. It is possible the Chronicall services are running fine, and there is still no call logs coming through.
- If an error is present, use this troubleshooting flow to diagnose the logging issue.
Verify PBX Configuration
- To see what PBX systems we are logging with, navigate to Admin (System) > System Settings > Server Edition.
- This will have a slightly different name for other phone systems but will be in the same spot as shown in the screen below.
- Select the (...) next to the server settings.
- Select the (...) next to each of your PBX configurations. Below, we are only communicating with one Avaya IP Office server.
- Reveiw the server settings inside, to verify all IP addresses and passwords line up with your PBX. You can review the related setup guides here.
Check For Missed Packets
- Missed packet or TFTP errors in the Tomcat logs indicate that there is an issue on the local network, and you will want to have your network administrator diagnose the missed packets if the below fixes do not work.
- Here are the file paths for the Tomcat logs.
- C:\Program Files (x86)\Xima Software\Chronicall\tomcat\logs
- C:\Program Files\Chronicall\tomcat\logs
- /var/lib/Xima\ Software/Chronicall/tomcat/logs
- The Tomcat logs mentioned above should indicate if there are any packets falling off on the network or TFTP errors. Follow the steps below to address any related issues.
Avaya IPO Steps
IP Office 9.0 Fix
- Navigate to File > Advanced Settings > Security Settings.
- On the unsecured interface tab, verify TFTP Configuration Read and TFTP Directory Read are enabled so we get user and trunk data. If not, check them as shown below, then save and merge the changes.
IP Office 9.1 Fix
- Log into Avaya Manager. Select File > Advanced Settings > Security Settings.
- On the unsecured interface tab, verify TFTP Directory Read and TFTP Server are checked so we get the user and phone data.
- Select Services from here, and verify your Service Security Level is set to Unsecure + Secure.
- Navigate back to the main Configuration page, and select Users > No User > Source Numbers.
- Add TFTP_CONFIGURATION_READ to the Source Numbers for No User.
- Save and Merge changes.
IP Office 10.0 Config
- Verify each IP Office you are logging with has a CTI Pro Link license. Each IP Office needs a CTI Pro license to log via TCP based DevLink3 as the monitor connection is no longer a reliable way for Chronicall to monitor UDP traffic in IPO v.10
- If you are on Avaya IP Office 10.0 or newer, verify you are set up for DevLink3 access as shown here.
- Use the Shoretel Multi Line Browser software to see if Shoretels own tool can see the lines loading on the local network. It will freeze up if it is not working.
- This issue seems to lie between Windows and Shoretel servers, as their own tools cannot see the TSAPI lines when down. We have seen Windows Server 2008 provide to be a more reliable connection when compared to Windows Server 2012 and 2016. With that being said, On January 14, 2020, Microsoft will be officially ending its support for Windows Server 2008 R2 editions so please keep this in mind if you decide to roll back the server version.
Shoretel Event Logs
- Compare the Shoretel event logs at the directory listed below to verify listed events match the data stored in Cradle To Grave.
- C:\Program Files (x86)\Xima Software\Chronicall\logs
- C:\Program Files\Chronicall\logs
- /var/lib/Xima\ Software/Chronicall/logs
- If the events match Cradle to Grave, escalate to Shoretel TAC as Chronicall is logging the data Shoretel is sending over, and the adjustments need to be made on the Shoretel side.
Avaya CM Steps
CDR Not Logging
- In the Call Detail View (for CDR data), we recommend trying to Re-Import GEDI exports. You can refer to step 1.4 on the install guide here to review the export and import steps.
TSAPI Not Logging
For Avaya TSAPI data, review the setup here in section 1.5 on the install guide here.
Cisco Not Logging
- Refer to the Verify Connection Settings article to troubleshoot the configuration between the Chronicall and Cisco server.
- If the UCCX is not logging, please refer to this article to troubleshoot UCCX in more depth.
- If the Tomcat logs in the Chronicall directory are showing "Connection Refused" errors, verify that the CTI Manager service is running in the Cisco CallManager Control Center per Cisco's article linked below.
- This link is a direct link to Cisco's website.