Background: We use 3CX Phone system in conjunction with Peplink to make for a great VoIP solution. 3CX’s session border controller (SBC) allows remote IP Phones to connect to the PBX seamlessly. 3CX has worked with IP Phone vendors such as Fanvil and Yealink and now these phones can run the SBC on-board.
Feature request: A custom firmware for devices such as Balance 20, Surf SOHO, Balance One & Balance One Core. The firmware would bring the 3CX SBC onto the router directly.
The firmware would present a simple option to add the 3CX URL and Authentication KEY ID into the Peplink UI creating the SBC tunnel between the PBX and the router.
Key Benefits:
- Makes unbreakable VoIP deployments EVEN easier
- Allows Peplink partners to target any 3CX customers and more than 25k global partners
I have previously had this thought as well, and my comments are:
- The ability to do it on phone’s now negates most of the need
- It could be done right now if 3CX had a Python or docker version of the SBC, using the edge computing functionality of Peplinks (not all of them note).
1 Like
I agree the SBC on the phone helps but (currently) only supports up to 10 IP Phones. For those 10+ user deployments it still makes sense to use a single SBC rather than deploying multiple SBC phones.
I note the edge computing comment but for the proposition to be attractive to the wider 3CX community, the function needs to be available on the routers with the lowest price points…if you have to spend thousands on a router then it’s cheaper to deploy a mini-pc to run the SBC.
I get that, but it also makes it harder to justify supporting (and harder to do).
The other option is of course to route the voice traffic through a Speedfusion tunnel to the 3cx (although this cannot be done with the 3cx hosted variants). This can have other performance benefits too, with all the Speedfusion traffic engineering options available.
In Germany a very popular SoHo Hardware is the FritzBox from AVM. This has also a SIP System inside, but the device itself is not the best.
To change such a bad hardware with Peplink could be great.
so +1
We use 3CX and Peplink extensively, yet I’m not interested in this feature at all. Here’s why:
Instead of using the 3CX SBC, we put a fusionhub in our VPC. Using a little routing magic and speedfusion WAN Smoothing, we get much much better overall results than using their SBC, and it can be setup right now on about any peplink device all the way down to a BR1 Mini Core (hw3 of course).
In fact, if I have a existing legacy raspberry pi SBC die, a mini core will replace it.
Sure. it’s an interesting idea, but I think a lot of us using peplinks with 3CX are using it to get away from SBC to a more reliable solution with speedfusion, rather than double down on SBC.
Hi, I’m very interested in learning more about how you effectively used SpeedFusion as an SBC. We have an IP PBX behind a Balance 20x with two ISPs. Our SIP provider can easily route calls to either ISP. The problem is, our IP PBX only supports a single WAN IP address. So if the call is routed to Balance WAN1 IP, and PBX’s WAN address does not match that same IP address, (the sip target), then the call signaling will fail. The only way we can really fail over to ISP2 is to manually reprogram the primary target at the phone company, and change the WAN IP of the PBX to match ISP2 (Balance WAN2 IP address).
We need the IP PBX to have a local IP address as it would with an SBC.
We have SpeedFusion bonding set up between sites so we can seamlessly route calls to IP phones at a second location (which also has a Balance 20X and 2 ISPs). And that works great with the WAN Smoothing functionality.
Any info you could share on how you are effectively routing SIP traffic via two ISPs to a single IP PBX target would be very much appreciated. Thank you!
This is the way. In 2011 I rolled out a 270 handset 3CX system across 30+ sites. The only way I felt comfortable doing this was because I had already deployed a Peplink SDWAN for seamless VOIP failover across multiple WAN links. We were using bonded 3G for VoIP at some locations even then.
Still today when I deploy 3CX its always in the cloud sat next to a Fusionhub with Peplink devices at the remote sites.
2 Likes
Fusionhub in a datacenter on super reliable routed networks with multiple peers. Your public IP for the PBX sits there on the FusionHub appliance WAN interface.
You then port forward from the Fusionhub over Speedfusion VPN to the 3CX LAN IP on the 20X. Effectively you are moving NAT from the B20X to the Fusionhub.
Now all VOIP traffic sent between the FusionHub (and your public IP that is the target for your SIP trunks) and your PBX benefits from seamless failover across any connected ISP on your B20X.
2 Likes