Forum Discussion
Delay transferring out from auto attendant
We have been testing Teams with Direct Routing trunks provided by a carrier partner. All inbound and outbound calls direct to/from Teams users connect without issue. We are using the Teams apps on Windows and iOS - no deskphones are involved yet.
I have a simple auto attendant set up which greets the caller with the text-to-speech feature, and then transfers to a queue. This queue plays the default music on hold while alerting queue members.
The problem I have is that a caller will dial the number associated with the auto attendant, the call will be answered within a couple of seconds, and then immediately the greeting will be read out and the user will be transferred to the call queue. There is then a silent period of between 5-10 seconds before the music on hold for the queue is heard - this varies with each call, at the lower end it's an acceptable delay, but when it gets to 10s of silence it really isn't workable. If I set the routing on the call queue to put the caller back into the auto attendant after a wait period this happens without any silence - the maximum wait period for the queue is reached and the greeting is played as soon as the music on hold ends.
I am not able to determine whether the delay is happening within the auto attendant as it just waits after playing the greeting, or whether it's an issue at the start of the call queue. I opened a support ticket and was told that this delay is expected behavior and it is designed that way - the problem is that it's long enough for people to abandon calls as they think there is a problem. The queue is in conference mode, but this isn't an issue with users answering calls from queues so I don't think that is relevant anyway.
Is it true that this delay is expected behavior? Is it expected due to a technical limitation or is it really designed that way?
Jonny Marlborough I'm experiencing the same thing, transfer out of an AA to a Call Queue, delay of 7+ seconds.
We also have exactly the same problem.
An Anynode from TE-System is used as the SBC.
From my point of view it seems to be a problem on Microsoft side.I have opened a Premier Support ticket on 11.11.2020. So far there is no solution.
Hi zilmar
Did Microsoft end up confirming it is an issue?
I have seen a new option GenerateRingingWhileLocatingUser under Set-CsOnlinePSTNGateway (SkypeForBusiness) | Microsoft Docs and New-CsOnlinePSTNGateway (SkypeForBusiness) | Microsoft Docs but unable to set via Powershell (I've even downloaded the latest Teams Preview Module - 1.1.11).
This sounds like it should resolve the issue and from the following link is $true by default Connect your Session Border Controller (SBC) to Direct Routing - Microsoft Teams | Microsoft Docs
Not sure if it's something MS is still working on and hasn't been deployed to all tenants.
Michael
Last week I received this reply confirming the problem.
As you know additional internal resources were involved on the reported issue as well we did reached out to our Product Group and from there they confirmed that they are aware of that behavior and they are working on fixing the behavior and reduce the delay significantly.
Call routing time justified by the hops in call AA => CQ => CQ agent, It can take up to 10 seconds if tenant is US and user accounts Europe locations.
During that call routing time if no greeting is configured on AA (is the case per screenshots presented).
For avoiding the silence admins can configure Greetings and Music on hold.
Set up an auto attendant for Microsoft Teams - Microsoft Teams | Microsoft Docs
Create a call queue in Microsoft Teams - Microsoft Teams | Microsoft DocsThe delay in call routing is being fixed by the Product Group.
Unfortunately the fix for this may be rolled by March end (there is no definite ETA currently). After the fix is done the delay should be reduced significantly.
- Hello, we recently deployed with one of our customers auto attendant solution with direct routing (AudioCodes SBC) and forwarding to the group voicemail and experiencing 15-20 delay when forwarding from AA to voicemail. We opened ticket to MS immediately, but they are not able to explain to us what causing this issue. It's strange that even after years they are not able to solve this issue.
Same here. It's just not a viable solution with all the delays.. Tons of issues with Operator connect with Verizon as well.
Quick update on this one - the delay is also present when an auto attendant routes a call to voicemail. A simple AA that reads a greeting and then connects to a voicemail box for an Office 365 Group will pick the call up immediately, read out the greeting, and then there is around 8 seconds of silence before the voicemail greeting plays.
So the issue seems to be related to transferring out of the auto attendant, rather than into the group. As far as I know there is no way to get logs out of these voice applications yet that would provide traces.
I've not seen it take as long as 8 seconds before, maybe half a second to a second. Are these Teams calls to the AA, or PSTN calls to the AA?
I know they introduced an option recently for Call Queues to use conference instead of transfer method, which speeds up answering calls for call queue members, but there isn't something similar for AAs.
Experiencing the same thing on transfers from the AA's. Callers have dead silence after selecting an option to be transferred to. This is if sent to a user, a CQ or a voicemail. No matter how long the silence, it is unacceptable.
- So, I think our issue is the same, or at least has the same causes as yours.
Essentially, our ideal call flow is Auto attendant > call queue > receptionist.
Unfortunately the handoff from AA to CQ takes a solid 5 seconds. Add that to the initial connection from the caller to AA (about 1 second) and then the handoff from the CQ to the receptionist (about another 2 seconds) and you have a SOLID 7+ second delay from the time someone dials to the time they talk to someone even if the receptionist answers IMMEDIATELY.
Clients have complained that it takes way too long, and they aren't wrong.
Is my issue the same as yours?
Has Microsoft finished the fix for this yet?- Yes it's the same issue. In our case we have a AA which transfers the call to a CQ and it takes about 8 seconds. Which is way too long. According to MS there will be a fix which reduces the transfer time to 1-3 seconds. ETA is Q3/Q4 2021.
- I'm REALLY glad to hear that MS is working on this. There's only a few days left in Q3, so hopefully we aren't looking at late into Q4. Realistically, it needs to be closer to 1 second, not 3 in order to give the impression of a professional grade, speedy phone system.
We came from an on-prem system which we all knew would be faster than any cloud-based platform, and this was expected. For things that used to be immediate, I prepped our users to expect a 1-2 second delay for most things (initiating, answering calls, transfers, etc), but anything above that is really tough to swallow when everything else used to be nearly instant.
By the way, our workaround to get past the CQ handoff delay is that it goes AA > Generic reception user account, and we have logged into the reception account directly and added receptionists as delegates, and then set Teams for the reception account to "also ring" delegates. Janky, but it works with some drawbacks.
That sounds like the same issue we have. I've not tested in a while but I've not seen any announcement that it has been fixed yet, and from people's testing in this thread it seems to still be a problem.
- Is your tenancy in a different region to the call queue members? (this was my scenario and I was getting the delay - we managed to resolve using some other SBCs and essentially relaying the call from SBC to SBC so that it breaks out in the same region as our tenancy.)
- Got an Update on this case from MS. The ETA will be Q3/Q4 2021. Hope the fix will not be delayed once more ...
- Unfortunately, my company has the same problem. I constantly get complains and I am hopeless, as an IT professional I can't do anything about it. I've been living with this problem since Microsoft Teams for desk phones been introduced and little improvement on call delay via call queue was made, other than the conference mode, which seems to have been a way to calm us down. Why other cloud services do not have this problem and MS can't figure this out? Maybe they should copy the technology from the smaller guys. Would switching to Verizon PSTN calling for Teams make any difference or is it strictly a software issue here.
What we have found is that the problem only occurs in DirecRouting and not in Operator Connect.Therefore, we have changed our hotline number to an operator connect. Since then, we no longer have any problems.
Szczipiorek
Jonny Marlborough please vote for this to be worked on by Microsoft.
- We recently implemented Auto Attendant with direct Routing and are currently experiencing the same issue. We promptly raised a support request with Microsoft, but unfortunately, customer service informed us that this particular issue is a design limitation. still no resolution and affecting our business badly.
- We recently implemented Auto Attendant with direct Routing and are currently experiencing the same issue. We promptly raised a support request with Microsoft, but unfortunately, customer service informed us that this particular issue is a design limitation. still no resolution and affecting our business badly.
