Packet loss on FreePBX


does anyone have experience with this problem?

I have FreePbX no. 1 version installed in the data center.
I have been watching outages of telephone calls for a long time. When measuring, the loss is 1-4% of packets.
When pinging from different ISPs it’s the same, a loss of 1-4%.
Various phones are used, such as Grandstream, Well, Gigaset etc.

I have FreePbX no.2 version installed in another data center and here the loss is 0%.

The IT technician says everything is OK.

  • Is there a problem in FreePBX?
  • Is there a problem with the data center?
  • Should I upgrade FreePbx to a higher version?

Thanks for the ideas

That indicates a network problem, I would suspect the data center.

Take a look at this discussion here - you can use the MTR to help diagnose network related issues.

MTR is looking at the ICMP protocol, although a passable 10000 foot diagnostic, if it shows congestion at one particular step, that does not mean that other protocols are being restricted because ICMP will be dropped if higher level protocols are being forwarded

Compare and contrast the results from both data centers, but use rtp debug to actually see missing media packets rather than ICMP loss.

How are you testing this? You mentioned using various phones so I am wondering how you are measuring this from a SIP phone. If you can help narrow down what you are doing I can perhaps offer some insights. I have dealt with real and imagined packet loss quite a bit.

I have done lots of testing with MTR and I have found it to be a fairly reliable indicator of SIP packet loss as well, even though it is using a different protocol. However, MTR also gives false positives sometimes so you need to be aware of those scenarios. I think the version currently in CentOS 6 and maybe v7 RPMs has a problem where it will give false postives when you do a report (but not on live viewing). That caused a lot of confusion for me before I figured it out. There are a few other times I have seen MTR giving false positives as well. Like when you have it running in 2 shells at the same time. I haven’t seen that one in awhile so maybe fixed now but something to be aware of.

You should also do MTR in both directions (if possible) to confirm you are seeing the drops at the same spot in both directions. Sometimes routes are not the same in either direction and it only happens in one direction as a result, so that’s another piece of information that is good to know.

Again, rtp debug will show packets arriving and leaving the server. If there is packet loss it will be immediately apparent.

If you want to be a little more appropriate, use the -u argument for mtr (RTFM :wink: )

Thanks for the feedback.
We also observe poor quality calls. Plus ping to sip server loss 1-4%. We will try to move FreePbx to another cloud array. I’ll let you know if it helped. Peter

As an addition to @dicko suggestion, you can also use VoIP probe on FreePBX machine and get nice graphs from some monitoring software.
I am using (the probe is free) and graphing it with Grafana.

1 Like

On the half dozen occasions I have had consistent <5% packet loss it ended up being a bad optical link. Either the transceiver or the cable. Any decent provider should be able to fix that for you.

Hi, I moved FreePbx to another cloud location. The loss of pacetas increased from 4% to 8%. IT claims it’s just from the internet. Can’t it be an attack? The system is on the Internet as
Thank you

All you know for reasonably certain is that the internet connection is not dimensioned for the traffic levels it is receiving. Without analysing what is being received, you cannot tell whether that is because of excessive legitimate demand or malicious traffic, and, if the bottleneck is upstream of you, you may not even be able to determine that there is any malicious traffic.

If this pbx is ‘hosted’ i would try another company fo a couple of euros .

Yes you are right. It will probably be the last and best solution. :slight_smile:

we found that the lost packets no longer come to the PBX input, so FreePbx is OK. IT will change the network card in the cloud. Thank you all for your support.

Remind them to change the ‘network card’ in the ‘other cloud’ at the same time :wink:

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.