AT&T home voicemail sends me a WAV email attachment that iPhone can’t play. Synergy (n): Still Meaningless Bullshit After All These Years. (Source: Me on May 29th, 2008)

The Problem

Part 1) We have AT&T for our home voicemail. When someone leaves a voicemail message there, I can get an email or text message. However, then I have to dial a 10 digit number, enter our home phone number, then a 6 digit PIN, then press 1, then press 1 again.

Which is annoying.

Part 2) AT&T can send me a copy of the voicemail as a .wav file — but (and you’ll love this part!) the .wav file can’t be played on an iPhone.

(Yes, this is the same AT&T with the exclusive contract with Apple to sell the iPhone in the USA.)

Part 3) There are lots of areas with poor/weak cell reception. The process described in Part 1 can take a couple of minutes just to get to the message.

Part 4) There’s no easy way to go back and search through old messages, unless you know the number. I can download the .wav on my desktop but it ends up with the name “message-x.wav” where X is a number. Not helpful..

The Solution

The easiest solution seemed to be to convert the file to MP3 and then send that file.

But, while I was at it, I might as well throw in a few extras such as doing a reverse lookup on the phone number to see who the call is from.

I used to scrape content from reverse lookup websites until I found Whitepages.com had released an API earlier this year.

I spent several days figuring out how to parse the information.

Then they changed it so you were getting a lot more information, which meant that I had to re-do everything that I had done.

Geeky Part #1: The Procmail Part

Procmail geeks will understand this next part

:0
* ^X-DCL-Caller-Number: \/[^ ]+
{
    # The phone number is sent as a Header to the email
    PHONE="$MATCH"

    # find a unique datestamp ready 
    TIMESTAMP=`date '+%s'`

    # set AND EXPORT (I forgot that part at first) a unique variable
    export METAMAIL_TMPDIR=$HOME/voicemail/temp/$TIMESTAMP
    
    # This will do nothing except dump the 
    # file into the METAMAIL_TMPDIR above
    :0 fb w
    | (mkdir -p "$METAMAIL_TMPDIR" && metamail -q -x 2>&1>/dev/null)

    # this external program does all of the heavy lifting
    :0 fb i
    | process-new-voicemail-wav.sh "$PHONE" "$METAMAIL_TMPDIR"

}

Geeky Part #2: The

This is the ‘process-new-voicemail-wav.sh’ script

#!/bin/sh

PHONE="$1"

METAMAIL_TMPDIR="$2"

# Get the Reverse Lookup Information for the phone number
reverse.sh $PHONE >/dev/null

# I am in Eastern Time, server is on California time, so we adjust +3 hours
TIME=`date --date '+3 hours' '+%Y-%m-%d-at-%H.%M'`

# Make sure that the folder we were given is valid
if [ ! -d "$METAMAIL_TMPDIR" ]
then

    echo "$NAME: FAILED could not find a directory $DIR at $TIME" |\
    Mail -s "$NAME Fatal error" $MAILTO
    exit 1
fi

# make sure we can get into the dir
cd "$METAMAIL_TMPDIR" || exit 2


for INPUT_FILE in `find $METAMAIL_TMPDIR/ -type f -print`
do

    # get JUST THE NAME of the person who called
    VM_NAME=`reverse.sh --just name $PHONE`
    
    # make sure we don't hit the API again too quickly
    sleep 1
    
    # get the just the ADDRESS of the person who called
    VM_ADDRESS=`reverse.sh --just address $PHONE`

    # Save the filename in a variable, since we use it 
    # several times
    OUTPUT_MP3="$PHONE.$MESSAGE_FOR.$TIME.mp3"
    
    # This is the core of the whole operation
    # ffmpeg will conver the WAV to MP3 and tag it
    # Unfortunately the tagging is limited to 30 characters per field, so we couldn't do a whole lot with it
    # so we use several fields. This means that I have to adjust my 'reverse.sh' script
    # so that it will give just the name and/or address if so requested
    # 
    # Note the "MESSAGE_FOR" part below was never fully implemented. My wife and I 
    # both have voicemail systems so I want to be able to tell those apart
    # most folks wouldn't need that part anyway.
    ffmpeg  \
        -i "$INPUT_FILE" \
        -author "$VM_NAME" \
        -timestamp "`date --date '+3 hours' '+%H:%M on %Y-%m-%d'`" \
        -album "Voicemail for $MESSAGE_FOR" \
        -comment "$VM_ADDRESS" \
        "$OUTPUT_MP3"
    
    if [ -f "$OUTPUT_MP3" ]
    then
    
        # mpack keeps chocking on "No such file or directory"
        # without an explicit TMPDIR
        #
        # YEAH THAT TOOK A LONG TIME TO FIGURE OUT
        # 
        TMPDIR=.
        
        export TMPDIR
    
        mpack -s "Voicemail Test $TIME" \
            "$OUTPUT_MP3" myemailaddresswhichisntthis@gmail.com

    fi
    
done    

exit 0
# EOF

Geek Part #3: The Reverse Lookup Script

