Conference Entry Tones/Announcements

I was working a customer who wanted help setting up Conference entry tones and announcements. There isn’t actually a lot to setup:


These are found under Meetings > Conference Bridges > Bridge Settings.

The most important thing to understand is that these settings apply to dial-in users, and not those users who join conferences through a Teams client.

The first setting is to turn on or off entry/exit announcements. Typically, this is useful when a large number of people dial in to meetings, or when you want an audio indicator that someone has joined a meeting.

The second setting allows you to select Tones or name announcement. If you select the option for a name, callers are asked to record their name before they join the conference.

The PIN length setting establishes how long a user’s dial-in PIN needs to be. It’s important to note that this isn’t the phone lock/unlock PIN, nor is it a voicemail PIN (Cloud Voicemail at present, does not have PINs)

The last setting is straight forward – send an email to users if any of their dial-in settings change.

An important thing to note, is that the tone/name announcement is played when dialin users join a conference. If someone joins a conference via Teams client, no tone or name announcement is played. When a tone/name is played, all participants hear the tone. This means that if you are the conference organizer and have dialed in, you will only hear tones and announcements for other people who dial in. This can be less than ideal, however there is excellent roster functionality available in all Teams clients, including mobile.

And finally, note that these settings are not configurable on a per-meeting basis. They’re an all-or-none setting.

Update: It was announced in March 2020 that these settings will become configurable on a per-meeting basis!

Basic Calls with the MTR

Microsoft Teams Room Systems, MTRs, are excellent devices for joining Teams meetings. However, you’re not always going to be in a meeting when you need to make or receive a call on an MTR. It doesn’t always make sense to put a regular desk phone in the room or a speakerphone on the table. So what does the experience look like?

Receiving a call

Receiving a call is straightforward. First, you need to have a phone number assigned to the MTR, either through a Calling Plan or Direct Routing. Note that you don’t need to assign a phone number to your MTR if you’ll only use it in meetings. When the number is called, the device rings, and you hit the answer button and the call uses the MTR speakers and Microphone. This probably isn’t desirable if you’re in a meeting, so you can have a look at turning on Busy-on-busy.

Placing a call

Placing a call on an MTR is different than on a regular Teams phone. The major difference is that the call is placed via the audio conference bridge. This has two implications. First, an outbound call will consume minutes from your outbound conference minute pool. Second, the call will appear to be from the conference bridge number and not any DID that you’ve assigned to the MTR.

Teams Admin Roles

Teams, like SfB, has a concept of administrative roles. These roles control what you as an administrator can see and do. This helps secure the environment, and also simplifies things for the administrator. If you’re not in charge of Direct Routing, why even see that in the Teams admin center?

I didn’t understand the first post that tried to explain these roles, and while they’ve improved the explanations and role descriptions, I thought a more thorough explanation might help others out. Here’s what my investigate found.

The four roles and a brief outline of what they do are:

  • Teams Service Administrator. This role manages the Teams service, and also allows the creation and management of O365 Groups, which are a core foundation for Teams
  • Teams Communications Administrator. This role can manage call and meeting functionality within Teams.
  • Teams Communications Support Engineer. This role can manage communication issues within Teams by using advanced tools.
  • Teams Communications Support Specialist. This role can manage communication issues within Teams by using basic tools.

If you’re more of a visual learner, here is what the four roles would see in the Teams Admin Center:

Teams Service Admin…


Teams Communications Administrator


The Teams Communications Support Specialist and Teams Communications Support Engineer see the same thing in the menu:


However they see different things when they drill down into things. Here’s what the Teams Communications Support Specialist sees:


and here’s what the Teams Communication Support Engineer sees:


Note the highlight part, showing that the Engineer role sees more advanced details suitable for their role.

PowerShell tells us a similar story. Here, the Teams Communications Support Specialist has no access to PSTN or voice commands:

PowerShell Spec

While the Teams Service Admin does:


While these four roles don’t provide the same degree of flexibility and granularity (and complexity!) that was available in Skype for Business Server, you should ensure that you follow the principal of least privilege when assigning permissions to your support team.

Cool Tool – What is My Tenant ID

In an organization running O365, every once in a while you’ll need to jump through hoops inside O365 or Powershell to find your tenant ID. While it’s not that terrible, it’s certainly not speedy. If you’re a Microsoft Partner, you often need the Tenant ID for various Microsoft paperwork. It can be a hassle to collect this from your customer, or get credentials setup early enough in the engagement process with them. For you, this is a lifesaver!

