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 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.