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

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

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

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.

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.

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?

If you are an employer or recruiter searching for specialists in Open Source VoIP technologies, then OS-VoIP.com invites you to participate in the launch of the OS-VoIP.com Job Board by submitting your Open Source VoIP openings for our job seekers.

If you are a job seeker with skillz in Open Source VoIP technologies then please visit the OS-VOIP.com Job Board regularly!

Good luck and happy hunting!

Take your standard Avaya Nortel Meridian PBX. A powerful system from an established vendor. The Meridian system provides Enterprise users PBX features that kick efficiency into high gear. These days, who can live without Find Me Follow Me, remote voicemail administration, hunt groups, and IVRs? But what about integration with your Enterprise Knowledge Base platform? Wouldn’t it be great to keep a directory of clients in a wiki format and then click on any phone number within this portal to initiate an outbound call from your IP Phone? A ginormous rolodex for everyone to share that’s never out-of-date and indexed automatically by the wiki search engine! Sorry Meridian, no dice.

Asterisk can. The most overlooked feature of Asterisk is the Asterisk Gateway Interface or AGI. AGIs function like CGIs on the web. They can be written in any scripting language (PERL, Python, Ruby, Bash, PHP, Java, etc.). Leveraging the power of an AGI and standard functions of Asterisk like “Dial” (guess what that feature does), you can write a script to query your MySQL or Oracle database of clients, retrieve a phone number and send the string of digits to Asterisk for processing. All Asterisk needs to know is which phone in your organization to call, and Asterisk immediately initiates a call to that phone. Once the phone is “answered”, Asterisk calls the client using the phone number retrieved by the AGI.

The way Asterisk has been engineered allows for an unprecedented level of creativity and under the supervision of an experienced engineer, Asterisk can literally do anything. Well, it won’t make your toast (but as soon as someone sticks a silicon wafer and NIC port into a toaster, I bet the “make toast” app will quickly follow), but it can be instructed using very simple scripts to do very nearly anything that takes place on the Internet.

Have you ever called a large company, like a bank or the telephone company, and when you “press 1 for Support” you are immediately greeted with a robot handler asking you for an account number? It always goes something like this, “Thank you for calling The Cable Company, please enter or say your account number so that we can better assist you.” You say, “123456789” and the IVR starts making some interesting alien bleeping noises. After a short pause, the robot handler speaks, “Thank you, you will now be transferred to a Customer Service representative. Your wait time is approximately a lot longer than you should have to wait.”

The waiting begins. Right as you’re about to hangup, an thick drawl floats over the wires, “Thank you for calling The Cable Company, may I have your account number please?”

What was the point of entering the number into the IVR in the first place? I gave my account number to the robotic handler! Didn’t the robot deliver the goods? Have you two ever spoken?!

Sigh. This is the proprietary PBX world. Most “turn-key” solutions sold through the last decade are feature-light and too complex to integrate with the majority of software applications currently used for business. The larger PBX solutions often do not come with an API for integrating your existing infrastructure with the features of your phone system. A company who purchases a solution from Panasonic for example does not have the option of writing a few scripts which take information from the caller via a key press and insert that information into the company’s database of Customer Information. The APIs that do exist for proprietary phone systems don’t give the consumer access to every command available within the PBX. As a result, integration is limited to click-to-call-type trickery which is to say proprietary phone systems are essentially only good for a parlor trick or two indulged by an audience ignorant of the unrealized potential inherent in Open Source VoIP.

Now let’s give Asterisk a chance. A company I know uses Asterisk for their primary phone system and has scripted an AGI to act as the Support IVR. Customers call into Support and they are prompted for their ticket number in order to help the agent quickly retrieve the open support case. It goes something like this:

“Thank you for calling our much more technically-savvy company. Please enter your ticket number to continue. If you do not have a ticket, please press 1.”

The customer enters their ticket number using a touch-tone phone.

“Thank you.” Alien bleeping. Ok so all phone systems do the alien bleeping thing. “We see that you last called on [Date] about this issue. Your call will be answered in the order in which it was received.”

A short wait…

“Hi John, this is Rob, I see you’re calling in about your VoIP account turn-up. Did you get the authentication credentials from the VoIP company as we discussed?”

Wait a tick. How did they know it was John, and wow the CSR has a great memory! Right? Wrong.

