Asterisk AMI DAHDI span and channel inventory with alarm evidence

Name the layer and observation window first

Record the responding Asterisk node and build, loaded chan_dahdi module, DAHDI package and kernel-driver context, configuration owner, manager identity and capture time. Keep physical port, DAHDI span, DAHDI channel, Asterisk channel, logical group, carrier circuit and call leg as separate identifiers.

AMI exposes Asterisk observations. A returned row does not by itself prove cabling, carrier service, clock quality, analog voltage, echo behavior or audio quality.

Use the span action only where the version supports it

Action: DAHDIShowStatus is documented as similar to the CLI dahdi show status and first appears in 18.23.0, 20.8.0 and 21.3.0. Check the exact branch and loaded module before treating an unknown action as an empty span inventory.

The published syntax documents no arguments, including no ActionID. Preserve the complete raw response, connection identity and timestamps; do not invent a transaction identifier, row event or completion event that the action contract does not document.

Take a separate channel snapshot

Action: DAHDIShowChannels is documented as similar to dahdi show channels. It accepts an ActionID and optional DAHDIChannel; zero or omission requests all channels. Retain the action request, response and raw output exactly as returned by the installed branch.

Treat this as a channel inventory, not a span-alarm history. A channel number is not interchangeable with a physical port, span number, group number or transient Asterisk channel name.

Use events as change evidence, not census rows

DAHDIChannel is raised when a DAHDI channel is created or an underlying technology is associated with it, and carries Asterisk channel identity plus DAHDIGroup, DAHDISpan and DAHDIChannel. SpanAlarm carries a span and textual alarm; SpanAlarmClear carries the cleared span.

These events mark observed changes after the collector is authorized and listening. Their absence does not prove that no channels or alarms exist, and a clear event without retained prior state is not a complete alarm history.

Build a reconciled evidence table

For one node and time window, retain the span snapshot, channel snapshot, configuration source, module state and relevant alarm events. Join only on explicit span or channel identifiers and mark unmatched rows rather than guessing mappings.

Record active calls separately because live channel state can change during collection. Repeat a bounded snapshot after an approved change, then compare row presence, identifiers and alarm transition chronology.

Collect narrowly and disclose what remains unknown

Use a dedicated AMI identity with source restrictions, only the required action and event classes, and explicit filters that retain DAHDIChannel, SpanAlarm and SpanAlarmClear. Restrict network reachability and protect credentials and circuit identifiers.

No PBX, FreePBX system, module, driver, card, gateway, span, channel, line, carrier circuit, configuration, manager account, credential, event stream, call, packet or audio was inspected or tested. Validate against authorized hardware and carrier records before operational reliance.

Keep PRI status and DAHDI inventory distinct

The AMI PRI guide narrows digital-span status and debug collection without collapsing PRI and DAHDI identifiers.