Start with observation, not suppression
FRAME_TRACE() exposes internal Asterisk frames as they are read from and written to the current channel. It can whitelist named classes, blacklist named classes or emit all classes when no filter is supplied. Use the smallest whitelist that answers the incident question; an unrestricted trace can create large, sensitive output and make the first divergence harder to find.
FRAME_DROP() changes call behavior by preventing selected frames from being received from or sent to one channel. It is not a quieter form of tracing. Do not drop a frame merely because its trace looks unexpected, and do not represent a call that succeeds after suppression as proof that the original sender, receiver or protocol behavior was corrected.
Name the channel and both directions
Asterisk defines FRAME_DROP RX as preventing Asterisk from receiving the selected frame from the channel and TX as preventing Asterisk from sending it to the channel. Those labels are relative to the exact channel object, not to the human caller, the whole bridge or the network capture direction.
Record the channel name, unique ID, linked ID, caller or callee role and dialplan priority before enabling either function. Caller, callee, Local-channel halves, queue members and transfer-created legs remain separate owners. A frame traced on one leg is not proof that a sibling leg received or emitted the same event.
Filter the frame class that matches the symptom
FRAME_TRACE() lists DTMF_BEGIN, DTMF_END, VOICE, VIDEO, CONTROL, NULL, IAX, TEXT, TEXT_DATA, IMAGE, HTML, CNG and MODEM as filterable classes. A DTMF complaint should begin with the two DTMF classes; an audio complaint may need VOICE and selected CONTROL chronology. One observed internal frame does not establish the original wire encoding, far-end interpretation or audible result.
A white list includes only named types. A black list excludes the named types. Omitting the list type defaults to white-list behavior, while omitting arguments traces all frames. Preserve the exact expression so an empty or broad result is not misread.
Treat control subtypes as call-state changes
FRAME_DROP() can suppress broad CONTROL frames or individual control subtypes including RING, RINGING, ANSWER, BUSY, CONGESTION, PROGRESS, PROCEEDING, HOLD, UNHOLD, CONNECTED_LINE and REDIRECTING. These are not interchangeable decorations. Removing one can alter answer supervision, early media, hangup treatment, hold state or identity updates.
Asterisk explicitly warns that dropping ANSWER may require a deliberate Progress() path to avoid undesired behavior. Do not translate that example into a general answer-supervision workaround. Define the expected state machine, test only on an authorized path and preserve the independent SIP, channel and bridge evidence.
Make temporary frame dropping reversible
A later FRAME_DROP write replaces the previous setting, which allows a narrow temporary experiment and an explicit restoration. Record the prior value, intended frame list, start priority, stop priority and cleanup path. Include hangup and exception handling so an early branch does not leave later dialplan behavior different from the accepted design.
Never leave VOICE, DTMF, ANSWER, HOLD or identity-related suppression in place as a production diagnostic shortcut. Prove both the target effect and an unaffected control call, then restore the original path before analyzing the retained evidence.
Correlate internal frames with the right external evidence
An Asterisk frame trace is a channel-internal observation. SIP methods and responses need a bounded signaling trace; RTP, RTCP and telephone-event questions need the appropriate packet evidence; audible or decoded behavior needs endpoint and user-path confirmation. Logger levels, destinations and collection windows remain separate from the FRAME_TRACE filter.
Store the smallest redacted artifact with timestamp, timezone, channel IDs and dialplan revision, then disable temporary tracing and extra logging. This guide is documentation-derived; no PBX, frame stream, packet path or call was tested.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk FRAME_TRACE dialplan function ↗
- Asterisk FRAME_DROP dialplan function ↗
- Asterisk logging overview ↗
- Asterisk collecting debug information ↗
- Asterisk CHANNEL dialplan function ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.