This is the flip side of the coin–the other half of IP telephony and the systems administration dilemma. It’s for the guys like me who enter the arena knowing how to configure, operate and administer a server, with some server-level operating system on it, and who are handy with the tools of that OS. We are adept at building open-source software from the C source files and issuing commands to run the software. It’s for those of us who arrogantly look at software like Asterisk or FreeSWITCH and think, “Piece of cake. Install the build tools,
make, edit a config file and done! I’ve done it a million times!”
Not so fast. What the systems administrator has before him or her at that point is software that may run, but not do anything useful. And to make it work in a sensible way, it seems like you have to understand
- the whole realm of telephony hardware, including endpoints and interfaces to analog and digital telephone networks;
- networking protocols, including some fairly complicated quality-of-service configurations and NAT/firewall workarounds if you’re in such an environment;
- phone company lingo, so that you can order the right service from a provider to connect you to the outside world;
- technical voice services areas like call routing and dial plans, so that your phone system is actually usable (by your business or family);
- business functions, so that you can get the call records into the hands of the people who are going to charge the users for their usage.
And, because I am sure I am forgetting a number of other areas, I’ll tack on “and much more.”
I personally have found these areas much harder to learn than server and operating systems administration. When it comes to voice, I know what I know, and more importantly, I know what I don’t know, which is quite a lot! But the real stumper is when I don’t know what I don’t know. (You know?) In situations like that, Google doesn’t help much because I don’t have the right terminology in the search. It’s time to find the voice gurus out there, the ones who have been through the various iterations of PBXes.
I suspect that it’s easier to add server and OS administration to a full and rich voice services skill set than it is to take a systems administrator and make him/her into a competent voice person. Any commenters care to share opinions on this?
Today I attended an all-day training session with the aforementioned title. I already have some experience using open source tools: we use Smokeping, Cricket/RRDTool, Multicast Beacon, and others. I have some experience with Wireshark. The value in today’s training was hearing an experienced network professional (Mike Pennacchi of Network Protocol Specialists) talk about how he uses these tools. Understanding the concepts and seeing an expert use the tools in certain ways is more helpful than just reading the documentation.
Aside from an extended session on Wireshark, which really helped me get a better grasp on its usefulness, the speaker presented a few other tools that were new to me. nTop can use Pcap or Netflow data to describe network usage. Nagios works well on its own but becomes a super power when combined with Centreon. I’m not trying to start a link farm here. These links will be useful when I get back to the office and find some time to start digging in.
Because this was a session on open source tools, there was a brief discussion about the “support” issue: who supports open source tools? One comment that I liked is that, even though there’s nobody on the line to yell at, with most large open source projects, the answers you get from searching Google are better and faster than what you’d get from phone support, anyway. I hate to admit this, because it makes me the last stop of responsibility in troubleshooting, but it’s pretty accurate.
This morning, four of my colleagues and I met with three IT professionals from the University of Oslo who are on a five-day tour of US east-coast universities and companies with large VoIP installations. They’re planning an upgrade of their 11,000-telephone deployment to voice-over-IP and we offered some insight, tips, warnings, and random thoughts on deploying VoIP at a large university.
They, like many current entrants into VoIP, are interested not just in open standards (SIP) but also in open source.
Is it true that a large institution like Penn State needs a large company like Cisco to provide and support a voice solution? It’s hard to argue against. Cisco provides excellent support. But what we don’t get is the opportunity to dig into the software code, make our own customizations and hack. From a support standpoint, this is a good thing. If we want to hack at the system, as we could with Asterisk, we lose a great deal of support. Significant tradeoff.
What’s out there right now for open-source VoIP PBX? I know only of Asterisk, sipX, Pingtel’s SIPxchange, and maybe SER/OpenSER (but these are just SIP proxies and don’t offer full PBX functionality on their own). I don’t believe any of these products or the companies behind them will be of significant interest to large VoIP customers until they look more like RedHat, for example–based on open-source but structured like a real enterprise solutions provider.