vicidial.org

Hey everyone,

I've been tasked with taking over an existing vici cluster, based off goautodial 2.1CE, but effectively a scratch install at this point.

I went through doing spring cleaning, removing old customers agents & extensions, renaming groups to accurately reflect reality, and moving users to contiguous blocks of extensions. Agents are 9500-9550, closers are 9551-9599, etc.
After doing this, the dreaded time sync error occurred.
I set NTP up on dialer1, and pointed dialer2, db, and clients to it.
Asterisk 1.4.44 was in use. I downgraded to 1.4.39.1-vici.
Vici was sort of upgraded to 2.4, but not completely. I finished the upgrade to 2.4 (mostly MySQL missing tables), then up to 2.6-392a build 130102-1135

After all of this, I verified normal inbound/outbound/station to station/xfer/etc were working correctly.
When we tried to fire up an existing campaign, using an existing list, there's no indication vici is pulling the caller into the conference room.
I set up a new test campaign, loaded an existing test list, and successfully predictive dialed myself with 2 way audio.
I cloned the old campaign.. no customer in the conference room.
I used the old list on the test campaign.. no customer.

So, any idea why my conference rooms are so lonely? Or any suggestions on where to look?

Oh, server specs: 8 core Xeon E5345 @2.33Ghz, 16Gb RAM, and RAID 10'd 10k RPM SAS drives.

time sync error often is entirely unrelated to time. often it related to network connectivity (or lack thereof) and/or identity of the server.

are your servers all communicating well between them and to the agents? (No dropped packets)

Did you modify the IP address of any of the server during your spring cleaning?

Last but not least: a "partially upgraded DB" (especially one missing tables!) can be the death knoll of a system. We've never had this problem in-house or during one of our installs, but we've "picked up the pieces" of some bad technicians and had to hand-sort issues created by rampant customizations gone awry.

You should consider a simple reinstall and re-adding your Lists/leads/ingroups/campaigns/phones into a clean system. It may allow you to keep your hair and have a fresh solid machine with which to move forward.

You can also attempt to troubleshoot with:

screen -r asterisk

which may show you a crash in an agi script invisble elsewhere.

and try the logs at: /var/log/asterisk and /var/log/astguiclient

Happy hunting and here is the Standard Comment to start you off:

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

Thanks for the reply William! I've updated my sig with my hardware.

williamconley wrote:time sync error often is entirely unrelated to time. often it related to network connectivity (or lack thereof) and/or identity of the server.

Or missing screens. Seeing that was what led me to discover the MySQL disaster.

williamconley wrote:are your servers all communicating well between them and to the agents? (No dropped packets)

The servers have a copper GigE switch to themselves, and clients all connect via wired 100M ethernet. No loss, lag, or jitter that I've measured.

williamconley wrote:Did you modify the IP address of any of the server during your spring cleaning?

Yep, went from public IP to internal IP back to external IP via the ADMIN perl script.

williamconley wrote:Last but not least: a "partially upgraded DB" (especially one missing tables!) can be the death knoll of a system. We've never had this problem in-house or during one of our installs, but we've "picked up the pieces" of some bad technicians and had to hand-sort issues created by rampant customizations gone awry.

Oh yea... that pretty much describes this setup. Someone installed FreePBX, FOP2, iSymphony, asternic cdr, a half-dozen copies of vtiger, a couple badly modded copies of goautodial, and a local mysql instance on the dialer for FreePBX.

williamconley wrote:You should consider a simple reinstall and re-adding your Lists/leads/ingroups/campaigns/phones into a clean system. It may allow you to keep your hair and have a fresh solid machine with which to move forward.

Should I attach the new instance to the existing database server, or rebuild the cluster from scratch?

williamconley wrote:screen -r asterisk
which may show you a crash in an agi script invisble elsewhere.

Hmm, my asterisk wasn't living in a screen; it's just started as a service. Should asterisk be invoked via start_asterisk_boot.pl instead of init.d?

If possible, I would merely reinstall from the latest version of Vicibox 4.X .iso and then call it a day. Considering the damage done by the previous Tech, i would bring along only your leads (download, rebuild, upload) to avoid any possible infection from the previous weirdness. You could be up in about an hour that way. (Single server ... add another 30 minutes for each clustered server ... and possibly some Learning Curve time)

Starting from scratch was definitely the best idea, though the forced migration has been a PITA. So many half-completed dialplans surrounding the 1 that's actually functional, so few comments... And tracing through FreePBX, vici, and custom dialplans is enough to make my head spin.

But it lives, and barely cracks idle with 15 agents and 3 closers. Good thing too, the next 10 agents start tomorrow!

Rule of thumb: 25 agents per server. If you are approaching that, it is a good idea to have a second dialer acquired and clustered into the first in anticipation of load issues.