OS-VoIP | Open Source VoIP » open source

Writing an RFP for an Open Source IP PBX – Part1

Aaron Rosenthal — Fri, 20 Mar 2009 16:02:23 +0000

Most large enterprises would naturally write an RFP for something as critical as their communication systems but also these are the Fortune companies who still haven’t really caught onto the awesomeness of Open Source IP PBX systems, though sooner or later they will and there are some things they should know when writing an RFP specifically for an OS IP PBX. And even if you’re not a Fortune company, you should still write an RFP… honestly, if you’re looking to invest anything over $100K on a phone system, you’d be silly not to have an RFP. Increasingly I’ve found that there is a growing number of large enterprises interested in evaluating an Open Source IP PBX and for those who do, one should understand the differences between an OS IP PBX and a proprietary IP PBX enough to tailor their information in an RFP to fit the realities of an Open Source IP PBX.

I thought I’d write an article about RFP’s for Open Source systems because too few companies write them. The process of writing an RFP can be just as useful in helping a company determine their own specific communication needs as it is for a vendor in determining what those needs are. Most of an RFP, whether for a proprietary or Open Source system, will likely be fairly similar except for a couple key OS VoIP areas which include – interface requirements, redundancy requirements, and management requirements. How you effectively outline your requirements for these three areas will largely dictate what type of Asterisk based IP PBX a vendor will quote for you.

Before I get into specific details about an RFP, I want to make sure that you understand a few important conceptual differences between a proprietary IP PBX and an Open Source IP PBX that will help you understand what you’re getting into. I might bring up these conceptual differences now and again… and I’ll start them with “TIME TO THINK DIFFERENT” just for fun…

TIME TO THINK DIFFERENT- It is an undeniable truth that most Open Source companies get a D for marketing and sales material in comparison to proprietary vendors. The simple reason is that proprietary PBX vendors have the cash $$$ to blow on marketing and most Open Source firms don’t (guess where those licensing fees go?). What results from this dynamic is that most proprietary vendors can show up with sexy clear cut marketing material touting all the bells and whistles of their IP PBX systems. This “loud” marketing material gets customers all riled up about the cool, new, and interesting things a pbx can do. Of course this makes sense, people prefer to learn visually and that’s what marketing material is for.

But anyone who knows this industry will tell you that there’s often a big difference between how marketing departments price and sell telecom solutions and how those telecom solutions are actually engineered. For example, proprietary PBX vendors will convince a company to buy a $10K magic box to expand their exsiting PBX’s voice mail capabilities when in technical reality that box is usually 80% empty and is nothing more than a couple $100 RAID1 hard drives. Imagine if proprietary vendors actually charged what things truly cost (plus a reasonable margin)? Now on the flip side, Open Source IP PBX vendors, the ones who really understand the technology that is, will sell their solution based on the cost to build it… hardware+software+development.

Ok, back to marketing material…. the thing about an Open Source IP PBX like one built with Asterisk is that you are literally faced with an UNLIMITED number of options for what you can do with that system. So rather than being presented with a list of capabilities which is what proprietary vendors do, many Open Source vendors prefer not to put that box around their customers by limiting capabilities to a simple sheet of paper or product brochure. If I were to write marketing material for all the things you could do with Asterisk, and trust me I’ve tried, the resulting product would result in a compendium of work no man or woman would ever care to read. Instead, companies looking for an Open Source IP PBX need to think a lot harder about what THEY want and what THEY need versus going the easy route of just picking a bunch of features off a page. And, if experience serves me right, too few companies actually address their own telephony needs because they’re so accustomed to waiting on a vendor to simply tell them that “these are the features you’re going to get” & “this is how its done”… hence why I’m writing this document – KNOW YOUR REQUIREMENTS BEFORE ANYTHING ELSE…. then put them into an RFP…. makes so much sense doesn’t it….

It’s undoubtedly a daunting task to be told “your IP PBX can do anything” (and it literally can) and then being asked, “now what do you want it to do”… but that is the case so instead of someone giving you parameters for functionality, you need to set your own when looking at Asterisk. DISCLAIMER – Yes systems like Switchvox and Trixbox have a definable set of features packaged into different software tiers much like proprietary systems, they even carry per-extension licensing fees like proprietary systems, but they’re also not your only Asterisk based option which is why you NEED to outline requirements because there might be a better Asterisk solution which is more appropriate for your company. Plus, I want to focus on large enterprises and unfortunately the bundled Trixbox and Switchvox options don’t satisfy organizational requirements that demand more than 150 simultaneous calls whereas Asterisk alone can handle many times that in the right deployment. I’ve worked with Asterisk systems (often built using additinoal complementary Open Source VoIP software) capable of supporting over 20,000 simultaneous calls. So anyone who questions Asterisk’s ability to reliably support large call loads either doesn’t know what they’re talking about or are scared shitless that their proprietary ways are in serious jeopardy so they’re just in denial.