This moment of customer satisfaction is brought to you by AGI. Here’s how it works:

The customer calls in and enters his ticket id. The AGI takes the input and opens a MySQL database connection. Using a pre-fabricated MySQL statement with a variable configured for the ticket id, the customer’s name, phone number, address, system information, the number of IP Phones provisioned for the server, and a history of all other tickets for this customer are returned to the AGI. The AGI then re-writes the Caller ID number and replaces this value with the ticket number. Then the company uses a simple URL to open the ticket in the web-based ticketing system. The URL uses the Caller ID (which is now the ticket ID) as a variable to execute a simple search function. Because the AGI passes the ticket ID, the ticketing system can quickly load all of the aforementioned information on the CSR’s monitor automatically. As the CSR accepts the call, a web browser opens displaying who is calling and why. This technology provides two major benefits: the company saves time on every ticket, this adds up to hours in the course of a year (and time is money); and the CSR looks like a hero in the eyes of the customer, this builds brand-loyalty and increases customer happiness.

The AGI I just described took one afternoon to completely implement. One afternoon. What couldn’t you do with one afternoon and your Meridian telephony system? You might get as far as a support call for help establishing your hunt group? You certainly aren’t going to find an API to make calls to your customer database for you. And even systems that allow custom integration typically don’t support scripting languages like PERL.

Yes, I admit… if you’ve ever called your bank or another Fortune company, you’re probably saying “well the computer voice does ask for my account information and the CSR does have it once I’m finally transfered”. Yes, there are plenty of phone systems which can provide this level of integration, but because they cost so much money and are so complex, often requireing millions of dollars, these systems are usually reserved for big corporations and massive call centers. Asterisk on the other hand can provide the same awesome functionality to any business serious about their phone system regardless of size- big or small.

Creativity gives Asterisk a distinct advantage that proprietary products cannot provide. Will not provide might be more accurate. If you could start writing code to realize a telephony idea rolling around your imagination, would you need the team of highly paid engineers at Avaya, Cisco, Nortel? You most certainly would not. And these proprietary vendors know it.

Let’s take a walk into our imagination and look at some other business needs that AGI can solve.

Predictive Dialers – so many outbound sales organizations require the ole predictive dialer. Your company gets hundreds of thousands of hot prospects that need to be called right away. The predictive dialer needs to be able to get a number from a database, mark the number as “in progress”, dial the number, determine if a person answers, if the number is disconnected, if an answering machine picks up, etc., then mark the number in the database with a new message indicating the number should not be tried again, and finally deliver the customer into a queue where a live operator closes the deal.

Predictive dialers are very expensive off the shelf. A company I know of called GCInfoTech has written a predictive dialer for Asterisk via AGI at tens of thousands of dollars less than off-the-shelf products.

Account Information – this could be anything from baking, to investing, to order status. When you call your bank to check your balance or transfer funds, the telephony application the bank uses checks a database just like our AGI example above. The telephony application the bank uses is proprietary and costs a lot of money. AGI is free to the determined programmer, or mar less than a proprietary solution even for a company looking to purchase a turn-key solution from an Asterisk professional.

Text-to-speech – while text-to-speech is a technology unto itself, it needs some text to convert into speech. Your AGI might use a wiki platform to store information on topics important to your customers. I know of a company in the Health Services industry that informs patients about diseases, medications, and news related to common illnesses. This company leverages a wiki platform and text-to-speech in order to write up information as it is received and posts it online (blog-esque). Customers call in and choose a topic from the IVR. Via AGI, the wiki article posted online is converted into spoken word automatically. Before Asterisk, the company had to record voice prompts for every new piece of information offered to customers. This required an enormous database of sound files and kept administrators busy for hours checking and re-checking file naming conventions, monitoring the health of the SAN, and performing database maintenance.

Asterisk matches up very well against many of the big names in PBX technology: Avaya, Nortel, Cisco. Feature for feature, Asterisk supports almost everything offered by these vendors. When companies are weighing the pros and cons of which PBX to purchase, the tale of the feature tape doesn’t provide a clear-cut winner. Then you factor in “creativity” boosting Asterisk far above the competition. I’ll be the first to admit that Open Source software in the enterprise comes with a special set of challenges – neither more nor less challenging than proprietary software in reality; but proprietary software cannot ever compete with the potential inherent in Open Source. AGI flings open the doors of possibility. How about writing in and telling us a few of your own ideas?

