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.
- Asterisk PRIShowSpans AMI action ↗
- Asterisk PRIDebugSet AMI action ↗
- Asterisk PRIDebugFileSet AMI action ↗
- Asterisk PRIDebugFileUnset AMI action ↗
- Asterisk SpanAlarm AMI event ↗
- Asterisk SpanAlarmClear AMI event ↗
- Asterisk AMI v2 specification ↗
- Asterisk Manager TCP/IP API ↗
- Asterisk AMI event filtering ↗
- Asterisk logging configuration ↗
- Asterisk network security guidance ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.