Should an organization need to deploy QoS in their environment for Teams, you’ll need to push settings out to your clients. Intune is the way to go, unless you’re still in the Active Directory phase of things and using Group Policy.
Well, there’s no point in me explaining how to do this, as Edgar Avellan has already done everything:
Now, a couple of caveats. First, I’ve long been a fan of NOT configuring QoS unless you are having call quality issues and can see issues in the Call Quality Dashboard or your network gear. Why not?
Most modern networks have more than enough bandwidth. QoS only helps when their is congestion.
There’s no QoS on the Internet. Only on your LAN/WAN.
You need to control the endpoint – byod devices won’t get prioritized
Okay, not 100% true. You could have your network gear mark traffic based on the source port number. However, this WILL lead to non-Teams traffic being marked. Marking the traffic on the client usually means that you can specific the executable name “ms-teams.exe” to avoid this. You will, however, need to use this approach to classify and tag traffic that isn’t generated from your managed endpoints:
Do you have a plan for your wifi? How much of your traffic in your offices is connected wirelessly vs wired?
Do you have a plan for marking inbound traffic? You need a firewall – or a router just past it – that can apply DSCP tags, as the traffic inbound from the Internet won’t have them. Otherwise, you’re only tagging outbound traffic.
What about non-Windows devices: web clients, Mac clients, and smart phones? Do you have control over these devices, and the ability to manage and monitor?
How about VPNs, SASE, ZTNA? What impact do they have on your DSCP markings? Do you enforce “always on”, so that traffic from a machine on your LAN in your office is immediately tunnelled out to the VPN/SASE/ETC device, even if it you’re communicating with someone who is also on your LAN in one of your offices?
If you’re thinking of doing QoS, your first step is to find evidence that says you need to do it (and user complaints about bad calls aren’t sufficient here). Then, plan, plan, plan, plan! Implementation and operations are significantly bigger that they appear at first glance.
There are a handful of license types for Microsoft Teams voice functionality. This seems painful, but really, it’s to your benefit – the licenses are “bundles” of features that you need for a specific function: user, auto attendant, shared lunchroom phone, etc. So, let’s dive in.
Throughout, I’ll use the full name “Microsoft Teams Room Pro” that you’d expect to see in the licensing tab of M365 Admin Center. I don’t stick formal names, but it feels like I should here if helping you find the right license.
Update: some name changes (surprise!) so I’ve updated this post. Update2: Where you see “E5”, that same bit applies to E7.
Microsoft Teams Phone Standard
This one used to be Cloud PBX, then Phone System. It’s what gives your Teams client a dial pad, the ability to dial out and receive calls from the PBX, and a bunch of functions you’d find in a phone system – caller ID, hold music, transfer, etc. Without this license, you can only do Teams-to-Teams voice chats and meetings.
This license is included in a number of “bundles” that I spoke of. It is included in E5/A5/G5, Shared Space, Resource Account, Microsoft Teams Rooms Pro. It is not included in E3/A3/G3 and below. If you’re running 3’s as your main license and adding Teams voice functionality, it might be time to consider bumping up to 5 (and 7!).
Calling Plans
These are really a family of licenses, they get you a phone number and dial tone from Microsoft. That last bit is important. This is “Microsoft the telco, like AT&T”, not “Microsoft the company that wrote Teams”. I’m not saying here that Microsoft is two companies, I’m only trying to demonstrate that Calling Plans are a “telco” thing and not a “Teams software” thing. Calling plans come in “minutes per user/month/country”, as well as pay as you go.
If you are using Operator Connect or Direct Routing, you do not need anything in the Calling Plan family of licenses.
Microsoft Teams Shared Space
These used to be called Shared Device, and CAP or Common Area Phone before that. From the voice perspective, this is a phone that isn’t assigned to a user. Rather, it’s assigned to a place or a role, eg “Lunch Room”, “Reception Courtesy”, “Duty Chief”. It also applies to a host of other things, mostly around Microsoft Places.
Microsoft Teams Phone Resource Account
This license solves the problem of “I have an Auto Attendant, how do I assign it a phone number so people can call it? And how do I assign it a UPN so that my Teams users can click-to-call it in a Teams-to-Teams call”. Think of this as a special type of user license that is severely restricted. It can’t actually log on, it doesn’t get a mailbox or SharePoint or Intune or whatever. The sole purpose of a resource accounts is to plug a phone number and UPN into your auto attendant (or call queue, or other custom voice app) – nothing more.
A resource account is based on a user account. Microsoft had a choice: copy the user account code and massively customize it to do everything a resource account needs without a license, or craft a purpose-built license that takes care of that, without requiring the rewrite. They chose the latter. That license is the Microsoft Teams Resource Account license. It is the ONLY license that you should assign to a resource account other than adding something from the Calling Plan family, should you be using Microsoft Calling Plans for your dial tone & phone numbers. In Teams Admin Center, resource accounts have their own section apart from users. In PowerShell, you’ll mostly use “user” commandlets.
And on the plus side? The license is completely free. You obtain it the same way you do any other license, but it’s $0. You need one of these for each phone number or UPN that you want to use to enable an auto attendant, call queue, or voice app to receive phone calls. (Note: if you have an auto attendant that forwards the caller off to a call queue, but you do not want that call queue to be called directly, you need only license the auto attendant. The call queue cannot be called directly, nor does it appear in the directory in Teams).
Microsoft Teams Audio Conferencing
This license allows the user to create a Teams meeting that allows dial-in capabilities. This is old school dial-in to a conference bridge. Those who dial in do not require this license, only the meeting organizer. It also allows dial out from the meeting to a phone number to add them to the meeting. This is an add-on, but it feels like it’s bundled with an awful lot of other licenses.
Did I miss anything? Hit me up in the comments if you’d like me to add or clarify something.
No, they’re not, and yes this is the first time I’ve started a post with a meme.
What am I talking about? I was working with a customer recently who needed to configure Teams to play something other than the “spa tunes” default hold music. In particular, the scenario was a call that comes to a call queue, is answered by an agent, and is then transferred elsewhere.
Here’s the Call Queue “Greeting and music” configuration with “Music on hold”:
And here’s the Call hold settings, with hold music:
And looking at these two screenshots, it’s not immediately clear what music/audio file (it doesn’t have to be music!) applies where/when.
Here’s the flow. When the caller first hits the Call Queue, they will hear the “Greeting” in its entirety. Then, they are placed into the queue and will hear the “Music on hold” while agents’ phones ring. Once the agent answers and begins the transfer process, the audio file from the “Call hold section” comes into play. That’s because the first part of a call transfer is to put the caller on hold.
If the Call Queue settings page referred instead to “queue wait music” and the Call hold settings referred to “hold music”, I think this would be clearer. It could also be helpful if there were info/tips on each page that explain when that music/file would be played.
Teams emergency call notifications meet all of the requirements of Kari’s Law, but they’re not super flexible. Microsoft received a bunch of feedback on this, and have a great solution.
At the most basic level of notification, you send a Teams chat message to a group of people. You can then layer on conferencing those same people into the emergency call, with or without the ability to unmute themselves. The users conferenced into the emergency call are the same list of users who receive the text notification, which isn’t great in some circumstances. For example, I would like to notify the intern sitting at the reception desk that an emergency call has been placed, but I would not want to conference them into a live emergency call. Anyone being conferenced in should be in the security department or similar, and not more “pedestrian” roles in the organization.
I recommend against allowing the ability to unmute, in most circumstances. The very last thing that a busy emergency call taker wants/needs is somebody unexpected talking over them as they’re trying to get the right response rolling. Unmute may be beneficial to a well-trained group of people who know to use it very selectively. The rest of us can just call 911 from a different phone, talk to a different call taker, and provide any additional information.
There’s also the option to conference in just one external phone number (which can also be just one internal number), with no method for them to unmute. This is a good option for a security desk where the staff don’t have Teams clients, or for a mobile phone.
For a more complex scenario – chat message to these people, email to these other people, conference in these Teams users, flash a light – there was no option in Teams that supported them. If an organization was using Direct Routing, some emergency service providers could offer additional services, and some people figured out how to have SBCs trigger a web hook when an emergency call was placed.
Microsoft has recently announced a preview of Graph API, with details available here. This API will provide the same information that Teams provides in its notifications, as well as to emergency services. As I become aware of services and apps that can consume this information, I’ll add their details to this post.
It is not an “either/or” choice of using the API or notifications built into Teams. You can easily configure both, using Teams for basic notifications, and the Graph API (and supporting applications) for richer flexibility.
If you have multiple SBCs (and trunks) in your Direct Routing deployment, you may have a scenario where a call comes in one trunk and then is automatically redirected out a different trunk by an Auto Attendant or Call Queue.
This could be because the destination is in a different country or rate center and you want to avoid long distance charges. I’ve also seen this in scenarios where a call comes in from the PSTN but then needs to be forwarded out a different trunk to a PBX or contact center, typically with an extension or private number that can be routed via the PSTN.
Resource Accounts that are under the hood of call queues and auto attendants need to have a voice routing policy assigned to them in order to send calls out a direct routing trunk. If that voice routing policy contains the SBC that was used for the inbound call, that SBC will automatically be selected for the outbound call, regardless of any priorities that you configure. If everything is configured properly, a REFER message will have the SBC (or something further upstream!) handle the forward and remove Teams from this loop.
However, if you need the call that came in via the first SBC to egress via the second SBC, you will need to create a voice routing policy that uses the second SBC and does NOT contain the first SBC. This voice routing policy gets assigned to the resource account for the call queue or auto attendant that is doing the forwarding.
If you are in a scenario where you have an auto attendant that is doing forwarding to numbers that must be reached via both of the SBCs, you will need to have one of the SBCs involved, or you’ll need configure the SBCs to route between each other and have Teams configured for direct routing to only the main SBC. Ideally, this would be your configuration anyway – Teams is not an SBC or session manager and should only be used as a last (hopefully temporary!) resort for oddball routing scenarios like this.
Failing that approach, you may be able to have the auto attendant or call forward to a Teams user and have that user set to call forward via the second SBC. You will need to test this, it’s entirely possible that there is/was something in my lab configuration and/or Teams call routing when I configured this, that does not apply to your scenario.
Teams Auto Attendants have a scheduling feature, which includes providing alternate call handling options during holidays. This isn’t well explained, and the flow within Teams Admin Center isn’t…. flowy. Once you understand a couple of key nuances, lightbulbs start going off.
If we have an Auto Attendant (AA) called “BumpinTheNetHQ” and want to setup Christmas and New Years holidays, we’ll see something like this in TAC:
Now if we click “+Add” we are prompted for a name for our holiday call setting, a spot to pick a Holiday, and then call handling things like a greeting and where to route/how to handle the call:
For the name of you holiday call setting, you should make it descriptive. In this case, I’m building the call flow for Christmas. I’ve included the “call flow” bit rather than just calling this Christmas, as I find it helps me keep all of the various uses of “Christmas” straight – especially if I’m working in PowerShell.
Note that you CAN edit this name, which is fantastic for tidying up to keep things a bit more understandable.
Here I’ve also assigned a “Holiday” called Christmas (more on that later!) and I’ve configured the Auto Attendant to speak “Ba Humbug!” before disconnecting the caller:
And if I click save, I am back at the Holiday call settings page:
I can click +Add and configure a New Years call flow as well:
Giving me this for Holiday Call Settings:
And this is “later”, so let’s talk about this Holiday drop down:
When you’re using this dropdown, you are presented with a list of ALL holidays configured in your Teams tenant, as well as an option to create a new Holiday:
Note that I’ve got the name of my Auto Attendant at the front of the Holiday name. That’s important to have as your different Auto Attendants for different departments may all have different schedules for the same holiday.
You can better administer Holidays through the Holiday section of the Voice menu on the left menu. Here we can see a list of all of the Holidays configured in Teams, plus the start of the dates that are configured for that Holiday. Note that you don’t get to see times here, and a long list of Holiday Dates may not fit on your screen.
Note that you CAN rename Holidays, just as with call settings.
We haven’t talked about times yet, or about multiple dates for a Holiday, so clicking on BumpinTheNetHQ Christmas gets us this:
I’ve defined Christmas for two years here, and I’ve also fiddled with the start time for Christmas 2024. If your organization (or department) closes early on Christmas eve, you could set the start time to 12/24/2024 and 2:00pm, for example. You can also cheat ahead and configure multiple years’ worth of holidays. Just be sure to put a reminder in your admin schedule/runbook/Outlook/whatever so that you remember to come back and update them (unless you plan on winning the lottery before they run out, in which case it’s not your problem!)
Eagle-eyed readers will have spotted the “BumpinTheNetHQ All Holidays” Holiday. Above, we have different call handling for our Christmas (Ba Humbug!) and New Years (the countdown message) Holidays. This is very flexible for different greetings and handling if that’s desired for your Holidays. However, if you don’t differentiate between Holidays with how they’re handled – say you just play a “we’re closed for the holiday, please leave a message and we’ll get back to you” greeting and dump the caller into voicemail for every Holiday – you would wind up having to manually duplicate (or dive into PowerShell) all of your call flow options. I’m using simple greetings and “disconnect” as an example here, but if you have a number of options “Press 1 for xxx, Press 2 for yyy…” that’s a lot of work to create and maintain.
Instead, you can build something like the “BumpInTheNet All Holidays” Holiday:
And use that with your single holiday call setting. Here we’ll just unceremoniously disconnect all callers on the above holidays:
The downside to this approach is that there is no description for each of the day/time entries in the Holiday. Some are obvious, some aren’t, especially if you are an international or multicultural organization.
Let’s just back to the “BumpIntheNetHQ” prefix on all of my holidays to reinforce that – every Auto Attendant will have an option to pick any existing Holiday that’s defined in a tenant. Starting the name of the Holiday with the name of the Auto Attendant that it applies to, or the department or team or whatever if there are multiple AAs that share the same exact Holiday set, will prevent a lot of grief.
If you’re just starting out with your Teams deployment, please spend some time building out a couple of Auto Attendants with a bunch of different Holiday structures so that you can understand how they work before you start deploying. You don’t need a phone number to call an Auto Attendant, you can call by name. You also don’t need to play a bunch of different menu options (unless you’re exploring those) – keep it simple and play a silly fun message to let you know where you wound up, and then just disconnect the call.
If you’re a visual/flow-chart type of person, here’s a visual of how these bits connect:
Or if you prefer the “one Holiday call settings, many Holiday date/time entries” approach:
My previous post dealt with having calls to a Teams number forwarded to a destination outside of Teams. What about if we want a number forwarded to a different destination that in our own Teams environment? You might want to do this for a departed employee to ensure calls to their number don’t get missed. You might merge two or more Auto Attendants in to one but still want all of the phone numbers to work. Easy peasy!
Fun fact, unassigned number rules work for calls from the PSTN, but also from within Teams. All your bases are covered, with the exception of a federated call or chat.
In Skype for Business this function was handled via the CsUnassignedNumber policies. In Teams, it’s handled by policies with the unwieldy name of CsTeamsUnassignedNumberTreatment.
While unassigned number handling can be configured in PowerShell if you’re doing a large number of rules, it’s otherwise easier to use TAC, especially for viewing what the rules are.
In TAC, you’ll find what you’re after under Voice, then “Routing rules”. That’s easy to overlook as “routing” is used in so many other places.
If you click Add, you get a pane that has these items:
Rather than throw any name and description in, plan out a bit of a naming standard. You’ll thank yourself later once you’ve got a few dozen rules. Something like “+1 425 8675309 to David” isn’t as meaningful as “1 435 8675309 to DSmith at Contoso.com” with a description of “1 425 8675309 used to belong to Jenny Jones. Ticket 342352” is much better. Note the inclusion of your ticket number so that you can find more details (and so you don’t have to write the full story here).
Evaluation order is next. The rules are evaluated from top to bottom, and evaluation order establishes where this rule will go. You can’t insert a rule by using an evalution order that’s identical to an existing one, you will need to pick an unused number. You can sort the rules after to wiggle everything in to the right spot.
And finally, we have the 4 rule types:
Advanced Setup lets you dive into Regex (more on step 2 in a bit!)
Number starting or ending with is a nicer version of Advanced, where the full capabilities of regex aren’t required. Just for fun, when you hit Okay and this rule hits the rules list, it’s in Regex format. Resistance is futile, you cannot escape Regex…
Phone number range is similar, and also generates Regex, which can get pretty gnarly for ranges:
And the final option is a single number, which is wonderfully, elegantly simple. Simple enough that I’ll skip the screenshot!
Step 2 is “then do this”, and your options are:
Greeting lets you play a greeting file (no text to speech here), and then the call is disconnected.
Your next option is “person in organization” which is pretty self explanatory: Jenny’s calls go to David, and that’s it.
The third option is a voice application, which is usually an Auto Attendant or Call Queue. If the first option of playing a greeting and disconnecting doesn’t work for you, you can use this option to send calls to an Auto Attendant, play a greeting (including text to speech) and then take some other action – let callers select from a menu of other options to handle their call.
And here’s something cool. The rules you build are processed in order, until there is a match. You can put very specific rules at the top, and less specific rules at the bottom, from the same range. For example +1 425 8675309 to send Jenny’s calls to David, and then +1 425 xxxxxxx to send that range of calls to an auto attendant.
But wait, there’s more! The unassigned numbers rules are the LAST thing that Teams does with a call before it sends back a “404 not found”. That means you can build a rule like +1 425 xxxxxxx to send all calls that hit it to an auto attendant. If Jenny still works for the organization, calls to +1 425 8675309 will reach Jenny and won’t ever make it to the unassigned rules. This is a great way to ensure that calls to an organization that may face large turnover are handled, without spending all day building and sorting rules.
There are a number of use cases for an organization to want to permanently forward calls to a Teams number, to a number outside of Teams. It could be that a function that used to be internal is now external, and there’s a desire not to change the number. An HR benefits hotline is one use I’ve see for this.
Your carrier may be able to setup a permanent forward for you, or if you’re using Direct Routing you may be able to setup the forward on an SBC. If you’re on Operator Connect your carrier may not offer this, and Microsoft does not offer it with Calling Plans. Additionally, these forwarding options would not have an object in the Teams directory that could be searched by name.
You could setup call forward settings in a Teams client, with the number assigned to the Teams user. That requires licensing, which may not be acceptable.
A free solution is to use a Call Queue or an Auto Attendant. The phone number gets associated with the Resource Account, which also populates in the Teams directory to allow dial by name. The Call Queue doesn’t need agents, and the exception handing is set to forward the call to an external number. Auto Attendants have an immediate forward option, which is a little cleaner (and more obvious when you’re viewing the configuration). I like Auto Attendants here for the ability to set up different destinations based on business/after-hours/holiday settings for those scenarios where this could be useful.
In both Auto Attendants and Call Queues, a greeting can be played before the message is forwarded.
You would create a Resource Account like this:
And then from M365 Admin Center add the free Resource Account license. Then grab a coffee (it can take a few minutes for the license application to take effect and show in Teams) come back to Teams Admin Center and select the Resource Account and assign the phone number.
The “Assigned to” part being blank is okay, we haven’t created our Auto Attendant yet. Let’s do that now and setup the call flow:
(and under Resource accounts, we can hook the Auto Attendant to the Resource Account we created).
Now calls to +1 425 555 1212 will be automatically forwarded to +1 425 867 5309. Additionally, internal calls by looking up HR Benefits Administration by name are possible:
and these will hit the Auto Attendant and be forwarded to +1 425 867 5309
Okay, apologies for huge post title, but I wanted to make sure that all the important bits were represented.
Teams has “Emergency Calling Policies” that handle location lookup settings and notifications, and “Emergency Call Routing Policies”, ECRPs. ECRPs establish Emergency calling masks and dial strings, along with a PSTN Usage which in turn points to a route to send emergency calls to. It might look something like this:
When this policy is assigned to a user OR to a site that a Teams client is in, this policy tells that client when 911 or 9911 are called by the user, Teams should call 911 vai the US-Emergency PSTN Usage.
The PSTN Usage is a Direct Routing configuration item that tells Teams where to route the emergency call. US-Emergency is where 911 calls go in the US, “DE-Emergency” might be the PSTN Usage for Germany for 112 calls. You wouldn’t want to mix those two up.
The Dial String and Dial Mask portion of the ECRP apply to ALL methods of PSTN access in Teams. That includes Direct Routing, and also Calling Plans and Operator Connect. CP and OC users will have emergency policies appropriate to their location/country set by the OC provider, or Microsoft in the case of Calling Plans. That includes dial strings and dial masks, as well as under-the-hood bits on call routing.
However, in my previous post I outlined changes to notifications for emergency calls that allowed different modalities and destinations to be configured for emergency calls to different Emergency dial strings. If you want “555” to be a number for security in a hospital with different notifications than when 911 is called, you need to first define 555 in an ECRP regardless of whether you’re using Direct Routing, Operator Connect, or Calling Plans. Then you can define the Emergency Calling Policy and appropriate notifications.
If you’re OC or CP and sticking with the basics of emergency calling and “911 is all we need”, you can’t escape needing to configure an ECRP if you are implementing Shared Calling. I mentioned above that OC and CP users have emergency policies pushed to their client by their OC provider or Microsoft (for CP). Well, if you are a shared calling user, you do not have a phone number assigned to you, and so you are not having the phone number and associated calling (and emergency calling) policies pushed to you. For regular calls, the Shared Calling number assigned to the Auto Attendant (it’s typically an Auto Attendant) handles call routing just fine – dump everything out to the carrier. For emergency calls, the Teams client needs to know the Emergency Dial Mask and Emergency Dial String. The only way for Shared Calling users to receive this configuration is via an ECRP. In the ECRP, you would NOT define a PSTN usage for OC and CP shared calling scenarios, but you would do so for DR scenarios. (The instructions on learn.microsoft.com are pretty good, should you venture into shared calling with OC or CP). This ECRP for OC and CP users is assigned to the user or it can be assigned to a site, maybe.
Note that if you have Direct Routing AND you want to use OC or CP for Shared Calling, things break a bit. Your OC and CP emergency calls should go to your OC provider or Microsoft (for CP). However, if you are also using DR and you’ve assigned a site-based ECRP that includes a DR PSTN Usage, that site-assigned ECRP takes precedence over the user-assigned CP and OC ECRPs. As a result, emergency calls from CP and OC users in that site will go to the DR provider. This could be very bad if that DR provide only accepts calls from their own numbers. It will only be somewhat bad if they’ll accept calls from any number but charge (typically three figures) to handle that call. Things might be okay if your OC provider is also your DR provider AND you talk to them and they’ll happily accept this scenario. Otherwise, avoid this scenario. Either don’t do site based ECRP, or use DR for your Shared Calling instead of CP and OC. AND, if you decide to not do site based ECRP and you are in the US, be aware that you are very likely in violation of emergency calling legislation that calls for automatic location determination… So, don’t do that, or hand this decision off to the corporate lawyers. (I’ll let you pick which is easier!)
Next up, I’ll show the configuration behind that scenario with the hospital using 555 for internal security notifications.
Teams Emergency Calling Policies (ECPs) fulfill some critical features. They have the setting to turn on or off “external location lookup mode”, which lets a user enter or confirm their address should they not be on a properly configured internal network, it allows a disclaimer to be displayed, and it determines who is notified when an emergency call is placed.
The emergency notification portion has just received an upgrade. There used to be only one notification option. This meant that IT staff using 933 to test emergency call routing would also be sending notifications, and it’s less than ideal to overwhelm notification recipients with testing.
Additionally, many countries have multiple emergency numbers – say one for police, one for fire, and one for ambulance – where different internal notification groups could be useful. For example, first aiders could be notified for calls to an ambulance but not a police scenario. I’ve also had organizations that wanted internal-only security numbers to generate internal notifications but otherwise not tie in to the 911 process. The scenario here was hospital security where someone may need security for access to a restricted area, or urgent security for an angry patient that was not yet a “get the police here” type of scenario.
The new ECP setup allows different notification groups and conference-call policies to be applied to a different “Emergency Dial String”, which is the emergency number that will be called. This is different than the emergency dial mask, which is the numbers that a user may enter to place a call. For example, the Emergency Dial String would be “911”. The Emergency Dial Mask numbers would be “911”,”9911″,”112″,”999″. Calling any of these four numbers will result in a call to 911. In the ECP notification settings, we define notifications for calls to 911, and not to the individual four mask numbers that could be dialed.
Here is an example configuration:
“Default” is what you will find for configurations that existed before this feature overhall. In North America that’s probably “911”. In a newly created ECP, you won’t see “default”.
Here I’ve set “artemis@torren.ca” to be notified via Teams chat when 222 is called. Should 123 be called, +14258675309 will be conferenced in – and here, no users will be send a Teams chat message.
This flexibility is a welcome addition to emergency calling in Teams!
I’ve used “dial string” and “dial mask” here, but haven’t covered where they’re defined. Adding a dial string number here alone won’t result in notifications. You will need to also configure an Emergency Call Routing Policy with the dial string(s) and dial mask(s) that you wish to use. This tells Teams to recognize these numbers as emergency calls, and for Direct Routing, tells Teams how to route those calls. (Note that Operator Connect and Calling Plan users don’t need to define emergency routes nor indicate that 911 and 933 are emergency numbers in North America for example… See my next post for way more details on this and Shared Calling in particular!)
Bump in the net 