Best Practices / Best Solution

[andrew_s]

Hello, I am new to 3CX and evaluating the solution. There are many "supported" phones, gateways, trunks, and hosting solutions. I am trying to determine if there is a most preferred solution that people have found with cost not interfering with the recommendation. Looking to see if there a solution that has the least amount of problems. Sorry if this has been discussed before, and if so if you could link the thread that would be great. Searched myself and could not find it.

Questions:
1. Cloud or on Premise?
2. Which gateways/trunks are best for either solution?
3. What is the least problematic handset?
4. What pitfalls to avoid with 3CX?
5. Which version of 3CX?(windows or linux? and also which build version)


If anyone has found the "magic" mix, please submit your solution and tell me why it's the "best".

Thank you!

 

[Nick Galea]

Hi Andrew

The questions should not be answered from a 3CX point of view but from your use case.

1. Cloud or on Premise?
Depends on your use case - are most of your staff working remotely? How big is your deployment? Do you already manage servers in the cloud on amazon, google, or OVH or another hoster?

2. Which gateways/trunks are best for either solution?
Depends on your internet connection. SIP trunks are the way to go if your internet speed can handle it. If you want to use 3CX in the Cloud you must use SIP trunks anyway.

3. What is the least problematic handset?
All supported handsets. Firmwares are tested and phones are fully supported by our support team.

4. What pitfalls to avoid with 3CX?
Do not use unsupported trunks or phones.

5. Which version of 3CX?(windows or linux? and also which build version)
Depends on your inhouse know how. If you have Windows Servers/ Machines in your office and are comfortable managing that, use the Windows version. In the cloud or on an appliance, use Linux

Hope that helps.

regards,

 

[andrew_s]

It does, thank you

 

[tsukraw]

Andrew,
As a installer here is my feedback based on my experience and what we do for our customers.
Keep in mind we have not tested every setup. We just know the way we do it is rock solid.

1. Cloud or on Premise?
We tend to do more on-prem vs cloud. The "Customer" in this case has more control over their system if it is on-prem and we seem to have better results over all. This is also a bit dependent on your deployment type. PRI/analog is not as easy to do in the cloud.

2. Which gateways/trunks are best for either solution?
Patton gateways hands down have been the best gateways made in my opinion. For both PRI and Analog use no other.

3. What is the least problematic handset?
We use almost 100% yealink phones. We have customers out there who have used the same models for clost to 10yrs and they are still moving along. Avoid the cheaper model phones, not that they are bad.... but you get what you pay for. We try to stick with the T4 and T5 series phones with Yealink. They cost a bit more but the feel and quality is worth the extra $

4. What pitfalls to avoid with 3CX?
This one is a little hard to answer publicly as i am sure Nick will read it. But I'll be honest with my response. One area we at times struggle with is not necessary the system its self but support. Not sure where you are from "I am in the USA" and there is a bit of culture difference i think. 3CX support is at currently to my knowledge based out of Cyprus "Europe". At times you will get guys on the phone who seem very quick to jump to conclusions that you are wrong and their way is the right way. With VOIP/3CX there are always multiple ways to do things when a customer needs a creative solution. I'm not at all saying the 3CX support guys are bad, they know their stuff and can be helpful. Just at times they are very intimidating when they jump right to you being wrong. Just be prepared for that.

Outside of support the product has been fairly rock solid. We have been selling/installing it for hmm 5 yrs i think with little issues overall.

5. Which version of 3CX?(windows or linux? and also which build version)
Our deployment base is 100% windows. (Always the newest build. Excluding Beta of course)
Reason we do windows is we are familiar with it. All my co-workers including myself have windows server backgrounds. So for us this was a big part of why we picked 3CX as our voice platform. We already know the server side no need to learn new CLI or such for a Linux.

