OS-VoIP | Open Source VoIP » Asterisk

Mark Spencer on Skype and Asterisk

Aaron Rosenthal — Mon, 02 Aug 2010 16:15:42 +0000

Here’s an interesting video from earlier this year with Mark Spencer addressing Skype and Asterisk.

America 2009 Video: Skype and Asterisk – What it Means for Business Communications (Mark Spencer)

IBM Smart Market embraces Asterisk… building your IP PBX becomes childs play

Aaron Rosenthal — Tue, 20 Oct 2009 21:55:49 +0000

Well last week marked the end of Astricon 2009 where a myriad of VoIP and Open Source companies came together to showcase new products, new solutions, and make big (and sometimes small) announcements. One of my favorites and more notable announcements was between Digium/Asterisk and IBM.

You can read some specifics here, but in short IBM has brought Asterisk into its Smart Market program. IBM’s Smart Market is a marketplace for applications designed or tweaked to operate on IBM’s hardware, specifically the IBM Smart Cube. It’s kinda like the Apple App Store, take the iPhone for example which is a “ready to rock” computer with a whole slew (70,000+) of applications designed to work perfectly (supposedly) on the iPhone… all purchased via the App Store. The IBM Smart Market and the Smart Cube hardware is much like the same.

Organizations with a tendency towards Open Source or just plain ole cost savings can now simply purchase their Smart Cube from IBM, download a customized version of Asterisk designed to be managed via the Smart Desk management dashboard, and BAM… with some configuration you’ve got yourself an IP PBX. Additionally… here’s my favorite part, support is handled directly by IBM! Anyone who has worked with IBM knows that their support is one of IBM’s strong points and exactly why I’m extremely excited to see IBM extending that support to Asterisk. Support is one of those areas which I think has stifled some of Asterisk’s growth primarily because the quality of support provided by the myriad of different Asterisk re-sellers and even Digium itself has been so varied in its quality that its quite hard to truly define a guaranteed level of support when it comes to Asterisk. Of course I’m rather biased but I like to think my company has some of the best Asterisk support around, but that just can’t be said about everyone :-)

Now all this product launch hoopla isn’t what really interests me… well yes IBM is providing Asterisk support = awesome…. and yes Asterisk is tweaked to be managed via the Smart Cube dashboard = actually kinda big…. but what I’m particularly excited about is the continued traction Asterisk is gaining within the world of telephony. Acceptance by a computing titan like IBM is just one more badge on it’s sleeve of awesomeness. I myself am thrilled how common the term “Asterisk” has become in almost every discussion pertaining to telephony and IP PBX solutions. There are still some haters out there but those who criticize the technology haven’t really taken the time to fully understand it, while those who have, become its greatest advocates.

I used to be surprised when people said they were actually familiar with Asterisk, now it seems to be one of the first things someone will Google when buying an IP PBX. Now I say this… but I also say it knowing that it applies primarily to the SMB market in which Asterisk has seen the largest amount of growth… but my only interest in the SMB market is its use as a case study to prove to larger enterprises that Asterisk based solutions fit business of any size and application and should always be evaluated right alongside the big players. We’re not quite there yet, 1000+ Asterisk deployments still remain few and far between, but as Digium and Asterisk start partnering with companies like IBM, and when companies like IBM are willing to stake their reputation on supporting Open Source software like Asterisk, I think it validates Asterisk’s future trajectory as being a respected IP PBX solution amongst not only SMB’s but organizations of any size.

But enough with my soap boxing… you probably would like to know about pricing.
There are two options for purchasing Asterisk for the Smart Cube:

$2,000 for 20 simultaneous calls.
$4,000 for 40 simultaneous calls.

Check it out!

By Aaron Rosenthal

Writing an RFP for an Open Source IP PBX – Part2

Aaron Rosenthal — Fri, 18 Sep 2009 15:40:31 +0000

Welcome to my second installment of “Writing an RFP for an Open Source IP PBX”… But first let me apologize to my loyal readers, I have let you down… I’ve been caught up in the regular grind of the summer and have neglected OS-VoIP. There’s a lot of interesting things going on in the Open Source VoIP space and I’ve got a long list of things I want to talk about, so get ready for some action here at OS-VoIP! Ok… onto RFP’s…

In my previous post, here, we went over a variety of reasons why Open Source needs to be approached and perceived differently than regular proprietary systems. We also discussed the importance of determining (in detail people!) your own requirements as the very first step in this process.

Part deuce starts with this………

Answer the important questions

Regardless of where you place this information in an RFP, it should always be addressed. The earlier you make these decisions the easier it will be to start off on the right foot when asking vendors to quote you an Open Source IP PBX solution. This is by no way a complete list of questions but these are the important ones.

