Few Seconds Audio Loss at Beginning of Call - Yealink headset shared with Teams

[jetpigeon]

Hi All,

I'm after some guidance if possible. We have an on premise (V18 Build 418 Enterprise) 3CX server and approx 70 extensions, the overwhelming majority of which are running Windows Softphone (v18.10.461) using Yealink WH66 Mono DECT headsets.

On a small but notable number of calls, regardless of whether they are external or internal (including direct extn. to extn.) an observable silence of a few seconds can be heard (or rather not heard) at the beginning of the call. The length of silence is easily long enough for callers to be saying 'Hello?... Hello?...' before they are able to communicate.

Or findings to date are:
- Wireshark cap. at the PBX and both ends of the call confirms UDP packets are leaving and arriving correctly at each location. Though we're not able to listen back to the audio or view SIP info in Wireshark presumably due to encryption or some proprietary protocol in use on the Softphone.
- Based on call recordings; it looks/sounds like it is usually or always the receiving party who is not transmitting or receiving audio upon answering the call.
- The problem does not appear to affect calls to hard phones or the mobile app.
- There's no reliable method of replicating the issue; it would appear at this stage to be totally random. We have replicated by randomly making lots of calls over and over again and it seems to have affected maybe one in 50 test calls, but other users regularly report experiencing the issue.

