Top VoIP Stories of 2008? You Tell Me.

It’s the time of year when lists are made.

The end of the calendar year invokes some primal drive in all of us to list the best and the worst from the previous 12 months. As it is with all other things, so it is with the world of telephony and VoIP. Here is a list of the top 25 VoIP innovations for 2008 from VoIP News. Here is another list. And another.

I’ve got nowhere near enough energy to list my own personal top 25 VoIP stories or innovations for 2008. Hell, I don’t even have enough energy right now for 5.

Personally, I think the development of an official effort by Digium and Skype to link up the Skype VoIP client and Asterisk is pretty exciting.

What do you think is the most innovative thing to happen in the world of VoIP in 2008?


Most Interesting Public Sector IT Story of 2008

Hands down this goes to the curious case of Terry Childs; the City of San Francisco Network Administrator who allegedly “went rouge” and locked city officials out of the citywide network.

Childs, who seems to have become something of a cult hero among IT professionals, was arrested earlier this year for his actions and now faces trial for them.

I suspect that we’ll soon see “Free Terry Childs” shirts popping up.

First Draft of VoiceXML 3.0 Released

The W3C has released the First Public Working Draft of Voice Extensible Markup Language (VoiceXML) 3.0. This is the next version of the VoiceXML language that reportedly will include a host of new features, including speaker authentication.

Although this is an early draft, according to the document:

By the middle of 2009 the group expects to have all existing functionality defined in detail, the new functionality stubbed out, and the VoiceXML 2.1 profile largely defined. By late-2009 the group expects to have all functionality defined and both profiles defined in detail.

I’ve got to find some time to go through this document — in addition to being a very interesting read, it might be kind of neat to provide input that might get incorporated into the standard by the W3C.

Guess I know what I’ll be doing for New Year’s Eve. 😉

How NOT to Manage an API

Recently, I decided to build a small application that interacts with the Twitter API, the API and Google Calendar to allow me to get advanced notice of any and all Boston Celtics games. The app is actually live and can be followed on Twitter.
Boston Celtics
It’s a pretty neat little application that runs on a daily cron job and queries a small database to see if there is a Celtics game on the following day. If there is a game the next day, it generates a link to add the game to Google Calendar, shortens the link using the API and sends out a Tweet with the game details and Calendar link. Pretty sweet, right?

Unfortunately, almost immediately after going live the Twitter API started to return some nasty HTTP responses and I was unable to update the status of the celticsgames account. Specifically, the Twitter API started to return the HTTP 417 response code. After doing a little Googling, I found that I was not the only person using the Twitter API to suddenly (and without any warning) run into a problem that broke their application.

The issue stems from the inclusion of the HTTP Expect header in the request that is sent to the Twitter API. I’m using PHP and cURL to interact with the Twitter API. Apparently, this header is sent by default with a value of ‘100-continue’ by cURL (unless you override it and set a different value). Seems the Twitter API grew very confused by this setting in the past few days. The HTTP spec states that:

A server that does not understand or is unable to comply with any of the expectation values in the Expect field of a request MUST respond with appropriate error status. The server MUST respond with a 417 (Expectation Failed) status if any of the expectations cannot be met or, if there are other problems with the request, some other 4xx status.

I did some checking and I can’t find any mention on the Twitter API Wiki about a recent change that would have affected how the Twitter API responded to HTTP requests with the Expect header set in any particular way (it is possible, though, that I could have missed it). I also referred to the specific list of HTTP status codes returned by the API — no mention of a 417 response at all.

In my opinion, this is a pretty crappy way to manage an API. If your goal is to encourage third-party developers to build applications that work with your API, don’t make breaking changes without going to great lengths to ensure the developer community understands how the change will impact them. And for goodness sake, update your documentation.

Fortunately, there is a Celtics game on later today (during which they will absolutely pound the LA Lakers) — that should take this bad taste out of my mouth.

