Sweet Sixteen… 3CX v16 ALPHA

[Tom | Voips.nl]

The Windows client will not have the switchboard anymore.
Instead all switchboard logic will move to the webclient.
It will be web based, one less app to handle and have all your communications through the browser.
The Webclient will have Queue views which will give an overview of All queues in the system or those you are currently managing.
This feature will be provided over the next 2 updates.

We don't like this change. We got more than 600+ active users of the switchboard. If it moves to the webclient which our clients don't use, than that is a problem. Then we need to explain all the 600+ users how the webclient works.

 

[timmbo]

Hi.

I would need the ability to set the outgoing Number for Calls which are coming from Bridges.
Here what im going to use:

PBX-A has an VoIP-Account with DDI (0720501078...) the Extensions are from 10 to 60, but i can use 0-999 on the VoIP-Account.
PBX-B is Bridged with with PBX-A, and in the outgoing Rules are set, if is called 0043....., go over the Bridge to PBX-A and Call over the VoIP-Provider with your Extension(249), so PBX-A should set the Number 0720501078+ the Extension, so it looks like this 0720501078249, so everybody who not pickup the Call, can call back on 0720501078249 and PBX-A has a rule for 249 to go over the Bridge to PBX-B to extension 249.

Can i use something like this in the near Feature in V16?

In the SIP-Packet right now is see only the Extenion 249 on the FROM-Header, to go to the Provider, and he reject the Call because 249 is not the right number on this Account.

Update:
I found a Solution.
Outgoing Parameter is for my own number, not for this which is Called, so i set
(249) and 0720501078\1

Bye
Timm

 

[dandenson]

IMO you should almost never remove and replace a feature in the same release. If the windows client is loosing the switchboard and it’s moving to the web interface.... switchboard should be depreciated in v16 but still there. Give users time to switch over.

It’s not great to be stuck a version behind because of a change that happened without depreciation.

 

[jem1]

IMO you should almost never remove and replace a feature in the same release. If the windows client is loosing the switchboard and it’s moving to the web interface.... switchboard should be depreciated in v16 but still there. Give users time to switch over.

It’s not great to be stuck a version behind because of a change that happened without depreciation.

Actually I recall a comment being made around the time of the web client release that they were going to basically make the desktop client soft phone (which is now in the web client), with the release of that it was only a matter of time before the desktop client would loose features and not get new ones.

The switchboard has been in the webclient I think since it's first release, it's nothing new for V16. I've been training new customers on the web client as i knew the desktop client was going bye bye eventually and been trying to get existing ones to use it over the desktop client.

 

[saint_]

OK the voiceapps as we had them before have been removed. But do not worry.
We have a solution that will make the design of voicescripts much easier giving admins full flexibility of the callflow.

3 new IVR types have been introduced in Version 16.
DTMF input, Launch Script and play file (The latter is something that many users will find helpful because they can clean up the IVR list to have fewer to maintain/troubleshoot)
Documentation will be released shortly especially on the launch script ivr.

The amount of flexibility and things you can do if you create IVR's that launch python scripts for example or Powershell ones, is really cool.
You can craft a script that can do anything - return specific error codes, enter DTMF or ID's, check them by querying a rest api crm or a database, Play prompts, without having to go through the CFD learning curve.

We will be releasing some some sample scripts soon.

Nick
Any ETA on the new documentation for the new scripting feature ? We are a new with 3CX and are slowly switching our old customer base to 3CX, but before we do that, we need a proof of concept for each customer who has IVR in order to show that 3CX can replace the enterprise grade PBXs.

We are testing in a lab and while updating our lab to 16 we lost it all (voice apps). Our projects are on hold until we can move on. We only use Linux based 3CX.

Thanks a ton !

 

[N_G]

Hi All - Thank you again for your feedback. Here are some brief answers:

@saint - we will be making a post about the CFD and scripts in the new year. Most probably you will find that the CFD will indeed remain and will simply output scripts that can be linked to an inbound rule so that you can process calls as they come in - making it infinitely more powerful. Please await a blog post about that early january and then we can look at your scripts and explain how they will fit in. We might even make a converter anyway

@pmterp - granular permissions is on our radar but please use the ideas forum to vote for the appropriate topic

@switchboardfanbase - the windows switchboard does currently not work in windows because we have updated the queue module and so the switchboard needs to be updated. We will see if it is feasible to be updated. But the future is the web client - this is where all development will take place. That said there will always be a windows softphone available.

 

[Paul Reynolds]

We've had a play with the 365 sync and whilst it's a great start and great functionality to have, it does need some features that aren't there yet. It might have been mentioned but there doesn't seem to be any way to control which extensions a user gets when they're automatically created. At the very least we'd need to be able to specify where the range starts (e.g. 201 not 001) but even more control would be welcome (e.g. reception/management often get lower numbers). It wouldn't be so bad but because the extension number is locked as soon as it's created there's no way to tidy up after. A field at the import screen saying which extension number to use would be welcome. And adding new numbers after that should pick the next available number after the highest existing. Maybe bring the users in a "pre added" state/screen and then assign extensions, similar to how adding a new phone is assigned to an extension after it's recognised.

Thanks

 

[VoIPTools]

We literally have close to a hundred CFD applications to convert so any information about how this will work is greatly appreciated. A converter would be a GODSEND. The majority of our CFD code is in external code (distributed DLLs).

We need to get started converting CFD applications URGENTLY if we are going to have any hope of being ready for V16 when it is released. We currently distribute our CFD applications as a compiled DLL. Is there going to be support for distributing a compiled solution? We simply cannot release our solutions (code) in plain text.

It sounds like this is going to be implemented using scripting languages. What languages will be supported? Can we do it in C# rather than a scripting language?

 

[N_G]

@Paul Reynolds - good point and we will look into this.

@voiptoys - the CFD will output plain C# code which can then be edited by developers if they want to. It will make customizing 3CX infinitely easier. We will no longer compile a DLL but you can link to a DLL i guess from your code if you want. As mentioned you will have to wait until further information is published early january.