3CX V18: Connecting Teams & Customers - Faster, Better, More Efficiently

[bravad]

We only validate backups from the latest v16 version to be converted and restored to v18 and not any other intermittent version!

When I get answers like you did .. I feel like you are just making fun of me ..
In his moments, I allow myself to highlight the inconsistency of the answers obtained ...

Ho ! Ok ok.. so if I understood your logic correctly .. ​

3CX are blocking alphanumeric characters in a CallerID field because people are misusing it so could possibly transmit the wrong information…. without worrying that others know how to use it correctly ... in different contexts ...
BUT ..
for such a big limitation, the inability to restore a version prior to the latest version V16 .. the system does not can not read the version of the pbx from which the backup came for execute restore correctly?

Or .. worse ..

block the possibility of adding multiple emails in the email field of a 3CX extension ... but you do not block the possibility of restoring a backup from an "too old" version. ?! ..

I understand what you are using it for, however, most other users don't use it the same way and end up breaking their SIP Trunk when they enter a number with spaces, hyphens, etc, as these characters are translated to ASCII when put in the User Part of a SIP message.

Let's see. This is clearly a way of avoiding the need to offer support!
You are not following a stable logic! The answers are contradictory to the different decisions!

The update process from the version you are on to v18 consists only of 2 Updates in v16 and then the final upgrade button to v18 with the OS conversion. Max 30 min job this is per customer

You say 30 minutes… It is obvious that you are disconnected from reality… It is time for you to attend the interventions supported by your resellers to see real life!
Features removed or restrictions added. Lost configurations following updates .. Custom templates crm to rebuild .. The pressure that a customer can exert during a service interruption ... Problems encountered during updates! The process obviously takes more than 30 min…

Just count the number of complaints from users who have failed to update 3CX via the 3CX Dashboard request.
I can't do it from the command line .. to see the errors in real time .. well no, that is not supported by 3CX either!
When its crashes in your laboratory .. no pressure, just restore a snapshot .. but when it crashes at a customer .. that a physical manipulation must be done like inserting a USB key .. it is not possible to '' call the customer and tell him "Update Its crashing, I'm getting into my car, I'll be there in 30 minutes to start a resolution"

So .. if you think you will do 2 updates in less than 30 minutes…. is possible !
Frankly .. its been a long time since you intervened with end users ..
@StefanW .. You are CEO… You've seen it all at 3CX. Don't make me believe you really believe 3CX software can update 2x in less than 30mins each pbx with 100% success rate on 100 pbx volume?.. all this remotely, without a back-up plan in the event of loss of access to the machine where 3CX is installed during the update process.

Just to highlight the inconsistency even more ... you process updates via 3CX Instance Manager .. ?!
Yes, the tool developed by 3CX to help 3CX Partners in managing PBXs.
Yes, the same tool that it offers to perform the update remotely but does not offer a solution to perform a backup before doing the update .. .. as recommended by 3CX team !

Do not forget this .. After the first update ... I will have to make a new backup .. which for 4GB of backup will take on its own .. several minutes .. exporting it outside the environment .. will also take several minutes because obviously ... . if the update fails, I will not be able to use the backup made before the first update to restore on V18 because it is not supported ... you mention me!

So in the future .. if your answers look like this, I will refrain from posting on your forum .. because, clearly, you are not thinking of the reality of resellers or end users!

I responded with disappointment .. no anger, no arrogance, just pointing out different scenarios that demonstrate the inconsistency.​

​

 

[Gunter Menzel]

We are actually running into an unfortunate side effect of moving most of Webmeeting's logic away from the cloud to the actual PBX with v18. Back in v16, meeting links would point to the Webmeeting cloud on port 443, whereas v18 links point to the PBX's FQDN using that PBX's HTTPS port - which is 5001 for literally all of our installs. This is unfortunate, because many company firewalls block connections to port 5001 as a non-standard port, which results in external users being unable to join meetings until their IT department updates their firewall rules. V16 had no such issue (what with 443 being the widely-used HTTPS standard port).

Obviously, we can work around this by re-installing with port 443, but even as a relatively small partner managing some 40 installs the amount of work involved is staggering (think ordering additional public IPs for customers already running web servers, re-provisioning ALL apps, getting customers to change their port forwarding rules, updating web-client browser bookmarks, and probably a few more).

Is there a chance we can get some sort of cloud relay, so we can keep v16-style meeting links?

 

[NickD_3CX]

We are actually running into an unfortunate side effect of moving most of Webmeeting's logic away from the cloud to the actual PBX with v18. Back in v16, meeting links would point to the Webmeeting cloud on port 443, whereas v18 links point to the PBX's FQDN using that PBX's HTTPS port - which is 5001 for literally all of our installs. This is unfortunate, because many company firewalls block connections to port 5001 as a non-standard port, which results in external users being unable to join meetings until their IT department updates their firewall rules. V16 had no such issue (what with 443 being the widely-used HTTPS standard port).

