Very interesting thread! My general sense, being both a person of heavy UNIX systems programming and modest telco background, and as an Asterisk enthusiast, is that Asterisk itself is quite production-worthy as such. Experience suggests that what is controversial about it from a business standpoint, in terms of total cost of ownership, support, and dependability, are many things rather ancillary to it that contribute to the overall experience of an Asterisk-based system as a product. Some of these pitfalls have already been pointed out with regard to the shortcomings of consumer-grade PC hardware, hard drives, power supplies, etc.
In other words, it seems to me that you can't just throw up an Asterisk box as such and have it perform to your expectations. My experience with the few Asterisk based IP PBX appliances that claim to be thusly turn-key has been very poor, although, in their defense, it's been a while and I'm sure those platforms have come a long way. But overall, the domain of expertise required to make Asterisk work well in an environment demanding of high availability is of a scope considerably beyond Asterisk itself, and amounts to a fairly broad nexus of network engineering, *nix systems administration, and so on. Most generalised -- and, to some extent, highly specialised -- IT savvy is required, as can be true with anything open-source and not packaged as part of some immaculate, embedded black box culturally or technically. Asterisk works well if deployed in a manner that brings quite an array of skills to the table in a rather comprehensive way. In and of itself, it assures little. This conclusion is supported by the differences in my effort expended to support and (re)engineer third-party Asterisk installations of varying quality and sophistication. And of course, what I am saying here applies to most other things as well. It is possible to set up Apache or MySQL or Linux itself naively, "from the heart," as well, as many do, or to do it in a nuanced, refined manner that is attentive to the specificity of tight production requirements and capitalises upon considerable expertise. All Asterisk setups in which I have been involved have generally involved a from-scratch custom compile of Asterisk, zaptel (if necessary), and very frequently - especially if the latter is required - a hand-compiled kernel as well. I do not use Trixbox, any Asterisk administration front-ends, IP PBX appliances, and so on. I can't really comment on their respective merits, but even if I could, I feel strongly compelled to point out that this would be more of a referendum on particular vendors or integrators who have packaged Asterisk a certain way than about Asterisk in principle, which is something several people have already said. If all of the nuances of a hand-maintained Asterisk configuration are observed, I think it's a pretty solid product in any event, but it does increase total cost of ownership for my clients as they have to find someone like myself or other Asterisk consultants on this list with the knowledge and experience to do that sort of thing. It's the same sort of dilemma that arises between investing a lot of faith in a stock CentOS or Fedora install by someone who "kind of knows a bit about Linux" vs. hiring a really knowledgeable Linux sysadmin, where the limitations of the distribution don't really matter because they're going to know what to do with it on a highly detailed level. The latter obviously gets vastly superior results, but costs a lot more money and time. At the risk of inflaming a lot of passions, including those of hard-working developers, I must say that where Asterisk may be production-worthy, the entire constellation of things (like Zaptel) of which its PSTN hardware interface capabilities comprise is absolutely not, if my experience is at all telling. Of course, that's not all Zaptel's or Digium's fault; much of it is just the buggy, flaky, and very inconsistent nature of PC hardware, the kernel, ${insert true culprit here}. Nevertheless, my only truly solid experiences with Asterisk have come in situations where it is used as a purely SIP agent. FXO interface hardware, PRI cards (Sangoma, Digium, Rhino, etc.) all have bugs, strange interop problems I've never seen before with big iron TDM switches or newer telco softswitches that generate those circuits, bizarre apparent interpretations of certain ISDN messages, and can cause system instability, lockups, etc. (Whether they are the true cause of it or whether that's just a consequence of their interoperation with the PC is unknown to me, and somewhat beside the point.) They've come a long way, I think. When I first used Digium T1 cards, little, basic things like B channels not being hung up properly were still a major and frequent theme. For low-capacity installs involving at most one or two PRIs, I think one may be all right at this point. But I still think it's experimental and avant garde from a production standpoint; I find myself frequently stressing to my clients how much better off they'd be just getting SIP termination and origination elsewhere and breathe easier. Sangoma seems quite all right. Rhino is OK, although as far as their multiport FXO interfaces go, it suffices to say there is a difference between making it work and making it work well. Their free support does go a long way toward that end. Your mileage may vary. Caveat emptor. In general, though, almost any installation with any TDM trunking of nontrivial volume is something in which I've ended up deploying dedicated ISDN VoIP gateways, most recently Cisco AS5300s and 5400s. In general, this is what I would advise to anyone thinking about terminating more than a handful of PRIs, let alone DS3s worth of traffic. Get proven, reliable hardware (even if it is expensive) from vendors for whom TDM and carrier-grade telephony is a core competency. I've seen far too many people try to take the cheap way out with a bunch of Asterisk-oriented TDM hardware and not get quite what they were expecting. Don't do it. There's something gravely perturbing about running T1s into a PC anyway, although I know it's been done in certain esoteric commercial telephony applications for eons. Other, similar considerations apply. In a nontrivial SMB environment, it is critically important to take the time to properly implement QoS. If your network sucks, so will your Asterisk experience. Build VLANs and segregate your voice traffic. Don't use cheap routers and base commodity unmanaged switches. If you're doing VoIP out over the Internet or interoffice, make sure you understand that you need a real Internet connection to a provider that is well-peered to have any hope of delivering this type of service, and even then, you're at the mercy of best-effort phenomena. Sure, you have to have enough bandwidth, but that by itself is almost worthless; there needs to be good, consistent latency, no/very low packet loss, and your users need a way of reaching you over non-congested backbones, ideally ones that are voice affirming in that they implement end-to-end QoS on their IP transit network. In the end, it boils down to the same thing, really. Asterisk by itself is just an element of the question. What you surround it with -- and how -- is just as important in the final analysis. Get good PC hardware. Administer the operating environment well. If you want to be providing VoIP services, take the time to research and colocate in a great data center with excellent upstream connectivity and fabulous QoS--to the extent that this is even possible. If you are doing extensive PSTN connectivity, make sure you get real hardware for it - don't think you're going to get away with a bunch of PCs. Don't try to use Asterisk where it doesn't belong; it is not a transit element for carrier service, but rather an endpoint. It's a PBX, a feature/voicemail/IVR destination, etc. It is not a switch, a proxy, or anything else. That's what softswitches, OpenSER, media gateways, etc. are for, so build your voice service platform on that. If you're using it as an SMB PBX, make sure you've thought through your phone question. Don't get cheap phones, as the SIP interop issues and overall quality hit is simply not worth it. Think about how you're going to do mass-provisioning and other ways the phones relate to Asterisk (i.e. NAT). It's pretty stable, except perhaps at the margins of some of its broad features (I've run into a few bugs with queues, but they weren't show-stoppers). What you get out of it is, much as with the sewer system or with anything open-source that isn't commercially prebuilt and packaged on proprietary, embedded hardware with all sorts of ASICs and VLSI and solid-state goodness, mainly a question of what you put into it. Do the right things - and for the right reasons - and Asterisk is utterly awesome. Do things willy-nilly, and you'll get willy-nilly results. -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users