On Wed, Jun 24, 2009 at 11:11 AM, David Backeberg<[email protected]> wrote: > On Wed, Jun 17, 2009 at 7:10 PM, Marshall > Henderson<[email protected]> 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 _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