As a side note, Open Source routers and session border controllers are also extremely stable. We’ve worked with software such as OpenSIPS/SER and I’ve seen these systems route well over 80 million minutes/mth through carrier networks. For big enterprises, OpenSIPS might be part of your Open Source IP PBX solution….ya never know.

Where to start:

Ok so you’ve been assigned the responsiblity to source a new communication system for your firm. What do you do? “Oh, that’s easy” you say, I should start contacting vendors and see what my options are for replacing my janky ass key system…. WRONG! The very first thing you should do is determine what your users need, this is the RIGHT APPROACH. Consider you have a clean slate, anything goes, it’s Christmas, and anything you could ever want in a communications system is possible.

TIME TO THINK DIFFERENT -If you’re used to the proprietary PBX world, you’re probably thinking “well there’s always a big different between what we want and what we can afford”. And you would be correct, some features and functionality cost more than others. But, compared to proprietary systems where you’re accustomed to every single extra non-out-of-the-box feature costing money, this will likely not be the case for an Open Source IP PBX.

There’s a big difference between how most proprietary vendors like Cisco and Avaya price their IP PBX systems, and how Open Source systems are priced. The cost of most proprietary systems are usually a reflection of the market and what a company can afford to get away with yet still remain competitive. Usually this pricing is in the form of licensing fees, sometimes hardware costs, and usually if you want more features you’ll be paying [license fee]x[number of users] for a set of particular features. Open Source systems are quite different, and again it depends on what type of OS PBX you’re looking at, but in my experience the cost of an Open Source IP PBX is a direct result of the “engineering time involved in getting the thing configured + hardware + software”. And I guarantee, when talking about a big phone system, it will always cost less to custom develop a complex telephony feature using Asterisk than it would cost to purchase that same feature from a proprietary vendor.

Requirements Gathering:

So in writing an RFP, there’s always a few standard procedures all of which start with “Requirements gathering”. This is the process where you go to all your departments and listen to them either bitch about features they wish they had, or highligh the features they can’t live without.

Some companies prefer to gather requirements by forming an adhoc committee made up of individuals appointed from each department or division. This may make sense for a larger company where department heads can filter their groups requirements into a larger committee pool, but for smaller companies it might be just as effective to notify managers about the impending technology purchase and have them gather some comments/suggestions from their employees.

Information Technology
Operations
Sales/Marketing
Accounting/Finance
Executives
And whoever else I forgot….

Often the above departments might have their own opinions about how a new communications system can improve productivity or provide a competitive edge over your competitors. Let your employees be creative in listing new features which might make a difference in your operations. I’m going to list some department specific out-of-the-box features in Part2 of this article so hold tight.

And here’s where I stop and tell you to wait for the next installment of this article. Hope you enjoyed it and stay tuned for more tips about writing an RFP for an Open Source IP PBX.

Open Source VoIP in the carrier space : A look at Bandwidth.com

Aaron Rosenthal — Fri, 31 Oct 2008 21:58:49 +0000

We’ve talked a lot about enterprise adoption of OS VoIP but businesses are not the only users of this great technology, in fact there’s an untold story about Open Source VoIP and that’s its use within the carrier space. What too many people not in this field don’t know is that carriers are some of the largest users of Open Source VoIP technologies although few carriers will ever admit their use of open source. The reason why many don’t admit its use is the same reason why OS VoIP is slow to penetrate the large enterprise market; that reason being that OS VoIP is still perceived by an uneducated many that Open Source will always be the domain of basement dwelling techno nerds and hobbyists.

Well carriers ARE in fact one of the largest users and most ideal candidates for Open Source VoIP because they’re often the ones with the most to gain from the benefits of this technology- carriers spend squillions of $$$ on telecom infrastructures and thus they have the most to profit by simply replacing existing (and costly) proprietary hardware with Open Source software and COTS hardware. Large chunks of a telecom infrastructure can be replaced by various elements of Open Source Software and since telecom infrastructures are so expensive, theses savings can be astounding. Carriers also tend to have the in-house technical chops needed to work with Open Source software which is a skill few mid-sized businesses have. In fact I’ve found that increasingly carriers are requiring their engineers to be trained and well versed in software just like Asterisk and OpenSER.

