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.
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.