User Portal Voicemail Will Not Play


In the user portal, when I click on the playback button, I can see a quicktime icon appear below, but the message does not play! If I click the download button, the file downloads, but I cannot play it in Windows Media Player.

However, the file attached to the notification email plays fine.

Any ideas?

I just tested this on my test system which is the latest of all FreePBX 2.9 modules and I am not seeing the issue. Can someone else using the distro test this and let me know if they are seeing the same problem that is reported here.

Also have you verified all the FreePBX Modules are updated.

For each voicemail message I got the following files:

If I transfer these files to my Windows computer, they will both play.

If I go to the User Portal and download the msg0000.wav, it will not play.

I have noticed that the downloaded file from the User Portal have a “newline” in top of the file. This is why it won’t play. If the “newline” is removed it is exact the same file as “/var/spool/asterisk/voicemail/default//INBOX/msg0000.WAV”

Please also see this thread:

Best regards
Henrik Larsson

When I downloaded both files using WinSCP, I used Windows Media Player and both the WAV and wav files played fine.

In the user portal, when I try to play the file, I see a quicktime logo in the plugin area, and the file will not play. When I click the download button, and download the file to my desktop, the file will not play in Windows Media Player. I tried opening the file using a sound file editor called Goldwave, and the file opens, but all I hear is garbage.

I understand what you are saying, but there is clearly a bug in the user portal module.

Currently, I have a test voicemail message sitting in my Inbox; the only message in the Inbox. The email attachment I received plays fine. If I try to listen to the message via the play button or download button in the user portal, it will not play. I downloaded the file and tried to play it on numerous players and it will not play, I think the file is corrupted.

Now, I logged into my PBX with WinSCP and went to /var/spool/asterisk/voicemail/default/100/INBOX. There are two sound files there, msg0000.wav & msg0000.WAV. When I download both files to my desktop, BOTH files play just fine!!

So what is happening in the user portal??? There is another thread about this issue as well:

when you play it though scp, what media player are you using? And when you try it from the user portal, what media player is the browser trying to use as its plugin?

a ‘WAV’ file is not really a codec, it’s a “container” which therefore may or may not be able to play.

Asterisk can produce two ‘versions’ of wav files and one of them tends to be more of an issue with players as others.

It sounds like you may have both enabled and for some reason Asterisk chooses to email one while we choose to play the other. It may be worth examining our priority order when multiple wav versions exists in case there is a better selection, but you should narrow this down by looking into what formats you are recording and see if a change there can address the issue and then let us know the details in a ticket so we can re-evalute this and see if there is a better selection process.

check the actual format of the file, that’s usually the cause if it’s something that media player can’t play.

The file is a WAV file which Windows Media Player should have no trouble playing.

Here is what’s interesting. The WAV file attached to the email notification is 4KB and plays fine. However, in the voicemail portal, when I download the file from the same voicemail, the file is 40KB and will not play!

Any idea what’s going on here?

There’a probably a carriage return/line feed somewhere in one of the #include files after the php closing tag “?>”. That carriage return/line feed gets “cleaned” by the ob_clean(); before the audio file is sent. The real solution is probably to clean the #include files.

You are missing this line


Look above at the correct example of what it should be

Oh wow, sorry, I read it backwards and thought the ob_clean(); needed to be removed.

Working OK now, thanks!

This issue has been resolved in the latest module update ( for the ARI Framework. The new module is available for download now. Many thanks to the developers for the lightning fast resolution.

Hi - love the distro!
I followed the instructions above, and found my audio.php file was already updated (just installed yesterday), yet I have the same issue where both voicemail & recordings do not play in the user portal or when downloaded to my PC.
Just like someone else posted, if I use WinSCP to view the files manually in the /var/spool/asterisk/monitor (or voicemail) folders, I can download/play them OK on my PC.

Here is the bottom of the audio.php file:

header("Content-Transfer-Encoding: binary");
header("Content-length: " . $size);



Mikael - I can confirm that adding your code has resolved the issue! Will your fix be included in a module update for everyone else? Thanks!

Yes it will be included.

I (seems to) have fixed the issue. I have closed the ticket but need some confirmation for the fix.

Testers, please edit /var/www/html/recordings/misc/audio.php and change from from this (line 49):

    header("Content-Transfer-Encoding: binary"); 
    header("Content-length: " . $size); 

to this:

    header("Content-Transfer-Encoding: binary"); 
    header("Content-length: " . $size); 

Save the file, then try to play or download the voicemail.

Ticket 5102 opened.

Ok I have been able to reproduce it. I was running a non true version of 2.9. It had a bunch of non standard things. I will work with the guys today and see if we can get this fixed.

Has someone opened a bug report on it yet? If not could someone.

Henrik - Excellent discovery! I can confirm too that downloading the WAV file from the User Portal, and opening the file in Notepad++, that there is a “newline” in the top of the file. After removing the “newline”, the file plays fine!

Now, if only we can get the developers to reproduce this issue and confirm its a bug :slight_smile: