[asterisk-users] Is Asterisk ready for Prime-Time?

Thu Mar 20 08:03:04 CDT 2008

Appologies for top-posting. This is the most interesting thread in a
long time. Alex, yours is the most well considered opinion I've seen in
a long while. I exactlt reflects my own, moerw limited experience.
Thank you for chiming in.

Two weeks ago on the VOIP Users Conference weekly call we had as our
guest Pika Technologies who are a Canadian company that make T-1/E-1
and FXO/FXS cards for Asterisk. One of their statements was the fact
that they don't rely on Zaptel for their driver. They have their own
driver which is unrelated to Zaptel.

Does anyone here have any experience with this? Is it markedly better,
or just more obscure and so harder to support?

Michael

On Thu, 20 Mar 2008 00:59:08 -0400, Alex Balashov wrote:

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

--
Michael Graves
mgraves<at>mstvp.com
http://blog.mgraves.org
o713-861-4005
c713-201-1262
sip:mjgraves at pixelpower.onsip.com
skype mjgraves
54245 at fwd.pulver.com