Hosted 3cx - Which virtual SBC to allow provisioning of "legacy" phones

[us1]

With v15 breaking support for remote provisioning of Polycom phones, my ability to sell the platform to customers with Polycom phones (as well as use of the common Polycom conference phones) has diminished significantly.

I came across a post in the forum regarding how an SBC (NOT the 3cx SBC...this particular post was regarding Sangoma SBCs) would allow for provisioning of those devices to the remote PBX. Would anyone from the 3cx mind sharing details on 1) How this would work and 2) Recommendations on third party SBCs that would allow this to operate.

Thanks.

 

[eagle2]

Alternative solution is to use VPN / Layer 2 tunnel connectivity, which could be provided by some routers (you need to be able to configure them -- both the router in front of the PBX and at remote sites).

 

[us1]

Alternative solution is to use VPN / Layer 2 tunnel connectivity, which could be provided by some routers (you need to be able to configure them -- both the router in front of the PBX and at remote sites).

I'm hoping to avoid the VPN route if possible. My goal is to have as few things to "break" as possible between the PBX and the endpoint. I understand the SBC route would essentially be another "thing" to possibly break but it keeps configuration on the customer side to a minimum.

Thank you for your input!

 

[eagle2]

SBC can be limited to 5 or 10 phones supported, depending on hardware used. Also not all phones are able to use SBC as a proxy server. Using only routers means less devices, in all cases you need the routers in place plus eventually the additional component -- SBC. So there are pros and cons of VPN/VLAN solution compared to SBC one. SBC could be preferred solution for small remote sites and/or unsuitable (SOHO class) routers to create tunnel to main (PBX) site.

I'm widely using MikroTik routers for connecting sites, which have excellent price performance (starting at $20) and are able to provide both Layer 2 and/or Layer 3 connectivity. Layer 2 connectivity allows all phones and PBX to belong to one and the same broadcast network segment, which makes provisioning task simpler. On Layer 3 you can use DHCP Option 66 to automate provisioning.

 

[Umbrella]

I'm also looking for a way of minimizing fault points, we currently hosting on the cloud.
the following may be a newbie question , but can someone point out how does ringcentral and other big VOIP companies do not require SBC or Tunnels to work, and are still able to offer uninterrupted service ?.

 

[cobaltit]

@Umbrella RingCentral and other hosted VoIP providers do use SBCs, they just do it on their end. It doesn't really matter which end the SBC is on, only that there is one in the path to help with NAT transversal.

 

[Umbrella]

@Umbrella RingCentral and other hosted VoIP providers do use SBCs, they just do it on their end. It doesn't really matter which end the SBC is on, only that there is one in the path to help with NAT transversal.

Thank you for the info I was not aware of that. So if i'm hosting the pbx on the cloud (google) can I host the sbc as well ? which begs the question why isn't the sbc bundled with the pbx ?

I guess I need a bit more clarification

 

[cobaltit]

Well the SBC provides two functions; assisting with NAT transversal and security. So typically your SBC would not reside on your PBX although Xorcom does it that way. There are solutions and it may be something 3CX has on the roadmap but may be slowed by a desire to have the same functionality on both Windows and Linux. In the meantime you have to use the 3CX SBC or VPN on the client side or find a partner/company that will offer you hosted SBC solution.

 

[Umbrella]

I appreciate 3CX commitment to linux, we use only linux versions on our installs. with that being said we cant rely on Raspberry's uptime.
we're looking for a robust setup that will just work out of the box. without hardware appliances involved, of course one can argue that the switches and routers are included under the same umbrella but these are all proven to last for a very long time.

to follow up on my previous post, instead of using a 3rd party for hosted SBC can we install the 3CX sbc on the cloud, on a separate instance from the pbx ? will that work ? how will that resolve the NAT issues on the client side ?

 

[cobaltit]

@Umbrella

You can install Debian on a machine and install the 3CX SBC on that instead of a Pi3. Otherwise the only way to have the 3CX SBC hosted would be to bridge or VPN the hosted SBC instance to your local network. The 3CX SBC does not work in the same way as a traditional SBC so the SIP listener needs to be local or at least not have NAT between it and the endpoints. Not having it on the same broadcast domain would also eliminate the PnP ability although you should be able to provision the phones to it just fine. This is all theoretical though as I've never actually done it but it should work in this fashion.

 

[Umbrella]

@coabltit

Do you have any experience with SBC on pi's in a production env? what is the uptime on these, how often do they fail ?
it would even make sense to install one and keep a clone as a backup in the local office. the last thing we all want is a customer calling saying his phones are down. By hosting the pbx on the cloud at least I can configure failover per extension by forwarding to an external cell number. this was one of the main reason i'm opting for the cloud base pbx rather than on-premise.

 

[leejor]

The raspberry Pi's are cheap enough that you could easily afford to have two (clones), at a location, and a set-up to toggle the power supplies with a simple 3-way AC switch.

 

[cobaltit]

@Umbrella

I've had reasonable success with the Pi's. The devices themselves are pretty solid, the bigger issue is how they recover when power is lost. There's a couple threads on settings to make them more reliable in that situation with scripts and setting changes. We still do most of our installs on-premise but other folks on the forums (@DSXDATA I believe) use them quite a bit with good results.

 

[us1]

Bvoip has a "cloud" SBC they use in front of their 3cx deployments. That said, I don't know their SBC of choice nor how it improves the service for their customers.

 

[sip.bg]

SBCs on providers site or in front of PBX cope with NAT issues mostly, also could act as firewall for filtering access to PBX / provider.
In such cases you usually need to configure SIP server and outbound proxy server into SIP endpoint, not STUN server (to send endpoint's public IP address and port to PBX / provider during registration).

With 3CX PBX this is not necessary (on the PBX site). In most cases even using STUN is not obligatory, as 3CX PBX will use the public IP: port from which traffic originates, but this may depend on NAT used in the remote site. It is recommended to use 3CX PBX public address, port 5060 as STUN server for remote endpoints.


On remote location sites you can you use also so called 3CX SBC which are doing mainly two things -- encapsulates the VoIP traffic to port 5090 TCP/UDP and provides a level of security by using 3CX tunnel. Hardware phone behind 3CX SBC is equivalent to 3CX soft-phone using 3CX tunnel to 3CX PBX. This solves any NAT issues on the remote site and adds security.


The alternative is to use IPsec VPN tunnels between sites, specially in a corporate environment.

 

[neville]

I have been testing a solution that one of the support people posted on the forums sometime in the past. I am using stun, incrementing the port for each phone, checking PBX delivers audio, and allow access outside the Lan. I have not made any changes to my Sonicwall and everything seems to work fine testing up to 6-8 phones.

This requires a solid internet connection as all the audio is handled by the phone system.

@us1 If you message me, we can discuss a network based SBC I have tested that works very well.

Chuck