VoIP.infoThe independent guide to business communications.
VoIP.info Troubleshooting

Asterisk WaitUntil returns PAST, fails or fires at the wrong time

Find the first divergence among installed application, loaded epoch, civil-time conversion, timezone, host clock, channel lifetime, absolute timeout, immediate status and downstream action.

Reviewed 2026-10-15Current Asterisk branch-23-generated WaitUntil, TIMEOUT, STRFTIME and STRPTIME references and branch 22 WaitUntil reference reviewed October 15, 2026; installed branch, module packaging, exact dialplan, channel lifetime, epoch source, civil-time input, timezone database, host clock, clock correction, scheduling, downstream action and caller treatment remain deployment specific; no host, module, dialplan, channel, epoch source, timezone database, clock, packet, scheduler or live call was inspected or testedAdvancedDocumentation based · not lab tested

Capture one target, conversion, channel timeline and status

Record timestamp and timezone, installed Asterisk branch, channel identity, context, extension, priority, exact loaded argument, original civil-time input if any, conversion zone and format, resulting epoch, application entry and return times, immediate WAITUNTILSTATUS, relevant channel hangup, next priority and caller-visible result. Redact caller data and secrets.

Classify the symptom as PAST, FAILURE, HANGUP, unexpected OK, late or early return, no return, missing status or correct return followed by a wrong downstream action. Do not combine them as one scheduling failure.

Prove the installed application and loaded dialplan

Confirm the running system exposes WaitUntil() and inspect its local help. Then prove that the active dialplan entered the intended context, extension and priority with the expected epoch. A source-file change or generated configuration fragment does not prove the loaded dialplan executed it.

Compare installed help with the branch-appropriate upstream reference. If the application, syntax or target priority differs, correct that boundary before changing timezone, clock or timeout settings.

Reconstruct civil time to timezone to epoch

When the target originated as a human date or time, replay the conversion with the same explicit timezone and format. STRPTIME() produces an epoch from those inputs, while STRFTIME() can render an epoch for comparison. Preserve the input, zone, format, output and database or library versions used by the actual system.

Check seconds versus milliseconds and daylight-saving gaps or duplicate local times. The epoch does not carry the conversion timezone, so changing only the display zone does not move the target instant.

Classify OK, PAST, FAILURE and HANGUP exactly

Capture WAITUNTILSTATUS immediately after the application. PAST means the target time was already past; FAILURE means the argument was invalid; HANGUP means the channel ended before the time elapsed; and OK means the wait succeeded. Keep the channel and timestamp attached to the observation.

A later variable read, a different channel or a downstream error can obscure the original result. None of these status values alone proves that a later playback, notification, call or media path worked.

Separate the target epoch from every channel timeout

Read the effective TIMEOUT(absolute), TIMEOUT(digit) and TIMEOUT(response) values and label them separately. The absolute type is a seconds-based maximum call duration; digit and response types govern digit entry. None supplies the absolute epoch consumed by WaitUntil().

If the channel ends before the target, establish whether the absolute timeout, caller hangup, transfer, bridge teardown or another dialplan action ended it. Do not disable the absolute timeout merely to suppress a HANGUP result.

Fix the first proved boundary and test a timing matrix

Correct only the first demonstrated divergence: application availability, loaded priority, malformed argument, unit conversion, timezone, format, stale target, host clock, channel lifetime, absolute timeout, result branch or later action. Preserve rollback and remove temporary high-volume logging.

Repeat authorized tests before, at and after the target plus invalid-input and early-hangup cases. Record immediate status, observed return time and next priority separately from the final caller outcome. No host, module, dialplan, channel, epoch source, timezone database, clock, packet, scheduler or live call was inspected or tested for this diagnostic.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.

Continue your research

Guide · Current Asterisk branch-23-generated WaitUntil, TIMEOUT, STRFTIME and STRPTIME references and branch 22 WaitUntil reference reviewed October 15, 2026; installed branch, module packaging, exact dialplan, channel lifetime, epoch source, civil-time input, timezone database, host clock, clock correction, scheduling, downstream action and caller treatment remain deployment specific; no host, module, dialplan, channel, epoch source, timezone database, clock, packet, scheduler or live call was inspected or tested

