Separate names with a comma.
Discussion in '3CX News / Tech Articles / Product Releases' started by Bianca, Jun 1, 2018.
Continue reading the Original Blog Post.
Wow that's a lot of great new features packed into the update! Keep up the great work.
Just updated lab box to test, some nice additions (particularly the trunk report)
Quick query on the recordings area -
Does this mean that we can now provision a record toggle key on desk phones ? If so, is there guide or any additional info ?
Also, we have customers using the web client to pause recordings when required, they are on PRO
Will they need to upgrade to Enterprise to maintain that functionality ???
Hi Thanks for your comment. If you do not have rights, you will press the button and nothing will happen. If you have, recording will record the call normally.
No there will not be any provisioning guides to configure recording buttons differently. And it will not work with all phones. So at the moment it is beta.
Start and pause web client will remain working as is - So if you stay on pro, EVERYONE will be able to start and stop recording (the way you have been working until now). Nothing has changed.
If you move to Enterprise you can start talking like this to your staff members:
You, Alice can start and stop recording. By default none of your calls will be recorded because you are an executive. But you can start and stop whenever and whatever you like.
Bob, All your calls are being recorded. Plus you cannot start and stop recording.
John, You can start and stop recording and by default all external calls are being recorded because we are interested to record your external conversations. However since you are a manager, you have the right to start and stop recording of any call that involves you.
Regarding the change log item: Added FQDN to the subject when Services are stopped
Is this the FQDN of the server (3CXserver01.fakedomain.local) generating the email or the generic FQDN that would be shared by both the primary and backup servers? For instance, currently both our primary and backup use voice.fakedomain.com and the emails from both servers use that, leaving us no way of knowing which server is generating the email.
Very good question - Are you using failover?
No that change was for admins that manage like multiple pbx's or that manage pbx's for their customers.
An issue I've run into with the beta is that it was overwriting the 3cxmediaserver.ini file with the default at every reboot. I ended up wiping the server, starting with a fresh debian install and then NOT applying the beta. Now my ini files settings remain the same through a reboot.
I have not attempted to reproduce this since rolling back.
Yes. Failover alerts from both servers use the same FQDN of the 3CX install versus the server they reside on, so you have no idea which server is generating the alert. I can put in the idea forum, though I'm sure there aren't enough enterprise customers to generate the interest in this to nudge it up. Sorry, my pessimism of the ideas thread is showing a bit.
Yes, what were the settings in that file? You should not have custom things going on in there. Explain because this WILL happen again for you. Also there is no need to wipe the server clean.
Don't worry - no need to put this as an idea because it is already in the pipeline. Now I understand. We do have an issue here. Because the passive server should not be sending emails.
We are preparing an update to the failover module which will correct this. Like this you will get ONE EMAIL, from ONE ACTIVE SERVER. The other that is passive will not be sending mails at all.
We will make a way to be able to recreate the default file so you will not need to uninstall and recreate the machine. Point taken. Update 6 will have this. Basically the file in your case was locked.. and then it was not saved properly.
Thanks for the update. I figured there might have been a better way to resolve, i just ended up wiping because I couldn't figure a better way to roll back sp5 beta.
I see in the change log: "Added SBC provisioning for the Polycom VVX phones".
Does this mean there is now full SBC support for the VVX phones, or is is a VPN still needed at remote locations?
Yes - it means that when you plugin a polycom, you can select SBC, and this will provision the polycom phone to proxy to an sbc
We have tested the beta. There is a old problem with the snom phones! They need a Line-Button on BLF1 to get CTI working.
You should not be using CTI anymore. Better start upgrading and use CSTA because we are cutting this soon..
So CTI is going away in the app? Will the app only work for the softphone mode?
Yes, our plan is for the windows and mac clients to be come mainly softphones - similar to the iOS and Android app. CTI is not going away but will be using CSTA instead and be driven from the web client - which can then remote control softphones, ip phones. The web client will also have an inbuilt webRTC based softphone.
Will the native Client be updated to support CSTA? Or are there any posibilities to use the WebClient with Hotkeys?
CSTA instead of CTI