Freeswitch - Asterisk - The futur of telephony ?
What is the future of Opensource telephony softwares ?
According to the actual state and evolution of Asterisk, i do not think that this kind of project could have a far future, except perhaps for hobby or as a template for an eventual fork. Asterisk is like a full time beta software. It does not have enough reliability, enough power (scalabilty and call processing power), and enough smartness and serious in its developpement.
In a few years we will say : did you remember when we were fighting with Asterisk ? It was a funny thing isn't it ?
Asterisk is good, for running Digium cards. Not really more. This market will slow down as soon as the telephony network will become mostly full IP.
We can do really better and Freeswitch is a good example of that even if not perfect. The future of telephony is not the TDM / SS7 world. It is the full IP (and IPv6) world. Asterisk is not IPv6 compliant. It is quite funny to see this today. ( i know, there is an IPv6 fork ).
In this regard, projects like Freeswitch are interesting because they do support a really higher full IP call processing power. They do support more seriously full IP technologies like HD voice and VoIP trunks and are not dependent from a TDM hardware vendor.
I will give here some important warnings :
1) Nature of the telephony world
The telephone software world is not like the data software world.
Telephone experts cannot deal with a moving target like Asterisk is. A company keep his telephony system often during 10, 15 or even 20 years and needs to have a clear migration path during this period. With Asterisk, each year give a new beta software version where most older applications will fails.
The Opensource telephony project of the future will need to take this into consideration, or it will dye.
API changes will need to be carefully studied, so that all the precedent developpements keep working on new versions. Like it is the case for the X86 instruction set in the computer world.
Dialplan changes should be even more conservative. Keeping an absolute compatibility with precedent versions is mandatory. The diaplan need to be simple to understand and program. the xml structure is good perhaps for a data software programmer, but for a telephone guy, it is quite cumbersome.
The Asterisk diaplan is simple to learn and program. That's a good point.
If no opensource telephony switch software take this into consideration, then the future of the IP world telephony software will be a commercial software, based on all the good work made by the opensource telephony community. This is not tolerable for all the community developpers who have spent so much time on the initial projects.
In this regard, i hope that projects like Freeswitch or like recent Asterisk forks will rise to a higher grade, to really become a professionaly usable alternative. User interface projects like FreePBX are very important as well for the end user. They should follow the same road, giving to the real users all the good things of the past, before to give toys for Geeks.
Telephony software world is a slow but serious world...
2) Reliability and serious redundancy
In the telephony world, things need to be perfectly reliable. Audio quality need to be perfect. No alternatives. World scaling and standards needs to be fully respected.
Because the futur of telephony is the IP world a special care must be taken with buffering, intelligent codec negociation, bandwith reservation and multiple trunk registrations for redundancy (true redundancy, not only outbound calls).
Asterisk almost completely fails here, forgetting to take into account those problems, at least for the lastest three points.
I've not seen any other projects taking into account the latest 2 points, bandwith control - reservation and redundancy problems.
Those tasks are perfectly managed in the traditional SS7 telephony world. This should be the same in the IP world.
I think that a telephony switch engine should be able to decide himself if a call (inbound or outbound) can be accepted according to the available WAN bandwith and requested codec. Eventually it should be able to choose a highly compressed codec if the bandwith become too restricted and the call cannot be rejected for urgency reasons. It should even be able to drop an active call to allow for an urgeny call to go through the trunk.
3) Providers
For the success of full IP telephony, a big effort needs to be done by VoIP providers and IP links providers. The best example is certainly the need for a consistent ANI and CID through providers. This is not the case today. When Caller IDs are correctly transmistted, very often the CID name disappear, and most often the ANI is not taken into consideration. This is a big problem for urgency services and law conformity.
All this is not serious. VoIP today is traditional telephony less basic functions and less the quality that everyone needs every day.
Please sir providers and sir programmers, do not reinvent the wheel. Bought a few books about SS7 and learn traditionnal telephony. Then do the same with VoIP. All the technology is here to get IP telephony fully working though the world. No need for advanced and heavy programming. Just smart programming and smart ideas.
After you will have succeeded in this, then you will be able to add advanced things for geeks. Not before.
Today full IP telephony is something like a dragster engine inside a consumer grade vehicule.
ENUM needs to be fully deployed as well, to simplify full IP telephony, and more importantly to remove all the bad things that happens to calls when they go through VoIP providers.
For this to work with a good audio quality, the IP Internet network need to be modified to support QOS through each country and ideally through the world.
Then, we'll have the future of telephony. This is not as difficult, just something serious where commercial considerations need to be kept away, specially in the provider world. ENUM is the door to bypass commercial VoIP providers brakes, forcing IP links providers to give the quality we need.
Only the Opensource community has the power to do this.
Olivier ADLER
FRANCE IP
According to the actual state and evolution of Asterisk, i do not think that this kind of project could have a far future, except perhaps for hobby or as a template for an eventual fork. Asterisk is like a full time beta software. It does not have enough reliability, enough power (scalabilty and call processing power), and enough smartness and serious in its developpement.
In a few years we will say : did you remember when we were fighting with Asterisk ? It was a funny thing isn't it ?
Asterisk is good, for running Digium cards. Not really more. This market will slow down as soon as the telephony network will become mostly full IP.
We can do really better and Freeswitch is a good example of that even if not perfect. The future of telephony is not the TDM / SS7 world. It is the full IP (and IPv6) world. Asterisk is not IPv6 compliant. It is quite funny to see this today. ( i know, there is an IPv6 fork ).
In this regard, projects like Freeswitch are interesting because they do support a really higher full IP call processing power. They do support more seriously full IP technologies like HD voice and VoIP trunks and are not dependent from a TDM hardware vendor.
I will give here some important warnings :
1) Nature of the telephony world
The telephone software world is not like the data software world.
Telephone experts cannot deal with a moving target like Asterisk is. A company keep his telephony system often during 10, 15 or even 20 years and needs to have a clear migration path during this period. With Asterisk, each year give a new beta software version where most older applications will fails.
The Opensource telephony project of the future will need to take this into consideration, or it will dye.
API changes will need to be carefully studied, so that all the precedent developpements keep working on new versions. Like it is the case for the X86 instruction set in the computer world.
Dialplan changes should be even more conservative. Keeping an absolute compatibility with precedent versions is mandatory. The diaplan need to be simple to understand and program. the xml structure is good perhaps for a data software programmer, but for a telephone guy, it is quite cumbersome.
The Asterisk diaplan is simple to learn and program. That's a good point.
If no opensource telephony switch software take this into consideration, then the future of the IP world telephony software will be a commercial software, based on all the good work made by the opensource telephony community. This is not tolerable for all the community developpers who have spent so much time on the initial projects.
In this regard, i hope that projects like Freeswitch or like recent Asterisk forks will rise to a higher grade, to really become a professionaly usable alternative. User interface projects like FreePBX are very important as well for the end user. They should follow the same road, giving to the real users all the good things of the past, before to give toys for Geeks.
Telephony software world is a slow but serious world...
2) Reliability and serious redundancy
In the telephony world, things need to be perfectly reliable. Audio quality need to be perfect. No alternatives. World scaling and standards needs to be fully respected.
Because the futur of telephony is the IP world a special care must be taken with buffering, intelligent codec negociation, bandwith reservation and multiple trunk registrations for redundancy (true redundancy, not only outbound calls).
Asterisk almost completely fails here, forgetting to take into account those problems, at least for the lastest three points.
I've not seen any other projects taking into account the latest 2 points, bandwith control - reservation and redundancy problems.
Those tasks are perfectly managed in the traditional SS7 telephony world. This should be the same in the IP world.
I think that a telephony switch engine should be able to decide himself if a call (inbound or outbound) can be accepted according to the available WAN bandwith and requested codec. Eventually it should be able to choose a highly compressed codec if the bandwith become too restricted and the call cannot be rejected for urgency reasons. It should even be able to drop an active call to allow for an urgeny call to go through the trunk.
3) Providers
For the success of full IP telephony, a big effort needs to be done by VoIP providers and IP links providers. The best example is certainly the need for a consistent ANI and CID through providers. This is not the case today. When Caller IDs are correctly transmistted, very often the CID name disappear, and most often the ANI is not taken into consideration. This is a big problem for urgency services and law conformity.
All this is not serious. VoIP today is traditional telephony less basic functions and less the quality that everyone needs every day.
Please sir providers and sir programmers, do not reinvent the wheel. Bought a few books about SS7 and learn traditionnal telephony. Then do the same with VoIP. All the technology is here to get IP telephony fully working though the world. No need for advanced and heavy programming. Just smart programming and smart ideas.
After you will have succeeded in this, then you will be able to add advanced things for geeks. Not before.
Today full IP telephony is something like a dragster engine inside a consumer grade vehicule.
ENUM needs to be fully deployed as well, to simplify full IP telephony, and more importantly to remove all the bad things that happens to calls when they go through VoIP providers.
For this to work with a good audio quality, the IP Internet network need to be modified to support QOS through each country and ideally through the world.
Then, we'll have the future of telephony. This is not as difficult, just something serious where commercial considerations need to be kept away, specially in the provider world. ENUM is the door to bypass commercial VoIP providers brakes, forcing IP links providers to give the quality we need.
Only the Opensource community has the power to do this.
Olivier ADLER
FRANCE IP
Comments