SBC x STUN which and when to use?

[Ruymar Castro]

I would like to know if in fact there is any recommendation from 3CX for the use of SBX x Stun, ie when and why to use SBC and not STUN?

Can I have a 3cx with 50 extensions in stun?

What is 3cx's recommendation for the use of one (SBC) and the use of the other (STUN)?

 

[Evolute IT]

For STUN, the recommendation is 3-4 phones top. Not because it doesn't work but because above that, it's a management nightmare (unique SIP and RTP ports per device + local static IP per device + port forward for each).

Above 3, go SBC. Not only it's easier and remove the requirement for all of the above, it also keep the audio flow local (if phones are under same SBC and call recording and "PBX Delivers Audio" are disabled). It also listens to multicast locally so new phones appear in the console automatically.

I'd say, if you need 2-3 phones in one place, the Webclient is the best way to go. If you need deskphone, a Pi 4 SBC is the better route rather than counting on the firewall NAT to be reliable.

 

[Ruymar Castro]

Frederick Marcoux, thanks for sharing your knowledge and opinion.

 

[Marco Lagoa]

In scenarios of decentralized IP phones, STUN is recommended, whereas in scenarios with several IP Phones in a single office (site) it is a good practice to use the SBC, as the gain in management and security is great. In companies that have a stricter security policy, the SBC is fundamental, as it greatly facilitates the release of SIP and RTP signaling only for the SBC's IP, without the need to release traffic from other ports to the internet. I practically use SBC whenever I can.

 

[Osney Santos]

For good practice I believe that sbc should be used when you have more than 3 IP Phones.

This reduces the firewall configuration and maintains the security of your LAN.

As an advantage, you also maintain audio traffic on your LAN, reducing bandwidth consumption.

Some may argue that it is not necessary to increment the ports for stun as 3cx recommends but the fact is that there is documentation for this and they must have performed several tests to prepare this documentation.

 

[cobaltit]

So if you have to ask this question, the answer is simple. Always use SBC, never use STUN. Once you've been doing this for a while and you've established knowledge of your firewall, then you can decide. STUN is 100% dependent on the firewall in front of the phone working properly. SBC doesn't care. STUN, without prior knowledge, is like rolling the dice. SBC is a sure thing.

 

[SweetAction]

<snip> + local static IP per device + port forward for each).</snip>

I have to bring up that this misinformation, which is commonly spread around, only is needed if the upstream device is not STUN friendly. You do NOT need to forward ports in STUN to local devices, the whole point of STUN is the device punches holes outbound to the STUN server, the STUN server learns them, and then inbound traffic can be sent that way.

If you can ensure the upstream device is STUN friendly you can do 50 extensions via STUN no issue. You could do more. You could do less.

If you won't have that ability, then go SBC - even for 1 phone. It's not worth the headache.

If you are going to port forward to a device (which is why it needs a static IP) what you are really doing is direct SIP. Which has a whole host of security concerns so don't.

3CX docs on STUN are here: https://www.3cx.com/pbx/what-is-a-stun-server/

@Ruymar Castro - Look at slide 6 here for recommendations. My recommendation is to always go SBC unless you must go STUN.
https://www.3cx.com/3cxacademy/videos/intermediate/configuring-remote-extensions/

 

[Evolute IT]

I have to bring up that this misinformation, which is commonly spread around, only is needed if the upstream device is not STUN friendly. You do NOT need to forward ports in STUN to local devices, the whole point of STUN is the device punches holes outbound to the STUN server, the STUN server learns them, and then inbound traffic can be sent that way.

Actually, see https://www.3cx.com/3cxacademy/videos/intermediate/configuring-remote-extensions/ Slide 7. It says "NAT to IP Phone in Remote Firewall".

While it is not necessary for SOME firewalls (those that are NAT friendly), it IS recommended and required to get support from 3CX.

@Ruymar Castro - Look at slide 6 here for recommendations. My recommendation is to always go SBC unless you must go STUN.

You forgot the link but I think it's the same as I just posted. Slide 6 instead of 7.

 

[SweetAction]

Actually, see https://www.3cx.com/3cxacademy/videos/intermediate/configuring-remote-extensions/ Slide 7. It says "NAT to IP Phone in Remote Firewall".

While it is not necessary for SOME firewalls (those that are NAT friendly), it IS recommended and required to get support from 3CX.


You forgot the link but I think it's the same as I just posted. Slide 6 instead of 7.

I can't tell you why the slide says that.
However I can tell you that STUN use in 3CX is literally designed to not need to open any ports manually. When you open the ports you are no longer needing STUN at all - you are now doing Direct SIP. Use any SIP device you want at that point - even ones without STUN will work in those setups.
I've done STUN phones many times before and never opened any ports on the remote, STUN friendly, firewall.

EDIT: Thanks for catching the missing link, I will edit my post now.

EDIT2: STUN use in 3CX is simply a way for PBX to learn the public IP of the hardphone (optionally what port the hardphone made an outbound connection on, but instead we specify that in the console) (which means traffic can return to the phone on that port). If you have NAT issues, STUN won't fix it.

 

[Evolute IT]

EDIT2: STUN use in 3CX is simply a way for PBX to learn the public IP of the hardphone (optionally what port the hardphone made an outbound connection on, but instead we specify that in the console) (which means traffic can return to the phone on that port). If you have NAT issues, STUN won't fix it.

Thus why the port forwarding required when the firewall is not friendly. For example, I had a Meraki MX64 before, I had to open ports for the phones to work correctly or I would get one-way audio a lot.

Now, we use a Fortigate FG-81E and the problem never occured again without any port forwarding nor SIP ALG.

As you said, STUN is for the public IP more than anything else. TURN server would do what you said earlier tho!

I should've just said that lol long week!

EDIT: Thanks for catching the missing link, I will edit my post now.

You're welcome! Thanks for not shooting the messenger for the STUN thing