Freeze one disputed mailbox query
Record the intended and observed Asterisk node, branch and maintenance release, manager session, exact action, full mailbox@context value, unique ActionID, send and receive times, raw response, collector version and the missing or disputed fact. Redact credentials and message metadata.
Classify the first gap as wrong node, login failure, action unavailable, permission denial, malformed request, wrong mailbox or context, backend mismatch, response not correlated, unexpected field mapping, stale store, parser loss or cache reuse.
Prove the exact mailbox, backend and action boundary
Confirm that the request reached the intended instance and that the mailbox exists in the stated voicemail context on the owning backend. Verify action availability and manager visibility in the current session instead of assuming another node or release has the same surface.
Do not change the context, manager permissions and backend refresh behavior together. Preserve the failed case, then correct the earliest demonstrated boundary with one reversible change.
Inspect the raw Waiting field before Boolean normalization
Preserve the complete MailboxStatus response as text. The branch-22-generated reference describes Waiting as 0 when messages are waiting and 1 when none are waiting; compare the installed server response with MailboxCount and the owning store before translating the value into true or false.
Record which documentation branch and collector mapping were used. A dashboard label that silently assumes the opposite convention can create an apparently inverted result even when transport and permissions are sound.
Separate store freshness from query and cache freshness
Compare the AMI collection time, collector cache time and voicemail-store update time. For an authorized IMAP-backed deployment, use the documented, narrowly scoped refresh path only after proving external modification and module ownership. For an external-MWI deployment, inspect that state owner separately.
Do not mass-refresh mailboxes or issue MWIUpdate or MailboxStateChange to make a local mailbox query agree. A successful write would change state, not validate the original read.
Compare independent evidence at the same scope
Use MailboxCount for urgent, new and old aggregates; use VoicemailBoxSummary or the voicemail application and storage evidence for detailed contents; and use VM_INFO with an explicit folder for a dialplan-side folder count. Keep phone indicators and PJSIP message-summary subscriptions as downstream MWI evidence.
Compare the same node, mailbox, context, backend, folder and time. A correct count does not establish message playback, endpoint subscription health or the state of a phone lamp.
Retest a clean session and close only the proven boundary
Start a clean manager session, issue one narrow action with a fresh identifier, preserve the raw response and compare it with one independent source that owns the disputed fact. Repair the mailbox key, permission, response mapping, refresh ownership or cache behavior actually demonstrated and restore approved access scope.
No PBX, mailbox, voicemail store, IMAP account, manager configuration, socket, response, MWI subscription, endpoint, phone, message, playback or live call was inspected or tested for this diagnostic.
Check user-list and backend status separately
If identity is disputed, the voicemail-user diagnostic checks framing, module ownership and context first.
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.