I’m deploying a system that is likely to encounter at its peak around 15 simultaneous calls. It has a symmetric connection of 30mbps (At least that’s what it’s supposed to have, but even at 15 Mbps symmetric, I should be encountering the problems I am), and is the only device on that internet connection. I recently did a test using call files where I initiated a number of call simultaneously. I was on the phone at the time, so that I could hear the deterioration and come up with a viable number of simultaneous calls. Eventually, I figured out that the system could handle about 13, including my call. After that, the quality detorated quickly. From what I’ve read, a normal call takes about 100kbps up and down, so even with a 15mbps connection, I should be able to easily handle 100 simultaneous calls. I ran a speed test and was getting in the 20mbps, even during the simultaneous calls. What could the problem be?
FreePBX is running on a dell poweredge r410, so I doubt that the problem is the processor.
My trunk is Flowroute, which doesn’t have any channel limitations, so I doubt the problem is with them.
But I also think it is unlikely to be solely related to our connection.
Is there anything I can do to do some more tests, or is what I’m experiencing with the call files likely to be similar to what I see in the real world? Can I experiment with codecs? What codecs should I try?
I’m at a loss. Can anyone with some experience weigh in?
Check the actual CPU utilization when running the test load. Also look at what codecs are being used for both test and normal calls.
If your call files are making realistic calls, e.g. calling an extension that auto-answers and connecting it to an external test number, then your simulation is likely reasonably accurate and you would have similar trouble in the live system.
OTOH, if they are e.g. calling an external number and playing an MP3 file, running 13 simultaneous decodes could be maxing out the CPU (I don’t believe that Asterisk can utilize multiple cores for this).
If possible, avoid transcoding on most normal calls. Even if you have plenty of horsepower, transcoding takes a quality toll. The trunk side should use only ulaw. For internal extensions, using only ulaw is simplest. (If you want g722 for extension-to-extension calling, you need some custom dial plan to avoid transcode on external calls.) If you have bandwidth-challenged external extensions (on mobile data or satellite), using opus or g729 is fine, provided that you don’t have more than two or three of those going simultaneously.
I am decoding mp3 files for each call. What is the best way to monitor the cpu usage and get an understandable idea of what is actually happening under the hood?
When you say that asterisk can’t utilize multiple cores for this, are you referring to decode an mp3 file, or just in general? I believe the server has multiple cores. When I run mpstat -P ALL, I get 16 different lines. Do you mean that I can only utilize 1/16 of my total processing power? When I run mpstat while making those simultaneous calls, I don’t see much difference in processor utilization. I feel like there must be a better way to test the cpu usage.
As far as transcoding, I checked, and both my extensions and the server are set to use ulaw as the top option. Are you saying that because I am decoding from mp3 to ulaw, I’m probably maxing out the cpu?
Install the sysstat package, enable it, from then on you will have an ongoing snap of your system’s various io’s counters and loadings every ten minutes with sar, to familiarize yourself with it