vicidial.org

Hi,

I just got done installing Vicibox 7 on Asterisk 13.

Having a problem with outbound calling where the call is being sent to DROP action immediately after the Survey First Audio File is played.

No matter what I set the Survey Wait Seconds & Drop Call Seconds to ( have tried 10,30,60 ) the call is sent to DROP action immediately.

I confirmed it is indeed the DROP action, because if I change it from AUDIO (playing buzz) to going to voicemail, etc, it sends call to the drop action.

VERSION: 2.12-565a
BUILD: 160827-0917

Is this a bug that can be resolved by updating or something?

1) Vicibox 7 on asterisk 13 seems unlikely. But let's explore that ...
* First of all: Vicibox 7 has three versions, and you should have listed the full version (7.0.3?).
* Secondly: Vicibox 7 installs Asterisk 11, not asterisk 13.
2) Have you tested this on a Default Survey (no changes to anything) before attempting to put in your own settings? This is often the best way to verify that you are not experiencing a bug, but actually broke something. Create a fresh campaign and test that it works with live agents using routing extension 8368. Once this is confirmed in autodial mode, change to the Survey routing extension. Make no other changes. If that works, then you should make only one change at a time and test after each to find your problem. Confirm the problem by changing back to verify that this fixes the error.

Time consuming, yes. But effective and free.

Thanks William,

Indeed your right, it's asterisk 11. My bad

I confirmed that it ignores [survey wait seconds] only when [survey method] is set to HANGUP.
-- When I changed [survey method] to EXTENSION which acts like hangup when sent to ext 8300, I noticed it started to work. (I first did what you said by starting with default campaign and first noticed it worked when transferring to a live agent also)

I also discovered that the survey_third_status and survey_fourth_status are only updated if the user listens to the whole [survey third (or fourth) audio file]. If they hang up before this, it never updates the [status] volumn in vicidial_log and vicidial_list. Same with opt-in's. It leaves the status at the original updated state of "PU"

In case anyone else runs into the same problem, I'll let you know what I did in order to change this for my needs, I modified the /var/lib/asterisk/agi-bin/agi-VDAD_ALL_outbound.agi file

In line 1422 I added BEFORE this line:

$AGI->stream_file("$survey_third_audio_file_array[$w]");


The following code which I found later in the route:

$stmtA = "UPDATE vicidial_log FORCE INDEX(lead_id) set status='$survey_third_status', end_epoch='$now_date_epoch', length_in_sec='$drop_seconds', term_reason='CALLER' where lead_id = '$CIDlead_id' and uniqueid LIKE \"$Euniqueid%\";";

$affected_rows = $dbhA->do($stmtA);

$dbhP=$dbhA; $mysql_count='01018'; $MEL_aff_rows=$affected_rows; &mysql_error_logging;

$stmtA = "UPDATE vicidial_list set status='$survey_third_status' where lead_id = '$CIDlead_id';";
$affected_rows = $dbhA->do($stmtA);

$dbhP=$dbhA; $mysql_count='01019'; $MEL_aff_rows=$affected_rows; &mysql_error_logging;

I also added the same above 4 lines after Line 1428, inbetween the { and }.

And to implement the same change on fourth digit, lines 1545 & 1551
And then on line 1721 & 1736 for when they opt in.

Now when a caller presses the 3rd or 4th input digit, or opts in, it updates the STATUS field immediately.

I haven't used this features on previous versions of VICI, so I'm not sure if this is how it's always been.

Thanks so much for your help.

I suspect it has always been this way as a feature. If someone pushes a button without listening to the recording, the response could be considered random button pushing instead of an actual response. But I bet there's a timer involved (as in XX seconds of the recording must play for the button press to be considered "real").

You may want to investigate the threshold and decide if the modification of the threshold is better than simply discarding it.After all, you'll upgrade some day and this will revert and you'll forget it ... so it may turn out that the original threshold would be "ok" in that circumstance.

Good postback!