(changelog debian)
[asterisk-config-auf.git] / etc-asterisk / cdr.conf
2; Asterisk Call Detail Record engine configuration
4; CDR is Call Detail Record, which provides logging services via a variety of
5; pluggable backend modules. Detailed call information can be recorded to
6; databases, files, etc. Useful for billing, fraud prevention, compliance with
7; Sarbanes-Oxley aka The Enron Act, QOS evaluations, and more.
12; Define whether or not to use CDR logging. Setting this to "no" will override
13; any loading of backend CDR modules. Default is "yes".
16; Define whether or not to log unanswered calls. Setting this to "yes" will
17; report every attempt to ring a phone in dialing attempts, when it was not
18; answered. For example, if you try to dial 3 extensions, and this option is "yes",
19; you will get 3 CDR's, one for each phone that was rung. Default is "no". Some
20; find this information horribly useless. Others find it very valuable. Note, in "yes"
21; mode, you will see one CDR, with one of the call targets on one side, and the originating
22; channel on the other, and then one CDR for each channel attempted. This may seem
23; redundant, but cannot be helped.
24;unanswered = no
26; Define the CDR batch mode, where instead of posting the CDR at the end of
27; every call, the data will be stored in a buffer to help alleviate load on the
28; asterisk server. Default is "no".
31; Use of batch mode may result in data loss after unsafe asterisk termination
32; ie. software crash, power failure, kill -9, etc.
37; Define the maximum number of CDRs to accumulate in the buffer before posting
38; them to the backend engines. 'batch' must be set to 'yes'. Default is 100.
41; Define the maximum time to accumulate CDRs in the buffer before posting them
42; to the backend engines. If this time limit is reached, then it will post the
43; records, regardless of the value defined for 'size'. 'batch' must be set to
44; 'yes'. Note that time is in seconds. Default is 300 (5 minutes).
47; The CDR engine uses the internal asterisk scheduler to determine when to post
48; records. Posting can either occur inside the scheduler thread, or a new
49; thread can be spawned for the submission of every batch. For small batches,
50; it might be acceptable to just use the scheduler thread, so set this to "yes".
51; For large batches, say anything over size=10, a new thread is recommended, so
52; set this to "no". Default is "no".
55; When shutting down asterisk, you can block until the CDRs are submitted. If
56; you don't, then data will likely be lost. You can always check the size of
57; the CDR batch buffer with the CLI "cdr status" command. To enable blocking on
58; submission of CDR data during asterisk shutdown, set this to "yes". Default
59; is "yes".
62; Normally, CDR's are not closed out until after all extensions are finished
63; executing. By enabling this option, the CDR will be ended before executing
64; the "h" extension so that CDR values such as "end" and "billsec" may be
65; retrieved inside of of this extension.
70; CHOOSING A CDR "BACKEND" (what kind of output to generate)
72; To choose a backend, you have to make sure either the right category is
73; defined in this file, or that the appropriate config file exists, and has the
74; proper definitions in it. If there are any problems, usually, the entry will
75; silently ignored, and you get no output.
77; Also, please note that you can generate CDR records in as many formats as you
78; wish. If you configure 5 different CDR formats, then each event will be logged
79; in 5 different places! In the example config files, all formats are commented
80; out except for the cdr-csv format.
82; Here are all the possible back ends:
84; csv, custom, manager, odbc, pgsql, radius, sqlite, tds
85; (also, mysql is available via the asterisk-addons, due to licensing
86; requirements)
87; (please note, also, that other backends can be created, by creating
88; a new backend module in the source cdr/ directory!)
90; Some of the modules required to provide these backends will not build or install
91; unless some dependency requirements are met. Examples of this are pgsql, odbc,
92; etc. If you are not getting output as you would expect, the first thing to do
93; is to run the command "make menuselect", and check what modules are available,
94; by looking in the "2. Call Detail Recording" option in the main menu. If your
95; backend is marked with XXX, you know that the "configure" command could not find
96; the required libraries for that option.
98; To get CDRs to be logged to the plain-jane /var/log/asterisk/cdr-csv/Master.csv
99; file, define the [csv] category in this file. No database necessary. The example
100; config files are set up to provide this kind of output by default.
102; To get custom csv CDR records, make sure the cdr_custom.conf file
103; is present, and contains the proper [mappings] section. The advantage to
104; using this backend, is that you can define which fields to output, and in
105; what order. By default, the example configs are set up to mimic the cdr-csv
106; output. If you don't make any changes to the mappings, you are basically generating
107; the same thing as cdr-csv, but expending more CPU cycles to do so!
109; To get manager events generated, make sure the cdr_manager.conf file exists,
110; and the [general] section is defined, with the single variable 'enabled = yes'.
112; For odbc, make sure all the proper libs are installed, that "make menuselect"
113; shows that the modules are available, and the cdr_odbc.conf file exists, and
114; has a [global] section with the proper variables defined.
116; For pgsql, make sure all the proper libs are installed, that "make menuselect"
117; shows that the modules are available, and the cdr_pgsql.conf file exists, and
118; has a [global] section with the proper variables defined.
120; For logging to radius databases, make sure all the proper libs are installed, that
121; "make menuselect" shows that the modules are available, and the [radius]
122; category is defined in this file, and in that section, make sure the 'radiuscfg'
123; variable is properly pointing to an existing radiusclient.conf file.
125; For logging to sqlite databases, make sure the 'cdr.db' file exists in the log directory,
126; which is usually /var/log/asterisk. Of course, the proper libraries should be available
127; during the 'configure' operation.
129; For tds logging, make sure the proper libraries are available during the 'configure'
130; phase, and that cdr_tds.conf exists and is properly set up with a [global] category.
132; Also, remember, that if you wish to log CDR info to a database, you will have to define
133; a specific table in that databse to make things work! See the doc directory for more details
134; on how to create this table in each database.
138usegmtime=yes ; log date/time in GMT. Default is "no"
139loguniqueid=yes ; log uniqueid. Default is "no
140loguserfield=no ; log user field. Default is "no
143;usegmtime=yes ; log date/time in GMT
144;loguniqueid=yes ; log uniqueid
145;loguserfield=yes ; log user field
146; Set this to the location of the radiusclient-ng configuration file
147; The default is /etc/radiusclient-ng/radiusclient.conf
148;radiuscfg => /usr/local/etc/radiusclient-ng/radiusclient.conf