AMDMINLEN: Force VICIdial AMD to Run a Minimum Time

Sometimes the AMD routing script finishes and hangs up faster than you want, cutting off audio you needed to hear. AMDMINLEN is the dialplan variable that fixes that. It forces the script to run for at least a set number of seconds before it can end the call, giving the analysis room to do its job. It is a small setting with a real effect on detection quality.

What AMDMINLEN does

When a call clears answering machine detection (AMD (answering machine detection)), the VD_amd.agi script takes over and routes it. Normally the script ends as soon as it has a decision. AMDMINLEN sets a floor on that. If you set it to 7, the script will keep running for at least 7 seconds before it is allowed to end and hang up the call, even if it reached a decision sooner.

That extra time matters when a machine greeting starts slow, or when the first second or two of audio is silence or noise. Giving the script a guaranteed window means it has more of the greeting to work with, which can cut down on calls that get misjudged because the analysis bailed too early.

Where to set it

AMDMINLEN is set in your outbound dialing dialplan (Dialplan), and placement is specific: the line goes immediately before the Dial line for your outbound pattern. It looks like a normal channel variable set:

• exten => _91NXXNXXXXXX,n,Set(__AMDMINLEN=7)

The double underscore makes the variable inherit down the call, so the AMD script sees it. The 7 there is just an example value in seconds; pick a number that fits how your leads and lines behave. After editing extensions.conf you need a dialplan reload or an Asterisk restart for the change to take effect.

flowchart TD
  A[Outbound call placed] --> B[Set AMDMINLEN before Dial]
  B --> C[Call answered and AMD runs]
  C --> D{Decision reached early}
  D -->|Yes| E{Min time elapsed}
  D -->|No| F[Keep analyzing]
  E -->|No| F
  E -->|Yes| G[End and route call]
  F --> G

When to reach for it

Use AMDMINLEN when you see machine calls slipping through as humans, or detections that seem rushed in the AMD Log Report. Forcing a longer minimum run can reduce those misses. The trade-off is that every call now holds open a touch longer, which is the same processing cost AMD adds to all calls, not just the machine ones. Do not stretch it so far that live people sit in silence wondering if anyone is there, because that hurts your contact rate as surely as a wrong detection does.

A practical way to choose a value is to look at how long the average machine greeting on your leads runs before the analysis usually settles. If your greetings tend to start with a few seconds of music or a slow intro, a higher minimum gives the engine the speech it needs. If your traffic is mostly quick greetings, a smaller floor avoids holding live people too long. Change one value, watch the next batch in the log report, and adjust from there rather than guessing in big jumps.

This is one knob among several. The Asterisk AMD parameters in the 8369 line control the analysis windows themselves, and your dial method (Dial method) decides whether AMD runs at all, since it never fires on manual dialing. Pair AMDMINLEN with sensible AMD parameters rather than treating it as a cure on its own. It is a floor on run time, not a replacement for tuning the detection itself.

For the bigger picture, read our AMD and CPD complete guide, and to understand the script AMDMINLEN governs see what VD_amd.agi does.

Not sure what value to use for your traffic? We tune AMDMINLEN and the rest of your detection settings as part of managed hosting. See VICIfast pricing to get help.