Cloud hosting or regular hosting

[integrity6]

Hello,

I have a customer who has an in-house install of 3CX and wants us to do the hosting. He is currently on v11 and we are moving him to v 12. We have so far never hosted anyone and I do understand that cloud server is great for multi-tenant hosting but if that was not important, are there any benefits to hosting using the cloud server or simply hosting the single instance on our servers and skip the cloud server installation? He wants us the move in a matter of days because of unavoidable urgency.
Will the session border controller work without the cloud server? It is important that the calls between extensions do not travel through WAN. They also use a patton device.

Thanks

 

[craigreilly]

I think it is going to be a little difficult if not impossible to connect your Hosted Server to their Local Patton with PSTN/T1 lines. You can probably do it with a VPN.
I am sure someone else will chime in on this matter for sure.

 

[cobaltit]

SIP trunks, call forward the lines on the Patton to the temp SIP DIDs until you can port them.

 

[ian.watts]

This. Sticking with Patton but hosted PBX offsite sounds all wrong.

 

[Pauliebrisbane]

Hosted PBX's are very common, either in the cloud as a managed service, or at the main "HQ" site while servicing satellite sites with local trunks. Is there a reason why it is bad on the 3CX platform?

 

[cobaltit]

A fully hosted PBX is a different scenario. The concern is pulling the dial tone from the local site to the remote server. Is it doable, yes. But unless that dial tone is under some sort of ridiculous contract, you can and should move them to SIP to make everyone's life easier. You won't find a lot of support for that scenario because it's just not a common or recommended one. But technically yes it can be done.

 

[Pauliebrisbane]

A fully hosted PBX is a different scenario. The concern is pulling the dial tone from the local site to the remote server. Is it doable, yes. But unless that dial tone is under some sort of ridiculous contract, you can and should move them to SIP to make everyone's life easier. You won't find a lot of support for that scenario because it's just not a common or recommended one. But technically yes it can be done.

I would have to disagree. I have installed and supported many solutions with a central call processor and up to hundreds of satellite sites with a mix of local and centralised dial tone. Mostly ISDN and some POTS (No SIP at all), these solutions worked flawlessly and supported by both the manufacturer and carriers.

It is a common solution when you have an organisation with hundreds of office locations. Why buy a PBX for each site, when you can buy a single system and allow interoffice calls over a private WAN.

Or if you have a main hub site and are opening satellite offices, it makes sense to utilise your existing equipment.

These are not uncommon solutions, and I can't see the downside or how SIP will make it easier.

 

[cobaltit]

I have installed and supported many solutions with a central call processor and up to hundreds of satellite sites with a mix of local and centralised dial tone. Mostly ISDN and some POTS (No SIP at all), these solutions worked flawlessly and supported by both the manufacturer and carriers.

Might want to look at the name at the top of the page... it says 3CX. And as far as 3CX is concerned, it is not a recommended or supported solution. The concern is with the dial tone, which you've stated you've done numerous times. 3CX itself doesn't really care as long as it can talk to the gateway. That being said, in this instance you are converting your dial tone to IP and then pulling it across the WAN, which is different from what you are doing before via frame relay.

As far as how SIP makes it simplier....
- No additional hardware for SIP
- If the customer loses internet at the local site, inbound calls will fail. SIP to your data center/office where the PBX is hosted will continue to work.
- And did I mention it would be manufacturer supported?

From a cost perspective, your logic is outdated. 3CX costs a fraction of what traditional digital PBXs used to cost, so it was more cost-effective to do what you mentioned instead of having a separate PBX. Also. your argument about 're-using' existing equipment doesn't fly because you won't be re-using any legacy digital equipment. In the recommended scenario, you would be removing the Patton and most likely saving some cost by switching the analog or PRI service to SIP, but there would be no additional hardware cost.

So to simplify my answer:

- If you are the average Joe and you want to plug your gateway in your customer's location and run in through your Linksys router, go do SIP and keep your hair.
- If you've installed and supported many solutions with a central call processor and local dial tone and you understand things like MPLS, etc, then I think you already have the knowledge to do what you want. Patton support is going to be your best resource for this.
- The SBC will work without the cloud server (you should see SBC as an option in the phone provisioning). And I believe the SBC is actually keeping audio local now per the last change log entry (http://www.3cx.com/blog/change-log/3cx-session-border-controller-build-history/) although I haven't wiresharked it myself to confirm.

But at the end of the day, do what you feel is best because you are supporting it. With Patton's blessing you should be ok, but you won't get support from 3CX.

 

[Pauliebrisbane]

Thanks for the reply, I have been trying to get that information for a while now as I have been looking to spec up 3CX systems similar to the others.

Example - 100 sites:
1 x centralized Call processor / PBX (Software or hardware) at HQ
All remote sites register with the central call processor at HQ
Gateway at major remote sites with connection to the PSTN and local failover in case of WAN failure. (calls still work in/out during WAN failure)
LCR implemented (TEHO) to reduce call costs.

I am new the 3CX so I may be looking at this the wrong way.
The above is what I have been attempting to replicate with the 3CX.
If I remove the remote gateways and have no local failover, I understand I would still require an SBC at each remote site?
If the phones are not in the same subnet as the 3CX server they will not use RTP between each other?

When I spoke to the distributor the best solution appeared to be a 3CX server at each site and bridge them together. This is when I saw the costs start to drive up above the centralized solution.

If I have missed something or interpreted something wrong please let me know.

 

[netswork]

I have a customer setup like this. Its not hosted but its the same. We have one 3cx server with 3 locations. Each location has a patton 4970 terminating a PRI and it works great. Once 3cx sets up the call the RTP is only between the gateway and the phone.

If you were going to host it using a VPN there is no reason it would not work.

If your going to host it and move it to sip just make sure the customer is the end user of the SIP service or there are a lot of hoops to go through for taxes.

 

[netswork]

If I remove the remote gateways and have no local failover, I understand I would still require an SBC at each remote site?
If the phones are not in the same subnet as the 3CX server they will not use RTP between each other?

When I spoke to the distributor the best solution appeared to be a 3CX server at each site and bridge them together. This is when I saw the costs start to drive up above the centralized solution.

If I have missed something or interpreted something wrong please let me know.

I have no experience with the 3cx sbc. If you have a private WAN or VPN then the SBC/tunnel is not needed. We run all of our clients over VPN.

I have one customer with 8 locations and they chose to put a 3cx server at each site for redundancy. 3cx works the same as a centralized call processor your used to in that once call setup is done, RTP is between handsets or handsets and gateway only. If your using a sip service then the RTP goes through the 3cx server. You can however setup a patton to terminate the sip trunk and have the RTP between the patton and the phone. RTP will be delivered from the server for MOH and for conferencing. I have several clients with multiple locations and only one server. Use a private WAN or VPN and its easy. I have never had any trouble getting support from 3cx when I needed it.