Do we plan to have a converged or segregated voice and data network?
This is a very important decision and will sometimes dictate the type of phones a vendor recommends as part of your solution. For example, if you are converging the voice and data networks and in turn daisy chaining desktop computers to the phones, you’ll want a phone with a switch, and possibly GigE support should GigE to the desktop be important. Some phones don’t even have a switch so be careful not to make the mistake of converging your networks only to find that the 150 cheap Polycom 320’s you purchased don’t have switches in them! Most network engineers would recommend that the reliable approach to take is keep your voice and data networks separate but this sometimes carries a greater upfront expense such as running a second ethernet drop to each workstation or purchasing twice as many switches.

On the topic of wiring, I’m going to share a suggestion which some of you might disagree with. Should you ever need new wiring, DO NOT make it a requirement in your RFP that your OS PBX vendor also be required to handle wiring! My opinion – office wiring should be left up to electricians… I’ve always said that any company (specifically in the OS IP PBX world) who does both wiring and Open Source IP PBX’s is going to lack significant skills in one area or the other. Good engineers who really know how to program software like Asterisk sit at their computers all day being programmers… they don’t usually make the best wiring contractors. We live in a world of specialization, companies can either do twice as much half ass’ed, or half as much bad ass! Wiring and software development are just too different for most companies to want to maintain dedicated resources for both.

What type of phone service do we want to use with this new Open Source IP PBX?
The beauty of most OS IP PBX systems is that they will work with almost any type of phone service. A lot of people for some reason think that an IP PBX will only work with digital phone service and this is not the case. If you are replacing a legacy phone system then chances are you’re using either a T1/PRI or POTS lines which won’t have any problem plugging into your new OS IP PBX. Now a vendor isn’t going to care much whether you stick with a PRI or POTS because that usually won’t impact the overall solution (other than the type of telephony cards/gateways quoted), BUT if you plan on using other types of phone service, then there’s a few more things a vendor should address and therefore why you need to let the vendor know about these in the RFP.

So what am I referring to? SIP and Internet based VoIP service. Most large businesses wouldn’t consider using internet based VoIP for their primary voice service because of call quality issues that still plague these options (no QoS, latency, etc), so I won’t discuss these here. Dedicated/private SIP on the other hand is a very good option for an OS IP PBX system. Dedicated/Private SIP is where the phone company is actually providing you with a dedicated voice circuit, such as a T1/fiber/ethernet, which is delivering SIP service directly from their network to your office. Using your data connection to run SIP over the internet is NOT a private SIP solution, it is a public SIP product. Here’s a little article I wrote about SIP which I hope to elaborate on soon.

One of the main advantages of using a SIP service is that you offload call transcoding from the PBX resources onto the carriers network. Asterisk for example is SIP native, so is FreeSWITCH, so by using SIP as your primary phone service that call can in many cases ride un-altered from the handset all the way through the carriers network and the transcoded to the work on the receiving end. By eliminating the need for the PBX server to transcode the call, you save resources and in-turn increase the call capacity of your server.

How do you plan to administrate your Asterisk system?
This is probably the most important question to be answered because what you say to this question will entirely dictate the type of Asterisk flavor you purchase. Although building an Asterisk system using open source or BE Asterisk can result in the most reliable, fully functional, and flexible PBX solution (when engineered properly), it also lacks what most IP PBX buyers want to see which is a user and admin interface. Asterisk is entirely programmed and configured within the command line, and unless your company is of a size where you can afford to hire a telecom administrator with Asterisk experience, you will probably need some sort of administration interface. If you are of the size where having a dedicated employee/s to manage your PBX… then it makes perfect sense to hire Sys. Admins with Asterisk and Linux experience. Actually, if you have these resources then you have even more of a reason to build an OS IP PBX. Remember that if you require an admin interface, and are a company larger than a couple hundred users, then most of your Asterisk PBX options will be licensed products. If you want that admin interface instead of employing an Asterisk engineer then you’re going to likely get tied into licensing and per seat pricing models… just FYI.

Existing PBX

It’s very useful for a vendor to know what type of PBX you’re currently running. This should give your vendor at least a general overview of the features and functionality current users are comfortable with, plus the vendor should be familiar enough with other PBX systems to know what features may or may not work differently to those found in an OS IP PBX.

Within your RFP, list the features of your existing PBX which are currently USED by your employees. Everyone utilizes different features so be sure to include all your departments in the conversation while you uncover all those features you never even used but others might find quite handy. This is a good beginning to your requirements gathering process so don’t forget to also prioritize which existing features are important and which ones are not.

Call Centers

Now here’s a hot Open Source topic… Asterisk and Open Source software for the call center-
I’m not going to stray down this road too far because writing an RFP for a call center PBX is usually quite different than a standard enterprise communication system. Call Centers have about a gagillion feature requirements and in many cases these requirements are so specific that a highly customized Asterisk system is sometimes just what the doctor ordered. Typically in a call center, specifically one using Open Source technology, Asterisk is rarely the only software being used as part of the “total solution”. There’s a whole slew of applications and OS software which… when combined… can rival even some of the most established call center solutions.

