I’m currently facing some performance issues with my FreePBX installation. The system runs fine under light loads, but when handling multiple simultaneous calls, the performance drops significantly. On an intel xeon server, I’ve noticed that the CPU usage spikes during peak times, which affects call quality and occasionally leads to dropped calls.
Here’s a breakdown of the current setup:
FreePBX version: 15.0.17.39
Hardware: Intel Xeon E5-2650 v4, 32GB RAM
Network: Gigabit Ethernet
Telephony: SIP trunking with multiple endpoints
I have tried optimizing the system by adjusting the SIP settings and increasing buffer sizes, but the issue persists. I’m wondering if the server’s hardware is a bottleneck despite the Intel Xeon being a high-performance processor. Could there be any specific configurations or best practices for optimizing FreePBX performance on a server like this?
Any advice or guidance would be greatly appreciated!
At what number of simultaneous calls does it start to give a spike?
I know the main problem could be the transcoding which uses a lot of CPU usage.
Try to configure the same codec for all SIP extensions and the trunk.
Only one codec is enough. G711a or b or other.
If the calls use the same codec everywhere, there will be no transcoding, so the performance will be better.
You might be able to switch from chan_sip to chan_pjsip – still SIP, but a newer Asterisk channel driver that handles more calls (and is the default on FreePBX version 17.)
The main issue with FreePBX 17 is you must reinstall everything. If you want to update your system, you can update to 16 easily.
Once done, you could start another system on 17 for test and next, migrate from 16 to 17.
Other way to improve the server is to use the direct media. (RTP direct) but you could have some issue with the DTMF.
With Direct media, need to select DTFM = Info. That means the DTMF signal is padding through the SIP protocol.
Using Direct Media the audio is direct to the endpoint. Eg; if the exetension 100 is calling 200, the the audio will be only between 100 and 200, not 100 → Asterisk → 200.
However, with Direct Media between 100 and 200, of course, Asterisk will always be in the middle to handle the SIP protocol.
It’s another way thought.
Anyway, keep in mind that you need to know what codecs are used on your system.
If you have extension 100 which does not support a G722 and there is a call from 200 with that codec, the call will be transcoded from G711 to G722 and will take some of the CPU usage.
In this case, Direct Media will not work. The appeal will be rejected.
I’d be more interested as to what was going on that would cause CPU (such as recording, transcoding, who knows) and see if that could be ruled out before recommending a drastic change like this.
Yes, those are great places to look as well, and motivated my click on the button for @franckdanard’s comment regarding transcoding (which was posted before my initial reply on this topic.)
I still, without hesitation, wholeheartedly believe your suggestion to blindly change to pjsip was meritless. The link you said can hardly compare to the Astricon presentation. If you want to redo the test from the presentation on current systems, the methodology is there and you can then do a legit apple to apple comparison.
That is a suggestion and I feel you would do better good by being less defensive, gathering information, and no making suggestions like this blindly. But that’s just my opinion.
I’m certainly not against pjsip and voted heavily to remove chan_sip during the DevCons (as is recorded). This said, I don’t know of any authoritative research backing the statement that pjsip can “handle more calls” than chan_sip and am only aware of the research that showed otherwise.
indeed, recording calls included. I forget this point.
But if this spike appears sometimes, the recording can be called sometimes too. So this is normal.