About Torren

I'm a Microsoft Certified Solution Master for Communication, aka Skype for Business. As a consultant I work in all areas of SfB design, deployments, and support, with a particular focus on voice workloads, networking, and high availability.

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.