Actually, not many people knew this but Genesys (dubbed the worlds #1 contact center software) used to fully support Asterisk. Quite a few call centers were deployed with Genesys software running in conjunction with the Asterisk PBX. I think this is a fairly good testament to Asterisk’s increasing presence in the large enterprise space. Genesys even used to be a participating partner in the Asterisk community… but not any more. Word on the street is Genesys partnered up with Microsoft with an integrated solution with Microsoft communication products and that was pretty much the end of their partnership with Digium… dang it.

Proprietary call center applications are purchased in modules – inbound, outbound, agent portal, etc….and each module costs more money. In the Open Source VoIP space, modules are replaced by 3rd party applications which work in conjunction with software like Asterisk. For example, ViciDial is free software for Asterisk designed for outbound call centers. QueueMetrics is licensed software with hundreds of reporting functions and options that works in conjunction with Asterisk. Aheeva makes a fully functional call center solution built entirely on Asterisk but unfortunately they’ve licensed the product out the wazoo which I think is very non-open-sourcian of them…

If you are compiling an RFP for an Open Source call center, then you definitely take your phone system more seriously than most businesses… obviously… because it IS your business. And naturally you’re concerned with the risk you might take with implementing an Open Source PBX system. As a call center I’m sure writing an RFP is as familiar as cotton candy at the carnival, so I won’t draw this out more than I need to. BUT… what I will say is “keep an open mind”. Your biggest risk in implementing Open Source VoIP software for a call center is not the technology itself, it’s the capabilities and experience of the company who implements the solution. Or, depending on your own technical chutzpah, maybe you can develop your whole call center PBX internally. I recently lost a call center bid for a 400+ agent facility due solely on the fact that the non-technical CEO hadn’t heard of Asterisk… and despite the fact we met EVERY requirement, and despite being able to scale infinitely with their growth, and even despite the capital cost being about $250,000 less than Cisco… they still got cold feet due to inaccurate assumptions and a bloated stomach from all the proprietary spoon feeding.

Here’s an important tip about the RFP process- if you’re making a recommendation to the CEO or CIO to purchase an Open Source IP PBX… insist that they participate in all discussions with the vendor. I’ll be the first to say that it’s not a simple task to understand these systems, and reading a proposal (the result of your RFP) is rarely going to single-handedly sell an OS IP PBX against a proprietary system. If a CIO is reading two proposals, one by Cisco for example, the other an Asterisk system… their instant gut reaction to the Asterisk proposal is to completely discredit it because the price is so low. If the decision maker isn’t educated about these systems, seeing a 50% price difference usually hurts more than it helps. They think “oh this solution must be the Yugo of phone systems” or “this vendor has wildly underestimated our requirements” or “where’s the other zero” ….

Without fully understanding the technology, the development, the capabilities of these systems… a CIO can not make an educated decision about an Open Source IP PBX. What is the solution, I’ve already said it… participate in discussions with the Open Source vendors, don’t make assumptions, ask questions when you have concerns, and LISTEN to the answers.

When buying Cisco or Avaya… the primary characteristics a decision maker cares about are features and price; they usually don’t question the products ability to simply “work”. Features and price are simple to address in a proposal. An Open Source IP PBX on the other hand… decision makers question EVERYTHING, will it be reliable? Will I get support? Does it have the features I need? Will it be too hard to use? These are all gut reactions which must be addressed by the vendor, and it’s no easy task. You simply can’t eliminate all these concerns through information in a single proposal… no matter how large it might be… It requires numerous calls, meetings, and research on the part of the final decision maker. Unless the final decision maker takes the initiative to understand these products, and participates in calls with the vendors to explain these systems, then they’re not going to be equipped for the questions and concerns they’ll undoubtedly have once a solution has finally be recommended by the vendor. So why should the CEO, CIO, or final decision maker spend so much time in understanding these systems…. because if an OS IP PBX is the right fit, they stand to save their own company A LOT of money, not just in upfront capital but most importantly in ongoing costs.

Solutions you might need, but didn’t know could be done with Open Source VoIP

And lastly I want to leave you all with a slightly greater understanding of the capabilities of software like Asterisk… because once you have a well engineered Open Source IP PBX, you’ll learn there’s much more you can get out of that bugger, the only limitation is… well…you. When it comes to the world of technology, and software, and especially voice, if you can think it… you can do it with Open Source software (caveat-if you know what you’re doing) For example, I’m working with a company right now for whom we built a custom IVR solution which in a lot of cases would be the extent of this systems capabilities. But with Asterisk, we are now able to take the same hardware, same software, and with some additional development increase the capabilities of their solution from an IVR to a full blown PBX to support almost one hundred remote call center agents.

So, where you might think you need multiple solutions or systems… you’ll find that sometimes your highly customizable Open Source IP PBX will scale and do the job just fine.

Here are some examples:

Paging – I see this ALL the time, I’m sure you do too. Company has their PBX, and they have their dedicated external paging system, and the two integrate. Well because endpoint costs on OS IP PBX’s are so low, I see very little reason why you wouldn’t use your PBX as your paging server as well. Paging features such as multi-zones, two way paging/intercom, and music are features which can all be replicated by most PBX systems. You can either use analog paging speakers, or IP paging speakers…. check out CyberData’s product. They have a very impressive product line, let me just forewarn you that every time I’ve ordered their products they’ve showed up anywhere from 2-6 weeks late. External paging with Asterisk = works swimmingly. All this is on top of the obvious fact that you can still page through the handset.

Emergency Notification – Companies can spend LOTS of money on emergency notification systems… but a lot of the same functionality can be dealt with by Asterisk. In an Emergency, the idea is to send out blasts to a particular group using all communication methods… email, voice, text, page, etc. By integrating Asterisk with something like a contact database, you could initiate Asterisk to make outbound blasts to phone numbers… either record a message or send via text which Asterisk can then read via a text to speech engine. On top of that, integrate Asterisk with an SMS gateway and that’ll take care of texting. Additionally, Asterisk could page all phones and paging speakers… and with the addition of a basic web app or custom script I’m sure there’s a LOT More you can do… like tweet, or facebook, oh the possibilities!

Access Control - Did you know that with IP access control devices which are SIP compliant, you can actually use Asterisk for access control? The interface might be a little dodgy but let’s say you have IP card readers to access a building, Asterisk can actually open the door (integrated with a door jam – analog or IP), you can log that action just the same as you can log when a user makes a phone call, you could even program Asterisk to make a call once someone entered a particular room. For example, maybe campus or corporate security receives a notification or call from Asterisk whenever someone enters a particular secured area. There are big massive giganticly expensive security systems that do just this, and usually people will integrate their PBX with said systems… but if your requirements are fairly basic, and you’re willing to compromise on sexy interfaces, you’ll find that your PBX might do exactly what you need for a fraction of the cost. Plus you eliminate the integration costs.

Now I know what you’re thinking… “if I use my Open Source IP PBX for everything won’t it become a single point of failure?” It all depends on how the system is built, maybe you build dedicated Asterisk systems with a single function. Or, with ALL the cash dollaz you save by using your Open Source PBX to replace other dedicated proprietary systems, you’ll have some extra budget to beef up the redundancy of your IP PBX. Pay a little extra to cluster or load balance your systems, purchase larger and more reliable servers, beef up your network redundancy, buy more POTS lines for fail over, heck… get some internet SIP trunks, and keep the PRI… You can make any technology completely fault tolerant with 100% up time… you just have to make the right development decisions and you need to spend the right amount of money. The lesson here is what would be cost prohibitive in the proprietary world is often affordable when evaluating an Open Source IP PBX.

Keep your options open, start from an “anything is possible with Open Source” mentality… and work backwards from there.

If you’re in the market for more than just a PBX, discuss with an Open Source PBX vendor and perhaps include a list of your requirements in the RFP. Just maybe you’ll kill multiple birds with one stone… a stone meticulously made out of Open Source software and COTS hardware!

Oh, and one last thing. Building an Open Source IP PBX is NOT free… I get this a lot. For some reason people expect to just buy the hardware, install the software and BAM, they’re good to go…. wrong. Large enterprises should realize that if you’re looking at a proprietary system that costs a million dollars for example, an Open Source system may cost half that. Nevertheless we’re talking real money, and even at half the price, five hundred thousand is still a chunk of change. If you plan on doing an Open Source IP PBX the right way, plan on paying top dollar for the best hardware and the best development resources. But you know what’s awesome….even if you pay top dollar for everything… your capital investment is still going to be a heck of a lot less than what you’d expect to pay for a proprietary system… and you’ll probably get a heck of a lot more!

Good luck hunting…

By Aaron Rosenthal

An Asterisk Milestone – Shove 10,000 simultaneous calls onto a single Open Source machine!

Aaron Rosenthal — Fri, 28 Aug 2009 20:54:29 +0000

Recently Olle E Johansson posted some details about how he managed to get 10,000 simultaneous calls out of a single Asterisk server. As far as I’m aware, this is the largest number of simultaneous calls documented on a single Asterisk based server, so congrats Olle… I hope you enjoy that bottle of wine!

Now who says you can’t get more than 250 calls on a single Asterisk server??? I’ve always known that with the right setup and configuration you could get at least 2,000 calls on a single Asterisk server… but 10,000 is a remarkable milestone. It’s news like this that further validates the significance Asterisk and even other open source VoIP software plays in the world of carrier communications. If I were a company like Cisco or Sonus, I’d pay very close attention to all this.

Now yes, 10,000 calls is a lot.. but it is inevitable and as Asterisk continues to evolve, its ability to handle more and more calls will increase. The maximum number of simultaneous calls which Digium (creators of Asterisk) will support is 250 calls, I really hope that soon they increase this capacity because it really is stifling Asterisk’s growth amongst service providers… but then again, these type of large call loads are not easy to achieve and often require the assistance of those who are extremely well versed in Asterisk.

From reading the post, I did get the feeling that there was a little bit of voodoo involved with reaching this benchmark, but hopefully we’ll see some documentation soon to follow so others can start replicating and testing such a load on large servers.

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.

Crossroads: Free or Commercial Asterisk?

TylerM — Wed, 18 Mar 2009 17:28:08 +0000

Editors Note: Here’s an interesting piece by Tyler Merritt which I think should generate some good discussions amongst the OS-VoIP community. I personally believe that most Asterisk vendors wouldn’t be in this business if Asterisk wasn’t free, but what I think this article addresses well is the question of “how “free” is Asterisk really for the end user?”

I believe that Asterisk is at a crossroads and has been for some time. Asterisk stands on the Path of Life for applications and ponders a fork clearly visible: Free or Commercial? Champions of the Cause of Asterisk on either side of the path cheer for one of the two forks. Which choice will the application make? Do the creators, contributors, designers, and dreamers really have a say in the matter? Is everyone making noise for nothing?

I don’t know the answer to all of the questions above, but I have a strong inkling that Asterisk must inevitably choose the Commercial fork. There is no future in Free. I stopped most of you right there. With that one statement you stopped reading. Your mind rejected the ugliness of the letters making up the word “commercial”, and I lost you. Perhaps Asterisk is destined to lose you when the next startup telephony switching software with a “free” bumper sticker affixed to the rear makes an appearance on the web (FreeSwitch ?). Commercial means casualty of the Open Source movement – right? Why should it?

Let me define terms. We can’t very well have an intelligent discussion about a subject where neither side agrees on standard terminology. So here is where I lay it out. You don’t have to agree with the definitions below. But if you don’t agree, then we can’t talk about the subject within the same field of reference. I think the terminology is fairly unbiased, so the playing field is level, but spin of any sort renders the discussion meaningless.

Commercial: a product or service obtained by an individual or business from another individual or business for a fee.

Free: a product or service obtained by an individual or business from another individual or business for no fee.

Future: Google has a whole list of definitions (Define:Future ) and none of them apply. In this case, when I say ‘future’, I mean of all the evolutionary choices that exist for this application, the ‘future’ marks the choice (or string of choices) that lead to the most dominant possible iteration of Asterisk. In other words, if Asterisk is a baby gorilla right now – what are the best possible combination of future choices that help the baby gorilla become the dominant silver-back in the group of telephony gorillas? Application Evolutionary Choose Your Own Adventure.

When I write as freely as I am writing now, I hear questions in my head in response to blanket statements I make. I say, “There is no future in Free” and I reply to myself, “Asterisk is an Open Source application – it can’t be closed now that it’s GPL, so what do you mean ‘there is no future in free?!’” I mean, simply, that Asterisk doesn’t scale in the long-run without commercial implementations. Asterisk isn’t Linux. Asterisk doesn’t have the same user-base as Linux. Linux was a blip on the technology radar all through the late 90s and still hasn’t gained as much traction as Linus might like. But Linux has a cult. A cult of devotees with zombie-thirst for ‘haters’. I’m actually one of them. Asterisk, by comparison, has a cult of devoted ‘integrators’ who LOVE the free ‘engine’ because they can build things on top of it and prof$t. No one loves this application enough to build it up and improve the foundations for free.

Sure, there is a community of developers who fork code back into the main Asterisk tree, and yes they have contributed modules and features and functions and we thank them for it. But I call shenanigans on any of those individuals who did it purely for the unrequited love they feel for an Open Source telephony switch. They do it to save their business money, or to make money implementing a cheap phone system for a non-technical customer. Or they do it to sell hardware.

Who is Anti-Free-Fork-Cheerleader-Number-One? Digium. Digium (Mark) did not write Asterisk out of benevolence and a desire to “give back” to the world and take away the wicked Crown of PBX from the Goliaths of telephony. Mark Spencer didn’t have enough money for a PBX, so he created one. It’s in his wikipedia article “Spencer did not have enough money to buy a PBX (private branch exchange) for his company so he decided to write Asterisk and later founded Digium.” Later founded Digium. He created an Open Source application, and later found a way to prof$t from it – by selling Digium TDM Cards that work really well with Asterisk!

Now the paragraph above might come off as negative towards ‘ol Mark. By no means should it be interpreted as disrespect. Mark Spencer is an engineering genius and did create the current undisputed champion of the open-source telephony world. He created an application that makes the incumbents quake with fear . But he did NOT do it for Free. He did it to save his company money, and then he created an auxiliary business model around this application to continue to make money.

So if we accept that Mark Spencer, a good guy, a great guy, is not Robin Hood, then we have a point in favor of the Commercial Fork.

Let’s look at other evidence that Asterisk is heading down Commercial Lane imminently:

Google “asterisk” (I did it for you )
What do you see as the first two pages?
1. http://www.asterisk.org/
2. http://en.wikipedia.org/wiki/Asterisk (this is actually the 3rd link, but the second is another page on asterisk.org so it doesn’t count)
So far, so good – Asterisk appears to be associated with URLs in the ‘ORG’ space – which isn’t for companies pushing products and services.
How about the next links through to the end of the page?
Asterisk.com!!! <– Commercial!
Blogs about Asterisk – telling people to get involved or telling people how to use it. And those blogs run Ad Sense (or their own ads); hence, they make money.
Books about Asterisk – books cost money.
Companies offering to sell you an Asterisk-based system (for money)
Some unassociated “Asterisk” sites that managed to make it onto the front page of Google Search and have nothing to do with telephony.

Two links for Free Asterisk – the rest for prof$t.

How about looking at the right-hand side (where all the ads that we tune-out live)?

For me it reads: Fonality.com, IntuitiveVoice.com,VoIPSupply.com, 3CX.com, thevoipconnection.com, Dell.com, vnowinc.com, freshairstudios.co.uk (offering voice prompt professional services – for Asterisk!)

Sure looks like a lot of businesses are finding creative ways to prof$t from Asterisk!

Ok so you still may be holding a grudge from Paragraph #2 – you might never be able to find it in your heart to forgive my slight. However, I have a point – Asterisk can only continue to exist on the Commercial Path. There isn’t an end-user use for this application. This is a telephone system (sans the system until you add hardware). Asterisk is a business tool. Businesses have a single reason to exist: prof$t. And they should. No business should exist for altruistic purposes. If you think otherwise, you’re a teenager struggling against the angst of learning to live with “the man” – or you’re crazy.

Look at the economy. People are losing the basic ability to feed their families left and right. Asterisk is a cost-savings solution, it’s a maintenance-contract savings solution, it’s a “this never should have been so complicated in the first place” solution (i.e. time). Asterisk is as much about money as the dollar bill. It’s either making dollars for someone, or helping someone use fewer dollars and maintain a tool they need to survive.

And it’s good. It is righteous that this application generate income for all parties. It is ok that companies have taken the product, built some service or function on top, packaged and sold it off to some other company that didn’t have the time/experience/expertise/money to get the same functionality from Avaya for a lot more money. Commercial is a blessing.

Without Commercial we lose most of the Open-Source world. If there wasn’t demand for Support and Professional Services – there wouldn’t be a Ubuntu. Sure Linux is free – but I remember the first time I had to install something – I didn’t even know the right words to google in order to find the “make” command (application – call it what you want). Linux walks the Commercial Path. Oh yes it does. And if there is even a ghostly resonance of Linux walking the Path of Free, it’s too ethereal even for my imagination to detect.

Asterisk isn’t a commercial product. I haven’t said it was, and I hope you didn’t get that impression. This part goes back to the messy work of defining our terms. Commercial doesn’t mean product in this article. We both know Asterisk can’t be closed down – that’s not how the GPL works. I posture that the only future (again, please re-read my definition of future) for Asterisk is on the Commercial Path.

Some of you agree with me. You may be wondering what’s the point of the whole article if you knew from the start that companies are prof$ting from Asterisk already? Reputation. The Open-Source community harbors within its ranks some of the most aggressive, stubborn, quack-defenders of any group or association online or off. People who rant and rage in forums and on message boards about the pure evil of companies who dare to take an application created in the beautiful spirit of ‘free’ and defile it with commercial shackles… don’t get it.

Without us – Asterisk would cease to be.

By Tyler Merritt

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.

Nortel buys Open Source IP PBX company Pingtel

Aaron Rosenthal — Wed, 13 Aug 2008 23:22:08 +0000

Today Nortel announced its acquisition of Pingtel, an Open Source IP PBX software company. This is some pretty big freakin news for OS VoIP… it’s BIG.. it’s HUGE.. it’s really BIG.. and here’s why…

This acquisition marks a milestone for OS VoIP as a technology because it A) shows that Open Source VoIP is a viable business model and B) it reaffirms that Open Source VoIP is finally established enough, reliable enough, and mainstream enough to warrant acceptance by one of the largest proprietary communications manufacturers around.

