Calls Waiting For Agents - Vicidial Not Transfering

[chrisls]

We are having a strange and intermittent problem related to Vicidial not transferring calls to available agents. Some information about our system:

1) CentOS
2) Single 3.2 GHz XEON Processor
3) 300 GB RAID
4) 1 GB Memory
5) VD 1.1.12

We have in between 15-25 agents logged in to a single campaign at any given time. The dial level is typically set between 1.5 - 3.0.

The system will be running just fine for hours, making about 40-50 outbound calls and transferring them in to the meetme rooms with the agents. The suddenly, Vicdial will stop transferring calls to agents. The nuber of calls waiting for agents starts to increment upwards as does the agents waiting for calls. In a couple minutes all of the agents will be waiting for calls and there will be 20+ calls waiting for agents. Then calls start to drop off.

Currently we have been logging all of the agents off of the system, resetting the hopper and then we let agents log in again. The problem typically will occur again in a few hours time.

I was told today by one of our SysAdmins that the issue typically doesn't occur when the autodial level is set to 1.5. Since this issue isn't repeatable in our testing I'm beginning to think its related to load. Has anyone else experienced this problem? I've included a screen shot of the campaign real time monitor when this issue occurs.

This is a great product and we are really happy with it. Just trying to work out all of the kinks right now.

Thanks!!!

[/img]

[chrisls]

The last image host won't work...This should...

[mflorell]

What is the loadavg of the server when this happens?

Please post some Real Asterisk CLI with AGIoutput turned on(STDERR) for the server for when this happens.

[alexjones]

I have the same problem but not always?
What is causing this?

[Op3r]

Did you put the exten = h on your extensions.conf?

check the table vicidial_auto_calls

this will help immensely

[alexjones]

Did you put the exten = h on your extensions.conf?

check the table vicidial_auto_calls

this will help immensely

For what should i check?

[enjay]

Look at the SCRATCH_INSTALL for the hangup extensions (exten = h,)

-enjay

[alexjones]

Look at the SCRATCH_INSTALL for the hangup extensions (exten = h,)

-enjay

exten => h,1,DeadAGI(call_log.agi,${EXTEN})
exten => h,2,DeadAGI(VD_hangup.agi,PRI-----DEBUG-----${HANGUPCAUSE}-----${DIALSTATUS}-----${DIALEDTIME}-----${ANSWEREDTIME})

[alexjones]

Look at the SCRATCH_INSTALL for the hangup extensions (exten = h,)

-enjay

exten => h,1,DeadAGI(call_log.agi,${EXTEN})
exten => h,2,DeadAGI(VD_hangup.agi,PRI-----DEBUG-----${HANGUPCAUSE}-----${DIALSTATUS}-----${DIALEDTIME}-----${ANSWEREDTIME})

Can someone tell me what is causing this and how can i fix it?

[kkj]

I have same problem. Please advice

kkj

[kkj]

Solved. I followed step by step configration again

[alexjones]

Solved. I followed step by step configration again

Can you tell me how did you solved the problem?

Thank you

Alex

[alexjones]

I'm the only one that did not manage to resolve this problem?
I don't undestand in what conditions is this happening because apparantly everything works fine in the moment it appears. I came across this problem since i updated to version 2.0.1. I'm using load balancing with 3 separate systems: asterisk, apache/vicidial and mysql servers.
Please help me...

Thank you,
Alex

[Op3r]

look at your screens if anyone is up

then

look at your extensions.conf for the H part.

also look if your server time are sync with each other.

[gerski]

did you put your exten=h to your extensions.conf?

[alexjones]

did you put your exten=h to your extensions.conf?

This is what i have:

exten => h,1,DeadAGI(call_log.agi,${EXTEN}) exten => h,2,DeadAGI(VD_hangup.agi,PRI-----DEBUG-----${HANGUPCAUSE}-----${DIALSTATUS}-----${DIALEDTIME}-----${ANSWEREDTIME})

[Op3r]

can you post your extensions.conf here?

or put it on pastebin

[alexjones]

can you post your extensions.conf here?

or put it on pastebin

The problem is in table vicidial_auto_calls, for some reason not all the records are erased and some of them remain there. At some point vicidial thinks that all the operators are busy and he dosent pass the calls. I did not find a way to overcome this yet. Maybe you guys have some ideeas?

[Op3r]

then delete it.

[alexjones]

then delete it.

I m doing that, but isnt there a way to fix this not to happend, i dont know what is causing this as well.

[Op3r]

because if you have that exten => h on your extensions.conf you wont have that kind of problem.

[chrisls]

because if you have that exten => h on your extensions.conf you wont have that kind of problem.

This issue has repeated itself on one of our systems. The explanation that alexjones writes:

>>>The problem is in table vicidial_auto_calls, for some reason not all the records are erased and some of them remain there. At some point vicidial thinks that all the operators are busy and he dosent pass the calls. I did not find a way to overcome this yet. Maybe you guys have some ideeas?

...seems to make a lot of sense and explains why agents aren't conferenced in to the calls.

Does anyone know what is CRON job script which check and maintains state on agent availability?

It seems if the hangup extensions weren't being called the system would have many more problems then this issue, which occurs on a very intermittant basis. If the hangup extension wasn't being called then call_log.agi and VD_hangup.agi wouldn't get fired off, causing all types of data managment issues.

I know on our systems we have the hangup extensions in the dialplan.

Anyone else out there experiencing these issues? Any more information/ideas would be quite helpful.

[mflorell]

The problem also might be with CentOS "nice"-ing the perl/agi scripts down so that they do not execute when they are supposed to. For some reason this problem only effects some CentOS installs, and I have not seen it happen on any other Linux distro.

If possible you should try any distro other than CentOS and see if the problem continues.