vicidial.org

Hi every one.

I have this question:

We configured a CAMPAIGN with some status in lead recycling. One of this status is DROP.

We define an attemp_delay of 1800 seconds.

In some hours we have a big call load and this cause more DROPs than usually. All this leads will be recycled with the same attemp_delay and they will be inserted in the hopper list almost at the same time, causing a new overload and new DROPs for the same leads.

There is a way to add a little random time to the attemp_delay to avoid this behaviour?

I looked into AST_VDHopper.pl and I find the following instructions:
$LLCT_DATE_offset = ($LOCAL_GMT_OFF - $default_gmt_ARY[$dgA]);
$LLCT_DATE_offset_epoch = ( $secX - ($LLCT_DATE_offset * 3600) );
$Rtarget = ($LLCT_DATE_offset_epoch - $recycle_delay[$rc]);

If i change it with the following, Have I the desired behaviour (adding a random time between 0 and 300 seconds)?
$LLCT_DATE_offset = ($LOCAL_GMT_OFF - $default_gmt_ARY[$dgA]);
$LLCT_DATE_offset_epoch = ( $secX - ($LLCT_DATE_offset * 3600) );
$Rtarget = ($LLCT_DATE_offset_epoch - $recycle_delay[$rc] + int(rand(300)));

Obviously it could be parametered

Thanks for your attention,

Marco La Delfa

Honestly I've never liked using lead recycling for drops (I think it's only really useful for busy numbers). I tend to have the list order set to RANDOM on the first run then DOWN_LAST_CALL_TIME for subsequent runs. I reset lead call status over night. That way the the drops get called back spread over the day rather than all at once.