VICIDIAL NOT USING ALL AVAILABLE CHANNELS ON RATIO

[covarrubiasgg]

Hello guys, happy hollydays.

I'm here with a problem i have been trying to figure out by myself for a couple months now, but it is time to ask for help.

We have a setup with 4 phone servers and a total of 210 channels (detailed description below), I can see on the realtime, the server is placing calls, but i am having very low contact rate, so i started debugging if everything is OK.

I noticed that if I run "dahdi show channels" not even half of my channels are in use (about 100 use channels from my 210) even though realtime report show 200 calls ringing.

I check the vicidial_auto_calls and there is indeed the 200 calls, but most of them has channel as NULL

If we switch from RATIO to MANUAL, we can see a much better channel allocation, not my 210 channels because we dont have that many agents, but at least a channel per agent, instead of the previosly where we were using only 100 channels when 160 agents were logged.

Already try to play with MAX TRUNKS, CALL PER SECOND, disabling DIAL BALANCE on the servers with less channels Avaialble and also using the BALANCE RANK to get priority on the server with most channels. But results are the same.

I dont think servers are overloaded, Load Average is 1.5 - 2.5
Also I dont think we are overloading asterisk, "core show channels" never show more than 200 channels per server

I dont have much experience with Digital Telephony, so I dont know if there is any configuration i can change on DAHDI or wanrouter ( for the servers with Sangoma )


Do you have any idea on why when the CAMPAIGN is on RATIO it does not use all my Avaialble channels ?


CALL CENTER OVERVIEW

160 AGENTS @PEAK
Total Channels Avaialble: 210

CAMPAIGN DETAILS

DIAL METHOD: RATIO
DIAL LEVEL 3.0
FORCE_RECORD_ALL // Converting to MP3 is done during night after hours
NO AMD


BUILD VERSION: 2.14-704a BUILD: 190312-0928

ARCHITECTURE

Database
Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz + 64 GB RAM
SAS3108 12Gb/s SAS RAID-on-Chip (ROC) w 8 x SSD RAID 1 + 0 ( 6 actice drives + 2 hot spares )
- ViciBox v.8.0.1

Web Server 1 / Web Server 2
Intel(R) Xeon(R) CPU E31220 @ 3.10GHz + 32Gb RAM
- ViciBox v.8.1.2

Phone 1 / Phone 2
Intel(R) Xeon(R) CPU L5520 @ 2.27GHz
Sangoma Technologies Corp. A200 ( 1 E1 + 1 Empty port ) [ 30 Channels ] (Each server Phone 1 and Phone 2)
- ViciBox v.8.0.1

Phone 3 -
Intel(R) Xeon(R) CPU X5550 @ 2.67GHz +16GB RAM
Sangoma Technologies Corp. A200 ( 2 E1 ) [ 60 Channels ]
- ViciBox v.8.0.1

Phone 4 -
Intel(R) Xeon(R) CPU X5550 @ 2.67GHz + 16GB RAM
Digium, Inc. Wildcard TE235/TE435 quad-span T1/E1/J1 card ( 3 E1 + 1 Empty port ) [ 90 channels ]
ViciBox v.8.0.1

Archive Server: External FreeNAS via FTP

PHONE SERVERS

Asterisk 11.25.1-vici
BALANCE DIALING: Y
Balance Rank: 0

[williamconley]

The scripts that run in screens (screen -list) manage the decisionmaking on each dialer. If you look at them, you will find one responsible for constantly checking the campaign(s) and deciding when and how many calls to make.

Note that if that script generates calls, and those calls terminate (busy, drop, etc) at some point, there is often a delay in generating a new call to replace the now-dead call based on the behavior of the system. In other situations, it's not so much a notable delay as it is a limitation of the calls per second on your carrier that causes the system to not really be dialing as heavy as it should.

Your description (auto-calls showing higher than real calls), however, tends to lead me towards: Drop Call Seconds. Try setting that to Zero and see if you have improvement. That setting being zero has been known to immediately generate a new call for each call termination instead of assigning that dead call to a "have a look in a few seconds" script which means the call is gone and no new call will be generated until the harvester script runs. That also tends to cause "bunching" because when the harvester script runs, it causes all the defunct calls to be replaced at the same time, generating a bunch of simultaneous calls. Many of those calls will then get answered simultaneously, causing yet more drops. Better would be to have the drop call seconds set to zero so they generate as they die, which tends to randomize the outbound replacement call. It's also worthy of an attempt (if bunching is in fact occurring) to limit your outbound calls to 1 call per second for each 10 agents on that campaign. This can be a logistical problem to calculate, but has been known to stretch out the dialing so calls do not arrive all at once any more.

Happy Hunting!

[covarrubiasgg]

First, thanks for the reply and detailed answer

Drop Call Seconds. Try setting that to Zero and see if you have improvement.

Will give it a try for sure

It's also worthy of an attempt (if bunching is in fact occurring) to limit your outbound calls to 1 call per second for each 10 agents on that campaign. This can be a logistical problem to calculate, but has been known to stretch out the dialing so calls do not arrive all at once any more.

Woah! Thats a handy rule, We dont use any trunk limit per campaign, but i will give it a try with our overall load. But this brings me a question. We have different number of channels on our server i.e Phone1 30 channels, Phone 2 30 channels, Phone 3 60 channels and Phone 4 90 channels..... so if we have 150 agents total, that means we should have 15 CPS, So i will try something like Phone1 2 CPS, Phone2 2 CPS, Phone3 4 CPS, Phone4 7 CPS

Also ours channels are un-even acros the servers, but the agents do spread evenly across all servers. Do you think this might be and issue?, I mean at some point we may have 35 agents on a server with only 30 channels and 35 agents on a server with 90 channels. We use Phone Aliases (All extensions on All Servers) and Vicidial handles the balancing for the agents.

[ed123]

Verify with you're VOIP, how many channels were open for you to use.

[covarrubiasgg]

Hi ed123, unfortunately we are not using VoIP, we are using Digital E1s

[williamconley]

also try debug mode in the asterisk cli to see if some of the calls are failing to initiate, which could cause them to get lost and stuck in the auto-calls table without an actual call. Timing is important with oddly generated calls such as E1/T1 and GSM gateways

[ccabrera]

Gabriel,

Here are some suggestions which have proven me useful in scenarios like yours:

1. Oversell your trunks. If one server has 30 channels, tell Vicidial he has 36, so more calls are tried. Then set a higher RATIO level until you begin to see CHANUNAVAIL status in the carrier stats (that would be your limit).

2. Check the --delay option inside the FILL script which runs in one of your server. That allows you to set the delay between FILL loops, so that calls in the cluster are assigned to agents quicker.

3. If hardware allows you, place all cards inside one box and set it as a VoIP gateway, so that your servers can take any amount of lines they need regardless of how many E1s each one has.


Hope this helps.