Why SBC still?

[Discovery87]

Morning Chaps

This is one for 3CX staff probably... (BTW this isn't a rant/complaint we love 3CX!)

Just wondering... Why do we have to put SBC's on site for all clients when 9/10 times the losing provider's system which we are replacing does not need one? I know we can run 3CX in STUN mode but that's always been terrible and requires a lot of manual router configuration for ports etc. Why does nearly every other VoIP solution out there simply 'work' out of the box, phones can go literally anywhere and just work but 3CX needs an SBC?

We are about to take on a large 100 user system (well large for us anyways) and this question has come up. We always put SBC's on site and everything works really well, but it does create a vulnerability in the system. The client will (rightly so) ask what is the benefit of us hosting their awesome new shiny VoIP system in AWS cloud if it's all dependent on a Raspberry PI in their server room?

Cheers!

 

[Evolute IT]

Why does nearly every other VoIP solution out there simply 'work' out of the box, phones can go literally anywhere and just work but 3CX needs an SBC?

What these companies don't say is that the service isn't reliable without one. Direct SIP or STUN can be useful, but the more phones you have, the worst it gets, specially if the firewall isn't smart with NAT.

3CX just decided to be honest and say: use an SBC to avoid issues. Or, go STUN and pray.

As for the question, tell the customer that this box is only for deskphones. If they use the softphones only and mobile apps, this device isn't required. Therefore, the equipment is required because THEY want deskphones. Otherwise, no power or no internet? Use the apps (mobile apps.)

We never got asked this by a customer because we present the system as fully cloud (except if you want deskphones.) Most customers are currently ditching deskphones for the apps with headsets.

 

[Discovery87]

What these companies don't say is that the service isn't reliable without one. Direct SIP or STUN can be useful, but the more phones you have, the worst it gets, specially if the firewall isn't smart with NAT.

3CX just decided to be honest and say: use an SBC to avoid issues. Or, go STUN and pray.

As for the question, tell the customer that this box is only for deskphones. If they use the softphones only and mobile apps, this device isn't required. Therefore, the equipment is required because THEY want deskphones. Otherwise, no power or no internet? Use the apps (mobile apps.)

We never got asked this by a customer because we present the system as fully cloud (except if you want deskphones.) Most customers are currently ditching deskphones for the apps with headsets.

Thanks pal this is useful. I have to say that as of yet I have not seen anything to make me think that previous VoIP systems we replaced we're unreliable. Most of time we are just waaaaay cheaper! What you are saying makes sense to me, I just haven't seen it in my experience. I can appreciate though, that most of our customers are 20-30 users or smaller so perhaps that is why?

 

[Evolute IT]

Thanks pal this is useful. I have to say that as of yet I have not seen anything to make me think that previous VoIP systems we replaced we're unreliable. Most of time we are just waaaaay cheaper! What you are saying makes sense to me, I just haven't seen it in my experience. I can appreciate though, that most of our customers are 20-30 users or smaller so perhaps that is why?

Perhaps it is. They may have good equipment also. Or, they got lucky.

Nobody knowns for sure.

 

[SweetAction]

I can't find my post about it, but basically, you have to handle NAT somehow.

You have 3 IP Phones. They are all behind the same public IP. The firewall / NAT device sitting between those phones and the internet will not forward unsolicited traffic to the phones.
The PBX needs to send a "ring please" message to the phone - so it sends the message to the Public IP (which is answered by the NAT device) and the NAT device says "don't know where this should be going, discard"

So you run a SBC to handle NAT (and other things). Where that SBC lives is generally where things vary - most other providers put that SBC in the cloud - but 3CX has you put it onsite.

There are other ways that are not supported by 3CX to run a SBC in the cloud, but that's besides the point here. For example, I can place a phone anywhere in the world without issue - but I use the built in VPN client on Yealink phones and a OpenVPN server inside the same LAN as 3CX to accomplish.

Hopefully this answers the "why do you need a SBC" as well as the "how do others not need a SBC" questions.

 

[VoIPTools]

Some vendors implement proprietary (non-SIP standard) solutions. If you want a fully SIP compliant solution, then you have to address the complexities of how to ensure communication traverses the firewall(s) reliably. You could implement a very expensive "true" Session Border Controller, but that adds a lot of cost (including redundancy) and complexity.

 

[Discovery87]

I can't find my post about it, but basically, you have to handle NAT somehow.

You have 3 IP Phones. They are all behind the same public IP. The firewall / NAT device sitting between those phones and the internet will not forward unsolicited traffic to the phones.
The PBX needs to send a "ring please" message to the phone - so it sends the message to the Public IP (which is answered by the NAT device) and the NAT device says "don't know where this should be going, discard"

So you run a SBC to handle NAT (and other things). Where that SBC lives is generally where things vary - most other providers put that SBC in the cloud - but 3CX has you put it onsite.

There are other ways that are not supported by 3CX to run a SBC in the cloud, but that's besides the point here. For example, I can place a phone anywhere in the world without issue - but I use the built in VPN client on Yealink phones and a OpenVPN server inside the same LAN as 3CX to accomplish.

Hopefully this answers the "why do you need a SBC" as well as the "how do others not need a SBC" questions.

Hiya, cheers for your time, I totally understand NAT, I guess what I am asking is, why is it even necessary? The Windows app doesn't need it? Perhaps we are looking at the wrong OSI layer altogether? Why can't the desk phones work from a purely outbound connection like any software application installed on a PC?

 

[SweetAction]

Hiya, cheers for your time, I totally understand NAT, I guess what I am asking is, why is it even necessary? The Windows app doesn't need it? Perhaps we are looking at the wrong OSI layer altogether? Why can't the desk phones work from a purely outbound connection like any software application installed on a PC?

The apps actually have a "built in" SBC (tunnel) right in the software. Deskphones do not (at this time, coming soon*) hence why they need an external SBC.

As for why the outbound connection from the phone isn't enough - it actually could be. Configured in STUN with a STUN friendly NAT device in front of it will be 100% functional.

 

[VoIPTools]

Just like other manufacturers, the 3CX software clients can use a proprietary 3CX tunneling protocol to communicate with the 3CX server. (But to be clear, standard SIP is sent over the tunnel). To do the same thing with a physical phone, you would need a 3CX specific firmware loaded on the phone.

The other manufacturers typically sell their own phones, with their proprietary firmware, specific to their PBX. With 3CX, you can make just about any phone work, provided the phone supports standard SIP. But the SIP standard does not address the complexities of having multiple devices behind one firewall. One could make the argument that this is an issue with firewalls rather than 3CX.

Another alternative would be to create a VPN between your remote office and the 3CX server. Then there would be no "need" for the 3CX SBC. However, you get some benefits using the SBC that may not be obvious to everyone. For example, when using the SBC, calls between phones at the same location do not have to send the audio all the way to and from the PBX. The audio stays local after the initial call setup. Also, when sending the audio packets over the tunneling protocol, some of the excessively chatty packets are stripped and automatically reinserted at the PBX. Both of these features reduce the bandwidth needed for phone calls -- an important factor in limited bandwidth situations.