SOLVED

Anonymous callers not appearing on desktop app

%3CLINGO-SUB%20id%3D%22lingo-sub-2855344%22%20slang%3D%22en-US%22%3EAnonymous%20callers%20not%20appearing%20on%20desktop%20app%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2855344%22%20slang%3D%22en-US%22%3E%3CP%3EHi%20Tech%20Community%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWe%20are%20seeing%20some%20strange%20things%20on%20our%20deployment%20and%20am%20hoping%20someone%20here%20may%20have%20experienced%20the%20same%20and%20have%20found%20a%20workaround.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWe%20have%20been%20using%20Microsoft%20Teams%20with%20a%20provider%20using%20direct%20routing%20for%20inbound%20and%20outbound%20calls%20to%20the%20PSTN.%20Things%20were%20working%20very%20well%20for%20the%20first%20month%2C%20however%2C%20it%20seems%20as%20though%20things%20have%20gone%20downhill%20since%20then.%20We%20are%20having%20issues%20where%20callers%20are%20placed%20in%20the%20queue%20that%20we%20have%20defined%20but%20notifications%20of%20this%20inbound%20call%20do%20not%20appear%20on%20the%20mobile%20or%20desktop%20applications.%20As%20such%2C%20our%20staff%20cannot%20pick%20the%20call%20up.%20This%20issue%20is%20with%20Microsoft%20support%20for%20now%20who%20originally%20blamed%20our%20SIP%20provider%20using%20an%20unsupported%20SBC%20version%20but%20now%20that%20this%20has%20been%20updated%2C%20Microsoft%20is%20finally%20escalating%20internally%20...%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIn%20the%20meantime%2C%20we%20have%20noticed%20that%20when%20callers%20who%20don't%20show%20their%20caller%20ID%20call%20us%2C%20the%20inbound%20call%20notification%20only%20appears%20on%20the%20mobile%20app%20and%20not%20the%20desktop%20app.%20We%20have%20checked%20the%20desktop%20settings%20and%20even%20toggled%20this%20in%20case%20this%20helped%20but%20to%20no%20avail.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%20class%3D%22lia-inline-image-display-wrapper%20lia-image-align-inline%22%20image-alt%3D%22CyberStriker_0-1634520774121.png%22%20style%3D%22width%3A%20400px%3B%22%3E%3CIMG%20src%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F317968i71CB4950D3B029E7%2Fimage-size%2Fmedium%3Fv%3Dv2%26amp%3Bpx%3D400%22%20role%3D%22button%22%20title%3D%22CyberStriker_0-1634520774121.png%22%20alt%3D%22CyberStriker_0-1634520774121.png%22%20%2F%3E%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIs%20anyone%20else%20experiencing%20this%20issue%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ERegards%2C%3C%2FP%3E%3CP%3ECraig%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-2855344%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EInbound%20Call%20Issues%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2859107%22%20slang%3D%22en-US%22%3ERe%3A%20Anonymous%20callers%20not%20appearing%20on%20desktop%20app%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2859107%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F1188186%22%20target%3D%22_blank%22%3E%40CyberStriker%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAfter%20almost%206%20weeks%20of%20running%20what%20I%20would%20call%20a%20degraded%20phone%20system%2C%20Microsoft%20support%20have%20finally%20provided%20a%20recommendation%20that%20has%20resolved%20the%20problem.%20Whilst%20I%20do%20not%20have%20all%20the%20technical%20details%20of%20what%20is%20actually%20happening%2C%20it%20seems%20as%20though%20the%20%22Conference%20Mode%22%20makes%20a%20difference%20to%20whether%20the%20Desktop%20Teams%20App%20will%20receive%20notifications%20from%20callers%20that%20have%20blocked%20their%20Caller%20ID.%3C%2FP%3E%3C%2FLINGO-BODY%3E
New Contributor

Hi Tech Community,

 

We are seeing some strange things on our deployment and am hoping someone here may have experienced the same and have found a workaround.

 

We have been using Microsoft Teams with a provider using direct routing for inbound and outbound calls to the PSTN. Things were working very well for the first month, however, it seems as though things have gone downhill since then. We are having issues where callers are placed in the queue that we have defined but notifications of this inbound call do not appear on the mobile or desktop applications. As such, our staff cannot pick the call up. This issue is with Microsoft support for now who originally blamed our SIP provider using an unsupported SBC version but now that this has been updated, Microsoft is finally escalating internally ...

 

In the meantime, we have noticed that when callers who don't show their caller ID call us, the inbound call notification only appears on the mobile app and not the desktop app. We have checked the desktop settings and even toggled this in case this helped but to no avail.

 

CyberStriker_0-1634520774121.png

 

Is anyone else experiencing this issue?

 

Regards,

Craig

2 Replies
best response confirmed by CyberStriker (New Contributor)
Solution

@CyberStriker 

After almost 6 weeks of running what I would call a degraded phone system, Microsoft support have finally provided a recommendation that has resolved the problem. Whilst I do not have all the technical details of what is actually happening, it seems as though the "Conference Mode" makes a difference to whether the Desktop Teams App will receive notifications from callers that have blocked their Caller ID.

Just in case other people are experiencing the same issues as we were, I've decided to write up this post to go through our 6 week saga hunting down this issue in the hope that this helps other people as well as catch the attention of Microsoft who really need to sort out their customer service.