One such carrier who not only uses Open Source VoIP everywhere, but embraces and openly acknowledges their use of Open Source is Bandwidth.com. Recently a registered CLEC in all 50 states, Bandwidth.com is growing Flash Gordon style. They’ve managed to top Inc. Magazines fastest growing tech companies 3 years and counting, all while using Open Source software to profitably grow their network and infrastructure at a pace and scale that has reliably kept up with their growing demand.

Now I don’t want to turn this article into an advertisement for Bandwith.com, because that’s not the goal here. The goal is to show that even a large successful carrier with thousands of business customers, with over a dozen telecom products, and a rising star in the telecom world, relies heavily on Open Source VoIP for a good chunk of their network infrastructure. Here at OS-VoIP we’re dedicated to proving OS VoIP’s ability to satisfy the needs of even the most demanding large enterprise… so from where I look at things, I really don’t see that big of a difference between the way in which a carrier network would be engineered and the way in which a large Fortune 1000’s VoIP network is built, in fact I would say that a carrier requires higher levels of redundancy (downtime means lost customers) and a far greater level of flexibility since carrier products and services must shift with market demand with speed and efficacy. So Mr./Mrs. CIO, take note because if Open Source VoIP is suitable for Bandwidth.com and many carriers alike, why not see what it could do for your organization?

I had the pleasure of speaking with Anders Brownworth, head of research and development at Bandwidth.com, and as a long time employee since 2002 (back when there were only 14 people; now there’s 175), I get the impression that Anders has been largely influential in the extent to which Bandwidth.com has adopted Open Source VoIP software. Anders is also a fellow writer at his self titled blog anders.com where you’ll regularly see posts about what he’s up to over at Bandwidth.com.

Bandwidth.com is a next generation telecom company where TDM switching is predominantly a thing of the past; replacing these old TDM infrastructures (typically the backbone of most RBOC’s) are IP networks which is the case for most young carriers building out a new infrastructure. Unless you’re a telco with existing investments in a legacy network, it makes about as much sense as a toothless carnivore to not build your network foundation on IP. Now the folks over at Bandwidth.com could have very easily built their IP network using a myriad of proprietary hardware (which they use in some places) but instead, like most startups do, they went the route of a more financially feasible and flexible option and that ended up being Open Source software. But alas, even while I’m writing this Bandwidth.com has solidified a greater partnership with Sonus Networks to build their Next Generation Network (NGN); a move spurred by their recent CLEC status. All of Bandwith.com’s gateway’s to the PSTN have always been Sonus, like most carriers, but their Sonus network is obviously going to grow even larger which will help them open up shop in more US markets to provide direct “last mile” access to their network…..but we’re talking about Open Source VoIP and that means we’ll talk about Bandwidth.com’s IP network.

Anders tells me that from day one Bandwidth.com has been a heavy user of OSS including Linux, Apache, and MySQL, but most importantly for us over at OS-VoIP is their use of Open Source VoIP software like OpenSIPS (formerly OpenSER) which has fixed Bandwidth.com’s core IP infrastructure on Open Source software from the very beginning… and it’s role is paramount. OpenSIPS is a SIP proxy/router software which Bandwith.com uses to route ALL of their SIP traffic; accounting for the majority of their VoIP calls and the billions of minutes each year that run through Bandwidth’s IP network. With SIP becoming a predominant standard in telephony, OpenSIPS has the potential to completely crush the proprietary IP routing and SBC market with its ability to support extremely large traffic loads while scaling in ways far more cost efficient than anything you’ll find in the proprietary market… all on COTS hardware!

But what do we all know about Open Source?… it’s that Open Source software is not always easy to work with. There’s no question the functionality is there, but I’ll admit that if you haven’t worked with something like OpenSIPS before, you should probably get your hands dirty (very dirty) before deploying something so mission critical as a SIP proxy for a carrier. The other option is hire a firm that knows what they’re doing. I’ve said it many times over, and I’ll say it again, the successful deployment of OS VoIP software for businesses or carriers is as much reliant on the engineer or firm who implements it as it does the software; make the right choices and you’ll reap endless benefits.

