cyber-cottage.co.ukMySQL stores username and passwords in the user table inside MySQL database. You can directly update or change the password using the following method:
Login to your server, type the following command at prompt:
$ mysql -u root -p
Use the mysql database;
mysql> use mysql;
Change password for user root, enter:
mysql> update user set password=PASSWORD("NEW-PASSWORD") where User='root';
Finally, you need to reload the privileges:
mysql> flush privileges; mysql> quit
In FreePBX users can listen to wav file recordings via the “Call Recordings” tab, This uses a field in the mysql cdr table to say where that recording is and what its called, They are now stored in year/month/day directory structure under /var/spool/asterisk/monitor so if the end user wants the recordings in mp3 format as many do its not just a case of converting them its also a case of updating the database.
Luckily this is fairly straight forward, its just a case of doing a quick query and then converting the file and the updating the database. First you have to install lame, This can be done simply with yum then write a script.
In FreePBX advanced settings, you need to enable “Display” and “Override” readonly settings and then add
/usr/local/sbin/postrecord.sh ^{CDR(linkedid)} to “
The script I use is simple with a bit of basic logging.
#!/bin/bash . postrecconfig.sh date >> /var/log/asterisk/mp3.log pcmwav=$(mysql -u$user -p$secret -s -N -D asteriskcdrdb<<<"select recordingfile from cdr where linkedid LIKE '$1' AND disposition = 'ANSWERED' ORDER by calldate DESC LIMIT 1"); mp3="$(echo $pcmwav | sed s/".wav"/".mp3"/)" nice lame -b 16 -m m -q 9-resample "$path$pcmwav" "$path$mp3" >> /var/log/asterisk/mp3.log touch -r "$path$pcmwav" "$path$mp3" >> /var/log/asterisk/mp3.log mysql -u$user -p$secret -s -N -D asteriskcdrdb<<<"UPDATE cdr SET recordingfile='$mp3' WHERE recordingfile = '$pcmwav'" >> /var/log/asterisk/mp3.log echo $pcmwav >> /var/log/asterisk/mp3.log echo "--------||-------" >> /var/log/asterisk/mp3.log date >> /var/log/asterisk/mp3.log echo "Done" >> /var/log/asterisk/mp3.log echo "--------||-------" >> /var/log/asterisk/mp3.log exit 1 The postrecconfig.sh file looks like user=freepbxuser secret=secret receptemail=info@youremailaddress.com file_age=35 dy=$(date '+%Y') dm=$(date '+%m') dd=$(date '+%d') path=/var/spool/asterisk/monitor/$dy/$dm/$dd/ As can be seen it steps through entry by entry converting and updating the DB, This example is cron'd to run hourly but does not delete the original wav file, this would be done in a separate script run weekly to remove old files. The reason to keep them is so that a backup of the original is held for a period in case of errors.
Hope this is of help to you and your users
We have been working with a client on a Hosted restaurant booking solution, providing the CTI and call tracking systems. This was complicated by the simple fact that the booking system was a closed system by another supplier.
The system works by the restaurant diverting their line to a DDI number we provide that sends the call to the system with the destination matching a defined number for that restaurant when the call enters the system the relevant settings are looked up in a database and audio message file, IVR options and CallerID name are set and the call is passed to the IVR. The caller then chooses their preferred option, The call can be depending of the time of day be passed to the call centre for a booking to be taken on the restaurants behalf or the call is passed to the restaurant where in many a Hosted Gigaset Dect handset is provided for them to take the booking or call the call centre for free.
The system has changed and evolved over time and by using Asterisk has meant that we can accommodate most requests for changes, Most recently we updated the statistics package to Asternic Pro
Statistics. This has allowed much more detailed reports to be created for queues and agents.
The calls are delivered to the platform over a EFM circuit from Gradwell.net providing quality and reliability combined with increased capacity over the original ISDN30 circuit.
For disaster recovery we provide a backup system in a data-centre that is kept in sync with the office system so in the case of power outage or system failure calls can be diverted to this system and calls take on mobile phones. Switching to back-up system is completed by the single click of a button on a web-page that instigates the diversion of the lines and starts the backup system automatically.
Currently we are migrating the database services off to a separate VMware server with 3 VMs, one for each of the core web or mysql servers. This will allow the service to scale as there are now over 1 million records per datatbase and it is showing no sign of slowing.