AMD NOTSURE in VICIdial and Asterisk, Explained

What AMD NOTSURE means

Asterisk's AMD() application, which VICIdial uses by default, ends every call with one of four values in AMDSTATUS: HUMAN, MACHINE, NOTSURE or HANGUP. It also sets AMDCAUSE to say which rule fired, such as INITIALSILENCE, LONGGREETING, MAXWORDS, MAXWORDLENGTH, HUMAN or TOOLONG.

NOTSURE has one cause: TOOLONG. It means the analysis ran for total_analysis_time (5000 ms as Asterisk ships it) and no rule decided. AMD did not hear enough silence to call it a person, and did not hear enough speech to call it a machine. It simply ran out of time.

That makes NOTSURE different from the other results. HUMAN and MACHINE may be right or wrong, but they arrive when a rule fires, often within a second or two. NOTSURE always arrives at the very end of the window. Whatever happens to the call next, the person who answered has already listened to the full analysis time in silence.

Why calls end as NOTSURE

To see why, it helps to know how AMD() decides. It splits the audio into speech and silence using silence_threshold, then applies its rules as the call goes on:

Silence before the first word longer than initial_silence: MACHINE, cause INITIALSILENCE.
A first greeting longer than greeting: MACHINE, cause LONGGREETING.
More words than maximum_number_of_words: MACHINE, cause MAXWORDS.
A single word longer than maximum_word_length: MACHINE, cause MAXWORDLENGTH.
Silence after a short greeting longer than after_greeting_silence: HUMAN.
None of the above before total_analysis_time: NOTSURE, cause TOOLONG.

So NOTSURE happens when a call never trips any rule. Some common patterns, as examples:

Noise that never counts as silence. On a line with hiss or background noise above silence_threshold, the pause after "Hello?" is not heard as silence, so the HUMAN rule never fires. The person waits, says "Hello?" again, and the clock runs out.
Speech in short bursts. A person who says a word, pauses briefly, then another, can stay under the word limit while never leaving a long enough pause for HUMAN.
Strange audio. Music, a carrier announcement with gaps, or a call screening assistant with an unusual rhythm may not match any rule cleanly.
Tight values. If someone shortened total_analysis_time to cut dead air without loosening the other values, more calls run out of time before any rule can fire.

Watch for it on your own servers. With console verbosity raised, Asterisk logs each AMD decision and its cause:

asterisk -rx "core set verbose 3"
asterisk -rvvv

Count the TOOLONG results over a busy hour. Then compare them by carrier. A trunk with far more NOTSURE than the others usually has an audio problem, not an AMD problem.

A short NOTSURE audit is worth doing before you touch any setting:

Pick one campaign and one busy hour of calls.
Count how many calls ended NOTSURE compared with HUMAN and MACHINE.
Split those NOTSURE calls by carrier or trunk.
Listen to ten of them and write down what you hear: a person, a greeting, noise, a screening assistant.
Note where VICIdial sent each one, to an agent or to the drop path.

The answers tell you whether you have a routing problem, an audio problem or a limit of the method.

How VD_amd.agi treats NOTSURE

In VICIdial, AMD calls go to extension 8369. It runs AMD(), then VD_amd.agi, which reads AMDSTATUS and routes the call: people to agents, machines to a hangup with the AA status or to your voicemail drop message.

What happens to NOTSURE depends on the version of the script and on your settings. Rather than trust a forum post, read the copy on your own server:

grep -n "NOTSURE" /var/lib/asterisk/agi-bin/VD_amd.agi

Then decide on purpose which way unclear calls should go. Each option has a cost:

If NOTSURE goes to...	What the person hears	What it costs you
An agent	Up to the full analysis time of silence, then the agent	Dead air, early hang-ups, more abandoned-call risk; some voicemail reaches agents
The machine path	Silence, then a hangup or your voicemail message	Every unclear person is lost, and they got a silent call or a recording

For most sales and service campaigns, sending NOTSURE to agents is the lesser evil. A person who waited is still a person. A person who was hung up on is gone.

The trade-offs of tuning NOTSURE

The setting that controls NOTSURE is total_analysis_time, in amd.conf or as the fourth argument to AMD() in your dialplan. Arguments in the dialplan override the file, so check your 8369 line before editing amd.conf.

Change	Effect on NOTSURE	Side effect
Lower `total_analysis_time`	More NOTSURE	Shorter worst-case silence
Raise `total_analysis_time`	Fewer NOTSURE	Longer silence on every unclear call
Lower `after_greeting_silence`	Fewer NOTSURE, more HUMAN	More short greetings sent to agents
Raise `silence_threshold`	Fewer NOTSURE on noisy lines	Quiet people heard as silence and dropped
Lower `maximum_number_of_words`	Fewer NOTSURE, more MACHINE	More talkative people dropped

