Asterisk and fault tolerance & embedded solutions.

Discussion in 'VOIP' started by Charles Hizark, Mar 5, 2004.

  1. Here is a interesting perspective on Asterisk I ran across:

    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,
    still have calls in progress that remain active until the calling
    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
    configuration. I bet this is possible. Especially with the newer hot
    cPCI bus systems and slave CPU cards. Even better if the chassis has
    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
    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
    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
    on it's own guts.

    8) 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
    the first four I would really like to hear that person tell me off.
    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
    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

    Don't forget the training aspect as well. I hope the person has time
    learn a new system. The quirks involved with it. Plus the problems
    integrating it with their current system(s). There a lot to be said
    thoroughly knowing the call routing logic of a single system well.
    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
    when those two systems are actually two different platforms as well.
    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
    doubt he would be awake to enjoy it. Or even if awake, have a steady
    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
    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
    to play with. I even have a line on some free JCT boards to set it up
    It's a great platform to learn many aspects of computers and
    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
    For I am certain it's suitable to many purposes. Maybe some of them
    even yours.
    Charles Hizark, Mar 5, 2004
    1. Advertisements

  2. 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.
    Brad Templeton, Mar 5, 2004
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.