5-7 second delay before calling end can hear when picking up call with Polycom phone
When a call comes in from the Auto Attendant / Call Queue and the call is picked up on a Polycom phone there is a 5-7 second delay before the calling end can hear audio. This delay is pretty long and causes confusion, it should be 2 seconds at the most.
Jochen
shared this idea
63 comments
-
Anonymous
commented
We're experiencing this same issue on our University phone lines. We've worked with both Audiocodes engineers and Microsoft. As mentioned previously, Microsoft relentlessly asks for logs without any resolution and don't try to replicate the issue. External callers are the only ones experiencing this, and many of our faculty and staff are reporting having awkward interactions when answering calls. Without any real solutions, we may have to revert back to our old hardline system.
-
Anonymous
commented
It seems that all teams native IP PHONE (audiocodes, poly yelinke ) experience a some delays when working with hard phones, so I guess that the solution must came from Microsoft
-
Mike Lovato
commented
We're experiencing this as well on our main office number (has Auto Attendant set up) which means our front desk loses several calls a day. We are also experiencing it on numbers with Auto Attendant. Same issue.
-
ejmick
commented
I have also experienced this. Small deployment, 5 users, 3 Poly CCX phones. Calls run through Auto Attendant (for scheduling) then to Call Queue to ring all users (Attendant Routing). When phones are in place, call presentation is delayed 3-10 seconds. When answering the call from the client or phone, response is very sluggish in that audio doesn't cut through for a few seconds. When phones are removed and run as "client only", performance is much improved. Not perfect, but about as you would expect. Customer feels as though they gave it a shot, but wants to replace it with something else.
As a partner looking to build a Teams Voice practice, this has us considering going back to our previous voice offerings. To Microsoft support's credit, they acknowledged this as a "known issue" and have engineers investigating a workaround and/or permanent fix. Hoping for a quick resolution to restore the faith. -
ATG
commented
I apologize in advance for the long post. I hope others find this helpful or have a different/better experience.
I spent from 20-May until 18-Jun working on this about 4 hours/day. Some on my own and some with a Microsoft engineer, basically going in circles. I would provide information, Microsoft would 'pass it up to the engineers'. My contact would ask for logging information...dates and times of problematic calls and each time asking for more examples and logs. Also asking me to "record the delay using a stopwatch", which Microsoft was quite insistent that I do...as in a literal stopwatch. I was told they needed to know exactly how long the delay was (despite it almost always being 6 to 10 seconds). Each time the engineer would call into the customer's front desk the report was 'it seems to be working fine'. I asked if the call was made using a normal mobile phone, the answer was 'I'm not allowed to do that'.
Never at any point, though requested, did Microsoft offer to get on a bridge with me and take and dissect a packet capture.
Microsoft eventually concluded that it must be the 'legacy' Polycom VVX601 phones...despite the same thing occurring on a Teams certified Yealink MP56 (though it was better, but still not good enough)...and the fact the VVX601 had been working fine for Months.
There is a call transfer setting (conference mode) in the Call Queue that made it better when enabled, but everything had to be native Teams (no mixed 3PIP mixed SfB allowed - which of course the customer is).
Using the Teams client worked fine with the incoming Auto Attendant and Call Queues, as did direct dialing a number associated to a user on the Polycom VVX601 - repeat...ZERO problem with direct dial. I believe there is something wrong with the call setup time when AA and CQ's are involved.
The customer, a medical office, was not interested in transitioning to the Teams client on the computer as having a physical handset was a client specified requirement when originally moving to Teams.
On 18-Jun, the owner of the business instructed me to go back to their their legacy PSTN system. "I cannot run a business like this..we look so unprofessional". I have to agree.
This Friday I am moving the customer back to their original carrier on analog lines. It cannot happen soon enough.
DISCLAIMER: Microsoft you are welcome to fact check this. If I have misstated anything in anyway, it is not intentional. I've done my best to report the facts as they were in hope this is useful to another individual or organization.
-
Stewart
commented
Lots of people having this audio connect delay issue.... anyone had a response from Microsoft yet?
-
ATG
commented
Same problem here. Beginning around 0900 EDT (1300 UTC) on Thursday, 20-May after having made zero changes to anything related to the customer's environment, the customer who previously had been happy with the Teams performance went to what is now reported as a 6 to 12 second delay from the time the call is answered to the time the customer can hear the caller on the phone. This includes the customer's test phone that I use back at my office completely separate from the customer LAN. As you can imagine, many calls are terminated by the caller thinking the call had not connected. Customer is using caller ID to call the patients back (medical office).
The customer is very unhappy about this and simply wants to dump the whole kit.
In this situation call comes into an auto attendant on a # associated to a service account and the auto attendant immediately forwards the call to the front desk phone. All phones are Polycom VVX 601 using Poly certified SfB firmware one rev in arrears (same problem with latest firmware).
Microsoft reports there is a known issue with Teams and Attendants/Call Queues that accounts for 2-4 seconds of delay but insists that anything more than that is a different problem.
I'll keep an eye here for any advice.
-
Kunal R
commented
We are using Yealink MP56, WH63 and WH67 along with Teams App on computer and laptop. After enabling the Conference Mode for call queues, you have to wait for like 2-3 seconds till the music stops playing. It's an annoying bug but users are getting used to it.
-
Anonymous
commented
I can't believe Teams Voice is actually called a phone system. Microsoft doesn't give their physical phone partners a set of usable Teams Voice code to produce a phone that actually works. Without a physical phone Microsoft Teams Voice is not a phone system!!!!!!
There is a huge time lag for people to answer calls from a call queue! You never know when to say hello and this is bad for customer service!
Contact on physical phones - You should be able to program an external number on your phone. This is a basic concept of a phone in a phone system. You should not have to dial an external phone number to add it to a contact list!!!! You should not have to log into the Teams client to add external contacts quickly or without calling them!!!!!
A phone should have the ability to transfer callers to a contact list quickly!! You should not have to look up in directory a persons name to transfer a call.
-
J-Pharr
commented
Glad I found this thread. Our office is all on Polycom VVX phones and we all have a 5 to 7 sec. delay at the beginning of any inbound and outbound call. I was thinking trying a newer model Yealink or similar to see if that fixes it, but is sounds like this issue is 100% on Microsoft's end of things. I'm responsible for moving everyone in our organization to Teams, so I have to take all the complaints from the staff and upper management.
-
beaine
commented
Yes, it happens in all our sites across the globe. Even with SIM card.! Employees are really frustrated and users wants to go back to previous product.
-
Jeff
commented
For sure this is a pretty big issue - and not only Poly phones - happens with the app.
-
ATG
commented
Same issue reported by my customer today. Polycom VVX 601, using SfB. Similar problem on 17-Dec-20. MS confirmed it was a config change on their end. It appeared to be specific to VVX/SfB.
-
Derek Nathan
commented
This happens on any phone or even the app! Extremely annoying.
-
Anonymous
commented
This issue affects the clients we've moved to Teams with Direct Routing and is frustrating them to the point that they're begging for Skype for Business on-premises back (!). As a result we're unable to move our remaining clients to Teams. Please, for the love of Bill, fix this ASAP!
-
Fabian
commented
We have an auto attendant/call queue and there are 11 seconds of silence after the initial ring. Teams phone system plays 7 seconds of music before the call is delivered to a queue member. Its not clear to me why there is even 7 seconds of music because there are agents available in this queue. Essentially the caller is waiting 18 seconds before it is answered while queue members are available.
-
Adnan
commented
we are facing the same problem here with one of our customers. with direct routing using poly phones when call is transferred from auto attendant to call queues it take up to 8 seconds for the user to hear the other end .
-
Anonymous
commented
We're experiencing 4-7 sec delays for incoming calls with Direct Routing. the same thing on Poly, Yealink and Audiocodes phones.
-
Kimberly
commented
Does anyone have a fix for dialing out with TEAMS and calls are not connecting? I am used to the 7-10 second delayed calling, but calls are literaly not calling out now.
-
Tom
commented
We have a lot of clients who want to switch to Business Voice now that work from home is more common, but the delays are causing a lot of frustration for the few clients we have already moved. Our first client to move is NOT using Direct Routing, we ported everything over to MS and they still have issues with AAs and CQs taking forever to transfer a call.
With everyone working from home now, Microsoft needs to start pushing out the fixes faster or we're going to have to start migrating our clients to another hosted solution.