This move by Nortel is ballsy for their industry but mostly because they’re just one of the first. It also plays well into their plan to become a software centric company. At OS VoIP we’ve always said that proprietary companies like Cisco, Nortel, and Avaya will need to adjust their business to stay competitive in a world of Open Source VoIP, and guess what, Nortel did. Since Nortel’s image has been a few PR campaigns behind Cisco and Avaya, a move like this is exactly what they need to re-vamp their image as a cutting edge communications company, plus it makes sense considering the “open” direction the entire technology industry is heading. From the quote below, you’ll see that Nortel has positioned more than one chess piece towards being “open”.

Over a year ago Nortel joined the open source community established by SIPfoundry** as an active contributor to the sipXecs open source project (led by Pingtel Corp), providing more than 300 new applications and features to date. The acquisition of Pingtel Corp by Nortel will further accelerate the development of a global open source ecosystem and reinforce Nortel’s direction and leadership in the development of interoperable and open unified communications solutions.

So on this day, August 13th 2008, mark Nortel down as the first large proprietary telephony company to take the leap into offering their own Open Source telephony solution. I don’t expect it to be very long for other proprietary businesses to follow Nortel’s lead but I don’t expect Cisco or Avaya to be scrambling for their cash in an effort to puchase an Open Source VoIP company. What I do suspect is that these proprietary companies will either begin to Open Source parts of their own software (doubtful), or partner with an Open Source VoIP company like Digium.

