Asterisk Dimensioning: What server do I need?

By Sean Pimental

In our training classes, we’re frequently asked to recommend hardware specs for an Asterisk server in a given setting. We welcome the “mini consulting” opportunities we get by interacting with students in live training classes, but this particular question continually challenges us. Unfortunately, there’s no “magic formula” we can use or recommend to answer the question easily. But the fact that there is no simple answer doesn’t mean there’s no answer at all. Keep reading for a rundown of the various factors we consider when assessing just how beefy the hardware running your Asterisk system needs to be.

As a general rule, you should always purchase hardware somewhat beyond your expected needs. In addition to providing a capacity buffer at the outset in case your estimates were off, this also affords you some room to grow without having to buy more hardware. Testing your hardware as thoroughly as possible before deploying it is also essential. Many (but not all!) capacity-related problems can be identified in a dry-run test of the equipment before it’s formally deployed.

But we still haven’t addressed the basic question: How much server do I need? As stated above, there’s seldom a concrete answer to this question. Listed below are several considerations you should keep in mind when determining just what you need, and a brief description of how they should impact your thinking.

1. How many concurrent calls do I expect?
This is perhaps the most obvious and basic consideration for the size of your system. You should spec Asterisk for the peak call volume, and not the average call volume. So figure out the maximum simultaneous calls you ever expect to have, and use that number. In general, if you expect fewer than 20 max concurrent calls, any off-the-shelf PC or server will work. Any more than that and you’re looking at dedicated server-class hardware.

2. How many external lines and internal endpoints will I have?
Keep in mind that if you’re using SIP phones, such as Digium’s phones designed specifically for Asterisk, they’ll generally register back to Asterisk on a regular basis – be aware that even idle phones can still consume system resources on the server.

3. What call services will I use?
Call recording, conferencing, queues, and audio transcoding are all more resource-intensive than simple pass-through audio calls. Add processing power, RAM, or storage space if you use many call services.

4. Will the server only provide Asterisk service?
It’s common especially in SOHO environments to use a single system to handle many services: Your PBX might also be running your web server, database, or mail server. If possible, avoid this! If you can’t avoid it, at least spend the money to upgrade your server so it can comfortably handle all the services it needs to. What’s worse than a down PBX? A down PBX at the same time your email and website are down, too.

We still haven’t offered much in the way of hard numbers. And unfortunately, we’re not going to. There’s just no way to offer specific details with any reliability. Hopefully, having a list of some of the most important considerations will at least get you started down the path of identifying what hardware you need. And hey – if you really just can’t live without a specific recommendation for hardware customized to your particular circumstances… come see us in class! We’d love to talk with you one on one in a classroom setting, where we can give even more detail. There’s always a list of upcoming classes at

Related Posts

There Are 5 Comments

  • How about memory requirements per sip channel, cpu power etc.

    I understand you can’t be too specific but this summary is neither more or less useful: “You need a server that will meet your needs”.

    I thought I was going to find an informative, interesting post. I was sadly disappointed.

  • james.zhu says:

    i think the dimension should come out with number of calls, recording, queue, transcoding with different versions of asterisk.

  • Jose M. Velez says:

    I agree that this article is lite or empty. Dimensioning Asterisk is not easy and anything you write would be obsolete in the next Asterisk generation. Also we must face the issue that it is difficult for Asterisk to be accepted in a large corporation with large installation. The IT would usually like to cover their “back” and select name brands like CISCO, AVAYA or others with 4 to 5 times the cost of Asterisk with high maintenance cost and support. All of this with less features than Asterisk. That applies to most Open-Source product. Consultants do not like to recommend an Open-Source product since their fees would be hard to justify. How much can you charge for an Open Source mail solution instalation vs Microsoft Exchange. The same applies to an Asterisk solution.

    I think that dimmensioning is important in a server redundancy or no fault should be addressed. Cooling, Redundant Power supply, SSD drives, RAID are important size this equipment must perform 24X7 without airconditioning in Weekends and night and usually in a poor ventilated PBX closet.

  • David Duffett says:

    I would take issue with some of the comments made so far!
    Dimensioning Asterisk, while dependent on a large number of variables, is indeed possible. A number of Asterisk appliance manufacturers have been very specific about the capabilities of their offerings. Here is one example:
    CPU: Core 2 Duo E8400 3 GHz
    RAM: DDR2 1 GB 800 MHz
    Echo Cancellation Tail Length: 32 mS
    Codec: G.711 alaw
    Maximum concurrent call: 480
    The above is taken from an Asterisk appliance manufacturer’s website.
    The reasons a lot of people shy away from publishing hard information about Asterisk server performance include not wanting to get into arguments if others get different result; not wanting to share information with competitor; – but the largest reason is the massive list of variables that can affect performance.
    What Sean’s post did was to highlight some of the most critical factors to take into consideration.
    I strongly disagree with some of the comments about getting Asterisk accepted as a credible solution for large scale enterprise deployment…

    Here are some examples of Asterisk going large:

    1. Olle Johansson of Edvina (Sweden) has a documented case of getting more than 11,000 (yes – eleven thousand) calls with full audio concurrently supported on one (yes one) server.
    And what stopped the call count getting higher? The Gigabit Ethernet got full!

    2. Intuit Innovations (Malaysia) supplied a system based on a number of clustered Asterisk servers (and SIP proxies) that supported 10,000 concurrent calls and 130,000 users!

    We are way past having to prove Asterisk for most deployment situations…

    As for not being able to charge a reasonable price for a solution based on Open Source Software – this is a limitation of you as the seller of such a system, not of the solution.
    A competent sales person will sell on value, not price – in other words, they will demonstrate that their solution meets the needs of the customer. Once this is done, the price is dependent on what the customer is prepared to pay – it does not matter where the system comes from. What the customer is worried about is reliability and support, and that is down to the organisation that has built and will support the system.

    Yes, the codecs used, transcoding required, recording or not, etc. will all affect the number of concurrent calls a given server will support – but you will not know the answers until you stop talking about it and go and actually do it!

    Most successful Asterisk integrators have settled on a given server build by testing things out iteratively until they come to a combination of components that supports their required functionality and system scale.

    If you’ve already done that, why not add a comment with your results to help out these dudes that just want to moan about stuff 🙂

  • SHIVAN says:

    Hello can someone please advise which brands of desktop motherboards work well with the B410P Card other than Intel boards?

Add to the Discussion

Your email address will not be published. Required fields are marked *

About the Author

Sean Pimental

Sean is a Digium veteran, working various roles from Hardware Test Technician, Software Technician, Product Quality Lead, Training Specialist, and currently a Systems Engineer. He has a Degree in the Science of Business Administration from the University of Alabama in Huntsville.

See All of Sean's Articles