Apr 05 2021 02:20 PM
Apr 05 2021 02:20 PM
With new Calling experience in Microsoft Teams and Direct Route settings, incoming calls from on-premises PBX and Microsoft Teams shows "Spam Likely" in call history - even though caller ID is a valid 4-digit number.
This is working with Teams client that did not updated to new Calling experience. Is there a way to turn off "Spam Likely" in Teams via Policy?
Apr 07 2021 01:40 PM - edited Apr 07 2021 01:41 PM
I'd claim that this additional info comes with SIP from the PBX or PSTN provider as SIP Header From Display Name. Or you user contact object, saved in Outlook if it affects only a single user.
I think you cannot change this in Teams neither via Shell nor TAC.
You could check your SBC for Teams Direct Routing and configure message manipulations to remove this info in legit calls.
Or you might better ask your pstn sip trunk provider/pbx admin which is connected to your SBC to ask if they use some sort of spam call information tagging. Maybe your provider could turn it off on your pstn sip trunk. Otherwise you usually could do this on your SBC.
Apr 30 2021 12:19 PM
I have verified this and the SBC is not sending any special information. It seems MS Teams client only accepts E.164 format as calling number which is wrong because it should allow internal extensions not to be labeled as "Spam Likely" Microsoft needs to find a solution to this. Customers are not happy about it.@Erik365Online
May 01 2021 09:21 AM
@Wilson007please check out the Microsoft Teams specifications for SIP etc. There are requirements named which must be satisfied to make it work properly.
Phone System Direct Routing - Microsoft Teams | Microsoft Docs
The SIP sent to Teams should be "clean" and comply with the specifications. In my deployments with coexistence I always sent E.164 from a SBC to Teams an no shortend numbers.
For reverse number lookup, and correct displayed numbers for call backs you could configure a SBC contact lookup based on ldap/http or else depending on what your SBC is capable of. Furthermore, you could configure Teams dial plans for users to enable short dials, e.g. Site 1 3digits or else.
May 03 2021 06:57 AM
Well this was working just fine until "New calling experience" was rolled out in the latest Teams client version. You have to keep in mind that Direct Routing is not just meant to connect to the PSTN but also to be able to seamlessly communicate to on premise PBX systems which more often than not are not configured for E164 format. I use Cisco CUBE for most implementations which is very simple to configure and I do follow to the T the Cisco and Microsoft configuration guide so I'm not trying to reinvent the wheel here. What I need is for Microsoft to find a way to let 4 or 5 digits in the calling number come across the Teams client without any Spam Likely label which in my opinion is absurd. I know I can manipulate the digits in the CUBE and force an E164 number appear in the Teams client but that defeats the purpose because customers don't want to see the full number for their own business reasons. Believe me, I've tried persuading customers into E164 format but not all like the idea, specially when it interferes with business processes. Spam Likely labeling should be optional like a policy in my humble opinion. @Erik365Online
May 04 2021 05:29 AM
May 05 2021 10:35 AM
Aug 15 2021 01:04 AM
Is this still ongoing or could it be fixed with the Microsoft Support?
You might check the Teams Calling Policy to disable it now or later, did you already see and read that Microsoft plans to rollout spam call notifications for Teams which seems to be the "feature" you are already having and experiencing.
I wrote an article about it: https://erik365.blog/2021/08/15/microsoft-teams-spam-call-notifications/ also covering the Teams Calling Policy parameters to enable/disable it, e.g globally with Set-CsTeamsCallingPolicy -Identity Global -SpamFilteringEnabledType "Disabled"
Aug 24 2021 08:48 PM
Aug 29 2021 07:54 AM
Oct 22 2021 09:25 AM
Oct 24 2021 08:38 AM
@LaurieBeamish No, I have not noticed any update on this in the documentation or elsewhere.
Nov 15 2021 02:27 PM