Hosted by 3CX: Your FAQs Answered!

[vanguard08]

These would be valid points if the provided smartphone apps and push notifications didn't shit the bed at the slightest breeze

I'm sure someone would be willing to assist you if you are having trouble with them. I've found them quite pleasant. I ran into the update issue when iOS pushed an update because of their security policy change but that wasn't the fault of 3CX. Other than that, I've had great success with them.

 

[N_G]

@cobaltit - Only register based trunks are supported. WIthout them its not easy to move instances quickly which may be required for redundancy.
@sofnisys @ccs1 You earn by selling 3cx, configuring it, additional hardware?
@Kym Busby - Thats just completely unfounded comment. Push infrastructure is run by Google and Apple and its working absolutely perfectly.

You can still deploy deskphones, no problem. Even in the home, even without SBC. Its just that support will be charged if you have an issue because it will be 100% an issue with firmware, firewall configuration or something like that. And this type of support is not included in the hosting. And your customer will not pay for it, nor will we. So apps are simply the way to go. But if a customer wants it, fine, but support will have to be paid for.

I myself had two deskphones in my house for a long time until i realised its just completely ridiculous and old fashioned. Plus i was the laughing stock of my kids and younger friends I now use my android phone solely, even when in the office and quite frankly its so much better to use one device and have all your calls and activity in one place.

In regards to privacy.... Are these the same people that have Zoom, Google Maps, TikTok, Facebook, Instagram installed? I would say an app gaurantuees higher privacy and security, simply because both Android and iOS will monitor what gets sent back and it has to be advertised upon installation. Of course calls can be recorded on 3CX but that is something the users know or should know and its the same on a deskphone.

 

[cobaltit]

