Auto Alt Dial with Invalid phone numbers

[VFRDavid]

First, let me say that if the data was "good" - this wouldn't have happened, but...just FYI - in case anyone else comes across this...

I have a client that is using the following system versions:
VERSION: 2.14-698a
BUILD: 190207-2301
Version: 2.14b0.5
SVN Version: 3065
DB Schema Version: 1562
13.21.1-vici

Installed pretty recently (this year) via the ISO available for download at that time...Anyway - a client just called me because their agents were suddenly waiting 10+ minutes for a call - I looked at the stuff I usually do (real time screen, vicidial_auto_calls, CLI, Campaign settings, hopper contents, etc) - and nothing jumped out at me right away - until I noticed that 99% of the calls in the vicidial_auto_calls table were various lengths of all zeros...in the MySQL query tool I was using - the "alt_dial" column wasn't visible, unless I scrolled right - and when I (finally) did - I saw that every phone_number with all 000's - was always an ALT dial...I turned off auto-alt dialing, reset the hopper, and the problem went away...then I went to the data, and (of course) found that the list they had just imported and were dialing had the second phone number column zero-filled whenever it didn't have an actual phone number there...

Could / should this have been potentially caught at two places in the system?

1) When we choose the "USA / Canada Check" in the Load New Leads tool - does it check the alt_phone field - or only the phone_number field? How difficult would it be to run the same check on both fields? (Optionally or otherwise). I can see that the phone_number is pretty much a requirement, where the alt_number isn't - so - it would have to only be checked if there is some value there - but - other than that, are there any difficulties?

2) When it goes to dial the alt_number - does it check for a valid / allowed time zone? Seems that if it were checking for valid time-zone - the "all zeroes" (or any invalid NPA/NXX) should cause this to fail? Is this something that is a lot more difficult than it might first seem?

I get that address3 may / may not contain phone numbers - so checking that one might be more optional (unless you do check it - to cover "mixed" data where some records have a phone number there and some have address data?).

Thanks for any feedback on this - and please let me know if there are already options I could have enabled that would have stopped this from happening for them...David

[mflorell]

1) it only checks the phone_number field
2) for standard auto-alt-dialing only the time zone of the phone_number is used

For both of these(and several other) reasons, we created MULTI_LEAD auto-alt-dialing with is far superior to standard auto-alt-dialing, and it is why we almost always recommend using MULTI_LEAD if you need to do auto-alt-dialing.

[VFRDavid]

I haven't looked at multi-lead in at least a few months - but based on the last time I did, especially for someone who only might have one additional number at most - the import for the Multi-lead setup was the deciding point for me (unless I am the one doing the imports, possibly). Anyway - I will take a second look in case this has gotten easy enough for at least some of my end-users to handle it - and then - only if alternate number dialing is critical for them...

[williamconley]

Code: Select all

exten=> s,1,AGI(agi://127.0.0.1:4577/call_log)
exten=> s,n,NoOp(No Dial Pattern Matches This Extension)
exten=> s,n,Hangup


This will "catch and kill" bad phone numbers. Put it in a generic carrier so it's not deactivated when you change carriers.

Without this, a bad number will not match a dialplan. Then the system will attempt to use "s", and fail. And then ... nothing. NO "AGI" so Vicidial doesn't attach to the process and clear the non-existent call from the tables. So those "dialing" entries begin to collect and never clear until the system screetches to a halt.

But with this, Vicidial attaches, the NoOp shows in the asterisk CLI (useful for troubleshooting), and then the Hangup clears the table entries and they no longer block future calls (cuz they're gone!).

[VFRDavid]

Thank you for your reply - I will test it ASAP (to be sure I implement it correctly) - I appreciate the help!