This document is applicable to the appliance model of Cisco Unified Communications Manager (i.e. CUCM version 5.x and later).   Recommended reading It is highly recommended to read the "Understanding CDR (Call Detail Records)" document at the following location to get a good background of CDR operations: https://supportforums.cisco.com/docs/DOC-13842   How to check the current CDR records and CDR configuration   Starting with CUCM 7.1.3 release, users get a pop-up message when they login to CAR (from Cisco Unified Serviceability, go to Tools > CDR Analysis and Reporting ). The pop-up message provides an overview of the CDR configuration as well high level overview of number of records in CDR database.   Sample screenshot:       The above information is very useful because you can see the time period that the CDR records cover. In the above example, the oldest CDRs are from Jan 4th and the latest CDRs are from Jan 5th. If you are trying to run reports for any days that are not included in this time period (eg: Jan 3rd or before -- or -- Jan 5th and later), it'll be unsuccessful because the corresponding data is not available in the database.   Prior to CUCM 7.1.3, the above pop-up message is not available. In that case, an alternate way to check the current records is:   From Cisco Unified Communications Manager CDR Analysis and Reporting page, navigate to System > Database > Manual Purge as seen in the screenshot below:       On the next page, click on Table Information:     A new pop-up window displays:     Using the Event Log   The Event Log is a handy tool to check the CDR Load status.   From Cisco Unified Communications Manager CDR Analysis and Reporting page, navigate to System > Log Screens > Event Log as seen in the screenshot below:   Then, select the ‘CDR Load’ job and specify the search interval as required as seen below:         The Event Log output is then displayed:             Important: If a DRS backup starts while CDR Loading is in progress, then the CDR Load status shows "Unsuccessful" in the Event Log output. In this case, the "Unsuccessful" status is cosmetic. Refer to CSCsy90529 in Cisco's Bug Toolkit for additional details.       Troubleshoot: Unable to search CDR data / Unable to view CDR records   Problem: I can't search CDR records or generate reports for a particular date.     Approach:   (1) Check if the CDR Enabled Flag is enabled in CallManager service parameters.   (2) Is CDR Load enabled ? (From CAR Tool: System -> Schedule -> CDR Load). Click here for screenshots.   (3) Using the Event Logs, check if the loader is running properly. Click here for screenshots.   (4) Check the current records in CDR as explained here. Does the date that you are searching for fall within the range between oldest and the latest records ? Most likely, the particular date will not be included in this range.   (5) Check the 'preserve' and 'processed' folders on the Publisher for CDR flat files. Click here for further information.   If you don't observe files in either the 'preserve' or the 'processed' location for the specific date, then it means that problem does not reside on the Publisher. Either the CDR records were not generated by the server that handled the call or it could mean that CDR Agent service on that server could not transfer flat files to the Publisher. Was the 'CDR Enabled Flag is enabled in CallManager service' enabled on that particular date ? Is the CDR Agent service running on the node that handled the call ?   For the particular date, if the CDR files exist in the 'preserve' location, but not in the 'processed' location, then it means that the files have not been processed yet.     (5) For what date is the CDR Loader processing data ?  Check the current records in CDR as explained here. Wait few minutes and check the current records in CDR again.   Did the Total records change between the iterations?   ---> If yes, then it means that the CDR Loader is running and processing data.The date of the latest record will provide an indication of the day for which the records are being processed.  If the date that you are searching for falls beyond the latest date, then you may need to wait for a while to provide time for the CDR Loader to process all the data leading upto that date.   ---> If not, it means that CDR Loader may not be running (try restarting the CAR Scheduler service on the Publisher). If you don't observe any additional records being processed, then set the trace level for the CAR Scheduler service to 'Debug', restart CAR Scheduler service, wait 10 mins, download CAR Scheduler logs via RTMT and engage Cisco-TAC for further troubleshooting.     Troubleshoot: CDR Files not being transfered to billing server     Problem: CDR flat files are not being transfered to the billing server.   Approach:           (1) Confirm that the billing server is configured correctly (verify the IP address). From the Cisco Unified Serviceability page, navigate to Tools > CDR Management to view the billing server parameters.           (2) Check if you can ping the billing server from the Publisher. From the Publisher CLI, you can use the following command:   utils network ping a.b.c.d    where a.b.c.d is the IP address of the billing server         (3) Check if the FTP (or SFTP) service/software running on the billing server.       (4) Check if the billing server is running out of disk-space.       (5) Check if the CDR Respository Manager service is running on the Publisher. If not, start the CDR Repository Manager service.       (6) On the Publisher, check the 'preserve' and 'destinationX' (X can be 1, 2 or 3) directories for CDR flat files. For example: if transfer of CDR files to billing server is broken from Jan 6th, then use the following commands:       file list activelog /cm/cdr_repository/preserve/20110106       file list activelog /cm/cdr_repository/destination1/20110106     (if multiple billing servers are configuration, the location will be similar to above, but the corresponding directories will be named destination2, destination3). This location contains symbolic links to files under preserve. CDR Repository Manager service uses these soft-links to determine what files need to be transfered to billing server.       If you don't observe files in either the 'preserve' or the 'destinationX' locations for the specific date, then it means that problem does not reside on the Publisher. Either the CDR records were not generated by the server that handled the call or it could mean that CDR Agent service on that server could not transfer flat files to the Publisher. Was the 'CDR Enabled Flag is enabled in CallManager service' enabled on that particular date ? Is the CDR Agent service running on the node that handled the call ?   If you observe files in the 'preserve' directory for the specific date, try restarting the CDR Repository Manager service on the Publisher. If the file transfer to the billing server does not commence, then set the trace level for the CDR Repository Manager service to Debug, wait 10 minutes, download CDR Repository Manager logs via RTMT and engage Cisco-TAC for further troubleshooting.       Troubleshoot: Alerts     CDRAgentSendFileFailed   This alert gets raised when the CDR Agent cannot send CDR files from a Cisco Unified Communications Manager node to a CDR repository node within the Cisco Unified Communications Manager cluster. This typically occurs when a Subscriber server is unable to send the CDR flat files to the Publisher.   Approach:   - Have there been any changes in the network connectivity between the Publisher and the Subscriber due to which SFTP traffic (port 22) may be getting blocked ?   - Try restarting CDR Agent service running on the Subsriber server for which the alert was raised.   - If the alert continues, change the debug trace level for the CDR Agent service on the Subscriber to 'Debug'. Wait 10 minutes. Download the CDR Agent service logs using RTMT. Check for errors in the file. You may need to contact Cisco TAC for further assistance.     CDRFileDeliveryFailed   This alert gets raised when FTP/SFTP delivery of CDR files to the outside billing server fails.   Approach:   This alarm signifies that there are CDR flat files in the /cm/cdr_repository/preserve/YYYYMMDD location on the Publisher, however the CDR Repository Manager service is unable to transfer these files to the billing server.  Troubleshoot approach is same as here. https://supportforums.cisco.com/docs/DOC-14548#Troubleshoot_CDR_Files_not_being_transfered_to_billing_server     CDRHighWaterMarkExceeded   This alert gets raised when the high water mark for CDR files gets exceeded. It also indicates that some successfully processed/delivered CDR files got deleted.   This alert will be thrown if the High Water Mark (HWM) configured on the CDR Management page is exceeded. To access the CDR Management page, from Cisco Unified Serviceability, navigate to Tools > CDR Management.   Whenever HWM is exceeded, CDR Repository Manager deletes the oldest processed folders one by one, till the usage goes below the Low Water Mark (LWM). There is no action required for this alert, unless the CDRMaximumDiskSpaceExceeded alarm is also observed.     CDRMaximumDiskSpaceExceeded   This alarm gets raised when the CDR files disk usage exceeds the maximum disk allocation. It also indicates that some unprocessed/undelivered files got deleted. As explained in the 'CDRHighWaterMarkExceeded' section, whenever HWM is exceeded, CDR Repository Manager deletes the oldest processed folders one by one, till the usage goes below the Low Water Mark (LWM).  If all the processed folders are deleted, but still the disk usage is higher than HWM and maximum disk alloacted on the CDR Management page, the CDRMaximumDiskSpaceExceeded alarm is thrown and CDR Repository Manager starts deleting the files from oldest preserve folders till the disk usage goes below HWM. This situation is not ideal because the system may delete CDR files before they were transferred to the sftp server or processed by local CDR Loader job.   Note - in typical working scenarios, all the CDR flat files will in the 'processed' location as opposed to the 'preserve' location. This signifies that all operations for those files have been completed.   So, the main aspect to troubleshoot is - why do the preserve folders contain data to begin with ? Is it because the CDR Files are not being sent to the configured billing servers and/or is it because the files are not being processed by the local CDR Load job on the Publisher ?     Troubleshoot: Numerous Entries in tbl_billing_error   Problem: There are numerous entries in tbl_billing_error. What’s causing it ?   Approach:   The following commands will work on CUCM version 5.x, 6.x and 7.x. For CUCM 8.x and later, please click here to get the corresponding commands.   Login to the Publisher's command line interface (CLI).   Check the error codes in tbl_error_id_map. Sort the list such that error codes that occur most often are listed in descending order.     admin:run sql select count(*) as cnt, error_code from car:tbl_error_id_map group by error_code order by cnt desc cnt error_code === ========== 24  31110 14  31148       Check what devices are causing the errors:     admin:run sql select count(*) as cnt, origdevicename from car:tbl_billing_error where datetimeconnect = '0' group by origdevicename order by cnt desc cnt origdevicename === =============== 12  SEP000BFDCDB25A 9   SEP001BD52D292D 3   SEP001D45B64090     In the above example, the error codes are:   31110: which means that dateTimeConnect in a CDR record is not a positive integer   and   31148: which means that destDeviceName in a CDR record is NULL     The above error codes imply that the call was not connected (i.e. it did not enter a connected state) but a CDR record was nevertheless created for it. Since the call was not connected, it's not a 'billable' call. Hence, the corresponding record is entered into tbl_billing_error (as opposed to tbl_billing_data). This behavior is frequently observed on systems where the CallManager service parameter: 'CDR Log Calls with Zero Duration Flag' is enabled. If this service parameter is entered, a CDR record will be generated for calls that were never connected or were connected for less than a second. Most common scenarios that cause such CDR records:   - When a user goes off-hook and then on-hook without completing a call. - When a user completes a blind transfer (the consultation call does not connect prior to transfer completion). - MWI On/Off calls.     If you observe a large number of entries in tbl_billing_error due to any of above scenarios, you can disable the CallManager service parameter: 'CDR Log Calls with Zero Duration Flag'.   A complete list of error codes and corresponding meanings is listed below:   Error code meaning:   31101: CDR's globalCallID_callManagerId <= 0 31102: CDR's globalCallID_callId <= 0 31103: CDR's origLegCallIdentifier <= 0 31105: CDR's dateTimeOrigination <= 0 31108: CDR's destLegIdentifier <= 0 31110: CDR's dateTimeConnect <= 0 31111: CDR's dateTimeDisconnect <= 0 31119: CDR's originalCalledPartyNumber is empty 31120: CDR's finalCalledPartyNumber is empty 31122: CDR's duration < 0 31137: CDR's Ldap error while retrieving UserID or ManagerID 31139: CDR's callingPartyNumber is empty 31147: CDR's origDeviceName is empty 31148: CDR's destDeviceName is empty 31151: CDR's origCallTerminationOnBehalfOf < 0 31152: CDR's destCallTerminationOnBehalfOf < 0 31153: CDR's lastRedirectRedirectOnBehalfOf < 0 31155: CDR's destConversationId < 0 31156: CDR's globalCallId_ClusterID is empty     ** Corresponding CLI commands for CUCM 8.0   In CUCM 8.0 and later, the tbl_billing_error and tbl_error_id_map tables have been consolidated. The syntax of the CLI commands has also changed slightly from previous version. Use the following CLI commands from the Publisher:   run sql car select count(*) as cnt, error_codes from car:tbl_billing_error group by error_codes order by cnt desc   run sql car select count(*) as cnt, origdevicename from car:tbl_billing_error where datetimeconnect = '0' group by origdevicename order by cnt desc     Important: CallManager always generates CDR data for calls that have a duration of 0 seconds and terminate because of an error condition of some sort, regardless of the setting of the CDR Log Calls with Zero Duration Flag service parameter. Calls to busy destinations or bad phone numbers are examples of this type of call. The duration of these calls is 0 because they were never connected, but their CDRs are generated anyway. In short -  if a call terminates abnormally, the corresponding CDR record will be created irrespective of the setting of the CDR Log Calls with Zero Duration Flag service parameter.     Reporting: Important limitations   All reports (User Reports, System Reports, Device Reports) are generated based on data in tbl_billing_data only.     For CAR (CDR Analysis and Reporting) reports:   - If CSV format is selected, it the report search is limited to 20,000 records   - If PDF format is selected, it the report search is limited to 5,000 records   The above limitation is documented in the Cisco Unified CDR Analysis and Reporting Administration Guide. Unless the CUCM version contains the fix for CSCsm17901, the system does NOT display any notification to the user that the report results may not be accurate if the above limits are violated.   Consider the following example to better understand this:   - Assume 1000 records are populated in tbl_billing_data each day. - So, for the month of January, there'll be 31000 records in tbl_billing_data (1000 records per day * 31 days = 31000 records).   Lets say a PDF report is generated for period from Jan 1 to Jan 10th. In this case, the search should ideally span 10000 records (1000 records per day * 10 days = 10000 records). However, a PDF report is limited to search only 5000 records. In this case, the report results will not be accurate since the total number of records in the search period are greater than 5000! However, if you an CSV report is generated, then the report results will be accurate since the corresponding search can span upto 20000 records.     General Tips   When you add calling and called party transformations to a route pattern or translation pattern, CallManager logs the transformed numbers in the CDRs and renders the transformed numbers on the display of the calling phone. CallManager does not insert transformations specified on the route list’s route group details (or applied by a individual egress gateway) in the CDRs or render them on the calling device.   Using the CDR Search option (under System -> CDR) will search the records in both tbl_billing_data and tbl_billing_error. Only the first 100 matches will be displayed.     Useful Links/References   Please refer to the 'Cisco Unified CDR Analysis and Reporting Administration Guide' for the appropriate release for additional information. To access the document:   -- Navigate to: http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html -- Search for 'Cisco Unified CDR Analysis and Reporting Administration Guide' for the appropriate CUCM release   Understanding CDRs (a document on Cisco's supportforums) ... View more

