If you’d like to discuss anything in detail, including bugs you reported that weren’t addressed by the Asterisk community, you can reach me directly via e-mail. malcolmd AT digium dOt com.

Cheers.

Every upgrade seems to come with some regression. Between the release candidate and the release of 1.8, it started dropping calls on transfer. How can any change that touches such important parts of Asterisk even be allowed that late in the release process?

I have completely given up on reporting bugs to Digium and just work around them instead, and I stick to a version that I know the particular peculiarities of.

Sorry, but Digium is doing a lousy job managing the Asterisk development process, and their responses to the community (as seen above, "smear campaign" etc) is only further proof of that.

We’ve addressed the TLS regression in 1.8.4.1.

BigSeph:

1.8.4.1 provides a number of fixes. The Changelog is here:

http://downloads.asterisk.org/pub/telephony/asterisk/ChangeLog-1.8.4.1

Gerard Monroe:

Of course we’re not attempting to produce or by inaction attempting to cause an unreliable Asterisk base to turn people to our commercial solutions.

In the interests of full disclosure let me start this post by saying that I work for Barracuda Networks on the CudaTel team and I am a member of the FreeSWITCH community. (In fact, I am sometimes called the "FreeSWITCH Community Liaison.") I hope it is not impertinent of me to offer my input even though I haven’t used Asterisk in a number of years. I noticed several people saying that Ward should "give FreeSWITCH a try," so I thought it might be good for me to pop in and say a few things.

First off, I can completely understand each side’s point of view. Ward (and the rest of the Asterisk community) should reasonably expect that the latest stable version wouldn’t render every Cisco 79xx unusable. That’s not at all unreasonable under the circumstances. I also empathize with Digium’s position. It really is hard to test everything. That being said, I must express my overall disappointment and general disagreement with the responses by Malcom Davenport and Jonathan Rose.

Malcom implied and insinuated that Ward was engaged in "smear" tactics and was otherwise mudslinging. Even if that was true – which I don’t believe, by the way – a better response would have been simply to say, "You’re right – a nasty bug slipped into 1.8.4. We’ll do our best not to let it happen again. In the meantime, we would like to discuss the situation with those reliant upon 79xx phones. Perhaps you are in a position to assist with pre-release testing…" Please believe me when I tell you that we’ve released FreeSWITCH versions that had problems and we’ve had to slap our respective foreheads and say, "How in the world did we miss THAT?" It happens. When your OSS community points things out, even if they do it in a way you feel is abrasive or rude, you still have to listen or run the risk of becoming the very opposite of the open source way: closed, proprietary, we-know-best. That’s a lesson we’ll keep learning until we release a version of FreeSWITCH with no bugs, no interop issues, running perfectly on Linux, OS X, and Windows. I’ll let you know if that day actually comes…

Another thing I wanted to point out is that while we love FreeSWITCH – and I mean *LOVE* it – we are not trying to proselytize converts away from Asterisk. The FreeSWITCH developers have a philosophy: use what works for *you*. In other words, use the tool that best fits your situation. The whole reason that Anthony Minessale started FreeSWITCH back in 2005 was because the tool (Asterisk 1.0/1.2) no longer met his needs. He tried to rally the troops to start on Asterisk 2.0 way back then, but to no avail. So he set about making his own tool to fit his needs. The result is a tool that can, but is not design to, replace Asterisk. The good thing is that FreeSWITCH is 100% open source and free. Try it for free. If you don’t like it use something else – you won’t hurt our feelings. 🙂

Regarding CudaTel and FreeSWITCH: There is only one branch of FreeSWITCH. There is no secret, closed-source version. The version that you download from git master is the same version that drives the CudaTel. Whenever the CudaTel team needs to add a FreeSWITCH feature/function/patch/etc. then they usually add it to the master FreeSWITCH branch *first* and then they git pull on the CudaTel side. (We are about to create a 1.0 "feature frozen, bug fix only" branch and a 1.2 dev branch… stay tuned for that one.)

