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.

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.

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.

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

It looks like they may finally be listening. Too bad much of the damage has already been done.

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.

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

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.

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

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 !

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.

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!

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.

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.

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

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.

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?

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

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.

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

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.

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?