Freeze the observer and first missing or extra line
Record timestamp and timezone, full Asterisk release, dialplan revision, console session, root and current-console verbosity, debug level, configured logger channels, active logger-filter output, expected group, exact channel name, call identifier, dialplan context and priority, and the first line that is missing or unexpectedly visible.
Classify the first divergence as function unavailable, assignment never executed, assignment on another channel, later replacement or clearing, different group spelling, filter state, console verbosity, log level, logger destination or an incorrect expectation about protocol output.
Prove the function and the assignment priority
Confirm LOG_GROUP() exists on the installed branch. Follow the channel through the priority containing Set(LOG_GROUP()=name) and verify that execution reaches it before the line being diagnosed. Asterisk recommends early assignment because filtering can affect the dialplan output visible from the start of the call.
Use the documented alphanumeric group value exactly. Do not assume that a configuration save, dialplan reload or the presence of the function in current online documentation proves that the running channel executed the write.
Find replacements, clears and channel boundaries
Search the loaded dialplan for every LOG_GROUP() write on the path. A later write replaces the previous assignment and an empty write removes it. Mark the exact priority and time of each change.
Then inventory new legs: outbound Dial channels, Local-channel halves, queue members and transfer-created channels. A correct group on the caller does not establish the same group on a callee. Correlate channel names and call identifiers instead of treating the whole call as one channel object.
Inspect filter, console and logger state separately
Read the active logger filter and compare its enabled group names with the channel assignment. Then inspect current-console versus root verbosity, enabled debug or verbose levels and configured logger destinations. The console that appears empty may have a different verbosity from another console, while a file can have different levels from either console.
Do not toggle multiple filters and verbosity levels at once. Preserve the prior state so the first mismatch remains attributable and the observer can be restored after the reproduction.
Do not use group filtering as protocol proof
If the expected dialplan line becomes visible, continue to the evidence type the incident actually requires. SIP signaling needs a bounded, correlated PJSIP trace; media symptoms may need RTP or RTCP evidence; routing needs loaded dialplan and channel transitions; billing questions need the appropriate CDR or CEL record.
LOG_GROUP() does not create those records or prove their contents. Asterisk call identifiers are also separate from group names and may behave differently across transfers.
Correct one boundary, reproduce once and clean up
Correct only the first proven mismatch: version, entry priority, group spelling, replacement, clearing, channel leg, filter selection, console verbosity, log level or destination. Repeat one authorized test and confirm both the intended line and an expected excluded line so the filter is not merely open.
Restore the previous filter, verbosity and temporary logger state, remove sensitive output and retain the minimal redacted artifact with its time window. No PBX, module, console, channel, dialplan, group, filter, log file, packet or call was inspected or tested for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk LOG_GROUP dialplan function ↗
- Asterisk 22 LOG_GROUP dialplan function ↗
- Asterisk logging overview ↗
- Asterisk basic logging commands ↗
- Asterisk call identifier logging ↗
- Asterisk collecting debug information ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.