Asterisk call file is not processed or produces no expected call

Freeze one job without resubmitting it

Record the generator job ID, filename, size, checksum, owner and mode, staging path, final path, modification time as an epoch, intended timezone, move time and expected channel and answered action. Preserve a sanitized copy outside the watched directory before editing. Classify whether the file never appears, waits in outgoing, disappears immediately, moves to outgoing_done, creates a failed channel or answers without the expected downstream result.

Do not drop another copy into the queue while the first job's state is unknown. Duplicate call files can create duplicate calls, repeated announcements or conflicting external transactions.

Prove watcher, path and filesystem access

Confirm pbx_spool.so is loaded in the running Asterisk instance and read that instance's effective astspooldir. Inspect the actual outgoing and outgoing_done directories, mount type, space, inodes, ownership and process access. Check whether a container, chroot, package wrapper or managed platform places the generator and Asterisk in different filesystems or namespaces.

If the file sits on NFS, retain that fact before assuming an event-watcher failure; Asterisk documents a build-time polling path because inotify does not work for the remote mount. Do not change module loading, mounts or permissions broadly until the precise path and access failure is demonstrated.

Check atomic delivery and scheduled time

Determine whether the generator completed the file elsewhere on the same filesystem and renamed it into outgoing. A file written directly in the watched directory can be consumed while incomplete. A cross-filesystem move can degrade to copy-and-delete behavior and expose partial content. Correct the staging and rename boundary before interpreting parser errors.

Compare the file modification time with the Asterisk host clock. A future mtime deliberately defers processing. Check scheduler timezone conversion, NTP state and whether a copy, restore or deployment unintentionally preserved a future timestamp.

Follow parser and attempt evidence

Review bounded Asterisk logs at the exact handoff time for open, parse and originate messages. Confirm one valid Channel plus exactly one answered-action form: application/data or context/extension/priority. Verify the channel technology and resource exist on the running build, the selected context and extension are loaded, and any referenced application or writable function module is available.

If the file is archived, inspect its appended status and retry markers without overreading them. Failed points to file/open/parse handling, Expired to exhausted channel attempts, and Completed to a successful originate path; none by itself proves that a later dialplan destination answered or that the intended human received the result.

Separate channel failure from answered-action failure

Correlate WaitTime, MaxRetries, RetryTime, AST_OUTGOING_ATTEMPT, channel cause, CDR or CEL and the answered dialplan or application. If the first channel never answers, remain on channel address, endpoint state, route, response and retry policy. If it answers, follow the application or dialplan as a new evidence path, including Local-channel optimization and any second Dial operation.

A call-file retry does not automatically retry a second destination that failed after the first channel answered. Avoid raising MaxRetries to compensate for a dialplan, authorization, media or business-workflow fault.

Correct one boundary and prove idempotent recovery

Correct only the demonstrated fault: module state, effective path, same-filesystem staging, ownership, mode, timestamp, syntax, channel address, loaded context or application. Submit one uniquely named non-production job and trace handoff, parse, attempt, answer, downstream action, archive and final business outcome.

Reconcile the original external job record before retrying it. Remove temporary traces, retain only sanitized evidence and document whether the system suppresses duplicates after an ambiguous restart. No host, file, module, channel, endpoint, dialplan result or call was tested for this diagnostic.

Do not look for spool evidence when dialplan Originate ran

The dialplan Originate diagnostic starts on the executing channel; call-file pickup, retry and archive checks apply only to filesystem submissions.