When it comes to delivering reliable VoIP services to customers over the Internet, the cruelest VoIP monster is packet loss- which causes latency- which in-turn causes jitter and dropped calls…not an ideal situation for a company trying to portray a professional image. The internet is not designed for the transmission of real time applications which has been the route of countless criticisms about the quality of VoIP. The farther your phone is located from the hardware terminating that call into the PSTN, the longer your latency and the greater your chances are for packet loss and thus poor call quality. There are dozens of VoIP providers today who are small businesses with “who-knows-what” running on the back-end and an infrastructure sitting in a single geographic location… these are the companies who usually give internet based VoIP a bad name. For example, if you’re a hosted VoIP customer in NYC and your hosted VoIP provider’s network is located at a data center in LA, there’s a good probability that call quality could be an issue since you’re talking about running packets coast to coast over the internet which as I said was never designed for real time transmission of data. What you want to do is use a hosted VoIP provider with multiple PoP’s (point of presence) throughout the country so that the distance your call has to travel over the internet is reduced dramatically. Sorry for ragging on you small VoIP providers but it’s just a simple fact… small VoIP providers with a network in one spot are best to serve customers who are geographically close to the network hub… but then this issue of latency and packet loss is a crap shoot, sometimes it happens, sometimes it doesn’t. Ok, latency and hosted VoIP provider pros and cons can be left for another article, another day. So where’s this going?….

Bandwidth.com on the other hand operates ~9 server farms and have POP’s on the east coast, west coast, and some in between. This dramatically reduces the hop your call has to make in order to get into Bandwidth.com’s network…. which in turn reduced latency and increases the quality and reliability of your call. The key is to get that VoIP call out of the Internet and into the carriers IP backbone as quickly as possible. I wanted to briefly touch on their network architecture just to explain some of the benefits of a distributed network which is what I think really separates the boys from the men in this hosted VoIP industry.

So which other piece of Open Source software is running behind the scenes at Bandwidth.com? The next is a new yet increasingly popular piece of software called FreeSWITCH. FreeSWITCH is somewhat of a competitor to Asterisk and while many will argue that one of the biggest advantages to FreeSWITCH is its ability to support up to 4 times the call volume of Asterisk, FreeSWITCH doesn’t have nearly the same breadth of capabilities and support found in Asterisk. Take a gander at a comparison I wrote about the two. FreeSWITCH is what sits behind Bandwidth.com’s new PhoneBooth product, a hosted VoIP solution, which was released over a month ago on Sept. 15th. PhoneBooth is a web based user interface to Bandwith.com’s hosted VoIP solution, providing their customers easy access to features and an admin portal that lets them manage their services. Developing an easy to use admin/user interface that integrates with the likes of Asterisk or FreeSWITCH has always been the golden egg of any company who ventured into developing their own interface of this type. Developing UI’s for Open Source software is always a time consuming process which is why the companies who spend the most amount of time and in-turn develop the most reliable interface will typically close up the code and license their newly developed interface.

Just to go off on a little tangent, Anders and I were discussing our frustration with Open Source developers who unfortunately give little or no consideration to how their product would look and work from a user interfaces perspective. Often OS software is written in the command line by hardcore programmers and by not including a UI, it unfortunately gives some OS software an elitist status because few people know how to work with it. Anders made a great comment which was that he’d “love to see some strong projects in the open source world that approach things from the designers perspective, allowing the designer to say “this is what should happen” rather than the user/admin interface being an after thought. I don’t know why more developers don’t do this because a sexy UI is perhaps the single most important thing general consumers look for…. and I digress…

PhoneBooth is the first robust interface I’ve heard of that was designed to work with FreeSWITCH (although Anders tells me that PhoneBooth WAS originally designed with Asterisk but later re-engineered for FreeSWITCH). Other examples of GUI’s designed to work with Open Source software like Asterisk include Switchvox, Trixbox, FreePBX, PBXtra, PBX in a flash, Intuitive Voice, and many many more. Each of the mentioned UI’s were engineered with varying degrees of success where the free GUI’s are typically less stable than the likes of Switchvox or Trixbox which are now licensed pieces of software; even though the foundation of these systems are built using Open Source Asterisk. Because Bandwith.com operates a tenant based environment, with thousands of customers, Anders and his team developed FreeSWITCH in parts, each part with a different responsibility and capacity to support larger loads. This is one distinction between Asterisk and FreeSWITCH which is FreeSWITCH’s ability to be easily broken up into pieces. Bandwidth.com developed separate conferencing, media servers, and databases from which PhoneBooth directly reads and writes.