Asterisk WaitUntil: epoch scheduling, status and channel-lifetime evidence

Wait on an active channel until an absolute epoch while keeping civil-time conversion, status, channel lifetime, call timeout and downstream action independently observable.

Read guide →
Guide · Asterisk 22 GotoIfTime, ExecIfTime, IFTIME, TESTTIME and STRFTIME documentation plus current public Sangoma Time Conditions and Time Groups guidance and FreePBX release/17.0 Time Conditions metadata version 17.0.1.19 reviewed October 15, 2026; Sangoma interface guidance is explicitly labelled for PBX GUI version 13 and is used for object and override semantics rather than as an exact FreePBX 17 screen map; installed modules, generated dialplan, host and explicit timezones, clock state, schedule, overrides, targets and calls remain deployment specific; no PBX, module, clock, timezone, dialplan, condition, override, destination or live call was inspected or tested

Asterisk time-based dialplan routing: conditions, zones and test time

Keep the timespec, timezone, channel clock, selected primitive, jump target and final destination independently observable when routing by time.

Read guide →
Troubleshooting · Asterisk 22 GotoIfTime, ExecIfTime, IFTIME, TESTTIME and STRFTIME documentation plus current public Sangoma Time Conditions and Time Groups guidance and FreePBX release/17.0 Time Conditions metadata version 17.0.1.19 reviewed October 15, 2026; Sangoma interface guidance is explicitly labelled for PBX GUI version 13 and is used for object and override semantics rather than as an exact FreePBX 17 screen map; installed modules, generated dialplan, host and explicit timezones, clock state, schedule, overrides, targets and calls remain deployment specific; no PBX, module, clock, timezone, dialplan, condition, override, destination or live call was inspected or tested

Asterisk GotoIfTime selects the wrong branch or destination

Find the first mismatch among channel time, timespec fields, explicit timezone, executed priority, selected target, fall-through and the downstream destination.

Read guide →
Troubleshooting guide · Asterisk 22 GotoIfTime, ExecIfTime, IFTIME, TESTTIME and STRFTIME documentation plus current public Sangoma Time Conditions and Time Groups guidance and FreePBX release/17.0 Time Conditions metadata version 17.0.1.19 reviewed October 15, 2026; Sangoma interface guidance is explicitly labelled for PBX GUI version 13 and is used for object and override semantics rather than as an exact FreePBX 17 screen map; installed modules, generated dialplan, host and explicit timezones, clock state, schedule, overrides, targets and calls remain deployment specific; no PBX, module, clock, timezone, dialplan, condition, override, destination or live call was inspected or tested

FreePBX time condition routes to the wrong destination

Separate call-path selection, PBX time, time-group matching, manual override and holiday logic before changing an open or closed destination.

Read guide →
Guide · Asterisk hangup-handler, CHANNEL, AMI event, hangup-cause and Return documentation reviewed October 12, 2026; exact events and channel behavior remain dependent on the installed Asterisk branch, modules, dialplan, channel technology and observer permissions, and no PBX, dialplan, channel, handler stack, event, record, endpoint, call or teardown path was inspected or tested

Asterisk hangup handlers: channel stack, order and teardown evidence

Attach bounded hangup subroutines to the correct channel, preserve LIFO stack order and prove push, pop, run and final hangup separately.

Read guide →
Guide · Current Asterisk CLI, logging, PJSIP troubleshooting and call-identifier documentation reviewed September 30, 2026; CLI commands are not shell commands; no PBX, trace, call or media tested

Asterisk CLI and PJSIP logging for one failed call

Bind one failed call to the loaded PJSIP objects, dialplan decision and short signaling trace, then prove diagnostic cleanup.

Read guide →
Hub

VoIP troubleshooting

Use symptoms and evidence to isolate registration, routing, media and device faults.

Explore topic →