I haven’t posted here in a while, so I just thought I’d mention something about freePBX 2.2.0, which was just released a couple days ago. For those that don’t know, freePBX is an open source configuration and web-based interface to Asterisk, which allows you to configure and run a PBX that has the equivalent functionality to commercial PBXs costing several thousands of dollars (or more). I’ve been involved with the freePBX project since December 2004 (when it was called AMPortal, or AMP for short), and minus a 6 month hiatus in early 2006, I have been contributing to the project ever since.

2.2.0 is a fairly signifigant release, adding a fair chunk of new functionality, fixing lots of bugs (over 200) including some long-standing bugs that have been around since the 1.x series. Among these are some bugs in the call handling that dealt with certain situations where you pass a call from a queue to a ring group, or going to a cell phone, and then forwarded back to another extension, etc, that were sometimes causing voicemail to never pick up, and some other strange behaviour. I was busy rewriting the modules API to make everything a bit more solid, and wrote a fancy new module administration interface. I also ported a nice new design done by Steven Fischer, which was a much needed upgrade from the basic look that the interface had from the start. I’ve also written some new modules (announcements, phonebook directory, misc applications, speeddial) and done some work on a half dozen others. Overall, we’re quite happy with this release and definately suggest that anyone using 2.x upgrades.

Going forward, there’s a few things I’d really like to do – write some hooks to use QuickForm, to make writing GUI code a lot simpler; finish my text-to-speech and manualconditions modules (which I’ve started on already); finish the daemon to write config files (instead of having the web server invoke a script); write the framework for a user portal; and add a menu before going to voicemail to allow callers to do various things besides leave voicemail.

Now, if I just had a clone or two that could my other day-to-day tasks like go to work, I would be set.

I came across an interesting article showing that running VoIP over a (TCP-based) VPN actually improves call quality. This goes against what you would expect – VoIP traffic uses UDP to ensure the least amount of latency, while TCP ensures all packets arrive in order, but means that one holdup can stall the whole stream.

Once they investigated more, it actually makes sense why this happens. The VPN ensures that all packets get there, in order, which yields a better call. What is needed for this is enough burst bandwidth so if a packet is delayed, there is enough headroom to ‘catch up’ to the stream (detect the error, and retransmit enough data to fill the gap). A 64kbps VoIP call takes up about 80kbps when encapsulated in a VPN. Having a 100kbps connection isn’t quite enough, but in the tests 500kbps was enough to improve quality (see the chart). The flipside to this is that on a bad network, nothing helps, which really just seems obvious.

The interesting implication of this is that it’s actually another reason to deploy VPNs to remote workers. Not only is the call now encrypted (something many VoIP protocols don’t do) with proven SSL technology, but it actually helps the quality, provided they have a half-decent connection to begin with.

The other point here is that it’s actually okay to overprovision as long as you have enough burst bandwidth. For example, if you have a 2Mbps pipe, and are serving 12 users from it, they consume just under 1Mbps total. That leaves another 1Mbps for burst capability if any of the streams get left behind, and 12 times more than any single connection requires. (This is of course assuming no other traffic is flowing on the VPN, so adjust numbers accordingly if the VPN is used for browsing, file transfers, etc).

I’d like to see a test done using OpenVPN (they only used commercial VPN products), but it’s clear that it’s a good idea to add SSL. It’ll be interesting to see where this heads: if SIP phone manufacturers will start adding VPN clients or even just SSL transports to encapsulate the SIP traffic. Perhaps even a new TCP-based protocol will be thought up.
digg story