CDR - Test Document       Overview This document is applicable to the appliance model of Cisco Unified Communications Manager (i.e. CUCM version 5.x and later).   What is CDR, CMR ?   Cisco Unified Communications Manager produces two types of records which store call history and diagnostic information, as follows:     Call detail records (CDR)— Data records that contain information about each call that was processed by CallManager . Call management records ( CMR )— Data records that contain quality of service ( QoS ) or diagnostic information about the call. Also referred to as diagnostic records.       Both CDRs and CMRs together are referred to as CDR data. CDR data provides a record of all calls that have been made or received by users of the CallManager system. CDR data is useful primarily for generating billing records; however, it can also be used for tracking call activity, diagnosing certain types of problems and capacity planning.   CDRs contain information about call origination, call destination, the date and time the call was started, the time it actually connected, and the time it ended. A call is considered started or originated when the caller goes off-hook. The call is considered ended when either the caller or the called party goes on-hook. CMRs contain information about the amount of data sent and received, jitter, latency, and lost packets.   Logging Calls With Zero Duration   A CallManager service parameter called 'CDR Log Calls with Zero Duration Flag'  determines whether CDRs for calls that were never connected or were connected for less than a second are generated. Examples:   When a user goes off-hook and then on-hook without completing a call. When a user completes a blind transfer (the consultation call does not connect). MWI On/Off calls.     Note: The CDR Log Calls with Zero Duration Flag service parameter is valid only when the CDR Enabled Flag service parameter is set to True. If CDR generation is disabled, the setting of the CDR Log Calls with Zero Duration Flag service parameter has no significance.   CallManager always generates CDR data for calls that have a duration of 0 seconds and terminate because of an error condition of some sort, regardless of the setting of the CDR Log Calls with Zero Duration Flag service parameter. Calls to busy destinations or bad phone numbers are examples of this type of call. The duration of these calls is 0 because they were never connected, but their CDRs are generated anyway.   CallManager does not generate CDRs for calls that terminate normally and have a duration of 0 seconds, unless the CDR Log Calls with Zero Duration Flag service parameter is set to True. When CDR generation is enabled, CallManager generates a CDR for each call that was connected for 1 second or more.   Configuration Enabling CDR   Enabled via CallManager service parameters.            Under System -> Service Parameters          Select a server from the drop down box and then select the CallManager service          Set the ‘CDR Enabled Flag’ to True     Needs to be enabled per server basis.   The default value specifies False           Enabling CMR   Enabled via CallManager service parameters            Under System -> Service Parameters          Select a server from the drop down box and then select the CallManager service          Set the ‘Call Diagnostics Enabled’ parameter to either:     Enabled Only When CDR Enabled Flag is True (generate CMRs only when the CDR Enabled Flag service parameter is set to True).         ---- or ----         Enabled Regardless of CDR Enabled Flag (generates CMRs without regard to the setting in the CDR Enabled Flag service parameter).     This is a clusterwide parameter.         The default value specifies Disabled.   Enterprise Parameters   Under System -> Enterprise Parameters, there are two parameters related to CDR:   CDR File Time Interval This parameter specifies the time interval for collecting CDR data. For example, if this value is set to 1, each file will contain 1 minute of CDR data ( CDRs and CMRs , if enabled). The CDR database will not receive the data in each file until the interval has expired, so consider how quickly you want access to the CDR data when you decide what interval to set for this parameter. The minimum value is 1 (which is also the default). Maximum is 1440. The unit of measure for this required field represents a minute.   Cluster ID This parameter provides a unique identifier for the cluster. Because the parameter gets used in CDRs , collections of CDRs from multiple clusters can be traced to the sources.The default value specifies StandAloneCluster . The maximum length comprises 50 characters andprovides a valid cluster ID that comprises any of the following characters: A-Z, a-z, 0-9, . -.     Architecture   Services CallManager Can be activated on any node in the cluster. Performs call processing and writes CDR, CMR data into flat files. The flat files are generated at a frequency determined by the ‘CDR File  Time Interval’ flag under Enterprise Parameters.   CDR Agent Runs as a network service on every node in a cluster (including the Publisher). It polls the local directory for CDR, CMR flat files every 6 seconds. If finds new CDR, CMR flat files, it pushes CDR, CMR flat files from that   node to the CDR Repository node (Publisher). Upon successful transfer, the system deletes the local copy of the file.   CDR Repository Manager It runs as a Network Service on all nodes in a cluster. But, in reality only the CDR Repository Manager on the Publisher performs any actions. On all other nodes, the service simply starts up, but then goes to sleep. It creates the directory structure used by CAR services. It manages the flat files that are received from other nodes. When the file arrives on the CDR Repository node, the CDR Repository Manager detects it.The system archives the file in a directory that is dedicated to the date that is indicated by the timestamp that was placed in the file name when the file was created. Sends CDR files up to three outside billing servers. Maintains CDR files for a certain number of days, up to 30 days. Periodically check the disk usage and delete old files. The thresholds are configured using the CDR Management (covered later in the presentation). Generate alarm if delivery failed, or disk usage too high.   CAR Scheduler It runs as a Network Service on all nodes in a cluster. But, in reality only the CAR Scheduler service on the Publisher performs any actions. On all other nodes, the service simply starts up, but then goes to sleep. Based on the CDR loading schedule, it accesses the CDR/ CMR files in the directory structure that the CDR Repository Manager service creates , processes these files and inserts the CDR information into the CAR database. The maximum size of CAR database is 6 Gb (not configurable). The CAR Scheduler purges data from the CAR database if it exceeds 6 Gb or if the number of records exceed 2 million. The two million record limit includes data in both tbl_billing_data and tbl_billing_error .     CAR Web Service Can only be activated on the Publisher. Runs as a feature service (Control Center – Feature Services). It needs to be running in order to access the CDR Analysis and Reporting (CAR) tool.   SOAP - CDRonDemand Service     The CDRonDemand Service is a SOAP/HTTPS-based service that runs on the CDR Repository node (i.e. Publisher). It receives SOAP requests for CDR file name lists from a third-party server based on a user-specified time interval (up to a maximum of 1 hour) and returns all lists that fit the duration that the request specifies. The CDR onDemand Service can also handle requests for delivering a specific CDR file to a specified destination through (s)FTP. The system can activate the CDR onDemand service on the CDR Repository node as it has to access the CDR files in the repository. There are two relevant parameters under System -> Enterprise Parameters that are used to throttle requests from the third party server:   Allowed CDRonDemand get_file Queries Per Minute ( Min:1 , Max:20 , Default: 10) Allowed CDRonDemand get_file_list Queries Per Minute ( Min:1 , Max:40 , Default: 20)   How CDR flat files are processed   We need to dig a bit deeper into the CDR Repository Manager Directory structure to understand how CDR flat files are handled. CDR Repository Manager Directory Structure   The CDR Repository Manager Directory Structure as described below exists only on the Publisher.   Everything under /var/log/active/cm/cdr_repository   admin:file list activelog /cm/cdr_repository <dir>   car <dir>   destination1 <dir>   destination2 <dir>   destination3 <dir>   preserve <dir>   processed <dir>   tmp <dir>   trans dir count = 8, file count = 0 admin:   trans – files being received from CM node   tmp – files waiting to be processed   preserve/yyyymmdd – files to be sent out and/or to be loaded by CAR   processed/yyyymmdd – files successfully sent to all destinations and loaded by CAR (if CAR is not activated and no billing server is configured, files are put here directly)   destinationX/yyyymmdd – contains symbolic links to files under preserve. CDR Repository Manager service uses these soft-links to determine what files need to be transfered to billing server.   car/yyyymmdd – contains symbolic links to files under preserve. CAR Scheduler service uses these soft-links to determine what files need to be processed by the CDR Loader.     Understanding 'preserve' and 'processed' directories   In regular working scenarios:   Once CDR Agent on the node running the CallManager service sends the files to the Publisher, they are stored in the 'preserve/yyyymmdd' directory on the Publisher. If CAR is activated, symbolic links will be created to these files in the 'car/yyyymmdd' location. If billing servers are configured, symbolic links to these files will also be created in the 'destinationX/yyyymmdd' location (where X can be 1,2,3 --- since at most 3 billing servers can be configured).   The files will remain in the 'preserve' location until CDR Loader processes these files and enters corresponding records into the CDR database. Once the CDR files are processed, they are moved to the 'processed' location.   In addition to CDR Loading being enabled, if Billing Servers are configured, the CDR files will continue to remain in the 'preserve' location until both operations are completed -- i.e. until both CDR Loading and transfering file to the billing server are completed.   Hence, in typical working scenarios, all the CDR flat files will in the 'processed' location as opposed to the 'preserve' location. This signifies that all operations for those files have been completed.     Example:   If you are troubleshooting any CDR data for Jan 5th, then you may want to check whether the corresponding files exist in preserve directory or processed directory.     To check whether preserve directory contains files for Jan 5th, use following command on the Publisher:   file list activelog /cm/cdr_repository/preserve/20110105     To check whether processed directory contains files for Jan 5th, use following command on the Publisher:   file list activelog /cm/cdr_repository/processed/20110105       Service Interaction   To better understand the service interaction, assume there are two servers in the cluster - one Publisher and one Subscriber. Assume CallManager service is running only on the Subscriber. Here's how CDR, CMR files are managed:     CallManager service on the Subscriber generates CDR/CMR flat files locally. CDR Agent service on the Subscriber transfers these files to the cdr_repository directory structure on the Publisher. Once the transfer is complete, the local copy of these files on the Subscriber is deleted. If billing servers are configured, then CDR Repository Manager service on the Publisher will transfer these flat files to the billing servers. If "Continuous Loading 24/7" is enabled (in the CDR Analysis and Reporting tool), then CAR Scheduler service on the Publisher will insert the call information in the flat files into the CAR database on the Publisher.     Note: - For every node that runs the CallManager service, the CDR Agent service on that node is responsible for transfering the flat files to the cdr_respository structure on the Publisher. If the CallManager service runs on the Publisher as well, then the CDR Agent service on the Publisher will transfer the flat files to the cdr_repository directory structure on the Publisher.   Billing Servers The system can send CDR files to up to three preconfigured destinations (billing servers) using FTP/SFTP. The CDR Repository Manager on the Publisher is responsible for transferring the CDR files to the billing servers.     Cisco allows you to use any SFTP server product but recommends SFTP products that have been certified with Cisco through the Cisco Technology Developer Partner program (CTDP). CTDP partners, such as GlobalSCAPE, certify their products with specified version of Cisco Unified Communications Manager. For information on which vendors have certified their products with your version of Cisco Unified Communications Manager, refer to the following URL:   http://www.cisco.com/pcgi-bin/ctdp/Search.pl     For information on using GlobalSCAPE with supported Cisco Unified Communications versions, refer to the following URL:   http://www.globalscape.com/gsftps/cisco.aspx     Cisco uses the following servers for internal testing. You may use one of the servers, but you must contact the vendor for support:   • Open SSH (refer to http://sshwindows.sourceforge.net/ )\ • Cygwin (refer to http://www.cygwin.com/ ) • Titan (refer to: http://www.titanftp.com/ )     Configuration screenshots:   CDR Load Schedule     From Cisco Unified Communications Manager CDR Analysis and Reporting page, navigate to System > Scheduler > CDR Load as seen in the screenshot below:   The following screen is displayed:       Disable Loading - To disable CDR data loading. Use this option if you do not want CDR data to be loaded into the CAR database. Changes take effect at midnight. You'll also need to use this option if manual purge operation is to be performed (loader should be disabled prior to executing the purge operation). You can force the change to take effect immediately by stopping and restarting the CAR Scheduler service.   Continuous Loading 24/7 - Enables the CDR Loader to run continuously 24 hours a day, 7 days a week to load CDRs into the CAR database. This choice represents the default setting for the CDR Load Scheduler. Note : If this option is chosen, it takes precedence over and ignores the other CDR and CMR load parameters on the screen, such as Time, Loading Interval, Duration, and Uninhibited Loading.   Load CDR Only - Check this box to load only CDR records into the CAR database. With this option, CMR records do not load into the CAR database. This choice represents the default setting for the CDR Load Scheduler. You must manually uncheck the Load CDR only check box to force the CMR records to load with the CDR records.         Useful Links/References   Please refer to the 'Cisco Unified CDR Analysis and Reporting Administration Guide' for the appropriate release for additional information. To access the document:   -- Navigate to: http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html -- Search for 'Cisco Unified CDR Analysis and Reporting Administration Guide' for the appropriate CUCM release   Troubleshooting CDR (a document on supportforums)                   ... View more