Dear Digium: It’s Time to Start Eating Your Own Dog Food

30 Comments

1. "….the scuttlebutt always has been that Digium uses a commercial PBX internally to support its telecommunications needs"

   SAY WHAAAAAT!! So, the creators of asterisk, who provide us with these wonderful, glitch free :rolls eyes: upgrades.. DO NOT even use their own system????

   Holy Shiznit! You must be kidding me. That is REALLY bad. How can an end user possibly feel comfortable using a product when the developers of the product themselves apparently have no confidence in their own brainchild.

   Shockingly Stupid!

2. This definitely explains some of the problems I have been having, but it also completely derails my thoughts of reinstalling tonight on the test rig.

   Any chance that the "PIAF 1.7.5.6.2 ISO" will leave something in /root/nv along the lines of "full_check_o_install" that when run gives a thumbs up or thumbs down on the state of the bits? I found that when I dialed "DEMO" from my first SIP Soft Phone that it was trying to connect to SIP/demo@nerdvittles.kicks-ass.net but never was the call answered. I assume something did not install correctly, so the first step was to consider reinstall.

   Thanks for all the work, and I look forward to testing things as soon as the bits are released.

   [WM: All current installs now check for install integrity. New 1.7.5.6.2 ISOs should be available on SourceForge within the next few hours.]

3. … that’s why most of the major developers/contributors to the FreeSWITCH project who work at Cudatael insisted that the Cudatel PBX be able to run directly on top of FreeSWITCH checked out from GIT. That way at least the devs are able to push out the latest version to as many as possible to make sure everything is working fine without patches.

4. PIAF need to switch or at least support freeswitch.
   super cool, fast, fully interoperable, easy manajability and greater integrability.

5. Howdy,

   In 2006, Asterisk 1.4 was released. Since that time, we’ve been fixing bugs as users have found them. We’ve not been able to address all of them, but we’ve done a reasonably good job. It’s been four and a half years, and the time has come to move on.

   The community of Asterisk developers, including Digium, agreed that eventually bug fix support would come to an end. The agreed-upon time has passed. Digium cannot continue to devote resources to providing bug fix resolution for 1.4 or 1.6.2. Doing so makes it more difficult to ensure the ongoing success of Asterisk 1.8 and future versions. We need to move the project forward. The more focused we can be with our engineering efforts, the better the project is going to be. Digium will continue to provide security fixes for both Asterisk 1.4 and 1.6.2 until April of 2012.

   Articles like yours don’t seem to serve any constructive purpose. They don’t encourage positive action. They don’t inspire others to help better Asterisk. No one’s going to decide, based on the article, to hire a new person or deploy an existing person to write enhancements or issue resolutions, Test Suite tests, or manually test for bugs within Asterisk. Articles like yours are just smear.

   You’re missing the point that Asterisk is an open source project, maintained and managed by Digium. To make the project as strong as it is, we need community members that contribute to making it better. This comes through code submissions for new features, bug fixes and security issues and testing. Asterisk works with many different endpoints and Digium has no way of regression testing with each and every device before a release is made. There are certainly many Cisco endpoints that can connect to Asterisk via SIP, but this is where a true community member can contribute, not criticize, by helping the project with testing and constructive feedback.

   Asterisk 1.8 will be widely adopted in the commercial marketplace. There is hand wringing about 1.8 just as there was about 1.6, just as there was about 1.4, just as there was about 1.2. Prior to 1.8, there was outcry that 1.6 was a sub-par release in comparison to 1.4. Now that 1.8 is out, we have similar declarations that it’s a sub-par release in comparison to 1.6. This isn’t new; it’s the cycle repeating itself. We’ll have the same group of people, upset when 1.10 is released, one day declare that 1.8 is the only way.

   Every software defect is embarrassing. At Digium, we’re focused on making Asterisk better for the world. With respect to the mentioned issue, it arose as a regression introduced after bug fixes to respect SIP Via headers, which were being ignored in violation of RFCs, were introduced. There was open participation in the creation of the patch to add the Via support, and parties inside and outside of Digium collaborated. A patch to fix the subsequent regression that affected Cisco phones was made, and will be included in 1.8.5; but it wasn’t made inside of the 1.8.4 release window.

   Digium has already staked its business on Asterisk 1.8; and, as always, we invite community members to contribute.

   To the question of Digium’s use of a commercial PBX internally. You bet we are. We make full use of Switchvox, our commercial unified communications solution. It’s great! You should try it. We have a 30-day free trial of the full-featured SMB version, and we’ve also got a fully-free Home version. We also use straight-from-SVN Asterisk 1.8. If there’s any confusion about whether or not Digium internally makes use of Asterisk of Switchvox, call me first next time. You’ve got my number.

   Cheers

   P.S.

   We appreciate the comment that 1.8 has been very stable since its initial release. We think so, too; certainly as compared to previous releases. Each one gets better. We’re just sad that it took you six paragraphs of mud to get to the admission that 1.8 is a great piece of software.

   [WM: Mud is in the eye of the beholder, I suppose. Recommending a software development strategy that has worked incredibly well for Novell, Microsoft, and Google didn’t strike us as mudslinging. In fact, it’s more than a little surprising that you can find nothing constructive in the entire discussion.

   As for the merits, it’s disingenuous to paint this as hand wringing over the coming of Asterisk 1.8. We’ve been one of the most vocal proponents of Asterisk 1.8. If you’re unaware of the contributions by the PIAF development team and the literally hundreds of technical experts on our forums who have embraced (and debugged) countless versions of Asterisk 1.8, then you need to spend a little more time getting out in the world.

   Our bottom line with Asterisk 1.8.4 is that Cisco invented VoIP. Their share of the VoIP market compared with Digium is not unlike comparing Google to Yahoo in the search business. To release a version of Asterisk that breaks every 79XX Cisco phone on the planet is unacceptable, plain and simple. From your vantage point as a paid Digium employee, you see it differently and that’s fine. But the name calling is quite unnecessary. You get paid to disagree. Let’s leave it at that.

   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. That makes a huge difference in terms of results. After using Asterisk 1.8.4, we can certainly appreciate why Digium has chosen to rely instead upon the SVN version. But the fact remains that production releases of Asterisk 1.8 shouldn’t be beta-quality code especially when compared against experimental SVN builds. If Digium makes such heavy use of SVN builds, I can’t help wondering what went wrong when 1.8.4 was actually the SVN build. Did no one notice when the Cisco phones stopped working, or perhaps Digium doesn’t own a single Cisco telephone set? That’s a little hard to believe.

   Finally, your touting of a commercial alternative only adds insult to injury. The net effect is to reinforce what many have long suspected to be the hidden agenda in corporate-sponsored open source projects. That’s unfortunate.]