3Com partnered with Digium to re-sell their SMB solutions, Dell partnered with Fonality/Trixbox for their own small business solutions, I don’t think it’s unreasonable for more proprietary vendors to take the same approach.

Now don’t get me wrong, I think this Nortel/Pingtel acquisition is great for the overall evolution of Open Source VoIP and its acceptance in the market place, but it’s not like Nortel is all of a sudden going to be the next big Open Source VoIP company. There are too many established players like Digium, Switchvox, Fonality, and many more for Nortel’s newfound openess to eat away much of their business. If anyone should be threatened by this move it’s Microsoft. Microsoft’s Office Communications Server ‘07 is a software based unified communications solution which although sexy, costs a queens dowry and doesn’t play very well with others. With an Open Source UC solution offered by a billion dollar corporation, Nortel should be able to (with some development and good marketing) compete rather well against Microsoft’s OCS.

So if you take anything from this blog, I’m not saying you should go run off to a Nortel vendor for your next OS VoIP system, because you should run off to me :) but what you should do is realize there are plenty of reasons why an Open Source IP PBX or UC solution might suite your company just as well as any proprietary option. Nortel obviously thought Pingtel’s Open Source UC solution was good enough to buy the whole damn company, so why wouldn’t your organization at least look at Open Source VoIP as an option for your next IP PBX.

