We see this question a lot and have quite a bit of experience with Asterisk and high loads. We also see a lot of answers with incomplete or inaccurate information. To help clear any confusion, we decided to post the information that we have learned.

Put simply, for switching only, you can safely calculate max calls using 25 calls per gig of CPU processing power. So for example, you have a dual core 2g machine. That's a total of 4g of processing power. (4g)*(25calls) =100 calls. You can probably push harder, but that's a safe number.

When you start adding features, things change in a hurry. Issues like real time db lookups, ring groups, auto attendant and recording voice mail are resource hogs. The unpredictable part that makes it tough to calculate is that you don't know how often multiple features may be running at the same time. For feature servers we only calculate 2.5 calls per gig. So using the same box above, that would be (4g)*(2.5 calls) = 10 calls.

If you want more details, read on. There are a couple of factors that you need to look at:
1.   Asterisk itself really isn't a problem. Using it with many of the products that include feature management, like FreePBX does create issues. If you want features, you'll either need to learn a lot about dial plans, or deal with those limitations.
2.   Your network, router, switches and cards matter way more than you think. We see this misconception a lot with people asking why their call quality suffers with only 13 or 14 Meg of data on their 100meg network. Here is why, the throughput rating for backplanes assumes a packet sizes are 1500 bytes (typical data). RTP (voice) is generally 160 bytes per packet (g.711). The real issue is how fast your router process packets. So let's do a bit of math. 100m / 1500 byte packet is 66.67k packet/sec. Multiply that times the RTP packet size of 160 and you'll realize that if your network contains only voice, your max throughput is 10.6M of RTP data.
Uncompressed codecs use about 80k (with overhead). So assuming you have nothing but RTP you can process a MAX of 132 calls, but you also need to factor about 5% use for SIP and Qualify messages, and then any other network traffic.
Bottom line, make sure your network cards, switches, and your router's back plane and processor will handle the load. All 100Meg routers are not the same.

3.   The server matters. The most important factor is bus speed. No doubt if you've run systems similar to what we described above, you've noticed the processors themselves don't seem to see much action. The 5% proc usage may give you a false sense of security. What you need to be watching is the load. If you are not sure what that is, you can view it by typing "uptime" at the command line. Look for a response like "load average: 0.05, 0.03, 0.00" The numeric values on the left (0.05 in this example) tells you what the current load factor is.
So here is what load is. Assume first this is a single core box. It's the usage of the server's processor bus divided by the capacity of the bus. So for example if a bus capacity is 10 and you are using 6, then 6/10=0.6. A load factor of 1 means the bus is full. There is no more room. Now you're starting to see some lag even though the proc itself isn't working to hard. It's the result of easy tasks, but a whole lot of them. To determine the max load for your server, multiply the number of cores by 1. So for example, an 8 core machine is at capacity when the load reaches 8.