vicidial.org

Hi,
I have installed 2 different versions of Vicidial on dedicated server but having same issue on both, Tried different trunks as well. There is no load, no memory issue

VERSION: 2.14-738a
BUILD: 200210-1628
ViciBox v.8.0.1

VERSION: 2.14-738a
BUILD: 200210-1628
ViciBox v.8.1.2 181002

I have setup simple Campaign with Ratio method, uploaded leads and started test campaign. When client picks up the call, it is transferred to agent after 3-5 seconds which is too much delay.

I have checked basic things but not sure how to properly troubleshoot this issue.

EDITED:

Upon Further checking, when I turn AMD OFF (set routing ext 8368), call is passed to the agent almost instantly but with 8369, there is a delay of 4-5 seconds

You have NOT installed two different versions of Vicidial. Both installations are VERSION: 2.14-738a. That's the Vicidial version and is the same on both systems. You used two different Installation .isos, but those merely account for the operating system and Environment in which Vicidial runs. All Vicibox installers install the Latest version of Vicidial, but each will have a slightly different environment including the Operating System, Asterisk version, MySQL version and lots of other package difference possibilities. In the end, however: Vicidial is the software you interact with in the Web interface and the software that controls the calls.

Next up: You're missing a major piece of information. The hardware upon which this installation has occurred. For instance: Is this a Virtual machine? If so ... that's your problem. Install it on a physical server and you'll get your speed. Vicidial uses hi-res perl timing which requires every "tick" of the system clock. Sharing that system clock in a virtualized environment is NOT supported.

If the system is not virtualized at all, then you'll need to find out where your bottleneck is. Is the command to transfer the call sent immediately but only acted upon later? Or is the command sent after the delay?

The methodology here is that there is a perl script running and controlling the call after it is answered. At the moment of answer, extension 8368 is fired (is that immediate or delayed?). After 8368 fires, it starts up a perl script and that perl script is expected to make a decision about which agent should get the call. So ... does that script fire immediately when expected or is it delayed? Is that script running quickly (as in under a second) or is it delayed?

OR are you even using 8368 at all? Are you using a different campaign routing extension that incurs a delay such as the AMD extension?

Happy Hunting!

Oh: I see you edited it with AMD. Yep, AMD requires at least two second to run. Vicidial itself has about a 1 second delay (perhaps 1.5) so a 4 second delay is completely normal if you use AMD. Always has been. Don't use it if you want to avoid the delay. Let an Agent decide if there's a machine, and if there is have the agent push the VM button (which can be automated to leave a VM message by the system if you like, releasing the agent for the next call immediately).

Thank you William for your quick response, always taking out your time to help others.

I never noticed before that it takes this much time And yes after thinking a little its seems logical that it would take few seconds to detect.
A quick question, should client hear the sound of transferring call to agent?

There is no sound involved in the transfer. But there is an alert sound when the lead is admitted to the meetme conference. This alerts all other participants in the conference (in this case, the agent) that someone has arrived. Unfortunately, to let the agent know "new lead arrived" also incurs the penalty of the newly arrived lead hearing the same tone. Without that tone, your agent would likey just sit there and remain silent. It can be turned off, but I wouldn't recommend it.

On our side we've done code customisation and disabled the alert tone for MeetMe and added code to play a custom tone only to the agent. This also gave us the opportunity to play a LOUDER, multi-beep tone to wake up distracted agents. Plus we could play a different tone for Inbound calls so that the agent knows to greet the person differently.

This is for debt collection call centres - debtors don't like being called and will put the phone down if there's any hint that it's a call centre. AMD delay is an unfortunate part of using the automated Answering Machine Detection and is thankfully not as much as 5 seconds for most calls - so acceptable. The other key thing is to train agents to say "Hello" the instant they hear the beep because the customer has already said their "Hello" 2-5 seconds earlier and is at risk of cutting the call.

It's not necessary to "customize the code" to turn off the sound: It's just a change to the extensions.conf file. To play a whisper/spy sound ONLY to the agent is a popular modification, we've had a few clients pay for this in various versions of Vicidial over the years.

But: To play a sound for inbound specific to an inbound campaign does not require custom code. This is a setting in the ingroup. We have many clients who have multiple ingroups representing different companies, and the agent MUST know which company they are representing. For this, the built-in solution allowing the playing of an audio file to the agent before dropping the call into the meetme conference is excellent. "Answer as XYZ corp" ... then "bleep" and a lead is dropped into the conference. Perfect.

AMD is always 2 seconds. The normal Vicidial routing delay is about 1.5 seconds. Total: 3.5 seconds. Too much for debt collection, arguably too much for any call center. However: Properly trained agents who begin talking at the earliest possible moment from their script can make up for the delay by minimizing the "human" delay. Bad agents will think ... inhale ... and say "um ... hello?" and blow the whole deal.