Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
May the source be with you, but remember the KISS principle ;-)
Skepticism and critical thinking is not panacea, but can help to understand the world better


News Recommended Links SIP trunks providers SIP VoIP Protocols Basics SIP Phones Softphones
Asterisk Trixbox FreePBX FreeSwitch      
Magic jack Google Voice Skype VOIP security Phone Fraud Humor Etc

Asterisk is probably the most popular open source VOIP PBX solution. Recently the number of Asterisk users has been increasing dramatically. FreeSwitch also grows in popularity and is used in pretty large deployments. 

Asterisk is the open source IP PBX developed by Mark Spencer. Provides voicemail, conferencing, interactive voice modules and call distribution among its basic features. There are several important open source projects based on Asterisk. Among them

Several sites such as provides configuration guides, tutorials, forums and some interesting pieces of source codes which you can implement in your Asterisk server at no cost.

Site  provides step by step tutorials and a list or very interesting list of 100 projects for beginners and advanced users.          


Old News

[Sep 14, 2009] Wide Open VoIP Top 50 Open Source VoIP Apps Virtual Hosting Blog

For many businesses, open source VoIP programs and apps offer a great way to save thousands of dollars every year in telephony costs. Better yet, open source programs are fully customizable to a business' specific needs, making them a popular solution that often just can't be beat. This popularity hasn't just helped business, but has also driven many open source programs to the forefront of their industry. In fact, it has been speculated that open source VoIP solutions could surpass the popularity of the ubiquitous desktop solution Linux. Here are a few of the open source programs and developers out there that have had loads of success as VoIP and open source solutions for it become more and more common in businesses around the world.

Asterisk 1.6 Dinosaur or Ostrich… It Really Doesn't Matter

April 16, 2008 | Nerd Vittles


Digium's point of view is a very dangerous one. The thing is that Asterisk is pretty crappy software (pieces mysteriously break than start working again in the next release, it's happened to me a few times) but the third party service and software ecosystem around it are better than anything else.

Digium has to realize this and do anything to keep third party developers and maintainers happy. If not, they won't stand a chance in future competition from big brands above as well as from smaller projects such as freeswitch below.


Quick comment: this isn't just a "Digium thing" in the way upgrades work; this is typically how software development goes in all organizations. Major version number changes mean API changes. That's just how the world works. If you couldn't change an API, then you wouldn't be able to grow and expand the feature set in the software, or sometimes even fix bugs, or increase reliability and scalability.

I have not heard about any fixed date or time frame for EOL'ing Asterisk 1.4. Since a lot of people are still running 1.2, I would imagine 1.4 will be with us for a long time yet (certainly more than a year).

The 1.6 branch has come out, is in beta mode, and I'm not sure what all the hubbub is about in third party incompatibilities. All major version upgrades are going to have things change in them that you couldn't otherwise do, and thus third party applications are going to need to keep pace - and it's not like you HAVE to run 1.6 in production (in fact, you shouldn't… it's not even out of beta yet).

In addition, the 1.6 branch is going to use a different release methodology, which is really the main reason a 1.6 beta is even out in the first place. This does not indicate 1.4 is going EOL anytime soon. Digium's Business Edition C.1.x software was only released around January, and I doubt there is any rush to deprecate that piece of work.

You're probably going to have 1.4 and 1.6 in lockstep for quite some time. The difference between 1.4 and 1.6 is quite a bit less than the difference between 1.2 and 1.4. The reason for 1.6 is that since you CAN'T just release software every year and EOL the existing software, then that means you have to wait 2+ years before you can even start using the new features. Some people can't wait that long, so you have two paths available to you now. 1.6 will allow new features to go in at each minor version release (this means 1.6.x, where 'x' is the minor version, and 6 is the major version - this is significant). So now we have two different methodologies.

A branch that only receives bug fixes and security fixes (1.4), and a branch that receives bug fixes, security fixes, and is allowed to implement new features (this follows the same time of release strategy as the Linux kernel - this is not a new concept). Digium has now also started using release candidates before creating a new release (as per the communities request), so you have the ability to test for any bugs that may have been introduced before the full released is put out for public consumption.

If you need to run 1.4, then go ahead, nothing is going to stop you from doing that, and it's not going away anytime soon. If you need the latest and greatest, or there is some new feature you absolutely must run in production, then you can run a 1.6 machine (when it stabilizes and comes out of beta and release candidate status) with just the feature you absolutely need in a stripped down version, or after extensive testing, then you could put it into production.

I personally think Digium is doing the "Right Thing(tm)" here and giving us choice, and isn't that what this is all about?


Despite the extra work it creates, I'm with Digium on this. It's often impossible to add flexibility or improve performance whilst maintaining API compatibility. The reason for the majority of API changes is to address short-sighted decisions in the original design; backwards compatibilty enforces perpetuation of the poor choice and a clean break must be made at some point. The re-plumbing work to which Jared refers is long overdue and, as he intimates, is necessary to provide the enterprise-grade platform for which you are all clamouring.

