vicidial.org

Hello,

We have set up a campaign with three classes of leads in three different lists. The leads in the first list we'd like to dial with Answering Machine Detection (AMD) turned OFF (Routing Extension 8368). When dialing leads in the other two lists, we'd like AMD turned ON (Routing Extension 8369). We tried splitting the campaign into two campaigns, but we also have a lead priority algorithm (which uses the lead rank) which falls apart when the campaign is split into two separate campaigns.

In an attempt to resolve this problem, I found that I could modify the file /usr/share/astguiclient/AST_VDauto_dial.pl and forcibly set the variable $VDAD_dial_exten = '8368' if the list ID is equal to the list ID of the first list (This change is made at around line 1383 in AST_VDauto_dial.pl - version 2.14).

This works great on a stand-alone VICI server!

However, when attempting to get this working in a clustered environment, it does not work. (Our cluster consists of 4x Web Servers, 8x Dialers and 2x DB servers). I have modified the /usr/share/astguiclient/AST_VDauto_dial.pl on all Dialer Servers and on all of the Web Servers (mainly because I'm not clear on which server should be executing this script -i.e. shotgun approach).

I realize that there may be a better way to do this, so here are my questions:

1. Can you suggest a better way to implement this so that leads from one list are dialed with AMD disabled and leads from another list are dialed with AMD enabled within a single campaign? (i.e. one where I don't have to modify the source code).

Assuming the method I've discovered is the best way for now - here is an additional question:

2. In a clustered environment, where is the AST_VDauto_dial.pl loaded from? I've found similar code in AST_VDauto_dial_FILL.pl and have made similar code changes here without success. However, I have NOT made the changes in the /usr/src/astguiclient/trunk/bin/ version of these files as I've assumed that these are used primarily for source management?

As you can probably tell from my question, I'm fairly new to VICI and its internals. So, any help would be appreciated.

Regards,

Peter Manley

Here are the specifics of our installation:

VICI version: 2.14-708a Build: 190414_0924
Linux Distro/Kernal version: SUSE Linux 4.4.176-06-default
PERL version: v5.18.2
Asterisk version: 13.21.1-vici
MySQL version: 10.2.23-MariaDB-log OpenSUSE package

Create a new extension not presently in use. Create a copy of the AMD script and modify it (preferably using a DIFF, more on that later!!) to suit your needs. Point the new extension to the copied AMD script instead of the original. Copy that script to all servers and be SURE to enable the execute bit (chmod +x). It's only needed on Dialers (the dialer that generated the call, which would be for an agent on that server in MOST but not all cases ...) so Just copy it to all servers to skip the drama. Remember that when you upgrade, the AMD script may get changes as well. Create a new DIFF if you need to after any upgrade, but if you're lucky the DIFF will "just work" against the new AMD script (it doesn't change very much that often, but Asterisk requires changes sometimes ...).

The script to change/update and the location to store it is in the asterisk agi-bin, not the version in /usr/src/astguiclient/trunk (that's the repository, the location from which the Vicidial Installer grabs its files, the LIVE files are in other locations that are not in /usr/src, but in /usr/share and /var/lib and /srv/www etc). use updatedb and "locate" to find the non-usr/src/astguiclient location of any file.

This is also an unusual scenario and I like to see systems that are "upgrade-proof". The first way I thought of to make these upgrade proof would be to just create a new single-purpose AGI script that checks the list ID (or a value in the list id name/description field, so you don't have to hard-code it and edit every time you add a new list!). If the List Name contains a keyword, initiate AMD (by sending the call to the appropriate AMD extension) if not, send the call to 8368. You could even put "ext=8368" directly in the Description field to make it cut-and-dried. A cleaner approach would be to use a key-value pair in the Settings Containers for any lists that require override with a "default" key-value for those that don't have an entry or just use the default campaign routing exten for those without an entry (this would avoid having an unprofessional entry in the Description field, but you'd need to become familiar with Settings Containers). This script would then be required on all Dialer (put it on all servers to be safe). And given the odds, the asterisk upgrades over time would eventually require some upgrade on that script but it would be very obvious and NOT be integrated into an existing Vicidial script at all. So MOST upgrades would likely leave this script entirely unaffected and your Custom "Campaign Routing Extension" would just continue to work after an upgrade without having to re-edit the AMD or any other script.

If you posted your result to the Core (Vicidial Issue Tracker link above) you may even be lucky enough to get this added as a feature and just have a "List Routing Extension Override" after one of the next upgrades. Cool feature. Probably at least 3-4 hours of production and testing. But cool.

Thanks Bill (I hope you go by Bill ),

I was able to determine that the script being executed was on our MASTER DB server in /usr/share/astguiclient/AST_VDauto_dial_FILL.pl. For now, I have modified this file to include a condition to change the $VDAD_dial_exten = '8368' if the list_id is equal to the one we want to override. But, I like the option you've described to make this "upgrade-proof". I'll work on implementing this over the next few days. I'd love to see this implemented in a future upgrade as a "List Routing Extension Override" feature. That would be cool . So, I'll post this request to the Core in the Vicidial Issue Tracker.

Regards,

Peter M.

Hi Bill,

It doesn't look like I have access rights to the issue tracker. If you feel that this feature is worthy of submission as a candidate feature for a future release, can you please add it?

Thanks,

Peter M.

All you need do is request an account on the issue tracker. It's not about "rights", it's a separate system.

The best method of approach is to build it, DIFF it (both preferably with the most recent SVN revision installed, so the DIFF is Very Fresh). Then post the issue in the issue tracker, and a link to that post here to bring the discussion and the issue to the same place.