vicidial.org

Hi guys,

I already discovered that when testing our system. Now it is productive. We just tested again, logged in one agent, set him to ready and dialing starts. But in the call_log there is a 14 second delay between the calls.

here is an abbreviated version of the call_log table

Code: Select all

start_time             start_epoch   end_time                end_epoch        length_in_sec
2012-04-23 13:40:50    1335181250   2012-04-23 13:41:11        1335181271        21           
2012-04-23 13:40:15    1335181215   2012-04-23 13:40:36        1335181236        21           

As far as I know, my collegue has the dial timeout set to 20 seconds. We would like to have the next number dialed immediately. Why doesn't that happen?

We are wondering if that is also the case when we are dialing out with +100 agents logged in and ready to take calls. Of course our system dials like there is no tomorrow, but we are still wondering. Any hints on that?

Thanks a lot in advance.

Cheers,
Marcus

Please do not do this:

latest SVN release with some PHP adaptions

List the actual vicidial version WITH BUILD.

Perhaps if you are wondering about the timing of the outbound calls ... you could share your campaign settings? Number of agents, available only tally, all sorts of settings have an effect on how many channels are dialed and when. Including the termination timing of the prior calls and drop call seconds.

Consider (as a test) setting your drop call seconds to Zero.

I just updated my signature. We tested with the following settings:
1 agent
available only telly = Y
dial level = 1
dial timeout = 20
drop call seconds = 5

we will test with "drop call seconds = 0". I will update this post, when we did and tell you the result.

UPDATE:
we set the "drop call seconds = 0" and now the delay between calls is reduced from 14 seconds to 5 seconds. But this does not make any sense. We are dialing out, then dial timeout is reached. Why should the parameter "drop call seconds" even be considered in this case?
I guess we will have to write another patch

I have been wondering about this for a long time and now when I got this info about "drop call seconds" I was able to dig further,
found that AST_VDauto_dial.pl checks if "dial timeout" + "drop call seconds" is more then "call end time" - "call start time"
and does this for every call, LIVE/XFER/SENT and so on.
I made the script compare only with "dial timeout" on every status except LIVE,
and when there is a LIVE-call it will add + "drop call seconds"
this will remove calls faster but hold on to a LIVE-call for "drop call seconds"


Testing:

Vicibox Redux 3.1.9 i686 (svn) | Admin: 2.4-354a 120104-2024 | Agent: 2.4-340c 111227-1940 | SIP | Linux 2.6.34.10-0.4-pae #1 SMP |
astGUIclient 2.4b0.5 | Perl v5.12.1 | Asterisk 1.4.39.2-vici | PHP 5.3.3

all calls are normal NA (No Answer AutoDial)

some info about the campaign:
only outbound calling
number of agents: 1
available only tally: Y
dial method: ratio
dial level: 1
dial timeout: 20 seconds
drop call seconds: 5


call_log:

Code: Select all

| uniqueid         | channel                            | type  | number_dialed | start_time          | end_time            | length_in_sec |
+------------------+------------------------------------+-------+---------------+---------------------+---------------------+---------------+
| 1335188553.36739 | Local/90047XXXXXXXX@default-8aea,2 | Local | 90047XXXXXXXX | 2012-04-23 15:42:33 | 2012-04-23 15:42:53 |            20 |
| 1335188518.36736 | Local/90047XXXXXXXX@default-5693,2 | Local | 90047XXXXXXXX | 2012-04-23 15:41:58 | 2012-04-23 15:42:18 |            20 |
| 1335188483.36733 | Local/90047XXXXXXXX@default-44fa,2 | Local | 90047XXXXXXXX | 2012-04-23 15:41:23 | 2012-04-23 15:41:43 |            20 |
| 1335188447.36730 | Local/90047XXXXXXXX@default-ea32,2 | Local | 90047XXXXXXXX | 2012-04-23 15:40:47 | 2012-04-23 15:41:07 |            20 |
| 1335188412.36727 | Local/90047XXXXXXXX@default-56a5,2 | Local | 90047XXXXXXXX | 2012-04-23 15:40:12 | 2012-04-23 15:40:32 |            20 |

