Open-source IP telephony and the systems administration dilemma

To effectively set up, operate, and customize an open-source phone system like Asterisk or FreeSWITCH, you need to be competent at Linux systems administration.
When Asterisk and FreeSWITCH first came about, this was clear, because to go though the process of building the software and running it on your server, you had to decipher and successfully follow compiling instructions and use systems administration skills to get it to work.
Enter the Asterisk+FreePBX “distro.” There are several of them out there now, and their promise is big: insert this CD or flash drive, boot your server, and out comes a working phone system with a configuration GUI. The installers even do a decent job of making the system secure, so that you’re not the victim of the first script kiddie to happen upon your server’s IP address.
Linux is pretty good at figuring out hardware configurations and installing drivers and setting up automatically. So, chances are, when the installer is done, you really do have a working system.
At this point, the person maintaining the phone system has to hope that all problems can be effectively diagnosed and solved through the GUI, that nothing interesting happens with the underlying hardware or operating system that would require troubleshooting, that all logging is available through the GUI, and that the security of the GUI’s web server (typically Apache, firewalled by iptables) is correct. 
What if you are running Asterisk+FreePBX and have a SIP communications issue with a provider? You can’t turn on SIP debugging in FreePBX. You can use the Asterisk Logs module to get some log information but you’d do much better with command line tools such as grep. The truth is, inability to navigate Linux and the Asterisk command line is crippling.
Taking advantage of the open-source system’s openness to customize and add new features, such as Google Voice integration, means getting into the nuts and bolts. Or wait for someone else to write a (probably buggy) GUI module for you.
The fact is, if you want to be hands-off with systems administration, you need to get an appliance-like system such as SwitchVox or the big name brand small business PBXes. You have to pay for these. With your money you will get professional support to operate the low-level controls when an error appears, and you’ll get full GUI access (probably) to everything you should have access to. If it’s not in the GUI, you don’t have access to it.
If you want free, you need to learn systems administration so that you can be your own support person. The forums of FreePBX and various distros are full of questions like, “My phone doesn’t work, what do I do?” Ask them what appears in the logs and they have no idea what you are talking about. It just doesn’t work like that.
This is the dilemma. Free and customizable, with the cost of learning systems administration (and maybe some scripting/programming) skills, or hands-off with the cost of paying the vendor for the software and support?
To be a little more specific about what I am calling systems administration skills, here are the things I believe a person needs to know in order to competently install and maintain an open-source phone system, with or without a GUI, and whether from a CD-installed distro or from RPM packages or from source (not an exhaustive list):
  • ability to navigate the Linux filesystem comfortably and know where certain kinds of files typically are (logs are in /var/log, config files are in /etc, executables in /usr/bin and so on)
  • ability to use a text editor
  • handiness with find, grep
  • ability to correctly configure a firewall or packet filter such as iptables
  • ability to read syslogs and follow clues to solve a problem
  • familiarity with the operating system’s package system (such as yum/RPM with CentOS) so that he/she can easily load necessary tools
  • some familiarity with development tools such as make, gcc, configure scripts, cvs and svn, and the ability to decipher output they produce
  • ability to configure user accounts and passwords
  • some familiarity with network diagnostic tools like netstat and tcpdump
  • for FreePBX, familiarity with command-line MySQL for database troubleshooting
  • for Asterisk’s mail needs (voicemail or fax to e-mail), ability to configure some mail sender

Is it a tall order? Yes, there is a learning curve. It’s not Windows 7. But, like learning a foreign language, when you go into the foreign land (Linux console) and can speak the language, you are empowered.

Asterisk on Amazon EC2 cloud; Google Voice update

Some quick updates on interesting topics featured on this blog.

A blog reader recently introduced me to Amazon’s Free Tier offering of their cloud infrastructure service. The gist: get a free year of a virtual server, within the limits of 10GB storage, 613MB RAM, and low CPU usage with some “bursting” as needed. That’s good enough for a test box, certainly.
I have been running Asterisk and FreePBX on the Rackspace Cloud since October 2010. It works great there, and if it weren’t for Amazon offering something for free, I would say that RS Cloud is still the better deal. (You can see the numbers for yourself if you calculate the price of Rackspace’s lowest-configuration cloud server and compare with Amazon’s. At only 256MB, the Rackspace server is a bit slim on memory, but more than adequate for development and testing and even running a few calls at a time in production.) But I’m into saving pennies and decided to move my test system to Amazon’s cloud, at least for the twelve months they’ll let me use it for free.
In short, it works according to my previous instructions for installing Asterisk and FreePBX on the Rackspace Cloud Server. Hackers who have set it up on RS Cloud can do the same on EC2 by selecting an instance within the Free Tier; use the Amazon Linux 64-bit image with 8GB disk. Use Elastic IP to give yourself a consistent (but not “static,” really) IP address. And note that your server is actually behind Amazon’s NAT, so you’ll need to configure SIP NAT settings as if you were behind a home router. Tip: use 10.0.0.0/8 for the localnet. Lastly, the firewall is configured on Amazon’s EC2 console, not in iptables. Enjoy!
Google Voice update
An unofficial, unsupported, much discussed Google Voice module for FreePBX made the rounds recently. In fact, the original author commented here on this blog advertising his module, but apparently no longer maintains it. I recommend sticking to the manual-configuration method documented here (hit the link just referenced and scroll all the way up). Unfortunately, Google Voice integration with Asterisk is still pretty flaky. Outbound calls will work perfectly, but inbound calls are hit-and-miss. I have seen this in my testing and so have others. (Note: don’t cross Michigan Telephone! Hi, MT!) Get a DID to forward to, use FreeSWITCH or an OBi ATA box for better success.