Lastly, I have to comment on the state of the documentation for FreeSWITCH. It is indeed lacking in some areas, particularly with respect to the speed at which new features are added. However, as the co-author of the only FreeSWITCH book (Packt Pub) I can say that we work very hard trying to keep the documentation updated. Also, we are actually working on the FreeSWITCH Cookbook (also from Packt). The FreeSWITCH documentation situation is getting better every day. Please don’t let "no documentation" be the only thing that keeps you from trying FreeSWITCH.

Thank you for letting me throw my thoughts into the hat! I appreciate your time. Ward, thank you for all of your hard work with promoting OSS telephony. Feel free to come to ClueCon in August and talk to us about your experiences. Also, if you want to do fun stuff with FreeSWITCH and have any questions please let us know.

Michael S Collins
FreeSWITCH Community Liaison
http://www.freeswitch.org
http://www.cluecon.com

[WM: The disappointing discovery for us at least is that a company with Digium’s size and talent pool that not only oversees the software development of both Asterisk and Switchvox but also manufactures VoIP hardware apparently lacks even a rudimentary test center with a dozen or two VoIP devices from the major manufacturers. That would include several Cisco 79XX models by the way. When one considers that Asterisk’s major selling point has always been connectivity, this becomes even more surprising. Yet the testing methodology (if you can call it that) which we continue to hear Digium pitch is "we put stuff out and you let us know if it doesn’t work." Little wonder that open source continues to be a very tough sell at any price in the commercial, medical and government sectors.]

piafdl: line 518: dialog: command not found
piafdl: line 152: dialog: command not found
piafdl: line 131: dialog: command not found
piafdl: line 166: dialog: command not found
piafdl: line 304: dialog: command not found
piafdl: line 304: dialog: command not found
piafdl: line 304: dialog: command not found
piafdl: line 304: dialog: command not found
piafdl: line 304: dialog: command not found
piafdl: line 304: dialog: command not found
piafdl: line 304: dialog: command not found
piafdl: line 304: dialog: command not found
piafdl: line 304: dialog: command not found
piafdl: line 304: dialog: command not found
piafdl: line 304: dialog: command not found
piafdl: line 304: dialog: command not found
piafdl: line 179: dialog: command not found
piafdl: line 434: dialog: command not found
piafdl: line 449: dialog: command not found
piafdl: line 463: dialog: command not found
piafdl: line 477: dialog: command not found
install-purple – 2.0.5 released on 050811

[WM: Doesn’t sound like a PIAF build. Try yum install dialog.]

Ward is clearly correct in his assertion that we, “the community” have a reasonable expectation that “Digium” has sufficient skin in the game that is played using open source releases of Asterisk. Remembering that Digium benefits from the sale of hardware that is used by the value-added distributions being fielded by the community, they should not be so defensive about Ward’s comments.

The problem, however, is that when Digium decided to wear two hats – acting as a member of the community in providing a commercial product for sale, and as the source in the open source community – they put themselves in the position of competing with the rest of the open source community. To placate the concerns, it was implied to the open source community that Digium’s commercial product would be built from the same platform as the open source – thus making a level playing field.

That said, I am troubled by two of the specific points that have surfaced…

First, with respect to the Cisco 79xx fiasco, this could have been avoided if there was documentation of the testing undertaken before release. Perhaps the open source community needs to adopt a standard for documentation of testing performed before a release is fielded. Clearly, if the community saw that the testing was not performed with station equipment as widely deployed as Cisco 79XX, then we would not likely have adopted it, and tested it ourselves.

Second, if their commercial product is based, as written in this blog, on Asterisk 1.2, then that means they have to be supporting 1.2, then Digium can., albeit absurdly, claim to be eating their own dogfood – just not what they want to serve to the rest of the world. However, how then can they claim the right to no longer support 1.4 and 1.6? Supposedly they gave up support of 1.2 when 1.4 and 1.6 were introduced. Which is it? Moreover, how level is the playing field if there is such disparity between 1.2 and 1.8 as everyone (including Digium) seems to state? On the surface, their actions appear as if they want to place the community at a disadvantage. I am not sure they are smart enough to be so conspiratorial, but can see why the community might come to that conclusion.

