asterisk/cdr.conf

changeset 310
73d852a30c9a
parent 309
2ff4e4701310
child 311
263143ec0fb2
     1.1 --- a/asterisk/cdr.conf	Sun Mar 20 19:27:35 2011 +0100
     1.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.3 @@ -1,148 +0,0 @@
     1.4 -;
     1.5 -; Asterisk Call Detail Record engine configuration
     1.6 -;
     1.7 -; CDR is Call Detail Record, which provides logging services via a variety of
     1.8 -; pluggable backend modules.  Detailed call information can be recorded to
     1.9 -; databases, files, etc.  Useful for billing, fraud prevention, compliance with
    1.10 -; Sarbanes-Oxley aka The Enron Act, QOS evaluations, and more.
    1.11 -;
    1.12 -
    1.13 -;[general]
    1.14 -
    1.15 -; Define whether or not to use CDR logging.  Setting this to "no" will override
    1.16 -; any loading of backend CDR modules.  Default is "yes".
    1.17 -;enable=yes
    1.18 -
    1.19 -; Define whether or not to log unanswered calls. Setting this to "yes" will
    1.20 -; report every attempt to ring a phone in dialing attempts, when it was not 
    1.21 -; answered. For example, if you try to dial 3 extensions, and this option is "yes",
    1.22 -; you will get 3 CDR's, one for each phone that was rung. Default is "no". Some
    1.23 -; find this information horribly useless. Others find it very valuable. Note, in "yes"
    1.24 -; mode, you will see one CDR, with one of the call targets on one side, and the originating
    1.25 -; channel on the other, and then one CDR for each channel attempted. This may seem 
    1.26 -; redundant, but cannot be helped.
    1.27 -;unanswered = no
    1.28 -
    1.29 -; Define the CDR batch mode, where instead of posting the CDR at the end of
    1.30 -; every call, the data will be stored in a buffer to help alleviate load on the
    1.31 -; asterisk server.  Default is "no".
    1.32 -;
    1.33 -; WARNING WARNING WARNING
    1.34 -; Use of batch mode may result in data loss after unsafe asterisk termination
    1.35 -; ie. software crash, power failure, kill -9, etc.
    1.36 -; WARNING WARNING WARNING
    1.37 -;
    1.38 -;batch=no
    1.39 -
    1.40 -; Define the maximum number of CDRs to accumulate in the buffer before posting
    1.41 -; them to the backend engines.  'batch' must be set to 'yes'.  Default is 100.
    1.42 -;size=100
    1.43 -
    1.44 -; Define the maximum time to accumulate CDRs in the buffer before posting them
    1.45 -; to the backend engines.  If this time limit is reached, then it will post the
    1.46 -; records, regardless of the value defined for 'size'.  'batch' must be set to
    1.47 -; 'yes'.  Note that time is in seconds.  Default is 300 (5 minutes).
    1.48 -;time=300
    1.49 -
    1.50 -; The CDR engine uses the internal asterisk scheduler to determine when to post
    1.51 -; records.  Posting can either occur inside the scheduler thread, or a new
    1.52 -; thread can be spawned for the submission of every batch.  For small batches,
    1.53 -; it might be acceptable to just use the scheduler thread, so set this to "yes".
    1.54 -; For large batches, say anything over size=10, a new thread is recommended, so
    1.55 -; set this to "no".  Default is "no".
    1.56 -;scheduleronly=no
    1.57 -
    1.58 -; When shutting down asterisk, you can block until the CDRs are submitted.  If
    1.59 -; you don't, then data will likely be lost.  You can always check the size of
    1.60 -; the CDR batch buffer with the CLI "cdr status" command.  To enable blocking on
    1.61 -; submission of CDR data during asterisk shutdown, set this to "yes".  Default
    1.62 -; is "yes".
    1.63 -;safeshutdown=yes
    1.64 -
    1.65 -; Normally, CDR's are not closed out until after all extensions are finished
    1.66 -; executing.  By enabling this option, the CDR will be ended before executing
    1.67 -; the "h" extension so that CDR values such as "end" and "billsec" may be
    1.68 -; retrieved inside of of this extension.
    1.69 -;endbeforehexten=no
    1.70 -
    1.71 -;
    1.72 -;
    1.73 -; CHOOSING A CDR "BACKEND"  (what kind of output to generate)
    1.74 -;
    1.75 -; To choose a backend, you have to make sure either the right category is 
    1.76 -; defined in this file, or that the appropriate config file exists, and has the 
    1.77 -; proper definitions in it. If there are any problems, usually, the entry will
    1.78 -; silently ignored, and you get no output.
    1.79 -; 
    1.80 -; Also, please note that you can generate CDR records in as many formats as you 
    1.81 -; wish. If you configure 5 different CDR formats, then each event will be logged
    1.82 -; in 5 different places! In the example config files, all formats are commented
    1.83 -; out except for the cdr-csv format.
    1.84 -;
    1.85 -; Here are all the possible back ends:
    1.86 -;
    1.87 -;   csv, custom, manager, odbc, pgsql, radius, sqlite, tds 
    1.88 -;    (also, mysql is available via the asterisk-addons, due to licensing
    1.89 -;     requirements)
    1.90 -;   (please note, also, that other backends can be created, by creating
    1.91 -;    a new backend module in the source cdr/ directory!)
    1.92 -;
    1.93 -; Some of the modules required to provide these backends will not build or install
    1.94 -; unless some dependency requirements are met. Examples of this are pgsql, odbc,
    1.95 -; etc. If you are not getting output as you would expect, the first thing to do
    1.96 -; is to run the command "make menuselect", and check what modules are available,
    1.97 -; by looking in the "2. Call Detail Recording" option in the main menu. If your
    1.98 -; backend is marked with XXX, you know that the "configure" command could not find
    1.99 -; the required libraries for that option.
   1.100 -;
   1.101 -; To get CDRs to be logged to the plain-jane /var/log/asterisk/cdr-csv/Master.csv 
   1.102 -; file, define the [csv] category in this file. No database necessary. The example
   1.103 -; config files are set up to provide this kind of output by default.
   1.104 -;
   1.105 -; To get custom csv CDR records, make sure the cdr_custom.conf file
   1.106 -; is present, and contains the proper [mappings] section. The advantage to
   1.107 -; using this backend, is that you can define which fields to output, and in
   1.108 -; what order. By default, the example configs are set up to mimic the cdr-csv
   1.109 -; output. If you don't make any changes to the mappings, you are basically generating
   1.110 -; the same thing as cdr-csv, but expending more CPU cycles to do so!
   1.111 -;
   1.112 -; To get manager events generated, make sure the cdr_manager.conf file exists,
   1.113 -; and the [general] section is defined, with the single variable 'enabled = yes'.
   1.114 -;
   1.115 -; For odbc, make sure all the proper libs are installed, that "make menuselect"
   1.116 -; shows that the modules are available, and the cdr_odbc.conf file exists, and
   1.117 -; has a [global] section with the proper variables defined.
   1.118 -;
   1.119 -; For pgsql, make sure all the proper libs are installed, that "make menuselect"
   1.120 -; shows that the modules are available, and the cdr_pgsql.conf file exists, and
   1.121 -; has a [global] section with the proper variables defined.
   1.122 -;
   1.123 -; For logging to radius databases, make sure all the proper libs are installed, that 
   1.124 -; "make menuselect" shows that the modules are available, and the [radius]
   1.125 -; category is defined in this file, and in that section, make sure the 'radiuscfg'
   1.126 -; variable is properly pointing to an existing radiusclient.conf file.
   1.127 -;
   1.128 -; For logging to sqlite databases, make sure the 'cdr.db' file exists in the log directory,
   1.129 -; which is usually /var/log/asterisk. Of course, the proper libraries should be available
   1.130 -; during the 'configure' operation.
   1.131 -;
   1.132 -; For tds logging, make sure the proper libraries are available during the 'configure' 
   1.133 -; phase, and that cdr_tds.conf exists and is properly set up with a [global] category.
   1.134 -;
   1.135 -; Also, remember, that if you wish to log CDR info to a database, you will have to define
   1.136 -; a specific table in that databse to make things work! See the doc directory for more details
   1.137 -; on how to create this table in each database.
   1.138 -;
   1.139 -
   1.140 -;[csv]
   1.141 -;usegmtime=yes    ; log date/time in GMT.  Default is "no"
   1.142 -;loguniqueid=yes  ; log uniqueid.  Default is "no
   1.143 -;loguserfield=yes ; log user field.  Default is "no
   1.144 -
   1.145 -;[radius]
   1.146 -;usegmtime=yes    ; log date/time in GMT
   1.147 -;loguniqueid=yes  ; log uniqueid
   1.148 -;loguserfield=yes ; log user field
   1.149 -; Set this to the location of the radiusclient-ng configuration file
   1.150 -; The default is /etc/radiusclient-ng/radiusclient.conf
   1.151 -;radiuscfg => /usr/local/etc/radiusclient-ng/radiusclient.conf

mercurial