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 ------------------- cdr-custom csv
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 ; [modules] autoload=yes ; ; 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. ; [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 ; 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". ;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". ; ; 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 ; 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". ;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 ; ; ; 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. 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 ; 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 127.0.0.1 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. ; [global] hostname=localhost (i've tried 127.0.0.1 and server ip also) dbname=nspabx table=cdr password=asterisk user=asterisk port=3306 ;sock=/tmp/mysql.sock ;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. ;charset=koi8r ; ; 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. ;compat=no ; ; 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. ; [columns] ;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,