Light-Weight SBC for Remote Office

edwindrood

New Member
Dec 15, 2025
3
0
1
59
Let me describe simply what I am wanting to do:
  • Install FusionPBX in-the-cloud on a OVH instance. (connected to VOIP.ms)
  • Install 5 end-point desk-phones in each of three different offices (where I do not have control of the Router)
  • Install an SBC on a light-weight small computer to connect the desk-phones behind NAT.
Ideally I would like to channel all of the RTP UDP traffic to the FusionPBX via the SBC over a single port (like 5090) that stays open, being initiated from inside the NAT.

I see great documentation on setting up a basic SBC for this on:

To simplify this, I also see that LibreSBC may be easier to deploy.

I plan on installing the SBC on an Atomic PI (small Cheap Single-Board x86 computer)

The main two issues that I have are:
  1. There are so many reasons for SBCs and they are so much a swiss-army knife of everything under the sun, it is nearly impossible to find just a simple "behind-the-nat" example. I do not want Load-balancing, HA in the cloud. I only want a simple behind-the-NAT SBC in a situation where I cannot open ports in the firewall in these three offices.
  2. I cannot find anybody who has a simple built-in solution for funneling all UDP RTP traffic via a single forced open port.
Therefore, I will attempt. using github/fatedier/frp to create a light-weight reverse-tunnel with all ports going over that.

I guess my main question is: Am I re-inventing the wheel here? Doesn't somebody else already have a better solution? (Let us assume that the IP phones do not have STUN capabilities)

I'll check back later, and if I have any results from my testing I will reply to this.
 
I don't see any reason why you would need an SBC, unless you have some crazy internet, fusionpbx should work just fine without it.
 
  • Like
Reactions: RTL
When your central PBX is not on your network, but rather behind a NAT (or on a remote vps), you will definitely (at a minimum) need to open ports for SIP Authentication and for RTP (audio) so that the phones can connect to the PBX.

You are correct. You do not need to do anything to your local NAT firewall for modern Yealink, Fanvil, etc. ip phones to connect. They have STUN and RPORT built in which are used to let FusionPBX know the path back and to create a reverse tunnel port for audio. However, my phones do not have that capability. (At least I do not think that they do)

I shall have to do some more testing. My massive amounts of Google searching is telling me that I am not the only one who has this issue.

1) If your phone does not have STUN or RPORT.
2) If you have no control of the local firewall (behind which is your desk-phone)

How do you get your phone to connect to the server? The phone can make an outbound NAT connection but both calls and audio coming in need to have an established path.

I happen to have about 30 Polycom vvx 410 phones. These are nice phones. I like the Polycom features. I like the color screen. I like the internal paging feature. I like that I can find plenty more of this model phone on e-bay for around $15 each.

Also there are many benefits to having an SBC. I have a few spare Raspberry Pi on a shelf, but I also have a few small x86 computers (Atomic Pi) which make great little headless Debian servers. I shall post here if I get one up and running and let everybody know if I think this is a good solution. Even better -- if I can get it to work on a Raspberry Pi 4B

If you know of a working template to get incoming calls to work on a Polycom vvx 410 behind a NAT, I would like to know about that. Although I do not see the features from the web interface, it is possible that some settings on the Polycom can only be made via template.
 
I'm sure there are lots of people on here using Polycoms, I certainly had a VVX and had no problems with it at all. Freeswitch is very good at handling NAT. Right now, for the past 4 years at least I have at least 100 different clients to a PBX on Oracle cloud which has a natted IP eg 10.x.x.x the PBX sits on and we have never had a NAT issue with any of the clients.