I see the SBC as the biggest bottleneck in the platform
You know that voice traffic consumes very little bandwidth? The whole point of the SBC is to get around the issues of NAT traversal, which it does very well. Keeping the media local for local DECT to DECT calls is also great. Others in this thread have listed the various benefits so won't repeat those.
It would be crazy to remove software SBCs. I use a multicell of multiple redundant DECT base stations. I have a pair of discrete standalone software SBCs setup as a HA failover pair.
If software SBCs were removed, this would kill me. There's no way that the manufacturer would come out with a new model of DECT base station with built-in SBC, and even if they did, I'd have to re-buy all this equipment, which has no justifiable business case - we'd sooner leave 3CX for something else, than rebuy, reinstall in roof cavities, and reprovision all of that.
Even if the rebuying of dozens of DECT base stations was somehow approved, you'd then have the complexity of trying to work out which one would be the active SBC and backup SBC for the multicell environment. I think it would be a head-scratcher. There's already enough complexity in DECT multicell already, without tossing SBC into that management domain. No - it is better to keep the SBC functionality completely separate for this use case.
Here's the big thing though - QoS. With software SBCs, I have fine-grained control over traffic marking and shaping using Linux nftables. For example here's what I configure for my environment:
Code:
techsupport@go3cxsbc1:~ $ sudo nft -s list ruleset
table inet qosmark {
chain postrouting {
type filter hook postrouting priority filter; policy accept;
counter ip protocol udp udp sport 20000-20127 ip dscp set ef return
counter ip protocol udp udp sport 5060 ip dscp set cs3 return
counter ip protocol tcp tcp sport 5060 ip dscp set cs3 return
counter ip protocol udp udp dport 5090 ip dscp set ef return
counter ip protocol tcp tcp dport 5090 ip dscp set cs3 return
counter ip protocol udp udp dport 123 ip dscp set ef return
}
}
With SBC built into a hardware device - I'm constrained by whatever options the vendor may or may not give me. With Debian Linux - I can basically do whatever in this regard. Packet sniffing is also a boon.
So having a SBC built into desk phone or two for a small office environment is perfectly fine. But in a bigger corporate environment with much more network traffic, it just doesn't fly - especially when it comes to DECT.
Remember that desk phones aren't the only use of SBCs. There's DECT as I've just mentioned, but I also use the SBCs for the odd fax-modem for the rare instance that a fax has to be sent (which is basically never these days, but I still like to have that option, possibly for sentimental reasons lol). There would be zero demand for Grandstream to come out with a fax-modem (HT801 or HT802 derivative) with a built-in SBC.
SBCs are here to stay. If you can setup a small office environment that doesn't need one or two, then all power to you. But I NEED them 100%, and they are one of the best things about 3CX, truth be told, and a big part of why I came over to 3CX, back in the day.
