Help with concurrent VoIP calls

Hi. I’m having trouble figuring out why I’m not able to make many concurrent VoIP calls on my system. I’m not aiming for a huge number, because I have purposely bought a low powered system, but I would think that I could get more. Here are the details:

I have a small-form-factor Asterisk server with an Intel Atom 230 CPU (1.6 GHz, 533 MHz FSB) and 512 MB DDR2 533. It is running Ubuntu Server 9.04 with the default Debian package manager installation of Asterisk. (version 1.4)

Here is what is going on: I’m making outgoing calls (with .call files) via SIP (using Vitelity’s service, if anyone wants to know) with about 55.0 ms latency. I’m using GSM-format prompts with GSM encoding (disallow=all, allow=gsm) and I’m able to make about 7 concurrent calls. I have a very fast internet connection, so there is still plenty of bandwidth, and the “top” command shows that Asterisk is only at about 5% CPU and 10% RAM. Even with only 7 calls, a landline phone will “skip” occcasionally, but cell phones have perfect quality.

I don’t think that 7 calls is very many, I’ll be happy if I can get 10 good-sounding calls. Can anyone give suggestions? (If this has been hashed out elsewhere, I’m happy with a link to more information!)


You are right that 7 concurrent calls is not a large number? What are the symptoms when you max out? Do the calls imply back up and ultimately clear? If so, it sounds like Vitelity is throttling the volume. I have never tried on a small box but on the systems we are running, we have to put bandwidth limiters on our own servers otherwise we can get up to large numbers of concurrent calls within a few seconds.


What do you call [quote]a very fast internet connection, so there is still plenty of bandwidth[/quote] ?

Also what are the calls doing ? how may times are you transcoding ? If you have plenty of bandwidth see what the capacity is with alaw ?

show translation will give you an idea of how hard it is for your setup to transcode.


Mudslide567: I’m not sure by what you mean by “calls imply back up and ultimately clear” but when I have more than 7 active calls then the audio quality on all of them just goes south- they will break up, be static-y, or have other quality issues. Vitelity provides at least 10 channels per account- so they won’t do anything if I have 10 concurrent calls. I tried 11 calls once, and the audio quality was bad, but they didn’t reject the 11th call. As far as limiting the number of calls, right now I am testing the system to see where to set the limit on how many to let the system make. Right now, that limit seems to be 7, and I’m trying to figure out how to increase it.

ianplain: Sorry for not being specific on the speed. I have the “best” Bellsouth Business DSL has to offer- 6 Mbps down, 512 Kbps up. So, not as fast as I’d like, but I’ve run the “iftop” command while making the calls, and the server is using less than 200 kbps up. (But, there is also the returned audio- so that is 200 kbps down at the same time) Thanks for mentioning “show translation” it does look helpful. But, I’m already making sure there is no transcoding that has to happen- the system is playing back a gsm file and is using the gsm codec over SIP. I’ve tried ulaw, and I can get even fewer concurrent calls with wav files and the ulaw codec.


Ok so you actually havent got “a very fast internet connection” you have an average connection. you need to run a speed test to a speed checker close to where your ITSP is and then see what the real speed is. something like myspeed checker

Then as you say when this is happening you your bandwidth is 200K which about right, But you have, even if you are getting the full 512K which I doubt have hit the the point that you will be getting unacceptable Jitter latency and packet loss, This is about 40% of available bandwidth.

You could grab the packets and put them in wireshark and see what it shows up. But Ill be honest with you and say that you are going to be very very lucky to get 10 concurrent calls out of a 512K link.


The modem indicates that I am getting very close to the 512 Kbps speed. When I wrote “very fast” it was to indicate that I wasn’t using up the full amount of my bandwidth- and, unfortunately, 512 is the best that I can get on DSL. However, after asking and reading in other places (the Asterisk mailing lists included) everyone does seem to be pointing to the jitter and latency that increases as more of the connection is used up, which I guess I should have expected, since I have done work with VoIP and Asterisk elsewhere. I’m really just trying to figure out how many concurrent calls my system can support, so I’ll probably try testing it elsewhere- my office has a 50 Mbps downlink over fiber. (not sure what the uplink is, but it is similarly substantial) Thanks for your help- I was trying to ensure that it wasn’t a problem with my configuration of Asterisk/the server that was holding the number down.

Ah but modems lie [quote]The modem indicates that I am getting very close to the 512 Kbps speed[/quote]

Mine indicates 750K but in reality its closer to 500K with a workable 250k.

Basicly you can safely use 40 - 45% of your actual bandwidth to be sure of quality calls.

If you want to test the server capacity set up 2 servers and pass calls between them or use on the test suites avalible


I should have asked the obvious question of how fast is “very fast” to get calibrated! Vitelity does not have to throttle the terminations since they are allowing your bandwidth to do it for them. I think getting 7-8 calls out of that DSL is likely to be about the best you are going to get.