The brilliant folks at ShareGate came up with Enter any domain name associated with your tenant – including the


and a few nanoseconds later:


Note that if your browser window is smallish, you may get an add that covers the ID and Copy to clipboard button, so hit maximize.

Where to put outside interface of an SBC

A frequent topic when I’m discussion SBC configuration for Teams with customers, is where the outside interface of the SBC should be located: the LAN, a DMZ, or “live” on the Internet. All of these options can work, so let’s take a look at the requirements and benefits of each.


Having the external interface of your SBC on your LAN can work, with a few important requirements. First, your physical external interface can’t be on the same subnet/vlan as your internal interface. This’ll cause all kinds of issues with traffic getting to the wrong place. You can have your logical internal and logical external interfaces share the same physical interface. You’ll need to also configure port ranges for signaling and media,  so there is some extra work. I don’t generally see this configuration for Teams, but do see it sometimes for Skype for Business server deployments where SfB is connecting to a PBX, or possible a telco via MPLS. Note that you can’t use one logical interface that is NATd sometimes and not NATd others – the SBC needs to insert your NATd IP into SIP packets, so you either NAT or you don’t, per logical interface. This configuration takes a lot of additional configuration, and it’s easy to mess up. I don’t recommend it if you can avoid it.

The DMZ/an “outside” subnet

This configuration involves having your Internal interface for connections to an existing PBX, and a second physical interface for connecting to Teams. This “outside” interface can be a VLAN or a firewall DMZ, anything that keeps it separate from internal traffic. Generally, the security guys insist on this being a DMZ connection and not a VLAN. You’ll need to setup 1:1 NAT on the firewall, or route public IPs into your environment for the SBC interface.

Another important step that’s regularly missed, is to disable any HTTP/HTTPS inspection, SIP helpers, SIP ALGs (Application Layer Gateways) or anything else that sounds, looks or smells like it wants to try and do something with the traffic. If your connection isn’t working, this is one of the first things that I would check. Fortinet, Cisco, Palo Alto, Juniper, all have these bits that need to be shut off. They simply don’t understand what the traffic is, and break it.

Live on the Internet

GASP! Who would ever connect an SBC live to the Internet? Well, lots of people. This is the simplest configuration that you can do. It doesn’t suffer from latency or HTTP/HTTPS/SIP “helpers”, firewall misconfigurations, or NAT issues. For those that say “it’s not secure”, well it sure is! Remember that an SBC is essentially a SIP firewall. It knows more about, and can do more things for SIP, than any general purpose/next generation firewall. SBCs typically include intrusion detection functions specific to SIP, and have robust host firewalls. Nobody is going to connect to the outside interface of your SBC on SSH, because you wouldn’t have it configured to do that, so there’s no need for a general purpose firewall to block SSH traffic. Okay, I picked on SSH here, but really, any port or protocol that aren’t SIP related.
It’s possible that your SBC will only be talking to a select few IPs (like an MS Teams configuration without Media Bypass), meaning that traffic from ANY other IP is simply dropped. While it’s possible that you’ll need to open things up – say if you turn on Media Bypass – the SBC is still going to inspect that traffic and ensure it’s valid. Again,  it’s a SIP firewall.


While the “Live on the Internet” configuration is a safe configuration with low administrative overhead, many security departments at organizations don’t understand enough about SBCs to understand that they are secure without a general purpose firewall in front of them. Typically this is a hill that I don’t want to die on, so I agree to having the SBC behind a firewall.

As much as possible, I avoid the one-interface solution “on the LAN” It requires more administrative effort, and is more confusion when you’re troubleshooting.

How emergency calling works from various deployment scenarios: CCE and DR

This is part III of a series of posts on the differences in emergency call handling between various deployment scenarios. Part I covers SfB Server (aka on-premises deployments). This post covers CCE and DR implementations.

Cloud Connector Edition, aka CCE, allows you to access your on-prem PSTN (and PBX) resources when a user is homed in Skype for Business Online. Likewise, Direct Routing provides the same access for Teams users. While CCE and DR are different technologies, how they behave with respect to emergency calling is the same.

This scenario is my least favorite for emergency calling, because it’s the least developed solution. When a user in these scenarios calls an emergency number, the call is simply directed toward the on-premises infrastructure. There is no location information included with the call, so the on-premises information has no idea how to handle the call.