I am told by Anders that Bandwidth.com just might open source their PhoneBooth project which would be absolutely fantastic for the general Open Source community! Some folks might even pee their pants. I do have my doubts that this will happen since PhoneBooth is already a valuable piece of Bandwidth.com’s business but if it is engineered as solid as I’d expect it to be, then PhoneBooth just might be the first robust GUI I know of for FreeSWITCH and perhaps it could be easily adapted back into working with Asterisk…. as I’m a little more of an Asterisk fan myself, this would be saweet.

And lastly no Open Source VoIP infrastructure would be complete without a dash of Asterisk here and there. When it comes to Bandwidth.com, Asterisk is primarily being used as a TDM to voip gateway which is just one functional characteristic to a piece of software that seems to know no boundaries in telephony functionality. Bandwidth.com has hundreds of these Asterisk boxes spread across the country many of which are used to trunk between Bandwidth.com’s IP network and legacy TDM phone systems or bridging the gap from a TDM carrier network to their IP backbone. It’s a simple role but Asterisk plays it very well.

If you made it to the end, and hopefully you did with a final sense of accomplishment, I want to thank Anders for taking the time and allowing OS-VoIP to dig into some great pieces of Open Source software running behind the scenes over at Bandwith.com. Open Source VoIP software, like those used by Bandwidth.com is being leveraged in places that most people wouldn’t even think of and in ways that are infinitely flexible. We currently live in a world where Open Source software (not all but some) has become so powerful, flexible, secure, reliable, and cost effective that ignorance is often the only argument left for not giving Open Source the brain space it deserves. I know I know.. not everyone shares the same passion for OSS and the first person to make it through this article who disagrees with me (hello you) will instantly, as if subconsciously wired into their brains, refer to support as the biggest issue facing Open Source…. and although I will agree that this is a problem for some Open Source projects, this argument is used WAY TOO MUCH as a generalization referring to all Open Source projects, because the support which exists for many OS projects can be remarkable.

Open Source VoIP software has progressed so much that knowledge of these systems has become a standard skill requirements amongst engineers working in this space. With hundreds of companies developing, implementing, and maintaining Asterisk (as an example), you’d have a hard time convincing me that Asterisk is lacking an appropriate support infrastructure. But, like all walks of life, there are firms who are better than others so if you’re looking to find a reliable Open Source VoIP engineering firm, with the ability to support your needs effectively, just make sure you evaluate your options thoroughly, and don’t always make your decisions based on price because if you do, you’ll usually get what you pay for. One thing many Open Source projects should take from the proprietary world is a more stringent and selective certification process. Having a particular certification to separate the boys from the men when it comes to Open Source engineering would make it much easier for firms to disseminate between a solid OS engineering firm and one which may be full of jokers.

If I’ve achieved anything by this article, look at the technologies Bandwidth.com uses and when you’re in the market for any enterprise grade telephony solution, I hope you’ll give OS VoIP technologies the attention they deserves.

74 Open Source VoIP Apps

Aaron Rosenthal — Thu, 03 Jul 2008 19:57:34 +0000

At some point I’ll be writing a full article on the squillions of Open Source VoIP apps out there but until I find the time to do so, I want to share with you all this list called 74 Open Source VoIP Apps & Resource.

Here at OS-VoIP, one of the things I’m trying to do is help individuals differentiate between Open Source VoIP apps that are ready for the enterprise and which ones are not. A lot of the misconceptions in Open Source VoIP stems from software which hasn’t been finely tuned enough to be enterprise ready or from implementors who just don’t know what the hell they’re doing.

Many of the OS Apps in this list of 74 are already widely deployed within the communication infrastructures of enterprises and carriers- like Asterisk and OpenSER. Others have a much lower adoption rate and still require a lot more development until they’re ready for enterprise adoption.

This isn’t a perfect world and hence some functionality required in a phone system is sometimes best left to proprietary software (for now). The good news is that the most important part of a communications system, the brains of a PBX, is perfectly satisfied by OS software like Asterisk and OpenSER. Proprietary software has it’s place in delivering added features and functionality to a system who’s core is built from Open Source software. Functionality like speech to text for example is (for now) best left to licensed software like LumenVox or using a proprietary contact center solution like Aspect on-top of Asterisk.

With the near limitless capabilities of software like Asterisk combined with an ever growing list of Open Source VoIP apps, the difficult part is to know which apps may compromise the stability of the system as a whole and which ones will best complement the functionality of your IP PBX. Either way there’s no question in my mind that the tools and applications already exist to turn Open Source VoIP into an IP communication system that rivals the likes of large proprietary systems by the likes of Avaya, Cisco, and Nortel.

For those of you in the US, have a great 4th of July weekend!