Asterisk AMI DAHDI span or channel is missing, alarmed or inconsistent

Freeze one node and contradiction

Record node, Asterisk build, process start context, chan_dahdi state, DAHDI driver context, configuration source, expected physical port, span, channel and group, manager identity, request and response, recent alarm events and the first contradictory timestamp.

Classify the symptom as unknown action, empty or partial span snapshot, missing channel, wrong mapping, active alarm, alarm without a clear, clear without prior state, or call and audio behavior that contradicts the control-plane evidence.

Prove observation support before interpreting absence

Check the installed branch against the documented DAHDIShowStatus introduction points: 18.23.0, 20.8.0 and 21.3.0. Confirm chan_dahdi, the expected kernel driver and required AMI permissions on the exact responding node.

Inventory available actions for the authenticated manager account. Repair version, module, driver or authorization visibility before treating an unknown or denied action as evidence that spans are absent.

Repeat span and channel snapshots separately

Capture the complete raw DAHDIShowStatus response, then issue DAHDIShowChannels with a fresh ActionID; first request all channels, then use DAHDIChannel only to narrow a known identifier. Do not wait for an undocumented completion event.

Compare both snapshots with the authoritative configuration and DAHDI driver view from the same node and time window. Mark missing and extra mappings explicitly.

Reconstruct alarm chronology from retained events

Verify the manager read class and filters allow both SpanAlarm and SpanAlarmClear, then order events by collector receipt and Asterisk timestamps where available. Join alarm transitions to the explicit span identifier, not a guessed channel or group.

A SpanAlarm reports Asterisk receiving an alarm description; it does not locate a cable or carrier fault. A SpanAlarmClear reports a transition, not proof of uninterrupted stability afterward.

Cross the hardware boundary deliberately

If Asterisk evidence and expected inventory disagree, inspect the authorized DAHDI driver state, generated and effective channel configuration, card or gateway mapping, timing source, signaling mode, cabling and carrier handoff with the responsible owners. Preserve before-and-after identifiers.

For analog symptoms, separate hook, ringing, polarity, caller ID, gain, echo and audio evidence. For digital spans, separate framing, coding, timing and carrier alarms. Do not infer these physical conditions from AMI alone.

Repair the first owner and verify a bounded case

Correct only the demonstrated owner: Asterisk version, module load, kernel driver, AMI authorization or filter, collector logic, generated configuration, span or channel mapping, signaling, hardware, cabling or carrier service. Repeat both snapshots and retain the next alarm transition.

Then place one authorized test call only if the deployment owner permits it and record that result separately. No PBX, module, driver, hardware, span, channel, line, circuit, event stream, call, packet or audio was inspected or tested for this guide.

Escalate a digital span through the PRI layer

The AMI PRI diagnostic reconciles PRI status and bounded signaling debug with DAHDI and carrier evidence.