VoIP.info Guide

Asterisk AMI PRI span inventory and bounded debug evidence

Use PRIShowSpans for a bounded PRI status snapshot, then govern PRI debug level and file output as separate operational changes without treating either as physical-line proof.

Reviewed 2026-10-27Current branch-23-generated Asterisk PRIShowSpans, PRIDebugSet, PRIDebugFileSet, PRIDebugFileUnset, SpanAlarm and SpanAlarmClear documentation, AMI v2, event-filtering, logging and network-security guidance were reviewed October 27, 2026; installed Asterisk, libpri and DAHDI versions, chan_dahdi availability, manager permissions, spans, debug levels, file paths, signaling, timing, framing, coding, alarms, hardware and carrier facilities remain deployment-specific; no PBX, FreePBX system, module, driver, card, gateway, span, D channel, B channel, line, circuit, configuration, manager account, credential, event stream, debug file, signaling frame, call, packet or audio was inspected or testedAdvancedDocumentation based · not lab tested

Separate PRI, DAHDI and physical identifiers

Record the responding Asterisk node and build, loaded chan_dahdi module, libpri and DAHDI context, generated and effective configuration owner, manager identity and capture time. Keep PRI span, DAHDI span, D channel, B channel, Asterisk channel, carrier circuit and physical port as separate identifiers.

An AMI status response describes the responding Asterisk process. It does not by itself prove carrier service, cabling, framing, coding, timing, signaling exchange, call completion or audio.

Take the PRI span snapshot exactly as documented

Action: PRIShowSpans is documented since Asterisk 10.0.0 as similar to pri show spans. It accepts an ActionID and optional Span; zero or omission requests all spans, while a value narrows the request to one span.

The action page does not document generated row or completion events. Preserve the complete raw response, ActionID, connection identity and timestamps rather than inventing a list boundary or parsing undocumented prose as a stable schema.

Treat debug level as a state change

Action: PRIDebugSet, documented since 13.0.0, requires Span and Level. The documented text values are Level: off, Level: on, Level: hex and Level: intense; the page also permits a numeric value. Record the exact requested and returned values and do not normalize an unfamiliar numeric level into a named mode.

Use the least verbose mode that can answer the stated question and a defined stop time. An accepted action changes Asterisk debug state; it does not prove that a signaling frame was emitted, retained or interpreted correctly.

Control file output separately and plan teardown

Action: PRIDebugFileSet takes a File path and directs PRI debug output to that file. PRIDebugFileUnset disables file output and has no Span or Level argument. The published contracts do not say that unsetting the file also turns span debug off, so use PRIDebugSet with Level: off as a separate, explicit teardown where appropriate.

Choose an approved path, confirm ownership, free space, rotation, access, retention and deletion before enabling output. Asterisk warns that debug logging can generate large volumes quickly on production systems.

Reconcile inventory, alarms and a narrow reproduction

Capture all PRI spans first, then one specific span when narrowing a known identifier. Retain SpanAlarm and SpanAlarmClear as transition evidence and compare them with the separate DAHDI span and channel inventory, configuration and carrier ticket for the same node and observation window.

If a reproduction is authorized, mark its start and stop, expected signaling step and call identifiers. A debug file may expose called or calling numbers and protocol details; redact shared evidence without destroying the chronology needed to diagnose the boundary.

Collect with least privilege and disclose unknowns

Use a dedicated AMI identity, source restrictions, only the required action and event classes, and filters that retain the relevant alarm transitions. Protect AMI credentials, circuit identifiers and debug output in transit and at rest.

No PBX, FreePBX system, module, driver, card, gateway, span, channel, circuit, configuration, manager account, event stream, debug file, signaling frame, call, packet or audio was inspected or tested. Validate the procedure against the installed branch, authorized hardware records and carrier handoff before operational reliance.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.