Reduce Initial Outbound Caller Lag

[escondido]

My system is setup as follows

-outbound calls only
-2:1 dial ratio
-AMD on, but no message is left
-Dial time out is 30 seconds
-Agent screen automatically shows pop up script for each call that is answered

The issue I'm experiencing is that my agents aren't hearing the initial, "Hello" from the caller. There seems to be about a 2-3 second delay from the time the caller picks up before the information is populated on the Agent Screen, Script comes up, etc. I'd love to reduce that time down, if possible.

I've been training everybody to immediately launch into the script once they hear the bloop sound and the script pop ups. It's not ideal, but it works most of the time.

Does anybody know if there are any changes I can make to reduce the initial lag? The only suggestions I've read so far are to turn off AMD, but I tried that and the results are the same. Plus, it's not very productive.

I welcome any and all suggestions. Thanks.

[mflorell]

If the information in your signature is correct, you are running very old software.

I would recommend:
- upgrading to the latest svn/trunk revisions of VICIdial
- reinstalling your systems using VICIbox 8, on dedicated hardware(no virtual machines!)
- using Asterisk 13(which is the default with VICIbox because it is much faster than previous versions

[escondido]

Yeah, I agree with you at this juncture. I've been using GAD for a few years now, but this is the first time I've used a test server vs buying seats. It's a fun learning curve. The plan is to move over to OVH, Hetzner or somebody local here in the USA after the testing phase is completed.

I had NO IDEA there were so many features missing because I was unaware the ViciDial Web GUI was installed. GAD definitely looks better, but it's been one headache after another.

I appreciate everybody's input.

[williamconley]

And for the record, there is no "cloud". There are computers somewhere else. There are virtualized computers. There are Amazon EC2-type shared-resource services (which is as close to "cloud" as you get). But no cloud. So just list the server-hosting-service or Amazon or Vultr server type you're using in place of "cloud".

And yes, virtualized servers will always (always) have timing issues that impact negatively on all timing-related functions. It's different for every service provider and software base. It's even been known to be different from install to install. But virtualized Vicidial is only viable for one or two agents and testing. Perfect for development/sandbox/proof-of-concept servers, though. To get a virtualized system with enough power to actually run a real room with Vicidial wastes more resources than it saves by an order of magnitude. The only way it's useful if you have some reason to need to use High Availability or to generate new servers on the fly to ramp up and ramp down quickly, which really doesn't happen very often (and when it does it usually costs much more than just putting down a hardware based system in the end. MUCH more, lol).