Asterisk TALK_DETECT events are missing, early or late

Freeze one event symptom on one channel

Record one authorized occurrence with timestamp and timezone, installed Asterisk branch, channel name, Uniqueid, Linkedid, call leg, Stasis application where relevant, expected event and actual event. Classify the first divergence: no start, no stop, repeated starts, start on background noise, stop during a pause, delayed stop, wrong channel or event present at one interface but absent from the application.

Preserve the dialplan, loaded state and consumer interval before changing thresholds. A missing application log line does not yet prove that TALK_DETECT failed.

Prove the function was attached to the intended live channel

Locate the executed Set(TALK_DETECT(set)=...), not merely a line in a file, and correlate it to the same channel identifier used by the expected event. Confirm that func_talkdetect is available on the installed branch and that the detector was not removed or replaced before the symptom.

If a Local channel, originated leg, transfer or bridge is involved, map every created channel. Setting the detector on one leg does not enable it on the peer, and a common linked identifier is not a substitute for the exact channel identity.

Prove voice media frames reached that channel

TALK_DETECT inspects voice media frames through an audiohook. Establish that the selected channel received the intended frames during the interval, with approved RTP, channel and application evidence. Separate signaling success, answer state and bridge membership from media flow.

If no relevant media reached the channel, stay on negotiation, routing, address, firewall, bridge or application ownership. Threshold tuning cannot recover frames the detector never received. Protect payloads and personal call data in every capture.

Read silence time and talking magnitude in the correct positions

Resolve the executed value as silence milliseconds,talking magnitude. An empty first value with a second number changes the talking boundary; one number changes the silence duration. Confirm the effective dsp.conf silencethreshold when the magnitude is omitted.

For stops during normal pauses, examine whether the silence duration is too short. For starts caused by stable background noise, examine whether the magnitude is too low. Do not describe the second argument as milliseconds or raise both values together without evidence.

Reconstruct audiohook order and direction

List DENOISE, AGC, JITTERBUFFER and other audiohooks in the order actually attached to the channel. Asterisk processes audiohooks in placement order. If the design expects received audio to be denoised before detection, prove that DENOISE(rx) was attached first; tx addresses audio sent to the channel and is a different path.

Correct only the demonstrated order or direction. A later DENOISE function does not retroactively change the frames already inspected by TALK_DETECT, and broad gain or noise changes can alter other applications.

Trace the documented event to the selected consumer

For AMI, look for ChannelTalkingStart and ChannelTalkingStop and match Uniqueid, Linkedid and timestamps; the stop event includes duration in milliseconds. For ARI, trace ChannelTalkingStarted and ChannelTalkingFinished within the intended Stasis application, and match the channel plus finished duration.

Then inspect permissions, event filters, Stasis scope, WebSocket or manager connection continuity, reconnect behavior and application deduplication. Keep “Asterisk emitted no event” separate from “this client did not receive, parse or retain it.”

Change one boundary and retest a controlled matrix

Correct the first proven divergence: wrong channel, no media, detector removed, threshold position or value, audiohook order or direction, event filter, application scope or consumer continuity. Retest representative speech, natural pauses and approved background conditions while preserving event times and channel identifiers.

Accept only the intended detector and consumer behavior without changing unaffected calls or downstream automation. Roll back the dialplan, filter or threshold if evidence diverges. This workflow is documentation-derived and was not reproduced on an installed or laboratory Asterisk system.

Do not substitute a blocking wait for a missing event

Use the silence and noise wait guide to distinguish a blocking dialplan gate from TALK_DETECT() event production and consumer delivery.