SBC instability

[stuartpgs1]

I am new to the world of forums so apologies if my question is ignorant or badly formed. We are currently self hosting 3CX sites.

3CX SBC Stability – Desk Phone vs Dedicated Device

Looking for some real-world feedback from others running multi-site 3CX setups.

We’re seeing frequent SBC tunnel drops (Event 4102) across a few sites — in one case averaging 30+ Up/Down events per day. Symptoms include intermittent one-way audio and occasional call instability, despite moderate call volumes and passing firewall checks.

One common factor is that the SBC is currently hosted on Yealink desk phones ( normally T43 U) rather than a dedicated device.The sites are small, less than 10 users

For those with similar environments:

• Have you seen instability when using phones as the SBC?
• Did moving to a dedicated SBC materially improve reliability?
• How stable should a healthy SBC tunnel be in practice?

Leaning toward standardising on dedicated SBC hardware, but keen to hear others’ operational experience before making the change.

 

[RoryJ]

There is an Omada Wifi Gateway

Besides the other suggestions in the thread you should disable any ALGs you don't need on that router, particularly SIP ALG. Usually found somewhere like Advanced > NAT Forwarding > ALG. I have seen TP-Link routers causing call quality and stability issues (even with router phones) with SIP ALG enabled, which it seems to be by default.

 

[fortech]

Just a footnote comment. Given the absurdly low price of a robust "tinyPC" (ie, amazon N150 based 16gb MiniPC is ~$200 for a basic beelink rig for example)... I've had very good experience with these sort of machines as dedicated SBC (ie, even for small office). If you have SBC role on a small dedicated piece of equipment like this, and do *not* use SBC-Routerphone mode - you minimize the interaction drama (ie, what if end-user powers off their handset, unplugs it, etc? they break the SBC role for others who depend on it...)

ie, get a nice reliable SBC tiny PC, running 3cx SBC/Debian official install / hide it in the network closet with the firewall / nice robust hard-wire connection
out of reach from end users
let your handsets talk to the one-and-only trusted SBC on the LAN
life is good

I have various small offices setup like this and they are ~zero trouble / zero frustration.

ie, Often - debugging little things - burns time and generates frustration quickly.

Tim

 

[Michael Menor]

We're seeing these as well, but we're using a physical SBC running Windows. There's no rhyme or reason and the drops are completely random.

 

[SteveITS]

And no packet loss at those specific times? One would need to have a test running of course, as I alluded to above.

 

[Colorado VoIP]

the only time we've experienced what you're describing directly related to the customer's internet having malfunctions. confirmed by running ping tests reflecting extremely high latency and packet loss. the tunnels will drop with enough packet loss.

 

[Kevin Attard Compagno]

Just to echo what others are saying here, the ONLY thing that fits is an intermittent connectivity instability at the time when the SBCs disconnect. I strongly suggest you focus your investigations on that.

 

[stuartpgs1]

The internet connection posts

> How stable should a healthy SBC tunnel be in practice?

Normally, up 24x7 unless there's a connection drop at either end.

Especially if it's multiple router phones I expect you have sporadic packet loss at either this location or the 3CX server if multiple/all locations drop at the same time. Try a "ping -n 1000" to various IPs...3CX server if it answers: local router LAN IP, 8.8.4.4, ISP WAN gateway, etc.

We tried the ping first time there were 3 packets lost out of 1000 subsequently we have tested many times and no packets are lost. We have installed a Raspberry PI as an SBC. Its still going up and down.

 

[adam5000]

whats the time difference between up and down?

 

[stuartpgs1]

whats the time difference between up and down?

Almost instant

 

[adam5000]

That's normal, nothing to worry about - unless you're saying this is affecting the end user?