VoIP.info Troubleshooting

FreePBX voicemail lamp and MWI not updating

Prove the mailbox count, endpoint mapping, subscription mode, SIP message-summary exchange and phone indication in order.

Reviewed 2026-10-17FreePBX 17 on Debian 12 with Asterisk 22 LTS documentation reviewed September 27, 2026. No mailbox, PBX, endpoint, SIP subscription, NOTIFY exchange, phone lamp or live call was tested.IntermediateDocumentation based · not lab tested

Prove the mailbox state before tracing the lamp

Leave one controlled message in the intended mailbox, then confirm that it exists and can be retrieved. Record the full mailbox identity, including its voicemail context. A wrong greeting, missing recording or failed retrieval is a voicemail deposit or routing problem; a correct new-message count with a dark lamp is the narrower MWI path.

RFC 3842 defines the SIP message-summary event package and its Messages-Waiting, Message-Account and new/old count fields. Those fields report message state; they do not prove that the phone displayed a lamp, programmed its voicemail key or can retrieve the mailbox.

Check the generated mailbox-to-endpoint mapping

In FreePBX, inspect the affected PJSIP extension and record its mailbox value, voicemail extension and MWI subscription type before changing anything. Sangoma documents that the mailbox control can associate one or more mailboxes with a device and that the voicemail extension may program a phone’s retrieval button. These are separate controls.

Compare the full mailbox@context identity with the mailbox that received the test message. Asterisk app_voicemail mailboxes require that complete form for PJSIP MWI. Confirm the loaded endpoint with pjsip show endpoint <endpoint> after Apply Config; a saved GUI value is not proof that the running object contains it.

Identify solicited or unsolicited delivery

FreePBX documents solicited MWI as a SUBSCRIBE followed by the server response and NOTIFY, while unsolicited mode sends NOTIFY without the phone first subscribing. Capture one bounded state change and identify which model is actually in use. Do not change both the phone and PBX at once to make the trace look cleaner.

For unsolicited delivery, Asterisk documents the PJSIP endpoint mailboxes option as the source of NOTIFY messages when mailbox state changes. For solicited delivery, confirm the phone sends a SUBSCRIBE with the message-summary event and that Asterisk accepts it. Asterisk explicitly warns that configuring unsolicited MWI while the same endpoint or AoR also subscribes can produce a denied-subscription condition; choose one intended model rather than stacking both.

Follow one complete SIP state change

Enable PJSIP logging only for a short controlled deposit or deletion window. For solicited MWI, preserve the SUBSCRIBE, response and resulting NOTIFY. For either model, inspect the NOTIFY destination, Event header, subscription state where present, Messages-Waiting value, new/old counts, response from the phone and timestamps.

A 200 response to NOTIFY proves receipt of that SIP request, not the device’s visual behavior. No NOTIFY points back toward mailbox publication, mapping, module or subscription state. A correct NOTIFY with no lamp points toward the endpoint account, device policy, firmware or presentation layer. A lamp that will not clear can reflect a remaining new count, a different mapped mailbox or an unobserved clearing NOTIFY.

Keep external storage and visual voicemail separate

If messages can change outside the normal Asterisk voicemail applications, such as through IMAP-backed storage or another mailbox interface, check the documented polling behavior and interval rather than treating SIP as the first failure. The PBX must first learn the new mailbox state before it can notify an endpoint.

A simple MWI lamp is not a visual-voicemail message list. Do not infer visual-voicemail application support, transcript delivery, per-message controls or phone compatibility from a working RFC 3842 summary. Test the exact endpoint feature separately under its vendor and PBX integration documentation.

Retest deposit, clear and a control mailbox

After correcting the demonstrated layer, deposit one message, confirm the new count and lamp, retrieve or delete it through the intended workflow, then confirm the count and lamp clear. Repeat with one unaffected extension or mailbox so a global restart does not masquerade as a durable mapping repair.

Turn off temporary PJSIP logging and protect message metadata, account identities and packet captures. Do not clear production messages merely to force a lamp change. No mailbox, PBX, endpoint, subscription, NOTIFY exchange, phone lamp, visual-voicemail feature or live call was tested for this guide.

Asterisk CLI — bounded MWI observation
pjsip show endpoint <endpoint>
pjsip set logger on
# Deposit or clear one authorized test message.
pjsip set logger off

Separate backend refresh from message-summary delivery

The AMI MWI control diagnostic bounds external mailbox refresh and state ownership before the FreePBX delivery path.

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.