Obviously, we can work around this by re-installing with port 443, but even as a relatively small partner managing some 40 installs the amount of work involved is staggering (think ordering additional public IPs for customers already running web servers, re-provisioning ALL apps, getting customers to change their port forwarding rules, updating web-client browser bookmarks, and probably a few more).

Is there a chance we can get some sort of cloud relay, so we can keep v16-style meeting links?

In order for External Participants to be able to join WebMeetings your users create, indeed, you will need to allow access to the HTTPS Port. There is no need to change the port as I agree, that would be an immense amount of work re-configuring everything, but I am sure that every Firewall device worth its money will allow you to open 5001 TCP and forward it to your 3CX.

I should also mention though that if you have any remote workers of any sort, your HTTPS port should already be open, as this is the port that, IP Phones use for provisioning, 3CX Mobile Apps to get presence, gain access to the WebClient.

There are no immediate plans as far as I am aware to add any kind of 'proxy', or give the option to have the WebMeeting behave like it did in V16 (not needing access to your HTTPS port to join).

 

[Gunter Menzel]

In order for External Participants to be able to join WebMeetings your users create, indeed, you will need to allow access to the HTTPS Port. There is no need to change the port as I agree, that would be an immense amount of work re-configuring everything, but I am sure that every Firewall device worth its money will allow you to open 5001 TCP and forward it to your 3CX.

I should also mention though that if you have any remote workers of any sort, your HTTPS port should already be open, as this is the port that, IP Phones use for provisioning, 3CX Mobile Apps to get presence, gain access to the WebClient.

There are no immediate plans as far as I am aware to add any kind of 'proxy', or give the option to have the WebMeeting behave like it did in V16 (not needing access to your HTTPS port to join).

Hi Nick, thanks for your reply.

As you have correctly assumed, our customers' firewalls are properly set up to allow inbound connections on port 5001. It is the firewalls of business partners and webinar participants (which we have no control over) that tend to block outbound connections towards port 5001 because it is an uncommon port. Technically, it is their 'fault', but it is our customers who have to point them towards their IT departments to get their outbound rules sorted, when it was not necessary before. I also recall a fair few hotel WiFi networks that restrict outbound traffic to common ports.

We have only updated a few installs and almost immediately received feedback of external users having trouble joining meetings. Maybe this situation is unique to our region, but in my experience, most larger companies tend to have restrictive enough firewall configurations to cause issues when joining our customers' webmeetings. Perhaps - given enough feedback from other partners - you will consider adding a Webmeeting proxy for compatibility. We would certainly appreciate it.

 

[bravad]

As you have correctly assumed, our customers' firewalls are properly set up to allow inbound connections on port 5001. It is the firewalls of business partners and webinar participants (which we have no control over) that tend to block outbound connections towards port 5001 because it is an uncommon port. Technically, it is their 'fault', but it is our customers who have to point them towards their IT departments to get their outbound rules sorted, when it was not necessary before. I also recall a fair few hotel WiFi networks that restrict outbound traffic to common ports.

We have only updated a few installs and almost immediately received feedback of external users having trouble joining meetings. Maybe this situation is unique to our region, but in my experience, most larger companies tend to have restrictive enough firewall configurations to cause issues when joining our customers' webmeetings. Perhaps - given enough feedback from other partners - you will consider adding a Webmeeting proxy for compatibility. We would certainly appreciate it.

Do you know what is the worst part of all this?
This is not very complex to do for a developer, allow "checking a box" to allow connection to the port 443 for webmeeting (ok yes, would still require open port 443 in your customers … which is not the case for V16 .. but would allow their customers to access the Webmeeting..)

It's also easy to add an entry in the nignx configuration file.
I myself tested it in the « pbx test ». Obviously, 3CX will immediately cry out loud "Your 3CX system's support is invalidated due to unsupported changes", which is why I am not writing the solution.

Once again, the developpers of 3CX… are not connected to the reality of « 3CX Partners ». They're working on theories but since they can't support end users after deployments ... they don't know all the problems they cause for theoretically minor changes to them!

Note that each comment reported to 3CX .. is immediately followed by a comment justifying a decision ... Instead of adapting, it is obvious that 3CX will insist that it is not their fault and that this is not a bug .. so not going to attend… anything .. Thinking only of the organizer side .. but not of the popular restrictions on the participants side ...

 

[Evolute IT]

Do you know what is the worst part of all this?
This is not very complex to do for a developer, allow "checking a box" to allow connection to the port 443 for webmeeting (ok yes, would still require open port 443 in your customers … which is not the case for V16 .. but would allow their customers to access the Webmeeting..)

It's also easy to add an entry in the nignx configuration file.
I myself tested it in the « pbx test ». Obviously, 3CX will immediately cry out loud "Your 3CX system's support is invalidated due to unsupported changes", which is why I am not writing the solution.