@cobaltit - Only register based trunks are supported. WIthout them its not easy to move instances quickly which may be required for redundancy.
[

Understood. Update 8 should resolve this use case but until then I think we are ok. We have the ability to point our IP authenticated trunks the 3CX FQDN so if the instance moves and DNS is updated, then the trunk should follow.

Thanks for the pointing out the now-obvious reasoning behind supporting registration-based trunks

 

[Phill.]

CFD for us is only ever used for time based routing. As this feature is limited to different hours on a trunk or inbound route, 'after hours' to route differently, OR choose a holiday, which then you have no option but to provide a prompt and it just hangs up is incredibly basic.

The alternative is having to first pay for the appropriate 3CX license, download/install CFD, create CFD, upload CFD, test CFD, then later remove CFD (optional, depending on logic) is the only option for times of the year when there are holidays and other times where we need to have calls flowing differently.

This is the biggest gap in functionality for our clients to be honest.

I just want something easy to just tee up dates and times and have routes flow as designed. Some cloud phone systems do this really well, and others just get too advanced and complicated...
I'd love to see this area get a bit of work done to make it simple and easy.

 

[N_G]

@Phill - this is very good feedback thank you. Can you give us some more examples or a screenshot what exactly you want? You can DM me if you prefer

 

[amenee]

Clarification about Debian Support?

My employer is offering 3CX solutions to its clients.

They are using 3CX on Debian and I'm aware that there are two options available - either use the 3CX own Debian ISO or use the vanilla Debian Stretch iso then add the 3CX repos to it.

Personally I'd like to use Debian 9 Stretch vanilla & then add the 3CX repos to it - I've tested this scenario and it works well.

Is this a supported setup that I can use for my employer's clients or not?

Thanks,
Regards,
AM.

 

[Phill.]

Sure no worries.

An example of what I would appreciate is for an additional functionality of the inbound rules. As you want the time conditions to match certain logic, but have the ability to fall back to regular business hours and after hours when logic isn't met.

These would need to be designed to allow for custom time conditions. Kind of how holidays work, but you can actually specify what happens on the holiday, not just a voice message > end call.

The particular time condition item could be set to perform time based logic. So you can set ranges for months, days of month, days of week and hours of the day, so then you can have a route if it matches these conditions, and a route if it doesn't match these conditions.

Within each of these time based logic items, you could also create OR statements to include additional time condition parameters, as practically speaking, you want to make it simpler to apply the time logic all within the one time condition item, rather than have a chain of several conditions. So just like your holiday feature, except there are OR statements.

So I guess this seems like an improved holiday feature, although its more like a custom time condition, as its not a holiday we are achieving, its specified routing based on time conditions. The voice prompt feature (like on the holidays) wouldn't be required (or just optional?), as you want to first perform the time based logic, then route to your specified IVR, Queue etc.

I know some people reading this will have 'alternatives' - this is not what I'm discussing, but thanks for the consideration.

Happy to provide further details

 

[N_G]

@Phill Thanks for the feedback. OK but this sounds quite complex and this is why we have the CFD. I dont see what business condition would require every company out there to need this, could you elaborate on this.

You can already set specific inbound rules for numbers with specific times and actions, its not just voice mail.

 

[Phill.]

@Nick Galea yes you can override the inbound rules with specific office hours, but that's only specifying days of the week.

I just find this really useful for holiday routing in advance, so you can essentially setup a different voice prompt and route based on the time condition for holiday periods, then remove whenever after the time/date period.

For instance, we have a client that uses a different cloud system and often changes holiday routing for school breaks. I can set a time condition so if it triggers on the inbound call, it plays the holiday prompt, then route the call based on the condition. When the time condition isn't met, school resumes, the call flow returns to normal and we can remove the time condition when we are ready.


I guess I'm biased to not use CFD as all I need it for is time condition logic..

If there was an option to choose a call route via the holiday settings, that would at least be a feature that I could find most handy at the least. I'm sure others would as well.

 

[N_G]

@amenee - no you need to use the 3CX Debian ISO to get tech support.
@Phill - the options that you are describing are for the CFD, so if the customer wants that then private cloud is the way to go which in all fairness works absolutely fine.....

 

[FridayIT]

@amenee 100% use the 3cx debian ISO, no reason to overcomplicate anything. this way you know your bases are covered, plus, we have seen issues caused by trying to use the debian autoupdate mechanism. And this way when 3cx does push the next debian or 3cx update, you can ensure there won't be any gremlins with the process .

@Phill 100% I'm with Nick, I recommend the CFD, while it's not as easy, this is the correct way to do this. We use the CFD on our end for anything incoming rules or extensions that require "logic"

 

[N_G]

The reason we block CFD on hosted systems by the way is for security reasons as it would be possible to upload files to the 3CX host and we are not in a position to guarantuee the security after this, that is why these have to be private cloud for now. As you may well appreciate we get thousands of trials and commercial users using these systems every week and of course there are those with less then good intentions

 

[amenee]

@nick-galea.2 given you only support 3CX Debian, technically speaking, what's the difference between vanilla Debian & 3CX Debian?
Also, is there any chance to convert a vanilla Debian into 3CX Debian?

 

[N_G]

There is almost no difference. The problem is that with the vanilla Debian often customers will make configuration changes install different packages or different versions of software that 3CX uses that will create issues. As such 3CX Debian is stock debian. Hosters in turn often have customized versions of Debian which can behave differently. This is why we limit the hosters we support (we test our product on the Google, Amazon, Azure Debian for example) and our own Debian.

 

[amenee]

Can customers install different packages or different versions of software that 3CX uses on 3CX Debian?

 

[Evolute IT]

Can customers install different packages or different versions of software that 3CX uses on 3CX Debian?

No, it won't be supported if it breaks. They build and test with specific versions.

 

[amenee]

Hi Frederick and thank you for your answer - what you're saying sounds to me more like "No but Yes, you can install different packages or different versions of software that 3CX uses on 3CX Debian, but if you do so, your install will be unsupported".

To clear this confusion, I'd like to summarise below the way I understand it and please anyone correct me if I'm wrong:

1. If you use 3CX Debian and install only 3cxpbx.-> Supported.
2. If you use 3CX Debian and you install 3cxpbx and other software. -> Unsupported.
3. If you use Debian Stretch and install only 3cxpbx. -> Unsupported.
4. If you use Debian Stretch and you install 3cxpbx and other software. -> Unsupported.

Given 1 & 3 seem to be (apparently) the same thing, why would scenario No.3 be Unsupported?

 

[amenee]

I think I get it now - No. 3 can't be used b/c 3CX Staff builds and test with specific versions

 

[N_G]

I think Fredericks answer was quite clear, but as additional clarification:

1 and 3 are not the same thing at all. In option 3 Debian will install updates overnight of components that we use for example a database server that will not have been tested with the 3CX server running on that machine. These are not security updates but general updates.

So if you want to use 3CX, its option 1 and option 1 only.