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.

911 and Mobile Phones

In my previous post I talk about how e911 services can use ANI and ALI information to know where you’re calling from when you’re on an analog circuit. Now let’s consider what happens when you call from your mobile phone instead of an analog landline.

Mobile Challenges

When you call 911 from a mobile phone, several challenges arise when trying to determine your location. Since you could be just about anywhere, it cannot be assumed that you are at your home or “billing” address. Instead, the telco needs to sort out your location. There are two different location determinations that need to be made.

Routing your call to the correct PSAP

The telco needs to connect your emergency call to the correct PSAP. This could be a simple determination if you’re in the middle of a large geographic region service by one PSAP. It could be a losing cause if you’re near a jurisdictional boundary, especially if your mobile is connected to a tower in the neighbouring jurisdiction. Two neighbouring counties may know how to re-route your call if you wind up talking to the wrong PSAP, however that may be more complicated if national boundaries are involved.

Providing your location to first responders

Once the telco has routed your call to the (hopefully!) correct PSAP, the PSAP needs to know where you’re located so that first responders can be dispatched.

PSAPs and Pizza are not the same

John Oliver has a brilliant segment¬†on YouTube where they stand in a PSAP and order pizza using a smartphone app. The app knows exactly where they are. The PSAP call taker doesn’t get the same results.

Why the different results? When you use an app to order pizza, the app has full access to the location gizmos like GPS in your smartphone. Your mobile call to 911 doesn’t, since there’s no standards or protocols in place for your phone to report its location to the PSAP. The 911 infrastructure just isn’t advanced enough to receive that location information.

Instead, it’s up to the telco to try to establish your location. It does this by calculating the length of time it takes a signal from your phone to reach a cell tower. This tells the tower how far away from it you are, but does not give a reasonable direction. Assuming you are near multiple towers, up to 4 are used. More towers means better accuracy.

A tower will have a very rough idea of your direction. Most towers have 3 or 4 antennas pointing in different directions, and their coverage areas are far too broad to be of use.

Once the telco has calculated your latitude and longitude, this information needs to be provided to the PSAP. The methodology for this seems like a Rube Goldberg machine: the telco creates a fake phone number for you, called a Pseudo-ANI. It provides this Pseudo-ANI to the PSAP as your phone number. Then, the telco performs an emergency update of the ALI database with a Pseudo-ALI that contains your latitude, longitude, and as much civic address information as can be determined. The PSAP uses the Pseudo-ANI to lookup the Pseduo-ALI, and now they have a location for you. All of this takes time to determine, so there will a period where the PSAP doesn’t have an address for you. Typically the Telco has 45 seconds to populate the Psuedo-ALI, and must update it every 30 seconds.

Mobile 911 service is really a kludge to be “backward compatible” with exisitng 911 infrastructure designed for analog phones.

Here’s what the PSAP will see once the telco will see when the information is provided (my labels are in italics, and refer to the nearest coloured box):

PSAP terminalNext up, we’ll have a look at how VoIP Systems can use 3rd party “next generation” services and ugly workarounds to also provide location information to PSAPs.

And do make sure you watch that John Oliver segment, it’s great stuff.


911 Background and Basics

Emergency calling is a part of every SfB deployment I’m part of, and yet it seems to be an area that most people don’t have a good background on. This makes understanding capabilities and limitations a bit of a challenge. Over the next handful of posts, I’ll cover the background behind 911, some basics on how 911 works with boring analog home phones, traditional TDM business phones, mobiles, and then we’ll through SfB into the mix.

Let’s start by talking about an analog home phone, or a single business analog line like for a fax machine. When you sign up with your telco for this line, you provide them with an address for service, and that address is where the line terminates. There is no option for you to move the line, so the telco can build a large list of names, addresses, and phone numbers, and be very confident in the static nature of that list, and thus its accuracy.

I won’t address MLTS, or Multi-Line Telephone Systems, aka a traditional PBX connected to the telco via PRIs. For the purposes of how 911 works, they’re largely treated as a collection of virtual analog lines, and there’s not much different about how that’s handled – you assign locations to numbers, and the telco enters that information into their databases.

In a 911 (vs e911) scenario, when you call 911, no address or telephone number information is provided. The caller has to provide this information. Once your location is established, that operator has to transfer your call to the correct PSAP – Public Safety Answering Point – local to you. That’s never fun when you’re in distress, so in most regions of North America we’ve progressed to e911 – e for enhanced – where your information can be automatically passed on.

With e911, the address that you provided to the telco is put into a database along with your phone number. Now when you call 911, the telco can use this information to route you to the correct PSAP, and the operator at the PSAP can see your information on their screen. As a safety measure, they’ll almost always verify your address with you. When your number is automatically display at the PSAP, it’s referred to as the ANI, or Automatic Number Identification. . The PSAP then takes your ANI and performs a database lookup to retrieve the civic address. This is called the ALI, or Automatic Location Identification.

Though very similar, ANI and Caller ID aren’t the same thing. Caller ID is for customers and can be blocked. ANI is for telco use. You can block your Caller ID, you cannot block ANI.

This system works very well with static analog systems, where a pair of wires physically terminates at the address you provided. It falls apart completely when the phone becomes mobile, either VoIP or cellular. In my next post, we’ll consider how cellular/mobile e911 can work (and fail!) and why the pizza company knows more about your location than your PSAP.