Once again, the developpers of 3CX… are not connected to the reality of « 3CX Partners ». They're working on theories but since they can't support end users after deployments ... they don't know all the problems they cause for theoretically minor changes to them!

Note that each comment reported to 3CX .. is immediately followed by a comment justifying a decision ... Instead of adapting, it is obvious that 3CX will insist that it is not their fault and that this is not a bug .. so not going to attend… anything .. Thinking only of the organizer side .. but not of the popular restrictions on the participants side ...

You know, there are many PBXes out there. Feel free to use another one if 3CX is that much of a problem for you.

 

[StefanW]

I agree that you can manage the availability on your own instance to make it accessible but you of course have no control over the client-side connecting to your instance. I recommend placing 3CX on the 443 port to mitigate this, given the customer has the port available on the public IP or an additional unused IP. Alternative, 3CX could be relocated into the cloud if local availability is not feasible.

We considered this part long and hard, in the end, the benefits of the v16 platform vs. the v18 platform in terms of privacy and reliability won this discussion. In v18 all personalised data is kept just in your own installation which for me is a paramount feature. In addition to the upcoming own MCU feature, there would be also no other way to fully accomplish this without the involvement of any 3CX could service...

The same also applies to remote staff consuming other services of your 3CX System (WebApp, Mobile Apps, etc) from remote locations, therefore the port consideration should be seen/planned for the whole 3CX deployment.

 

[StefanW]

When I get answers like you did .. I feel like you are just making fun of me ..

Trust me, this is 100% not true and is also not in my interest nor my general personality. Be assured that I only state what we do and what we don't do or will do. I do not undermine your posts/concerns, you are free to express them as I feel that I have to right to answer to them truthfully, out of my personal beliefs or the 3CX vision. Certainly, we will not agree to everything and need to find a solution/mitigation for such cases if possible.

If you see that v16 as 8 service packs (9 versions) and assuming v18 will have the same, on 2 operation systems and 7 core OS languages we check installation/restore and upgrade for, 3400 combinations is just for us not manageable and therefore limited to the latest version of the predecessor.

In terms of upgrading, I can speak only for the time it tasks to upgrade 3CX own core product(s) and not 3rd party developments in CRMs, CFDs or CC-API integration. Via the cloud service we offer, I have a quite good estimation of how much time and work it takes us to manage X amount of instances. The input regarding the backup to be taken before upgrade from the instance manager I noted down as I do agree to this functionality should be added.

 

[Jeff Koertzen]

It's not as long as it seems, remember that there was a much deserved 2-week holiday during August for our Dev Team, so that's why the delay seems bigger.
It will come when it's ready though.

Looking forward to the Windows Server/Windows 10 v18 release! Pretty jealous of everyone who has been able to upgrade already.

 

[Net4IT]

Hi support,

When can we expect the Windows release.
Have many customers asking me about this update.

Thanks.

 

[NickD_3CX]

Hi support,

When can we expect the Windows release.
Have many customers asking me about this update.

Thanks.

https://www.3cx.com/community/threads/where-is-the-windows-v18-pbx-installer.84084/post-392955

 

[inknow]

When can we expect Windows V18 release?

In this topic there was a mention of 3CX that official release would contain Windows installer as well:
https://www.3cx.com/community/threads/3cx-v18-alpha-4-windows-download.81897/

Any news about this? other than keep looking at the blog and maybe someday it will be released

 

[NickD_3CX]

@ITSD @inknow
Hopefully this will answer all your questions:
https://www.3cx.com/community/threads/v18-update-1-beta-fine-tuning-teams-integration.84237/

 

[N_G]

Windows build was released as a beta together with update 1 beta. Try it out, link in the blog post
https://www.3cx.com/blog/releases/v18-update1-beta/

 

[jaywagener]

@Nick Galea @StefanW I upgraded the V18 lab box we have been testing with and the issue with the manual reject/decline of the call in Teams is solved! Thanks for fixing that so quickly. We are looking forward to putting this into production ASAP.

Next up is testing the Windows V18 build. Any ETA on an upgrade Beta for this on an existing V16? I only see a full installer of this version and no option for installing the Beta version in the Updates section in the 3CX admin portal. We have an Azure lab Windows V16 that we would like to use for this. Otherwise we need to build another server with another license for testing this. Not a big deal, but the update would be easier.

 

[Evolute IT]

@Nick Galea @StefanW I upgraded the V18 lab box we have been testing with and the issue with the manual reject/decline of the call in Teams is solved! Thanks for fixing that so quickly. We are looking forward to putting this into production ASAP.

Next up is testing the Windows V18 build. Any ETA on an upgrade Beta for this on an existing V16? I only see a full installer of this version and no option for installing the Beta version in the Updates section in the 3CX admin portal. We have an Azure lab Windows V16 that we would like to use for this. Otherwise we need to build another server with another license for testing this. Not a big deal, but the update would be easier.

For Windows, you have to uninstall/reinstall unfortunately.