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

[Alex Balashov]

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