Disconnected (ADC) and Operator Question

[csbe]

Hey everyone. We've recently moved from a hosted dialer to Vici. Things are working well. However we noticed one big difference. Our old dialer automatically notices almost 8x as many Disconnected numbers and "Operator Intercepts" (ie "The verizon custom you are trying to call is no longer available..").

Vici identifies much less (as ADC status). I'm guessing these are mostly going into Asterisk AMD rather than the ADC status.

We like to know the difference between a consumer's answering machine, and a disconnected number/operator because the latter we'll never call again.

Any ideas on why vici would be catching so many less of these?

Vicibox 6.0.4 from Vicibox_v.6.0.x86_64-6.0.4.iso | ViciDial SVN Trunk v.2.10-443a build 140617-2017 revision 2130 | 1.8.32.3-vici | Multiple Servers: 6 Dial - 1DB - 1 Web| Amfletec VoiceSync PCI Chips | No Extra Software After Installation | Intel MultiCore Processors

[williamconley]

Admin->System Settings->Enhanced Disconnect Logging.

If this is not present, you may need to upgrade.

[csbe]

Thanks William. This will just use flag more codes as "ADC"? I left this off because in the help it says the following (and we're USA only):

Enhanced Disconnect Logging -This setting enables logging of calls that get a CONGESTION signal with a cause code of 1, 19, 21, 34 or 38. We usually do not recommend enabling this in the USA. Default is 0 for disabled.

[williamconley]

I think you'll find out if you test it. We always turn it on. By default. For all new client servers.

Depends on your carrier's signalling, but seems to work very well.

And you'll need your dial timeout to be 45 seconds to allow reception of the signal (many carriers do not send that signal until after 40 seconds of ring time). Note that by Carrier here, we mean the carrier of the call recipient, not your carrier. Your carrier just passes the signal through (if they're normal).

[csbe]

Hmm, we turned it on and every single call didn't go to an agent.

Something weird is happening. I've asked the carrier to confirm the disconnect codes, and we're going to check the carrier logs.

If we implement Sangoma CPD will these signals trump that, or will Sangoma pick it up?

[williamconley]

The theory is that Sangoma is better at this. But mostly it's for AMD, and I'm not sure if you can turn off the AMD (which can be problematic as it causes a 2 second delay ...). However, if you're using AMD then sangoma could be helpful.

Set up a virtual sangoma server with a test line and see if it helps or hinders.

Also, your carrier is not likely to be altering the disconnect codes at all. It's the carriers of those you're calling. If your carrier is altering the codes in any way, you need to change carriers. Which brings up the next question inevitably: Please tell me you have three carriers at least? (Most do not charge a monthly fee, so any funds on the account will carry over forever ... excellent for testing!)

[csbe]

Yeah we're working on setting up Sangoma now. Ideally we can figure out something on our end to get the disconnect stuff handled properly, then have Sangoma catch the "90-95%" of the answering machines. Still no idea why every single call didn't go to an agent when I turned on enhanced logging. Looking into it...

I'm a bit hesitant to set the dial timeout to 45 seconds, we're at 25 seconds now after a bunch of trial and error and that seems like a sweet spot. But I guess if we're doing a better job of detecting answering machines maybe a long dial timeout won't make a huge difference anymore.

We actually have exactly 3 carriers, so don't worry hah (however we're only using one for live dialing, with the other two as backup/testing).