Add option for logging congested calls as CONGESTION instead of NO_ANSWER in CDR
[asterisk/asterisk.git] / configs / cdr.conf.sample
index 4e4c3d4..882f487 100644 (file)
 ; 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 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".
 ; submission of CDR data during asterisk shutdown, set this to "yes".  Default
 ; is "yes".
 ;safeshutdown=yes
-;
 
-; 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 so that CDR values such as "end" and "billsec" may be
-; retrieved inside of of this extension.
-;endbeforehexten=no
+;
+;
+; 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
-;loguniqueid=yes ;log uniqueid
-;loguserfield=yes ;log user field
+[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
+;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
-