Why do voicemail messages not playback properly on the iPhone or iPad via the ARI? The weird thing is that if I copy the voicemail message from /var/spool/asterisk/voicemail/default/102/INBOX to /var/www/html/ and then type the direct url to the wav file it plays back fine. How do I fix this?
I don’t think it could be a permissions issue because messages in that mailbox playback fine on my computer. They just don’t work on the iPhone or iPad. I get an error that says: “Cannot Play Movie. The server is not correctly configured.”
That sounds like a permissions problem. Check the permissions on that mailbox.
it has to do with cookies and PHP session use. The embedded quicktime player doesn’t respect the PHP cookies while streaming, apparently.
A workaround would be to detect iDevice, and make the player URL include the session.
ini_set("session.use_only_cookies",0);
might do it but I didn’t try it.
I am not sure that it is permissions. I did a quick (and very very ugly hack) to the php code to convert the files to mp3 on the fly and the iphone will play it. If it was permissions, then I don’t think it would work for mp3.
I know the iphone didn’t initially like wav files at all. At some point, they added support in mail attachments. Perhaps the headers aren’t being sent in a way that the iphone recognizes it?
Here is my very ugly solution added to audio.php (also required installing lame for conversion).
// split the path into parts for easy dealing
$mp3_path = $path_parts['dirname']."/".$path_parts['filename'].".mp3";
// if the mp3 file doesn't exist, try to create it
if (!is_file($mp3_path)) {
$output = exec("/usr/bin/lame -h -b 192 $path $mp3_path");
}
// if the mp3 file was created, then use it instead
if (is_file($mp3_path)) {
$path = $mp3_path;
}should do better error handling instead of the two “is_file” checks, but it was a 2 minute test.
Also, nice to note that everything cleans up properly when a message is deleted due to wildcards already in the delete code.
ARI was written well before the iPhone. I wouldn’t advise using either on it.
Doing on the Fly conversion is pretty heavy on the system. Imagine if someone had 100 voicemails. Ouch. Nice job though.
Agree it is heavy. But I have a small system and they wouldn’t look at them 100 messages at once. Your have a good point on a large install.
Are there alternatives for the iphone?
Looking at the headers now to see there is something simple that is confusing the iphone browser on it. Since it does have the ability to play the file it isn’t a codec problem. It really should be able to work.
It’s most likely just bad code. We just need to update ARI. It’s on the roadmap.
more info… works only when clicking on download
-
Login into your box
-
Goto your home directory
cd /home/ -
Download the lastest version of lame from here http://pkgs.repoforge.org/lame/
wget http://pkgs.repoforge.org/lame/lame-3.97-1.el5.rf.x86_64.rpm -
install rpm
rpm -Uvh lame-3.97-1.el5.rf.x86_64.rpm -
nano /var/www/html/recordings/misc/audio.php
add after … $path = $_SESSION[‘ari_user’][‘recfiles’][$_GET[‘recindex’]];
$path_parts = pathinfo($path);
// split the path into parts for easy dealing
$mp3_path = $path_parts[‘dirname’]."/".$path_parts[‘filename’].".mp3";
// if the mp3 file doesn’t exist, try to create it
if (!is_file($mp3_path)) {
exec(“lame -h -b 128 '”.$path."’ ‘".$mp3_path."’");
}
// if the mp3 file was created, then use it instead
if (is_file($mp3_path)) {
$path = $mp3_path;
}
The way the iPhone requests the file is very strange. Here are the requests it made when I requested a 142764 byte audio file stored on my server:
1: Request the file but stop accepting data after about 20 kB
2: Request again with header Range: bytes=0-1
3: Range: bytes=0-142763 (stop accepting data after about 20 kB)
4: Range: bytes=139264-142763 (ie the last 3500 bytes of the file)
5: Range: bytes=0-1
6: Range: bytes=0-142763 (again stopping after about 20 kB)
7: Range: bytes=139264-142763
8: Range: bytes=10356-139263 (finally downloads the whole thing minus the first 10 kB)
When I look at a capture through ARI it stops after the second request, probably because the request isn’t being replied to properly.
So what’s needed is for the code that serves audio to support partial content, or for the iPhone to behave normally. Maybe a workaround might be to temporarily create a symbolic link to the audio file for Apache to serve up natively?
This works for me on 2.10: http://pastebin.com/7adR6HBg
Really the whole thing needs to be rewritten from the ground up. I think this is one of the oldest parts of FreePBX and it definitely shows!
I opened issue 6557 for this iPhone issue and included my patch for 2.10. We’re just starting to look at using ARI for our clients (if we can secure it sufficiently through a proxy) so will need this functionality ourselves.