Asterisk and FreeSWITCH

Aaron Rosenthal — Fri, 01 Aug 2008 20:50:11 +0000

This week I’m using some link bait which discusses a few of the differences between Asterisk and FreeSWITCH. David Greenfield wrote a short blog post discussing one particular case study where FreeSWITCH was used over Asterisk. I wouldn’t say I’m all that crazy-go-nuts over the post but the topic is worth additional discussion since FreeSWITCH and Asterisk are both fantastic pieces of OS telephony software each of which are strong in their own right. This is in no way a comprehensive comparison between the two, but it’s a start.

I think an even better comparison between Asterisk and Freeswitch was written by Anders Brownworth which looks at the differences between the two from a slightly more technical overview. As head of R&D for Bandwidth.com, I’m glad to hear Anders is playing with Open Source software like Asterisk and FreeSWITCH. My last post about Junction Networks discussed the use of OS software in a carrier network, it would be good news for OS-VoIP to learn that a big player like Bandwidth.com also uses OS software somewhere within their infrastructure, and where (they probably do already but won’t admit it like most carriers). Perhaps Mr. Brownworth can shed some light on the topic for another OS-VoIP article???

Most people will agree that Asterisk in its current state has more feature capabilities than FreeSWITCH in its current state. What largely differentiates FreeSWITCH features and Asterisk features is how they operate as you begin to scale a system and the way in which those features and dial plans are managed.

