Freeze one disputed request and response boundary
Record the intended and observed server identity, running branch and maintenance release, manager listener and transport, account, session identity, exact action, unique ActionID, send and receive times, raw response with secrets redacted, collector version and the value considered missing, stale or wrong.
Classify the first failure as wrong node, connection or login failure, malformed request, action unavailable, permission denial, response not correlated, frame truncated, field not parsed, old snapshot reused or valid value disputed by a different evidence source.
Prove the current session and target node
Confirm the request followed the intended protected path to the expected Asterisk instance and that the client did not reuse cached identity across a reconnect, failover or restart. Correlate the Login result and user-visible action inventory within the same session.
Do not rotate credentials, broaden ACLs and change the target simultaneously. A successful connection to another listener can return internally consistent but operationally wrong evidence.
Validate the action frame and correlation identifier
Verify the exact Action: CoreStatus or Action: CoreSettings header, one ActionID, Header: value formatting and the terminating blank line. Retain the complete response rather than only a dashboard field. Match on both current session and returned identifier.
A client that relies on arrival order can attribute a valid response to the wrong request. A parser that stops early can drop later fields while still displaying a green collection status.
Separate action availability from the returned value
Use the manager account's visible command inventory and effective authorization before labeling an empty result as a core fault. Distinguish unknown or unavailable action, authorization error, malformed request, transport close and a successful response whose schema differs from the collector's expectation.
Do not grant every manager class to test the theory. Identify the least permission needed for the documented read path, preserve the negative case and restore the approved scope.
Interpret status and settings as different evidence
If a status value is disputed, compare the same node and clock with independent process, restart and reload evidence. If a setting is disputed, compare the reported value with the effective configuration owner and running version. Keep configured limits separate from current load, and keep version or process facts separate from channels, registrations and call health.
Do not make one action substitute for the other. A successful response establishes only that the current session received that response from its target.
Repair the earliest demonstrated boundary and retest
Make one reversible correction to target selection, framing, permissions, correlation, parser tolerance or cache handling. Start a clean session, issue both actions with fresh identifiers, preserve their raw responses and compare them with the independent evidence source that owns the disputed fact.
Close only when the collector identifies the correct node and session, accepts additional fields, flags missing evidence and avoids converting a core snapshot into a call-health claim. No PBX, manager configuration, account, socket, response, value, channel, packet, media stream or live call was inspected or tested for this diagnostic.
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.