michael@202: ; michael@202: ; Asterisk Call Detail Record engine configuration michael@202: ; michael@202: ; CDR is Call Detail Record, which provides logging services via a variety of michael@202: ; pluggable backend modules. Detailed call information can be recorded to michael@202: ; databases, files, etc. Useful for billing, fraud prevention, compliance with michael@202: ; Sarbanes-Oxley aka The Enron Act, QOS evaluations, and more. michael@202: ; michael@202: michael@202: ;[general] michael@202: michael@202: ; Define whether or not to use CDR logging. Setting this to "no" will override michael@202: ; any loading of backend CDR modules. Default is "yes". michael@202: ;enable=yes michael@202: michael@202: ; Define whether or not to log unanswered calls. Setting this to "yes" will michael@202: ; report every attempt to ring a phone in dialing attempts, when it was not michael@202: ; answered. For example, if you try to dial 3 extensions, and this option is "yes", michael@202: ; you will get 3 CDR's, one for each phone that was rung. Default is "no". Some michael@202: ; find this information horribly useless. Others find it very valuable. Note, in "yes" michael@202: ; mode, you will see one CDR, with one of the call targets on one side, and the originating michael@202: ; channel on the other, and then one CDR for each channel attempted. This may seem michael@202: ; redundant, but cannot be helped. michael@202: ;unanswered = no michael@202: michael@202: ; Define the CDR batch mode, where instead of posting the CDR at the end of michael@202: ; every call, the data will be stored in a buffer to help alleviate load on the michael@202: ; asterisk server. Default is "no". michael@202: ; michael@202: ; WARNING WARNING WARNING michael@202: ; Use of batch mode may result in data loss after unsafe asterisk termination michael@202: ; ie. software crash, power failure, kill -9, etc. michael@202: ; WARNING WARNING WARNING michael@202: ; michael@202: ;batch=no michael@202: michael@202: ; Define the maximum number of CDRs to accumulate in the buffer before posting michael@202: ; them to the backend engines. 'batch' must be set to 'yes'. Default is 100. michael@202: ;size=100 michael@202: michael@202: ; Define the maximum time to accumulate CDRs in the buffer before posting them michael@202: ; to the backend engines. If this time limit is reached, then it will post the michael@202: ; records, regardless of the value defined for 'size'. 'batch' must be set to michael@202: ; 'yes'. Note that time is in seconds. Default is 300 (5 minutes). michael@202: ;time=300 michael@202: michael@202: ; The CDR engine uses the internal asterisk scheduler to determine when to post michael@202: ; records. Posting can either occur inside the scheduler thread, or a new michael@202: ; thread can be spawned for the submission of every batch. For small batches, michael@202: ; it might be acceptable to just use the scheduler thread, so set this to "yes". michael@202: ; For large batches, say anything over size=10, a new thread is recommended, so michael@202: ; set this to "no". Default is "no". michael@202: ;scheduleronly=no michael@202: michael@202: ; When shutting down asterisk, you can block until the CDRs are submitted. If michael@202: ; you don't, then data will likely be lost. You can always check the size of michael@202: ; the CDR batch buffer with the CLI "cdr status" command. To enable blocking on michael@202: ; submission of CDR data during asterisk shutdown, set this to "yes". Default michael@202: ; is "yes". michael@202: ;safeshutdown=yes michael@202: michael@202: ; Normally, CDR's are not closed out until after all extensions are finished michael@202: ; executing. By enabling this option, the CDR will be ended before executing michael@202: ; the "h" extension so that CDR values such as "end" and "billsec" may be michael@202: ; retrieved inside of of this extension. michael@202: ;endbeforehexten=no michael@202: michael@202: ; michael@202: ; michael@202: ; CHOOSING A CDR "BACKEND" (what kind of output to generate) michael@202: ; michael@202: ; To choose a backend, you have to make sure either the right category is michael@202: ; defined in this file, or that the appropriate config file exists, and has the michael@202: ; proper definitions in it. If there are any problems, usually, the entry will michael@202: ; silently ignored, and you get no output. michael@202: ; michael@202: ; Also, please note that you can generate CDR records in as many formats as you michael@202: ; wish. If you configure 5 different CDR formats, then each event will be logged michael@202: ; in 5 different places! In the example config files, all formats are commented michael@202: ; out except for the cdr-csv format. michael@202: ; michael@202: ; Here are all the possible back ends: michael@202: ; michael@202: ; csv, custom, manager, odbc, pgsql, radius, sqlite, tds michael@202: ; (also, mysql is available via the asterisk-addons, due to licensing michael@202: ; requirements) michael@202: ; (please note, also, that other backends can be created, by creating michael@202: ; a new backend module in the source cdr/ directory!) michael@202: ; michael@202: ; Some of the modules required to provide these backends will not build or install michael@202: ; unless some dependency requirements are met. Examples of this are pgsql, odbc, michael@202: ; etc. If you are not getting output as you would expect, the first thing to do michael@202: ; is to run the command "make menuselect", and check what modules are available, michael@202: ; by looking in the "2. Call Detail Recording" option in the main menu. If your michael@202: ; backend is marked with XXX, you know that the "configure" command could not find michael@202: ; the required libraries for that option. michael@202: ; michael@202: ; To get CDRs to be logged to the plain-jane /var/log/asterisk/cdr-csv/Master.csv michael@202: ; file, define the [csv] category in this file. No database necessary. The example michael@202: ; config files are set up to provide this kind of output by default. michael@202: ; michael@202: ; To get custom csv CDR records, make sure the cdr_custom.conf file michael@202: ; is present, and contains the proper [mappings] section. The advantage to michael@202: ; using this backend, is that you can define which fields to output, and in michael@202: ; what order. By default, the example configs are set up to mimic the cdr-csv michael@202: ; output. If you don't make any changes to the mappings, you are basically generating michael@202: ; the same thing as cdr-csv, but expending more CPU cycles to do so! michael@202: ; michael@202: ; To get manager events generated, make sure the cdr_manager.conf file exists, michael@202: ; and the [general] section is defined, with the single variable 'enabled = yes'. michael@202: ; michael@202: ; For odbc, make sure all the proper libs are installed, that "make menuselect" michael@202: ; shows that the modules are available, and the cdr_odbc.conf file exists, and michael@202: ; has a [global] section with the proper variables defined. michael@202: ; michael@202: ; For pgsql, make sure all the proper libs are installed, that "make menuselect" michael@202: ; shows that the modules are available, and the cdr_pgsql.conf file exists, and michael@202: ; has a [global] section with the proper variables defined. michael@202: ; michael@202: ; For logging to radius databases, make sure all the proper libs are installed, that michael@202: ; "make menuselect" shows that the modules are available, and the [radius] michael@202: ; category is defined in this file, and in that section, make sure the 'radiuscfg' michael@202: ; variable is properly pointing to an existing radiusclient.conf file. michael@202: ; michael@202: ; For logging to sqlite databases, make sure the 'cdr.db' file exists in the log directory, michael@202: ; which is usually /var/log/asterisk. Of course, the proper libraries should be available michael@202: ; during the 'configure' operation. michael@202: ; michael@202: ; For tds logging, make sure the proper libraries are available during the 'configure' michael@202: ; phase, and that cdr_tds.conf exists and is properly set up with a [global] category. michael@202: ; michael@202: ; Also, remember, that if you wish to log CDR info to a database, you will have to define michael@202: ; a specific table in that databse to make things work! See the doc directory for more details michael@202: ; on how to create this table in each database. michael@202: ; michael@202: michael@202: ;[csv] michael@202: ;usegmtime=yes ; log date/time in GMT. Default is "no" michael@202: ;loguniqueid=yes ; log uniqueid. Default is "no michael@202: ;loguserfield=yes ; log user field. Default is "no michael@202: michael@202: ;[radius] michael@202: ;usegmtime=yes ; log date/time in GMT michael@202: ;loguniqueid=yes ; log uniqueid michael@202: ;loguserfield=yes ; log user field michael@202: ; Set this to the location of the radiusclient-ng configuration file michael@202: ; The default is /etc/radiusclient-ng/radiusclient.conf michael@202: ;radiuscfg => /usr/local/etc/radiusclient-ng/radiusclient.conf