2005-06-03 01:42:31 +00:00
|
|
|
;
|
|
|
|
; 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
|
|
|
|
|
2014-11-14 18:12:05 +00:00
|
|
|
; 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. Unasnwered Calls which get offered to an
|
|
|
|
; outgoing line will always receive log entries regardless of this option, and
|
|
|
|
; that is the intended behaviour.
|
Merged revisions 89622 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r89622 | murf | 2007-11-26 23:24:02 -0700 (Mon, 26 Nov 2007) | 1 line
closes issue #11379; OK, this is an attempt to make both sides happy. To the cdr.conf file, I added the option 'unanswered', which defaults to 'no'. In this mode, you will see a cdr for a call, whether it was answered or not. The disposition will be NO ANSWER or ANSWERED, as appropriate. The src is as you'd expect, the destination channel will be one of the channels from the Dial() call, usually the last in the list if more than one chan was specified. With unanswered set to 'yes', you will still see this cdr entry in both cases. But in the case where the dial timed out, you will also see a cdr for each line attempted, marked NO ANSWER, with no destination channel name. The new option defaults to 'no', so you don't see the pesky extra cdr's by default, and you will not see the irritating 'not posted' messages.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89623 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-11-27 06:47:08 +00:00
|
|
|
;unanswered = no
|
|
|
|
|
2011-08-22 17:05:14 +00:00
|
|
|
; 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
|
|
|
|
|
2010-08-09 12:14:58 +00:00
|
|
|
; 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
|
2012-06-29 17:02:32 +00:00
|
|
|
; 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".
|
2010-08-09 12:14:58 +00:00
|
|
|
;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.
|
2010-08-09 12:52:04 +00:00
|
|
|
; The default value is "no".
|
2010-08-09 12:14:58 +00:00
|
|
|
;initiatedseconds=no
|
|
|
|
|
2005-06-03 01:42:31 +00:00
|
|
|
; 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
|
2006-09-11 16:41:49 +00:00
|
|
|
; records. Posting can either occur inside the scheduler thread, or a new
|
2005-06-03 01:42:31 +00:00
|
|
|
; 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
|
2006-03-14 16:49:34 +00:00
|
|
|
|
2007-04-05 22:40:42 +00:00
|
|
|
;
|
|
|
|
;
|
2007-08-21 15:04:37 +00:00
|
|
|
; CHOOSING A CDR "BACKEND" (what kind of output to generate)
|
2007-04-05 22:40:42 +00:00
|
|
|
;
|
2009-05-28 14:39:21 +00:00
|
|
|
; 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
|
2007-04-05 22:40:42 +00:00
|
|
|
; proper definitions in it. If there are any problems, usually, the entry will
|
|
|
|
; silently ignored, and you get no output.
|
2009-05-28 14:39:21 +00:00
|
|
|
;
|
|
|
|
; Also, please note that you can generate CDR records in as many formats as you
|
2007-04-05 22:40:42 +00:00
|
|
|
; 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:
|
|
|
|
;
|
2009-05-28 14:39:21 +00:00
|
|
|
; csv, custom, manager, odbc, pgsql, radius, sqlite, tds
|
2007-04-05 22:40:42 +00:00
|
|
|
; (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.
|
|
|
|
;
|
2009-05-28 14:39:21 +00:00
|
|
|
; To get CDRs to be logged to the plain-jane /var/log/asterisk/cdr-csv/Master.csv
|
2007-04-05 22:40:42 +00:00
|
|
|
; 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.
|
|
|
|
;
|
2007-08-21 15:04:37 +00:00
|
|
|
; To get custom csv CDR records, make sure the cdr_custom.conf file
|
2007-04-05 22:40:42 +00:00
|
|
|
; 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!
|
|
|
|
;
|
2007-08-21 15:04:37 +00:00
|
|
|
; 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'.
|
2007-04-05 22:40:42 +00:00
|
|
|
;
|
2007-08-21 15:04:37 +00:00
|
|
|
; For odbc, make sure all the proper libs are installed, that "make menuselect"
|
2007-04-05 22:40:42 +00:00
|
|
|
; shows that the modules are available, and the cdr_odbc.conf file exists, and
|
|
|
|
; has a [global] section with the proper variables defined.
|
|
|
|
;
|
2007-08-21 15:04:37 +00:00
|
|
|
; For pgsql, make sure all the proper libs are installed, that "make menuselect"
|
2007-04-05 22:40:42 +00:00
|
|
|
; shows that the modules are available, and the cdr_pgsql.conf file exists, and
|
|
|
|
; has a [global] section with the proper variables defined.
|
|
|
|
;
|
2009-05-28 14:39:21 +00:00
|
|
|
; For logging to radius databases, make sure all the proper libs are installed, that
|
2007-04-05 22:40:42 +00:00
|
|
|
; "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.
|
|
|
|
;
|
2007-08-21 15:04:37 +00:00
|
|
|
; For logging to sqlite databases, make sure the 'cdr.db' file exists in the log directory,
|
2007-04-05 22:40:42 +00:00
|
|
|
; which is usually /var/log/asterisk. Of course, the proper libraries should be available
|
|
|
|
; during the 'configure' operation.
|
|
|
|
;
|
2009-05-28 14:39:21 +00:00
|
|
|
; For tds logging, make sure the proper libraries are available during the 'configure'
|
2007-04-05 22:40:42 +00:00
|
|
|
; 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]
|
2007-08-21 15:04:37 +00:00
|
|
|
usegmtime=yes ; log date/time in GMT. Default is "no"
|
2008-04-09 19:00:40 +00:00
|
|
|
loguniqueid=yes ; log uniqueid. Default is "no"
|
|
|
|
loguserfield=yes ; log user field. Default is "no"
|
2010-07-09 11:06:19 +00:00
|
|
|
accountlogs=yes ; create separate log file for each account code. Default is "yes"
|
2005-06-03 01:42:31 +00:00
|
|
|
|
2006-05-20 22:30:05 +00:00
|
|
|
;[radius]
|
2007-08-21 15:04:37 +00:00
|
|
|
;usegmtime=yes ; log date/time in GMT
|
|
|
|
;loguniqueid=yes ; log uniqueid
|
|
|
|
;loguserfield=yes ; log user field
|
2006-05-20 22:30:05 +00:00
|
|
|
; 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
|