Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > VOIP > Asterisk and fault tolerance & embedded solutions.

Reply
Thread Tools

Asterisk and fault tolerance & embedded solutions.

 
 
Charles Hizark
Guest
Posts: n/a
 
      03-05-2004
Here is a interesting perspective on Asterisk I ran across:


http://groups.google.com/groups?hl=e...ws.com&rnum=14

Not blow anyone's ASTERISK bubble BUT,,,,,,,

Show me an Asterisk system that can:

1) Have a communication bus that can survive the removal of the CPU,
and
still have calls in progress that remain active until the calling
parties
hang up.

Difficult problem to solve. One would have to have some sort of
parallel network connection. Perhaps one could have a buffering or
cache solution.

The CPU problem could be solved by a blade server or failover.

2) I have yet to hear of any Asterisk box running a fully redundant
CPU
configuration. I bet this is possible. Especially with the newer hot
swap
cPCI bus systems and slave CPU cards. Even better if the chassis has
and
embedded H.110, or equivalent in LAN/memory, switching bus.

Yes could be solved.

3) A redundant configuration where either CPU can talk to the
communications
boards (T1/E1), and LAN interfaces. And which can address all boards
in the
system redundantly.

Sounds like a job for Infiniband or a platform that has a switched
crossbar architecture like IBM P-Series or Sun.

4) A redundant configuration that has either shared system memory
between
the CPU's, or at least table copies between memory that hold all
static and
dynamic call information.

5) A redundant configuration that can swap between system CPU's in
less than
20 seconds.

6) A redundant configuration that can synchronize on, and share one,
two ,
and more network clocking signals. Plus synchronize on a independent
stratum 3 or greater clock source.

7) And can support 1,000 or more endpoints (TDM and/or IP) without
choking
on it's own guts.

A redundant configuration that can synchronize on, and share one,
two ,
and more network clocking signals.



Well there is a lot to consider, but with the right hardware the
problems can be overcome.

Heck, if someone could even educate me that an Asterisk server can do
even
the first four I would really like to hear that person tell me off.
I'll
buy you a beer to do it as well.


I am not against the Asterisk idea. It's a fine idea. And with
boards from
eBay, it can even be relatively low cost.

But Paaaaallleeese! do try to pass the server as either free, or
entirely
robust. And for the project the gentleman has in mind, he will have
to pay
for compression licenses. Granted that they are fairly low cost, but
not
free.

Don't forget the training aspect as well. I hope the person has time
to
learn a new system. The quirks involved with it. Plus the problems
in
integrating it with their current system(s). There a lot to be said
for
thoroughly knowing the call routing logic of a single system well.
Rather
than knowing two different platforms, half well.

Especially when it your personal time and reputation at stake; at two
in the
morning trying to do call tracing between two disparate systems. Even
worse
when those two systems are actually two different platforms as well.
God
help that poor soul in the call center. Should he live through the
experience I would by the individual a mercy shot of whiskey. Though
I
doubt he would be awake to enjoy it. Or even if awake, have a steady
hadn
to raise the glass to his/her lips before it sloshes out.

Open-source is great as well. Just don't forget that to change an
open-source iten, you have it know it well. And you have to know how
to
code well. Otherwise you will be stuck trading T.A.C./Support costs
for the
price of hiring a sysadmin, and/or a software coder, and/or a hardware
person (to either build h/w, or code drivers), plus a field tech
trained to
work with the system inad install it (so you can have a vacation).

Now with all this said I know I am going to build and Asterisk server
myself
to play with. I even have a line on some free JCT boards to set it up
with.
It's a great platform to learn many aspects of computers and
communications.
I suggest anyone out who is wondering about the system do the same.
Evaulate the platform for your needs, and it's suitability to the
purpose.
For I am certain it's suitable to many purposes. Maybe some of them
are
even yours.
 
Reply With Quote
 
 
 
 
Brad Templeton
Guest
Posts: n/a
 
      03-05-2004
One of the nice things about VoIP is that you don't have to design
the system so that you can handle removing CPUs or dying machines.

VoIP can be, if it weren't for all our firewalls, peer to peer. The
RTP audio stream should flow directly from phone to phone, no proxies
in the way.

The proxies that handled the signalling can happily die with a call
underway that they signalled. If they handed signalling control over
to the phones after call setup, they don't even have anything else to
do. If they insisted on being proxies for the hang-up and other
possible events, then if they die, the call hang-up won't work quite
right, in that the first phone will say BYE and never get an ACK, and
then give up, and the other phone will perhaps do the same.

If the proxy in the middle saved its state out as it was running, it can
die and another system take over and handle the rest of the call without
a problem

Trying to design fault-tolerant hardware where you can pull out a CPU
is the wrong approach. It still can be handy, and is able to handle
faults in the middle of a transaction, but otherwise fault tolerant
protocols are much better than fault tolerant hardware.

Of course, SIP could do better at the fault tolerance and probaby will
in the future.
--
Tour Greece, Turkey and the Black Sea in my photojournals
http://www.templetons.com/brad/photo/europe/
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
get most common number in a list with tolerance Astan Chee Python 0 02-20-2009 08:50 AM
RMI, fault tolerance and load balancing without tomcat apm35@student.open.ac.uk Java 11 02-19-2008 05:08 PM
TIBCO EMS Fault Tolerance Vijay Bajwa Java 0 06-12-2007 09:11 PM
YAML::Syck fault tolerance Phlip Ruby 2 01-21-2007 04:42 PM
How's the fault tolerance when mounting a drive as a folder? Dandelion MCSE 1 06-19-2006 04:27 AM



Advertisments