Asterisk frame trace shows no DTMF, voice or expected control event

Freeze one missing event and one channel

Record timestamp and timezone, full Asterisk version, dialplan revision, exact symptom, channel name, unique and linked IDs, caller or callee role, bridge or application state, trace expression, logger destination and the first expected DTMF, VOICE, VIDEO or CONTROL event that is absent. Preserve the matching SIP and packet identifiers when they exist.

Classify the first divergence as unavailable function, trace never executed, wrong channel, wrong read or write viewpoint, incorrect white or black list, missing logger output, event not converted into an Asterisk frame, frame removed elsewhere or an incorrect expectation about the call state.

Prove function availability and execution

Confirm the installed build exposes FRAME_TRACE() and, only if a controlled suppression test is approved, FRAME_DROP(). Current documentation lists FRAME_TRACE from 10.0.0 and FRAME_DROP from 16.21.0 and 18.7.0, but online pages do not prove package contents or loaded functions.

Follow the live channel through the priority that enables the trace. A saved FreePBX or custom-dialplan edit, successful reload or correct-looking file does not prove the affected channel executed that line before the expected frame.

Correct the filter before interpreting an empty trace

For DTMF, whitelist both DTMF_BEGIN and DTMF_END. For media, select VOICE or VIDEO and the smallest necessary CONTROL context. Confirm whether an omitted list type is intentionally using the default white list. A black list with the target type removes it from the view, while an empty argument set produces a broad trace rather than a narrow one.

Inspect logger level, destination and collection window separately. An empty console can be a logging-observer failure even when frames exist; a visible frame remains internal evidence, not proof of a wire packet or decoded result.

Map RX and TX to this channel, then follow sibling legs

State the viewpoint in plain language: frames Asterisk reads from this channel versus frames it writes to this channel. Then repeat the map for the other leg only if the evidence requires it. Do not label RX as universally inbound or TX as universally outbound across a bridge.

If an event exists on the caller leg but not the callee, inspect the application, bridge, Local-channel optimization, direct media and feature logic between them. A shared linked ID correlates legs; it does not make them one channel or prove frame forwarding.

Keep protocol and media evidence attached to their layers

A DTMF_BEGIN or DTMF_END frame does not by itself identify RFC 4733, in-band audio or SIP INFO on the external leg, nor prove that an IVR consumed the digit. A VOICE frame does not prove continuous RTP, correct codec translation or audible speech. A CONTROL frame does not replace the corresponding SIP response, channel-state transition or bridge event.

Compare the internal chronology with the bounded PJSIP trace, packet capture, application log and endpoint observation needed by the symptom. Stop at the first layer where the event diverges.

Do not turn FRAME_DROP into the repair

If an approved isolation test requires suppression, choose one exact frame type, one direction, one channel and one short window. Preserve the prior state, establish a cleanup priority and verify both the intended effect and an unaffected control. Dropping ANSWER, DTMF, VOICE, HOLD, CONNECTED_LINE or REDIRECTING can materially change call behavior.

Restore the original setting immediately and correct the demonstrated owner: sender behavior, dialplan timing, channel selection, bridge logic, logger configuration or protocol path. No PBX, module, dialplan, channel, frame, DTMF event, control event, media stream, log, packet or call was inspected or tested for this diagnostic.

Trace periodic audio on the asynchronous and owner channels

The periodic-hook diagnostic separates hook-channel playback, injection into the owner call and final decoded audio before broad frame tracing.