forked from SimplesIP/pabx-app
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
167 lines
8.1 KiB
167 lines
8.1 KiB
; |
|
; Asterisk Call Detail Record engine configuration |
|
; |
|
; 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. |
|
; |
|
|
|
[general] |
|
|
|
; Define whether or not to use CDR logging. Setting this to "no" will override |
|
; any loading of backend CDR modules. Default is "yes". |
|
;enable=yes |
|
|
|
; Define whether or not to log unanswered calls that don't involve an outgoing |
|
; party. Setting this to "yes" will make calls to extensions that don't answer |
|
; and don't set a B side channel (such as by using the Dial application) |
|
; receive CDR log entries. If this option is set to "no", then those log |
|
; entries will not be created. Unanswered Calls which get offered to an |
|
; outgoing line will always receive log entries regardless of this option, and |
|
; that is the intended behaviour. |
|
;unanswered = no |
|
unanswered = yes |
|
|
|
; Define whether or not to log congested calls. Setting this to "yes" will |
|
; report each call that fails to complete due to congestion conditions. Default |
|
; is "no". |
|
;congestion = no |
|
|
|
; Normally, CDR's are not closed out until after all extensions are finished |
|
; executing. By enabling this option, the CDR will be ended before executing |
|
; the "h" extension and hangup handlers so that CDR values such as "end" and |
|
; "billsec" may be retrieved inside of of this extension. |
|
; The default value is "no". |
|
;endbeforehexten=no |
|
|
|
; Normally, the 'billsec' field logged to the backends (text files or databases) |
|
; 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. |
|
; The default value is "no". |
|
;initiatedseconds=no |
|
|
|
; 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. Default is "no". |
|
; |
|
; WARNING WARNING WARNING |
|
; Use of batch mode may result in data loss after unsafe asterisk termination |
|
; ie. software crash, power failure, kill -9, etc. |
|
; WARNING WARNING WARNING |
|
; |
|
;batch=no |
|
|
|
; Define the maximum number of CDRs to accumulate in the buffer before posting |
|
; them to the backend engines. 'batch' must be set to 'yes'. Default is 100. |
|
;size=100 |
|
|
|
; Define the maximum time to accumulate CDRs in the buffer before posting them |
|
; 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 that time is in seconds. Default is 300 (5 minutes). |
|
;time=300 |
|
|
|
; 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". Default is "no". |
|
;scheduleronly=no |
|
|
|
; 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". Default |
|
; is "yes". |
|
;safeshutdown=yes |
|
|
|
; |
|
; |
|
; CHOOSING A CDR "BACKEND" (what kind of output to generate) |
|
; |
|
; To choose a backend, you have to make sure either the right category is |
|
; defined in this file, or that the appropriate config file exists, and has the |
|
; proper definitions in it. If there are any problems, usually, the entry will |
|
; silently ignored, and you get no output. |
|
; |
|
; Also, please note that you can generate CDR records in as many formats as you |
|
; wish. If you configure 5 different CDR formats, then each event will be logged |
|
; in 5 different places! In the example config files, all formats are commented |
|
; out except for the cdr-csv format. |
|
; |
|
; Here are all the possible back ends: |
|
; |
|
; csv, custom, manager, odbc, pgsql, radius, sqlite, tds |
|
; (also, mysql is available via the asterisk-addons, due to licensing |
|
; requirements) |
|
; (please note, also, that other backends can be created, by creating |
|
; a new backend module in the source cdr/ directory!) |
|
; |
|
; Some of the modules required to provide these backends will not build or install |
|
; unless some dependency requirements are met. Examples of this are pgsql, odbc, |
|
; etc. If you are not getting output as you would expect, the first thing to do |
|
; is to run the command "make menuselect", and check what modules are available, |
|
; by looking in the "2. Call Detail Recording" option in the main menu. If your |
|
; backend is marked with XXX, you know that the "configure" command could not find |
|
; the required libraries for that option. |
|
; |
|
; To get CDRs to be logged to the plain-jane /var/log/asterisk/cdr-csv/Master.csv |
|
; file, define the [csv] category in this file. No database necessary. The example |
|
; config files are set up to provide this kind of output by default. |
|
; |
|
; To get custom csv CDR records, make sure the cdr_custom.conf file |
|
; is present, and contains the proper [mappings] section. The advantage to |
|
; using this backend, is that you can define which fields to output, and in |
|
; what order. By default, the example configs are set up to mimic the cdr-csv |
|
; output. If you don't make any changes to the mappings, you are basically generating |
|
; the same thing as cdr-csv, but expending more CPU cycles to do so! |
|
; |
|
; To get manager events generated, make sure the cdr_manager.conf file exists, |
|
; and the [general] section is defined, with the single variable 'enabled = yes'. |
|
; |
|
; For odbc, make sure all the proper libs are installed, that "make menuselect" |
|
; shows that the modules are available, and the cdr_odbc.conf file exists, and |
|
; has a [global] section with the proper variables defined. |
|
; |
|
; For pgsql, make sure all the proper libs are installed, that "make menuselect" |
|
; shows that the modules are available, and the cdr_pgsql.conf file exists, and |
|
; has a [global] section with the proper variables defined. |
|
; |
|
; For logging to radius databases, make sure all the proper libs are installed, that |
|
; "make menuselect" shows that the modules are available, and the [radius] |
|
; category is defined in this file, and in that section, make sure the 'radiuscfg' |
|
; variable is properly pointing to an existing radiusclient.conf file. |
|
; |
|
; For logging to sqlite databases, make sure the 'cdr.db' file exists in the log directory, |
|
; which is usually /var/log/asterisk. Of course, the proper libraries should be available |
|
; during the 'configure' operation. |
|
; |
|
; For tds logging, make sure the proper libraries are available during the 'configure' |
|
; phase, and that cdr_tds.conf exists and is properly set up with a [global] category. |
|
; |
|
; Also, remember, that if you wish to log CDR info to a database, you will have to define |
|
; a specific table in that databse to make things work! See the doc directory for more details |
|
; on how to create this table in each database. |
|
; |
|
|
|
[csv] |
|
usegmtime=yes ; log date/time in GMT. Default is "no" |
|
loguniqueid=yes ; log uniqueid. Default is "no" |
|
loguserfield=yes ; log user field. Default is "no" |
|
accountlogs=yes ; create separate log file for each account code. Default is "yes" |
|
newcdrcolumns=yes ; Enable logging of post-1.8 CDR columns (peeraccount, linkedid, sequence). |
|
; Default is "no". |
|
|
|
;[radius] |
|
;usegmtime=yes ; log date/time in GMT |
|
;loguniqueid=yes ; log uniqueid |
|
;loguserfield=yes ; log user field |
|
; Set this to the location of the radiusclient-ng configuration file |
|
; The default is /etc/radiusclient-ng/radiusclient.conf |
|
;radiuscfg => /usr/local/etc/radiusclient-ng/radiusclient.conf
|
|
|