Forum Discussion
Delays when trying to answer an incoming call cloudpbx
I'm having multiple reports of multiple sites/tenants having an strange issue with trying to answer a call. When they get an incomming call, this can be direct or call queue transfer, there is a delay when they try picking up the call. I.E. I get an incomming call. I get a new Skype for business notification. I click on that notification to answer the call and there is a long delay and the call never establishes. This is happening for different users, different sites as well as for different tenants. All users are using Cloudpbx. Personally I have not been able to catch this in action yet.
Without purchasing expressroute for these sites, what are my options to speed up this pickup time?
What could be the cause of these type of delays?
Does the notification of a new call come in on a different port or does it follow the normal sip ports.
-I know audio and video data comes in on completely different ports. (In the 50000 range)
Has anyone else ran into this yet?
One customer is using Polycom bToe setup and the other is using softphones.
26 Replies
When callers call the main number, the Auto Attendant redirects the call to a Call Queue which takes between 7 to 30 seconds for the actual call to flow to the users.
This is so frustrating to our customers and us as an MSP. Microsoft Phone System needs some serious attention. There are a lot of issues that haven't been addressed since Skype for Business (Lync) online went GA.
After contacting Microsoft, here is what I got from them:
"Hi Hacene,
I spoke with my Senior Engineering Team and they stated that "confirmed unfortunately we can control the transfer time since it is based on phone lines". Unfortunately, there isn't any setting that can be put in place to control the timing. My suggestion would be to use the following link:
User Voicehttps://www.skypefeedback.com/
This is how MS engineers know what the user base is requesting and the more votes a suggestion has the more MS will listen. I apologize for the inconvenience.Thank you,
Office 365 Support"
- Add me to the frustrated partner/msp. Jan - Aug 2018. Finally I see it is the norm. Very sad. My first phone deployment and my last since issues not resolved. Any help is appreciated.
We have tested this again in the past 60 days. The delay that we were seeing has been reduced to about 2 seconds. This is much better than it was before. In some cases, this is still very annoying to people who are used to just picking up the phone and talking. It takes some training to wait for a second or two to start talking.
I have had this issue logged thru Microsoft Advanced support and the development team for nearly a year now. This is the kind of thing that the product needs to resolve before it can be realistically sold to customers of any size.
I don't get it, in what planet is a 5 second delay even remotely acceptable? This problem has existed for some time and the very least Microsoft can do is publicy provide updates on a regular basis.
We are having the same issue. Any word from Microsoft support? Is there a case number associated with this that we can call in on to find out the status? Thank you!
This issue is still outstanding. Microsoft is reporting any solutions to this posting. The last update we received as mid December. All I know is that they are still working on a solution.
Looks like it have been a problem for a verry long time.
Here is a possible workaround.
http://windowspbx.blogspot.no/2012/05/microsoft-lync-simple-ring-group-for.html
We implemented this fix with our customer to get around the problem in the short term. We have had Microsoft give us 3 trail E5 and calling plan licenses to get this implemented (1 E5 for each of the office locations/ring groups). This actually works very well except for the potential long term maintenance of the solution and the wasted license cost of a dummy user and plan. We are hoping that Microsoft can fix this prior to year end so we don't have to go back to the customer and have them pay $150/month to get around an obvious design flaw with the auto attendant. If there is a way to have "free licenses" for this type of situation, that would be great so the pressure on Microsoft getting this fixed can be lessened.
We still see significant media establishment delays (4-5+ seconds) for incoming calls to call queues.
Supposedly the latest Polycom firmware (5.7.0) fixes this issue on Polycom's end (issue EN-32447) -- but we've deployed that firmware and don't see any changes -- Call Queue answering still has a huge delay.
Has anyone heard more about this issue?
Thanks for the feedback on this! I finally was able to get a solid answer from Microsoft that this is a known issue and they have the fix "on the roadmap." There is no solid date for fixing this, but they are trying to fix it before the end of the year. Of course, this is coming from an engineer and not a public statement so take it with a grain of salt.
Statement from a Microsoft engineer:
As discussed, this is something which is an ongoing issue in Online Auto-Attendant. As you are well aware that this feature is recently introduced in the Online and the engineering team is working on it.
The delay of calls in the call queue (something around 5seconds) is a known issue and the engineering team is already aware about the same. We have also raised our concern since we had multiple queries regarding the delay earlier. It has been reduced than before and still the scope is to reduce it lesser than 2 seconds and as I mentioned the team is working on it and we do not have an ETA for now.
I sincerely apologies for that and at present we do not have a work around to overcome this situation. However, once this is fixed or we get any update from the backend, we will keep you updated on the same.
But soon we can expect that the delay will be reduced lesser than two seconds.
However, I request you to add your valuable feedback in the below link which will be viewed by Product level group directly and we can expected this sooner.
https://www.skypefeedback.com/
Soooo I guess I'll watch the forums to see when this issue has been resolved.
- And? 2 years later?
