Freeze one deposit and retrieval attempt
Record timestamp and timezone, caller, called identity, ingress route, ring or timeout path, extension, expected FreePBX voicemail destination, expected mailbox and context, greeting heard, digits pressed, recording duration, hangup method, expected owner, retrieval route and the installed FreePBX, Voicemail and Asterisk versions. Use a short authorized message with a unique spoken identifier and no confidential content.
Classify the first failed boundary: the call never reached voicemail, reached the wrong mailbox, played the wrong greeting, exited before recording, returned success but no message is visible, stored silence or clipped audio, appeared under another folder, rejected the correct owner login, exposed retrieval without the intended authentication, or deposited correctly but only email or the lamp failed. The last two notification paths already have separate diagnostics.
Prove the FreePBX route and voicemail destination type
Follow the same call through its inbound route, time condition, IVR, ring group, queue, Follow Me or extension no-answer or busy branch. Current FreePBX Core source publishes distinct voicemail destinations for Busy Message, Unavailable Message, No Message and Instructions Only. Preserve the exact selected destination and generated extension such as the vmb, vmu, vms or vmi form rather than reducing every result to 'went to voicemail.'
A caller hearing a prompt does not establish which extension or mailbox owns it. Confirm the saved FreePBX route, successful Apply Config, generated dialplan and loaded branch independently. Do not edit generated ext-local voicemail entries as the durable repair.
Bind the mailbox, context and greeting
Prove the effective mailbox@context passed to Asterisk. The voicemail context is not automatically the dialplan context, PJSIP endpoint name or display extension, and Asterisk uses default when a VoiceMailMain retrieval context is omitted. Confirm that the intended mailbox exists in the effective managed configuration before inspecting storage files.
Asterisk documents different busy and unavailable greeting options, and a multiple-mailbox deposit uses the first mailbox's greeting. It also supports early-media greeting playback and caller exits to surrounding dialplan branches. Record the selected greeting mode, any temporary greeting, instructions and exit digit separately from message acceptance. A familiar voice or extension number alone is not mailbox identity proof.
Prove recording completion and stored audio separately
Capture the VoiceMail application result for the authorized attempt. Asterisk exposes VMSTATUS as SUCCESS, USEREXIT or FAILED; preserve that value with the channel identifiers and time. SUCCESS is an application result, not proof that the expected mailbox contains intelligible audio, that a user can retrieve it, or that email or MWI completed.
Through an authorized mailbox or administrative view, confirm the message identifier, folder, timestamp, duration and playable content without copying production audio into an unrestricted ticket. Distinguish no stored message, a zero-length or truncated file, silent captured media, a valid message in another mailbox or folder, and a message deleted or moved under policy. Check capacity, retention and storage health only after the mailbox and application result are established.
Treat retrieval as its own authenticated call path
Asterisk VoiceMailMain can target a specific mailbox and context or prompt for one, and exposes folders such as INBOX and Old. Follow the owner's internal or approved remote retrieval route into the exact mailbox, then preserve authentication result, selected folder, message list, playback and exit destination. A message moved to Old is not the same as a missing deposit.
Do not enable PIN-skipping as a troubleshooting shortcut. VoiceMailMain's s option skips the passcode check for that execution and therefore changes the authorization boundary. A phone's voicemail key, caller ID, endpoint registration or access to a feature code does not independently authenticate the mailbox owner. Keep PINs and voicemail audio out of shared logs.
Correct one owner and replay the full lifecycle
Correct only the demonstrated owner: source route, busy or unavailable branch, FreePBX voicemail destination type, extension mailbox setting, voicemail context, greeting state, caller-exit destination, storage or retention condition, retrieval route or credential reset. Submit and Apply Config through supported FreePBX controls, then verify generated and loaded state before replaying the call.
Retest a busy deposit, an unavailable or no-answer deposit, the intended greeting and instructions, a caller exit if enabled, authenticated retrieval from the normal owner path, a failed-login control and one unaffected mailbox. Confirm the stored audio and final destination. Then validate voicemail email and MWI independently if they were part of the incident. This workflow is documentation-derived and has not been reproduced on a customer or laboratory PBX.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Sangoma FreePBX voicemail overview ↗
- Sangoma FreePBX Voicemail Admin ↗
- Sangoma FreePBX voicemail extension settings ↗
- FreePBX Voicemail release/17.0 metadata ↗
- FreePBX Core release/17.0 voicemail destinations ↗
- Asterisk 23 VoiceMail application ↗
- Asterisk 23 VoiceMailMain application ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.