Asterisk call files: atomic submission, scheduling and outcome evidence

Treat a call file as an originate request, not a completed call

A call file tells Asterisk which channel to create and what to run after that channel answers. The required Channel field owns the first leg; the answered action is either one Application with Data or a dialplan Context, Extension and Priority. File appearance, successful parsing, channel creation, answer and downstream dialplan completion are separate evidence states.

Record a unique external job ID in a safe variable or account code and correlate it with the channel unique ID, CDR or CEL and application result. Do not treat disappearance from the outgoing directory, an archived Completed label or a successful first-leg answer as proof that a second destination, announcement or business workflow succeeded.

Submit atomically on the same filesystem

Asterisk explicitly warns not to create or write the file directly in the watched outgoing directory because pbx_spool.so can read a partial file. Create and close the complete file in a staging directory on the same filesystem, apply the intended ownership, permissions and modification time, then move it into the configured outgoing directory with one atomic rename.

A copy across filesystems is not the same operation and can expose intermediate content. Give the submitting service only the narrow path and operation it needs, protect destinations, caller identity, application arguments and variables as control input, and never allow an untrusted user to choose arbitrary dialplan contexts, applications or writable functions.

Prove the loaded module and actual spool path

The watcher is provided by pbx_spool.so; confirm the running module state before diagnosing the generator. The spool root comes from astspooldir in asterisk.conf, with outgoing and outgoing_done beneath that root by default. A package, container, chroot or managed PBX can move the effective path.

Inspect the running process identity, configured spool root, directory type, ownership, mode, mount and available space. A file in the documentation's common /var/spool/asterisk/outgoing path is irrelevant if this instance uses another root or cannot read, append, rename or delete it.

Separate attempt, answer and retry policy

WaitTime bounds the answer wait for one attempt. MaxRetries counts retries after the initial attempt, and RetryTime controls the wait between them; their documented defaults are 45 seconds, zero retries and 300 seconds. Preserve those meanings when estimating how many attempts and how long a job can remain active.

The official source appends attempt markers and exposes AST_OUTGOING_ATTEMPT to the originated channel. A failed channel attempt can be retried, while an answered first leg that later reaches a busy or failed destination through the dialplan may still complete the spool originate. Put application-level retry, deduplication and recipient-result policy in an owner that can observe that later outcome.

Schedule with modification time deliberately

A future modification time tells the watcher to defer the file until that time. The timestamp is filesystem state rather than a timezone-bearing field inside the call file, so the submitting scheduler owns timezone conversion, clock synchronization, daylight-saving behavior and missed-job policy. Set the final modification time before the atomic move and preserve it during transfer.

A future timestamp can also explain a file that appears stuck. Compare the exact epoch value, host clock and intended execution time before touching the file. NFS adds a separate boundary: the official documentation warns that the usual inotify approach does not work on an NFS-mounted spool and describes a build-time polling alternative.

Archive bounded evidence and control duplication

With Archive: yes, Asterisk moves the processed file to outgoing_done and appends a status of Completed, Expired or Failed; otherwise the file is normally deleted. Archive filenames can collide, and the current source replaces an existing same-name archive, so use a unique, sanitized name and export needed evidence to a controlled record system.

Treat the spool as a queue, not the authoritative job database. Make external submission idempotent, record who requested the call and why, limit retention and access, and reconcile ambiguous restarts before resubmitting. Test a non-production number, no-answer, invalid channel, future job, retry exhaustion and restart under an approved procedure. No originate or call was tested for this guide.

Apply call-file evidence to a FreePBX Wake Up Call

The Wake Up Call diagnostic maps the managed job to a complete future-dated file, spool pickup, attempts, answered application and terminal archive state.

Track the channel created by a call file separately

If a call-file path needs focused dialplan output, the LOG_GROUP guide keeps the created channel assignment separate from spool acceptance and later call outcome.

Separate in-dialplan Originate from spool submission

The Originate application guide has no filesystem pickup or archive boundary; call-file queue status and dialplan application status remain different evidence.