A crash course in Perl

Found in a posting on the unofficial Penn State intranet (Yammer):

for those who already know the basic building blocks of programming or scripting (statements, blocks, conditionals, variables, operations, and so on).
Perl is always in my toolbox. Real programming languages are for Real Programmers. Perl is for systems administrators and hackers. You can do anything with it; it will probably just take longer to run (but if you don’t care about that, it will probably be quicker to write).

VoIP news roundup

Some interesting VoIP-related news I read this week:

TAC to FCC: Set a Date Certain for the End of the PSTN – and the proposed year is 2018. The big concern seems to be maintenance of infrastructure when traditional landline subscribers are dropping off rapidly. I think that infrastructure still has a lot of value to it, but not necessarily for traditional telephone service. What could the utilities or private enterprise do with a copper grid and switching infrastructure that reaches even the most rural parts of the United States?

From the VoIP and Gadgets blog: How Skype Works With Facebook – an interesting interview about how Skype put their technology in the web browser for Facebook video chat. It’s basically the Skype client condensed down to a browser plugin.

Meanwhile, Google is doing it their own way with XMPP: Announcing Google+ Hangouts – Google keeps working at the XMPP extensions to make the protocol media-rich, and now they have group video chat. I don’t have a Google+ account and haven’t tried it out yet.

Google’s offering is standards-based: “To support Hangouts, we built an all-new standards-based cloud video conferencing platform.” And those standards are “XMPP, Jingle, RTP, ICE, STUN, SRTP” and “HTTPS + SRTP”. Some folks would say that it’s not “standards-based” unless SIP is doing the signaling. I think the only thing standard means today is that your work is published for others to use and some technical group of people reviews it. XMPP has that. SIP’s technical body is the IETF and H.323’s technical body is the ITU. Who’s more standard?

The standard with the most implementations wins (Betamax, anyone?) and Google has the weight to tip the end-user-connectivity scales toward XMPP/Jingle. SIP is firmly in place as the current IP trunking standard but might soon be falling behind when it comes to connecting the end-users.

Cisco’s Mobile Connect is useful; worth the two license units

Recently I decided to explore Cisco Unified Communication Manager’s Mobile Connect feature. This used to be called Single Number Reach and is exactly what you would expect: one number rings multiple phones–your VoIP set and an off-system number. It is straightforward to set up; follow this helpful guide on the Cisco Learning Network.

The nice thing about Mobile Connect is that it isn’t simply a multi-ring scheme; rather, it’s effectively a shared line appearance with your cell phone or other remote number. Communications Manager maintains supervision of the line, even if you take the call on your remote line (mobile phone), which allows you to easily switch between the remote and the desk phone. I believe, though I have not tested it, that this configuration would also allow the Mobile Connect line to participate in a hunt group.

In CUCM 7.x, you can configure an on-hook screen Mobility softkey to enable or disable Mobile Connect. This way, it does not have to be an always-on feature.

Enabling a Mobile Connect number consumes two additional device license units (DLUs) if you are licensing devices a la carte. The functionality is very nice and probably worth the licensing cost for those who want to use it.

A free, open-source SIP-H.323 gateway with video?

Has anyone implemented a video-capable SIP-H.323 gateway using free, open-source software?

If so, please comment.

Asterisk, FreeSWITCH and YATE all have some ability to connect SIP and H.323 endpoints to one another. Asterisk acts as a back-to-back user agent (B2BUA) and the other two act as proxies. All can switch audio calls. Video seems to be another story.

In theory, it should be straightforward. The difficult part is translating the signaling; the media streams are the same. Thus the interworking component (PBX, switch, or proxy) should be able to translate signaling and then proxy the media between the endpoints. If video is just another media stream, why doesn’t it work just the same as an audio-only call?

