vicidial.org

Hi,

I'm having problems with calls being dropped in my production server. My installation has been working for almost 3 months now when suddenly yesterday I noticved that my dropped percentage has risen to 15%. I am using Ratio dialing, vicidial 2.0.3 and asterisk 1.2.24.

What I noticed on the timeOnVDADall page was that the Dropped part of the Dropped/Answer ratio is increasing when this statistics get updated. But during the update interval, I have agents available and the number of calls waiting for agents never goes past 0.

Looking at the VDAD report, as previously I was getting only around 10-15 calls every 15 minute intervals, I am now getting 150 to 200 calls getting dropped every 15 minute interval.

My server set-up is as follow:

1 dual-xeon 3.2GHz for mysql/apache
1 dual-xeon 3.2 GHz for asterisk server 1 (20 agents) with x100p
1 dual-xeon 3.2 GHz for asterisk server 2 (20 agents) with x100p

If I reset the servers, the problem goes away.

Anybody have an idea whats causing this?

Thanks!

ragnaAdik

maybe its just the database..

try to move mysql to another PC and update the apache pages (dbconnect.php) and /etc/astguiclient.conf to point to that ip of the new DB.. dont forget to add permission to cron and root from the other computers ip.
execute this on the new mysql PC
ie. GRANT ALL PRIVILEGES ON *.* TO root@192.168.1.1 IDENTIFIED BY "PASSWORD";
ie. GRANT ALL PRIVILEGES ON *.* TO cron@192.168.1.1 IDENTIFIED BY "1234";
ie. FLUSH PRIVILEGES;

dont forget to configure mysql to accept remote connections that is to comment bind-adress 127.0.0.1 on the settings file of mysql (my.cnf). for me it is located on /etc/mysql/my.cnf. im using debian linux

Also try to re-create the campaign

see if this approach work hehe..

MySQL is already accepting remote connections as the asterisk servers are on different machines. I also noticed a lot of messages like

DBD::mysql::db do failed: Duplicate entry '1196954001.8767250' for key 1 at /usr/share/astguiclient/FastAGI_log.pl line 411.

While troubleshooting the problem, I first tried restarting the MySQL server but the problem did not go away. I then tried restarting the asterisk process and all the processes shown on screen -r on the asterisk servers and this fixed the problem.

Any ideas at which script should I look to troubleshoot this problem?

Thanks!

Hi


are you load balancing or multi server setup ?

if you are doing load balancing, you need to follow Loadbalance document to make everything work fine,

and you need post some kind of logs to assits you.

ram

Why are you using RATIO instead of using ADAPT dial method?

ram,

I'm doing both load-balancing and multi-server set-up. I followed the load_balancing.txt. My installation has been working for about 3-months without a hitch until a few days ago when I encountered the 'unaccounted' drop calls. What I mean by 'unaccounted' is that during the observation period, I always have available agents waiting to take the call but the DROPPED part of DROPPED/ANSWER ratio statistics keeps on rising.

Unfortunately, I turned off all logging about a month ago as the dialer was working flawlessly. The only abnormal logs that I could see by running screen -r on the astguiclient processes are those something like below

DBD::mysql::db do failed: Duplicate entry '1196954001.8767250' for key 1 at /usr/share/astguiclient/FastAGI_log.pl line 411.

If the problem happens again, I will post relevant logs. Thanks!


matt,

The room managers decided to use RATIO dialing and just adjust manually the dialing ratio based on dropped calls and number of waiting agents. Apparently, the quality of the leads they're getting varies and they don't want long idle time for agents.

I'll ask them anyway to use ADAPT_average and just adjust the max dialing rate instead and see if the problem repeats itself.

Thanks again for this great software!

ragnadik

What are the loadavg on all servers?

Are you watching your mysql activity with mtop when this happens?

Real Asterisk CLI output when calls are waiting with agents waiting too