Audio "drops"(pause) for user(s) Part 2

[TLCtech]

• CX Version, e.g. Standard Annual 16.0.8.9
• Server OS, Raspberry Pi
• 3cx hosted locally
• Provisioning Method: Local
• Trunk Provider: Call Centric
• Has the Firewall Checker passed: YES
• Are custom Phone Templates being used: NO

In case you missed it, we are having some very weird audio issues at our lawfirm.
Previous Threads:
https://www.3cx.com/community/threads/audio-drops-pause-for-user-s.80903/#post-372959
https://www.3cx.com/community/threads/voice-mail-issues.82503/

TL;DR
The audio for either the caller calling in, or the user going out, will just drop for several seconds and the come back. This has been going on for almost a year, but had been really bad since spring. When people leave us voicemails, the audio will stop for several seconds, and then either catch up super fast or drop back in. Often the voicemail audio is jumbled, like it was spliced and layered over itself.

Ive been tearing my hair out trying to get this fixed. A call to callcentrix showed we have jitter coming from the ports 3cx is using. The client has been hard to work with regarding this issue, and Ive been out with an injury for several weeks, but they finally let me do a packet capture. The problem is they have switched to a fall back system using their personal phones, so virtually no calls are being made. So we set up a call with one extension who sees this issue often, calling out to my personal cell phone using my cell carrier. We did about 20 min of a podcast going one way, with the other person listening for any gaps. Then, we switched and had the other side for 17 min do the same thing with a different podcast. Prior to this test, another user reported poor 3cx "signal" during an internal call and had to switch to cellular to call them back. This is possibly unrelated, but should also be reflected in the capture.

Should I upload that capture data here? I wasnt sure how safe that was to do.

Before I forget:

• "Poor signal" call was either at 2:38 or 2:44pm, as those were the two calls she showed me
• First test call started at 4:04 pm
• Second test call started at 4:48 pm

Thanks in advance

 

[aschildmeyerSTR]

For the most part, we dont have any extension to extension issues. Sometimes we will have poor signal reported but that could be a lot of other things

I have done speedtests from the PI and there isnt often bad jitter.

I haven't done the ping to the sip carrier. But I have done a constant ping to google, for instance, and there wasnt really bad latency or any dropped packets. I dont know what a "full frame packet" is and google is being less than helpful.

By full frame I mean 1500 bytes and depending on network gear 1472 instead. So you want to ping with the byte length of 1472 let's say. 1472 is worse case scenario but I think g711 would be around 250 bytes. Which is still much larger than doing a standard ping.

On windows that would be ping 8.8.8.8 -l 1472 for example.

Next your really want to ping your sip provider. If they don't have ping open then do a TCP or udp port ping to them instead, ideally with a full 1472-1500 byte packet. If you ping Google or 1.1.1.1 that won't be good. They use anycast and CDNs that potentially get closer and usually on network to you. Your sip carrier might be somewhere else with high latency and bad routes that are causing you jitter. All it takes is a bad peer between your isp and your sip provider.

Next fast.com will show you jitter and loaded latency meaning when there is load on the line that might make devices tip over when there is any load. So do a speed test at fast.com and if you can ping your sip carrier.

Also another thing I'll do is a path ping for 5 minutes to get averages of every hop inbetween. If you cant do that do a traceroute from you to your sip carrier and see how many hops and where you go for the end latency.

 

[aschildmeyerSTR]

For the most part, we dont have any extension to extension issues. Sometimes we will have poor signal reported but that could be a lot of other things

I have done speedtests from the PI and there isnt often bad jitter.

I haven't done the ping to the sip carrier. But I have done a constant ping to google, for instance, and there wasnt really bad latency or any dropped packets. I dont know what a "full frame packet" is and google is being less than helpful.

Yeah, that seems pure internet related then so I'd focus on that then.