Whilst the overall attitude of the staff have mostly been very favourable, it was frustrating working with them when I felt powerless when it came to escalating the issue and even more annoyed when they resorted to finger-pointing at our SIP provider.

This deployment at this medium sized business with around 30 agents have a very simple set up where we have an Auto Attendant that presents the caller with an IVR giving callers a choice of joining one of three call queues. The call queues are configured using agent routing as the agents are doing mixed duties, serving the front desk as well as taking calls so agent routing works best for us. Agent routing is where all agents will be notified of incoming calls and have a chance to pick the call up. This may cause some race conditions but it is of minor impact to the staff whilst providing the best experience for the caller.

For whatever reason, Microsoft have not invested in providing decent Teams Calling reports. The report that was provided as an example is good starting point but the way the visualisations were configured were terrible as you would see things like 100% call abandonment that sticks out like a sore thumb even if it was just 1 call out of 1 in that particular time period. We pretty much had to create our own reports to provide actual useful information to our management staff.

We noticed that at the beginning of September, that the call abandonment numbers were significantly higher than the weeks before. We receive up to 80 calls per hour and the average number of abandoned calls went from 2 to 10. Whilst this doesn't seem significant, we conducted some call tests and found that there were times when we were in the queue but none of the agents were notified of the inbound call so they couldn't pick up. Some of our test calls went through immediately but some appeared to be clogged in the queue and then the queue would suddenly start flowing again and we would see a barrage of calls as if something was causing the queue to stall and then it would suddenly flow again.

The agents are all using the Teams Desktop App and Teams Certified headsets. After logging a ticket with Microsoft, we were asked to provide logs from Teams, enabling debugging then using the ctrl+alt+shift+1 key combo to generate the logs and after a week of going back and forth, as we were using direct routing through a SIP provider, we were asked to provide the SBC (session border controller) logs from our SIP provider.

After providing the SBC logs, we were advised that the SIP provider was not using a certified version as per https://docs.microsoft.com/en-us/microsoftteams/direct-routing-border-controllers. Now whilst this was a good reason for us to have our SIP provide update their version of the SBC, it does not take away from the fact that the problem was most likely on the Microsoft platform seeing that callers could actually get to the queue but it was the Teams desktop app that was not receiving a call notification. Despite pushing Microsoft support to have someone escalate and actually help us with the issue, they resorted to finger-pointing and would not assist until our SIP provide updated the SBC version. We pushed our SIP provider to look into updating their version and they said they needed to do the necessary testing before rolling it out.

Whilst this was happening, out of desperation, we had configured an additional queue and had callers move from one queue to the other after a time out period of 1 minute. That is, if a caller is in the first queue for one minute, they are moved into the second queue that was looked after by the same agents but new callers would land up in the first queue. Callers who were in the second queue for a minute would be pushed back into the first queue and callers would flip between queues till they were either answered or abandoned the call. This turned out to improve the situation somewhat. We had no idea why but it was not ideal and we were still seeing higher than normal call abandonment.

After waiting a little over a week for the SBC to be updated, of course, the issue persisted, as originally suspected, it was something to do with the Microsoft platform. We were asked to provide with a generic looking Microsoft website that instructed us to collect a bunch of logs and we yet again had to do multiple test calls until we were able to capture the situation where the issue would occur. After submitting the logs to Microsoft, yet another week goes by with nothing but "we are looking into it" responses when prompting them for an update.

Meanwhile, we started testing to see if the Teams Mobile app would provide any additional improvement as the Teams Desktop app appears to be far more problematic in many ways. That's when we found the smoking gun. As it turns out, most calls coming through the queue would appear on both the desktop and mobile apps but anonymous calls, where the caller had switched off their caller ID, would ONLY appear on the mobile app!

This explained everything. It explained why the queue would stall and then suddenly flow again and why having two queues with callers flipping between both queues every 1 minute actually helped the situation. The anonymous callers simply couldn't get through due to the lack of notifications to the desktop app and they would clog the queue until they hung up. The problem wouldn't have been as bad if we had used a different agent routing method but as I said before, it is the best for the business based on the current mode of operation.

So we decided to have a few agents install Teams apps on their phones so that they could use that to handle anonymous calls to prevent these calls from clogging the queue. I then updated the ticket with Microsoft with these findings and that was when it was suggested that we look into enabling "CONFERENCE MODE" in the call queue. After a full 6 WEEKS of running in a degraded mode, I'm glad to say that it appears to have solved the problem.

What really puts a bee in my bonnet is the poor customer service from Microsoft. It seems as though they needed everything from us. The logs, the test calls, everything. As the platform owner, they should have visibility of the entire call flow and be able to clearly see that it is the anonymous calls not being picked up. Instead of the support team taking ownership of the problem, it seems as though internal processes prevented them from escalating to other teams effectively and when our ticket as with engineering, they were more interested in seeing how they could palm the problem off to someone else. In the end, the problem was solved but through OUR OWN PERSEVERANCE and ongoing testing and trial and error to eventually isolate the exact cause and reporting it to Microsoft rather than support actually putting on the customer service hat and actually help with proper investigation of the issue.

Microsoft, as a US$2.3tn+ business and only getting bigger, you can do better.