Remote Extensions Best Practice

I’m looking to switch from a very well known VoIP system to VitalPBX, probably using a carrier license. I’ll have dozens of tenants, all at remote locations. With my current system setting up an SCB at each remote site is almost trivial, and works flawlessly using a Raspberry PI or any other single board computer. As I’m looking into Vital, I’m not seeing a clear answer on best practice for dealing with hundreds/thousands of remote extensions and desk phones. Is there a simple SBC that I can set up like I have now, or is it standard to set up many VPNs to connect from remote sites. Any insight would be appreciated.

1 Like

Not sure I totally follow.

You have the PBX in the cloud and an SBC at each remote location? What is the purpose of the SBC at the remote location?

OP is referring to 3CX. SBC at each remote location is to overcome any possible firewall problems. It’s a sledgehammer to crack a nut in many cases.

1 Like

Understood.

So each client has an additional internet for the SBC?
Does the SBC act as a mid-registrar or as a gateway/proxy?

My understanding is that the SBC acts as a proxy for all phones on one site behind the same NAT/firewall. I never bothered with it myself though it does involve a couple of config changes. I think as much as anything it was to avoid extra load on 3CX support (which I understand).

The SBC is set up on the LAN at each remote site and acts as a proxy for all remote phones.

We’re told repeatedly by 3CX that direct provisioning over the internet without the SBC is insecure and should not be used under any circumstance. That’s why I’m reaching out for advice. I’m looking for an idea of what others are doing for multi-site remote extensions at scale.

Please excuse my ignorance as this is the only solution I’ve ever used in a professional environment.

TBH, I am not sure how a SBC at a client side behind their firewall is going to solve any potential firewall issues.

  1. Are you referring to config file provisioning? If so, using https with auth provisioning is very secure and you shouldn’t use an SBC for that, rather use a WAF.
  2. If you referring to phone calls, a TLS+SRTP connection is very secure. However, that doesn’t protect the PBX from attacks/hacks etc. An SBC at the client side also doesn’t protect the PBX. So not sure…

Asterisk is capable to handle hundreds of concurrent calls. However, 50 simultaneous call setups is going to use more CPU than 150 concurrent calls that weren’t setup simultaneously.
Of course, if you do UDP sessions, your load is going to be way lower than doing TCP or TLS.

So…
I would setup an SBC that sits in front of your PBX that does the following:

  • Edge proxy
  • Mid-registrar
  • Security rules to allow only authorized users
  • TLS/SRTP to UDP bridge. So the phones talk to the SBC securely over the internet and the SBC talks to the PBX over UDP to reduce the load.

I hope that makes sense

1 Like

Having the SBC behind the client’s firewall allows for all traffic to be tunneled through the client’s firewall by the SBC device. No need for any open ports. No one way audio problems, no call drop problems etc.

One way audio issues or opening ports is normally for the side of the PBX being behind a firewall.

Can you elaborate on the tunnel? Between what systems and what protocol / technology is used for the trunnel?

Blockquote We’re told repeatedly by 3CX that direct provisioning over the internet without the SBC is insecure and should not be used under any circumstance. That’s why I’m reaching out for advice. I’m looking for an idea of what others are doing for multi-site remote extensions at scale.

We have been doing multi tenant remote extensions for many years, before we even started using VitalPBX, and have never had an issue. We actually decided against 3CX because of the need for SBC or other device onsite, not willing to trust the uptime of our solutions to a Raspberry Pi. 3CX is the only solution that requires this as far as I know so I don’t see the lack of it as any issue.

Brian, I know that I am going a bit off-topic, but I am very curious about this SBC requirement at the client side. Do you have more information about this? See my questions above.

I am a huge fan of having an SBC in front of the PBX, to do:

  • Traffic filtering
  • DDOS prevention
  • Blocking
  • Header manipulation
  • Bridging
  • Transcoding

All these stuff that takes off a huge load of the PBX and in the same time keeps the PBX protected.

I feel the problem is that this box is named SBC by 3CX. It is not really an SBC in the way that you think of it. Instead I think it should be renamed CSB (Client Side Box) whose function is to tunnel traffic to and from the PBX (and handle local traffic, that is extension to extension traffic which does not need to go across the internet at large).

SBC in this case is short for Session Border Controller (Not Single Board Computer), it does have some advantages such as I believe you can call inter office even if the Internet is down, but as I said it is a piece of remote hardware that has to be maintained, and could fail, so I’m not a fan of them especially in situations where we may maintain the phones but not the network.

You can read the 3CX link about it here. 3CX Tunnel/Session Border Controller | What it is and how to use it

(Hopefully links to other products for discussion purposes like this are allowed, if not I apologize in advance.)

1 Like

Thanks for the insight. Do you have any recommendation on what SBC(s) you use/works well sitting in front of the PBX?

We recommend FREESBC de Telcobridges, some time ago we made a blog in conjunction with them. FREESBC has very good support and the price accessible month.

https://telcobridges.com/vitalpbx-case-study/

What 3CX refers to as an SBC is in reality simply a VPN that the physical phone devices use to connect to the PBX. Yes it may do some signaling magic, but in the end you can do the same with a simple VPN to each remote location. It used to be a decent product, however from the number of 3CX partners that I see embracing VitalPBX I am not the only one who has lost confidence in 3CX. On the flipside, we use the 3CX SBC with teamviewer installed to allow us to test network/audio quality at the remote location, without having to pester a client to let us set up a remote connection to a local machine for testing purposes.

1 Like

Please, read the following Blogs and you will see how easy it is to enable a VPN in VitalPBX with the OpenVPN module

Thank you, much appreciated!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.