6. I’ll just throw my opinion in here, for what it’s worth. I think that both the Asterisk and the FreePBX developers have the same problem, and it’s sort of similar to what you find in some religious groups. And that is, they tend to develop their own view of the world (or their software) because they are mostly talking to each other. They don’t see themselves as the world (or the bulk of their users) sees them. They have a certain inner circle that communicates with each other, and when that group decides something is important, it will be addressed, and if that inner group decides it’s not important (or disagrees with those not part of the insider group about the importance), it won’t be addressed.

   My current peeve with Asterisk is that incoming Google Voice calls aren’t working as they should, so we have to resort to various hacks to make our calls come in (or get a DID and use that). I realize that Google apparently did something that caused the problem, but it seems that no other hardware or software that offers Google Voice support (at least none I’m aware of) is having this issue, just Asterisk 1.8.x. However for the moment I’m willing to cut them some slack because of all the problems they had following the recent tornadoes in their area. But still, it seems to me that fixing that ought to be at least somewhat of a high priority, because quite a few people installed Asterisk 1.8.x in the first place just to get the GV support.

   But mainly I just wanted to voice agreement with those who are suggesting that you should consider releasing a version of PiaF that includes FreeSWITCH. I understand that FusionPBX (a GUI for FreeSWITCH) has undergone some upgrades recently so you might want to look at that as well. I’m certainly not saying that FreeSWITCH is perfect, and the big problem you’d have in getting started with a FreeSWITCH/FusionPBX package is the lack of really good documentation. But I do think that those folks have not yet gotten so big that they just don’t seem to care anymore. Even if you tried it for six months or a year and decided it wasn’t worth the effort, at least you’d know what the differences are between the two types of software.

   And there are even other options (one I’ve heard about, but don’t know much about is YATE, which has the advantage of being open source, cross-platform software, but for some reason I suspect it doesn’t have the features of Asterisk or FreeSWITCH).

7. WM: You respond to the bug with Cisco 79XX phones like this:

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

8. Even if we do have a 79XX phone lying around somewhere, that doesn’t mean we are going to be testing it all the time. That’s part of the whole open source social contract. We provide you (the community) with software with which we let you do whatever you want (for free no less), and in exchange, you (again, the community) provide us with an army of testers and guinea pigs so that we become aware quickly when such and such piece of equipment won’t work with our software. Personally I think this is a fair exchange, and if you are unwilling to be a guinea pig for constantly changing software, you have the option of sticking with a stable release for as long as you please so long as it suits you. If 1.6.2 is so awesome and 1.8 so unusable, by all means stick with 1.6.2 until 1.8 has what you need. 1.8 being the premier version right now just means we’ll have the opportunity to catch up with whatever it is you need from it much sooner.

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