There are two ways to deal with this. First, you can subscribe to a service from RedSky or West that will accept the call, have an operator determine the location, and send the call on to the correct PSAP. You would need to provide default emergency location information to the 3rd party handling these calls.

The second option would be to deploy on-premises solutions from these 3rd parties that would provide location information automatically. The only way this can current be accomplished is through switch interrogation, as there is no concept of the LIS database or location policies with online users. Alternatively, users can enter their location manually via an app on their laptop – but this doesn’t address deskphones. This is not a straight forward scenario, and it may not provide the solution you’re looking for. This is something that I would want to see a proof-of-concept for before I’d roll it out to an entire organization.

Note that simply routing calls out to your PSTN connection isn’t a good idea. There’s no way to ensure the call gets to the correct PSAP, and sending a call to the wrong PSAP will only cause delays in emergency response. You can read up on anticipated news from Microsoft about improving this situation in my earlier post.

Next up, we’ll sort out what happens when you have a mixed environment, with users in multiple scenarios.

How emergency calling works from various deployment scenarios: SfB Online and MS Teams with PSTN Calling

This is part II of a series of posts on the differences in emergency call handling between various deployment scenarios. Part I covers SfB Server (aka on-premises deployments).

If your user is homes in SfB Online or MS Teams and uses PSTN Calling, things are simpler but also have much less functionality. With PSTN Calling, Microsoft handles your emergency calls, based on static location information that you configure when you setup a user. When you place an emergency call, an operator answers and verifies your address, before directing the call to the appropriate PSAP. If you can’t speak, they will assume the address you’ve input is where you are at and forward the call to the PSAP for that location.

Emergency location information in the admin center of Office 365

You can add emergency location information in the admin center.

This scenario is clearly less than ideal, in that it’s neither automatic nor dynamic. It does, however, meet all e911 legislative requirements for the time being – the call is routed to the appropriate PSAP, and the user only needs to dial 911. In the United States, Kari’s Law comes into effect on Feb 16, 2020, and will require some additional capabilities, mainly an notification to a responsible party (reception, security desk) at the site of the caller. I cover what Microsoft is/needs to do in this regards in another post.

If you’re wondering why you need to bother with inputting the emergency locations if an operator answers each call, there are two reasons. One, it’s easier for the operator to read the address and have you confirm it versus you having to know it (or find it, if you’re not in your usual office). Two, it’s needed for the scenario where you can speak.

Next post, we’ll cover Cloud Connector Edition (CCE) and Direct Routing, where your online user gets PSTN service from on-premises.

Teams, e911 dynamic locations, and Location Based Routing

Two features that have been noticeably missing from Microsoft Teams are LBR (Location Based Routing) and dynamic location support for e911. Both have been available for on-prem deployments since the days of Lync. With this announcement LBR is now in preview and is expected to be generally available by the end of Q1.

What is LBR
In Skype for Business, users are assigned a voice policy. That policy links usages and routes. Together, these determine whether the user is permitted to call a number, and what path through the system the call will take. If William from New York is in his office and calls a customer down the street, that call will travel through the SfB system and exit to the PSTN in New York. If William travels to Los Angeles and calls that same customer, the call will flow back to the New York office (via the WAN if William is on the corporate network, otherwise via the Internet and Edge server) and will exit to the PSTN in New York.

In some countries, this type of routing isn’t permitted. When William is in Los Angeles, the call to his customer in New York must flow via the PSTN. There may also be restrictions on when you can blend PSTN and SIP calls in a conference. For example, you may be able to have PSTN callers join a SfB meeting, but only from one location. Thus, instead of call routing being done via the policies assigned to the user, we have Location Based Routing – the call routing is determined by the location of the caller.

In SfB, configuring LBR meant entering your IP subnets and assigning them to sites. Each site would then be configured to route PSTN calls via a particular gateway. Further policies within SfB would do things like block two PSTN sites from joining a conference.

The challenge in trying to build something like LBR in Teams versus in SfB comes down to the uniqueness of the IP address, which is used to establish the users location. In SfB, your office and favorite coffee shop might share the same IP subnet, however SfB knew if you were on the corporate network or not based on whether your client was connected directly to your Front-End pool, or was connecting via the Edge pool.

With Teams, the Edge and Front-End infrastructure isn’t there to help disambiguate the subnet that a user is on. Reading through the LBR documentation we can see a new cmdlet


