VoIP.info Troubleshooting

FreePBX Asterisk Info report is missing, stale or contradicts the CLI

Trace module, data provider, query, transform, observation time and owning Asterisk object before reloading, restarting or changing a working endpoint or trunk.

Reviewed 2026-10-16Sangoma Asterisk Info documentation, the FreePBX Asterisk Info and ARI Manager release/17.0 repositories, and current Asterisk CLI documentation reviewed October 16, 2026. The Asterisk Info release branch exposed module version 17.0.2 and an ARI Manager dependency when reviewed; that repository state does not establish the versions installed or loaded on a selected PBX. The report surfaces snapshots from Asterisk, while configuration ownership, module state, report implementation, time, node, command output and service outcomes remain separate. No PBX, module, ARI or AMI session, endpoint, trunk, channel, queue, conference, voicemail box, subscription, packet, media stream or live call was inspected or testedAdvancedDocumentation based · not lab tested

Freeze one discrepancy with exact scope

Record the PBX node, Asterisk version and uptime, installed and enabled Asterisk Info and ARI Manager versions, report and subsection, browser time, last reload shown, disputed row or field, expected value and the independent observation that conflicts. Preserve the page result and any displayed error before refreshing, applying configuration or restarting.

Classify the first failure as menu absent, module disabled, dependency unavailable, report query failed, blank report, stale row, transformed value, time-skewed comparison or genuine loaded-state difference. A missing row is not automatically a missing endpoint, and a stale row is not proof that the deleted object can register or receive calls.

Prove module and data-provider state before changing service configuration

Verify the installed Asterisk Info release, enabled state, signature state and declared dependency. Confirm the installed ARI Manager module and the local Asterisk interfaces required by that release without exposing credentials or broadening a listener. Review module and web-service errors from the same request window.

The FreePBX 17 source enables HTTP and ARI configuration during Asterisk Info installation and declares ARI Manager as a dependency; that source behavior does not prove the selected PBX retained, generated or loaded the same state. Keep the GUI module, generated settings, local listener, authentication and report request as separate checkpoints. Do not expose ARI to an untrusted network as a report repair.

Compare the same object and time through the CLI

Choose the narrow CLI inventory or detail command that owns the disputed value on the installed Asterisk build. Capture object name, technology, unique identifiers and command time. For registration or contact questions, do not compare an outbound Registry row with a phone contact or reduce endpoint, AoR, contact and registration to one label. For active calls, distinguish channel, bridge and call.

If the CLI and report now agree, the first comparison may have crossed a state change or refresh boundary. If they still disagree, preserve both outputs and inspect report filtering, source class, transformation and cache behavior before touching the working object. Never use an originate, reload, restart or module unload as the first observational command.

Trace a stale or contradictory row to its lifecycle owner

For a removed extension or trunk, compare the FreePBX source record, generated configuration, loaded PJSIP endpoint, AoR, contact or outbound registration and live channels. Apply Config, an Asterisk reload and an Asterisk restart are different lifecycle events. A stale report row can coexist with correct routing and must not be treated as authorization or reachability by itself.

For queues, conferences, hints and voicemail, use their owning runtime command or event source. A member state, watcher count or message total can change while a browser page remains open. Establish whether the report is expected to be point-in-time, refreshed on navigation or fetched asynchronously, then repeat one controlled observation rather than repeatedly restarting service.

Repair the earliest demonstrated boundary and retest service separately

Correct only the proven module, dependency, generated-setting, local-interface, query or rendering fault. If a restart is actually required for loaded-state cleanup, schedule it with active-call checks, rollback and an explicit service window. Retain the before-and-after report and CLI evidence on the same node and version.

Then test the affected function independently: registration, inbound and outbound routing, queue or conference behavior, BLF event delivery, voicemail access and two-way media as applicable. A repaired report is not proof of those outcomes, and a working call does not prove every report is current. No PBX, module, endpoint, trunk, queue, conference, subscription, voicemail box or call was inspected or tested for this documentation-derived workflow.

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.