Define who may schedule which destination
Wake Up Calls can accept a schedule through its administration page or through the configured feature code. The reviewed release/17.0 source generates that code in from-internal-additional, while operator mode and operator-extension settings can change whether a caller schedules only their own extension or supplies another destination. Record the scheduling identity, entry path, operator-mode state, exact destination and authorization decision.
A valid internal destination is not automatically an authorized reminder target. Keep guest-room, clinical, school, emergency and premium-route policies outside a convenience feature. Limit destination length and route reach deliberately, protect the administration page, and do not expose the feature code through an inbound route without a separate authenticated design.
Keep displayed time, PBX time and stored epoch together
Capture the requested local date and time, timezone, current PBX clock, NTP state and the stored Unix time before changing a schedule. A spoken or displayed time can be correct while the underlying host timezone is wrong, or the stored epoch can be correct while the user expected a different daylight-saving interpretation.
Repeat rules and the time-step control are current repository behavior, not proof of the installed build. For recurring reminders, retain the start date, repeat type, generated occurrences and cancellation owner. Test a future daylight-saving transition in an isolated acceptance plan rather than assuming every repeated wall-clock time will be interpreted as intended.
Treat the saved job and Asterisk call file as separate states
The module source builds a wake-up call file with destination, scheduled time, language, wait time, retry time, maximum retries, caller identity and an answered-call application. Asterisk documents that a future modification time holds a call file until the scheduled instant and that the outgoing spool is watched for new files. Preserve the module job ID and stored schedule before looking for the corresponding spool artifact.
A row in the Wake Up Calls page does not prove that a complete file reached the configured Asterisk spool directory. Conversely, an old archived file does not prove that a current job still exists. Never create a call file directly in the watched outgoing directory; Asterisk warns that it can read a partial file, and the module's supported generation path should remain the owner.
Separate attempts, answer, prompt and human confirmation
Asterisk defines WaitTime, MaxRetries and RetryTime as call-file attempt controls. They do not establish that the destination rang for the expected human, that an answering machine did not answer, or that the reminder prompt was audible. For one authorized test, retain each originated channel, answer state, application start, selected language, prompt playback and confirmation or snooze result.
The reviewed module defaults and confirmation menu are source evidence only. Record effective installed settings instead of copying defaults into an incident report. A completed call-file status is narrower than human acceptance, and a retry after voicemail answer may not match the business expectation.
Retain bounded history without turning the spool into a data leak
The reviewed module requests call-file archival, while Asterisk documents the outgoing_done location and the appended Expired, Completed or Failed status. Treat archived files and module history as operational records that can expose destinations, timing, caller identity and retry behavior. Set access, retention and deletion owners, and redact shared evidence.
Archive presence is not a delivery receipt. Correlate the file status with Asterisk logs, channel events and the intended endpoint only for the authorized time window. Do not publish full call files, dialed destinations, room assignments or caller data as troubleshooting examples.
Accept and roll back the complete reminder path
After one supported change, verify module and feature-code state, scheduler authorization, stored time and destination, generated call file, Asterisk spool processing, originated channel, answer, prompt, confirmation or terminal failure, history and cleanup. Test an authorized cancellation, a busy or unanswered endpoint and one control reminder without using an emergency number.
Preserve the previous module settings, feature code, prompts and schedule for rollback. This guide is documentation-derived; it does not claim that a FreePBX host, call-file queue, endpoint, timing path, prompt or human response was laboratory-tested.
When a reminder does not ring or arrives at the wrong time
Use the Wake Up Call diagnostic to separate stored time, generated file, spool pickup, attempts, endpoint answer, prompt and confirmation before recreating the job.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- FreePBX Hotel Wakeup repository ↗
- FreePBX Hotel Wakeup metadata — release/17.0 ↗
- FreePBX Hotel Wakeup configuration and call-file source — release/17.0 ↗
- FreePBX Hotel Wakeup feature-code dialplan — release/17.0 ↗
- Sangoma Wake Up Calls user guide ↗
- Asterisk Call Files ↗
- Asterisk directory and file structure ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.