Delay transferring out from auto attendant

Brass Contributor

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?

36 Replies
37 seconds seems wild. To me, that would appear to be a different issue, unless you have the same issue, but on steroids.

@YouGotServered 

 

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.)

@_PeterL_ Ours is all the same region.

 

Sadly due to this issue and the continual Teams outage (like the one last week due to a bad update that MS had to rollback due to lack of good QA), we have been instructed to look for a replacement ASAP.

 

Microsoft's horrendous and slow support is not acceptable for something as critical as phones, ESPECIALLY when we've had 3 outages in the past 6 months (NOT including the bandwidth.com DDoS attack which I can't blame MS for). Our clients want a vendor that they can actually call and get resolutions from instead of essentially throwing a ticket into a volcano. Most of our Teams issues have gone unresolved with support. We've been told to wait months for resolutions that never come.

 

Teams is a good platform, but not for traditional calling I'm afraid.

BUMP! We are still seeing this? any update in this thread group? We have added a generic greeting but overall the transfer is still quite high.
No, there has been no update/resolution.
This problem is not resolved. New ETA is January 2022.
I just spoke with Microsoft Support and they are saying that while they are working on they fix, but there is no timeline to share and that we should monitor the Office Roadmap for improvements to the Call Queue handling. They are not giving out a time at this point though and said it was part of a large scale change to the architecture of the teams auto attendants and call queues on the back end.
Any update on this issue we also have 10 sec delay in the redirection from AA to CQ.

@krsandeep Same here. We have a ticket open with MS as well and they are acting like they have never heard of this issue before. 

 

We are using @YouGotServered solution with delegates and that has helped but we really need these CQs to work quickly.

This delay they have region wise like for USA it could be 7 sec for other 10 or more than that.
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 

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.
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.