Predictive Dialer

[ahmedsallam]

Good Afternoon Sir
I hope my email finds you well . We are facing 2 support cases at one of our customers that has Vicidial predictive dialer solution so I hope you can support us .Here it is:

• Time sync problem: As you know , The dialers need to be time synchronized together with the database server . We tried to allow the dialers to synchronize with database server but it is sometime become out of synchronization . The system at our customer cant access the internet to synchronize with online NTP servers as the customer environment is offline so do you know the root cause of the problem and a solution or a work around to solve it?
• Storage capacity: The hard disks at some dialers become out of space . Is there any document you have to explain the archiving process ? Does the system supports archiving ? If not , Is there any way to configure automated delete for the records – for example- 6 months old ?

Appreciate your support.

Best Regards

[williamconley]

1) Welcome to the Party!

2) As you are obviously new here, I have some suggestions to help us all help you:

When you post, please post your entire configuration including (but not limited to) your installation method (7.X.X?) and vicidial version with build (VERSION: 2.X-XXXx ... BUILD: #####-####).

This IS a requirement for posting along with reading the stickies (at the top of each forum) and the manager's manual (available on EFLO.net, both free and paid versions)

You should also post: Asterisk version, telephony hardware (model number is helpful here), cluster information if you have one, and whether any other software is installed in the box. If your installation method is "manual/from scratch" you must post your operating system with version (and the .iso version from which you installed your original operating system) plus a link to the installation instructions you used. If your installation is "Hosted" list the site name of the host.

If this is a "Cloud" or "Virtual" server, please note the technology involved along with the version of that techology (ie: VMware Server Version 2.0.2). If it is not, merely stating the Motherboard model # and CPU would be helpful.

Similar to This:

Vicibox X.X from .iso | Vicidial X.X.X-XXX Build XXXXXX-XXXX | Asterisk X.X.X | Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation | Intel DG35EC | Core2Quad Q6600

3) You have posted two questions in one thread line with the subject line of "predictive dialer". To be clear: This is the Vicidial forum. Vicidial is indeed a predictive dialer, but your headline observing this serves no purpose. Next time, create two threads and put a proper subject line on each one if your intention is to get help on these topics (many people never read past the headline ... and that's a lot of eyeballs that would never even know that your problems are simple and they could have offered you help ... days ago!).

4) You posted your supports requests in the General Discussion board instead of the support board. I'll move this ticket to the support board. But once again, if you want support ... it's useful to post your request in the appropriate board (assuming you want as many qualified eyeballs on your problem as possible, yes?)

5) time sync is tricky, but not difficult: There are two possibilities. First: Time sync is actually not staying synced. If all the servers in the cluster are syncing to the DB server or at least all to the same server (as it should be), but they are getting Out of Sync with that master server, then you have a local networking problem you need to work out. To be clear: the actual time is irrelevant. The servers must all have the SAME time as the system timing depends upon this. But they do not need the correct time at all. Second possibility: A networking problem between the agent's "Web Servers" and the Agent Web Browser. If they are dropping packets, a time sync error will be tossed even though this error is unrelated to time. Each packet updates a field expected to be updated every second. If that field gets too far outdated (due to dropped packets), the system can not tell if there is a time sync problem or dropped packets. So it tosses the time sync error for clarity (that's a bit of sarcasm, hope you enjoyed it).

Storage Capacity: Explore this section of your crontab -e:

Code: Select all

### recording mixing/compressing/ftping scripts
#0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57 * * * * /usr/share/astguiclient/AST_CRON_audio_1_move_mix.pl
0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57 * * * * /usr/share/astguiclient/AST_CRON_audio_1_move_mix.pl --MIX
0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57 * * * * /usr/share/astguiclient/AST_CRON_audio_1_move_VDonly.pl
1,4,7,10,13,16,19,22,25,28,31,34,37,40,43,46,49,52,55,58 * * * * /usr/share/astguiclient/AST_CRON_audio_2_compress.pl --MP3
#2,5,8,11,14,17,20,23,26,29,32,35,38,41,44,47,50,53,56,59 * * * * /usr/share/astguiclient/AST_CRON_audio_3_ftp.pl --MP3


That last entry "ftp" is the one you want. Execute it with --help to get the options:

Code: Select all

perl /usr/share/astguiclient/AST_CRON_audio_3_ftp.pl --MP3 --help

This relies on the "/etc/astguiclient.conf" values for "FTP recording archive connection information"

Code: Select all

# FTP recording archive connection information
VARFTP_host => 10.0.0.4
VARFTP_user => cron
VARFTP_pass => test
VARFTP_port => 21
VARFTP_dir => RECORDINGS
VARHTTP_path => http://10.0.0.4


This script will push all recordings from each dialer to a central FTP server AND change all the links in Vicidial (using VARHTTP_path) so these recordings are still available via the admin GUI. Users in Vicidial will not know they no longer reside on the dialers, nor will they care. They'll still just click on the link for access.

It's a bit tricky to get set up correctly, but once you get it set up all you need to do is mirror the HD on that FTP server to have redundant copies of all recordings on all servers (because recordings will no longer be stored on those servers!).

Note: You must also use the "remove old recordings" options in crontab -e to purge the "no longer needed" recordings from the servers.

Code: Select all

### remove old recordings more than 7 days old
#24 0 * * * /usr/bin/find /var/spool/asterisk/monitorDONE/FTP -maxdepth 2 -type f -mtime +7 -print | xargs rm -f


Recordings are stored in /ORIG/ (uncompressed, no longer needed after being compressed to MP3, so this folder can be emptied without penalty).

After compression, recordings are stored in MP3. This folder should not be pruned.

After being moved to the FTP server, the MP3 files are moved to FTP. These can be pruned at will also as they are now copied on the FTP server.

The MP3 folder should not have any files in it at the end of the day if the system is running properly and all files are being pushed to the FTP server. Also worthy of note, you an set up a second FTP server and use the script (read the manual) that pushes to the 2nd FTP service and it will take all the files from FTP, send them to the redundant FTP server and move the local file to FTP2. This gives you a 2nd copy of all your audio recordings without the need for a mirror. Then you would ONLY prune the FTP2 folder and the ORIG folder. If any other folders collect files, you'll know one of the scripts is failing (or the FTP or FTP2 servers is offline and unable to accept files).

6) Happy Hunting!