By Tyler Merritt

What, exactly, is VoIP? VoIP stands for Voice-over-Internet-Protocol which means I can make phone calls using my Internet connection right? Sure, this is an accurate albeit airy definition. “Internet Protocol” comes in a variety of flavors. The most popular mechanism for VoIP currently is the SIP protocol. However, VoIP can use other protocols like H.323, Skinny (SCCP), GSM, ILBC, Jabber, and a bunch of other proprietary types of VoIP like chatting on XBox Live! or using a voice chat application like Roger Wilco on your PC! All of these applications allow you to use the Internet to have a verbal conversation with another person or even a group of other people. Many chat clients have added support in recent years for audio conversations – iChat, MSN, Yahoo! Messenger, Google Talk, and many more. “VoIP” is a single term with a limitless number of accurate applications. From a business perspective, VoIP often applies to Hosted solutions from companies like Packet 8; VoIP equally applies to premise IP PBX solutions from companies like Digium with their switchvox appliance; and VoIP even applies to Hybrid offerings from companies like Fonality with their Hybrid-Hosted IP PBX offering.

In consideration of the space alloted to this no-holds-barred VoIP revelation, let’s look specifically at hosted VoIP offerings (Vonage, Skype, Cbeyond, XO, Teliax, Broadvoice, Bandwidth.com, among others, all offer ‘hosted’ VoIP services).

VoIP reminds me of the story of Doctor Jekell and Mr. Hyde. In the lab, VoIP is an incredible technology with countless potential uses far beyond those implemented by most modern Providers. In the lab, calling costs return null and quality is arguably superior to the traditional PSTN which has been long plagued by the laws of physics directing analog wave forms towards oblivion with each mile of copper traveled. In the lab, VoIP setup is so simple a child who knows how to type can enter in the authorization credentials for a new account and service commences almost instantly. VoIP is a healing technology that can redirect hundreds or even thousands of dollars a month back into the business’ coffers. In the lab.

But….VoIP on the streets is a ruffian, a hoodlum causing a ruckus in nearly every Local Area Network it touches. Problems arise when the IT department must punch yet another hole in an already teetering firewall and provide a special lane for this new special traffic. VoIP the destroyer.

Now, the position of Devil’s Advocate carries with it a measure of responsibility to own up to ones accusations. I’ve written that VoIP has its dirty side, maybe even an evil side. I didn’t write that SIP is evil, or IAX is evil, or even heaven forbid I write that Skype is evil. VoIP is evil principally because it doesn’t know what it wants to become when it grows up. VoIP is not a standard. SIP is a standard. G711 is a standard. No one controls VoIP.

Anyone over half a century old remembers when the four major Baby Belcos dominated the American telephony landscape. They each created their own standards for interoperability and charged the other major players fees to run calls on their copper. This made Long Distance a cash cow for many years for these companies. But they grew and expanded and ran into each other’s territory quickly. The complexity of making sure one network’s proprietary standards interoperated correctly with all the other networks became a nightmare. Companies consolidated and eventually single standards emerged and carriers started making money off features and services like 3-way calling and Caller ID.

VoIP is currently a youngster stretching its wings in the wide, wide world of free market. Which standard will win? SIP? IAX2? GSM? Nobody knows, and woe to the business owner who dives into a single technology headfirst without first understanding some of the basic ground rules. Luckily, I’m going to point out some of the more obvious pitfalls in order to better prepare the uninitiated for the trails of VoIP. Please don’t misunderstand; I’m an industry insider working for a leading IP PBX vendor. I live VoIP. VoIP can and will save you money, time, and trouble. But you have to know how to approach it, or it will rear back and bite you in the wallet. The first rule: VoIP is currently uncontrollable, so vett your Provider and PBX vendor carefully.

As any IT manager knows, implementing fundamental network features like QoS, CoS, VLANs, and ACLs helps the LAN operate efficiently and improve the lives of all employees. VoIP requires many of these same standards to prioritize VoIP packets above all other types of traffic. VoIP is greedy for bandwidth, pushing smaller packets through the same CAT5 at a much higher rate of speed. I always use the same analogy: “regular” Internet activity like surfing the web is comparable to a softball pitcher’s vocation. A large chunk flies from the pitcher’s hand to the catcher’s mitt, and so too are HTTP packets received by a host from a server. VoIP resembles a machine gunner standing on that same pitcher’s mound shooting at a target. The same distance is covered in the same amount of time, but the payload in terms of bullets delivered is much higher, though each bullet is many times smaller than the softball.

