Calls getting placed on hold after answering

[Jason Tenpenny]

So we just recently switched our phone system to Teams. We've noticed on a few occasions that we try to pick up a call from a call queue, and it puts the call back on hold. The user has to resume the call in order to actually answer the call. I think it's only happened on physical handsets from Yealink and not from the Teams app on computer or mobile. Anyone else seen this and possibly have a fix? We've tried rebooting the handsets, logging out and logging back in, etc. They're running the latest firmware.

[#2]

Just started seeing a very similar problem but with the teams client. Were you able to find a solution? @Jason Tenpenny 

[#3]

@ChrisbieUnfortunately I have not found the answer. TBH I haven't had a ton of time to investigate it. Interestingly enough, the desktop client is the only place that we haven't had it happen. It's happened once or twice on mobile, but still not nearly as much as on the desk handset.

[#4]

Take note of when it happens: Date, Time, callers numbers, queue name, your number. Report it to Microsoft . The will check system logs and investigate cause and hopefully fix it.

[#5]

@KeepingITreal I am having this same issue. As soon as I pick up from a desktop app, I get told that I have been placed on hold. It's getting annoying. Have anyone figured out a solution besides just hanging up?

[#6]

This is now standard on my Teams on OS X. Well done MS

[#7]

Started happening to me about a week ago.

But it goes on hold twice before it puts me through.

Nothing changed on my PC.

Running Windows 11.

[#8]

Hi There,
we are facing the same issue with some of our call queues (not all of them).
Any solution on this case yet?

[#9]

We're having the same issue occurring for us in our business recently. We are using Teams desktop clients with Jabra Evolve2 65 headsets which are certified devices for Teams integration. I've tried updating the firmware for them and no luck. Only users using these headsets have the problem.

[#10]

Hi,

We are having a similar issue.  Call queue calls are being placed onto Hold for any user using the Teams client in a VDI session (Version 1.4.00.29469 (64-bit). Citrix HDX Optimized).  They cannot retrieve the call, it just is lost.  A call directly to their Teams DID works fine. 

  I can answer a call in the same call queue using Teams desktop client Version 1.5.00.2164 (64-bit) with no issues over VPN. 

Any thoughts/recommendations?  

[#11]

@sukosuna 

We are having exactly the same issue - puts an incoming call on hold twice before connecting it. We are also using the Teams desktop client with Jabra Evolve2 65 Teams version headsets. I struggled to find any solutions and so raised a support ticket with MS.  They said other cases have identified the headset is causing the issue but weren't able to confirm it was particularly this Jabra headset.  They have suggested the following:

• Clear the Teams program cache.

• If you are connecting the headset via Bluetooth, reset the connection.

• Try another headset to confirm your original one is the issue.

I have not had sufficient time to prove if any of these have resolved my issue, but thought I'd post them here for others to try.

Hope that helps and would be glad to hear if anyone has success with these solutions!

[#12]

@Clive_H The only solution is to not use Teams. We used Plantronics 8300 and 8500 headsets and experienced the same problem. They said the same thing to us and gave us the same things to try. We moved to RingCentral. The experience for the end user is much better but their backend Admin stuff is not fun at all. 

[#13]

I found a fix for my issue, which was VDI Teams users not being able to answer calls in a Call Queue. The Conference Mode feature on the Call Queue was set to Off by default, I turned it on and all VDI users were able to work again. Don't know why/how this call queue ever worked as it was setup a while ago (and never changed) and had no issues for months until very recently. Wondering if this Conference Mode on the Call Queues is a new MSFT function? Not sure. Maybe this will help some others experiencing similar issues.

[#14]

Hi Tom,

Our VDI/Citrix environment just encountered the same issue today and applying your fix to our existing Call queues has resolved the issue.

Thank you for posting your issue here.

[#15]

@Tom_McG  this is a while ago and you may have noticed by now, but one "gotcha" with enabling Conference mode on a Call Queue is that once answered the user won't be able to transfer the call.

We're having this issue now as well, answered calls going on hold, but we can't enable Conference mode as the person answer the phone needs to bel able to forward calls to the appropriate users. 

[#16]

I have just encountered the issue with Call Queue calls going on hold when being answered for the first time today. Finding this thread pointed me to Conference mode - however we have disabled conference mode on our call queue for this very reason - if it was enabled, the Teams Desktop app would no longer give us call transfer options. We did find that using a Polycom CCX500 phone DID allow the call to be transferred, but the options were missing entirely from the Teams desktop app. This is frustrating because Polycom CCX500's in a GCC High tenant are a DUMPSTER FIRE and we can't get good firmware to get them to work right. We ultimately disabled conference mode on our call queues, which now leads me to this issue - calls going on hold when they are answered. I'm opening a Microsoft ticket, but don't have high expectations.

[#17]

Update for my issue: We put the user who was experiencing this issue onto a headset and had them answer calls from the teams desktop app instead of using the Polycom CCX500. So far, no further issues with Call Queue calls going into hold, they all come in just fine. Will continue testing but after being able to reproduce it very regularly prior to removing the Polycom and having zero calls go into hold after seems to heavily suggest it was the Polycom in this case.

[#18]

Turning on conference mode resolved the issue for us.