Whilst a simple upgrade tool for syntax in extensions.{conf|ael} might save a few folks a few minutes, I don't think that's where the bulk of this problem lies. We'd all love to have tool to automatically fix all the AGI/AMI code out there, written in PHP, Perl, C, etc, but it's impossible to do algorithmically. That said, I believe it would be possible to add a compatibility shim to PHPAGI, for instance, to allow most if not all existing PHP AGI scripts to run without modification.

The suggestion that Digium are responsible for fixing everyone else's code is simply ludicrous. As Jared explained, many of the devs can't legally touch much of the code that will need to be fixed. Even if they could I doubt they'd want to; fixing code with which you're not familiar is fraught with difficulties. It's even less appealing when you consider that much AGI code is crufty nonsense written by amateurs. The logical conclusion of this argument is that Microsoft must be similarly charged with fixing every third-party application broken by a service pack, and the Linux/glibc folks must cease scheduled development and spend the rest of eternity fixing all the userspace regressions just assigned to them by downstream!

I'm not sure how you reached your conclusion that Digium have their head in the sand based on Jared's response. You had the opportunity to shape the development of the areas of v1.6 which displease you. I'm afraid it was you with your head in the sand, ignorant of all the work happening in public view for all to see, discuss and even influence. If Digium's track-record with Asterisk v1.2 is anything to go by, you've a long time yet before v1.4 will be unmaintained. There's plenty of time to adapt and to test before you need to look at using v1.6 in production.

Please stop criticising the Asterisk devs for doing necessary work. You may not see it, but they do have our best interests in mind. The benefits of a more maintainable, better architected and more consistent Asterisk codebase far outweigh any short-term heartache during the transition.

[WM: There's a significant difference in saying that "Digium [is] responsible for fixing everyone else's code" and saying that "Digium has responsibility for not breaking everyone else's code." If you reread the article, I think you'll find that I suggested the latter. As for a conversion utility saving a few folks a few minutes, I've spent the better part of six months cleaning up the carnage in dozens of applications that was directly caused by the needless syntax obsolescence imposed in Asterisk 1.4. And for what? I provided a good example in the article that broke virtually every dialplan. Suggesting that such changes were necessary to "improve the engine" is pure B.S. Funny you'd mention Microsoft. I wrote a shareware database management system (WAMPUM) in 1985 for DOS that still runs just fine under Windows XP and Vista.

In fact, I regularly hear from folks that still are using it… almost two decades later! Maybe that's the reason Microsoft is still around while Lotus 1-2-3 (that owned 95% of the spreadsheet market at one point) is now just a blip in the history books.

If you recall, Lotus developers came up with the brilliant idea to change much of 1-2-3's spreadsheet syntax. It gave everyone the perfect opportunity to switch to Excel.]

Using trixbox CE as a SIP Gateway

Jun 05, 2009 | VoipStore
If you have a need to have multiple PBX systems running and you want them all to make and receive calls, you will run into a major problem with that because of NAT issues and port forwarding limitations. In this article, I will explain how to use a trixbox CE system as a front-end gateway that will manage the trunks to the SIP providers and forward calls to the different PBX systems as well as allow the PBX systems to dial out through the trixbox CE system.

Besides testing different PBX platforms like I do, why might you want to do a setup like this? There are several reasons I can think of:

While this is only showing a SIP provider to multiple PBX's, the concept can also be applied to a SIP trunk coming into the gateway and then a PRI connection to a legacy PBX that doesn't support SIP trunks, thus allowing a non-IP PBX system to use VoIP trunks.

We won't go into the setup of the actual SIP trunk into the trixbox CE (FreePBX) system as that is dependant upon the provider and should be pretty straightforward. What we will need to do is create trunks from the other PBX systems into the trixbox CE box in order to route calls

Voice Marketing Vendors | Voice Broadcasting |

10 Best VoIP Web Hosts Compared - 2009 WHDb

Dot5Hosting: Home and commercial users can tap a VoIP system into Dot5Hosting, as this company's servers are linked to the Internet via fiber-optic connections that span more than seven diverse backbones and well-known providers such as Congent, So net and Time Warner. Their systems include a high power UPS generator electrical backup, closed circuit monitoring and redundant air-conditioning systems. But that's not the only redundancy they boast - they utilize Dell and IBM servers which run Dual Intel Xeon processors with 2GB of DDR-RAM and SCSI hard drives with RAID-1 redundancy. Current packages start at $3.95 per month.

Asterisk Voip hosting - Web Hosting Talk


We provide VoIP service to business customers and do so with asterisk, we have load balanced dell servers with P4 2.8Ghz HT processors and during peak usage each node is handling around 100-120 concurrent calls with almost no load.

so as others have said, you don't need much in the way of hardware, figure 30Mhz of CPU per call.

Login, Inc. - Data Solutions Provider

Recommended Links

Totek - Asterisk VoIP (SIP) News & Technology Source - Home


The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2018 by Dr. Nikolai Bezroukov. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case is down you can use the at


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019