Our FreePBX Distro has been producing garbled audio recently
We’ve been running FreePBX Distro for a year or 2 now with no real problems until recently after making a major change in the way the phones were setup… Note: This phone system was inherited when companies merged and we’ve been trying to keep them working on what is familiar to them… (We usually use IPECS)
Here’s the old setup which was working fine:
2 FreePBX Distro VMs at 2 of our sites connected via IAX2 (main box had the SIP trunk) Both FreePBX VMs would go out through separate external IPs to talk to each other…
Current setup (Audio Issues began):
1 big virtual FreePBX Distro with roughly 50 handsets remotely connected from 3 different site links… Ever since this change, our audio has been choppy/garbled (Both incoming and outgoing)
I believe the FreePBX framework version currently running is 2.11.0.38 with Asterisk 11.10.2
Things we’ve tried so far after reading up on other peoples similar issues:
Jitter Buffer (Made things worse no matter the settings)
QoS (we have 10Mbps links)
Increasing System Resources + setting up a dedicated NIC for the VM
G729a codec rather than alaw (alaw & ulaw seem to be acceptable)
Changing Qualify/Registration timeouts and such
I’m currently building a physical server to run FreePBX Distro on as I was remembering a thread I had read yesterday where they mentioned that a virtual FreePBX would generate similar audio issues for remotely connected handsets as it cannot process network data as fast as a physical machine would… (This is what prompted us to try the dedicated NIC for the VM earlier)
Here is an example of the log activity that has been getting on my nerves:
[2014-08-22 10:58:00] NOTICE[1802]: chan_sip.c:23665 handle_response_peerpoke: Peer '8013' is now Lagged. (2026ms / 2000ms)
[2014-08-22 10:58:10] NOTICE[1802]: chan_sip.c:23665 handle_response_peerpoke: Peer '8013' is now Reachable. (20ms / 2000ms)
[2014-08-22 11:39:50] NOTICE[1802]: chan_sip.c:23665 handle_response_peerpoke: Peer '9546' is now Lagged. (2026ms / 2000ms)
[2014-08-22 11:40:00] NOTICE[1802]: chan_sip.c:23665 handle_response_peerpoke: Peer '9546' is now Reachable. (34ms / 2000ms)
[2014-08-22 11:46:39] NOTICE[1802]: chan_sip.c:23665 handle_response_peerpoke: Peer '8017' is now Lagged. (2019ms / 2000ms)
[2014-08-22 11:46:49] NOTICE[1802]: chan_sip.c:23665 handle_response_peerpoke: Peer '8017' is now Reachable. (30ms / 2000ms)
[2014-08-22 12:44:16] NOTICE[1802]: chan_sip.c:23665 handle_response_peerpoke: Peer '9536' is now Lagged. (2024ms / 2000ms)
[2014-08-22 12:44:26] NOTICE[1802]: chan_sip.c:23665 handle_response_peerpoke: Peer '9536' is now Reachable. (34ms / 2000ms)
[2014-08-22 12:58:28] NOTICE[1802]: chan_sip.c:23665 handle_response_peerpoke: Peer '9536' is now Lagged. (2018ms / 2000ms)
[2014-08-22 12:58:38] NOTICE[1802]: chan_sip.c:23665 handle_response_peerpoke: Peer '9536' is now Reachable. (22ms / 2000ms)
Another thing worth mentioning is that we have an IPECS system using SIP on the same subnet as the FreePBX VM which is registering out through the same external IP (I believe both are using port 5060)
Is this something we should modify? (e.g. IPECS uses port 5060 while FreePBX uses port 5061 or is having 2 separate SIP systems using the same external IP a big “no no”?)
Let me know if you needed any particular information that I’ve left out or have only partially provided
Regards
-Dan
Not true. Schmooze Com, the sponsors of the FreePBX project, run all of our testing and production machines on Solus KVM solutions VM systems. On our master one we have 17 employees about 9 of which are not in the office (Wisconsin). We have some in California, Texas, Arizona, Seattle, New York… each person has a hard phone and softphone connected. I’ve talked with the boss while driving my car over Bria which is connected of AT&T’s LTE network while driving (so it’s switching towers) whith no issues.
VM is being hosted at our data centre in Sydney (http://www.globalswitch.com/locations/sydney-data-center/) along with others + physical servers via a 20Mbps up/down link…
Is that sufficient or should we look into getting the hosting you mentioned?
Thanks for your assistance with this
P.S - Sorry for not linking it properly but this site said I’m too new to post links…
I can usually get the same results in about an hour where there will be a latency spike in the 1,000ms range but there have been a few instances of 3,000ms and even a 6,000ms…
(I suspect our Provider of being dodgy at this stage since doing a trace to a voip phone at a site via a different provider doesn’t show any latency spikes and much less loss%)
is our Data Centre Router
is the external interface at the Data Centre going out to the world
is the inner workings of our Provider
is the Provider’s Edge
is the Customer Edge
is the site router’s external interface
Not sure what else to check at this stage… I wish we didn’t change providers and move the FreePBX to our Data Centre in another state at the same time (Tempted to move it back to see how things play out…)
Your global 1.2% loss probably is reflective only of your TCP connections as UDP is connectionless so you won’t ever know what you are loosing , but such losses on tcp connections are huge and will will likely reflect that your UDP connections will be no better so ultimately unacceptable, the root cause will either be your virtualization’s network stack or your network provider’s network, maybe both, It is pretty well guaranteed that it is not intrinsically Asterisk/FreePBX, Try another provider or another Data Centre (my personal money is on your data center as the culprit)
I’ll try another Data Centre first since that will be easiest for me (I’ll run more tests over the week after that and will hopefully see some better results)
Well… Moved it out of the Data Centre and what do you know… No loss and acceptable latency… (If I tracert to a device in the Data Centre, the loss begins as soon as it gets there)
Time to move everything around and change the routing tables in the Data Centre (Possibly replace/remove certain equipment after further testing)