Here is our Magic Mix. The standard configuration we start the conversation with for new customers.
3CX Professional (we never do standard)
SIP Trunking (We use NexVortex exclusively. They used to be supported by 3CX until recently. 3CX will hopefully bring them back)
*PRI (If SIP Trunking is not a option we go in with PRI. We try very hard to avoid analog installs. They are a headache.)
Yealink T46 (This is our "Standard" phone model we start the conversation at. 888voip is a good distributor if you don't have one)
Yealink CP860 (This is the entry level conference phone by Yealink. We have a lot of customers with conference rooms)
Snom PA1 (This is a paging adapter made by Snom. It allows you to connect into existing Paging amps. Good option for the price)
HP/HPE/Aruba. PoE Switches. (the Yealink/Snom equipment is PoE based. We only do installs with PoE. We don't use power blocks)

If you got any specific questions fee free to PM me.

 

[andrew_s]

That's exactly the type of feedback i was looking for, thank you Tucker.

If the correct setup is to always choose supported solutions, then what SIP trunking provider are you looking into now? Or are holding off to see if 3CX will support that SIP trunk again? I suppose my fear would be to choose something and then it goes off the supported list. I would then try to avoid that by picking one of the longest running supported providers by 3CX, do you know which provider has been long supported and most likely to stay supported?

I'll probably reach out to you directly with more detailed questions when I have time to start diving into 3CX further. Thank you for the offer!

 

[OCWI]

Hey Andrew!

Here is another perspective that works the best for us. We are a bit more volume based however. Our model is focused on gauge R and R, or rather how reproducible is each of our installs with the same results.

Questions:
1. Cloud or on Premise?

Cloud, OVH VPS SSD only. (im normally a google person too!)

2. Which gateways/trunks are best for either solution?

Telnyx- weve tried all them on the supported list.

3. What is the least problematic handset?

Yealink T46S

4. What pitfalls to avoid with 3CX?

-Using STUN. Dont do it.
- Using a windows border controller, horribly unreliable.
- Use Raspberry pi 3 only for a border controller and must ensure that wait on network is enabled.

5. Which version of 3CX?(windows or linux? and also which build version)

Both seem ok, but we only run linux unless we absolutely have to perform an on site PBX installation for analog line setup. We avoid at all costs, even if it significantly impacts our margins.

 

[neville]

We do exactly as OCWI. We have had great success following this model.

 

[andrew_s]

Great advice OCWI! Thank you! Looking into everything you suggested

 

[cobaltit]

I liked tsukraw's post and I wanted to say I strongly agree with #4. The other big complaint I've had is 3CX does what 3CX wants to do. For 100% channel product our feedback is largely ignored or not requested at all. We often find out about disruptive changes at the same time as the general public. They've made steps to improve in this area with the idea section and alpha/beta releases so things do seem to be changing.

 

[OCWI]

No prob, Neville and Andrew. The only weakness with that philosophy is if, in the rare case, something goes wrong we have no way of monitoring the actual trunk status. We can monitor the pi's and the PBX with some creativity - but not the trunk itself.

Any votes we can get on this particular thread to help bring the issue to the front for 3cx would be appreciated. It says in progress but has been for a few years now : (

https://www.3cx.com/community/threads/3cx-sbc-status-in-admin-gui-in-progress.42985/page-3

 

[neville]

No prob, Neville and Andrew. The only weakness with that philosophy is if, in the rare case, something goes wrong we have no way of monitoring the actual trunk status. We can monitor the pi's and the PBX with some creativity - but not the trunk itself.

Any votes we can get on this particular thread to help bring the issue to the front for 3cx would be appreciated. It says in progress but has been for a few years now : (

https://www.3cx.com/community/threads/3cx-sbc-status-in-admin-gui-in-progress.42985/page-3

I agree totally and I have already voted for this.

It is a big hole in the product line at this time and causes unnecessary heartache for the client and headache for us.

I have tested some lately with dropping the internet for our test network and the Raspberry PI has reconnected without input from us. Not sure if others are seeing this.