This cmdlet lets you define your external IP address and assign them to your tenant. For example

New-CsTenantTrustedIPAddress -IPAddress -MaskBits 30 -Description “HQ Internet”

When your Teams client or device traverses a NAT firewall and has a matching public IP, the tenant now knows that this Teams client/device is on an internal network, and it can apply LBR according to the internal subnets and sites that you’ve defined.

What about e911?

Emergency calling (e911) and LBR both require the same underlying technology to be able to identify a user’s location. With this basic foundation in place, we can likely expect to see subnet-based location policies for e911 soon. There’s still some additional work to be done, as at a minimum Teams will need to provide for masking/translating a user’s DID and replacing it with a number that’s unique to the location of the user when 911 is called.Subnets may not meet legal requirements for the granularity of the location that’s reported. In Skype for Business Server, there’s the LIS (Location Information Service) database and the ability to embed PIDF-LO (
Presence Information Data Format Location Object) – aka your location – into SIP packets. These allows a client to be located by the access point, switch port, or switch that they’re connected to. SfB Server talks to external LIS databases that may be provided by vendors like West or Redsky, who take on the task of determining the users location and providing it to SfB.

None of this functionality exists in Teams yet, and it’s all required to do proper granular, dynamic location determination for emergency calling, natively in Teams.

LPE vs 3PIP vs Teams Native Phones

When OCS (or was it OCS 2007 R2?) first really featured enterprise voice and had deskphones, there were two types. One was the Tanjay, a futuristic, right angled obelisk of discomfort, and Aries.

Tanjay was interesting in that it would allow you to type your AD credentials on the touch screen, if you had the patience. It was a terrible interface for sure. More often than not, the USB “better together” over ethernet function was used. The receiver (the part you hold in your hand, for those that might not share this same terminology) was uncomfortable to hold in your hand, to press against your head, and to squish it between your head and should was agony. I screamed in terror when one customer advised me that they had found 50 of these units on sale on eBay or some other site for “cheap cheap cheap!”.

The Aries phone was less edgy (literally and figuratively), and the Polycom CX500 and CX600 series were perhaps the most deployed (and most loved) phones of the group. They worked well, felt comfortable, had enough features without being rocketships, and just worked.

Both Tanjay and Aries devices are part of Lync Phone Edition, or LPE, family of devices. The software for these devices was provided by Microsoft – as were some initial physical design – with the manufacture and support of the devices left to the manufacturer – Polycom, Aastra (since acquired by Mitel), and HP. I think it’s fair to say, however, that these devices were underspec and thus underpowered when it came to doing true enterprise level telephony. Specifically, the lack of ability to any soft of programming or customization, and the woeful response time for call setup in a response group.

Under the hood, the LPE devices ran Windows CE. Win CE (or wince, if you weren’t a fan) hasn’t been a desired or supported development platform for some time now. It doesn’t support TLS 1.2 and above, which means that it’s soon to be no longer supported with Office 365 (to be clear, this means “will no longer work” versus “don’t call us if something doesn’t work right, but it might be ok”), nor in most on-prem or hybrid environments with a basic understanding of the risks of running out-of-date security protocols like TLS 1.1.

LPE devices were managed natively through Skype for Business. Initially, this was via a HORRIBLE nightmare of SharePoint team services ugliness, then directly supposed through later versions of Lync/SfB. I should clarify that by “Managed”, I mean chunky and clunky firmware update processes that were about as graceful as an elephant on figure skates. Reporting was iffy, and embarrassing, to be honest.

Rewinding a few years, we saw the introduction of 3PIP, or 3rd Party IP Phone, in late 2011 . These devices didn’t run the Microsoft provided Win CE software, or run the Microsoft dictated hardware under the hood. Instead, Microsoft provided a framework for IP Phone vendors to develop their own devices that would be certified to function with Lync and then Skype for Business. These devices offered a much increased level of customization, were faster, and with a number of different manufacturers producing a number of different models, 3PIP provided more than an adequate spectrum of devices for your telephony pleasure.

3PIP phones can mostly be managed the same as LPE devices, or instead you could (and should) manage them through the manufacturers management software. This approach can be hit and miss. For the ability to configure all kinds of functionality on the devices from a central platform, we give two thumbs up. For those who had to suffer with multiple vendors, and thus multiple management servers and differing feature sets, feature support, and ability to not hate your job, we are obliged to give two thumbs down, and more if we could.