Other points to note:
- 3CX server is on same LAN as clients.
- Firewall check passed (irrelevant for internal calls though where we are also seeing this issue).
- Windows client firewall & AV appears fine (does not affect majority of calls and during capture of an effected call we saw timely arrival of UDP packets in both directions in packet cap).
- Yealink headsets all up-to-date with latest firmware. Possibly has been observed using other headsets (of which there's only 1 in the organisation so difficult to know with certainty).
- Issue has not occurred with any other use of the headsets (e.g. Teams) - leading us to believe this is an issue with the 3CX client itself or compatibility with opening an audio session with the headest in a timely manner.
- Affects calls with call recording on and with call recording disabled.
- Affects calls FROM mobile app / hard phone, but only ever observed when the receiving end is on Windows client with a headset.
- We've observed switch & network stats and don't believe there's any issue with the network.
- The caller can hear queue announcements / music with no issues, the issue occurs as soon as the receiving agent picks up the call, further solidifying our believe that the issue is client side at the receiving end.
- Once the audio starts working, the call is solid and reliable with no other issues of note.

Your thoughts would be appreciated as we have at this point tried everything we can think of including pretty much every audio related setting in Windows as well as settings in the headset app.

Thanks in advance,

 

[Charles_3CX]

I would actually suggest checking this also with the desktop app and webclient as the 3cx app for windows (legacy app) is now as stated ‘legacy’. Furthermore it has not received any development since version 16 and will not, going forward. It is also not longer tested with the latest version of 3cx nor with the yealink headsets on current firmware, and since the issue does not occur with ip phones or mobile apps there is a good chance that this issue is actually between the legacy app and the headset.

 

[jetpigeon]

Hi Charles, many thanks for your reply.

Sorry I should confirm the affected setup is indeed the latest build of the Windows desktop app (v18.10.461 - installed and provisioned from the web app) which runs on some build of Chromium and looks / feels identical to the web-app, so presume it's the latest and supported version?

If we're using the wrong software though please let me know and we'll happy roll out a later version.

Many Thanks,
Alastair

 

[Charles_3CX]

In this case you are using the latest version and desktop app which should work. Since though you mentioned that issue does not happen with the teams app, can you check to make sure that the teams app is closed when using the desktop app as we have seen issues with teams app not playing well with others and not releasing the audio device when it is open in tantum with other apps, relying on same audio devices. Also check that the audio devices are chosen in the desktop apps audio settings. You can also test by ringing *777 echo test for example, to check whether audio is delayed to rule out any other endpoints and or VoIP providers.

 

[jetpigeon]

Thanks for the suggestions and interesting to know there may be known interoperability issues with Teams - we can try that for testing but unfortunately leaving Teams closed won't be a feasible workaround here as it is used heavily throughout the organisation for day-to-day operations.

We thought similar regarding a delay in claiming the audio device and have tried unchecking the boxes in Windows audio setting to prevent applications from taking exclusive control of the device, which we had assumed would mean that Teams would not be able to claim the headset exclusively - but that yielded no improvements.

We've also ensured that the 'default softphone' setting in the Yealink app is set to 3CX (labelled as 'softphone 2'). The 3CX app is successfully linked to the Yealink headset.

I can confirm that *777 always works reliably every time with zero delay (to the best of our knowledge and based on tests to date) - it seems that the issue is at the receiving end of the call (our logic here is that is when listening to call recordings for an effected extension to extension call, we can hear the caller speaking, but the recipient audio does not kick in for a good few seconds).

We've ruled out the VoIP provider and NAT issues etc. as this affects both internal and inbound external calls (but not outbound external).

Appreciate that this might be a Windows issue, but given we've only seen the delay on the 3CX app we're hoping that there's something within that that might be fixable.

If there's any logs or anything we can extract or provide for further analysis let us know, we'd be happy to provide.

 

[Charles_3CX]

Troubleshooting this issue requires running wireshark captures along with verbose logging and to check would require a ticket open with 3cx technical support via a partner or or direct from your customer portal.

 

[jetpigeon]

Thanks Charles,

As per first post we've verified UDP data is leaving and arriving correctly in Wireshark at both clients and at the PBX. Happy to trawl through some verbose PBX logs myself but am 99% sure this a client side issue. Just wondered if there are any logs we can get from the client?

Will open a paid support ticket on this also to progress as suggested.

Many Thanks,
Alastair

 

[GeorgeK_3CX]

Hello @jetpigeon
Can you please also clarify the OS Version where the 3CX Desktop App is installed? Also good to mention this in the ticket.

 

[comsyco-gavin]

Can I just add that we are having the same issue here with a very similar setup, one thing I have noticed is when I answer a call the desktop dialar shows a small countdown of a couple of seconds and when that countdown expires then audio appears to be normal,

We have ran through the same trouble shooting as the OP

Our server is using - 4.19.0-21-amd64 #1 SMP Debian 4.19.249-2 (2022-06-30) x86_64

 

[Rhys Haskell]

I am having the exact same problem with Yealink headsets aswell, doesnt happen with other brands of headset. Haven't got round to looking at it yet.

 

[RP!]

We expierence the same, no audio until the countdown expires.

3CXVersion 18.0 U5
Softphone on Win11
Jabra headsets

 

[Charles_3CX]

We expierence the same, no audio until the countdown expires.

3CXVersion 18.0 U5
Softphone on Win11
Jabra headsets

Can you please answer the following question to narrow down this issue?

• Does the system run on self-hosted, hosted by 3cx, or on-premise?
• Is the webclient/desktop app paired with an IP phone in CSTA mode?
• What OS/platform is the system running on?
• Are you getting the behavior from other locations also?
• Do we get the same behavior if you connect to the web client from another public IP?
• Does this happen with every call? External and internal (user to user)?

Additionally, can you disable the integration with the headset from under the desktop app/WebClient> settings > audio video settings, then check and see if the issue is still present?

 

[RP!]

Hey @Charles_3CX,

we fixed the problem by enabling "pbx delivers audio". Clients/Softphones and Deskphones are in different subnets in our case and our firewall policys denys direct connections from Deskphone Subnet to Client/Softphone Subnet. I guess, if the countdown is expired there is a fallback to "audio via pbx".

Thank for your effort!

Regards,
Rafael.

 

[it186]

I was having the same issue as some of the users mentioned in this thread. The Wirreless headphone device used here is Yealink WH66. I upgraded the firmware on the devices (WH66), the issue got resolved.