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

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?

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

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.

Every single CIO/CTO on this planet should use this list as a go-to point whenever in search of a particular software solution.

There are still people in this world who think Open Source is a load of rubbish and that it’ll never catch on and will never displace larger proprietary solutions. Although this is true for PLENTY of open source projects, that is NOT the case with most of the established open source solutions listed in this blog. It is true, I’ll admit, the open source software below may not perfectly fit your organizational needs, it may not be sexy, and it could require a more technical IT department to implement…… although, at the same time it may not be any of these. But, what Open Source will almost ALWAYS be is more flexible and more cost effective.

When evaluating software solutions, most companies like to put together a selection of at least 3 possible options; 3 software solutions selected from the many, all 3 of which will ultimately be pitted against one another in a battle to the death within a stadium full of IT managers, C-level executives, and vendors. I’ve always thought companies should build a boxing ring in their office just to let potential vendors duke it out with the winner getting the contract. Just think, this probably wasn’t too far from the truth a few hundred years ago plus there would have been the whole impending death thing. But seriously, although this post isn’t really dedicated to OS VoIP (yes Asterisk did come out on top for VoIP), I do want to encourage technology executives to search for possible Open Source solutions whenever evaluating software for your company. If you turn a blind eye to Open Source, you just might be missing out on something that could save your IT budget millions and you’d never know if you didn’t look. So check these out and it’ll be like winning the lottery should you find an Open Source application that DOES meet your technology requirements.

The BOSSIE wards are divided up into these 8 categories. And the winners are…..

Collaboration

Social networking: Elgg
Wiki: Media Wiki
Mail and Calendar: Scalix
Remote Control: VNC & Chicken of the VNC
Blog Publishing: WordPress

Developer Tools

Object Database: Db40
Version Control: Git
Web Client Library: HttpClient
Parallel Programming: Intel Threaded Building Blocks
Business rule management system: JBoss Drools
Rich Internet Applications: Open Flex
JavaScript Framework: Prototype
Web Services Test: soapUI

Enterprise Applications

Content Management: Alfresco
Enterprise Resource Planning: Compiere
Project Management: dotProject
Application Monitoring: Hyperic HQ
Business Process Management: Intalio BPM
Enterprise Portal: Liferay Portal
e-Commerce: Magento eCommerce
Business Intelligence: Pentaho Open BI Suite
Customer Relationship Management: SugarCRM
Reporting: Jasper Reports

Networking

IP Telephony: Asterisk
Log File Analyzer: AWStats
Wifi Network Scanner: InSSIDer
Server Monitoring: Nagios
Wireless Network Interface: NDISwrapper
Router, Firewall, and VPN: Vyatta
VoIP Monitoring: WireShark
Network Monitoring: Zenoss Core

Platforms and Middleware

Server Operating System: CentOS
Enterprise Service Bus: JBoss ESB
Database: MySQL
MySQL Administration: phpMy Admin
Small-Footprint OS: Puppy Linux
Data Migration: Jitterbit
Desktop Operating System: Ubuntu
Desktop Virtualization: VirtualBox
Server Virtualization: Xen

Productivity Applications

Sound Editing: Audacity
3D Modeling: Blender
Web Browser: Firefox
Image Editing: Gimp
Productivity Suite: OpenOffice.org
PDF Creation: PDFCreator

Security

Penetration Toolkit: Metasploit Framework
Windows Password Cracker: Ophcrack
Network Firewall: SmoothWall Express
Network Intrusion Detection: Snort with BASE
Security Log Analysis: Splunk
Disk Encryption: TrueCrypt
Gateway Security: Untangle Gateway Platform

Storage

Network Backup: Amanda
Storage Server: Free NAS
Online Backup: Free Online Backup
File Management: WinMerge
Disk Monitoring: smartmontools
Storage Administration: StorageIM

Well isn’t that a nice long list of Open Source software. Yes there’s a few there which are little babies and still have plenty of maturing to do, but others in this list are already mature and reputable OS projects like Asterisk (of course), SugarCRM, OpenOffice.org, MySQL, CentOS, and many others.

If I could add anything else to this list, I think Zimbra-Collaboration should get a mention along with Teamwork for project management.