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

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.

@Jonny Marlborough 

 

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.

@Jonny Marlborough I'm experiencing the same thing, transfer out of an AA to a Call Queue, delay of 7+ seconds.

@Jonny Marlborough 

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

 

Hi @Michael Milad-Said 

 

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 Docs

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

 

Hi @zilmar ,

 

Ok thanks for the info.

I had initially raised a support ticket with Anynode and they mention the below solution as a temporary fix for the silence. I've tested this and it works ok (replace Australia with your respective Country ringback tone)

 

Hope it works for you :)

One more thing though:

On the SIP Node on which the incoming call is received, you could configure an Australian Ringback Tone from anynode's own Media Sources, if you like.

- Inbound_Node_configure_Ringback_tone.PNG
Inbound_Node_configure_Ringback_tone.PNG
Note: In version 4.0.6 this can be found under Media Sources, but in the latest version 4.2 this was now renamed into Tones and Announcement. Also the layout looks a bit different now, but the undelying software architecture has not changed.

This Ringback tone will not resolve the "~5 second delay" issue (after the 200 OK), but it may alleviate the observed symptoms somewhat. At least the caller should hear a ringback tone then as long as the transferred call is still in the 180 Ringing state. After the ICE peer negotiation finished successfully and anynode receives the final 200 OK, the Ringback tone would then stop to be played, of course.

We are experiencing the same delays discussed here. Has there been any developments/improvements/releases since Feb?
I got confirmation from MS that this is still a problem and this should be fixed by the end of this year.
Same here. We are experiencing up to 8 seconds of silence. MS confirmed its a known issue and there will be a fix by the end of the year. This is a deal breaker for us and we will not move anyone over to Teams until its fixed.

I have an open support case about this and MS stated that his will be fixed by the end of July. Hope they keep the promise. We will find out next week. I'll keep you updated

@ATKai 

Did they say which year? Because I've been suffering from this since December now.

 

Can anyone recommend an alternative platform to move the AA workload to?

The first statement was that they will fix it by the end of the year 2021. Then I created a Ticket for that and then the statement was that the fix will be deployed earlier then expected (July 2021). But so far nothing has changed and now I don't really get a response from the support engineer ...
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?
Got an Update on this case from MS. The ETA will be Q3/Q4 2021. Hope the fix will not be delayed once more ...
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.
I have a client where from the time they dial the number and hit send on their cell phone, it takes 37 seconds for it to ring at the branch location - single auto attendant, single call queue - 3 users in the call queue. Will be doing some testing tomorrow and opening a support ticket. But sounds like the same issue.