FreePBX Asterisk Info: read each report as a bounded runtime snapshot

Identify the report implementation before interpreting a value

FreePBX exposes Asterisk Info under Reports as an advanced troubleshooting view. Sangoma describes it as information obtained from Asterisk that could also be obtained through the Asterisk CLI. The FreePBX 17 release branch identified Asterisk Info 17.0.2 when reviewed, declared ARI Manager as a dependency and described the module as a snapshot of current Asterisk configuration. Record the PBX, Asterisk version, Asterisk Info version, ARI Manager version, report name, browser time and Asterisk uptime before comparing results.

Do not treat the repository version as the installed version or assume every older report label still maps to the same channel driver. Confirm the installed branch, enabled modules and report implementation. A visible menu proves only that the GUI route is available; it does not prove that every data provider, Asterisk module or report query succeeded.

Keep summary counters and call objects distinct

The documented Summary includes uptime, last reload, active SIP or IAX2 channels, registries and peer counts. Sangoma explicitly notes that an active channel count is not an active-call count because one call can contain two or more channels. Record each counter with the report time and then use the Channels report, bridge or channel evidence and call identifiers for the disputed call.

Uptime is process-lifetime evidence, and the displayed reload time is not proof that a particular form value generated, parsed or loaded as intended. A registry count does not identify which trunk is registered. A peer total does not establish which contact is reachable. Never turn one aggregate, one green label or one low-latency number into capacity, call quality, successful routing or media evidence.

Distinguish Asterisk registrations from devices registering to Asterisk

The Registries report documents connections for which Asterisk is the registering client, commonly outbound trunk registrations. It does not list phones or every peer registering to the PBX. The Peers view covers devices or trunks connecting to Asterisk, while the combined SIP and IAX views retain their own technology scope. Keep outbound registration, inbound endpoint identification, AoR contact, qualification status and routed call behavior separate.

For PJSIP, compare the report with the exact loaded endpoint, AoR, contact and outbound-registration objects on the same node and at the same time. A registered trunk can still have wrong number routing, caller identity, authorization or media. A reachable contact can still fail dialplan selection or calls. A report row is not evidence that an endpoint is permitted, dialed or carrying usable audio.

Use channels, conferences, queues and subscriptions as live scopes

Channels are live communication objects, not durable extension records. Conferences describe active bridge consumers. Queue reports describe one current queue and member state view. Subscriptions expose hints and watchers used for presence or BLF. Voicemail-user data reflects mailbox state. Preserve the object type, technology, identity, node and observation time before joining any of those views.

An empty Channels report can be correct when no channel exists. A queue member marked available is not proof that a phone will ring or answer. A hint with watchers is not proof that a lamp updated. A conference row is not proof of two-way media, and a mailbox count is not proof that notification or retrieval works. Continue to the owning application, event stream, logs, signaling and media only when the question requires them.

Cross-check the exact disputed field through the running Asterisk CLI

Asterisk documents the CLI as a surface for inspecting components, changing configuration, viewing logs, generating calls and reading embedded help. That breadth means a CLI session is not automatically read-only. Select the narrow installed command that owns the disputed field, record its help and output, and avoid reload, restart, originate, module or database actions during observation.

Capture the report and CLI output inside one bounded window on the same PBX. Include stable object identifiers where available rather than comparing only display names. If they disagree, preserve both results and the time difference. Determine whether the GUI transformed, cached, filtered or failed to fetch the source before changing the endpoint, trunk, queue or dialplan that may already be correct.

Accept the report as a diagnostic view, not a service verdict

A useful acceptance check starts with an intentionally idle baseline, then one controlled extension registration or trunk state, one bounded test call and the corresponding report changes. Correlate loaded objects, logs, SIP messages, bridge state, RTP directions and decoded audio only as required. Retain redacted screenshots or exports with module versions, node and timestamps; report content can expose numbers, addresses, mailbox state and operational topology.

After updates, rerun the same bounded comparison. Do not restart Asterisk merely to make a report look tidy without assessing active-call impact and preserving the original divergence. No report, registration, channel, queue, conference, subscription, voicemail or call result is claimed from this documentation review.

Compare dashboard aggregates with the exact Asterisk Info object scope

The System Dashboard guide treats call and trunk cards as aggregates. Asterisk Info can expose a different current object scope, so compare node, timestamp and object owner rather than expecting every count to match.