Every row moves calls from NOTSURE into HUMAN or MACHINE, and each move adds errors on one side. That is the core limit of timing rules: they can be faster or more careful, but not both. If you tune, change one value at a time, run a full day, and look at three numbers together: NOTSURE share, AA share and agent-connected share. For a wider list of causes, see VICIdial AMD not working.

What NOTSURE costs in dead air

Every NOTSURE call is a long silent call by design. Take an example: a campaign with a 5000 ms analysis window that sends NOTSURE to agents. The person answers, says "Hello?", waits, says "Hello?" again, and only after the window closes does the call head for an agent. Many people hang up before that. Those who stay start the conversation annoyed.

There is a rules side too. Under the US Telemarketing Sales Rule and FCC rules, a call is abandoned if the person is not connected to a live agent within 2 seconds of their completed greeting, and abandoned calls must stay under 3% of answered calls per campaign per 30 days. Ofcom in the UK has similar rules on silent and abandoned calls. A NOTSURE call has usually passed that 2-second mark. This is not legal advice; check with counsel.

And there is reputation. Short silent calls that end in a hang-up are exactly the pattern that leads people to report numbers as spam. Our page on dead air calls covers the other causes.

How nomoVM avoids a NOTSURE result

nomoVM takes a different approach to unclear calls. Instead of one fixed window that every call might run to the end, it decides most calls about 2 seconds after answer. Only calls that are genuinely unclear get more listening time, up to 3.2 seconds. Then it decides. It never returns NOTSURE.

Two answers, not four. AMDSTATUS is HUMAN or MACHINE, with AMDCAUSE saying why: HUMAN, MACHINE, SCREENING, SILENCE, TONE, BUSY or UNKNOWN.
A shorter worst case. The longest listening time is 3.2 seconds, not 5. The client timeout is 4500 ms to cover that plus network time.
Only confirmed people reach agents. A timeout or error after streaming started is treated as MACHINE with cause UNKNOWN. AMDSTATUS is HUMAN only when AMDCAUSE is HUMAN.
A safe fallback. If the key is wrong, the plan limit is reached or the service is unreachable, nomoVM returns FALLBACK before any audio is used, and the dialplan runs Asterisk's own AMD() for that call. On those calls, AMD() can still return NOTSURE as it does today. Fallback calls are never billed.

Because nomoVM sets the same AMDSTATUS variable before the same VD_amd.agi, nothing else in VICIdial changes. You add one script to the dialer you already run, copy your AMD extension as 8370 and switch a campaign's Routing Extension. There is no additional infrastructure required, and it takes about 10 minutes. The steps are in VICIdial AI AMD setup in 10 minutes, and VICIdial AMD explains how it fits.

On 400 real outbound calls checked by a person, nomoVM sent 94.9% of live people to agents, and 88% of calls sent to agents were live people. The accuracy page has the details.

Want to see how many of your calls would leave the NOTSURE pile? Start free with 30,000 calls a month and follow the VICIdial AMD setup guide on one campaign.

Frequently asked questions

What does AMDSTATUS NOTSURE mean?

It means Asterisk's AMD() reached its total analysis time without any of its rules deciding HUMAN or MACHINE. The cause is reported as TOOLONG. The call has been silent for the person on the other end the whole time AMD was listening.

How does VICIdial handle AMD NOTSURE calls?

VD_amd.agi reads AMDSTATUS and routes the call, and how it treats NOTSURE depends on your version and settings. Search your copy of the script for NOTSURE to see what it does on your server. Either way, decide on purpose whether unclear calls should reach agents or be dropped.

Should I lower total_analysis_time to reduce dead air?

Lowering it shortens the worst-case silence, but more calls will run out of time and come back as NOTSURE. Raising it gives fewer NOTSURE results but longer silences. It is a trade-off, not a fix, so change it in small steps and measure both outcomes.

Is a NOTSURE call an abandoned call?

It can be. US rules count a call as abandoned if the person is not connected to a live agent within 2 seconds of finishing their greeting, and a NOTSURE call has usually waited longer than that. This is not legal advice; check with counsel.

Does nomoVM ever return NOTSURE?

No. nomoVM returns HUMAN or MACHINE, or FALLBACK before any audio is used. Most calls are decided about 2 seconds after answer, and only unclear calls listen up to 3.2 seconds. A timeout or error after streaming started is treated as MACHINE with cause UNKNOWN, so only a confirmed person reaches an agent.

Can a FALLBACK call still return NOTSURE?

Yes, because FALLBACK hands that call to Asterisk's own AMD(), and AMD() can return NOTSURE. FALLBACK only happens when the key is wrong, the plan limit is reached or the service cannot be reached, and those calls are never billed.

AMD NOTSURE: what it means in VICIdial and how to stop it