Call on hold disconnects when resumed, but only if the call came from a call queue

Occasional Contributor

We are having a very vexing issue with some of our users who are members of a call-queue group.


Everyone is on Teams version Windows 10 1909.


If they take a call from the call queue and subsequently put that call on hold, when they click on Resume the call drops. If they receive a call made directly to them, the call can be put on hold and resumed as normal without fail.


The issue occurs consistently with our Jabra Engage 65 and 75 units which initially indicated it might be an issue with those headsets, but when we tried others (including a cheap Logitech wired headset) it still happens, which casts our view back to Teams itself.


We originally discovered a workaround: by disabling "New Meeting Experience", the issue went away completely. But when MS pushed an update a few weeks ago removing the option and we are back to where we started.


We've opened a ticket with Jabra but so far their best suggestion was that another communication app might be running and interfering with the call control command chain. We've scoured for apps and/or background services and cannot find anything except Teams.


Any suggestions for things to look for or try would be very much appreciated.

9 Replies
Hello @B_Flow,
Can you please check with one setting on the Call Queue configuration?
1. Remove the Custom Greeting and
2. Save the Call Queue.

Test the configuration and keep it for a day or two. If everything works fine, we should be able to add the custom greeting again and see if the issue gets resolved.

With Regards,
Satish U
Thank you for the suggestion. We removed the greeting, saved the Call Queue, and tested: Unfortunately no change in behavior.

We have exactly the Same issue.
We use teams with direct Routing.

If the call comes from a call queue and the customer wants to contiune the call, the call is disconnecting after 2 seconds.

We use Jabra 930 and Sennheiser MB Pro 1.
If i switch to a wired head Set, the Problem still Not exists!!!

Anyone a Suggestion?


@Timboh I have not been able to make any progress at my end at all. Jabra says they cannot recreate the problem at their end. We've opened a ticket with Microsoft which should enable Jabra to collaborate with them on the issue. Its particularly interesting that you are having the same thing happen with Sennheiser as well as Jabra (which makes me think this really is more of a Teams issue, miscommunicating with the hardware or something along those lines).


I would strongly encourage you open support tickets with all three companies if at all possible to help draw attention to this obscure but very real and debilitating bug.


After a lot of Research in oure case i could say i have solved the Problem.

In our case it was a misconfiguration in the DNS settings.
After we deleted all old Skype4Buisness entries in the DNS, we were able to resume calls.

I did a Check and i have added all old Skype DNS entries back and the Problem comes back directly.

Please Check the following:
- Do you have old Skype DNS entries?
- are you able to reach sip.domain and lyncdiscover.domain from your local domain?
- also check if the correct srv records are reachable and configured correctly in your Office 365 tenant.

Hope this will help!



are there any new findings on the problem?

We have the same issue :

Direct Routing

Call from Call queue

contiune the call, the call is disconnecting after 2 seconds

Jabra Pro 930 Headsets

Teams 64-bit

Never use or configure s4b in our environment




best response confirmed by ThereseSolimeno (Microsoft)



Hey Ingo, 


can you please check, if the conference mode is not active in your call queue?




If it is not active, please activate it! 


I think, this should sovle the problem.




Hi Tim,

thanks for the fast respond.
I have started a try and will see if it solves the problem.




We faced identical issues with multiple customers (historically SfB customers) a call accepted from a callque was dropped when put in hold while transferring i.e.


Changing this setting immediately solved the issue, also call handling is much faster now!