PRESS_CALLBACK_QUEUE Issues

[midnightwalker05]

Hello Everyone.

First here are my specs:

VERSION: 2.14-694a
BUILD: 181005-1738
Load Average: 51 - 5%
Virtualized on Vultr, 2 Cores 4 GB RAM
Codecs ulaw, gsm for recordings
Pure Voip
ViciBox v.8.0.0-beta
Installation made from the ISO, read all the manuals

So, before you guys tell me that virtualization is not supported, let me tell you that I have 6 vicidial servers virtualized (different versions, different clients, different virtualization providers), and they work like a charm, most of the issues I encountered where user errors.

However I now installed this version of Vicidial to use the PRESS_CALLBACK_QUEUE feature that I think is really great, so it works really good with a few calls (to be more precise I tested it with several one call queues) and the agent gets the call back, it calls back the customer and they get connected (the only issue is that I had to change the asterisk version on the server settings for it to work properly in case anyone faces that issue).

Ok now the ugly part, when I tested it with live calls (6 calls on queue 4 agents taking calls) sometimes one agent gets stuck, basically the agent screen sees he is active waiting for a call, the real time report says that the agent is INCALL A but no phone number dialing. The agent needs to logout and the callback gets lost. So I just deactivate this option or change it for people to basically leave a VM to be called back.

Maybe this has been already fixed, but I searched on Mantis and nobody reported anything like this. In fact there's very few people talking about this great feature.

So I dont know if someone can share some light into this issue, or if its a bug that needs to fixed we are more than interested in sponsoring a solution.

And finally as this is my first post on the forum I would like to thank everybody in the vicidial team for giving us this great piece software!

[frequency]

I have been running 40-50 servers on virtualized environment but they are our own machines and nodes. we monitor the nodes for cpu load, disk usage and networking load. One node even has 25 virtualised containers and it works fine until you cross a 100 concurrent calls but load avg's remain high like 8.00 as compared to 1.00 avg 1.50 on dedicated machine. Kumba has explained that a lot of times what causes it to take more load than a normal one..

Problem on public clouds is you don't control the nodes, other users are utilizing the same cpu and disk's. A lot of high disk usage problems on virtualized servers are mitigated because nodes now have nvm'es and super high capable ssds with 10gbit networks. they is a chance your cpu power is stolen or some user are running high disk programs on your node. check for %w and %st time during calls when u encounter the issue. you can also get your server moved to a different node to see if problem can be resolved.

[thephaseusa]

That one node that has 25 containers on it must be a beast. What are the specs on it?

[midnightwalker05]

I have been running 40-50 servers on virtualized environment but they are our own machines and nodes. we monitor the nodes for cpu load, disk usage and networking load. One node even has 25 virtualised containers and it works fine until you cross a 100 concurrent calls but load avg's remain high like 8.00 as compared to 1.00 avg 1.50 on dedicated machine. Kumba has explained that a lot of times what causes it to take more load than a normal one..

Problem on public clouds is you don't control the nodes, other users are utilizing the same cpu and disk's. A lot of high disk usage problems on virtualized servers are mitigated because nodes now have nvm'es and super high capable ssds with 10gbit networks. they is a chance your cpu power is stolen or some user are running high disk programs on your node. check for %w and %st time during calls when u encounter the issue. you can also get your server moved to a different node to see if problem can be resolved.

I dont think this is an overload issue, nor a public cloud issue, everything works fine on the server except when we activate the PRESS_CALLBACK_QUEUE, and the scripts that control this feature are the same ones that run for the rest of the processes on vicidial.

As I mentioned I believe not many people are using this feature thats why there is no feedback about it. And the issue presents as soon as calls start to come in, right now I have the same 4 agents taking calls and 8 calls on queue and the load is 39 - 6% (Full recording enabled as well), so no problem there.

Ive tested several different providers and Vultr and Digitial Ocean really deliver in my experience, I not only run Vicidial servers on them but also Asterisk servers that I use as call flow servers which one of them takes around 50 calls per second with no issues whatsoever (of course thats a 16 core, 32 RAM server), but as I mentioned I dont believe the issue is there as the servers runs just fine until I try to use the feature.

[dspaan]

We are also running all vicidial servers virtualized and we also use the new PRESS_CALLBACK_QUEUE feature, it's great. I think still most people use vicidial for outbound and of those that do inbound very few use this feature because it's very new.

We don't experience the problem you describe, i recommend contacting the vicidial group or did you already?

There is also an older version of the PRESS_CALLBACK feature which you can use and works in a different way by creating a copy of the lead on an outbound list.

[williamconley]

If this feature pushes someone back into a queue ... it may be hitting that mystical virtualization barrier on heavily used systems. Queues in Vicidial are CPU intense and a missed cpu cycle (due to virtualization) could have very unpredictable results. While the script may be the same as other events, if this results in the script being required to run continually while trying to acquire an agent to drop the call on ... a single missed ticket can cause death of the script.

Of course, this should be visible in the system when this occurs, since that script would then stop logging and should also show as a zombie or something similar.

We've had some clients institute regular Asterisk Queues for virtualized systems (since they are not cpu intense at all and have no problems with virtualization). They are slower, but inbound and transfers have no requirement for speed by comparison to outbound calling. An extra half second won't kill anyone.