Choose AGI only when the dialplan should wait
AGI connects the dialplan to an external program and is generally synchronous: channel operations wait while the program is active. Put a duration budget, failure branch and observable result around that wait. A database, HTTP API, model or other remote dependency inside the script becomes part of the live call path even when Asterisk can launch the script successfully.
Use the smallest interface that matches ownership. Local or FastAGI fits a bounded dialplan step; AsyncAGI lets AMI queue AGI commands and correlate results; ARI fits an application that owns live channel state. Interface choice does not by itself supply authorization, retries, idempotency or proof of the caller-visible outcome.
Select the execution model explicitly
Local AGI(command,args) starts a process and communicates through standard input and output; when the command is not a full path, Asterisk resolves it under astagidir. FastAGI uses an agi:// TCP URI, while hagi:// adds an SRV lookup for _agi._tcp. EAGI behaves like AGI but provides incoming audio out of band on file descriptor 3. None of those forms is interchangeable with agi:async, which is driven through AMI actions and events.
Record the chosen form, exact target and installed branch in the change plan. Do not infer encrypted transport from an AGI URI, and do not revive DeadAGI: the current application reference marks it deprecated and directs operators to AGI.
Define a strict protocol and input contract
Allowlist the script, arguments, channel variables, AGI commands and writable dialplan functions the workflow actually needs. Treat caller-controlled digits, names, URLs and identifiers as untrusted data, and never turn them into an arbitrary EXEC, shell command, file path or dialplan target. Keep credentials out of arguments and routine traces.
Standard output belongs to the AGI dialogue, so keep application logging on a separate sink or use bounded AGI VERBOSE messages. Parse every command response before issuing the next command and attach a safe transaction ID to logs. A process that stays alive while emitting unrelated output, waiting on its own input or failing to consume responses can hold the channel without completing useful work.
Bound local process and filesystem ownership
Resolve the effective astagidir, executable or interpreter path, owner, mode, service identity, working directory, environment and dependency versions from the running Asterisk instance. A script that succeeds in an administrator shell has not proved it can start with Asterisk’s identity, environment, file limits or path.
Give the service account only the files and destinations it requires. Bound runtime, child processes, memory and external calls; return a deliberate dialplan result on failure; and make cleanup safe after termination. Do not widen directory permissions or run Asterisk as a more privileged user to hide an unresolved launch boundary.
Bound FastAGI network and hangup behavior
For FastAGI, inventory the exact URI, name-resolution path, optional SRV record, address, port, route, allowlist, server listener, script selector and downstream dependencies. Define connection and request timeouts plus a dialplan fallback. A reachable TCP port proves neither that the requested service ran nor that its AGI commands produced the intended call result.
Hangup is a separate lifecycle. The AGI application reference says local AGI normally receives SIGHUP, while FastAGI receives a HANGUP indication inline; dialplan execution can remain in AGI until the process exits or the connection closes. Change AGISIGHUP or AGIEXITONHANGUP only for an explicit cleanup model, then test caller hangup during each blocking operation.
Accept launch, dialogue, application and call outcome separately
Capture AGISTATUS immediately after the application and interpret its documented values—SUCCESS, FAILURE, NOTFOUND and HANGUP—as the AGI application result, not proof of a downstream business outcome. For AsyncAGI, preserve channel identity and a unique command ID so AsyncAGIExec results can be matched to the queued AMI action; ASYNCAGI BREAK deliberately returns control to the previous source, usually the dialplan.
Acceptance should cover success, missing executable, invalid input, refused or unavailable FastAGI service, slow downstream dependency, malformed dialogue, caller hangup mid-command and the unaffected-call path. Correlate the dialplan branch, AGI command responses, application record and caller-visible outcome, then remove temporary traces. No AGI execution or call was tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk AGI overview ↗
- Asterisk 23 AGI application reference ↗
- Asterisk 23 EAGI application reference ↗
- Asterisk 23 AGI command index ↗
- Asterisk 23 AGI VERBOSE command ↗
- Asterisk AsyncAGI AMI action ↗
- Asterisk 23 AsyncAGIStart event ↗
- Asterisk 23 AsyncAGIExec event ↗
- Asterisk 23 ASYNCAGI BREAK command ↗
- Asterisk deprecated DeadAGI application reference ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.