Asterisk PJSIP voicemail lamp is stuck on or off

Prove the mailbox state before diagnosing the lamp

Record the endpoint, mailbox, voicemail context, visible lamp or icon, timestamp and the action that should have changed it. Verify the authoritative new and old message counts for the exact mailbox@context through a supported Asterisk view. A message stored in another context, moved externally, marked urgent or visible only in a user interface can create a different state from the one the phone displays.

Asterisk's branch-22 AMI MailboxStatus and MailboxCount interfaces can inspect mailbox state, while RFC 3842 defines the Messages-Waiting indicator and per-context counts carried in application/simple-message-summary. A correct count in Asterisk does not prove that a NOTIFY was generated, delivered or interpreted.

Identify subscribed or unsolicited MWI ownership

PJSIP MWI can follow a phone SUBSCRIBE to the message-summary package or unsolicited NOTIFYs configured from an endpoint's mailbox list. Capture the endpoint and AOR that Asterisk actually loaded, the SUBSCRIBE where present, the subscription response and the subsequent NOTIFY. Do not combine both models accidentally.

Asterisk documents that endpoint mailboxes sends unsolicited notifications, while an AOR mailboxes value allows subscription for those mailboxes. Its troubleshooting guide warns that configuring both for the same mailbox can cause the subscription to be denied because unsolicited delivery is already selected. The version-sensitive mwi_subscribe_replaces_unsolicited option changes that ownership and must be read from the running endpoint before it is altered.

Match mailbox identity, modules and NOTIFY body

For app_voicemail, use the documented mailbox@context form. A mailbox number without its context can exist as text yet never receive the state changes expected from the actual voicemail store. Confirm res_pjsip_mwi.so, the MWI body generator and the voicemail-state provider used by this deployment are loaded; a module mentioned in documentation is not proof of running state.

Inspect the NOTIFY's Event value, Subscription-State where applicable, Content-Type, Messages-Waiting, Message-Account and message counts. Bind it to the same dialog or unsolicited path and endpoint. A 200 response acknowledges the NOTIFY transaction; it does not prove that the phone accepted the mailbox identity or updated its lamp.

Treat external mailbox changes as a separate source

Asterisk normally knows when its own voicemail application changes a mailbox. If another program modifies external voicemail storage, the internal state can remain stale unless that integration signals a refresh or uses the supported external-MWI path. Asterisk 22 documents VoicemailRefresh for targeted rescans and warns that continuous pollmailboxes scanning can create significant load.

Do not enable global polling or manufacture message counts merely to change a lamp. Identify the storage owner and supported notification mechanism, then refresh only the affected mailbox where appropriate. res_mwi_external is an alternative state source with different ownership and is documented as mutually exclusive with app_voicemail; verify the active architecture before loading or unloading either module.

Separate delivery from phone rendering and aggregation

If the correct NOTIFY reaches the intended contact and receives a final response, inspect the endpoint's account selection, voicemail identity, firmware behavior and local reset rules. A phone with several accounts or mailboxes can aggregate indications differently from Asterisk. Asterisk's aggregate_mwi can condense multiple configured mailboxes into one NOTIFY, while voicemail_extension and mwi_from_user affect identities carried in unsolicited messages.

Do not change caller identity, authentication, contacts or mailbox aggregation together. Compare one known-new and one cleared state, retain the actual NOTIFY bodies and confirm whether the phone keys its lamp to the Event dialog, Message-Account, From user or account registration under its own documentation.

Correct one owner and prove the complete transition

Correct only the demonstrated mailbox context, subscription-versus-unsolicited model, loaded module, external-state refresh path or endpoint interpretation. Preserve the prior configuration and rollback trigger. On a FreePBX-managed host, use supported module controls and generated-configuration ownership rather than editing generated PJSIP files directly.

Leave a new message, confirm the authoritative count changes, observe the matching NOTIFY and lamp-on transition, then retrieve or mark the message read and observe the count, NOTIFY and lamp-off transition. Repeat after endpoint restart and registration renewal, and test another mailbox as a control. No PBX, mailbox, endpoint, subscription, notification, module, external store, lamp, message or live call was tested for this guide.

Prove mailbox state before debugging message-summary delivery

The AMI mailbox-query diagnostic keeps the voicemail store and raw query result separate from PJSIP subscription and phone-indicator evidence.

Prove the upstream AMI state owner first

If an external control is disputed, the AMI MWI control diagnostic checks release, module, scope, counts and EntityID before tracing NOTIFY.