Submit a ticketCall us

Have You Auto Renewed? If not, you're missing out.
The SolarWinds Renewal Program comes with a host of benefits including the most recent product updates, 24/7 technical support, virtual instructor-led training and more. Experience all of this with the convenience of Auto Renewal, and never worry about missing any of these great benefits. Learn More.

Home > Success Center > VoIP & Network Quality Manager (VNQM) > 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 June 2nd, 2016

Overview

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 [Server:ftp.server.info], [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

Environment

VNQM version 4.x with Cisco Call Managers

Cause 

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. 

Resolution

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 ftp.example.com, substituting the domain name or IP address of where you are connecting. For     example, open 192.168.1.12.
    • 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 1.3.6.1.4.1.9.9.156.1.1.2.1.8 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.

 

 

Last modified

Tags

Classifications

Public