A recent article posted in The Technoverse Blog (in Telecom Patchboard)
My curiosity got the better of me. While I’m completely content to use turn-key cloud telephony–OnSIP, in my case—the lure of DIY telecom is sometimes too enticing to resist.
This led me to SIPfoundry’s sipXecs, an open-source PBX that many are using instead of an on-premises metal-based solution.
SIPfoundry has grand goals for open VoIP solutions. They are an independent non-profit that hopes to promote “free and unencumbered” telephony. Which is another way of saying their sipXecs PBX software is 100% standards based. So if enough companies, small and large, install sipXecs on their servers, we can all communicate via SIP over the Internet and not pay a dime in per minute charges.
I thought I’d experiment with sipXecs to see what all the shouting was about.
I am not part of a corporate structure with spare LINUX servers on tap. I did what a lot of business that need on-the-fly access to data center servers are trying: I grabbed a virtual server from Amazon’s Elastic Computing Cloud or EC2.
Did I also mention I’m not really an IT person? Certainly sipXecs requires a very tech savvy person to install and maintain. I knew about EC2 from a previous writing assignment, and I was after all a former UNIX developer.
Just enough background to get me into trouble.
The first speedbump I ran into was learning enough about EC2 to grab an appropriate virtual instances—in my case I was looking for Red Hat’s Centos version 5 OS—from their data center in the clouds. There are references at the end to explain how to access EC2: the key tool being Amazon Web Services or AWS console.
EC2 and AWS are not terribly difficult to comprehend and work with, but there are subtleties with private and public IP addresses and DNS—some of which is still stumping me.
My goal was modest: just to bring sipXecs up and experiment with its browser-based interface. If I could get a SIP endpoint connected, I would consider that just gravy.
I forged ahead with my foundry.
The documentation on their Wiki explains how to install the software—you’ll need to learn a little about the yum software installation utility. So … once the sipXec is installed, you then configure this soft PBX using their sipxecs-setup command.
After a little trial-and-error, I got sipXecs on-line and then scooted into the browser interface.
From what I can tell, this thing looks like a real PBX:ACD, auto-attendant, conferencing, hunt groups, intercom (automatic answer), along with support for lots of SIP phones (Cisco, Avaya, Linksys, Polycom, Audiocodes, …) and gateway integrations to the TDM world.
Overall, I am impressed. Quibbles: the responsiveness of the Amazon virtual OS instance I’m using is sluggish, but I didn’t pay for anything very powerful.
Yes, did try to get my X-Lite softphone to connect;unfortunately that involves a level of DNS prowess that I don’t possess at this point. I hope to have a resolution soon enough and should have another post on how sipXecs plays with endpoints.
I was on do-it-yourself-mission in this post but that shouldn’t take away from the fact that sipXecs is a serious product for large companies. For the enterprise, a new player, eZuce, has recent stepped in to provide corporate-level support.
Even with pay-for-support model, I believe that sipXecs is very competitive proposition versus on-premise hardware. Check out the eZuce site for my information. read more....
No comments:
Post a Comment