I’m admittedly more biased towards Asterisk because it’s been around longer and well, because my company is a Digium partner, but I’m also not one to ignore new software even if it feels like sleeping on the other side of the bed. That’s the problem with these large stagnant corporate IT infrastructures, it’s that the people in charge of them have largely relied on their proprietary vendors for information about new technology, and have become too comfortable with relying on these folks for the right information. It takes a true IT leader to step out of their comfort zone and see whether there’s a better way of doing things, something other than that which has been spoon fed to them by vendors. A very simple way to prevent this type of comfortable stagnation is to simply read a few select magazines, and/or blogs on a regular basis; just to keep you up to speed with everything. Throw a wrench into the machine; rustle some vendor feathers; go ahead and see what’s new, source some technology solutions from competitors of existing vendors… there’s little to lose- either you find something better or your vendor freaks out enough to offer better pricing, it’s a win win!

Back to FreeSWITCH and Asterisk. So why would one consider using FreeSWITCH and why Asterisk? There’s no easy answer to this question because it truly depends on what you’re trying to do, and since both pieces of software offer near limitless possibilities, I’m left with only the time and patience to discuss just a few. Depending on what you’re trying to achieve, and what you need done, FreeSWITCH and Asterisk in my experience are typically used in a complementary fashion. Since FreeSWITCH was largely designed to satisfy the carrier space, perhaps its biggest advantage over Asterisk is in its distinctly different architecture. The general consensus amongst developers is that FreeSWITCH is capable of handling larger call loads on less hardware yet Asterisk has far more feature capabilities and is therefore perhaps the most suitable of the two in small to mid sized IP PBX deployments.

For anyone who has worked with Open Source VoIP software, they will know that in order to build the most stable VoIP system, you’ll probably end up using a collection of Open Source software (maybe even proprietary software as well). Our rule for production systems is only ever use the software that does the job the best, and if that means proprietary then so be it (most of the time there’s still a perfectly suitable OS alternative). This is the beauty of using software which is highly interoperable. One example in the design of an IP PBX would be using OpenSER for handling routing and load balancing, FreeSWITCH could be used as the IVR media gateway and conferencing, while Asterisk is left to handle the majority of the PBX features. Technically Asterisk could take care of all this but with a little more complexity, especially when handling thousands of simultaneous calls. I would argue that in the ~1000 extension space (still a fairly large system for Open Source VoIP standards) Asterisk may be all you need to build a complete IP PBX.