9. +1 on the suggestion to explore freeSWITCH. I’m not the VOIP expert many of you are, but I’ve experimented a bit with sipXecs and the stuff the 2600hz.org guys are doing. They’re weak on documentation, tutorials, quick start guides, etc., but it seems to me there’s much less drama between devs and contributors.

10. +10 for a Freeswitch alternative. In fact I hate FreePBX for the same reason I hate Digium’s decisions in making changes so quickly and breaking functions while they can avoid it. Maybe it’s time for a new group of volunteers to put up something better as an alternative based on FreeSwitch that can compete with FreePBX and Asterisk as well.

11. I second to the opinion, no doubt FreeSWITCH seems to be taking over and sipX can be good option for distributed architecture solution.

    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 🙁

12. I’ve been to Digium’s HQ in Huntsville. They use Switchvox (which last I checked, ran a deeply patched version of Asterisk 1.2) and Polycom phones in production.

    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.

13. As someone who has been involved in the design and deployment of “bleeding edge” technologies – first display paging service, first cellular system operator, first satellite VoIP network designer / operator – I think I have a fair appreciation for the situation that currently confronts us.

    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.

14. Trying the ./1833.sh script and I am getting these erros right at the start. Probably not a big issue but maybe Ward Mundy can have the team look at it – Regads

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

15. Greetings to all my fellow OSS telephony users!

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

16. Now appears to be a problem with Polycom TLS phone registrations as well.

17. What ever happened to people taking responsibility for their screwups? I don’t think Ward is on a smear campaign. He’s stood behind Asterisk for years through all the ups and downs. Pointing out problems that are crippling to an organization using Cisco phones and finding a way to mitigate that damage for PIAF customers is how things should work. Did any of the Digium posters offer a fix/workaround/solution or at least a time line on it being taken care of?

18. I back up this: 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, and I still can’t digest the reply from Digium to someone who has stood behind Asterisk for years through all the ups and downs… (which has also been said here)

19. ward:

    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.

20. I’m very confused and surprised, I have been using "incredible pbx" a test mode for some time, I like it because it integrates "google voice" and more functions, I had to format the pc I had installed the system and if it was working well, I have Polycom, then the installation process "incredible pbx" is long, which is the version that you recommend for use in production?, thanks for everything, and I hope this does not stop this wonderful project

21. Huge Asterisk fan, using in call center production, but my gosh Malcolm, you come off as "jerky" at best with the comments and your later replies No real flames here. Maybe just stress. These guys are on the Digium side (I mean look at the years and years of history with Ward)…take advice, fix and don’t make the same mistakes again.

22. Hopefully, things will get better. However, after reading Rod Montgomery’s comments in this thread on the FreePBX Forum, one has to wonder.

23. Totally agree. Any commercial company MUST eat their own dog food. The excuse of "Digium uses a commercial PBX internally to support its telecommunications needs" might have been accepted 5 years ago but not today.

24. PIAF Forum: Should Digium Get a Pass on Quality Because Asterisk is Free?

25. As someone who commercially supports a few Asterisk installs, I have given up on upgrading it. They break their API at any time with no hesitation so my external scripts break.

    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.

26. Lasse,

    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.

27. I agree with MichiganTelephone. The asterisk culture is very similar to the mac culture. I’ve used asterisk and had so many issue with it… for instance a bug causing high CPU usage in 1.6.1 was supposed to be fixed in 1.6.2
    i upgraded in production, turned out the bug was more severe in 1.6.2 and actually crashed asterisk… i wouldn’t recommend any version of disasterisk for production, maybe for you home as a hobby. Telephony needs to be 99.999% available and asterisk simply cannot provide that.

28. Second vik’s comments. As an old telephony professional, for many a small to large business, the hang on the wall and forget it commercial system that doesn’t require babysitting and isn’t built on the fragile pc based platform is the choice that the wise businessman should select, at least for any business that relies on the telephone for their survival.
    For some specialized applications the above may not apply.
    I feel sure many will disagree.
    I won’t even bother to address some of the basic design flaws in Asterisk, the lack of understanding of some basic telephony concepts that have been, or not, fixed over the years, and any consideration of the user.

29. I trust more in piaf, and I would like to hear the final verdict asterisx, or recommendations because I need to install the PBX in a company with over 300 employees, 24 x 7, and I’ve been trying for years piaf, now that I have decided it is a waste for production. I welcome your recommendations, thanks for everything

30. Everything is working fine again, just change the polycom by another, just download the iso, install the purple and ran the scrip to set the voice google account, I already made my calls I needed, I will only monitor its operation and we will see if we put it into production, thanks and congratulations to the team piaf.

Comments are closed.