With the introduction of MS Teams, we’re about to see the introduction of phones that again run Microsoft provided code, like the LPE, on vendor provided devices. The really interesting part here, is that the platform for this code is Android. Yup – the platform for “Microsoft Teams” phones is Android. Microsoft had indeed changed!

When it comes to Microsoft phone systems online, there may be some gotchas. First, LPE is soon to be out of the picture. It’s unrealistic to update the decade old software on the decade old hardware to support modern encryption and provide user experience that feels good and doesn’t involve smashing the device with a hammer.

Next up, let’s talk about 3PIP. The 3PIP devices all talk SIP, and work very well natively with Skype for Business – online and on-premises. When it comes to MS Teams support, you can expect basic phone functionality, but not much more than that. 3PIP devices run SIP, and MS Teams runs MNP24 with SIP for backward compatability. 3PIP devices are connecting to MS Teams through a gateway for Teams connectivity. There will be some MS Teams functions that will likely never reach these devices. Specifically, modern portal device management, media bypass (Teams, not SfB Server media bypass), and less mainstream calling features like call park/retrieve.

And now on to MS Teams devices. These are the future of the Microsoft phone product line, including desktop phones, conference room phones (“starfish”), and for some room system devices. I expect lots of feature growth here, including when beefier hardware is needed – this is just a Teams app running on Android, which is a much more agile platform than the legacy days of Win CE.

The moral of this post, is that you should avoid LPE devices at all costs, including for on-prem (how long until the OS/Skype for Business Server app no longer support that laughable “security” that TLS 1.1 and below provide?). 3PIP devices are great, but going forward I be cautious. While they’ll work with SfB and SfBO and MS Teams, the fact that they connect via a gateway to MS Teams and have limited MS Teams modern portal support means that some caution is warranted. Make sure that they’ll be able to do what you require in terms of functionality, but also management now and in the future.

Branch Offices in Hybrid and Online Environments

In my previous two posts, I’ve covered branch office solutions including the SBA and the alternatives. No discussion on branch offices could be called complete without including hybrid environments.

The hybrid conversation is the same as on-prem when your user is homed on-prem and not online. As soon as your user is homed online, you have two seperate considerations

  1. User connectivity to the Cloud for all functions but PSTN
  2. Cloud connectivity to Cloud Connector Edition (CCE), Direct Routing (DR), or On-Premises Call Handling (OPCH)

For the first point, local Internet is what Microsoft recommends. Recall from earlier posts that you can use your router/firewall to direct O365 traffic out locally, and send all other traffic across a WAN, if that’s what your organization requires. If this Internet connection fails, your options are to route across the WAN, a 2nd Internet connection, mobile clients with LTE, or head elsewhere to work.

For the second point, things can get a bit more complex. The routing and high-availability of CCE, OPCH, and DR varies. Other factors will be centralized PSTN breakout vs a more localized approach – you’re more likely to have a business class or redundant connection for a centralized service than if you have distributed services.

Cloud Branches

One common solution that I see a lot of, is a hybrid scenario with branch office users hosted online, and main office users hosted in the on-prem pools. This eliminates the cost and administrative overhead of running branch office solutions, while keeping some infrastructure around for financial, compliance, interoperability with other services/devices and other reasons. Cloud-homed branches are also a great stepping off point when you’re moving a larger organization to a pure online environment.

Pure Cloud Considerations

At this point it shouldn’t be surprising to you that there really aren’t any new or unique considerations for branch offices when your entire organization is cloud based. From a branch office perspective, there’s no local infrastructure different versus hybrid scenarios.

Edge Cases and Wrap-up

In the past couple of posts, I’ve covered branch office considerations for high-availability. The range from SBAs, redundant WANs, redundant Internet, full pools, and more. While comprehensive, I didn’t cover every use case. When considering the solutions that best apply to you, draw up a simplified map of your environment, get a bunch of copies of it, and have at them with a red pen to indicate failure points. Work through these outages using your most important use cases to establish what works, what’s limited or hobbled, and what’s entirely broken. If a scenario doesn’t work for your use cases, put it aside.

You’ll now have two piles – works for me, and doesn’t work for me. Next, review the scenarios that do work, and establish which one best fits your business needs, including pricing. If the mighty dollar sign knocks all of these scenarios out of contention, you now need to sort through the “doesn’t work” scenarios, and work through them to find “the best of the worst” that does the best job of fitting your business needs and budget.