JUST RELEASED: Visit the Incredible PBX Wiki
In our last column, we lamented the fact that Asterisk® 1.6 development seemed to be on a collision course with the dinosaurs because of developer insistence on deprecating and removing commands from the application programming interface (API) in the name of technology enhancement. The problem this poses is that applications and dialplans written for previous versions of Asterisk no longer function even though the code is barely a year old. In the corporate and government sectors, this would mean major, costly (annual) rewrites of code just to keep a functioning phone system. And, as we noted, these organizations buy phone systems to last a decade so such a development strategy would all but rule out use of Asterisk in the Fortune 500, medical, and government sectors.
Today we want to share the Digium® response and address some of the new issues that have been raised. For those of you that haven't met him, Jared Smith, who co-authored the terrific Asterisk: The Future of Telephony books, now serves as Digium's Community Relations Manager. Jared sent us a thought-provoking response which you can read in its entirety here. For ease of understanding, we're going to quote a number of sections of Jared's response and address them below so that you get the full picture of how dangerous the Digium development approach is to the future of the Asterisk project. We've been concerned in the past with Fonality's decision to keep trixbox ce on the bleeding edge while reserving a more stable Asterisk product for paying customers. Now it appears Digium has decided to do much the same thing with the open source version of Asterisk. That's unfortunate for all of us that care about the future of the project.
Jared Smith: "I think we can both agree that the feature set is an important part of any PBX system. Or, as you put it, "It's the Feature Set, Stupid!" There are two major reasons for moving from Asterisk 1.4 to the upcoming Asterisk 1.6 release at all, and the first one is features. Asterisk 1.6 brings a lot of new features to the table over what was available in Asterisk 1.4 and Asterisk 1.2. (The other big change in Asterisk 1.6 is that a lot of its internal plumbing got re-worked, so that it should be more efficient, more stable, and better able to handle larger call volumes.) Unfortunately, your article doesn't differentiate between features of Asterisk and features that third-parties (yourself included) have bolted on to Asterisk. To use the same analogy that I gave when I met you in Charleston, we here at Digium want Asterisk to be the best engine in the world. Whether you make that engine into a Formula One race car or a big brown delivery truck is up to you -- we're simply building the best engine we can. Now, we've gone and built a newer version of the engine ("More horsepower! Higher torque! Faster zero-to-sixty speed!"), and suddenly everyone complains that the starter motor doesn't fit in the same place that it used to. I know it's not a perfect analogy, but hopefully you get my point... "
Uncle Ward: We obviously applaud enhancements which make Asterisk "more efficient, more stable, and better able to handle larger call volumes." It's the rest of the paragraph that highlights the fundamental problem with the current Asterisk development strategy. The point is that, for Asterisk to survive, the developers need to appreciate that they're not building a mousetrap in a vacuum. Asterisk without a dialplan is worthless. Asterisk without application code has little value particularly in vertical markets. To carry Jared's engine analogy one step further, the concern is not about Digium's repositioning the starter motor. It's about eliminating fundamental components that businesses rely upon to keep their communications engine running. It does little good to develop "the best engine in the world" if this year's version requires kerosene while last year's version ran on gasoline and next year's version requires hydrogen. Such changes force a complete reworking of the infrastructure that organizations rely upon to keep their cars and their phone systems functioning.
Jared Smith: "APIs change when major versions of the software are released. (APIs are Application Programming Interfaces -- think of them as building blocks inside of the Asterisk code that both Asterisk and third-party programs can use to do various things.) The problem is, when we make Asterisk better, we often have to change those APIs to do so... I'd challenge you to find any major project that provides source-level API compatibility as a *guarantee* between major release versions. (Look at Apache 2.0 - 2.2, PHP 4 - 5, MySQL 4 - 5, PostgreSQL 7 - 8. They all have the same thing -- Major changes almost always require API changes.) When the Asterisk APIs stop changing from major release to major release, then Asterisk *WILL* be as dead as the dinosaurs are. "
Uncle Ward: We defy anyone to explain why "making Asterisk better" required breaking every dialplan on the planet because some developer thought Set(TIMEOUT(digit)=timeout) was a code improvement in Asterisk 1.4 over DigitTimeout(timeout). No one wants to stand in the way of progress. But moving forward is quite different than throwing the baby out with the bath water. Supporting both syntaxes would have required one extra line of code in the API. In the alternative, Digium could have released a source code translation application which would automatically convert existing code to the new syntax. This almost always has been done with major changes in programming languages. We would hasten to add that most of the developer-inspired changes with which we have been concerned have little or nothing to do with making Asterisk a "better engine." It's just a different engine. And therein lies the problem!
Jared Smith: "Luckily, Asterisk is an open-source project, which means that when Asterisk does evolve, that the changes aren't made in secret. Any third-party developer who wants to make sure his code remains compatible with the latest version of Asterisk can do so at any time. He doesn't have to wait until 1.6.0 is released to find out that his code will have to be changed to fit the new APIs. The Asterisk code is always available to test, play with, qualify against, etc. so that the developer can update their code to be compatible, so that when the time comes that real users want to use it, their applications will be ready."
Uncle Ward: The concern here isn't that third-party developers can't make changes to accommodate future Asterisk API changes. The problem is that businesses that stake their livelihood on a phone system that is Asterisk-based expect it to keep working year after year after year. Third-party developers come and go. So, if a company purchases an Asterisk-based system which includes fax and text-to-speech telephony support, those companies have a right to expect that their applications will work next year with the currently supported version of Asterisk. Jared's response sent me looking for the image to accompany this week's article: an ostrich burying his head in the sand. Third party developers move on or die, Jared. You can't pretend that folks never used their code because you're too focused on future enhancements to your race car engine to worry about preserving the necessary infrastructure to support applications that already work. As we put it last week, "You break it, you fix it. I break it, I fix it." That's a really simple design concept that should be fundamental to any API development changes. This in no way impedes the design goal of "making things better." Just don't make other things worse in the process.
Jared Smith: "The next point I'd like to address is that of responsibility. Your article somehow assumes that it's the responsibility of the Asterisk developers to somehow know about all these third-party apps, and make sure they never break due to API changes. I can see three flaws with that argument -- first of all, there's no way the Asterisk developers could possibly know of every third-party application, it's state of affairs, and so forth... The second flaw is this -- even assuming for a moment that we could keep track of all the third-party apps and try to keep them up to date (which we both know isn't possible), licensing concerns would keep the Digium-paid Asterisk developers from doing so... The third flaw to that argument is the point I made earlier... if Asterisk *were* to guarantee source-code API compatibility between major releases, there's no way possible that Asterisk could continue to grow, evolve, and adapt to the changing telephony market. "
Uncle Ward: I'm reminded of the Venus and Mars book about the differences in perspective between men and women. Are you really saying that Asterisk developers had no idea that folks were using dialplans and text-to-speech applications with Asterisk after Digium just worked with Cepstral to produce an Allison voice?? Come on, Jared. This isn't about whether it is Digium's responsibility to fix third-party developer code. This is about whether corporations and government organizations are going to invest in a telephony system when the business philosophy of the engine manufacturer is that they could care less whether they break existing telephony applications with each new product release. As I read Jared's response, Asterisk developers can't and won't be responsible for making sure they don't break existing applications and dialplan code, and Digium won't do anything to migrate existing code to new platforms. I'm not sure I understand how development of a piece of migration application code requires a knowledge of every third-party application in the universe. Presumably, the Asterisk development team does know when it changes the syntax of some command in the existing API. Why then would it be so difficult to provide another application that translated the "old code" into the "new syntax?" That doesn't require that any third-party apps be reviewed. And it doesn't stymie future development. Just provide the tool to fix stuff that you broke!
Jared Smith: "Last but not least, let's talk directly about your bug report. In it, you claim that 'Lack of native support for either Flite or Cepstral TTS breaks thousands of existing text-to-speech Asterisk applications.' Asterisk has never had native support for either Cepstral or Flite for text-to-speech, so I'm not sure how not having it in Asterisk 1.6 breaks anything. I'm afraid that if I were to follow your logic to its logical conclusion, it would be better to write that as 'Since the developer that wrote app_swift won't update the code for Asterisk 1.6, it's Digium's responsibility to do so.' Again, I've got to point out that Flite and app_swift are totally outside the control of the Asterisk development team."
Uncle Ward: Wrong again. What the Asterisk developers can control is making sure that, when a change is made to the API, they either support the new and old syntax or, in the alternative, that the developers provide a separate tool to convert existing source code to the newly-created syntax. That's what any responsible developer would do. This isn't a problem with a third-party application developer refusing to update his or her code. Many of these developers are no longer available or reachable. So it behooves the proponent of changes that impact the operation of existing telephony systems to provide a migration vehicle to the new platform. It's as simple as that. Give it some more thought, Jared. There's a lot more than either of us may appreciate riding on the outcome of our discussion.
Special Thanks to Our Generous Sponsors
FULL DISCLOSURE: ClearlyIP, Skyetel, Vitelity, DigitalOcean, Vultr, VoIP.ms, 3CX, Sangoma, TelecomsXchange and VitalPBX have provided financial support to Nerd Vittles and our open source projects through advertising, referral revenue, and/or merchandise. As an Amazon Associate and Best Buy Affiliate, we also earn from qualifying purchases. We’ve chosen these providers not the other way around. Our decisions are based upon their corporate reputation and the quality of their offerings and pricing. Our recommendations regarding technology are reached without regard to financial compensation except in situations in which comparable products at comparable pricing are available from multiple sources. In this limited case, we support our sponsors because our sponsors support us.
BOGO Bonaza: Enjoy state-of-the-art VoIP service with a $10 credit and half-price SIP service on up to $500 of Skyetel trunking with free number porting when you fund your Skyetel account. No limits on number of simultaneous calls. Quadruple data center redundancy. $25 monthly minimum spend required. Tutorial and sign up details are here.
The lynchpin of Incredible PBX 2020 and beyond is ClearlyIP components which bring management of FreePBX modules and SIP phone integration to a level never before available with any other Asterisk distribution. And now you can configure and reconfigure your new Incredible PBX phones from the convenience of the Incredible PBX GUI.
VitalPBX is perhaps the fastest-growing PBX offering based upon Asterisk with an installed presence in more than 100 countries worldwide. VitalPBX has generously provided a customized White Label version of Incredible PBX tailored for use with all Incredible PBX and VitalPBX custom applications. Follow this link for a free test drive!
Special Thanks to Vitelity. Vitelity is now Voyant Communications and has halted new registrations for the time being. Our special thanks to Vitelity for their unwavering financial support over many years and to the many Nerd Vittles readers who continue to enjoy the benefits of their service offerings. We will keep everyone posted on further developments.
Some Recent Nerd Vittles Articles of Interest...
I am sure I must be missing something here.. Why not just continue using the old engine? What new features does 1.6 possess that we can’t live without?
[WM: For the short term (about a year), version 1.4 will continue to be supported. After that, probably not which translates into no security patches which translates into a mess.]
I have to agree completely. In doing conversions of my dialplan from 1.2 to 1.4, I had to scratch my head when some of my dialplan no longer worked. I thought to myself, why on earth do I have to specify something like how to play background tones with a new command, what the heck was wrong with the old one? And how to set callerid changed? Why on earth would that be changed and deprecated? Why can’t both be supported? Your point about an application that Digium would provide that you could run your old dialplan through to identify deprecated code would be extremely helpful. As a corporate user, we are still on 1.2. Love to get to the features of 1.4 but not happening for a while!
http://lists.digium.com/pipermail/asterisk-users/2008-April/209688.html
You gave me the inspiration to patch up app_swift to work with 1.6.x codebase.
[WM: THANKS!! We’ve updated our Cepstral tutorial to reflect your addition.]
And see this thread for many additional comments.
I only have one system of 40+ peers, that I work with; currently with 1.2 installed, planning for upgrade to 1.4 in the near future. I have stopped updating because I am concerned that updates may cause downtime. To insulate myself from this problem, I am building a second machine to run the upgrade on, before attacking my production machine. Given the current status of asterisk development; I am currently re-evaluating any upgrade/update. I may ultimately elect to hold at 1.2 and make no changes to my "working perfect system". If I were considering selling and setting up asterisk systems for a living; I would definitely investigate other open software options, as it appears to me that Asterisk is attempting to narrow the field of players, sort of like the razor companies change blade styles every year to create demand for more expensive blades and eliminate third party commodity pricing. As an end-user; I see this strategy as a dead end for the consumer, that reduces the number of sellers in the distribution chain, minimizes competition, while increasing margins for the razor manufacturers. Proprietary sip system vendors to some degree protect their existing customers and their authorized dealers, by making tools available to "convert" one outdated system to the latest and greatest, thus welding existing customers to the vendor. Viewing this whole discussion gives me pause, about my decision to adopt asterisk in the first place for personal use. And to my thoughts of encouraging one of my sons to sell and install asterisk systems.
Commenting on what Jim Carter said: "I have stopped updating because I am concerned that updates may cause downtime. To insulate myself from this problem, I am building a second machine to run the upgrade on, before attacking my production machine."
Not testing on a sandbox and directly updating your production system is destined for failure. You should *never* update your production system without first testing on a development server, and running through your test plan (you have a test plan right?) to try and catch as many issues as possible. Test plans are extremely important in an upgrade situation, especially when it comes to your phone system.
Way too many times have I seen people upgrade their production systems blindly, with no backups, and having never tested the system, or even read the CHANGES log to figure why in the heck they upgraded in the first place.
And in regards to people moving from 1.2 to 1.4, and 1.4 to 1.6 (which btw isn’t even released as anything but at beta at this point… why are you trying to use 1.6 in a production environment already?), the transition from 1.4 to 1.6 will be relatively painless (unless of course you’re using third party applications, but this is a major version upgrade, sorry, not all third party apps are going to work out of the box as Jared has already commented on, even if you don’t agree with him). The amount of dialplan changes has certainly been quite a bit more minimal in terms of fundamental changes.
And I know it’s going to be a bit painful at first to go from 1.2 to 1.4/1.6 syntax, but believe me, you’re going to LOVE dialplan functions, do to the power and flexibility it gives you. At least from my viewpoint doing clustered systems, database integration (all hail func_odbc), and delivering calls to Queue members via the Local channel, the dialplan functions have made the impossible in 1.2, possible in 1.4.
I used the link in the Cepstral install instructions that you have recently changed, and it is not backwards compatible to 1.4 now. Please put the link back up to the app_swift that works with 1.4. I did some searching around and found it, but your instructions are for a 1.4 install and a 1.6 app_swift and it does not compile, because the API has changed. Of course.
[WM: Huh? There’s a section in the article to install app_swift with Asterisk 1.4 and a new section to install app_swift with Asterisk 1.6. You simply pick the install that matches your version of Asterisk. The Asterisk 1.4 installation section was not removed.]
I see this more from Digium’s perspective, but perhaps that’s because I’ve been in telephony for over a dozen years. If you look at the "closed source" platforms (e.g. Cisco, Avaya), you find the same upgrade obstacles with 3rd party integrations and even their own "in house" products when considering major version upgrades. For example, one adjunct version might not be compatible with another, custom applications/integrations can break, and sometimes things work differently than they did before.
These companies are still going strong and "fortune 500, medical, and government sectors" still use them. I think it’s a bit premature to think that Asterisk will fall flat on it’s face for making some radical changes that might result in incompatibilities.
With open source, the issue of inter-compatibility becomes magnified by the rapid development cycles and the wide array of "bolt on" 3rd party integrations that result from popular applications. I completely agree with Jared that it’s the 3rd party developer’s responsibility to keep in lockstep with the growth of the original application.
I do find validity with the argument that Digium could provide a tool to update things, like the dialplan code, automatically. It’s called an "upgrade path" and is an essential consideration that must be taken when proposing a new version to a customer base. The nature of Asterisk’s free-form configuration makes this very challenging, but it’s the one suggestion that I felt could really make a difference.
Interesting article & analysis…thanks!
[WM: Thanks for your comments. Of course, the Cisco’s and Avaya’s of the world don’t release major version upgrades annually thereby throwing all of their customers into tailspins. And they do provide upgrade tools. The major companies also don’t drop support for their prior releases within a year or two of initial release. Finally, take a look at /usr/src/asterisk/UPGRADE.txt on your 1.4 system and give an honest answer as to how many of these so-called "engine enhancements" more closely resemble developer quirks. Changing API grammar and syntax doesn’t usually result in much of a performance improvement except for the fact that all the old third-party code no longer works so there’s less "stress" on the race car.]
I strongly agree with Ward and the nerd vittles community. It is reckless to change the API’s in such a manner. It would essentially break third party applications ! A graceful non-evasive approach should always be considered as a first option. We all want to drive a Ferrari but for the vast majority including the business community, having a stable 1.4 system and the ability to transition these applications seamlessly to the next software release is of the highest importance. Having 10+ years background supporting software upgrades and applications for the telephony industry, there is a graceful way to approach it. As a general rule, breaking third party apps would never fly in the real world business environment. Consideration for applicable patches for the prevention of breaking these APPS is the responsibility of any Vendor, "at least responsible ones."
Would Digium create code that would render their interface cards useless in future release ? I don’t think so! Just ask our friends at MS. They know a thing or two about ‘THAT’!
Hope that consideration for the greater Asterisk community is considered. No one likes to have ideology or ‘BAD CODE’ crammed down their throat.
Regards,
-Ed
I’m trying to understand how Digium (and Jared) could write a response completely OFF THE POINT like this. They appear to be living in a FANTASY world, forgetting thousands of developers that work FOR REAL with their product. DIGIUM! WAKE UP AND *READ* WHAT WARD IS TALKING ABOUT instead of giving childish replies like this. BTW, Ward: The picture of the ostrich is just PERFECT to Digium’s behavior.
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.
Hey Thanks for these updates on Asterisk. I’ve been reading the Nerd Vittles site for a year now and have implemented several of the useful tutorials including switching to the awesome PBXIAF. I’m still in high school but have my own computer and web consulting business for which I use PBXIAF for calls. As a student I can’t afford a lot so PBXIAF in its open source state is excellent. These changes in the code concern me because when it comes to my personal and business interests, I can’t afford to lose time and money when an upgrade comes out. It really seems trivial to implement some of the things you said – ie either stop deprecating code or introduce a translator. I’ll be watching the Nerd Vittles site quite closely to see how things turn out. Thanks for the great work and for the care you show toward your readers and users of Asterisk!
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?
Was not one of the reasons that Microsoft was so successful was because they catered to developers? Ignoring developers and technical people will lead to [problems] for Digium because it is they who often decide what gets used in the corporate environment.
You can’t have it both ways. If you want the slow release cycles of, say, an Avaya, where feature sets may stagnate for half a decade: buy an Avaya. The same thing that makes the cool Nerd Vittles stuff even possible in the first place is the flexibility inherent in a FOSS package like Asterisk that has a fast paced feature uptake. Given enough beer, you could probably entice a programmer to add any feature you’d like to the * code base. Try doing that with an Avaya engineer. Try talking to an Avaya coder without first being a paying customer in the tens or hundreds of thousands of dollars range.
That being said, I do think that Digium should probably give a bit more effort in providing migration tools (actual tools, not just documentation) and also make more of an effort to not be quite so much of a moving target. I realize that sometimes it’s just impossible to do that, but if the choice exists, even if it takes a bit of extra work, then the decision should be made for as much backwards compatibility as possible. I’m not saying they don’t do this in the first place, but there’s always room for improvement.
You’re missing one major point in API transition; that is, during the 1.2 series, DigitTimeout(5) was deprecated in favor of Set(TIMEOUT(digit)=5). A whole release cycle of something like 18 months, and you can’t be bothered to read the deprecation notices? And then you complain when 1.4 removed it? Why aren’t third party developers responsible for reading deprecation notices, when Digium provided a clear upgrade path?
[WM: Just wondering how long it would take you to chime in, Tilghman. This isn’t about notice. You kinda missed the point of the articles. Big surprise there.]
I am curious to what extent the API has changed and how difficult it would be for someone in the open source community to release a source code translation app. I saw the same example in the last two articles, so I am just curious as to how expansive the actual changes are.
Dont get me wrong – I know this is not the point. I run a software development business, and my software (not telephony related) is used by my customers in conjunction with other software. I am fully aware that changes to our code can have a dramatic and widespread impact, so we do not keep the blinders on and simply do whatever we want. I do not want to go out of business anytime soon, and over the last 10 years I have found that one simple question keeps me competitive and loved by my customers: Can we do better? Before we release ANYTHING, I ask my team this question, and inevitably we discover things that may require more work, but make for a better solution. I can certainly say that if I were leading the 1.6 development team and asked this question, someone would have brought the issue up. Furthermore, in the event that we did overlook something so crucial, I would be certain to rectify it and take advantage of still being in a beta state to do so.
Still, I’d like an answer to my first question if anyone even knows.
Please also do remember that there are developers that don’t work for Digium. To keep saying Digium when you refer to decisions made by the developers is not correct.
I was part of the decision and made the code to update the manager interface. There was a lot of discussion about pro’s and con’s on the mailing list before we touched it, and code in a branch to test. I would have appreciated your feedback then. The changes to manager were carefully documented and constructed in a way to help developers recognize the AMI version, which wasn’t possible before. Previously, things changed but not the version number.
[WM: Thanks for your comments, Olle. Digium does still own the Asterisk code so… the buck stops there in our book.]
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.]
I’m still using 1.2 because 1.4 doesn’t offer a compelling reason to me except "you’ll get left behind."
I understand some of the dialplan changes made the "language" more consistent and extensible and I’m all for that.
I don’t understand the attitude some (most?) of the developer’s display. For instance, look at the agent/queue/callback nonsense. The attitude of the developer’s was received as "it wasn’t implemented well so we’re just going to remove it rather than fix it — besides, you can probably cobble up something similar with a bunch of dialplan stuff anyway." I could probably cobble up something to replace voicemail or sort or saynumber with a bunch of dialplan statements, but isn’t the whole idea of applications to bundle complexity and make it easy to use? Maybe we should cobble up a replacement for Asterisk with a bunch of tin cans and string using carrier pigeons for signaling… (SIP = Slow Incoming Pigeon?, PSTN = Please Stop Tugging Now?)
Who thought prefacing some of the CLI "verbs" with "core" was a good idea? What’s the logic in deciding which verbs require core and which ones don’t? Why should I have to retrain my fingers based on somebody’s arbitrary decision to make a bad CLI even worse?
Re: CLI changes
In order to make the CLI consistent, it was changed to a ‘module’ ‘verb’ ‘argument’ syntax. In 1.4 unfortunately it is inconsistent, but myself, and mvanbaak on IRC went through the entire CLI command set a couple of times to make it consistent with that approach. This makes grouping the CLI commands together much more obvious rather than having a couple of different methodologies doled up together.
You can view the work we did on this in the bug tracker here: http://bugs.digium.com/view.php?id=8925 which contains the tree structure of the command set while we were doing the audit.
The reason for the ‘core’ is because that is essentially the module name — core functions which are more closely associated with the CLI appear here, e.g. core show channels, where ‘core’ is the ‘module’, ‘show’ is the ‘verb’, and ‘channels’ is the ‘argument’.
This is now done throughout the CLI, and is implemented in 1.6-beta and beyond.
Developers that don’t know how or don’t try to provide compatibile interfaces should go back to school. As pointed out several times, there are many ways to provide backward compatible support in API’s, Microsoft struggled with this for years with DLL’s and eventually solved it. That is why interfaces/API’s have versions (or should have). Marking things as deprecated is fine (hidden of course in the overly verbose spew of stuff going into the log) but the previous version of the API should work at least across one major release. This might be called professional programming and design. I’m sure the changes for 1.6 are for the better but, unless Digium is thinking of the changes as potential support and upgrade income, then it is a mistake to drop compatibility for the previous major version.
An alternative is upgrade tools. Again Microsoft examples of this support exist. For Visual Studio, you can import VB6 projects years after that version was no longer for sale. A bit of creative thought from the Digium developers would find a graceful solution.
Welcome to the big world of non-toy software. I love Asterisk for what it provides. Please don’t make us look elsewhere…..
Wow, application interface compatibility is that hard? How about interfaces like IA32 (the x86 instruction set), that started with 8086 in 1978 and even today’s superscalar, out-of-order, speculative multi-core, multiprocessing monsters can run code written for the oldest machine. Asterisk developers, please don’t insult peoples’ intelligence by claiming that managing interface versioning is an unsolvable problem, because it has been solved.
How about that for not breaking interfaces? And I don’t think Intel or AMD hire a bunch of folks to keep track of what behaviors of what instructions, applications are relying on.
Asterisk = Beta
As always.
I have been using Asterisk for almost 10 years now I think.
It has always been "beta" software to me.
The changes going now from 1.2 to 1.6 are big and will be a pain in behind for many, but it will not stop digium from moving on.
We all know that for Asterisk to move up, they need to solve a few things with the core engine, and in doing so things will break.
Which is why I build lean boxes with little adding third party app’s installed on the box.
Asterisk can be used well after the EOL and if you lock it down and do not expose the box to the outside world then you may be running the 1.2 / 1.4 branch for YEARS to come.
I have two boxes still in play running AMP 1.x, they have not seen an update in YEARS yet rock on.
Hi,
it seems for me like a philosophical debate which role a company will play in the future. Digium is now big enough to set the condition and all others have to follow. But it can as well very fast be the end of such an arrogant company (there are some examples in the history and also in this days).
As Ward said, it’s not that a company can’t create new features with new API’s and, of course, it is the right of Digium to change the syntax if they want to bring in a new methodology (Leif, you are right).
But it has to comply with the tradition that such big, fundamental API changes should only happen over a big time period. But it seems just the opposite: Digium changes its API structure every time, so there is no reliability / trustworthiness.
If Digium feels they are strong enough to give up the support of a community, well – they can do it. But why they should do it? It makes no sense to destroy a good idea. And this is what the community and – I believe – Digium itself want: a fruitful Future for both!! sides.
There is plenty of time to create a codex of trustworthiness, which Digium could discuss with its partners (not only this community, but with all 3rd party developer or even bigger companies), because THEY are the key base for Digium and any similar company which is mainly based on communities.
Please have a look to the changing world in the music business – the inflexible dinosaur will die if they do not focus on the new customer behavior and their special needs! There is a similar problem in the discussion here – nothing else!
Ward, I completely agree with you, and it looks like most of the commenters do as well. I have worked with asterisk since the early betas like many others and updating dial plans and scripts after ever major release is frustrating and unecessary. I don’t think that any analogy or comparison is really required for this issue. I think that the asterisk development team should hold itself to a higher standard than that of apache, mysql, php, cico, avaya etc. Just because others makes syntax and API changes doesn’t mean that its OK. There is no good reason for syntax to change and there is no good reason for different ways to do the same thing. For example, look at python’s mantra … "There should be one—and preferably only one—obvious way to do it".
I agree with bubba’s comment that Asterisk = beta. It is unfortunate that releases are never really stable until the next release is in beta making for a very short life cycle. And also no concrete upgrade path.
I am very interested in what Mark would have to say about this. I think when long term support and a solid upgrade path are established, no one will be able to compete with asterisk. Let’s just hope that day is sooner rather than later.
I’m mostly in agreement with Ward on this. One of the long standing complaints about the whole Unix/Linux environment is the instability in some areas – anyone else remember the old joke about "what’s the print command called today ?"
Of course the API needs to adapt as things develop, but there’s a balancing act to be followed between wholesale changes that break everything, and doing it in a more user & developer friendly way. It would be interesting if the Asterisk developers could come up with a list of more than one or two commands that could NOT be retained in their original form as a means of backwards compatibility.
But I think I can come up with a better car analogy. The one I have is that they’ve improved the engine and decided for no particular reason to redesign the bolt pattern where it mates to the gearbox. Thus every manufacturer has to redesign their gearbox before the car will work with the new engine. There is a standard method where you want to fit a different engine to a gearbox – and that’s to fit an adapter, or in software terms a slice of compatibility middleware.
If the Asterisk developers really had the projects and users best interests at heart, they would include the compatibility layer as standard (ie retain the calls but mark them as deprecated) so the cars will still work and the gearboxes can be sorted out over time.
Their current approach seems to be exactly what we criticise the non-free software industry for !
You make good points; however, i think you might be missing mark on something here. One thing any codebase has to worry about is feature creep. If the Asterisk project is continually worrying about backwards-compatibility with the products of dozens of third-party open source and closed source developers’ projects by maintaining support an obsolete API, each party may find that security flaws are harder to patch up, and that the codebase grows to the point of unmaintainability. I don’t believe it is an unalienable right of a company or individual that uses an open-source solution implemented by a third-party developer (using god-knows what code) to demand of a company that released software with no warranty whatsoever (isn’t asterisk gpl’d?) that they support any particular feature or line of code at all. Microsoft may have become successful in part because of catering to vendors, but they have a bloated, crappy, and permanently buggy codebase precisely because they attempted to provide support for y^x features
That said, it would be irresponsible of Digium not to manage changes in a way that would minimize impact on the user base, and a poor job of managing expectations between major releases will only hurt the business side of their business in the long run.
[WM: Thanks for sharing your perspective. Micro$oft, of course, has no monopoly on buggy software. There’s plenty from others to go around. For the most part, many of these syntax changes have absolutely nothing to do with engine enhancement much less securing the codebase. Many are little more than developer-inspired, developer-driven quirks and program language fetishes.]
"Name an open source project that maintains source-level API compatibility as a guarantee between major releases?" OK. How about Apache Ant. Code written 8 years ago that relies on the public APIs and that continues to work on the latest checkout.
This works because API backwards compatibility is accepted as a core value by the developers. No change that would result in breaking backwards compatibility is allowed. This is needed because people used to use Ant for XML configuration of dependency injection before Spring was available.
Now, I am not of the opinion that APIs should never be broken between major releases for most projects. But I do believe that they should not be NEEDLESSLY broken. If you can maintain backwards compatibility while introducing new functionality, you should do so. To do otherwise is to show contempt for the efforts of your community in trying to enhance your product. You have to assign zero value to the time it will take them to rework their applications in order to make changes without at least trying to maintain backwards compatibility. Now, if there are tradeoffs that need to be made in order to make the application better, you can still respect the effort required by others but decide the benefits are worth it. But you had better make it clear to everyone that you tried hard not to break the API, and explain the reasons why it was necessary in each case.
A completely separate issue is breaking dialplans. These are not APIs. These are not used only by third party developers. They are the scripting language that is exposed to end-users. The considerations and justifications that go into breaking your end-user scripting language should be several orders of magnitude higher than for APIs. In fact, I have never encountered a situation which would justify breaking it across a single major release. You might want to move to a new scripting language. You might want to sundown your existing one. But such an action should occur over several years with lots of lead time for everyone to move over to the new language.
Which wouldn’t hurt for the APIs either. Ever heard of documenting APIs as deprecated, Digium, and removing them later? Apparently not.
http://www.python.org/dev/peps/pep-3108/
Here’s an example of "the right way" to depricate (in this case python modules, but can be applied to API commands).
The best quote from the page is:
"Each module to be removed needs to have a justification as to why it should no longer be distributed with Python."
Basically they described IN ONE PAGE every command/module that will change. They divide it up into two categories: "Modules to Remove" (Previously Deprecated, Platform Specific, Hardly Used and Obsolete) and "Modules to Rename".
Next to each module they described their reasoning for removing that module (e.g. this code hasn’t been updated in 15 years, also there is a better command that follows the new standard, etc. etc.)
Digium realized they had language consistency issues and began the noble task of cleaning up the code.
Unfortunately they introduced the new language then decided to roll up the entire complex deprication/obsoletion process into the same .x release without providing any justification or conversation to the development community.
But it was their heavy-handed approach to developers that may prove most damaging.
I agree that new commands must be introduced for an API to move forward, but the old ones must also be kept around while they are still considered useful by the dev community. If a new command really is better, the dev community will recognize that and the old command will die gracefully. Then it can be removed (after 10 years).
Once upon a time, there was a bank that invented ATMs. They realized the great potential of the ATMs at once so they installed the ATMs in all their branches and killed all their tellers. The people cried "we know the ATMs are better but we still want tellers because it’s what we’re used to". But the bank insisted it was smarter than the people and they should just accept it. So the people went elsewhere. The bank eventually closed.
The End
In Response to Comment by Jeff Whiteside: "These companies are still going strong and fortune 500, medical, and government sectors still use them. I think it’s a bit premature to think that Asterisk will fall flat on it’s face for making some radical changes that might result in incompatibilities."
That’s a terrible example. You’re speaking of companies that already have this in place and have spent a lot of money to get the system where it is. They, of course, are going to continue to weather the changes and issues of broken applications. They have no choice in the matter.
But new companies looking at Asterisk as a viable platform do have a choice. When they talk to Joe Schmo Inc and he says asterisk just changed everything and all the custom additions they paid to have made to their system don’t work anymore with new asterisk code…The prospective company is going to say screw that…let’s stay the hell away from that. What is the point of having a free PBX that we now have to spend thousands on everytime they decide to (make their engine better)
And why the hell does it seem that the more they make changes the longer the commands get to achieve the same results?
This is why I still use 1.2.x.
But FreeSwitch is starting to look pretty good now.
http://www.venturevoip.com/news.php?rssid=1997
It looks like they may finally be listening. Too bad much of the damage has already been done.
All the comments here are from great interest.
I will just add that designing and programming a telephony software is not like writing a database or an HTML engine. It’s a totaly different world.
Telephony switchs are often kept during 10 years in a company. In europe it is more often 15 or 20 years.
In this regard, it is very important to keep compatibility during at least 2 or 3 versions, to allow for clients to have a good migration path for evolutions. Digium program Asterisk like a game. More, it’s like they were playing with it.
So please Digium, stop to program Asterisk like a data software or a game. Telephony is more than that, it needs a lot more design smartness, a lot more reliability and serious, and a lot more compatibilty through versioning.
I would prefer to have an asterisk 1.6 with three times less new functions, but perfectly reliable and with all the basic functions we really have and need on a traditionnal PABX, instead of having chat, voice recognition, and advanced stuff only necessary for advertising and marketers. Asterisk is not yet reliable enough neither powerfull enough to target big telephone switch replacement. So let’s give him the basic functions and the reliabilty it does need to really become the futur of telephony : the telephony we need and we can find inside 90% of the companies.
The linux kernel have some very interesting improvement in recent version 2.6.x. regarding multitasking and near realtime. Asterisk seems to totaly ignore them and concentrate almost only on new telephony functions even if some efforts have been made.
If the world telephony network is today working, this is because big standards have been accepted by all major telcom providers.
Asterisk need to follow this road or it will dye.
I’m still using asterisk 1.2 on production systems because later versions are like a moving target, it is very time consumming to learn, test and implement them on a production system. For example they broke very usefull functions we have inside FreePBX and it is not permisible. Who is using in the real world asterisk alone ? Most users are using it with FreePBX through Trixbox or other similar distributions.
Dispite their efforts, the FreePBX team didn’t success in fully adapting Asterisk 1.4 after one year, for advanced dialplan functions. We still have issues. This is not good for such a big project, with all the support and bug report it does receive from experts from all around the world.
I realy think that Digium should listen them a bit more, or really open the project instead of saying "we are the best and because of this we can decide wich modifications are needed when they are needed".
I will give an exemple of a very bad code change :
Inside asterisk 1.4.21, a new milliwatt application has appeared. It is now 1004 Hz instead of 1000 Hz, and the audio level is now 10 dB lower. How many of you were informed of this change ?
This is now the default milliwatt application.
First, the 1004 Hz frequency produce a lot of distorsion because the sampling is 8 KHz. Second, using a new reference audio level break all audio test applications relying on the old reference level.
In my test lab, watching our spetral analyser, i was very surprised to see such a low level and such a high distorsion on a G711 link called from a good POTS line. I thought at first that our VoIP provider had changed their setup and droped down their quality level !! Calling our Asterisk server from another provider did show the same signal, so i finally discovered the Asterisk milliwatt change !
This is a perfect sample of a bad evolution. Changing milliwatt is a very very dangerous option for all providers and users using this application to control links. Imagine a Lab doing certification tests, having to connect to different providers with different milliwatt applications… What a disaster in their results…
There should be at least a big warning in the install process, and the older milliwatt should be compiled by default, not the new one.
This been said, let’s make a new telephony world all together with Asterisk or a forked project if needed (Asterisk 1.6 could be a good start template), and please let’s help to remove progressively all the old traditional telephony stuf and providers who are causing lots of headache and interconnection problems. Asterisk, Full IP, and ENUM is the futur of Telephony ! Not Asterisk alone.
Olivier
I do feel the need to correct everyone on one point here.
There are long-known, time-honored semantics for version numbering, and going from 1.2 to 1.4 being called a "major version upgrade" is not one of them.
1.4 to 2.0, yes.
That said, I concur with Ward’s point of view, which is, approximately "it is, indeed, incumbent on Digium not to break the programmatic interfaces to Asterisk without exceptionally good reason, and that’s standard Release Configuration Management best practice, and they should know this. IE: Mark and Jared are wrong, and Ward’s right.
And, a followup I meant to include but forgot seems quite on point here as well:
Asterisk is not a PBX.
You heard me.
It’s a *toolkit* for building PBXes.
Just like XML is a *toolkit* for building data-transport-wrapper languages (note; *not* -storage 🙂
If you’re going to be a toolset, you have a much different and more stringent set of rules to follow, and these are the rules that Ward’s complaining about Digium breaking.
I’ve danced this exact same dance with a DBMS vendor intermittently for the last 20 years, with the same justifications on their side and results on mine.
And one final observation, about milliwatt.
If they changed it *to* 1004hz at 0dbm/600ohms, then on that particular point I have to grant them absolution (though yes, making the old version available would probably be nice…)
1004hz at 0dbm has been the standard milliwatt test tone since Mark Spencer’s *parents* were in diapers.
An 1940 IRE publication is the first reference I can find to milliwatt tone, but I can’t confirm it specifies 1004, and based on my memory of *why they picked 1004*, it wouldn’t.
I’m trying to source it now, but as I recall it was to put it *far enough away* from a submultiple of the digital sampling frequency that early, wobbly, PCM circuits would be less likely to screw it up.
[…]
Apparently, the problem was that when Bell deployed the D-1 PCM channelbank in the early 60s, they discovered that digitally generated 1khz tones would translate to a pattern on the PCM side that looked too much like the framing pattern, and dumped the digital link.
Digital Telephony by Bellamy appears to have a citation on this, but Scribd is predictably worthless, and Amazon wants me to log in. I have a copy at home; I’ll dig up a citation tonight.