vicidial.org

I have Few Campaigns.

All of a Sudden I see NO LIVE CALLS in any of my campaigns.

- Leads are There
- Its set as 24 Hrs Dialing
- Tried repairing the DB but no Change
- New Restart hang up all existing calls but Still shows NO LIVE CALLS.
- Tried reseting the Asterisk But No change.
- It doesn't happens at any particular moments.
- Network ping is Ok and Can ping google normally from the server
- Server is on STATIC Public IP.
- I tried creating New Campaign also but same stats. It doesn't dial.
- I tried to login from Vicidial Basic VERSION: 2.4-325c BUILD: 110430-1924 Server: 192.168.0.100 Agent Screen But No Changes.
- Load Averages : 0.68 0.35 0.31

Any Suggestions why it can happens ?

Any Advice to Resolve it ?

did you checked the total number of screen running

screen -list

Yes and All screens are there ...

is manual dialing working too?

Manual is working ...

Reinstalled the Dialer but Problem is still there !!

Any Clue or Hint where to check ?


[root@go ~]# screen -ls
There are screens on:
4151.ASTfastlog (Detached)
4148.ASTVDadapt (Detached)
5273.ASTVDremote (Detached)
4130.goautodial_d (Detached)
5267.ASTlisten (Detached)
6504.pts-0.go (Attached)
4125.astshell20120306230102 (Detached)
5261.ASTupdate (Detached)
5264.ASTsend (Detached)
5270.ASTVDauto (Detached)
4286.asterisk (Detached)
11 Sockets in /var/run/screen/S-root.

*check the HD of the server if its full
-if full remove some unnecessary files


*check the physical memory of the vicidial

- reboot the server



i hope it helps

HDD has more than 80% Free

Physical Memory is also Ok.

It happens 3-4 times daily . Cant Reboot so Frequently as its a Production server and calls are always going on.

gmcust3 wrote:HDD has more than 80% Free

Physical Memory is also Ok.

It happens 3-4 times daily . Cant Reboot so Frequently as its a Production server and calls are always going on.

I assume everything is ok, except that real-time report is not updated?

Calls ALSO doesn't come to agent !!!

under campaign
check how many leads are in hopper and what u have set the hopper level

200 is the Value.

I tried Reset Hopper also but No Charge !!

did in realtime its showing leads to be dialled:? or is it zero
also in the camapign what it is showing for total leads in hopper for this campaing.( u can see this at the bottom of the campaign screen)

i'm not sure if this would help but try to repair the MYSQL...

mysqlcheck -u cron -p --auto-repair --check --optimize --all-databases

gmcust3 wrote:Manual is working ...

mmmm.. if manual dialing is working then you might have toggled something in your configuration

> What's your dial method?
> Dial Prefix?
> Did you add a "Dial Status"?

striker wrote:did in realtime its showing leads to be dialled:? or is it zero
also in the camapign what it is showing for total leads in hopper for this campaing.( u can see this at the bottom of the campaign screen)

Enough Leads are there !!!

sadikhov wrote:i'm not sure if this would help but try to repair the MYSQL...

mysqlcheck -u cron -p --auto-repair --check --optimize --all-databases

Already tried this ..

I can Ping my Lan and WAN both normally.

When I used the same Installation Method at other place, Its works like charm !!

MySql Restart solves the Problem

But would like to know why its happening ?

Anyway to find the root cause ?

Any Advice from Mentors ?

DELETE FROM vicidial_auto_calls where channel IS NULL

Once I run this Sql, All starts again.

But why calls are getting stucked and Status comes as XFER ?

Why below query is giving me error in mysql ?
----------------------------------------------------------
CREATE EVENT e_vicidial_auto_calls
ON SCHEDULE
EVERY 55 SECOND
COMMENT 'Clears out sessions table'
DO
DELETE FROM vicidial_auto_calls where channel IS NULL

Guys

I am having this problem too, once I restart the MYSQL service it all starts again, how can we aviod this.!!!!

TXS

Start by looking in the logs /var/log/mysql/ and maybe /var/log/apache2/error_log
have you tried "DELETE FROM vicidial_auto_calls where channel IS NULL" as gmcust3 said fixed the problem for him (temporary)

