VoIP.info Guide

Asterisk periodic hooks: owner channel, async execution and injected audio

Attach one bounded periodic dialplan hook while keeping the owner channel, generated hook ID, asynchronous hook channel, interval, audio and teardown evidence separate.

Reviewed 2026-10-15Current Asterisk branch-23-generated PERIODIC_HOOK, Playback and CHANNEL references plus branch 22 and 20 PERIODIC_HOOK references reviewed October 15, 2026; installed branch, func_periodic_hook availability, owner channel, hook ID, context, extension, whole-second interval, hook-channel dialplan, audio file, bridge and media topology, recording policy, load and teardown remain deployment specific; no host, module, dialplan, channel, hook, bridge, recording, audio stream or live call was inspected or testedAdvancedDocumentation based · not lab tested

Define the periodic outcome and the channel that owns it

Use PERIODIC_HOOK() only after naming the exact call leg that should own the recurring action and the business reason for it. A recording notification tone, operational reminder or other periodic sound can have different policy, consent, timing and audibility requirements. The function is an audio mechanism, not evidence that a legal or organizational recording-notice obligation has been met.

Record the owner channel unique identity, linked identity, bridge or application state, expected listeners, start condition, stop condition and rollback. A connected call, active recording and audible injected sound remain different observations.

Create the hook once and retain its returned ID

The documented read form accepts context, extension and a whole-second interval and returns a hook ID. Store that exact ID on the channel whose dialplan owns later enable or disable actions. Re-evaluating the creation expression can create another hook rather than retrieve the first one, so treat creation as a state-changing action.

Validate that func_periodic_hook is available on the installed branch, that the context and extension exist in the loaded dialplan and that the interval is the intended whole number of seconds. A non-empty ID proves creation of a hook object, not that its dialplan ran or that a listener heard audio.

Keep the owner channel and asynchronous hook channel distinct

Asterisk explicitly documents that the periodic dialplan does not run on the channel where the function was set. It runs asynchronously on a new channel, while audio generated there is injected into the call for the owner channel. Preserve both identities in logging and troubleshooting.

The hook dialplan receives HOOK_CHANNEL and HOOK_ID. Do not assume it shares every mutable variable, application state or bridge role of the owner channel. Use the documented identities to correlate one hook run with its owner and avoid reading or changing an unrelated channel that happens to have a similar name.

Design a short, bounded hook dialplan

Keep the hook extension deterministic and shorter than its intended cadence. Avoid blocking network calls, unbounded loops, secret-bearing logs or heavy work on every run. The public function reference specifies the whole-second interval but does not promise an exact wall-clock scheduler, overlap policy or capacity for a chosen deployment. Measure timing and load on the installed system instead of turning an interval into a performance guarantee.

For a sound file, Playback() supplies its own PLAYBACKSTATUS and can fail when the file is absent. Its default answer behavior also matters outside an already answered media path. Keep hook invocation, application completion, frame injection and listener audibility as separate checkpoints.

Toggle the exact hook ID instead of rebuilding state

Asterisk documents write operations that set one hook ID to off or on. Retain the ID and the timestamp and reason for each state change. Do not disable by recreating the hook with another expression, and do not use one stored ID as if it controlled every channel or every call.

A successful dialplan assignment is not proof that the intended hook was active at the next interval. Verify the owner channel still exists, the correct ID was addressed and a later run occurred or remained absent as expected. Transfer, masquerade, bridge and channel-lifetime behavior require observation on the actual call path.

Accept timing, audio and teardown independently

For one authorized test call, retain hook creation time and ID, owner and hook-channel identities, expected interval, each bounded invocation, application result, bridge membership or media topology, recording state and what each intended listener actually heard. Use an unaffected call as a control and remove temporary verbose or media logging after the window.

Test enable, disable, re-enable, transfer and hangup only where authorized. A hook that ran is not proof that its sound was mixed to both directions, captured in a recording or heard exactly once. An audio report after hangup may belong to another leg, a second hook or buffered media; correlate the channel and hook ID before claiming that the original hook survived teardown.

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.