[LINK] Asterisk Linux PABX

[Glen Turner]

r.polanskis at uws.edu.au wrote:
>
> It's also a question of scalability.  A PABX is often driven by
> an embedded OS and relies on various hardware to do it's switching.

Hi Rachael,

There isn't a scalability problem, as voice control is very different
from packet control.  The scalability issue in voice control is
making a routing decision in less time than the user even thinks
of hanging up.  And routing decisions are rare -- once per call
establishment. Even a PABX terminating thousands of lines might
make only a few routing decisions a second.

The way this is done on PABXs is by scaling the hardware. You
know that you'll never have to make more routing decisions than
50% of the number of extensions plus the number of outgoing circuits
on a external trunk.

So by limiting the extensions and trunks on the hardware you limit
the routing problem. Which is how PABXs got away with using 8 bit
CPUs for this stuff.

The "VoIP model" isn't subject to more routing decisions -- people
still make the same number of calls.  But the routing decision
hardware is usually more centralised, so it sees more load.  Even
so a program like Asterisk can route a few hundred to a few thousand
calls per second. That's in the order of a million lines.


The problem for the new technologies is the low cost of the existing
technologies (nb: cost not price).  Telco suppliers and carriers
have been robbing their customer blind, but the equipment itself is
very cheap to make.  And tools like Asterisk spell the end of that.

The problem is then one of cash flow. The telco or telco supplier
can accept a standard markup rather than an outrageous markup at
any time. So someone competing against that has to be careful that
their business can cope with that happening.

In Australia, the existing telcos also set the rules, and change
them when they don't suit.  So a competing business can't assume
that the regulatory environment will stay stable either.

The story is quite different for enterprises, which is where most
VoIP is happening. Even if the telco drops their price to $0 the
new technologies are cheaper as they only require one copper line
to each desk rather than two (and the price of the cabling is about
70% of the cost of getting Internet and phone service to a desk).
So whereever an enterprise has a 'greenfields' site which requires
cabling, then VoIP is cheaper.

> Then there is the question of call accounting, timing the call
> and being able to do things like conferencing and party line linkups
> and so on.

The newer technologies are actually a lot more flexible about
this stuff.  Very few "magical" limits.  My analaogue line will
only let me conference in two other parties, because of the way
the hardware works.

> I don't think linux on the X86 platform can scale like that without
 > the beefing up of the architecture to where the TCO becomes almost
 > equivalent to a hardware solution with a software control interface.

You're assuming the control protocols doesn't have built-in failover.
They  do. So although robustness is nice, it's not essential.  The
big problem is actually devices which interface back to the PSTN --
these carry across the "one 99.999% availability box" assumption
underlying the PSTN switching devices. So interfacing to SS7 is a
pain.

> Then, where are all the OSS billing systems?

There are none I know of.  That doesn't shock me, as there was
no great free ISP billing package either, and the VoIP billing
systems are usually add-ons to the ISP systems.

The voice routers pump out RADIUS records, so it's trivial to
write your own and interface it directly into your on-billing
and reconciliation. That's what we did.

> Are you going to trust the contractors who currently come out and
> do your PABX work to manage OK on the software based systems?

My experience has been "yes". Which surprised me. But they are
all expereinced technical staff, and the backend of these
systems has been UNIX for a long time. So moving the entire
routing to a Unix-like box doesn't seem a huge step.

I've had more trouble with Unix system administrators. You
say "this machine can't run anything else other than call
routing" and they don't listen. Then the trivial program they
added has a memory leak and clags the box...

That's the nice thing about "appliances", it limits the box
to one process and out-sources the systems adminstration
(which are also the two bad things about "appliances").

> What happens if the computer crashes (and it will)?   PABX
> systems rarely have critical "catch fire" situations and
> their simplicity actually protects them from the
> worst case scenarios as opposed to an evil X86 box that
> has all sorts of moving, volatile components.

If the computer crashes you re-dial and it uses the fallback.
That works.  My experience is that PABX crashes are much rarer
but are totally unrecoverable when they do happen (they are
meant to fallback too, but the nature of time-division circuits
is that they don't have the good peak capacity attributes of
packet-multiplexed data circuits, so you can find a non-congested
trunk to place a call on).


The new technologies have problems. And the cost of handsets is
at the top of that list.  Call routing isn't a problem.

There is a huge regulatory challenge.  The new technologies allow
differing grades of voice service. And some of them are not at all
suited to a "standard telephone service", but we're already seeing
some poor grade voice services pitches as standard telephone
replacements.  But to say that all VoIP calls must be of high
quality also missed the point.  There has a be a middle way, perhaps
with well-signposted service grades, or some generic rule that
requires a standard telephone service to a premises before other
services can be provisioned??  The ACA have called for submissions
on exactly this topic and it will be interesting to see what they
come up with.

Glen