3CX v17 (Not a typo)

[DrainBamaged]

Now that v16 is out of the gate, I'd like to encourage the engineers to focus on the Enterprise with v17.

I have five 3CX production installs (soon to be six and maybe even seven later this year). I need to control and direct those telephony installs via independent web interfaces. My licenses are all on separate accounts, I have no way to group them together in one browser tab to unify maintenance renewals on the same date.

I can't even differentiate between the various 3CX sites in my browser, they're all labelled "3CX Phone System Management" . I can't run usage reports across all sites (unless I run them individually then manually piece them together). Nor can I organize inter-site conferences within my own company without work-arounds like this: https://www.3cx.com/community/threa...rence-calls-with-multiple-3cx-installs.59726/

I cannot use Exchange in a DAG configuration with 3CX (which is what 99% of corporations use) which is a huge inconvenience for us as we have to run a single mail server just to support 3CX voicemails.

3CX is amazing for a small or medium sized company, but when you get up into Enterprise software, the shortcomings are glaring. I encourage you to focus on unification so an Enterprise license means just that.

Thank you.

 

[cobaltit]

Not necessarily arguing with you but most of your issues seem to be the fact that you are running multiple instances of 3CX. Not being all that familiar with Avaya/Mitel/Cisco solutions are you saying those options let you run physically separate sites yet somehow manage them in a SPOG or unify the reporting? I don't feel like that was the case, at least with phyiscally separate on-prem stuff. Maybe with some add-on's or centralized reporting instance but I would imagine you can accomplish the same with a single central 3CX instance.

Otherwise there are ways to accomplish most of what you want to do today:

• For the licensing, you should be able to work 3CX sales directly or via a partner to consolidate the licenses under one email.
• Don't think they can consolidate renewal dates but if it's that important, you can always buy new licenses
• Use one of the supported browsers you don't don't use for everyday tasks and just make them your home pages. Tabs will be in the same place everytime. Can also use addons to color the tabs or give them fixed names.
• Your best bet for usage reports is going to be CDR exports to a central location and then massaging the data there. @voiptoys can probably help with that.
• The conference call issue again is something I don't think the aforementioned leaders of on-prem stuff did. A single 3CX instance would solve this as well or the workaround you posted which isn't that big of a deal to configure. Or just some training that 3CX is used for site-based conferencing and then use whatever 3rd party conference you used to use before 3CX. This one doesn't seem like an easy fix compared to the some of the others but maybe they can leverage something with the Instance Manager an bridging conferences in each local site. Not sure what kind of multi-site/enterprise revenue 3CX is drawing to make this happen though.
• Re Exchange DAG problems, are you talking about using Exchange UM for voicemail?

 

[DrainBamaged]

Will address a few of your main points. A single instance would be impractical given the global locations of our offices.

One other thing I didn't mention was logging and admin access. Changes are not logged in any great detail. So if someone on my team deleted fifty extensions, I could not tell you who did it or when without a lot of forensic digging.

"For the licensing, you should be able to work 3CX sales directly or via a partner to consolidate the licenses under one email."
We deal with many software companies where this is handled natively. Multi-site installs with central management and reporting on a single web page. The point isn't that I can work behind the scenes for many days coordinating to this goal, it's the fact I shouldn't have to on an Enterprise licensed product.

"Your best bet for usage reports is going to be CDR exports to a central location and then massaging the data there. @voiptoys can probably help with that."
Voiptoys isn't free. Not bashing them, but why should I pay an additional monthly subscription fee for functionality I should be getting directly from 3CX? The add-on companies exist because 3CX does not contain the features people want/need. Even a simple report on call volume by site can take multiple hours to assemble.

"Exchange DAG problems, are you talking about using Exchange UM for voicemail? "
3CX does not support (nor does it work) with Exchange in DAG. A rather disappointing discovery after trying for six weeks to get UM working and engaging support.

Quote from our support ticket:
The scenario described with Two Exchange Servers set up as DAG is not in the manual and is not supported by 3CX.
BOTH servers in the DAG won't work as you wish. You need to use only one (1) Exchange server and not like your scenario.
In the Manual it makes reference to just one Exchange server and not multiple servers set up as DAG,
that is why works for you in one server and not the other and vice versa.

My comments are not spiteful. I'm simply trying to make a great product even better.

 

[BrenttG]

We actually have cloud hosted instances of 3CX, with apps and desk phones being used in diverged continents, UK, US, And elsewhere, all you need is a good datacenter that has strong peering with the various providers that cross the oceans, etc.... Your reasoning given thus far for having separate PBX's, is not needed, or perhaps you didn't realize it was that simple....

EDIT: BTW in our cloud environment, we are running thousands of phones...

 

[Jorge Alfonso]

@BrenttG This may be off-topic, but i'm Curious how you deploy/provision all these phones from the cloud? I've had a lot of issues with provisioning phones from systems hosted in the cloud without having to use an SBC on premise. We have site to site vpns the provision request via dhcp don't seem to work well using yealink phones.

 

[BrenttG]

We have pretty much zero issues, we almost never use SBCs, and we have option 66 provisioning working at 99% of our sites, the few that dont is because we dont have access to the DHCP server, not a technical issue.

