Rejected Prevent "multiple CTI devices" dialog being displayed by Windows client

[jonpennell]

It would be great if it was possible to "filter" the list of devices for the "Deskphone(CTI)" option. My client has two devices per extension. One is a Yealink T48, the other a DECT handset linked to a Gigaset N720 installation. The Gigaset supports basic CTI, the Yealink "fill" CTI/CSTA. It would be great if I could limit the Desktop(CTI) option so it did not offer the Gigaset as a target.

This kind of functionality would be especially useful where the same extension is logged-on to devices in different locations. It is annoying when the Desktop(CTI) connection on one LAN subnet offers a CTI device on another, for example.

 

[jonpennell]

Or perhaps the Windows 3cx client could evaluate which of the possible CTI devices is on the current subnet and filter out those that aren't - if that left only one, the client could connect to it without prompting.

 

[N_G]

Going forward you should use the web client and its CSTA integration. There will be no further development of CTI on the Windows client....

 

[jonpennell]

Does the Windows client not support CSTA then? Will it ever? Is the Windows client being deprecated in favour of the Webclient?

 

[nobody]

The Web Client is currently a waste of precious screen estate,
The Web Client is not compatible with windows, but only with special browsers.
The Web client has no single sign on with Windows
The Web client can be closed with a click of a button

A webclient might be cheaper for the developer but the user experience is equally worse on all platforms compared to a native client. A web client should only be used if there is no other option for the client, or, as a temporary workaround, of if the Application really fits good for a Webclient. A web client is not good for things running as a service.

 

[jonpennell]

I think I might have phrased that a little differently - but cannot help but agree with you on most of the points... which was the whole reason I asked Nick if there were plans to stop development of the Windows client.

 

[jonpennell]

And if the Windows client is not being deprecated - how about changing this feature request..? We have carefully tested several phones on the 3cx supported list and opted to purchase Yealink T46 and T48 models (which obviously DO support CSTA) but we are stuck with the legacy DECT N720 system (which doesn't support CSTA and only basic CTI). I DON'T want the Windows 3cx client to offer to use the legacy CTI devices - so how about an option that makes 3cx only list/connect-to CSTA devices in the CSTA_USER_AGENTS parameter?

[Edit] Actually I'll raise another "idea" since this one will probably be ignored now it's been rejected

 

[N_G]

The Window client will become similar to the Iphone or Android client and be mainly a softphone. So it makes no sense to control a phone from a softphone, so the windows client will not support CSTA.

 

[jonpennell]

Thanks for the clarification Nick - I would hate to see the Windows client go... although it does need a couple of cosmetic tweaks as other posts have suggested (including mine)

To be honest, I won't be sorry to see the CTI mode go... although I'm sure others will feel differently.

I've posted another ideas thread today, on my original topic but substitutuing "CSTA" for "CTI" - feel free to delete the thread... you've comprehensively addressed my concerns/problems. If a forthcoming Windows client drops CTI/CSTA mode then my issue goes away...

 

[N_G]

Hi Jon,

Well actually CTI will stay - its just we switched to using CSTA rather then unreliable http..... The web client will be the main client, and we will focus on making it much better but the windows softphone is here to stay and also will be improved and rewritten. We just wont duplicate features such as switchboard etc.

@nobody - The webclient is certainly not cheaper to develop. Its compatible with Chrome, Edge and firefox which hold 99% of the market. Chrome obviously 85% of that. Notifications are being improved and we are working on a single sign on solution which allows sign in via Microsoft or Google...

 

[nobody]

Good to hear that the windows client will be developed further. Look for a SSO solution to sign in to active directory, also users should be importable from ldap/ad. Just when I added a few new users yesterday or any time I change users accounts I think this would be a very good Idea/Admins will love this. MDM solutions from Blackberry or MobileIron also do this, you can add a local user or an ldap user. If ldap you you could even try to import the DID for the user. With the SSO no password has to be set and distributed.

 

[jonpennell]

@NickGalea - well, in many respects my problem still stands then - despite investing in supported handsets, users switching to Desktop(CTI) mode will continue to get prompted whether they want to use their Yealink (yes) or c***py Gigaset as the target (no) and worse, when the MD who has a Yealink at home on the same extension number is in the office, he can accidentally select the home Yealink as the CTI target..

 

[N_G]

No, i think you misunderstand CTI. CTI means computer telephony integration and uses CSTA going forward. If people want to use CTI, they must use the web client.... The CTI in the softphone will be removed. I hope that makes it clearer....

 

[jonpennell]

OK thanks Nick, that actually was my original understanding but then I changed my mind lol

One thing - the often requested BLF on monitoring extensions to show when an extension presence is DND. Until now, one of the only possible suggested solutions is to have the windows client open too so you can see if presence is indicating DND (since the BLF doesn't do so). This will be more problematic when the user cannot have the softphone client configured in CTI mode since at every load it will bitch if the desktop PC doesn't have a microphone. Currently to allow users to see if another extension is on a call we have the windows client open in CTI mode controlling their desktop phone. They don't use integration to originate or answer calls but if switched to softphone the client complains as the desktop machines don't have audio capability...

 

[jonpennell]

No, i think you misunderstand CTI. CTI means computer telephony integration and uses CSTA going forward. If people want to use CTI, they must use the web client.... The CTI in the softphone will be removed. I hope that makes it clearer....

I was just being lazy and referring to the legacy CTI behaviour vs the new CSTA behaviour