vicidial.org

Hi,

System:
4 Dialer Servers running ViviBox 6.x - All Asterisk 1.8, except one running ViciBox 7.03 (Asterisk 11.23)
1 server DB server (24 cores, 24GB RAM, HD 146Gb SAS). Very fast.
1 WEB Server
90 Users - Dial level 8:1

Many dead calls arriving on Agents. So, I follow all steps on "OUTBOUND DIALING OPTIMIZATIONS" doc.

This is "AST_vdad_debug_log_report.ph" report for yesterday:

Code: Select all

9943 CALLS FOUND
4 SERVERS


FINISHED -
TOTAL ANSWERED CALLS:  9943
LRERR:                 7786  (78.31%)   average 2.722858 sec
preroute:              9925  (average 0.197099 sec)
LRpreroute:            0  (average 0.000000 sec)
nLRpreroute:           9925  (average 0.197099 sec)
uncounted:             0
SERVER SUMMARY -
     191.1.1.87 - AST03 - AST03 - asterisk 1.8.32.3
          TOTAL:        1738
          LRERR:        4837  (278.31%)    average 2.643577 sec
          preroute:     1729  (average 0.272908 sec)
          LRpreroute:   0  (average 0.000000 sec)
          nLRpreroute:  1729  (average 0.272908 sec)
     191.1.1.84 - AST02 - AST02 - asterisk 1.8.32.3
          TOTAL:        1553
          LRERR:        1336  (86.03%)    average 2.721682 sec
          preroute:     1549  (average 0.454953 sec)
          LRpreroute:     (average 0.000000 sec)
          nLRpreroute:  1549  (average 0.454953 sec)
     191.1.1.89 - AST04 - AST/WEB - asterisk 1.8.32.3
          TOTAL:        4872
          LRERR:        993  (20.38%)    average 2.647808 sec
          preroute:     4867  (average 0.118195 sec)
          LRpreroute:     (average 0.000000 sec)
          nLRpreroute:  4867  (average 0.118195 sec)
     191.1.1.81 - DB - DB - asterisk 11.23.1
          TOTAL:        1780
          LRERR:        620  (34.83%)    average 3.464116 sec
          preroute:     1780  (average 0.114814 sec)
          LRpreroute:     (average 0.000000 sec)
          nLRpreroute:  1780  (average 0.114814 sec)


I cound't find meaning for: preroute, LRpreroute, nLRpreroute.

That was more of a failed experiment really. A client paid us to test a few ideas for code and process optimizations and we found out that they had little to no real impact on the speed at which the calls were sent on to agents compared to a default VICIdial setup.

The "preroute" entries are supposed to indicate at which step the call finally routed to an agent, or didn't. Although the example you posted clearly shows something went wrong because the math just doesn't look right.

LRERR is a local resolution error, it means that the carrier hadn't started sending audio right away, so the Asterisk channel hadn't resolved, so the call couldn't be routed yet. With the optimization BETA setup, the call will rapidly keep checking up to 100 times for the channel to resolve, and it will log each attempt and how long it took in a vdad log table.

In the end, the best optimization you can have is to use a fast database server and a good carrier really, and from the high number of LRERRs on this, I would suggest you try out a new carrier.

Thanks Matt.

Carrier is analog lines hooked on Khomp device on a separated server with IAX2 trunks to dialers. There is AMD step before outbound AGI. See my dialplan:

Code: Select all

exten => 8369,1,Playback(sip-silence&alo)
exten => 8369,n,AGI(agi://127.0.0.1:4577/call_log)
exten => 8369,n,AMD(3000,1500,800,4000,120,40,4,256,500)
exten => 8369,n,NoOp(AMD Status: ${AMDSTATUS} - ${AMDCAUSE})
exten => 8369,n,AGI(VD_amd.agi,${EXTEN})
exten => 8369,n,AGI(agi-VDAD_ALL_outbound.agi,NORMAL-----LB)
exten => 8369,n,AGI(agi-VDAD_ALL_outbound.agi,NORMAL-----LB)
exten => 8369,n,Hangup()


Local channel still existing on AMD step? And possibly no audio on it?

Analog lines are horrible for answer detection in Asterisk. We recommend using just about anything else.

We never recommend anyone use AMD, mostly because of the average 30% false-positive rate, meaning 3 out of 10 calls it codes as a machine are actually a human.

Given those two conditions, I'm not surprised at the stats you showed.

Analog lines are client decision based on costs and they're warned about problems on answer detection.
They make 100k calls to get 10% positive (agent talking with customer). So, AMD is a must. we just redial to false-positive. Mute call is about 4% and Voicemail about 5% of 10k taken calls.

They are just happy with numbers. I'm not.