vicidial.org

Hi,

We are experiencing intermittent dropped calls which are caused by overdialling when agents are spread across multiple tel. nodes.
This raises serious issues with the new UK OFFCOM drop calls rules in place we strictly follow.

Campaign settings are Ratio, dial level 1, available only tally= YES, agents logged on multiple tel. servers in same cluster, Next Agent Call - highest wait time, campaign routing extension 8368, no trunk shortages/LB calls- all tel. node has plenty of trunks. All agents do not pause or log off during shifts, they only use pause after call and that's strictly enforced.
Happens on production servers with no load etc. issues and is quickly reproducible on a development cluster with only 2-4 agents logged in.

When all agents are on the same tel. server there are no overdials and dropped calls.

Test scenario:
1) One agent on tel. server A and one on tel. server B.
2) Both agents are in READY, agent on B has higher wait time
3) 2 calls are placed, 1 on A and 1 on B
4) Call on server A is answered and passed to the agent on server B because of its higher wait time.
5) Server B still has 1 ringing call
6) AST_VDauto_dial.pl on server A doesn't seem take into account that there is still ringing call on server B. Server A places a new call since it has 1 READY agent, but the only active call on it is XFER status, the one passed to the agent on server B. That XFER call increments DBIPgoalcalls on server A to 2, because tally_xfer_line = 1 ($DBIPgoalcalls[$user_CIPct] = ($DBIPgoalcalls[$user_CIPct] + $tally_xfer_line_counter)) , then vdautodial log gets Calls to place: 1 (2 - 1 [0 + 1||]) 2 |
7) Now there are 2 ringing calls for only 1 READY agent- the old one on server B and the new one on server A. If both ringing calls get answered, as it happens on campaigns with high answer rate, DROP occurs.

These DROPS are now of a big concern, first because now UK regulations allow a lot less dropped calls, and second, because small campaigns (3-8 heads) with high answer rate do not have a chance to pick up on calls and go below the target drop rate and have to be reverted to manual dial midday because they exceed the allowed drop rate.

Are we missing something or is this a long standing issue which happens in rare conditions as above, and needs code changes?

BTW- hope Irma does not cause severe damages...

If you have less than 5 agents, you should be manual dialing instead of ratio dialing.

The example above with 2 agents is for test purposes and simplicity explaining the issue.
Same happens on campaign with say 15 agents when 13 of them are in long calls and the 2-3 ready agents happen to be on different servers, or during break times...

We have campaigns with much higher head count, up to 15, which are also struggling to mantain drop target because of the above issue and have to switch them to manual dial when it's above the target reducing productivity.
These campaigns have low call volume and high contact rate and call duration, because of the quality leads.

Is this a known limitation in code requiring changes?

This was one of the reasons we created phone login load balancing grouping(campaign settings). To force agents on the same campaign to be on the same servers so issues like this don't happen.

Thanks Matt.

Is there a reason why DBIPmakecalls is not decreased with the number of outbound ringing/sent/live... calls on all servers, the same way it's done with the inbound queue no dial option? Wouldn't that fix the overdialling when agents are on multiple servers?

Dialing is done on a per-server basis, if you decrease that variable it will lead to other issues.

Well, there has to be a way to grab the number of excess calls on the other servers and subtract that value from DBIPmakecalls on the local server.

AST_vdautodial log on server B in the test example above, shows Calls to place: -1 (0 - 1 [0 + 1||]) 1 | for a loop, made at the same time when the excess call was initialed on server A...

Same could have been calculated and subtracted from DBIPmakecalls on server A prior to making the excess call. Just not sure what other issues might arise from this, can you elaborate please?
Is it the timing with the AST_vdautodial scripts on the rest of the servers?

Sorry to keep asking, it's a big issue for us, keeping agents on same tel. node one way or another, is quite restricting and imposes limitations in agent's flexibility to change their desks/campaigns/phones when needed. At the same time, current UK regulations for abandon calls are very tight and strict.

We went through this in detail several years ago. Using Phone login load balancing grouping was the best way to deal with agents on multiple dialing servers, and it works very well. There is A LOT going on in the background where changing how one variable behaves has consequences throughout the dialing subsystems.

This is probably one of the most interesting conversations I've seen on here in years. Our experience with this has usually resulted in agents logging out from the "ready" status instead of during the dispo screen, thus stranding the call made for them while they were waiting.

But this sounds like there has (in the past) been a race/collision scenario where asterisk killing a call and the perl script watching the call end tries to modify the DB at the same moment that another script is deciding how many calls to make but since there's more than one server involved in the process the measurements can never be perfect.

I have also bumped into the "generate a new call NOW!" instead of in 15-45 seconds when the kill script runs being a problem in the opposite direction (not enough calls being generated).

I think it would be an interesting experiment to find where the conflict is in the scenario and see if the system has progressed to a point where both challenges can be resolved in some fashion. But I can also say that if Matt says it's a no-win situation, it likely *is*.

Indeed it is interesting.

Don't think the issue has anything to do with collision or asterisk waiting call to hang up.

If you go to the simplified test scenario described above, you should get exactly what and where the issue is. It's rather flaw/limitation in the dial logic, where calls are placed on each server, taking into account only the agents/calls on the same server and being unaware of the (excess) calls placed on other servers, talking about pure outbound campaign.

I couldn't capture details why exactly these excess calls cannot be subtracted from the number of calls to place, the way it's being done with inbound queue no dial option, just taking Matt's word on that as usual, guess they have spent plenty of time on this.

Believe me, if there was a quick fix we would have chosen that over spending all of the time we did developing the PLLB Grouping features.

mflorell wrote:Believe me, if there was a quick fix we would have chosen that over spending all of the time we did developing the PLLB Grouping features.

Oh, I'd never suggest "quick" fix. Not in that quagmire. But finding the precise problem and identifying it in detail has often allowed us to provide a sledgehammer to fix it. Sometimes that sledgehammer causes heavy load, but if load isn't an issue ... at least it's a solution.

But it can't be as bad as "The Fix" from 8 years ago (roughly). That was a biatch.