diff options
author | Matthew Jordan <mjordan@digium.com> | 2014-07-17 21:17:28 +0000 |
---|---|---|
committer | Matthew Jordan <mjordan@digium.com> | 2014-07-17 21:17:28 +0000 |
commit | fc0fecb4768d696db3324bcf6dd03325bb4cd513 (patch) | |
tree | 12615f96e88382b2824d4901f6949571e41ea2e4 /configs/samples/cdr.conf.sample | |
parent | 1ce23d4534994fdd8bfb8ad3b9ca1884194097be (diff) |
configs: Move sample config files into a subdirectory of configs
This moves all samples configs from configs/ to configs/samples. This allows
for additional sets of sample configuration files to be added in the future.
Review: https://reviewboard.asterisk.org/r/3804/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418870 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Diffstat (limited to 'configs/samples/cdr.conf.sample')
-rw-r--r-- | configs/samples/cdr.conf.sample | 171 |
1 files changed, 171 insertions, 0 deletions
diff --git a/configs/samples/cdr.conf.sample b/configs/samples/cdr.conf.sample new file mode 100644 index 000000000..458e19ab4 --- /dev/null +++ b/configs/samples/cdr.conf.sample @@ -0,0 +1,171 @@ +; +; 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. 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. Default is "no". 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 behaviour. (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.) +;unanswered = no + +; 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" + +;[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 |