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:

BridgeSettings

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 docs.microsoft.com 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…

TACServiceAdmin

Teams Communications Administrator

TACCommsAdmin

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

TACSpecEng

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

TACSpecWide

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

TACEng

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:

PowerShellServiceAdmin

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.

Call Queues – Who can be an agent

Call Queues are the modern, online version of SfB Response Groups. A call comes in to the organization, and is queued and distributed to “agents” based on a number of factors.

One question that I get often is “who can be an agent in a call queue?”

The short answer is that only users can be agents. This means that Common Area Phones and Meeting Rooms cannot be agents. Well, they can, if you license them as a user. However, if you take advantage of the lower priced CAP or MeetingRoom licenses, then they cannot be agents in a Call Queue.

There are some other restrictions.

If you’re using a Direct Routing number for your Call Queue, your agents must be Teams users. If you use a Calling Plan number, you can use Teams, Skype for Business Online, and Skype for Business Server users.

If you want Teams agents, the agents must be in Teams Only mode. Calls are only handled by Teams apps when a user is in Teams Only.

Bonus: SfB Server Response Groups only offered calls to desktop clients, not mobile. That’s awesome if you assume that everyone who might be an agent is permanently planted in a chair in front of a desk, but that’s not reality! Call Queues allow calls to be offered to users logged on to a number of different devices – including mobiles – check out this doc for details.

(Note: this post has been edited to update it with capabilities made available soon after publication date. While I don’t normally update past blogs with new information, I felt it made sense given the timelines involved.

Updates are coming fast and furious at times from Microsoft. If you have thoughts on revising historical posts (or not!) I’d love to hear from you – hit me up in the comment section or find me on twitter @bumpinthenet)

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 http://www.whatismytenantid.com. Enter any domain name associated with your tenant – including the .onmicrosoft.com:

Whatismytenantid

and a few nanoseconds later:

Whatismytenantid2

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.

Cool Tool – UCDialPlans

If you’ve ever had the need to build a Skype for Business (or Teams!) dial plan, or sort out the regex for a number range, http://www.ucdialplans.com is your friend.

All around good Canadian kid Ken Lasko has been running this site for years. Got PRIs and need to route 7 digits to the telco vs 10 when it’s a local call? No problem, that’s just a tick box to let the optimizer know that it needs to dip into telco databases and see what exchanges are in your calling area. Internal extensions, trunk codes (9 for an outside line) and more are available.

Working with Cisco or AudioCodes gear? It can do those, too. There’s just so much stuff here, you have to go check it out (and be sure to donate a few bucks so Ken can keep building the awesomeness):

Lasko

The site is well laid out and easily navigate by scrolling or the menu at the tab. Check it out, I’m sure you’ll find something useful there.

 

Cool Tool – Regex101

If you’re doing voice with Teams or Skype for Business, chances are good that you need to do regex. While some regex’s can get awfully complex, there are some basic ones that look like they should be easy, but are deceptively complex. If you’re writing your own regex, you should be testing it with at least these values:

  • The first number in the range
  • One less than the first number in the  range
  • The last number in the range
  • One more than the last number in the range
  • A number somewhere in the middle of the range

Well, that sounds like no fun at all if you have to place 5 test phone calls and check logs to make sure things worked. Sure SfB Server has some testing tools build into the control panel, but what about if you’re working on a Ribbon SBC or Microsoft Phone System?

Enter one of my favourite sites, http://www.regex101.com. Pop in your regular expression, enter your test value in the “test string” field, and if it turns green you’ve matched. On the right, you get a breakdown on the various elements in your regex, what each means, and if these individual bits match, and there’s a quick reference too – a great way to learn regex!

Here’s an example. The regex ^(12\d{2})$ is for the range 1200-1299, and I’m testing that 1299 is a match:

regex101

Pretty awesome stuff!

 

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.

The LAN

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.

Conclusion

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.