Aug 11 2020 05:53 AM - edited Aug 12 2020 03:44 AM
Aug 11 2020 05:53 AM - edited Aug 12 2020 03:44 AM
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?
Aug 13 2020 04:53 AM
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.
Aug 15 2020 05:28 PM
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.
Oct 16 2020 11:56 AM
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.
Jan 07 2021 03:13 AM
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.
Feb 15 2021 02:55 PM
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.
Feb 15 2021 10:45 PM
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.
Feb 17 2021 02:14 PM
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.
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.
Apr 08 2021 02:16 AM
Jun 23 2021 03:26 AM
Jul 28 2021 05:14 PM
Jul 29 2021 02:06 AM - edited Jul 29 2021 06:53 AM
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
Aug 04 2021 10:23 PM
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?
Aug 13 2021 06:03 AM
Sep 15 2021 01:00 PM
Sep 16 2021 02:23 AM
Sep 16 2021 02:28 AM
Sep 16 2021 06:12 AM
Sep 16 2021 07:14 AM