CentOS 6.5 Lampp (Xampp) and MYSQL CDR

Hi there Asterisk community,

I was wondering if it was possible and if so, how to use Lampp’s MYSQL to store the call detail records in.
I’ve tried installing the mysql-devel package and i’ve tried changing the modules.conf, cdr_mysql.conf and cdr.conf. Also i’ve reloaded and restart Asterisk and the entire server multiple times but still no changes.

When i execute the command cdr show status i get the following messages

Call Detail Record (CDR) settings
  Logging:                    Enabled
  Mode:                       Simple
  Log unanswered calls:       No
  Log congestion:             No

* Registered Backends

In the MYSQL from Lampp i made an account with the following credentials: asterisk/asterisk and gave it permissions to the designated table.


; Asterisk configuration file
; Module Loader configuration file

; Any modules that need to be loaded before the Asterisk core has been
; initialized (just after the logger has been initialized) can be loaded
; using 'preload'. This will frequently be needed if you wish to map all
; module configuration files into Realtime storage, since the Realtime
; driver will need to be loaded before the modules using those configuration
; files are initialized.
; An example of loading ODBC support would be:
;preload => res_odbc.so
;preload => res_config_odbc.so
; Uncomment the following if you wish to use the Speech Recognition API
;preload => res_speech.so
; If you want Asterisk to fail if a module does not load, then use
; the "require" keyword. Asterisk will exit with a status code of 2
; if a required module does not load.
; require = chan_sip.so
; If you want you can combine with preload
; preload-require = res_odbc.so
; If you want, load the GTK console right away.
noload => pbx_gtkconsole.so
;load => pbx_gtkconsole.so
load => res_musiconhold.so
; Load one of: chan_oss, alsa, or console (portaudio).
; By default, load chan_oss only (automatically).
noload => chan_alsa.so
;noload => chan_oss.so
noload => chan_console.so
load => cdr_addon_mysql.so


; 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.


; Define whether or not to use CDR logging.  Setting this to "no" will override
; any loading of backend CDR modules.  Default is "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".

; 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".

; 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".
; Use of batch mode may result in data loss after unsafe asterisk termination
; ie. software crash, power failure, kill -9, etc.

; 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.

; 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).

; 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".

; 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".

; 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.

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"

;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


; Note - if the database server is hosted on the same machine as the
; asterisk server, you can achieve a local Unix socket connection by
; setting hostname=localhost
; port and sock are both optional parameters.  If hostname is specified
; and is not "localhost" (you can use address instead), then 
; cdr_mysql will attempt to connect to the port specified or use the 
; default port.  If hostname is not specified or if hostname is 
; "localhost", then cdr_mysql will attempt to connect to the socket file 
; specified by sock or otherwise use the default socket file.
hostname=localhost (i've tried and server ip also)
;timezone=UTC ; Previously called usegmtime
; If your system's locale differs from mysql database character set,
; cdr_mysql can damage non-latin characters in CDR variables. Use this
; option to protect your data.
; Older versions of cdr_mysql set the calldate field to whenever the
; record was posted, rather than the start date of the call.  This flag
; reverts to the old (incorrect) behavior.  Note that you'll also need
; to comment out the "start=calldate" alias, below, to use this.
; ssl connections (optional)
;ssl_ca=<path to CA cert>
;ssl_cert=<path to cert>
;ssl_key=<path to keyfile>
; You may also configure the field names used in the CDR table.
;static "<value>" => <column>
;alias <cdrvar> => <column>
alias start => calldate
;alias clid => <a_field_not_named_clid>
;alias src => <a_field_not_named_src>
;alias dst => <a_field_not_named_dst>
;alias dcontext => <a_field_not_named_dcontext>
;alias channel => <a_field_not_named_channel>
;alias dstchannel => <a_field_not_named_dstchannel>
;alias lastapp => <a_field_not_named_lastapp>
;alias lastdata => <a_field_not_named_lastdata>
;alias duration => <a_field_not_named_duration>
;alias billsec => <a_field_not_named_billsec>
;alias disposition => <a_field_not_named_disposition>
;alias amaflags => <a_field_not_named_amaflags>
;alias accountcode => <a_field_not_named_accountcode>
;alias userfield => <a_field_not_named_userfield>
;alias uniqueid => <a_field_not_named_uniqueid>

Mysql and Mysql-server locations


Asterisk version: 11.8.1

Thanks in advance for all the support,

Did You re-configure and re-install Asterisk after installing mysql-devel package?

If yes: Is /usr/lib/asterisk/modules/cdr_addon_mysql.so available at Your system ?
If yes: There should be some error-messages when You try to issue a module load cdr_addon_mysql.so on the asterisk CLI
If no: You need to select cdr_addon_mysql during a reinstall with make menuselect

If no: Reinstall Asterisk with configure && make menuselect and take care to choose dr_addon_mysql

BTW: As cdr_addon_mysql is deprecated You should better try to use cdr_adaptive_odbc.so instead - just have a look at the modules dependencies and don’t forget to install the ODBC-driver for mysql