So i have deployed some instances at my customers and all facing the same problem with different firewalls with different Trunks and so on.
No Ringback
Calls are canceled after some time
Some cracks and bad understandability
Calls are not connecting
It takes 2 - 3 seconds until you can hear someone
And so on. I have tested a lot but why is this so worse? It’s telephone and it should work. My customers are not really happy with that solutions because it’s much worse then the old telephone system.
So i like in in general but that are problems that appear very often and i can’t solve it. Does anyone else have the same problems?
You’ll need to provide more details if you want to get help. Without information such as PCAP traces, Asterisk logs, and firewall settings (FreePBX and Customer Firewall too), it will be very difficult for anyone to assist you.
I believe you’re already familiar with the steps to collect the necessary details from your FreePBX and firewall.
Yes i know the problem is that problems are not everytime to it’s very difficult to get them and capture them. It’s not really constant. But when i ask the people here ist mostly the same problem.
I have made same tests when i set “alaw” as the first codec the quality is very bad and it’s cracking and not really good. Now i have set “ulaw” with “g.722” and it seems better. I don’t know what the problem is but i can’t capture it.
At the moment this post was for my frustration because i tried and captured a lot and there is a problem that i can’t take very well.
Were these brand-new deployments, or upgrades from previous versions (i.e. - restoring config backups to v17)? Sounds like some configuration review and tweaks might be in order, but without specifics it’s tough to determine.
Crackling indicates a network problem. I presume by hardware, you mean analogue with mechanical, or electromechanical switching.
I’d say most or all of your problems relate to VoIP versus analogue, rather than being the result of using Asterisk. Some might also be the result of running on a VM that isn’t set up for near real time use.
Ok good suggestion. One installation is on a VM an another is on a separte small computer with some power. Both have the same problems.
@gregarican i have new installed and configured installations and one that has an config import. That problems are the same with different hardware and Trunks. And different networking and firewall solutions. I have exactly the same problems with completely differrent configurations.
@david55 ok and how to setup the VM for real time use? It’s the default installation for FreePBX 17 and Debian 12. At the moment i use VMWare at this customer.
The One VM has 8GB RAM, AMD EPYC 7313P with 2 cores. The load is 0.05. There are only 1 - 3 calls at the same time. Unifi Netzwork with Unifi UDM-Pro. With a Easybell Trunk. With SNOM D785 telephones.
The other system is installed on a seperate computer made for firewalls and has 32GB RAM with an i7 and DDR5. Unifi switches with a Sophos XGS firewall. With a Vodafone Trunk. Here we use Yealink DECT W80.
So i used different solutions for different customers. I have made changes for the UDP-Timeout and so on. I have the same problems now on 3 different FreePBX Systems.
I have another system from Auerswald with an Easybell Trunk and it’s working without any problems also with Unifi and UDM-Pro.
@BlazeStudios I don’t think that it’s a hardware problem the systems don’t have a high load and the servers are not the smallest ones.
The second solutions i descripted there was also an Auerswald 6000 before. With the same Vodafone SIP trunk and same Firewall and Network and there was no problem. At the end the Hardware had some problems but there was no such problem as we have now with FreePBX.
And i had some discussions with some other FreePBX users that were facing the same problems and were also a bit frustrated.
VM can be an issue if you don’t dedicate RAM and CPU cores to the Asterisk VM. Whilst my knowledge of VMWare is now very dated, it used to give quite large time slices to to the guests, and would fake the real time clock. That isn’t a problem for most business applications, but VoIP is an edge case, as you typically want to keep scheduling and page fault delays to under 20ms. If you don’t have enough dedicated RAM, the host can go into swapping.
By configuring the VM I mean setting it up such that the Asterisk threads are not competing with other guests for access to a CPU and Asterisk RAM cannot be paged out to make room for other guests.
It looks like you can reserve RAM in VMWare, but CPU is reserved in MHz, not in cores, which makes me think that the reservation is averaged over a finite amount of time, which may well be more than the acceptable jitter time for VoIP. I did see another query result that suggested using CPU affinity.
Several of the articles I looked at point out that reserving goes against the point of a virtual machine, but with semi-real time applications, like VoIP, you cant allow the host to take full advantage of the diversity in the workload. You either have to significantly under-commit the host, or reserve resources.
Note that waiting for CPUs will have similar effect to waiting for network resources, and you may have to look at which of them is causing the actual problem.
(VoIP is only semi-real time, because quality degrades, rather than their being a catastrophic failure, if the processing gets delayed.)
It sure can, which is why I actually asked for those details before making the jump to “It’s the VM” considering that the issues being described can exist both on a physical system just as much as they can on a virtualized system.
@rene.hoehle We need to see some debugs and PCAPs of these issues happening. It will give us more insight on what the problem may be.
Thank good point. I will reserve the resources now to test. But the other system is a dedicated system and has the same problems. So only for understanding i like FreePBX and for me it’s great but this whole issues are a problem. I have reserved the 8G now for the system and the CPU.
In the next weeks i will migrate the systems to Proxmox. Perhaps that can fix some problems.
Or we can do actual troubleshooting on these issues that may not even be related to the VM. The only reason the VM is being “blamed” for any of this is because you mentioned a VM. If you would have just presented these issues on their own with no mention of a VM we would be troubleshooting the actual issues before jumping to “It’s the VM” as the reason.
Right now nothing actually supports “It’s the VM” definitively just that these are problems anyone can run into.
I will say this popped up on the Asterisk forum earlier:
I bounced them here, but there hasn’t been a post yet. From an Asterisk perspective there haven’t been any reports of issues, and I can’t think of any changes that would cause such a broad swath of issues - just general things as already mentioned.
This is whats my problem to find that problems if it’s FreePBX… if it’s perhaps the telephone and so on that whole system is so complicated and blown up with the years that it’s hard to debug and find that problems exspecially when they don’t happen all the time. I’ve asked with some technician that has a larger installations and they said to some of my problems… “Yep thats normal…” ok but i don’t want that this is normal
When i suggest that product to my customers and install it and they have such problems like that it’s not really good.
At the customer with the standalone hardware i have the problem that on internal calls there is sometimes no “ringback” you don’t hear anything and then the other one is there. Then i have switched the “Ring” to a “audio” tone in the follow me module and it was workling again. That’s another problem that i have and made here a post without an answer. But this is perhaps a Yealink problem.
Hmmm, this sounds strange to me. I’m running a FreePBX for my basketball club since around 4 years and I’ve deployed two new systems (home and employer) in the last two weeks, all FBPX 17. The latter two with around 15 extensions, all running Auerswald D-Series and COMfortel phones and Groundwire app on IOS.
All three are VMs on Proxmox with less resources than your deployments (4 vCPU, 4GB RAM). Home and Employer running on Dell R730 / R720 with Perc RAID 7200rpm HDDs, so no SSD.
Trunks from Telekom and Easybell.
No issues at all. Which makes my think if it might be some “external” issue with your deployments …
BTW: You’re mentioning “hard to debug” … IMHO the internal debugging options are much better than in our Auerswald appliances
OffTopic: Auerswald COMmander 6000 … I still have this dinosaur lying around here. Was a great piece of hardware at it’s days
Hey thanks for your reply. “Hard to debug” i mean when the problem won’t occur when i’m at the office or not everytime. It’s very hard to get the problem in that point. Some of these things are very strange. The problem is when you change that system people notice very small inconsistencies and are annoyed that it’s not working like before. Some of that i could fix.
Yesterday i could here that there are problems with the connection with Easybell and the VM. I’ve made some tests and could reproduce it for 2 times. Perhaps with the suggestion to set the resources it’s better now i have to wait for some response.
I have one Easybell SIPTrunk here at my home (beside my main Telekom CompanyFlex) and one as main and only trunk at my Employer. It did not notice any issues …
In this case I would just run a packet capture on the FreePBX system in the background for a while so you are able to check the captured traffic using Wireshark later. I always think this is the best and easiest way to debug issues like that.
For example just run something like that in your terminal: tcpdump -i eth0 -w any-file-name.pcap -W 5 -C 50
This will capture the network traffic on interface eth0 and creates a new file when the current filesize reaches 50MB. It will create up to 5 files and then starts to overwrite the oldest ones. Adjust the values according to your needs.
Tell your client to note the time when a problem occurs so it is easier for you to find it later in Wireshark.
It could also be an issue with your phone devices. Which phone models are you using?
@JaCoTec i have on another customer the Easybell Cloud and it’s easy and it works. So it’s strange.
@joni1802 good point i can run it next time when i’m at the office and tell everyone that he should tell me when something heppen then i can analyse it.