Asterisk has loads of features and although most work near flawlessly, there’s also a couple that don’t. One simple example is the call barge feature. I work with Polycom phones and wouldn’t have it any other way but the call barge feature for some reason or another does not work properly between Polycom and Asterisk. If anyone at Asterisk/Polycom is reading this, GIT-ER FIXED! So FreeSWITCH can actually be used in such an instance to provide this standard “key system” functionality.

For very specific applications like conferencing and media serving, FreeSWITCH is the clear winner.

As the above quote from Anders Brownsworth states, FreeSWITCH is also excellent for conferencing. In fact Junction Networks, see post, also uses FreeSWITCH for their conferencing service. One of the reasons why FreeSWITCH is so good at conferencing is that call conferencing is a very resource intensive activity. Each call added into a conference requires an exponential amount of computing resources. Although Asterisk handles conferencing quite well, FreeSWITCH can support more calls on less hardware.

I haven’t done much testing on the topic, but from what I hear people saying, typically a single Asterisk server has the capacity to handle ~250-300 simultaneous calls whereas FreeSWITCH users claim that with the same server ~1000 simultaneous calls can be handled. Remember that the purpose behind FreeSWITCH is…well… switching and call control, therefore most of the processes running FreeSWITCH aren’t all that resource intensive hence more calls/less hardware.

At the end of the day, it helps to know where you’re trying to go. If you plan to implement some element of Open Source telephony into your corporate communications infrastructure, you need to know exactly how the system must scale because scaling is one of the most important differentiators for which Open Source VoIP software to use and how you use it. If for example a large corporation decided to replace their entire Avaya infrastructure with Open Source VoIP software, the typical approach is start with a few small locations and eventually migrate everything into one large centrally managed yet geographically dispersed system. The difficult part about this approach is a single office might have 100 users, where Asterisk would be the software of choice, but a larger centrally managed system will likely be built for a much larger user population using a combination of the software I’ve already mentioned. You can’t expect that the lessons learned building a small Asterisk system will map well to a larger clustered system built with various OS VoIP software.

Highly skilled Open Source VoIP engineers are few and far between, my advice to anyone interested in OS VoIP is to either use a highly skilled OS engineering firm, or run your Linux engineers through weeks (if not months) of training. You might say, well what about a consultant? Consultants can be an excellent resource for projects like these, but my experience is that only 1 in 10 really know what they’re doing. There’s a lot of amateurs out there who might have plenty of Trixbox deployments under their belt but the second you say custom development or troubleshoot, they’re stuck with a finger up the bum, wide-eyed, and not a single clue as to what to do. I say all this because every week at SpecialAI some poor business gives me a call because their OS VoIP project got stuck where their consultants IQ ran out. Perhaps I’ll write an article about how to choose the right OS VoIP consultant/freelancer but the responsible move for most organizations with a stretched IT department is to spend the extra money and simply hire the right company with the right support infrastructure to build, deploy, and maintain mission critical OS VoIP systems.

A couple AsteriskNOW tutorial chapters

Aaron Rosenthal — Thu, 31 Jul 2008 17:21:06 +0000

I just got some tutorial chapters from PackT Publishing’s AsteriskNOW book by Nir Simionovich. Although most OS-VoIP readers aren’t developers, and the ones who are probably rarely use AsteriskNOW, I figured there’s no harm in putting these up even if only a few people find the chapters useful.

Here are the two chapters extracted from the PackT AsteriskNOW book:

Chapter 5 – Tentacles of the PBX — The Calling Rules Tables
Chapter 7 – “For Annoyance, Press 1″ — Voice Menus and IVR

It seems that AsteriskNOW has largely been neglected by Digium ever since they purchased Switchvox. AsteriskNOW was Digium’s first attempt to an easy to use administrative interface to the Asterisk software but once Switchvox came into the picture it seems their engineering resources went away from the AsteriskNOW UI and into the Switchvox UI. This move obviously makes business sense since Switchvox is a real revenue generator for Digium yet I hope they soon re-direct some focus towards the eventual development of a comprehensive OS UI for Asterisk.

To date, there still does not exist (to my knowledge) a suitable Open Source Asterisk UI which I’d feel comfortable implementing in a large scale IP PBX. There are certainly plenty of Asterisk UI flavors but most have been created as a licensed product. In a perfect Wallgreens world, Digium or some other knight in shining armor will engineer an open source UI for administration and a UI for users; one which is reliable regardless of scale or clustering, and one which is Open Source. This would certainly result in the eventual nail in the coffin for many proprietary IP PBX systems. So far the closest I’ve found is Druid by Voiceroute which is still a work in progress.