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.

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.

How emergency calling works from various deployment scenarios: SfB Server

At a recent user group meeting, an attendee asked about all of the various call flows for emergency calls, from Skype for Business Server, Skype for Business Online, hybrids, and Teams. Over the next couple of posts, I’ll cover how the various scenarios work. First up, Skype for Business server.

SfB Server has native emergency calling functionality, using Location Policies, Sites, and Subnets. You can use this functionality to override the caller ID (thus setting an ELIN, or Emergency Location Identification Number), and routing it out via the appropriate gateway. You can also turn on alerting via IM, though this doesn’t do a lot of good unless you go to the next step…

SfB Server also has a Location Information Service, or LIS. This service uses the BSSID (the access point and channel a device is connected to), subnet, switch port, or switch to location the endpoint. Additionally, you can integrate with 3rd party servers/services that perform this LIS role. Some of the 3rd party services may perform better if you need to get down to the switch/switchport level to determine a location. The various locations (ERL, or Emergency Response Location) are programmed by you into the LIS, and associated with the subnet/BSSID/switch/switchport data. Yeah, this is a LOT of work to keep up! You enter the location in a format called MSAG, or Master Street Address Guide. This is a strict format that helps avoid confusion, especially when you get into suite numbers, floor numbers, and things like “east”. I have seen addresses like “235 East Highway 16 West”. It’s important to get things in the right place!

Once SfB knows your location from the LIS process, it includes the address in PIDFLO (Presence Information Data Format Location Object) in the SIP header that it sends to the gateway. There are a couple of connectivity options here:

If you have a gateway with ELIN capability (and licenses), the gateway can use the PIDFLO to select an ELIN, then send the call via the PSTN to the PSAP. If the PSAP needs to call back, the ELIN gateway maintains the translation for 30 minutes (usually configurable if 30 minutes doesn’t work for you).

If you’re in multiple PSAP jurisdictions, you’ll need to have a SIP trunk PSTN service that covers these, or if you can’t get a SIP trunk that does that, or if you’re using PRIs, you may need to route the emergency call gateway to gateway within your organization to reach the gateway that is in the correct location. You can make these routing decisions based on the ELIN (oh, 425-123-xxxx is Redmond, so send the call to that gateway, then send it to 911). You can’t route using 911 as the destination address, so this can turn into a bit of a routing mess.

An emergency call goes from a user to SfB Servers to a gateway, then via the PSTN to the PSAP

Routing emergency calls is easy when you only have one site.

If you want to avoid the routing headaches just described, you can also use 3rd party solutions from companies like West and RedSky. They have the LIS systems described above, but can also handle the ELIN translation function, and add enhanced notification/alerting options. Both offer services where your emergency calls are sent to their response centers, and then routed to the appropriate PSAP. This routing takes place automatically if the information included (think PIDFLO) is valid and matches their records. If it’s not, an operator answers the calls, gathers location information, and sends the call to the appropriate PSAP.

SfB users in two sites place calls, via the same SfB Servers, but then to different PSAPs via different gateways and PSTN services

Emergency call routing is more complex with multiple sites and/or multiple PSTN services. You MUST route emergency calls to the correct PSAP!

When you use these services, you also gain the option to have your receptionist/security desk conferenced into the call. This may be listen-only, or they may be able to speak (listen only keeps the call taker at the PSAP from getting confused as to what’s going on at the scene… Call taking is stressful. Take the stress of a help desk employee trying to decipher a technology problem over the phone, and now add the pressure of time and safety.) The conference function allows the reception/security desk personnel to take action locally – send a security or first aid team to the location, evacuate the building, meet emergency responders to direct them to the site.

Next up, we’ll hop online and see what Skype for Business Online and MS Teams can do for us, when using PSTN Calling services from Microsoft.

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 https://techcommunity.microsoft.com/t5/Microsoft-Teams-Blog/Additional-Voice-Features-for-the-New-Year/ba-p/295062 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 https://docs.microsoft.com/en-us/microsoftteams/location-based-routing-configure-network-settings we can see a new cmdlet

New-CsTenantTrustedIPAddress

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

New-CsTenantTrustedIPAddress -IPAddress 198.51.100.0 -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.