Name the channel and the media transition you need
Use WaitForSilence() or WaitForNoise() only after naming the exact channel whose received media should control the next dialplan step. A caller leg, callee leg, Local-channel half, bridge peer and recording channel can share a call story without receiving the same frames. Preserve channel name, unique identity, linked identity, answer state and media direction.
Silence and noise are signal classifications, not proof of a human speaker, voicemail beep, intelligible message, consent or call completion. Write the intended transition in operational terms—such as a continuous quiet interval after a prompt—and keep the later business decision separate.
Keep milliseconds, iterations and timeout in their own fields
Both applications document the first argument as a required continuous interval in milliseconds, the second as the number of iterations and the optional timeout in seconds. The published defaults are 1000 milliseconds and one iteration. Record the units beside every value; a copied bare number can otherwise turn a one-second design into a much longer or shorter wait.
The timeout bounds how long the application can remain waiting when the requested classification never arrives. It does not change the required quiet or noisy interval into a confidence score, nor prove why the timeout occurred. Treat total wall-clock time, required duration and iteration count as different evidence.
Branch only on a documented status contract
The public WaitForSilence() reference documents WAITSTATUS as SILENCE or TIMEOUT. Preserve the value immediately after the application on the same channel before another dialplan step can replace it. An empty or unexpected value is a contract or execution problem, not evidence that silence was heard.
The public WaitForNoise() page documents its arguments but does not publish an equivalent WAITSTATUS table. If a workflow depends on a noise result variable, confirm the installed branch with core show application WaitForNoise and a bounded authorized test instead of transferring the silence contract by analogy. Keep documented API, installed help and observed behavior separately labelled.
Prove received voice frames before tuning the wait
A wait application cannot classify media that never reaches its channel. Before changing duration or timeout, establish signaling, negotiated media, the exact channel leg and received voice frames during the interval. A connected call, bridge membership or rising packet counter elsewhere is not the same observation.
Muted endpoints, direct media, an external bridge owner, one-way audio, codec failure or early-media handling can move or remove the frames expected by the dialplan. Follow the call path first. Protect payloads and personal call data, and use only the least intrusive authorized evidence.
Choose a detector whose semantics match the job
WaitForSilence() and WaitForNoise() pause dialplan progress until a duration and iteration condition is met or a timeout returns. BackgroundDetect() is a different application: it plays a file, monitors received audio, applies minimum, maximum, silence and analysis-time conditions, and can jump to the talk extension. TALK_DETECT() produces channel talking or silence notifications rather than serving as the same blocking wait.
Do not replace one with another merely because every feature mentions silence or speech. Preserve whether the design needs a blocking gate, playback interruption, event notification or answering-machine classification, then validate the chosen application on the installed branch.
Accept timeout, classification and caller outcome separately
For one authorized non-emergency test, retain application start and end time, exact arguments, channel identities, answer and bridge state, received-media evidence, immediate status value and the next executed priority. Test representative quiet, speech, background-noise, muted, one-way-audio and hangup cases within a bounded window.
A SILENCE result is not proof that a person finished speaking, and a timeout is not proof that the threshold is wrong. Record what the listener heard and what the downstream application did separately. Restore prior dialplan and logging after the test; no host, module, dialplan, channel, packet, media frame, detector, endpoint or live call was tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk 23 WaitForSilence application ↗
- Asterisk 23 WaitForNoise application ↗
- Asterisk 22 WaitForSilence application ↗
- Asterisk 22 WaitForNoise application ↗
- Asterisk 23 BackgroundDetect application ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.