My first experience with switching a user from an existing calling plan in Microsoft Teams to Direct Routing did not go as planned. Not at all. I’ll walk you through what I did…and what I did wrong, as googling this particular error didn’t really lead me to the answer!
I seemingly had everything right – I followed the Configure Direct Routing documents to the T, and to switch the user over, I removed their calling plan, and then used powershell to add the ONPREMURI property (aka the user’s phone number) in E.164 format with the tel: prefix to the Teams user. I have the SBC all set up and outbound calls are working fine, yet inbound calls don’t seem to be working, as I’m getting a “404 Not Found” reply to the SBC invites in the SIP traces.
Initial research led me to a lot of posts regarding this problem with autoattendant numbers, not user numbers, and some people claim to have had to wait 5-10+ days for settings to take effect. I started to wonder if part of that delay is really just how long it takes the Teams client to pick up the settings, and whether simply having the user sign out and back in updates it quicker. I later found it indeed helped; once you assign a phone number via ONPREMURI, signing out and back in picked it up fairly quickly, although YMMV.
Since I didn’t see nearly any posts about this problem affecting user accounts, this leads me to believe I did something wrong, or at least wrong-ish. I re-read the Planning Direct Routing documents many times, and engaging the SBC’s tech support pointed out that the domain I used for the SBC is not the same as the user’s primary domain. Could that really be it? While some IT folks think they know the answers, I’ve been humbled enough that I’ll entertain any feasible answers, so let’s look into it…
First, in the planning document found here: (https://docs.microsoft.com/en-us/microsoftteams/direct-routing-plan#sbc-domain-names), I found the following statement:
It is possible that a company might have several SIP address spaces in one tenant. For example, a company might have contoso.com as a SIP address space and fabrikam.com as the second SIP address space. Some users have address user@contoso.com and some users have address user@fabrikam.com.
The SBC only needs one FQDN and can service users from any address space in the paired tenant. For example, an SBC with the name sbc1.contoso.com can receive and send the PSTN traffic for users with addresses user@contoso.com and user@fabrikam.com as long as these SIP address spaces are registered in the same tenant.
Next, in this document on how to share an SBC amongst multiple tenants: https://docs.microsoft.com/en-us/microsoftteams/direct-routing-sbc-multiple-tenants, I found some distinctly important facts that weren’t in the planning guides:
When a call arrives at the Microsoft 365 or Office 365 Direct Routing interface, the interface uses the Contact header to find the tenant where the user should be looked up. Direct Routing does not use phone number lookup on the Invite, as some customers might have non-DID numbers that can overlap in several tenants. Therefore, the FQDN name in the Contact header is required to identify the exact tenant to look up the user by the phone number.
After you have registered a domain name, you need to activate it by adding at least one user with Phone System license and assigning a SIP address with the FQDN portion of the SIP address matching the created base domain. License can be revoked after the domain activation (it can take up to 24 hours).
I thought this may have been the issue; the domain in the FQDN I used for the SBC, while it was already registered to the tenant, has never had a phone-system-licensed user using that domain specifically. As such, the domain was likely never registered somewhere in the SIP front end for Teams. While I can’t say for sure this affected my actual problem at all, I did create a dummy user to make sure I dot all the Is and cross the Ts. The next day, I attempted to configure a couple other numbers for new users, which actually worked fine, and inbound calls from the SBC were fine. Okay, that proves the SBC config is good for inbound calling! What gives with my first user!
After some back and forth with the user, I found their Teams desktop client still showed their Teams number, and it also showed in sip traces on outbound calls too. That was likely why inbound calls wouldn’t work, Teams thought the user still had the MS Teams number despite adding the custom number in ONPREMURI.
As it turns out, while I did pull the user’s calling plan and set the ONPREMURI parameter, I did not remove their Teams number from their user account. (What threw me off, was that in the Teams Users admin panel, it showed the ONPREMURI number for the user!) As such, it kept that number instead of using the one I entered into the ONPREMURI property. To add insult to injury, when I noticed this and removed the (former) Teams number, it actually removed BOTH, as the user then had no number listed in the Teams “Users” admin panel. Interestingly outbound calls still worked, with either NULL or a random number showing up in caller ID.
So in the end, I was able to re-assign the proper number via the ONPREMURI property again using Powershell (set-csuser -identity user@domain.com -onpremuri tel:+15551212), and after a few minutes, I had the user sign out of Teams and back in, and within a matter of minutes, it picked up the proper number and inbound calling now worked. The important thing here, was likely the proper order of events for switching from calling plans to Direct Routing:
- Step 1: Remove MS Teams number from the user
(Teams Admin Panel > Voice > Phone Numbers) - Step 2: Remove calling plan license(s) from user account in O365/M365 admin panel
(Note that this is only the calling plan; you still need a phone system license to use Teams for PSTN calling. Also note that the Teams module will not let you set the ONPREMURI property without this step first.)- Update, once you remove the calling plan, keep using get-csonlineuser to see that enterprisevoiceenabled goes to false, before going to step 3. Doing so eliminates the possibility of this happening after you apply onpremuri.
- Update, once you remove the calling plan, keep using get-csonlineuser to see that enterprisevoiceenabled goes to false, before going to step 3. Doing so eliminates the possibility of this happening after you apply onpremuri.
- Step 3: Assign the custom phone number to the user using Powershell by using set-csuser to configure the ONPREMURI property. See this article for more info.
Again, while I had good luck with this working relatively quickly using the order of steps above (another number I switched worked in under 10 minutes from step 1 to step 3), you may find you do need to be patient and give Teams up to 24 hours for changes to take effect.
UPDATE 3-3-2021:
One more thing to note – I found that again with the timing of the change, that once you remove the calling plan license, some time is needed (for me its been 5-20 minutes) for that to take effect. You can generally apply the new phone number almost immediately after removing the plan, but what I found was that once the plan change “kicked in”, the EnterpriseVoiceEnabled and HostedVoicemail properties get changed to false, even if you apply them via set-csuser when adding the onpremuri. My new step is to wait some time to see these go to FALSE on their own before setting the onpremuri, so that you don’t have people unable to call after you actually have tested it working.
If you have any other tips/tricks to share, or a war story about dealing with Teams or Office365, feel free to leave a comment below!