Test Environment before deploying (SBC)

I am testing FreePBX (Plan to use PBXact once live).
I got the main office test environment setup and working correctly.
However I was planning to use Vega SBC at the branch offices to provision/register the phones and connect back to the PBX in main office.

I can not find any documentation on this setup. The documentation i do find is ways to connect the SBC from the PBX on the same LAN but nothing on remotes sites or missing/“the page doesn’t exist”

Do I need a SBC at main office as well as branches? How do I configure the SIPtrunk on the PBX and SBC?

Unless you are building a very large system, you probably don’t need SBCs.

If you have an existing or planned VPN between offices (used primarily for non-telephony applications), you can leverage that to connect phones as if they were all at HQ.

Or, if your phones have a built-in VPN capability, they can connect to the VPN server integrated in FreePBX.

Or, the phones can connect over the public Internet to the PBX, using TLS and SRTP for privacy, with appropriate firewall rules so only the branch office IP addresses have access.

If you do want telephony-specific hardware in each branch, consider using a FreePBX instance. For example, this can be set up so emergency calls will work, even if the connection to HQ is down, or so that intra-branch calls have lower latency and bandwidth usage.

If your branches are far apart (and certainly if they are in different countries), you’ll probably want trunking resources on the PBX in each branch.

The Remote sites most of them are small around 5 phones. I was hoping the SBC would give me a zero touch setup for phones as there are not IT at these sites.

We do have a VPN for Data between the offices but we fully segment our phones from our data network.

So your suggesting to run a freepbx at the remote sites and bridge them?

As as side not we have allworx in the existing system and we had to do a lot of monkeying with ports to allow all the phones at the remote site to work over nat. And would like to avoid that this time around. Played with 3CX and the SBC worked great but phone features for que management was severely lacking.

If this were my system, I would not use an SBC; perhaps some of the experts on this forum will chime in and disagree.

Instead, I would choose one of four architectures:

  1. Get the VPN working properly and have all the phones appear as if they are local. For isolation, you can have two private subnets at each location, one for data and one for phones. You will need some QoS rules so data traffic doesn’t saturate the line and cause voice quality issues. If DHCP for each branch is local, each will have to provide the private IP of the HQ PBX in option 66, so the phones will autoprovision properly. Routing between these nets should be NAT free.

  2. Use the VPN client in the phones to connect to the VPN server in the PBX. You’ll need to initially provision each phone at HQ before shipping to a branch, but reprovisioning should not be an issue. You’ll still need QoS rules unless upload at each branch is so fast it never gets saturated. This option is NAT free.

  3. Connect the remote phones over the public internet, using SIP over TLS and SRTP for security. Each branch router supplies DHCP option 66 as above, so zero touch. NAT requirements: At each branch, no SIP ALG. NAT timeouts greater than registration expiry. QoS rules based on phones IP or MAC range. HQ firewall forwards RTP port range to PBX.

  4. A PBX at each branch with SIP tie trunks to HQ. This is obviously more complex to administer, but might be chosen based on better reliability for 911 calls, lower latency on external calls and/or reduced traffic over the VPN.

1 Like

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