This was where I spent the majority of my time. After I had gotten it worked out the first time, Whitepages changed things so that you got much more data back, and all my underlying assumptions no longer held. This is a good thing, I guess, but it made things much more complex.

Plus, then I realized that I needed to take mobile phones into consideration, which was a whole other rathole to deal with.

I won’t post the whole script, since it is currently 362 lines long, but suffice it to say, it is huge and complex.

Bumps In the Road

Actually there were a bunch of snags in the road.

1) Metamail wasn’t using the folder I told it to use. Without that, we didn’t know where to look for the voicemail file.

2) ffmpeg wasn’t the first program I tried.

First I tried ’sox’ and then ‘lame’.

Both said that they could not deal with this specific kind of WAV (Thank you AT&T for using an odd kind of .wav file!) which is described by ‘file’ as “RIFF (little-endian) data, WAVE audio, ITU G.711 mu-law, mono 8000 Hz”

Lame died with an error “Unsupported data format: 0×0007”

It was only then that I did even more research and found that ffmpeg could do it, and it was already installed! YAY!

3) ‘mpack’ is a program to email files from the commandline. I had to download, compile, install it. All of which worked fine.

It just refused to work once it was installed.

It kept telling me the file wasn’t there when it was.

I finally tracked that down to needing to be explicit when dealing with a Temp directory for mpack as well.

4) After many, many frustrating hours over many days trying to get this all to work, my wife came in and said “You do realize that the amount of time you are hoping to save will never match the amount of time you’ve spent on this, right?”

So, you know… ouch.

On the other hand, she was also looking for a voicemail message from a friend of ours we haven’t spoken to in years. She had deleted off her voicemail, and I knew I must have a copy of it somewhere, but was it called ‘message.wav’ or ‘message-5.wav’ or ‘message-10.wav’ or what? I know she’s in California but none of the files are marked in any way to tell what the phone number was.

We ended up having to look for her number a totally different way which wouldn’t work 99% of the time.

I Finally Solved All of the Problems (*)

(*) Except for one.

Remember how excited I was that ‘ffmpeg’ was already installed on the server?

Well it is.

Sorta.

It is installed on the webserver. It is installed on the machine I ssh into to make sure that everything was running (vs testing on my Mac and then having new problems on the actual machine).

However, mail is not delivered to the same machine as the webserver/ssh machine.

Mail is delivered to a different machine.

That machine does not have ffmpeg installed.

Sometimes the Answer is: “Go To Bed”

I finally quit around 2 a.m. last night and decided to go to bed. Of course, as soon as I got into bed I realized what I could do:

Solution: Have procmail run ‘wget’ or ‘lynx’ on a specific URL (web page) which would run PHP which would execute the shell script on the webserver not the mailserver.

Since I was tired, I went to sleep.

Today I tried working on the PHP page, using what is no doubt an entirely unsafe method of calling a shell script and feeding the $QUERY_STRING directly to it.

It seemed to work, so I tried to add some security to it…

…at which point I broke it so badly I couldn’t even figure out how to make the un-safe method work again (I haven’t done that much PHP work and haven’t written raw PHP in 5+ years).

So I gave up.

Sometimes the Answer is: Give Up

It might not make a great after-school special, but the truth of the matter is that sometimes you just need to give up.

At least for a little while.

You need to take a break, step back, and re-evaluate everything.

For example, I realized that I had gotten really far afield from my original goal: make an MP3 (I haven’t even mentioned some of the other grandiosity that I had in mind, such as a web-accessible, searchable archive).

Sometimes the Answer is: Doest Thou Shitteth Me?

So have you guessed what I missed?

I’ll give you a hint: something happened last Friday.

With Apple.

And the iPhone.

iPhone OS 2.0 was released.

Here’s a bug-fix for iPhone 2.0 that you won’t see listed in the reviews my Macworld, or Ars Technica, or Engadget, or anywhere else except here:

iPhone 2.0 brings compatibility with the kind of .wav file used by AT&T for their home voicemail.

Now I’ve already mentioned that this was an odd kind of .wav file, so I cannot believe this was an accident. Apple fixed their mobile media player to work with AT&T’s home voicemail.

Quote The Wife

Relaying this information to my wife she said “So this is one of those times when I should NOT say ‘I told you so’ right?”

Well, the fact of the matter is that I’d still like to get the reverse lookup information in there, but with the free People application for iPhone which uses the Whitepages.com data, it is easy enough to do a manual reverse lookup.

All things being equal, this is probably the best possible outcome. Ok, well, the best possible outcome would be that the reverse lookup information is included, but really, that’s not a huge issue.

This means that I don’t have to worry about any piece of the chain breaking down between a procmail receipe, a PHP page, and two shell scripts.

And it means that I have spent the evening relaxing with the family and writing this up… and now I can go to bed.

UPDATE: I am told that Vonage also uses “RIFF (little-endian) data, WAVE audio, ITU G.711 mu-law, mono 8000 Hz” files which also play on the updated iPod Touch.