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?

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.

Bluetooth is the primary technology that makes all this possible since most cell phones these days have bluetooth, plus it’s the perfect proximity based technology that just happen to be in our cell phones; ideal for presence. Here’s an article by Little Nerds which discusses how to get presence up and running specifically with Asterisk.

To make this work in a much larger office, and to have it work for an entire user population, I think it would be a great idea for handset manufacturers to start incorporating bluetooth into their phones for this very purpose. This way my desk phone is what recognizes my presence and the IP PBX could route calls accordingly even if I were in the office but not at my desk. I wonder if you could combine presence with extension mobility… that might be excessive!

Has anyone gotten presence to work with Asterisk using something other than Bluetooth?

Just today I stumbled on this article written by Flavio E. Goncalves which compares Asterisk and OpenSER. It’s a short and concise article worth sharing with you all. Here’s a few snippets.

“If you work with IP telephony, it’s quite possible that you have not heard about OpenSER, but certainly you must have heard about Asterisk. Well, I love a polemic headline and I have seen this question asked in the forums many times. So, I will dare to compare these two very popular softwares dedicated to the VoIP market. The idea here is not to show you which one is the best, but mainly how they are different from each other. Below is a comparison topic by topic.”

“Asterisk is a Back to Back User Agent (B2BUA), while OpenSER is a Session Initiation Protocol (SIP) Proxy. This makes all the difference between them. The SIP proxy architecture is faster than a B2BUA because it deals only with signaling. On the other hand, the B2BUA architecture, even being slower, handles the media and it is capable of several services not available in a SIP proxy such as Codec Translation (that is G729<->G.711), Protocol Translation (SIP<->H323), and services related to media such as IVR, Queuing, Text to Speech, and Voice Recognition.”

Read the rest of the story here