I was a little surprised by how late I encountered this situation.
I had recently configured a client's O365 tenant for Teams Direct Routing (Teams DR). Prior to DR, few of the users were enabled for Microsoft Calling Plans & were utilizing telephony in this model. The client wanted to move away from Calling Plans as it was not a cost effective solution.
Post configuration, naturally, I tested my own account for calling capabilities and it worked fine for me. It worked well for a few others too which gave me a boost that the pilot had been going well. But ... ;-)
Issue
One of the user's for whom I had enabled for DR the same way I had enabled the rest, complained about telephony issues. These were the issues reported by him:
1) Outbound Call - Rings his personal cell however, the CLI (Calling Line Identification), basically the Teams Number (DID) did not appear. It rang as 'Anonymous'.
2) Inbound Call - PSTN Inbound from his cell towards the Teams client resulted in a fast drop. It never arrived on his Teams client.
My Assumption
Because I'd provisioned his account the same way as I'd done mine, I didn't run a thorough background check on his policies and contacted the telco. The SBC was hosted in carrier's network backbone & I had to rely on their analysis.
At this point of time - I assumed the DID must not have been ported over by the telco. However, I was told that the DID along with a full block of numbers was correctly activated on the SIP trunk.
What next ?
The carrier confirmed the call did progress over their backbone. At this time, I asked them to analyze the SIP traces for Outbound & Inbound calls.
Telco's Analysis
Outbound - Non-Working Logs (another user's)
'From' Header is being sent as 'anonymous'.
Comparing with my outbound call
'From' Header is being sent along with the DID assigned.
Inbound - On further questioning the telco about the incoming call made to the non-working user, we got to know Microsoft Teams sent back '404 User Not Found', to the telco's SBC.
What Does This Mean ?
For Teams this clearly meant the DID that I'd provisioned was somehow not set properly on the conflicting account. However, I had confirmed before that the 'OnPremLineURI' attribute was already set with the work number, for the account for which the issue was happening. Parameters like TenantDialPlan, OnlineVoiceRoutingPolicy were also set similar to my account.
I had overlooked a basic parameter which was different. Could you guess by now, which parameter (the hint is already in the title of the article) ?
Teams Direct Routing Diagnostics
Let's take a look at my approach here. The next thing I did was to run 'Direct Routing Diagnostics'. If you're unaware such a thing exists, I hope this blog is already helpful for you at this point.
This diagnostic appears if you progress to open a service request and search for 'Teams Direct Routing'. You might even not end up opening a service request with MSFT.
I fed the user's UPN for this issue appeared. It took about 30 seconds to run the diagnostic check.
It came back with the below result. 'No Phone Number was found for the user.'
But the number was clearly there as I could see from PowerShell and compared to my account. I ran the same diagnostic against my account. There were absolutely no issues.
At this point I had figured out that the problem was the way Microsoft understood the 'Phone Number Type' for my account v/s the account which had the problem.
My Account:
Phone Number Type - On Premises
Non-Working Account:
Phone Number Type - Online
Demystifying
The below screenshot is an output of my account first, followed by the non-working account.
You might observe for my account, the voice policy attribute shows as HybridVoice.
For the non-working account it shows as BusinessVoice.
For a Direct Routing user this attribute should always be HybridVoice.
As soon as I noticed the BusinessVoice value for the conflicted account, I immediately logged on to the O365 Admin Dashboard to take a look at the licenses for the conflicted account.
It appeared as below.
For my account it was E3 + Microsoft 365 Phone System only.
Fix
It seemed an AD security group was enforcing both these licenses and it was creating a conflict in O365. Removing the Calling Plans license disabled the EnterpriseVoiceEnabled parameter (it became false).
Just kept M365 Phone System license on the account and manually set EnterpriseVoiceEnabled to $true and tested, the call worked as it should.
In Outbound - CLI was observed.
In Inbound - Teams client rang.
Microsoft's Opinion
In a parallel discussion with Microsoft Support, I raised the below question:
If the voice policy is indeed BusinessVoice, why did the call branch out to the OnlinePSTNGateway (Direct Routes) even if Microsoft identified the PhoneNumber type to be 'Online' ? The call shouldn't have worked at all if Calling Plans took precedence.
The technician told me this has been reported earlier to MSFT as well in a few cases. They were unsure as well as to why this happens & there was no documentation on this matter too.
Lessons Learnt
This little issue costed me a full day. 2 hours effort was lost initially with telco support. They were helpful for sure, however, I should have first done due diligence within the Teams environment. We should always start with the basics of troubleshooting an issue.
Calling Plans and Direct Routing can't co-exist obviously & this was a gentle reminder ;)
Hope you liked the blogpost!
Comentários