Modern LANs are starting to adopt this new start-up technology into their standard firmware and basic rule sets. But existing infrastructure, even a few years old, may require a complete overhaul to effectively welcome VoIP. Up until the advent of VoIP, the Internet has largely been a TCP club. But VoIP is quickly changing the landscape with its insistence on bringing UDP to the table in a big way. While a well-managed LAN can easily accommodate this UDP influx, what about the WAN? Who controls that?

The small to medium business owner doesn’t have any influence over the wilds of the WAN. Even the most airtight iptables and QoS policies don’t translate at all once packets start leaving the safety and stability of the LAN. ISPs provide no control whatsoever to standard business DSL or Cable bandwidth circuits. In perfect democratic equality, the DSL or Cable modem treats every packet in with the exact same priority. First come, first served. But voice conversations don’t work like that. There can be no delays or interruptions when a person is speaking naturally. And isn’t the conversation you’re having over the phone more important than whatever YouTube video is streaming on your monitor?

ISPs are starting to offer circuits that account for our special child VoIP. But another snare springs from the Internet – what happens when your VoIP traffic travels from one ISP to another?! What if the two ISPs don’t implement the same QoS rules for VoIP packets?

There is no control. You the consumer control your business’ LAN and that’s about it. The rest is up to the ISP, the VoIP provider, and even the phone company when you call a regular land-line or cellular phone!
So what can be done to make sure this fascinating technology has the proper environment to share its many blessings? Here are some simple rules to follow when shopping for VoIP:

Ask the provider detailed questions about their backbone.
Do they host their servers in a reputable data center? Do they get their bandwidth from a well-known provider like Level 3? A friend of mine thought it would be neat to start a VoIP company and began offering services through machines hosted in his garage. He did some good business for awhile, but his company didn’t last long.

Make sure your VoIP service requires authentication.
This point may seem like a no-brainer, but many VoIP providers do not require registration from the customer, making toll fraud incredibly easy for even amateur hackers. Authentication strings that use a hash in place of a clear-text password provide required security.

Find out what kind of VoIP architecture the provider uses.
Is their network built on a proprietary solution like Broadsoft or do they make use of Open Source VoIP solutions like Asterisk? Proprietary may turn out products with fewer initial bugs and open lines of communications to the developer via a support team, but Open Source means a much larger community of devoted followers hammering away at the application out of sheer pride and commitment to excellence. Asterisk is the most widely deployed Open Source telephony platform in the world precisely because so many people have contributed hours upon hours towards development and stability.

Figure out the DTMF type up front!
With analog lines and PRIs, DTMF was never really a consideration. VoIP companies have choices like rfc2833, inband, and info – and some companies use a different DTMF setting for inbound calls and outbound calls! If customers can reach your Auto Attendant but can’t dial an extension because key presses aren’t recognized, you might as well not have a phone system at all. This one is the Achilles Heel for almost every company I know.

Make sure your network supports QoS.
It cannot be stated enough that VoIP traffic on your network needs an all-access pass to the HOV lane. Because VoIP uses UDP instead of TCP, there are no second chances for these packets. They need to arrive in order, unchanged every time. If your network equipment does not support QoS, simple things like sending an email when someone is on the phone will have a noticeable effect to the conversation. Some customers may detect “clipping” or “clicking” on the line however briefly. A good QoS policy protecting VoIP easily soothes its greedy need for dedicated bandwidth. VoIP does not like to share.

By following these rules, you’ll find you’re much better prepared to welcome VoIP into your LAN. You cannot exercise control over every avenue VoIP travels, but taking care to provide the proper environment within your LAN goes a long way to guaranteeing quality from your phone system. Selecting your provider with care ensures that when VoIP leaves the LAN, it is treated with respect by the ISP and VoIP provider. You definitely cannot control every bit of the Internet, but you can test the waters methodically and enjoy this technology and all the powerful features it has to offer.

Written by Tyler Merritt

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.