PBX to SBC Packet Loss - Call Quality Loss

[contoured]

I have two different 3CX PBXs that are experiencing an issue where packets are being lost from the PBX to the SBC (roughly %15). This issue cropped up on both PBXs at roughly the same time which was late last week and is causing a major hit on inbound call quality.

Both PBXs are hosted in GCP in different VPC networks
They are in entirely different offices with unique network and routers.
One is on update 3 and one is on update 4. Both SBCs are on version 16.0.390.
Both SBCs were working well for several months prior.
One of the PBXs has 7 SBC's connected but only one is having the issue.

I have performed several tests on this Including
-Rebooting
-Reinstalling SBC software
-Updating PI
-Changing to Windows SBC
-Deleting and re-creating SBC trunk
-Pouring over both firewalls to eliminate any firewall issues
-Firewall test on both PBXs
-Restarting 3CX instance

Has anyone experienced a similar issue? Any suggestions? One of the PBXs is my company's NFR boxes that we use daily. I have performed several packet captures from 3CX and oddly they never reveal RTP streams.

 

[leejor]

This issue cropped up on both PBXs at roughly the same time which was late last week

This being the case...what do the two systems have in common? Were any updates done just before this started...same ISP?

 

[contoured]

Both in GCP, Both use Pi SBCs.

I'll double-check the customer's provider but there's a good chance they also use Frontier. But there are at least a few other customers that also use Frontier.

 

[cobaltit]

I have performed several packet captures from 3CX and oddly they never reveal RTP streams.

This is not odd, this is expected. The whole point of the SBC is to encapsulate the traffic into a single packet stream.

As far as your issue, I'd try moving your instance to another region.

 

[leejor]

The fact that two different locations began having issues at the same time, and, I'm assuming, that the SBCs (and 3CX, or other network components) at both locations were not "touched" in any way just before this began, that leaves the network between GCP and each remote locations ISP, as the prime suspects. If it is the ISP (common ISP used at both locations?), then other traffic on the networks should also be affected. You should be able to perform tests (latency/packet loss) to comfirm any ISP issues.