Screen Pops with Asterisk and XMPP

A few weeks ago, I wrote a post on using CCXML and PHP to do screen pops with the Voxeo Prophecy platform. The task was made incredibly easy with a nifty PHP class library designed specifically to interact with XMPP servers.

After getting screen pops working in Prophecy, I decided to try my hand at getting them to work in Asterisk (this is, after all, how the majority of phone calls to me are handled). It turns out, the PHP script I developed to do screen pops in Prophecy can be reused to do the very same thing in Asterisk. If you’d like to give this a try on your own, here is what you will need:

  1. A working Asterisk instance. (This example assumes you know how to modify Asterisk config files.)
  2. A copy of the very cool XMPPHP library from Google Code. (This example assumes that the PHP code used to interact with XMPP servers is running on a separate server than the one housing Asterisk. More on this below.)
  3. An XMPP server and a client, or simply use your Google account.

There are three components to this example. First, you’ll need a PHP script to interact with an XMPP server. You can use the same script employed in my previous screen pop example:

$conn->message('', 'You are receiving a call from: $ani');

Next, you’ll need a simple AGI script for Asterisk to interact with. This script will send an HTTP request to the PHP script above:

# Contents of screen_pop.agi
# It don't get any easier than this...
curl http://ip_address_to_your_web_server/screen_pop.php?ani="$1"

On your Asterisk server, place this script in /var/lib/asterisk/agi-bin/ and ensure that it is executable. You’ll need to specify the IP address to the server running this script. Note — there isn’t any reason that these two scripts can’t run on the same machine (you can run PHP scripts on an Asterisk server), or even be consolidated into one single script (just make sure to include the XMPPHP library). In fact, you could even run the XMPP server used to send screen pops on the same machine running Asterisk.

The mechanics of this specific example were influenced by the set up for my previous screen pop example, and I am (at heart) a lazy basterd. But I digress…

The last piece to be put in place is to modify extensions.conf to ensure that our AGI script is invoked. You’ll want to add something like the following to the appropriate dial plan context (your specific Asterisk set up will influence this heavily):

exten => 123,1,AGI(screen_pop.agi|${CALLERID(num)})

This will pass the caller ID to our AGI script, which will then invoke the PHP script and send the details of the call to the XMPP account of our choice. I’ve noticed in practice that adding this to my dial plan causes the IM to be sent to my Google Talk account a good 2-3 seconds before the phone rings. Plenty of time to give someone a heads up about who is on the other end of an incoming call.

Obviously there are lots of options for looking up information on the caller, once you have their caller ID, that you can use to augment the information in your screen pop.

Just goes to show you, there isn’t much you can’t do with open source / open standards.

Viva screen pop!

Facebook Integration Enabled

I’ve been experimenting with Facebook Connect for a week or so now, and I’ve finally got it enabled for comments on this site. I’m using a slightly modified version of the WP-FBConnect plugin that can be found here. I’ll probably continue to tinker with the code as I use it more, and get a better feeling for what I like and don’t like.
Enabling this plugin displays a new log in option for leaving comments — users now have the option of logging into this site via Facebook Connect. This will create a new account on the site that they can use to leave comments, manage their profile, etc. Additionally, when a user leaves a comment, they have the option of having it published on their Facebook profile. Pretty neat!

Now I’ll just have to write some interesting posts so that people feel compelled to leave comments. 😉

Note – I have noticed a little bit of strangeness when logging in via Facebook Connect using Firefox (the behavior has appeared when running Firefox 3.0.5 on both Linux and Windows). After logging in, the page seems to revert to a pre-logged in state (the Facebook Connect button is displayed after a user has logged in). A page refresh, or navigating to a new page seems to clear this issue, but it could be confusing for those using Firefox. I’ll have to dig into this some more to figure out what is causing it and get it resolved.

If you encounter any issues logging into this site with Facebook connect, leave the details for me in the comments section.