gmcust3: "Why below query is giving me error in mysql ?"
You should have posted the error too.

btaveras wrote:Guys
I am having this problem too, once I restart the MYSQL service it all starts again, how can we aviod this.!!!!

1) Welcome to the Party!

2) when you post, please post your entire configuration including (but not limited to) your installation method and vicidial version with 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 "from scratch" you must post your operating system and should also post the .iso version from which you installed your original operating system. 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) And then you should also take DomeDan's advice above (Happy hunting!)

4) You may have a crashed mysql table. In which case:

mysqlcheck --auto-repair --all-databases -p1234 -u cron

Guys thanks for the quick replay, here is my server info:
vicibox.x86_64-4.0.1.iso | ViciBox Redux v.3.1.13 release | Asterisk 1.4.39.2-vici | Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation | Intel(R) Xeon(R) CPU X3323 @ 2.50GHz | quadcore

I have tried all the repairs commands:

DELETE FROM vicidial_auto_calls where channel IS NULL; (this solve it for a few hours but it later comes back and the calls get stuck in the table.)
mysqlcheck --auto-repair --all-databases -p1234 -u cron (I repair the DB like a millon times and after a few hours it comes back)

I also did was change the Storage Engine in phpMyAdmin to the vicidial_auto_calls table from MEMORY to MyISAM so it can be optimize and repair and still the same problem, because this table was in MEMORY when I repair the DB this table in particularly was giving me this error: The storage engine for the table doesn't support check, optimize or repair. Im running out of solutions.


Thanks a lot guys

change the table type back. memory tables do not need to be optimized because they are too fast for that. nor do they need repair as they are wiped clean at restart.

you probably have illegal phone numbers being dialed. these clog up the auto-calls because they are initiated but never completed. modify your dialplan to catch all "illegal/invalid" numbers and immediately hang them up (after attaching the vicidial agi process).

I change back the table type,

Can you please explain with more detail about the illegal phone numbers, never hear that expression on the vicidial, can you explain me what they are? and how to add them to the dial plan.

if you have a dialplan entry such as "exten => _91NXXNXXXXXX" but you dial a number such as "81571285718518275182", this will not match the dialplan entry. Which means no dialplan will be executed. Since vicidial will put the number in the autocalls when the call is initiated, it requires that another script (later) remove the call from autocalls. But no other script will ever run ... since no diaplan was executed. Hence, the entry will stay in autocalls forever. So be sure that any and every call you initiate matches a dialplan entry somewhere.

