[Asterisk-Users] IBM to Run VoIP On Linux

[Rich Adamson]

> Asterisk has got to be about the best kept secret in telephony.  I've seen
> numerous articles on slashdot about VoIP, even in relation to Linux and
> only *once* has the post even mentioned Asterisk.  Am I missing something,
> or is Asterisk clearly a good potential player in any kind of linux-based
> soft-switch idea?

There are probably as many opinions on the topic as there are members of
this list. Personal opinion based on many years of professional I/T
and telecom experience is:
 - no marketing plan that list members can internalize (eg, no one knows
    where the project is heading, what's on the planning plate, when
    something will be released, or when problems will be corrected).
 - no formal/stable releases and associated components (as others have 
     already noted)
 - poor documentation for a very sophisticated product

Others have mentioned the product is lacking some feature or function,
however those are probably related more to single instances of not being
able to sell the product into "a" certain account, loosing a sale
because some competitor sold a customer something that asterisk didn't
have at the moment, or, inadequate skills to find a programming solution
to some customer-needed function. I doubt the feature/function issue has
anything to do with world acceptance of asterisk (except for better
nat support).

The poor documentation is evident by the number of "how-to" postings that
have been occurring, the many arrogant responses from a select _few_ to
newbie questions, and helpful examples that are so dispersed that
finding them tends to consume inordinate amounts of time. The Handbook
does a good job from an introduction perspective, but between it and getting
to a basic working system is a significant and very time consuming problem 
(and that's coming from a person with 20+ years of central office, pbx,
and transmission engineering experience within a telephone company that
had over 8,000 employees.) If a newbie can't read C-code and hasn't 
been involved with any form of pbx from a technical perspective, the 
frustration of getting even a SOHO system operational is extremely high.

John Todd's sample config's have been a good first step for newbies, but 
the average newbie doesn't have clue where to find them (as one example 
only) until after burning up the list with questions. After internalizing
those configs and then looking at someone else's config for some specific
function, it is not obvious in many cases how to integrate the two as:
a) the second set of config's are not used in the same context as the
first set, and, b) there is no base set of config's that would
provide such an integrated understanding.

If I were a trade rag evaluator/writer/publisher, I'd have to give up on
trying to do much with this product as I'd run out of time trying to
locate enough info to make it work in some acceptable pbx fashion.

Although I have a small SOHO system running in production (with fully
functional internet-based nat devices), I'm hesitant to suggest/recommend 
an asterisk-based system to clients right now because of the above items.
Having been in the technical consulting business for over ten years now, 
I know without a doubt what it takes to support something like this, and
I think several people on this list have already hinted that its far more
difficult/time-consuming then most readers would anticipate.

The more knowledgable list members have sufficient experience to find
ways to address 99.9% up time, their own set of integrated feature/function
configs, etc. But those few are "not" going to be the ones driving
digium hardware sales upwards at a level needed for ongoing support.
I'd suggest that a few not-so-time-consuming steps would lead to a
significant increase in hardware and support sales, and therefore
system acceptability and exposure. (Eg, 1000 newbies buying one/two 
x100p's have a greater financial impact then selling a few TE410's; 
1000 newbies will create more industry exposure/acceptance then 10 
highly skilled asterisk people that support their customer base.)

I'd suggest something like the following to improve its acceptance and 
thus hardware sales (listed in priority order) and exposure:
 1. Stop all new development for 30 days, fix existing problems, apply 
    outstanding patches, and document (implementation/user, not developer)
 2. get a stable release approach that "includes" a fully functional base
    system where 95%+ of the features actually work (with no echo, with
    nat working for newbie's, etc).
 3. include in the stable release sufficient base-level config's that a
    newbie has a reasonable chance at implementation "without" having to
    post questions to the list or dig through 1000's of google items.
    (think about this very carefully). Might even include a url at the 
    top of each config file "where" to look for sample config help, etc.
 4. take a list of typical pbx features, develop the "integrated" asterisk 
    configs and scripts necessary to implement those features, and publish 
    those in some common web or distro directory.
 5. improve the printed documentation shipped with the hardware. (Those
    single-sheet instructions are missing several required steps, and 
    have zero examples.)
 6. document the basic user-oriented functions (eg, where is the list of
    *72-type functions). A user-guide would be nice.
 7. publish, at a minimum, a TO-DO list that has some form of list
    "prioritization" of feature/function/problem-resolutions and
    estimated release timing.
 8. Put together a marketing/sales plan for support and publish it on your
    web site. What's included; how to contact; options that might address
    an annual contract, per-call support, feature implementation, off-hour
    support, flat-annual-fee based on number of phones, etc. I, for one,
    would be interested in a commercial support plan based on a single 
    700-number or email address to reach help for certain items including 
    configuration assistance.

There certainly are a number of list members, including myself, that would
be willing to help with the effort, but someone has to take a lead role
and establish some common direction that does not exist today.

Rich