Forum Discussion

Jason Tenpenny's avatar
Jason Tenpenny
Iron Contributor
Sep 16, 2019

Calls getting placed on hold after answering

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.

    • Jason Tenpenny's avatar
      Jason Tenpenny
      Iron Contributor

      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.

      • KeepingITreal's avatar
        KeepingITreal
        Brass Contributor
        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.
  • Fabio_Strincone's avatar
    Fabio_Strincone
    Copper Contributor
    Hi There,
    we are facing the same issue with some of our call queues (not all of them).
    Any solution on this case yet?
  • sukosuna's avatar
    sukosuna
    Copper Contributor
    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.
    • Clive_H's avatar
      Clive_H
      Copper Contributor

      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!

      • Chrisbie's avatar
        Chrisbie
        Copper Contributor

        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. 

    • Tom_McG's avatar
      Tom_McG
      Copper Contributor

      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?  

  • Freak4915's avatar
    Freak4915
    Copper Contributor

    Jason Tenpenny Just had this issue start happening at home with the desktop client. Just throwing my two cents into what could be causing this. I was running snort on the WAN interface in pfsense. With this enabled caused calls to be put on hold. Once disabled the call would work as normal. Will be checking the logs and post again, but it could be related to a firewall rule/policy which is causing this.

Resources