If necessary, determine the "minimum length of a number" (such as "_XXXXXXXX.", which would be 8 digits or more -- because of the "." at the end --and put in a dialplan entry that causes all those calls to be terminated immediately after the agi line executes. So vicidial will "attach", then the call will terminate, and vicidial will delete the entry from autocalls.

Code: Select all

exten=>_XXXXXXXX.,1,AGI(agi://127.0.0.1:4577/call_log)
exten=>_XXXXXXXX.,n,Hangup


It is not a good idea to make this entry too short, because it has the potential to interfere with the operation of the system if it gets too short.

Before we upload the leads we make sure that there is no numbers with more or less than 10 digits, and we do not dial 011 numbers in this center.

This is the dial plan that we are using right now:

exten => _81NXXXXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _81NXXXXXXXXX,2,Dial(${SIPxcast}/${EXTEN:1},,tTor)
exten => _81NXXXXXXXXX,3,Hangup

please check this out:

mysql> select call_time, channel, queue_priority, phone_number from vicidial_auto_calls;
+---------------------+--------------------+----------------+--------------+
| call_time | channel | queue_priority | phone_number |
+---------------------+--------------------+----------------+--------------+
| 2012-12-17 19:52:49 | NULL | 0 | 6092925467 |
| 2012-12-17 19:52:46 | NULL | 0 | 6092918154 |
| 2012-12-17 19:52:46 | NULL | 0 | 6092916329 |
| 2012-12-17 20:04:59 | NULL | 50 | 6093961789 |
| 2012-12-17 20:04:59 | NULL | 50 | 6093961865 |
| 2012-12-17 19:52:44 | NULL | 0 | 6092910668 |
| 2012-12-17 20:05:10 | NULL | 50 | 6093963836 |
| 2012-12-17 19:52:45 | NULL | 0 | 6092914205 |
| 2012-12-17 20:04:59 | SIP/xcast-00001963 | 50 | 6093960906 |
| 2012-12-17 19:52:47 | NULL | 0 | 6092918758 |
| 2012-12-17 20:02:16 | SIP/xcast-00001944 | 0 | 9084562232 |
| 2012-12-17 20:05:07 | NULL | 50 | 6093963296 |
| 2012-12-17 20:05:12 | NULL | 50 | 6093964041 |
| 2012-12-17 20:05:07 | NULL | 50 | 6093962984 |
| 2012-12-17 20:04:54 | NULL | 50 | 6093960208 |
| 2012-12-17 20:05:05 | SIP/xcast-00001966 | 50 | 6093961951 |
| 2012-12-17 19:52:49 | NULL | 0 | 6092929647 |
| 2012-12-17 19:52:50 | NULL | 0 | 6092980387 |
| 2012-12-17 19:52:50 | NULL | 0 | 6092981960 |
| 2012-12-17 19:52:51 | NULL | 0 | 6092983465 |
| 2012-12-17 19:52:52 | NULL | 0 | 6092983767 |
+---------------------+--------------------+----------------+--------------+
21 rows in set (0.00 sec)


as you can seee there are calls that entered the table at 19:52 with the queue_priority =0 those calls are not hang up they are stuck in the table and it wont hang up, and you can see the numbers are with 10 digits also you see calls with a queue_priority=50 those are fine. and you see the time 20:05.

please advice

cool. did they have a dial code of 1? and a dial prefix of 8?

yes sir, the dial code is 1 and the dial prefix is 8, everything is set up and they are currently working with that setting. I'm live this the agents write now.

I didn't mean "in general" I meant on those particular leads. Especially the ones with "null" for a channel. Have you actually checked them?

I cant check them, I only see them when I execute the query, once I run the query DELETE FROM vicidial_auto_calls where channel IS NULL; everything goes back working fine. and yes I only use those setting on those particular leads.

no agents log in and I got this

mysql> select call_time, channel, queue_priority, phone_number from vicidial_auto_calls;
+---------------------+---------+----------------+--------------+
| call_time | channel | queue_priority | phone_number |
+---------------------+---------+----------------+--------------+
| 2012-12-17 20:10:29 | NULL | 0 | 6094663366 |
| 2012-12-17 20:10:42 | NULL | 0 | 6094665350 |
| 2012-12-17 20:10:45 | NULL | 0 | 6094669651 |
| 2012-12-17 20:10:42 | NULL | 0 | 6094665457 |
| 2012-12-17 20:10:43 | NULL | 0 | 6094666859 |
| 2012-12-17 20:10:45 | NULL | 0 | 6094668952 |
| 2012-12-17 20:10:43 | NULL | 0 | 6094668425 |
| 2012-12-17 20:10:39 | NULL | 0 | 6094664091 |
| 2012-12-17 20:10:42 | NULL | 0 | 6094664469 |
| 2012-12-17 20:10:24 | NULL | 0 | 6094662248 |
| 2012-12-17 20:10:45 | NULL | 0 | 6094690512 |
| 2012-12-17 20:10:28 | NULL | 0 | 6094662567 |
| 2012-12-17 20:10:45 | NULL | 0 | 6094668918 |
| 2012-12-17 20:10:43 | NULL | 0 | 6094668116 |
| 2012-12-17 20:10:42 | NULL | 0 | 6094666663 |
+---------------------+---------+----------------+--------------+
15 rows in set (0.00 sec)

get the original lead from the vicidial list table. that's how you determine whether the dial code is 1, not by "deciding" or "remembering". the dial prefix is set by the campaign, but the dial code is set on each lead (unless the campaign is set to ignore the dial code ...). you can also check the asterisk log or asterisk cli interface to see if the numbers in question have a "problem" when dialing. perhaps that is what is missing from your troubleshooting technique. "asterisk -R" and watch the leads dial, look for errors such as "extension not found".

No facing this Issue ?

I am using Goautodial !!