Solved Headset drops out after period of inactivity.

[Matthew Marven]

Hi All,

I am using a Jabra Engage 75 headset on the latest firmware available from Jabra Direct [3.4.1] with the 3CX for Windows client [16.0.1.88]. The headset works fine when first switched on then after a period of activity disconnects from the 3CX client, the status of the client changes from 'On Hook' to 'Connecting' and in Jabra direct changes from 'Ready to 'Not Ready', in order to resolve I either need to do a test call for example to the echo service (*777) and leave the call connected for 30+ seconds or go to settings > Re-register within the client.

The issue is related to the 3CX client as I am unable to recreate the issue within MS Teams or my machine at times the phone shows as disconnected.

To confirm I have followed these instructions to configure my headset.

Thanks in advance for any suggestions.

 

[JohnS_3CX]

Hi Matthew

If the client says "Connecting" instead of on Hook, it may not be related to the Jabra headset at all.

Can you disable the headset and remove it from the computer altogether (including Jabra Direct) to see if the 3CX Windows client loses it's connection after a while? If we can eliminate the headset from the equation then we have one less thing to troubleshoot.

 

[Matthew Marven]

Hi John,

I have just uninstalled Jabra Direct, removed the driver for the headset from device manager and rebooted.. where do we go from here? Thanks

 

[JohnS_3CX]

Allow some period of inactivity just like before, and lets see if the 3CX client loses the connection again and says "connecting"

 

[Matthew Marven]

Hi John, I haven't seen the 'Connecting...' status as yet, I did notice though that I could recreate the problem with the headset yesterday even when the status was 'On Hook...' right before I uninstalled.

 

[JohnS_3CX]

Ok then it appears that your first post was describing 2 events that were probably unrelated.

As for the Jabra client losing the connection part: don't have much to go on I'm afraid. The only thing I can suggest in that case is to close down the 3CX client and then relaunch it. See if the Jabra Direct application will detect it again. If not, then it seems something may be blocking communication.

Note that these apps will usually make use of some internal ports to talk to each other which may become blocked for any reason (ie something else took over the port) or the listener has stopped. I can't provide you with the specifics but if you know how to use netstat you can take a look to find out which ports they are in case you want to do some sleuthing

 

[Matthew Marven]

Hi John, thanks for your input that's not a bad idea. I am sure it's something in our environment that's causing the issue, it's going to be difficult to find out what!

 

[Matthew Marven]

Ok so it looks like in my initial post I haven't described the issue very well. After doing further troubleshooting I now notice the following:

1. The device shows as connected within Jabra Direct but there is no audio when calling *777 to echo service.
   
   
2. In Windows Settings > Microphone the mic shows as in use by 3CXPhone for Windows.
   
   
3. It takes roughly 30 seconds of being on the phone before the audio picks up.

I will do some more digging and see if I can figure this out.

 

[JohnS_3CX]

Make sure the device is correctly configured in the client too:



Depending on your PBX server location, ensure you have enabled the tunnel


It must also be enabled in the extension:


This will help reduce audio issues when connecting to a remote PBX.
This will not apply at all if the PBX and PC are on the same local network.

 

[Matthew Marven]

Hi John,

Thanks for the advice I did check and confirm those settings however it seems I have been looking at this all wrong, after disabling pretty much all start-up programs and services other than those needed for 3CX to work I still had the problem so dug out an old laptop, put a clean install of Windows 10 on and installed the two apps and I can recreate the issue!

So it would seem something with our network config is causing the issue. My office is connected to the main office via a Ubiquiti NanoStation 5AC where the SBC resides, our PBX is running as Google VPS. Would I need to prioritise traffic from the SBC or is the traffic for the Windows client sent straight out to the internet? Sorry I will have a read up on this! To be honest I am surprised this is the issue as we are running 7 Yealink phones from the 'remote' office and have had absolutely 0 issues in the 3 months they have been installed.

I am also going to take a headset over to the main building and see if I am able to recreate the issue.

Thanks!

 

[Matthew Marven]

So just to confirm, I can recreate the issue in the main office building too when plugged directly into the cabinet switch. It's strange as the audio from the Mic doesn't go through but you can hear the caller on the other end just fine, once the audio has connected you can hang up and make a call straight after and have 2-way audio just fine.

I've ruled out it being the Jabra too as I have the same problem using the internal mic on my laptop!

 

[JohnS_3CX]

Yealink phones = no issues because they connect via the SBC (which uses a tunnel to talk to the PBX)

Windows clients = connect via direct IP and can be affected by routers, packet inspection, blocked ports etc. The SBC is not utilized by the app at all. But the app can establish its own tunnel (just like the SBC) and talk to the PBX directly. If you block communication between the LAN ip of the PBX and the PCs, then the app will be forced to go via the internet, and the tunnel will become active hence fixing the audio issues.

..once the audio has connected you can hang up and make a call straight after and have 2-way audio just fine.

Sounds like the firewalls are messing with the traffic, but once the ports have been opened the first time, it works the 2nd time round.


Bring the tunnel up on the clients like I described earlier, by blocking access to the PBX local IP for all the PCs under that network. You may have to reprovision your clients if they didn't already have the option in their extension to "Reprovision on startup". If they didn't have access to the PBX local IP in the first place then there is no need to block, only enable the tunnel on the extensions and reprovision the clients!

 

[Matthew Marven]

Thanks John, I sussed it! I was setting up traffic shaping and as I was checking the log to ensure it was hitting my rule and it dawned on me that the 5090 traffic is UDP, as audio worked (eventually) and then stopped soon after it sounded like something was being closed down before the app was expecting it to be.. I extended the session timeout on UDP for my rule and everything has been fine since.

A bit of a needle in a haystack that one thanks so much for your help in getting this issues resolved!

 

[JohnS_3CX]

Hi Matthew,

You're welcome, glad to hear it was resolved!