Plantronics headsets over RDP with RemoteFX - 3CX app resetting to Primary Sound Driver

[dalep]

We are testing redirecting our Plantronics headsets over RDP with RemoteFX.
We can successfully enable headset call control (answer/end calls with button on headset) by installing Plantronics Hub and the 3CX Windows Soft Phone on our terminal server – call control only works when the Plantronics audio device is selected in the audio options in the 3CX windows client settings…
Our problem is that every time we disconnect from the terminal server and reconnect, the audio devices are reset back to Primary Sound Driver…….. which stops headset call control working….
It appears from analysing the XML config file under \AppData\Roaming\3CXPhone for Windows folder that the Plantronics GUID is changing every time I reconnect to the terminal server session – I assume this is why it keeps resetting back to the primary sound driver.
Is there any workarounds or fixes for this issue???
I'm guessing the easiest way for 3CX devs to fix this would be to enable headset call control without having to have the Plantronics audio devices selected, as I don't see how this would "enable" call control in the first place.

 

[JohnS_3CX]

Hi @dalep

I'm not sure there is a solution to your issue. When you disconnect the audio device RemoteFX creates is probably being removed and the client is forced to return to "Primary Audio Device"

>I'm guessing the easiest way for 3CX devs to fix this would be to enable headset call control without >having to have the Plantronics audio devices selected, as I don't see how this would "enable" call >control in the first place.

Nope, you computer may have a single device, but a lot of computers have multiple audio devices appearing and the client cannot make an assumption as to which one the user needs. You need to select a device so the app knows to ignore the rest and focus on that one.

Your issue is an edge case related to RemoteFX so might have to find a different audio solution (or an alternative USB emulator) that will always be present.

 

[dalep]

Hi @dalep

I'm not sure there is a solution to your issue. When you disconnect the audio device RemoteFX creates is probably being removed and the client is forced to return to "Primary Audio Device"

>I'm guessing the easiest way for 3CX devs to fix this would be to enable headset call control without >having to have the Plantronics audio devices selected, as I don't see how this would "enable" call >control in the first place.

Nope, you computer may have a single device, but a lot of computers have multiple audio devices appearing and the client cannot make an assumption as to which one the user needs. You need to select a device so the app knows to ignore the rest and focus on that one.

Your issue is an edge case related to RemoteFX so might have to find a different audio solution (our sound card emulator) that will always be present.

Hi @JohnS_3CX
Thanks for your reply - I'm guessing that if plantronics hub is installed, it would be reasonably safe to assume you could send the SDK Connection information to Plantronics hub - regardless of which audio device is selected in 3CX settings. However that may be another discussion...

Please help me understand what your sound card emulator would achieve for us? I have a good general understanding of most things IT, however, don't necessarily have in depth understanding of some aspects so bear with me,

 

[JohnS_3CX]

That was a suggestion on my part. The problem with RemoteFX is that once the user disconnects, the audio device gets physically "unplugged" from the remote machine. And then when you reconnect, an effectively "new device" is plugged in that you need to select from inside whatever audio applications you use.

Sorry I entirely mistyped earlier (we do not have such an emulator and never did). I have edited my post above to clarify what I meant. I do not know if such a solution exists and I'm not convinced this problem can be overcome without losing the integration feature (buttons working for answer/hangup) because as mentioned earlier, this is an edge case issue related to the way RemoteFX works, it's nobody's fault really.

Hope this makes things a bit more clear and apologies for not clearing that up earlier.

 

[dalep]

That's ok @JohnS_3CX
For now we are going to remove the chrome extension and utilise the 3CX Windows App installed on server with RemoteFX - each user will have to spend 15 seconds each day when they log onto the server to change the audio options to the headset to enable headset call control - this is a small price to pay for a better experience.
From my perspective, the windows app is a better solution, as while it doesn't look as "nice" as the Chrome extension and WebClient, being its own application where everything can be handled is better (aside from the fact it is not glitchy like our experience with the chrome extension - discussed in another thread).

 

[nobody]

I once also tried out this but in addition all cliens had to use a VPN to connect to the rdp server. It never worked well, mostly because of the additional problems the VPN connection adds.
I then installed the windows client on the local PCs. Since the pbx accepts connections also from internet using the tunnel, the audio problems are less, also the user experience is better.
The windows phone app can be remote-controlled from the rdp server using the web app. So all needed functionality is there.
This solution has the drawback that you have to install the windows app on every client PC, but otherwise works good. You have to block incoming connection to the pbx via the VPN using a firewall rule.

 

[dalep]

I once also tried out this but in addition all cliens had to use a VPN to connect to the rdp server. It never worked well, mostly because of the additional problems the VPN connection adds.
I then installed the windows client on the local PCs. Since the pbx accepts connections also from internet using the tunnel, the audio problems are less, also the user experience is better.
The windows phone app can be remote-controlled from the rdp server using the web app. So all needed functionality is there.
This solution has the drawback that you have to install the windows app on every client PC, but otherwise works good. You have to block incoming connection to the pbx via the VPN using a firewall rule.

Thanks for your reply @nobody,
Our staff that use the phone in a big way are on the same network as the server so it is working OK
We initially started the same as you suggested with the app installed locally and using the Web client to remote or CTI to the local windows app, however this does have its drawbacks as you cannot 'hold' a call or use the keypad during a call for entry of auto attendant directions (you have to minimise the rdp session and do this on the 3cx windows app). Also transferring calls is clunky as if the transferee doesn't answer there is no way to retrieve the original call without going back to the local pc 3cx windows app....
I just can't wait until the remainder of our 5 year warranty on our $80k server runs out then we'll start looking at options to remove the need to use rdp at all, then running the app on the local pc will be no problem as that's where the user will be working