3CX SBC Troubleshooting Tips

Status
Not open for further replies.

jamestalmage

Free User
Basic Certified
Joined
Jul 14, 2020
Messages
10
Reaction score
1
I have a Google Cloud hosted 3CX instance.
Linux OS.
License is Standard Annual 16.0.5.619.
Provisioned using 3CX's automated tool.
The Firewall checker has passed.

I have three sites all connecting to the same instance via SBC's.
Raspberry PI 3B+, with latest Rasbian OS and SBC software installed per 3CX instructions.
All Rasberry PI's are complete CanaKit Kits with approved power supplies and SD Cards, etc.

12 Yealink phones at the main site.
2 Yealink phones at each of the smaller sites.

Everything worked fine for the first 7 months of install. Problems have only appeared in the last couple of weeks.

The main site still connects fine and is stable, it handles the majority of the call volume.

The biggest problem is at one of the smaller sites. Calls last under a minute before being dropped, or more often, the remote caller can't hear, but they can hear the caller on the onsite phone. On the status page for the SBC, the "UDP status" routinely cycles between Up and Down.

The third site has limited call volume (the users there prefer the phone app), and I'm not getting complaints. But, the status page for that SBC is exhibiting similar "UDP down" behavior, so I suspect it has a similar issue that is just not being reported.

I've seen other posts where it's suggested this is a firewall issue, but my cloud-hosted instances firewall was automatically configured (and has one SBC that is rock solid). So I suspect it is related to conditions at the remote site. My understanding was that no firewall configuration was necessary at remote sites when using SBC's.

I was just told (literally as I typed this) that their IT company installed new firewalls at both the sites experiencing problems. So now I am *really* suspicious that is the issue. But, I've got no details on what firewall accommodations need to be made at the SBC site (I thought it was none). What might be happening here?
 
I think i know where the evil lies, Have them disable SSL/TLS Inspection and test for a little while and see if the issue is resolved.

If there is little or no change, have them disable the advanced filtering and inspection in those firewalls, not a quick exception for a single IP, off COMPLETELY during the test.

To summ it up, with most normal firewalls, you do not need to make any changes for an SBC to work, however, in the name of security, some firewalls are extremely hostile to traffic they do not explicitly recognize, and thus will impose restrictions on it, or block it entirely.

They also sometimes perform transforms on the traffic, again in the name of security, that violate the protocol standards and thus it causes repetitive breakdowns in communications due to this.

I bet you if you try the above, you will discover the cause. I also would posit a guess, that your dealing with either a Sophos or a Fortinet, there are others that exhibit this behavior as well but those two i have seen most prevalently.
 
You just need to confirm that 3cx tunnel port (tcp / udp port 5090) and https port (443 or 5001) is allowed out.

No port forwarding is required
 
Status
Not open for further replies.

Forum statistics

Threads
111,954
Messages
589,921
Members
164,852
Latest member
priya