Start with the channel that owns the audiohook
Asterisk documents TALK_DETECT() as a channel function that raises notifications when it detects talking or silence. It uses an audiohook to inspect voice media frames on the channel where it is applied. Name the exact channel, unique identifier, call leg and media direction before treating an event as evidence about a wider call.
A shared linked identifier, bridge membership or customer conversation does not move the detector to every peer. A talking event proves that the detector crossed its configured boundary on that channel; it does not by itself prove answer, bridge entry, intelligible speech, transcription, remote audio or who spoke.
Enable, update and remove one detector explicitly
Writing TALK_DETECT(set) enables the detector. The documented write arguments are dsp_silence_threshold first and dsp_talking_threshold second; the function can be written again to change the parameters on an already enabled channel. Writing TALK_DETECT(remove) removes it.
The following isolated example only shows function ordering and syntax. It does not answer, originate, bridge or verify a call.
[sa-talk-detect-example]
exten => 7301,1,NoOp(Attach detector to this channel only)
same => n,Set(DENOISE(rx)=on)
same => n,Set(TALK_DETECT(set)=1200,256)
same => n,NoOp(The application consuming media and events belongs here)
same => n,Set(TALK_DETECT(remove)=)
same => n,Hangup()Keep the two thresholds in different units
The first argument, dsp_silence_threshold, is time in milliseconds below the talking boundary before Asterisk considers the user silent. Asterisk 22 documents a 2500 ms default. A value that is too short can emit a stop notification during a natural pause.
The second argument, dsp_talking_threshold, is the minimum average magnitude per sample in a frame for talking or noise to be present. It is not a duration. Asterisk documents values from 1 through 32768 and a default from dsp.conf silencethreshold, or 256 when that setting is absent. A low magnitude can let room noise trigger starts.
Treat audiohook order as part of the configuration
Asterisk says TALK_DETECT, JITTERBUFFER, DENOISE and AGC use audiohooks and that audiohooks are processed in placement order. If detection is meant to inspect denoised received audio, place DENOISE(rx) before TALK_DETECT(set), as the official example does. Record the actual order rather than inferring it from the final dialplan file alone.
DENOISE itself distinguishes rx, audio received from the channel, from tx, audio sent to the channel. A filter on the wrong direction or attached after detection does not establish what frames the detector evaluated.
Map AMI and ARI event schemas without merging them
AMI documents ChannelTalkingStart and ChannelTalkingStop. Both identify the channel and include Uniqueid and Linkedid; the stop event also reports the detected talking duration in milliseconds. ARI uses ChannelTalkingStarted and ChannelTalkingFinished; its finished data model includes the channel and duration in milliseconds.
Preserve the interface, event name, application or session, timestamp and channel identifiers. AMI class filters, ARI Stasis application scope, reconnects and consumer logic are separate from detector configuration. Absence at one consumer is not automatically absence inside Asterisk.
Qualify thresholds with bounded evidence
For an authorized test, preserve the installed branch, loaded function and modules, channel identifiers, detector write, audiohook order, media evidence, event stream and timestamps. Use several bounded samples that include speech, natural pauses and representative background conditions. Change one threshold at a time and record expected and observed event boundaries.
Do not convert event timing into speech-recognition accuracy or laboratory validation. Remove the detector and restore the prior dialplan or channel path if downstream automation, privacy treatment, recordings or unaffected calls change.
Choose blocking wait or asynchronous talking events deliberately
The silence and noise wait guide distinguishes blocking WaitForSilence() and WaitForNoise() behavior from TALK_DETECT() notifications and BackgroundDetect() playback interruption.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk 22 TALK_DETECT function ↗
- Asterisk 22 DENOISE function ↗
- Asterisk 22 AMI ChannelTalkingStart event ↗
- Asterisk 22 AMI ChannelTalkingStop event ↗
- Asterisk 22 ARI data models ↗
- 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.