First your firewall rules on the cloud side have to be spot on, second, you need to setup option 66 on the DHCP server that is local to the yealink phones, and make sure the firewall on the client side is also configured properly. Sometimes we have seen web filters interfere with config downloading to the phones, or TLS inspection, you may need to create exceptions for the phones to get past these things.

You also need to make sure that the phones are configured for Direct Stun, so that they are using the FQDN, and make sure that per client site, there are no port overlaps on the SIP and RTP ports, for every remote site, you can re-use the ports, this is how we lay them out on the remote provisioning. just make sure that no 2 phones that are at the same site, have the same SIP and RTP ports or strange issues will arise.

We use IPSEC VPNs for a couple sites that have problematic firewalls, but 95% are direct stun, also make sure that PBX delivers audio is turned on for all the remote extensions, it makes a major difference with little issues relating to the firewalls.

 

[jvivona]

just to jump in - we do a lot of drop-shipping of phones to our clients. with fanvil or yealink, when we buy the phones from a wholesaler - we get the mac addresses in advance. we load them in & they are sent to the fanvil / yealink RPS servers. the office mgr (or someone responsible like that) dole out the phones - when they get plugged in - the user knows to put in their extension & VM PIN to auto-configure the phone. The next weekend we do any firmware upgrades if needed.


as for the OP issue - as a reseller myself, when you buy licenses - as of the new portal from 3CX if you use(d) the same email address for all the licenses, they are consolidated into 1 single user portal for renewals. There are a number of other missing "enterprise" features, some have been coming down the pipeline (webconference + audio bridge has been a "saver" for some clients looking to leave) - as a partner, the instance manager is proving to be a great piece for us and some of our multi-site, multi-bridge customers. BUT - rule #1 - Get your reseller to help you out - won't take you but 1 email to the right person - not weeks / days. If you are that big of a customer with 3CX - you probably have the ear of your local sales person & if not - give me a call & I'll personally help! The reseller should be doing something for that $$$$ they make...

Back to enterprise - It's been an uphill battle - I can see some of the things with DAGs and central reporting being issues in really big, diverse environments - the question for 3cx becomes - how many of those are there in the current base (and the prospect base) and is there enough revenue to justify development resources to it. From our side, there's major - across the base - challenges that need to be solved / developed to help the entire user base instead of maybe 5-10% (that's a guess, I have no facts to back up that number) - but that's my 2 cents.

** Also - even with direct stun, we don't modify the default SIP / RTP ports of the phones - if your firewall does NAT stuff correctly - you shouldn't need to *** But YMMV

 

[BrenttG]

just to jump in - we do a lot of drop-shipping of phones to our clients. with fanvil or yealink, when we buy the phones from a wholesaler - we get the mac addresses in advance. we load them in & they are sent to the fanvil / yealink RPS servers. the office mgr (or someone responsible like that) dole out the phones - when they get plugged in - the user knows to put in their extension & VM PIN to auto-configure the phone. The next weekend we do any firmware upgrades if needed.

We try to always have option 66 deployed ahead of time, then there isnt even a need for the user to do anything other than plug in the phone, granted we only sell yealink, but we deal with used polycoms regularly also. We also get our MACs early for large projects/orders, but for the mid/small we have them in stock in our warehouse already, so we just scan them into excel ourselves.

** Also - even with direct stun, we don't modify the default SIP / RTP ports of the phones - if your firewall does NAT stuff correctly - you shouldn't need to *** But YMMV

This will work sort of for the first 8-10 phones, we have seen, but over that number, you will start getting port overlap, and audio issues, signalling issues, etc.... This should not be relied upon.... Its not about having proper NAT, its about the SIP protocol itself needing to be able to tell between multiple phones all appearing behind the same external IP. it will be less prevalent on phones that do dynamic source port mapping, but many do not, and it is the exception, not the rule. Remember the need to remap ports arrises due to multiple remote phones, at the same place. And if there is IPSEC, or if the pbx is local, or an SBC is present, it negates the need to change the ports....

 

[jvivona]

This will work sort of for the first 8-10 phones, we have seen, but over that number, you will start getting port overlap, and audio issues, signalling issues, etc.... This should not be relied upon.... Its not about having proper NAT, its about the SIP protocol itself needing to be able to tell between multiple phones all appearing behind the same external IP. it will be less prevalent on phones that do dynamic source port mapping, but many do not, and it is the exception, not the rule.

Interesting.. we see something different - so I'm always interested. I know all the training tells me otherwise, but we tried it with a 75 phone install and have just not seen those issues. Maybe they aren't telling me.. I'll do some more probing of customers... I KNOW you are right on the tech side - it just we've not seen it. maybe I need to get one of those big-whooper installs with a few hundred phones & cloud server (ALL of our 100+ phone installs have on-prem because they have local IT resources)

I'll let you know as I know more.. Thanks for the advice.

** and - with a lot of the clients, we're not the overall IT firm for them - just their phone guys.. The moment they start talking with the MSP or IT provider - all of a sudden we have phone issues, if we try to deal with the DHCP 66 thing. I do agree with the used Cisco, have a couple that have them & DHCP 66 is obviosuly the only answer there **

 

[BrenttG]

if the PBX is local to the phones, the port mapping on each extension is not needed. its only if the PBX and the phones have 1 or more levels of NAT between them.

 

[jvivona]

@BrenttG - I'm with you there. We're only talking about cloud with NAT at the firewall. Local LAN/VPN - all the rules don't apply.