Point a campaign at it.

Everything turns on a single campaign setting.

In VICIdial, a campaign decides where an answered call goes to be judged. The setting is Routing Extension, in Campaign Detail. On a stock install it reads 8369, which is the dialplan extension that runs Asterisk's own detector.

You are going to add a second extension, 8370, that hands the call to AMD Cop instead. Then you change that one field on one campaign from 8369 to 8370.

Nothing else moves. Lists, dispositions, recordings, reports, agent screens, carrier settings and every other campaign stay exactly as they are.

Add extension 8370.

Open your Asterisk dialplan. On a standard VICIdial install that is /etc/asterisk/extensions.conf and the context is [default]. Find the existing 8369 entry and put the new one directly underneath it, so the two live together and whoever reads this file next can see what happened.

; Stock VICIdial detection. Left exactly as it is.
exten => 8369,1,AGI(agi://127.0.0.1:4577/call_log)
exten => 8369,n,AMD()
exten => 8369,n,AGI(VD_amd.agi,${EXTEN})
exten => 8369,n,Hangup()

; AMD Cop. Same shape, different detector.
exten => 8370,1,AGI(agi://127.0.0.1:4577/call_log)
exten => 8370,n,AGI(amdcop.agi,127.0.0.1:8370)
exten => 8370,n,AGI(VD_amd.agi,${EXTEN})
exten => 8370,n,Hangup()

The only line that differs is the second one. Where 8369 calls Asterisk's AMD(), 8370 calls amdcop.agi, which the installer put in your AGI directory. It sets AMDSTATUS and AMDCAUSE the same way AMD() does, which is why VICIdial's own VD_amd.agi on the next line keeps working untouched.

The address at the end is where the engine is listening. Leave it as loopback if AMD Cop runs on the dialer. Otherwise use the address you set as listen in amdcop.conf.

Reload the dialplan and check the extension is really there.

sudo asterisk -rx "dialplan reload"
sudo asterisk -rx "dialplan show 8370@default"

Change the field.

1. Open the administration screen Log in as a user with campaign rights.
2. Admin, then Campaigns, then your campaign Pick one campaign to start with. If you have a low volume campaign on real traffic, use that one.
3. Switch to Detail View The short campaign form does not show the field you need.
4. Find Routing Extension It will read 8369. Write that number down somewhere, even though you now know it.
5. Change it to 8370 and submit That is the entire integration.

The change applies to calls placed after you submit. Calls already up finish on the path they started on, so there is nothing to drain and nobody gets cut off.

Watch the places you already watch.

• The Real-Time screen. Agents should stop hearing recorded greetings. That is the whole point, and it is the first thing a floor manager will notice.
• Your existing reports. AMD Cop writes the same AMDSTATUS values, so your machine and human counts keep filling the same columns they always did.
• The AMD Cop log. One line per call, with the verdict, how long it took and the reason behind it.
• Recordings, which is the only honest test. Pull twenty calls that came back MACHINE and listen to them. Then pull twenty that came back HUMAN. Numbers on a screen cannot tell you whether the verdicts were right.

sudo journalctl -u amdcop -f

<timestamp> call=<uniqueid> verdict=<HUMAN|MACHINE|NOTSURE|HANGUP>
           ms=<time to decide> conf=<0.00 to 1.00> cause=<short reason>

Run it beside what you have.

The cleanest comparison is two campaigns working the same list, on the same hours, with the same agents. Leave one on 8369. Put the other on 8370. Compare dispositions after a full week.

Do not compare a week of AMD Cop against last month's numbers. Lists, staffing, weather and the calendar move those figures more than any detector does, and you will end up arguing about the wrong thing.

Two questions are worth answering, in this order. How many live people were dropped as machines? That is the expensive mistake. Then, how many recordings still reached an agent? That is the cheap one.

Tuning for false positives.

A false positive here means a live person was called a recording and dropped. That is the mistake worth caring about. It costs you the contact, it annoys the person you called, and in the US and the UK it counts against your abandoned call limit. The FTC caps abandoned calls at 3.0% of answered calls and Ofcom sets the same limit for silent calls.

If you find them in the recordings, move the bias toward people.

[detection]
bias = favour-human

sudo systemctl reload amdcop

That makes the engine hold out for stronger evidence before it will call something a machine. More recordings will get through to agents as a result. That is the trade you are making, and it is the safe direction to err in, because an agent hanging up on a recording costs you ten seconds and a dropped customer costs you the contact.

Two more levers, in the order you should reach for them.

• max_analysis. Raising it gives the engine more audio before the hard stop. Verdicts land later and your dialer waits longer, so raise it in small steps.
• min_audio. Raising it stops the engine deciding on very little sound. Useful if you see wrong verdicts on calls that answer with a long silence.

Change the field back.

That is it. There is no migration to unpick because there was never a migration.

1. Admin, then Campaigns, then the campaign The same screen you changed.
2. Detail View, Routing Extension Change 8370 back to 8369.
3. Submit Calls placed from that moment go through stock detection again. Calls already up finish where they started.

You can leave extension 8370 in the dialplan and you can leave the service running. Neither does anything while no campaign points at it, and both are there if you want to try again next quarter. If you would rather have it gone, the install page covers removing the service.

If something looks wrong.