Another fun tidbit: Calls seem to get worse after being transferred.
I can get a call and have decent audio only to have it become problematic after transferring to another extension.
Still struggling with this. Anyone else have any ideas on things I can try?
I unplugged literally everything on my network except for my PBX and my two Vegas and I’m still getting choppy calls. I swapped all cables and used two different switches. Unless it’s a network issue on the Vegas or the PBX host itself, it can’t be a network issue.
Thoughts?
I’m creating a new VM and installing FreePBX from scratch. I should be able to copy my config from my old system to my new one, right? I have a ton of extensions and inbound routes I’d rather not have to re-create.
Does copying a config also copy custom audio files?
That is the point of the backup and restore module. Is there a reason not to use it?
If you are going to copy thing, you are going to miss things.
Right, that’s what I meant.
I’ll make a backup and then restore it on the new VM. I just want to make sure a default backup will restore the custom greetings I’ve saved.
Apologies for not being clear.
If you did everything through the GUI, then the backup of that module will get it. If it does not, then that is worth a bug report.
Ok, basically I just want to back up everything except for the calls (I have far too much to back up).
I didn’t see any comments about whether you have checked your hyper-V host to verify no performance issues (disk, network, cpu) corresponding with this audio issue starting up…
I can see no issues with my host server. No settings have been changed on it and it has only the one VM. I have done no recent updates on it prior to this issue happening and it had been running without incident for years prior.
All of these things matter - what’s your load average on the system? How many CPUs are allocated? Is steal time high on the VM?
Did you figure out if you’re seeing out of order RTP packets?
That can cause strangeness sometimes. Have you tried enabling jitter buffers on the SIP endpoints in question?
Matthew Fredrickson
The load is low. My dashboard current reports 0.17, 0.27, 0.30 for 1, 5 and 15 minutes. That’s pretty close to what it is normally. I think I’ve seen it spike to just over 1, but that was during an update.
I have 12 virtual CPUs allocated and 8GB RAM. Steal time is a 0.0 and I’ve never seen it change.
RTP debug shows no out of order packets. During the choppy audio, at most I’ve seen 2 consecutive to/from packets.
I do not have jitter buffers enabled, nor have I ever had them enabled. What settings do you recommend I use to try and sort this out?
Additionally, since this is a new occurrence (started late last week) and only seems to affect outbound audio (we can hear the other end just fine), would jitter buffers help with this?
Also also, all of my extensions are PJSIP, under which I cannot see any jitter settings. Would they even be applied?
In watching my debug, I’m seeing the following error every so often:
The 'stasis/m:manager:core-00000007' task processor queue reached 3000 scheduled tasks again.
It seems to only show up when doing the RTP debug (and shortly after ending it). I haven’t seen it again after stopping the debug.
so you’re saying it’s only choppy to people on the outside? So only “upstream” traffic then?
I have a client that had this issue with sip. Phones were local PBX was cloud based. Basically once Covid hit and everyone in the area started working/schooling from home and running video chats all day the local cable carrier’s upload bandwidth just couldn’t handle the load. Well that and they loaded up too many end users on the local node. Took some pushing but finally they agreed to fix it.
I think you said you were using a PRI or T1 so prob not the same issue.
I finally used MTR (or WinMTR - Download WinMTR ) to prove to the cable company that the slowdown was on their node and therefore the issue was with their equipment.
That’s correct. Callers sound fine to us but we sound choppy to them. This is happening on both my PRI and my POTS lines (via a Vega 100 and Vega 60, respectively), so even if it were a bandwidth issue with my T1, that wouldn’t be the case on my analog lines.
Additionally, my remote extension at my house has no issues making calls to extensions at the office, and that connection definitely goes across the internet.
Something changed in my office last week Thursday and I can’t figure out what.
ok, so it’s not the vega’s logically because they are separate paths.
how are the vegas and the PBX connected? Since ext to ext is fine its got to be the link between the PBX and the Vegas. What, in that link could cause upstream packets to get slowed down or dropped?
They’re all connected on the network.
I’ve replaced the network cables, tried different switches and even put my backup Vegas in place – all with no luck.
The only thing I haven’t replaced is my VM host. I don’t have another option for that at the moment. I’m building a new VM (same host) with the latest distro, but if the issue is the host, I’ll likely have the same problems with a new VM.
Edit:
I’ve even completely isolated the PBX and the Vegas onto their own switch. It couldn’t ring any of the phones but the on hold audio was still choppy.
Since the issue is always only on the outbound via Vega devices and never on internal calls to the PBX, seems unlikely to be the Hyper-V server unless the Vega devices are on a separate network from the internal phones.
Also, what FPBX and asterisk versions?
Any idea if any updates recently applied?
My thoughts exactly. I’ve ruled out every possible thing as a cause for the problem (I think).
Vegas? No
Cables? No
Switches? No
VM? No
I’m not sure what else to try here.
FreePBX 14.0.16.9
Asterisk 16.17.0