Call Detail Record configuration

This configuration documentation is for functionality provided by cdr.

Overview

CDR is Call Detail Record, which provides logging services via a variety of pluggable backend modules. Detailed call information can be recorded to databases, files, etc. Useful for billing, fraud prevention, compliance with Sarbanes-Oxley aka The Enron Act, QOS evaluations, and more.

cdr.conf

general

Global settings applied to the CDR engine.

Configuration Option Reference

Option Name	Type	Default Value	Regular Expression	Description
`debug`	`Boolean`		`false`	Enable/disable verbose CDR debugging.
`enable`	`Boolean`	`1`	`false`	Enable/disable CDR logging.
`unanswered`	`Boolean`	`0`	`false`	Log calls that are never answered.
`congestion`	`Boolean`		`false`	Log congested calls.
`endbeforehexten`	`Boolean`	`1`	`false`	Don't produce CDRs while executing hangup logic
`initiatedseconds`	`Boolean`	`0`	`false`	Count microseconds for billsec purposes
`batch`	`Boolean`	`0`	`false`	Submit CDRs to the backends for processing in batches
`size`	`Unsigned Integer`	`100`	`false`	The maximum number of CDRs to accumulate before triggering a batch
`time`	`Unsigned Integer`	`300`	`false`	The maximum time to accumulate CDRs before triggering a batch
`scheduleronly`	`Boolean`	`0`	`false`	Post batched CDRs on their own thread instead of the scheduler
`safeshutdown`	`Boolean`	`1`	`false`	Block shutdown of Asterisk until CDRs are submitted

Configuration Option Descriptions

debug

When set to True, verbose updates of changes in CDR information will be logged. Note that this is only of use when debugging CDR behavior.

enable

Define whether or not to use CDR logging. Setting this to "no" will override any loading of backend CDR modules. Default is "yes".

unanswered

Define whether or not to log unanswered calls. Setting this to "yes" will report every attempt to ring a phone in dialing attempts, when it was not answered. For example, if you try to dial 3 extensions, and this option is "yes", you will get 3 CDR's, one for each phone that was rung. Some find this information horribly useless. Others find it very valuable. Note, in "yes" mode, you will see one CDR, with one of the call targets on one side, and the originating channel on the other, and then one CDR for each channel attempted. This may seem redundant, but cannot be helped.

In brief, this option controls the reporting of unanswered calls which only have an A party. Calls which get offered to an outgoing line, but are unanswered, are still logged, and that is the intended behavior. (It also results in some B side CDRs being output, as they have the B side channel as their source channel, and no destination channel.)

congestion

Define whether or not to log congested calls. Setting this to "yes" will report each call that fails to complete due to congestion conditions.

endbeforehexten

As each CDR for a channel is finished, its end time is updated and the CDR is finalized. When a channel is hung up and hangup logic is present (in the form of a hangup handler or the h extension), a new CDR is generated for the channel. Any statistics are gathered from this new CDR. By enabling this option, no new CDR is created for the dialplan logic that is executed in h extensions or attached hangup handler subroutines. The default value is yes, indicating that a CDR will be generated during hangup logic.

initiatedseconds

Normally, the billsec field logged to the CDR backends is simply the end time (hangup time) minus the answer time in seconds. Internally, asterisk stores the time in terms of microseconds and seconds. By setting initiatedseconds to yes, you can force asterisk to report any seconds that were initiated (a sort of round up method). Technically, this is when the microsecond part of the end time is greater than the microsecond part of the answer time, then the billsec time is incremented one second.

batch

Define the CDR batch mode, where instead of posting the CDR at the end of every call, the data will be stored in a buffer to help alleviate load on the asterisk server.

Warning

Icon

Use of batch mode may result in data loss after unsafe asterisk termination, i.e., software crash, power failure, kill -9, etc.

size

Define the maximum number of CDRs to accumulate in the buffer before posting them to the backend engines. batch must be set to yes.

time

Define the maximum time to accumulate CDRs before posting them in a batch to the backend engines. If this time limit is reached, then it will post the records, regardless of the value defined for size. batch must be set to yes.

Note

Icon

Time is expressed in seconds.

scheduleronly

The CDR engine uses the internal asterisk scheduler to determine when to post records. Posting can either occur inside the scheduler thread, or a new thread can be spawned for the submission of every batch. For small batches, it might be acceptable to just use the scheduler thread, so set this to yes. For large batches, say anything over size=10, a new thread is recommended, so set this to no.

safeshutdown

When shutting down asterisk, you can block until the CDRs are submitted. If you don't, then data will likely be lost. You can always check the size of the CDR batch buffer with the CLI cdr status command. To enable blocking on submission of CDR data during asterisk shutdown, set this to yes.

Import Version

This documentation was imported from Asterisk Version SVN-branch-13-r420538

Asterisk Project : Asterisk 13 Configuration_cdr