Submit a ticketCall us

whitepaperYour VM Perplexities Called, and They Need You to Read This.

Virtualization can give you enormous flexibility with future workloads and can be a key enabler for other areas, like cloud computing and disaster recovery. So, how can you get a handle on the performance challenges in your virtual environment and manage deployments without erasing the potential upside? Learn the four key areas you need to be focusing on to help deliver a healthy and well-performing data center.

Get your free white paper.

Home > Success Center > VoIP & Network Quality Manager (VNQM) > VNQM - Knowledgebase Articles > Missing call records (CDR files) in VNQM when working with an FTP

Missing call records (CDR files) in VNQM when working with an FTP

Updated November 7, 2018


This article provides brief information and steps to resolve the issue when call records or calls are not reported on Cisco Call Managers. 


Issue I

No error appears, and the logs look like they run fine, and just do not find any files.


Issue II

  • ERROR SolarWinds.Orion.IpSla.Jobs.Ftp.CiscoCcmFtpJob - Failed. FTPServer=*FTPINFO*,Duration=00:00:00]

   SolarWinds.Orion.IpSla.Jobs.Ftp.IpSlaFtpException: Server returned an error: Bad message --->      WeOnlyDo.Exceptions.FtpDLX.ServerException: Server returned an error: Bad message


Issue III

  • INFO SolarWinds.Orion.IpSla.Jobs.Ftp.CiscoCcmFtpClient - CDRFTP - Getting sorted file list [], [Directory:/directoryroot]

   2016-01-22 12:45:25,106 [48] WARN SolarWinds.Orion.IpSla.Jobs.Ftp.CiscoCcmFtpJob - CDRFTP -        Finishing job due internal timeout...
   INFO SolarWinds.Orion.IpSla.Jobs.Ftp.FtpDLXIpSlaFtpSession - Disconnecting by request from          outside
   WARN SolarWinds.Orion.IpSla.Jobs.Ftp.CiscoCcmFtpJob - CDRFTP - Job finished...
   WARN SolarWinds.Orion.IpSla.Jobs.Ftp.FtpDLXIpSlaFtpSession - Exception occured on                  GetFilesInDirectory Method: 
   System.Net.Sockets.SocketException (0x80004005): An existing connection was forcibly closed by      the remote host


Issue IV


  • FTP credential test fails


VNQM version 4.x with Cisco Call Managers


The following are causes for the issue:

Issue I

  • This issue occurs when the FTP path is bad or the sequence numbers are out of order.


Issue II

  • Bad file name/data.


Issue III

  • The FTP job cannot complete the directory listing due to the size of the directory. 


The following are ways to resolve the issue:


Issue I. 

  1. Test FTP credentials from the Edit Node page in VNQM, by going to VOIP & Quality Settings > Manage Call Manager and selecting the call manager to edit. 
  2. If they fail, verify they are correct to FTP. If they appear correct, try accessing FTP via command prompt.
  3. Type open, substituting the domain name or IP address of where you are connecting. For     example, open
    • Note: By default, the open command uses the TCP port 21 to make the FTP connection. If a different TCP port is needed to connect to the domain name or IP address you are using, enter the port number after the domain name or IP address in the open command.
  4. Once connected, a username and password prompt will appear Enter your credentials. You should now be able to     browse, send, or receive files, depending on your rights. Some servers may also allow anonymous logins using guest or an e-mail address.
  5. Check the file path the call records are store in using the dir command to verify files are present, if not the same in the web console correct it.


Note: If the above checks out follow the article below to verify there is not a sequence number issue. 

Resetting CDR sequence numbers


Issue II.

  1. Check files in FTP, note the file name specifically the cluster name IE: cdr_standalonecluster_01...
  2. Check the CCMmonitoring table in the Solarwinds Database and verify the ClusterName column matches the     standalonecluster section of the filename listed above.
  3. If they do not match, remove the Call Manager from VNQM and re-add it to see if it will re-sync.
  4. Recheck the CCMmonitoring table if it still shows bad data then continue if not it should be resolved.
  5. If not, perform an SNMPwalk and verify that what is being returned for the OID it should match the standalonecluster from the file name, if it does not match the customer needs to work with  Cisco to clear the stale data or fix the mismatch. 


Issue III.

  1. Log into the FTP itself.
  2. Clear files from the FTP either by deleting them or moving them to another folder (customer choice here).
  3. Recommend customer enable the CDR polling job to delete the CDR records after download.
  4. Log  into the Orion Web console. 
  5. Click Settings in the top right.
  6. Click on VoIP & Quality Settings.
  7. Click on Manage Call Managers.
  8. Check a Call Manager and click Edit. 
  9. Check the box to delete after download.


Issue IV

  1. Check if S/FTP is up and running
  2. Verify if the user for the S/FTP can really access the S/FTP site
  3. Check if S/FTP service is up and running



Last modified