Name the owner before selecting an action
Record the intended Asterisk node, installed branch and maintenance release, loaded voicemail or external-MWI module, manager session, mailbox identity, context, storage owner and downstream endpoint. Decide whether an external program changed stored voicemail, an external service owns count state or a remote Asterisk node is synchronizing state.
A voicemail mailbox, external MWI object, remote mailbox state and SIP message-summary subscription are not interchangeable. Select the action only after naming the owner.
Scope VoicemailRefresh narrowly
The documented VoicemailRefresh action tells Asterisk to poll for mailbox changes made outside the voicemail application. With no Context, it polls all mailboxes; with a context and no mailbox, it polls that context; with both, it polls one mailbox. Use a unique ActionID and the narrowest supported scope.
The current branch-23 page is generated under app_voicemail_imap, while the branch-22 page is generated under app_voicemail_odbc. Verify the installed action and module rather than converting either generated page into a universal backend claim.
Treat MWIGet and MWIUpdate as external-MWI state
The current and branch-22 pages assign MWIGet and MWIUpdate to res_mwi_external_ami. MWIGet accepts a specific mailbox or a slash-delimited regular expression. MWIUpdate requires a specific mailbox and count fields; omitted OldMessages or NewMessages default to zero.
Send both counts explicitly and preserve mailbox identity. Do not use a broad regular expression or zero default to conceal an ownership or inventory problem.
Keep MailboxStateChange remote and version bounded
The branch-22-generated page documents MailboxStateChange from maintenance releases 24.1.0, 23.7.0, 22.13.0 and 20.23.0. It is for synchronizing remote mailbox state and says it should not set local mailbox state. The remote EntityID is required, and a value matching the local system is rejected.
The same page distinguishes this lighter remote-state action from MWIUpdate, which depends on res_mwi_external. Check the exact installed release and action inventory before use.
Separate accepted control from delivered indication
An accepted AMI control request does not prove stored messages changed, the intended state owner emitted an update, a SIP subscription exists, a message-summary NOTIFY traversed the network or a phone rendered a lamp. Correlate each boundary using its own timestamps and identity.
Keep MailboxCount, MailboxStatus, MWIGet, raw NOTIFY evidence and endpoint display as separate observations. A disagreement identifies the next boundary; it does not make one source universally authoritative.
Bound access, fan-out and recovery
Use a dedicated least-privilege manager account, redacted retained frames and explicit rate and scope limits. In a controlled environment, exercise one known mailbox, wrong context, unsupported action, denied action, remote EntityID rejection, complete count transition and a downstream subscription control.
Do not enable global polling, widen manager permissions or publish mailbox identifiers merely to satisfy a collector. No PBX, module, mailbox, store, backend, manager session, response, subscription, NOTIFY, endpoint, phone, message, playback or live call was inspected or tested.
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.