Name the server and manager session before the query
Record the intended Asterisk node, running branch and maintenance release, manager listener and protected transport, manager username, session identity and collection time. Establish authentication and user-scoped action visibility before treating a response as evidence from the expected PBX.
A reachable manager socket or successful Login does not prove that the client reached the intended node, that these actions are visible to the account or that later data belongs to the same connection.
Send the documented action with a unique ActionID
The generated references define Action: CoreStatus and Action: CoreSettings; each accepts an optional ActionID that is returned for transaction correlation. Use a new, non-secret identifier for each request, terminate the AMI message with a blank line and retain the complete response frame.
Do not infer which request a response belongs to from arrival order alone when a client pipelines actions or shares a connection. Keep reconnects as new sessions and do not reuse late responses from a closed connection.
Ask CoreStatus only for core status evidence
Asterisk describes CoreStatus as a query for PBX core status variables. Treat its response as a point-in-time statement from one running core. Preserve the returned field names and values exactly as supplied by the installed release rather than forcing them into a schema copied from another branch.
Core status is not a call-quality test, SIP registration inventory, channel census, configuration diff or root-cause explanation. Correlate any restart or reload interpretation with the selected node, clock and independent service evidence.
Ask CoreSettings only for reported core settings
Asterisk describes CoreSettings as a query for PBX core settings such as version information. Preserve the whole response and distinguish a reported setting or limit from current usage, effective module behavior and the source file or automation that owns it.
A value returned by the action does not prove spare capacity, successful reload, healthy trunks or that a configuration-management system would reproduce the same state after restart.
Compare snapshots without erasing their boundaries
Attach server identity, session identity, action, ActionID, request time, response time and collector version to every snapshot. Compare like with like: same action, node and maintenance context. Preserve absent fields and newly added fields instead of silently substituting defaults.
The AMI v2 specification allows fields to be added to existing messages. Parsers should accept additional fields, retain the raw frame and alert separately on missing required evidence, malformed messages, unexpected values and transport loss.
Corroborate the operational question at its owning boundary
Use user-scoped command inventory and manager permissions to explain action availability. Use server-side process, configuration-lifecycle, logging, channel, SIP and call-path evidence for the operational question itself. Keep collection read-only and narrowly authorized.
Accept the integration only when it can identify the right node, correlate both actions independently, preserve complete responses and state what neither response proves. No PBX, manager configuration, account, socket, response, core value, channel, packet, media stream or live call was inspected or tested for this guide.
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.