I’ve tested YATE (built-in modules), Asterisk’s chan_ooh323, a custom chan_ooh323 for Asterisk 1.4 that specifically enables video (but crashes/disconnects, and is definitely not supported unless you buy the unnamed company’s video IVR product, which I haven’t), FreeSWITCH’s mod_h323 and mod_opal. I never really got the FreeSWITCH mods working stably. YATE and Asterisk worked fine in audio mode. Neither would translate video (H.263 protocol, nothing fancy).

Additional reading: RFC 4123, Session Initiation Protocol (SIP)-H.323 Interworking Requirements

I want to ride my bicycle, I want to ride my bike… to work

Get Rich Slowly features a reader story today on The Costs and Savings of Bicycle Commuting. It’s a good, short read. And don’t miss the discussion in the comments section.

Three years ago I wrote a blog post here titled Greener IT through bicycling and VoIP. I believe little has changed since then, except that a greater number of people are thinking “green.” Indeed, the bicycle paths from my house to work are seeing more traffic during the morning commute, and the bikes or riders are laden with bags that seem to indicate they’re riding to work and not just for fun.

We’ve done more video conferencing over the last few years. Our meetings use online agendas and notes rather than printed handouts, allowing participants to join by video and participate just as effectively as if they were in the room. 
Two weeks ago, I attended a [popular IT training company’s] course using their online delivery method. The delivery platform is Adobe Connect, and the instructional designers have done a good job of making online students feel that they are part of the classroom. Some interaction is limited by the separation, but overall it’s an effective way to take the class. Furthermore, the university saved money by not paying travel, lodging and meal expenses for me, and I avoided the slight hassle of traveling. Three out of four days, I took the class from home; one day I took it from the office. Guess which location had fewer distractions? (Hint: I have a very distraction-free home office.)

IPv6 Day thoughts

Today was World IPv6 Day, the day when many web sites and Internet service providers were supposed to test IPv6 for 24 hours. I doubt most people noticed. My workstation is IPv6-connected and I kept a connection tracker up for most of the day to see when IPv6 was used. I was disappointed to see that Akamai did not go over IPv6 today, at least from here. Google and Facebook (which uses “face:b00c” in its IPv6 addresses) showed up on the list. A number of Penn State web sites showed up, but they had been IPv6-enabled long before today.

In other words, ho-hum. From my perspective, World IPv6 Day was a blip. The IT world just needs to keep pressing on diligently in deploying IPv6.

I played with Asterisk 1.8 a little, to see what needs to be done to enable IPv6. Just bind it to the v6 stack with bindaddr=:: in sip.conf (or sip_general_custom.conf if you use FreePBX). That’s it; you’re ready to communicate over IPv6.

Check out the free IPv6 Certification from he.net. You get an IPv6 Sage T-shirt when you have completed all of the exercises that test your IPv6-configuration skills.

Skype gateway with FreeSWITCH’s mod_skypopen

There has been a lot of talk about Skype connectivity in the VoIP blogs lately. Digium announced that they will no longer be selling their Skype channel driver, and this news rekindled interest in free/DIY methods for connecting Skype to Asterisk. Nerd Vittles has a good writeup, specific to the PBX-in-a-Flash/Incredible PBX implementation. His method relies on the SipToSis gateway application (read the SipToSis how-to for more generic setup instructions).

If you are only wanting to receive Skype calls, you can transfer them to your PBX via Tropo developer account, free.

I decided to add Skype to my home PBX last weekend, and chose FreeSWITCH’s mod_skypopen as the connector.

Why?

  • The PBX is Asterisk 1.4, and I’m holding steady on this version until 1.8 becomes a bit more stable. Thus, because I want to use Google Voice,
  • FreeSWITCH is already in place, on the same machine, as a gateway to Google Voice. It has been working well in this role.
  • mod_skypopen requires only the FreeSWITCH module and Skype. No extra connector software is required.
  • It works and was easy to install!

Asterisk 1.4 continues to be a rock-solid choice and is supported (security patches will be provided) for another year. For me, the only killer feature that 1.8 provides is Google Voice connectivity. There are bunch of other new features too, but I don’t need them. Stick with that which works, until you need the features or the support is gone.

Back to mod_skypopen. There are basically two ways to install this to FreeSWITCH. The easy way, and the hard way.

Today, the easy way. If you visit the FreeSWITCH wiki page on mod_skypopen, you’ll find some notes on building and installing the module. If you’re running a fairly standard install of FreeSWITCH that utilizes the autoload_configs structure, you can follow through the wiki instructions to build the module and the fake audio driver and then run the Perl installer found in the source directory to automatically build out your configs, configure the Skype client(s) and set up a shell script to get everything going at startup.

If, like me, you have set up FreeSWITCH only to act as a feature gateway for Asterisk, and have aggressively minimized the configuration, you’ll want to avoid the installer script and perform the necessary steps by hand. More on that in the next posting: “the hard way.” (Not really that hard.)