[asterisk-users] Redundant Connectivity

[Marshall Henderson]

On Wed, Jun 24, 2009 at 11:11 AM, David Backeberg<dbackeberg at gmail.com> wrote:
> On Wed, Jun 17, 2009 at 7:10 PM, Marshall
> Henderson<marshallmch at gmail.com> wrote:
>> architecture, etc. On a brand new dual or quad core xeon type
>> system(quite likely multiple physical CPUs, each with multiple cores),
>> And finally, are there any hard or soft limits to be concerned about
>> in regards to the number of simultaneous calls a system can handle? As
>> mentioned, the server function will be purely routing, no other
>> services available. Can each server handle 500 simultaneous calls?
>> More?
>
> You don't mention anything about codec for SIP, and that changes the
> overhead per call. I've done 500 calls on similar gear without
> breaking a sweat. You should have the same result. I have no clue
> about your questions with regard to IAX.

Our calls will be either g729 or uLaw but will all be passthrough.
There will be no transcoding happening.

>
>> I'm planing to use Asterisk 1.4.x for this project as it's stable and
>> works very nicely in my existing systems. 1.6.x seems to be a bit too
>> bleeding edge... If there are specific examples why 1.6.x would be a
>> better choice, I'm all ears. Or, is 1.2.x or 1.0.x the way to go? :-)
>
> there have been a series of security fixes, so if you go 1.4.x make
> sure you are going with recent revisions or mitigating the risk of
> using an old version. You can always read the change log for the 1.6.X
> versions to find out what you're missing by living with old versions
> of asterisk. Mostly you're missing changes to underlying performance
> enhancements, and 'new' features that many of us have been using for a
> year plus.
>

The general 'feel' I've been getting from reading the lists and
various forums is that 1.4 is the 'tried and true' version while 1.6
is still too new/bleeding edge/untested/unproven/etc to be used in
production. Is this incorrect? I've largely stayed away from it at
this point...

> Some people will say that 1.4 is too bleeding edge. You need to burn
> in any solution you choose if you want to be satisfied that the result
> scales appropriately and reliably. Callfiles, a while loop, and
> logging come in handy there.

That would be my preferred testing methodology as well. I'd likely put
some looping dialplans to keep the calls running, generate a bunch of
call files from another box and see how the target box handles the
load. Of course, proper logging of Asterisk, system stats, etc are all
necessary.

Marshall