between these calls there are: 15, 16, 15, 15 seconds as you can see


applying patch:

Code: Select all

--- AST_VDauto_dial.pl.orig   2012-04-24 10:16:43.000000000 +0200
+++ AST_VDauto_dial.pl   2012-04-24 11:38:26.000000000 +0200
@@ -1420,7 +1420,7 @@
       #      $event_string = "|     vac test: |$auto_call_id|$CLstatus|$KLcalltime[$kill_vac]|$CLlead_id|$KLcallerid[$kill_vac]|$end_epoch|$KLchannel[$kill_vac]|$CLcall_type|$CLdial_timeout|$CLdrop_call_seconds|$call_timeout|$dialtime_log|$dialtime_catch|$PARKchannel|";
       #      &event_logger;
 
-            if ( ( ($dialtime_log >= $call_timeout) || ($dialtime_catch >= $call_timeout) || ($CLstatus =~ /BUSY|DISCONNECT|XFER|CLOSER/) ) && ($PARKchannel < 1) )
+            if ( ( ( ( ( ($dialtime_log >= $CLdial_timeout) || ($dialtime_catch >= $CLdial_timeout) ) && ($CLstatus !~ /LIVE/) ) || ( ($dialtime_log >= $call_timeout) || ($dialtime_catch >= $call_timeout) ) ) || ($CLstatus =~ /BUSY|DISCONNECT|XFER|CLOSER/) ) && ($PARKchannel < 1) )
                {
                if ( ($CLcall_type !~ /IN/) && ($CLstatus !~ /IVR/) )
                   {

call_log:

Code: Select all

| uniqueid         | channel                            | type  | number_dialed | start_time          | end_time            | length_in_sec |
+------------------+------------------------------------+-------+---------------+---------------------+---------------------+---------------+
| 1335259457.42180 | Local/90047XXXXXXXX@default-5ce7,2 | Local | 90047XXXXXXXX | 2012-04-24 11:24:17 | 2012-04-24 11:24:38 |            21 |
| 1335259435.42177 | Local/90047XXXXXXXX@default-8282,2 | Local | 90047XXXXXXXX | 2012-04-24 11:23:55 | 2012-04-24 11:24:15 |            20 |
| 1335259412.42174 | Local/90047XXXXXXXX@default-4712,2 | Local | 90047XXXXXXXX | 2012-04-24 11:23:32 | 2012-04-24 11:23:52 |            20 |
| 1335259389.42171 | Local/90047XXXXXXXX@default-38aa,2 | Local | 90047XXXXXXXX | 2012-04-24 11:23:09 | 2012-04-24 11:23:29 |            20 |
| 1335259366.42168 | Local/90047XXXXXXXX@default-596a,2 | Local | 90047XXXXXXXX | 2012-04-24 11:22:46 | 2012-04-24 11:23:06 |            20 |


here there are: 3, 3, 3, 2 seconds between calls


Tried if drop still works as it should and yes, the test-call was hold on to for 5 seconds before hung up.

I don't know about inbound or other methods if there could be problems with this change to the if-statement

thanks for your detailed answer. I didn't find the time yet to check this, since we are dealing with "bigger" problems right now

I will answer asap and tell you our results.

Hi DomeDan,

we applied your patch for FastAGI_log.pl on the 26th of march,:q
mentioned here:
http://www.vicidial.org/VICIDIALforum/v ... =4&t=19289

unfortunately we didn't see a big change in productivity. now we hope the following patch will help a bit more

Now we are patching AST_VDauto_dial.pl and we are curious about the results. I guess I can tell you on monday how todays shift went. Have a nice weekend!

Cheers,
Marcus

Cool!
yeah the first patch will only be noticed if theres a lot congestions (bad numbers) in the list.
I recommend using my "real-time carrier report" script to get a view of what is happening, I would compare it too looking at the asterisk cli but more human-friendly http://www.vicidial.org/VICIDIALmantis/view.php?id=518

I'm looking forward too hear about the results! have a nice weekend you too!

Regards