The bottom line, I’m afraid to say, is that Digium’s actions are inconsistent with what I believe are reasonable expectations of people in the open source community, and we must therefore actively explore alternatives. As an Asterisk / Asterisk derivative platform based user and consultant who recommends them to clients, this is a painful situation.

As a communications systems architect with a vested interest in consensus standards, I am willing to commit to conversations focused on examination of our options or even documentation of an architecture.

PS My apologies in advance for any typos – I am sight impaired and recovering from eye surgery.

The only thing I can say about Switchvox is that the operator panel gives sales people, executives, and other non-technical people the warm-fuzzies. Oh, and its slightly less expensive than other paid solutions.

Having tried to adopt 1.8 in "the commercial marketplace" on 3 separate occasions, and having to roll back to 1.4 in every case, I do agree with Ward. Contributors need to test their contributions. The quality of code being contributed to 1.8 is much lower than I’m comfortable relying on. If the developers aren’t taking enough pride in their work to test it, and Digium isn’t taking enough pride in the code to test it, where does that leave us?

I dearly hope Digium isn’t hoping an unreliable Asterisk base will turn people to their commercial solution(s). That just won’t be the case.

I love Asterisk for what is good at, using for many years in large production environment but cant think of going to 1.8x yet as it was hard decision to upgrade to 1.6x last November. cant’s risk with 1.8 for quite some time until better confidence is built. This kind of events doesn’t help and let us think again 🙁

As for this lack of eating our dogfood quality, no. If we didn’t use Switchvox internally, then we’d have an embedded system (which by the way isn’t entirely distinct from Asterisk) that we wouldn’t be using internally. THAT would be not eating our own dogfood. Coincidentally, this is dogfood that we are asking people to pay money for, so being able to guarantee the quality is slightly more important than with the dogfood recipe we’ve been dishing out for free.

[WM: Uh, hello, we all thought Asterisk 1.8 was a stable release since it’s the only one that hasn’t been retired. Sure wouldn’t want you to have to go to the trouble of plugging in a phone. You’re probably much to busy for that. Seriously, Jonathan, it’s one thing to solicit input from the Asterisk user community about unknown bugs. It’s quite another to know about a problem and hide it from the user community in a production version of the software… all the while enjoying internally an SVN release in which the bug has been patched. From your comments, this distinction may be too subtle for you.

After you wipe that silly grin off your face, enlighten all of us community people (CPs?). Which version, if any, of Asterisk 1.8 really is stable and production-ready? Is it 1.8.4 or is it the SVN flavor of the week or is it none of the above? Not to put too fine a point on it but… we’re looking for the yummy stuff that goes in the front of the dog, not what comes out the back.]

"As we said in the article, if Digium and other Asterisk developers shifted gears and actually relied upon Asterisk 1.8 to meet their telecommunications requirements, this never would have happened. Digium may have staked their business on Asterisk 1.8, but the company clearly is not dependent upon Asterisk 1.8.4 to make and receive phone calls."

Digium does in fact use 1.8 in house, but that is besides the point. You’re talking about a very specific phone deployment (Cisco 79XX) and assuming that Cisco phones are deployed throughout Digium. While I haven’t been to the new Digium office yet, I would be shocked to find dozens of Cisco phones deployed throughout the office.

[WM: Malcolm’s response was ambiguous on the actual use of Asterisk 1.8 within Digium. I’m sure they have Asterisk 1.8 servers running within the building. However, using an SVN release in some lab environment (if that’s what it is) is a far cry from depending upon a production version of Asterisk 1.8 to run your day-to-day operation. Kinda sounded like that task was delegated to their commercial product. We never suggested that Cisco phones were deployed throughout Digium; however, we’d be shocked if Digium didn’t have at least one Cisco 79XX phone on the premises. From Malcolm’s response, it also seems clear that Digium management was fully aware that Asterisk 1.8.4 would break Cisco phones before the software was ever released. I’m fairly certain that you were aware of the problem as well. What’s puzzling is that there still is no Asterisk 1.8.4 patch to fix the problem even though it has been addressed in the SVN upon which many of the developers happen to rely.]