If you need a “best effort” method to block external calls to specific numbers, but aren’t hugely concerned over whether the solution is perfect, there is an option that will work with Calling Plans, Direct Routing, and Operator Connect.

Teams Dial Plans normalize the number a user enters on the keypad (or clicks on), usually into E.164 format. This allows users to dial based on their habits versus adherence to the E164 format. For example, they might dial 425 555 1212 and Teams will normalize this into +14255551212 to actually place the call. We can take advantage of this for call blocking by creating dial plan normalization rules that translate the dialed number into something other than the proper E164 format.

For example, 425xxxxxxx might get translated into +11001234567. That number doesn’t exist under the number plan for the +1 country code, so the call will fail. (It’s technically invalid, there are no area codes beginning with “1” in the North American Numbering Plan. Yet anyway!).

If you build something like this out, note that the “test” field here won’t allow you to put a + in front. You’ll have to test without the + here, and then test with the + at the client level.

Notice that the rule has \+?1? in front of the condition. That will match a + or 1 if they’re present, but doesn’t require them to be there. This means that even if a user knows how to dial an E164 number, this method can still catch and block the call.

You could get trickier here and translate to an E164 number that belongs to one of your Teams endpoints, and users would wind up connecting to that Teams endpoint. You could use Teams Routing Rules to build a rule that would play a message to the caller if these numbers were dialed.

I did say above that this solution may not be bulletproof. It’s possible that a client may implement number normalization in such a manner that it won’t match on a number in E164 format, on the assumption that it’s already in E164 format so it does not need to be normalized.

This is also where I put on my consultant hat and talk about non-technical aspects. If you have a user who is routinely abusing your phone system, and there is not technical solution to the issue, you may need to implement non-technical measures – a trip to HR, a visit with the school principal, etc..

It’s common for an organization to want to restrict where a user or phone can call outside an organization, especially long distance tolled calls. There are a number of different ways to do this, with a variety of different administrative impacts.

If a user has calling plans, the first way would be to only license the account for domestic calling, versus domestic and international. If you do this, note that adding a Communications Credit license to the user will allow them to make international calls on a pay-as-you-go basis. You might want communications credits assigned to a Calling Plan user to allow them to continue to make outgoing calls once the “per user per month” pooled minutes expire. If that’s the case, you’ll need to implement an additional method discussed below.

Regardless of whether a user’s PSTN service is via Calling Plans, Operator Connect, or Direct Routing, you can restrict where they can call in Teams Admin Center:

Here, I can block outbound calling entirely with “Don’t allow”, permit international calling with “Any destination” or only to Karl’s own country/region with the middle option “In the same country or region as the organizer”.

The text here – specifically the word “organizer” – would lead you to believe that this is for dialout from meetings. However, it does also apply to PSTN calls Get-CsOnlineDialOutPolicy (SkypeForBusiness) | Microsoft Learn

Note that this restriction will apply regarding of Operator Connect, Direct Routing, or Calling Plans being the PSTN connectivity option for the user.

This isn’t a terribly granular capability. If you’re on Operator Connect, your operator may be able to do some extra screening for you. There are some other solutions that may work well, or at least well enough, for your scenario, in my next post.