The USA Government wants to know where your phones are. SRSLY! No joke!
Congress recently enacted new laws, and directed the FCC to make new rules, regarding the rapid relay of many phone device’s detailed location information to emergency dispatchers when you dial 911 through many types of business telephone systems. There are some specifics that have yet to be determined, but Kari’s Law requirements exist in 2020 and the requirements of RAY BAUM’S Act will begin to exist in 2021.
Yes, these public safety changes could save lives; but there are trade-offs, including increased operations expenses and decreased privacy of device location information.
Many lives saved with 911! Thank you first responders!
The goal of the new laws is to provide quick access, not to the world, but to first responders. The implicit understanding is that your private address information will never be released publicly – it is shared with the PSAP and the first responder only. However, consumers should be offered more choices, given the many modern threats to long-running database storage of private information – such as identity theft, doxxing, swatting, and the like. These are real problems and any reader who agrees, or just thinks twice about enabling “Location Services” on their cell phones for privacy reasons, should find value in reading further. (Not necessarily because “Location Services” is always accurate – sometimes the PSAP might only get information on the cell phone tower location and not the phone itself. While location information from mobile devices is getting better, it is far from a sure thing.)
These issues will be tackled in this FAQ and mixed in with some helpful information for the DIYer PBXer.
For some background, please click back to the FAQ post from January 2020 about some new nationwide changes coming to 911. Since then, many more states got on board as well; in Colorado, the Legislature copy-pasta’d some pointers to large portions of the Federal stuff, and then added some new local carrots-and-sticks. Also, per line taxes/fees/surcharges are going up on 911 services in Colorado, but that is subject for another FAQ post – check your phone bill!
Over the next couple of years, these new interventions will affect lots of both new and existing phone systems throughout the US.
Your business, non-profit, etc., may be affected if you do any sort of outbound phone calling across your network eg. hardware desk phones, laptop software phones, some smartphone apps, and (possibly) other communication tools that only look like telephones if you view them from certain angles; even if you just use your PBX to order the occasional pizza delivery by way of traditional MLTS-PSTN audio services.
If you do fall into this category, then new emergency calling rules such as those regarding the area/location of the caller during 911 calls, could mean major increases needed in budgets for several departments, including but not limited to: IT, Compliance, Security, Safety, HR, and WFH Management teams. This could be particularly burdensome if your upstream telco/provider requires station-level location information, such as one new DID per device, which is all that some providers are currently offering (due to it being very profitable, with few competitors yet innovating in this space.)
Getting better location info automatically relayed to 911 operators when they need it is perhaps the biggest new telephony challenge for managers of WFH users in 2021!
Big change is coming!
Here’s the TL;DR timeline of TODO items for busy IT admins of New and/or Existing MLTS:
|Due Date||17 Feb 20||6 Jan 21||6 Jan 22|
|- HQ desk phone||E||E|
|- HQ wireless||E|
N = required on New systems.
E = required on Existing systems.
- New systems a must - let’s do it on more though - H/T for the link!
- For new systems installed after February 16th, 2020, you need to allow your MLTS to “P”arse 911 when dialed directly just like that. No more extra 9 or other prefix/suffix.
9911and 911#are no good without plain 911 as well!
- And get rid of that “eleven” key while you are in there (that’s a joke. 🤦)
Alert 🚨 📯 ✉️
- For new systems installed after February 16th, 2020, you need to configure your MLTS to “A”lert somebody else in your organization, preferably on-site, or another organization, whenever 911 is dialed.
- Only required “if the system is able to be configured to provide the notification without an improvement to the hardware or software of the system”.
- You need to “L”ocate the MLTS-connected device (ie. the phone) that is being used to call 911, in Meat Space and (very often) in Dial Space.
- Meat Space “L”ocate: This is where you need physical help right now (“please send the meat wagon to XYZ street, room 123.”) Many older rules talk about Automatic Location Information (ALI) while newer rules refer to this concept as Dispatchable Location (DL), and other vendor documents reference terms such as Emergency Response Locations (ERL). You may find that there are lots of internal company discussions needed to find the best path here because the answers are unique to each entity and may need to be drilled-down to individual users and devices across disparate, sometimes changing geographies.
- Dial Space “L”ocate: The Emergency Location Identifier Number (ELIN) – also know as the Caller ID number – used on the 911 call that the Public Safety Answering Point (PSAP - the 911 call taker, or, 911 operator) can dial back to reach the caller (and/or other users near the caller) if they get disconnected on the original call. When dialed, this number must primarily be answered by human beings and not answering machines or catch-all Interactive Voice Response (IVR) systems that leave the PSAP folks wondering how to connect back to you.
The “L”ocate portion is probably the most burdensome step.
For larger businesses, or any business with remote WFHomers, the updated “L”ocate requirements could take several time consuming steps to satisfy, along with presenting new on-going data security, integrity and maintenance tasks, long into the future.
Some parts of the Meat Space “L”ocate questions can probably be answered best by your existing telco or whomever they subcontract the work to. Reaching out to your account sales reps to discuss new and updated contracts for better “L”ocate of ELINs/TNs/DIDs for HeadQuarters, Branches, and WFHers is a Very Good Idea right now. ⏰ Because in 2021, barring repeal or other nullification of the laws, many many existing systems with fixed on-prem devices such as HQ desk phones will be affected. And by 2022, the Meat Space and Dial Space “L”ocate questions need to be considered for all phones on your MLTS, including both on-premises and remote, such as those over VPNs and WANs eg. Work From Home users.
Remember: the goal is to get you the help you need as quickly as possible when you dial 911.
For some small businesses, with one phone number that rings everybody in the office, there might be just one Meat Space “L”ocate question to consider. Check your phone bill – the Street number and/or the Suite number may already be on file with the telco, and this might be exactly what the PSAP sees! If that location info looks granular enough, and you confirm this same info is what the PSAP sees on test 911 or 933 calls (make a test call to the non-emergency PSAP number first!) then the new “L”ocate requirements are potentially already satisfied (but you should still look into the “P”arse and “A”lert portions to help reduce risk in those areas!)
In more complex setups, for example, if you currently use one main number as your Caller ID number on all of your outbound calls – including 911 calls – and when you call that number back it goes right to your main company IVR – then you might want to make some improvements to your Dial Space “L”ocate configuration.
This can vary from install to install, but here is one very generic way to get the “L”ocate portion done on many different types of closed and open source PBX systems:
- Order new (possibly unlisted) phone numbers from the telephone company specifically for use as 911 call back numbers, one for each area/room/etc. in your building.
- Configure your PBX to route inbound calls to these numbers to ring either single phones or ring groups of phones in the same area.
- Configure your PBX to use these numbers as the outbound Emergency Caller ID numbers when users dial 911 from these phones.
Note that these steps come with some trade-offs, namely:
- Increased monthly expense of new telephone numbers. Shop around; Some SIP vendors are offering new 911 support options for less than one dollar per number per month. Your local fixed line T1 PRI provider might charge slightly more. Others let you keep your numbers and instead assign you new “L”ocate codes to suffix at the end of your Caller ID number before routing the call from your PBX to them.
- Increased spam calling to these telephone numbers. Where legal, consider shim IVRs to limit this spam eg. “thanks for calling xyz - this number uses privacy screening - to connect press 1” then proceed to ring the phone(s) only if the caller presses 1 (most robocall robots are not yet smart enough to press any buttons like that.)
- Increased confusion between caller and operator. The call back number seen at the PSAP might not be the phone number that the caller is used to working with. So if/when the operator tries to confirm the number, the caller might not understand what number is being used. This can be ameliorated with increased user training and handset stickers.
P - A - L
Parse - Alert - Locate
Penguin PBX Solutions can help you navigate the process, based on your specific needs, from interfacing with your IT team on suggested dial plan updates to reviewing technical telephone company contracts.
Or just Do It Yourself!
Please review the open source Always Be Conferencing (ABC) project from Penguin PBX Solutions for more advanced technical details. ABC can integrate easily with most newer Linux® setups running software such as ASTERISK® and/or FreePBX® *. ABC provides dial plan shortcuts for many “P”arse, “A”lert, and “L”ocate issues, along with detailed Examples and mini-HOWTO documentation, in a single text file that you can copy into your /etc/asterisk/ directory and get started testing within just a few minutes.
When talking to your telco, a sample spreadsheet to send them to ask about the “L”ocate processing details might look like this:
|Phone #||Addr. 1||Addr. 2||City||ST||Zip|
|303 555 0000||123 Main St.||Room 101||Denver||CO||80000|
|303 555 1111||123 Main St.||Laundry Room||Denver||CO||80000|
|303 555 2222||123 Main St.||Floor 2||Denver||CO||80000|
|303 555 3333||123 Main St.||Kitchen||Denver||CO||80000|
|303 555 4444||45 Pena Blvd.||Bldg. F||Denver||CO||81111|
|303 555 5555||777 Pearl St.||AP Dept.||Alma||CO||82222|
|303 555 6666||777 Pearl St.||Penguin Room||Alma||CO||82222|
|303 555 7777||Peak 8 Hwy||Apt. 21||Frisco||CO||83333|
|303 555 8888||Peak 8 Hwy||Apt. 42||Frisco||CO||83333|
|303 555 9999||999 Wheat Rd.||Horse Barn||Rye||CO||84444|
You may notice that this is (potentially) lots of new info you now need to share with the telco. It includes HeadQuarters (0000-3333), Branches (4444-6666), and Work From Home/Road listings (7777-9999).
Can your telco handle this info ?
Particularly the (possibly new) second address line ?
Many telcos outsource this increased information handling work to larger national 911 call processing outfits. Then your telco would send all of your 911 calls through these other entities over some type of internet Protocol network. These outfits can be in another State entirely, creating potential for more widespread and complicated outages of 911 than ever before. But the work continues, and there are many upsides to moving at least the nomadic VoiP and secondary fixed line traffic to these types of new upstream, aggregated systems. However, the case is weaker for primary fixed line migration away from the current systems curated over many previous years of more decentralized and distributed landline service as provided by the seasoned professionals at your local telephone company. In those older local scenarios, 911 works well and is very accurate.
Important: the “L”ocate info you store with the telco should be automatically shared with the PSAP agency. Usually that is only done at the time of the 911 call. With ABC, and some telcos, dynamic updates at the time of the call may be possible (cell phones try to do this, too.) But in theory, any phone number in the US can be pinged manually by any PSAP operator at any time for the phone’s currently stored Meat Space “L”ocate info. This awesome power comes with lots of responsibility; fortunately, there are some 4th Amendment protections to overcome in non-exigent circumstances to prevent abuse… Anyhow… that is maybe subject for another FAQ in the future…
PBX and MLTS users need to plan for device location updates that may affect their liberty, privacy and safety during emergency calling and remote Work From Home scenarios.
And your IT team might need to know where you are when Work From Homing, so that they can tell the phone company before you ever dial 911.
Below are some things that users might do to change their address. Please meet an employee named “Homer”, who is soon to be Work From Homering (doh!):
- Homer works 9-5 at the power plant and orders pizza for department lunches using his desk phone.
- One day, due to government over-reaction to novel diseases or some other hobgoblins, Homer is told to go home with his new work laptop running VPN client software and SIP software phone at same extension number as his desk phone.
- Homer moves around with the laptop, maybe to short-term rental in the mountains for increased Vitamin D and recreational opportunities.
- Homer is called back to work several weeks or months or years later.
Each step represents another change of address – a change in Meat Space “L”ocate information. The more rapid the changes, the more tedious the updates. Making these updates as seamless as possible is one of the design goals of Always Be Conferencing (ABC). The helpful IVR menus and other tools in ABC could help you automate more of the “L”ocate change process, or at least distribute the work amongst your users. New versions of ABC (currently in testing) include cloud/web API integration options you can try with several different telco vendors, for smoother end user experiences.
Back to Homer: if Homer does end up needing emergency help while WFHomering, do you really think somebody is going to open his laptop and use his soft phone to dial 911 ?
More than likely, people will first try to use their cell phones in emergencies – over 90% of all 911 calls in Denver come from cell phones. Even an out-of-contract cell phone can (usually) call 911! And often send GPS satellite info, too! Or, if the cell phones are on wifi due to lack of cellular coverage, then most telcos already sort out the “L”ocate question by allowing you access to your phone’s advanced settings where you can manually update your address, and, of course, keep updating it every time you move. So this procedure can become part of the responsibility of users of your Wifi calling solution - maybe send some reminders to your users to let them know.
The practical effect of increased costs to business due to compliance in this area may result in actors seeking out lower-priced alternatives. If privacy is not much of your concern, and you want to save some money, then another option to consider is pre-loading your various addresses into some new national provider database system that sits outside your telco. Or, you might want to exert more control over your data, so your company might try out something like ABC, which can be configured to only reveal your “L”ocate info in the clear at the moment it is needed by your desk and soft phone users - similar to what cell phones do already on most 911 calls. Or, you could decide to adopt policies of cell phones only with no general purpose SIP soft phones on laptops anymore; or perhaps abandon the PSTN entirely for WFHers, as a way to signficantly reduce regulatory compliance burdens. Instead, maybe you’ll only be able to video chat on your laptop and never see a dial pad (so sad! ;)
Please note this is not legal advice - see disclaimers for some other important information about this site.
But do take the advice to work with your users, train them and test your systems. This is lots of change in the works.
UPDATES - December 2020…
Clarified several implementation timeline issues and requirements, including the required use of direct-to-human call-back numbers as Caller ID.
But digging deeper, you might argue that direct-to-human call-backs do not make sense in all situations, because when using the main company and/or IVR number as the call-back, the disconnected PSAP operator might hear pre-recorded “Thank you for calling ACME widgets…” and maybe they press 0 from that menu to reach your on-site front desk operator, who could then look-up where the call came from internally. Or at least the PSAP operator would know the company name.
Contrast this with a call-back to a human when the human does not answer the call-back, well, what information do you have then ? Potentially, if the number is un-published, because it only exists for 911 call-back purposes, or if the user never set up their voicemail, then the PSAP might have nothing to go on! The phone might just ring and ring, or go to generic voicemail prompts eg. “Please leave a message for 555-1234”. How is that faster/better for first responders than just using your main published business number that everybody in your company knows by heart ? Could users instead be trained with some stickers to just add their extension number to the information they relay to the PSAP ? Maybe instead of relying on sweeping nationwide mandates, some states could experiment more in this area by allowing the market to improve the process ?
Asking questions… this is the way.