configs/cdr.conf.sample

   1 ;
   2 ; Asterisk Call Detail Record engine configuration
   3 ;
   4 ; CDR is Call Detail Record, which provides logging services via a variety of
   5 ; pluggable backend modules.  Detailed call information can be recorded to
   6 ; databases, files, etc.  Useful for billing, fraud prevention, compliance with
   7 ; Sarbanes-Oxley aka The Enron Act, QOS evaluations, and more.
   8 ;
   9
  10 [general]
  11
  12 ; Define whether or not to use CDR logging.  Setting this to "no" will override
  13 ; any loading of backend CDR modules.  Default is "yes".
  14 ;enable=yes
  15
  16 ; Define whether or not to log unanswered calls. Setting this to "yes" will
  17 ; report every attempt to ring a phone in dialing attempts, when it was not
  18 ; answered. For example, if you try to dial 3 extensions, and this option is "yes",
  19 ; you will get 3 CDR's, one for each phone that was rung. Default is "no". Some
  20 ; find this information horribly useless. Others find it very valuable. Note, in "yes"
  21 ; mode, you will see one CDR, with one of the call targets on one side, and the originating
  22 ; channel on the other, and then one CDR for each channel attempted. This may seem
  23 ; redundant, but cannot be helped.
  24 ;
  25 ; In brief, this option controls the reporting of unanswered calls which only have an A
  26 ; party. Calls which get offered to an outgoing line, but are unanswered, are still
  27 ; logged, and that is the intended behaviour. (It also results in some B side CDRs being
  28 ; output, as they have the B side channel as their source channel, and no destination
  29 ; channel.)
  30 ;unanswered = no
  31
  32 ; Define whether or not to log congested calls. Setting this to "yes" will
  33 ; report each call that fails to complete due to congestion conditions. Default
  34 ; is "no".
  35 ;congestion = no
  36
  37 ; Normally, CDR's are not closed out until after all extensions are finished
  38 ; executing.  By enabling this option, the CDR will be ended before executing
  39 ; the "h" extension and hangup handlers so that CDR values such as "end" and
  40 ; "billsec" may be retrieved inside of of this extension.
  41 ; The default value is "no".
  42 ;endbeforehexten=no
  43
  44 ; Normally, the 'billsec' field logged to the backends (text files or databases)
  45 ; is simply the end time (hangup time) minus the answer time in seconds. Internally,
  46 ; asterisk stores the time in terms of microseconds and seconds. By setting
  47 ; initiatedseconds to 'yes', you can force asterisk to report any seconds
  48 ; that were initiated (a sort of round up method). Technically, this is
  49 ; when the microsecond part of the end time is greater than the microsecond
  50 ; part of the answer time, then the billsec time is incremented one second.
  51 ; The default value is "no".
  52 ;initiatedseconds=no
  53
  54 ; Define the CDR batch mode, where instead of posting the CDR at the end of
  55 ; every call, the data will be stored in a buffer to help alleviate load on the
  56 ; asterisk server.  Default is "no".
  57 ;
  58 ; WARNING WARNING WARNING
  59 ; Use of batch mode may result in data loss after unsafe asterisk termination
  60 ; ie. software crash, power failure, kill -9, etc.
  61 ; WARNING WARNING WARNING
  62 ;
  63 ;batch=no
  64
  65 ; Define the maximum number of CDRs to accumulate in the buffer before posting
  66 ; them to the backend engines.  'batch' must be set to 'yes'.  Default is 100.
  67 ;size=100
  68
  69 ; Define the maximum time to accumulate CDRs in the buffer before posting them
  70 ; to the backend engines.  If this time limit is reached, then it will post the
  71 ; records, regardless of the value defined for 'size'.  'batch' must be set to
  72 ; 'yes'.  Note that time is in seconds.  Default is 300 (5 minutes).
  73 ;time=300
  74
  75 ; The CDR engine uses the internal asterisk scheduler to determine when to post
  76 ; records.  Posting can either occur inside the scheduler thread, or a new
  77 ; thread can be spawned for the submission of every batch.  For small batches,
  78 ; it might be acceptable to just use the scheduler thread, so set this to "yes".
  79 ; For large batches, say anything over size=10, a new thread is recommended, so
  80 ; set this to "no".  Default is "no".
  81 ;scheduleronly=no
  82
  83 ; When shutting down asterisk, you can block until the CDRs are submitted.  If
  84 ; you don't, then data will likely be lost.  You can always check the size of
  85 ; the CDR batch buffer with the CLI "cdr status" command.  To enable blocking on
  86 ; submission of CDR data during asterisk shutdown, set this to "yes".  Default
  87 ; is "yes".
  88 ;safeshutdown=yes
  89
  90 ;
  91 ;
  92 ; CHOOSING A CDR "BACKEND"  (what kind of output to generate)
  93 ;
  94 ; To choose a backend, you have to make sure either the right category is
  95 ; defined in this file, or that the appropriate config file exists, and has the
  96 ; proper definitions in it. If there are any problems, usually, the entry will
  97 ; silently ignored, and you get no output.
  98 ;
  99 ; Also, please note that you can generate CDR records in as many formats as you
 100 ; wish. If you configure 5 different CDR formats, then each event will be logged
 101 ; in 5 different places! In the example config files, all formats are commented
 102 ; out except for the cdr-csv format.
 103 ;
 104 ; Here are all the possible back ends:
 105 ;
 106 ;   csv, custom, manager, odbc, pgsql, radius, sqlite, tds
 107 ;    (also, mysql is available via the asterisk-addons, due to licensing
 108 ;     requirements)
 109 ;   (please note, also, that other backends can be created, by creating
 110 ;    a new backend module in the source cdr/ directory!)
 111 ;
 112 ; Some of the modules required to provide these backends will not build or install
 113 ; unless some dependency requirements are met. Examples of this are pgsql, odbc,
 114 ; etc. If you are not getting output as you would expect, the first thing to do
 115 ; is to run the command "make menuselect", and check what modules are available,
 116 ; by looking in the "2. Call Detail Recording" option in the main menu. If your
 117 ; backend is marked with XXX, you know that the "configure" command could not find
 118 ; the required libraries for that option.
 119 ;
 120 ; To get CDRs to be logged to the plain-jane /var/log/asterisk/cdr-csv/Master.csv
 121 ; file, define the [csv] category in this file. No database necessary. The example
 122 ; config files are set up to provide this kind of output by default.
 123 ;
 124 ; To get custom csv CDR records, make sure the cdr_custom.conf file
 125 ; is present, and contains the proper [mappings] section. The advantage to
 126 ; using this backend, is that you can define which fields to output, and in
 127 ; what order. By default, the example configs are set up to mimic the cdr-csv
 128 ; output. If you don't make any changes to the mappings, you are basically generating
 129 ; the same thing as cdr-csv, but expending more CPU cycles to do so!
 130 ;
 131 ; To get manager events generated, make sure the cdr_manager.conf file exists,
 132 ; and the [general] section is defined, with the single variable 'enabled = yes'.
 133 ;
 134 ; For odbc, make sure all the proper libs are installed, that "make menuselect"
 135 ; shows that the modules are available, and the cdr_odbc.conf file exists, and
 136 ; has a [global] section with the proper variables defined.
 137 ;
 138 ; For pgsql, make sure all the proper libs are installed, that "make menuselect"
 139 ; shows that the modules are available, and the cdr_pgsql.conf file exists, and
 140 ; has a [global] section with the proper variables defined.
 141 ;
 142 ; For logging to radius databases, make sure all the proper libs are installed, that
 143 ; "make menuselect" shows that the modules are available, and the [radius]
 144 ; category is defined in this file, and in that section, make sure the 'radiuscfg'
 145 ; variable is properly pointing to an existing radiusclient.conf file.
 146 ;
 147 ; For logging to sqlite databases, make sure the 'cdr.db' file exists in the log directory,
 148 ; which is usually /var/log/asterisk. Of course, the proper libraries should be available
 149 ; during the 'configure' operation.
 150 ;
 151 ; For tds logging, make sure the proper libraries are available during the 'configure'
 152 ; phase, and that cdr_tds.conf exists and is properly set up with a [global] category.
 153 ;
 154 ; Also, remember, that if you wish to log CDR info to a database, you will have to define
 155 ; a specific table in that databse to make things work! See the doc directory for more details
 156 ; on how to create this table in each database.
 157 ;
 158
 159 [csv]
 160 usegmtime=yes    ; log date/time in GMT.  Default is "no"
 161 loguniqueid=yes  ; log uniqueid.  Default is "no"
 162 loguserfield=yes ; log user field.  Default is "no"
 163 accountlogs=yes  ; create separate log file for each account code. Default is "yes"
 164
 165 ;[radius]
 166 ;usegmtime=yes    ; log date/time in GMT
 167 ;loguniqueid=yes  ; log uniqueid
 168 ;loguserfield=yes ; log user field
 169 ; Set this to the location of the radiusclient-ng configuration file
 170 ; The default is /etc/radiusclient-ng/radiusclient.conf
 171 ;radiuscfg => /usr/local/etc/radiusclient-ng/radiusclient.conf