Emergency Services and the Remote Worker

Employee safety is the primary goal of every employer. To accomplish that goal, as well as be compliant with new Federal legislation that recently went into effect (i.e. Kari’s Law and the pending RAY BAUM’S Act §506), commercial enterprises have been scrambling to implement and deliver compliant services to their workforce. With the COVID-19 pandemic, millions of workers have been forced to suddenly shelter in place, or self-quarantine, and have found themselves operating in a remote environment, with little forethought or planning, especially for 911 calling from those devices.

IT administrators have had to scramble just to establish to set up basic connectivity, let alone advanced functionality as the pandemic has flushed many employees from their high-rise offices to their residences. This creates the dilemma of trying to maintain some sense of business flow while at the same time practicing the ever-important social distancing required to combat the spread of this virus.

While most businesses have had some form of remote working capability for workers for some time, often the solution may not have included actual telephony. Additionally, the bandwidth engineering estimates never considered voice and the mass amounts of simultaneous workers. Another issue is the system has never been really been put under a load test of this magnitude and demand as it has now.

For some employees, telephony is secondary. Their need is to just collaborate with each other. For this group, they can utilize teleconferencing  applications such as Zoom, Teams, WebEx, the Avaya Spaces solution (available free for 90 days), along with scores of others providing a virtual team or online meeting room. Most of these are fine internally, but fall short with basic telephony and calls to and from customers in the outside world.

Even while the push has clearly been to move to multimedia sessions, the phone is still an important part for some environments and verticals. For those, employees continue to require some form of remote solution from their PBX telephone system, and often a Contact Center. Many customers deliver this through an IP softphone or integration into the desktop such as the Avaya IX Workplace for Ocrana®, or in some cases, a physical IP telephone device, like the Avaya J179 SIP Phone connected back into the corporate environment though a Session Border Controller.

And this is where the problem begins. A Recipe for Disaster.

To a child or family member 911 is 911 on any phone.

Remember, even though it is at your home, your phone is connected to your corporate PBX telephone system on a virtual ‘extension cord’ that is miles long. The actual PSTN telephone lines are in the PBX at the address of where work is located, or worse, someplace in the cloud. But the number on your telephone is associated with the address of your office at work. These three ingredients can easily lead to disaster if you dial 911 from the work provided IP telephone in your home office, and the proper accommodations have not been put in place to deliver the proper address.

One of the great misnomers that exist out there, is that your telephone system can actually transmit the location of the person making a phone call to 911. Sorry – FALSE – IT CAN’T.

How does that work then? The current 911 network is fairly simplistic in how it works. Calls get routed to the local 911 center based on Caller ID (called Automatic Number Identification) and the install or billing address. See the problem?

What about answering your 911 calls yourself? Many THINK this is a good idea, but it’s actually NOT PERMITTED unless you are a Public Safety Answer Point. Are you? Find out for your self:

Through the magic of the Internet, we’re able remotely place a physical telephone miles or even states away from where the telephone company (and the 911 center for that matter) believes it’s located. This is where most people will just say, “I’ll just not use that phone for 911. I know better.”

While there may be a thread of truth in that, what about your family members? What about your mother or father that don’t really understand technology? What about your child, or the babysitter? Or what about anyone else who happens to be in your home where your ‘special phone’ is the closest phone when they need 911?

Don’t worry, all is not lost. As quickly as technology can break something as simple as dialing 911, there’s more technology that we can layer on top to correct the situation we’ve created. Today brand new NG911 technology exists in the network that will allow you to, provide the location of your device, let an administrator provision the location, or even have the device discover where you are using common forensic discovery tools. In any case, where you are can likely be determined in some form or another. This Youtube Video highlights the Location Discovery issue.

But, that is only half the problem.

Once the location is known, the call routing issue can be solved using a carrier based 911 solution known as a VoIP Positioning Center or VPC. The job of the VPC is similar to that of a long distance telephone company. Just like AT&T, Sprint, and MCI can route to your calls anywhere in the country, the 911 VPC has the same ability on a specialized 911 network.

The PBX simply routes all remote user calls to the VPC, with the location information, and the VPC takes care of getting the call to the right PSAP, and delivering location information. When a device registers as a phone, the location was discovered, and the routing entry is created for the VPC database.

In order to deal with the immediacy of the Coronavirus Pandemic, and the masses amounts of people headed home to work, Avaya has worked with our Select Partner, 911 Secure, LLC to provide a basic level of 911 service that can be deployed immediately with minimal expense. The service is called SecureNOW™ and until May 26th, they are offering this temporary static VPC routing service for remote users for only $0.25 per user per month. Location changes can be made, but are updated manually.

This is a scaled down solution of the Frost & Sullivan 2019 Best Practice Leadership Award winning SENTRY™ solution.

NO HARDWARE OR SOFTWARE IS REQUIRED ON PREM.

The SecureNOW™ Temporary Remote User 911 Service By: 911 Secure, LLC

A simple 911 call routing change is made in the PBX for Remote Users, redirecting them to a special 10-digit PSTN access number of the VPC service, and the routing database will terminate the call at any one of the ~6500 911 PSAPs in the US that corresponds to the home address of the user.

In the following video, I along with Brian Anderson, Director of Avaya Public Safety Solutions review the entire landscape and technology.

Follow me on Twitter @Fletch911
Want a solution and not just Hype?
Don’t just fill in a web form that puts you on a SPAM email list, for a FREE, NO OBLIGATION 911 Compliance Live interview Audit with a NG911 Subject Matter Expert CLICK HERE

Fixing 911 Overload

Every year, NENA – The National Emergency Number Association – estimates that there are over 240 million calls into 911 call centers (known as Public Safety Answer Points or PSAPs). A common problem among all PSAPs continues to be non-emergency calls arriving into the center on Their specialized 911 trunks that exist specifically for emergency calls. The quantity of these trunks is typically limited in each center and and the amount has been carefully engineered to handle the normal volume of 911 calls from the community served by that agency along with a few spares and diverse CO routing where available. The problem is that when they become flooded with non-emergency traffic, legitimate emergency calls could be blocked.

This design also makes the PSAP more susceptible to SWATTING and DDoS attacks by practically anyone and from anywhere. In some areas, emergency calls into a center that is busy may overflow to an adjacent PSAP. While this seems like a logical idea from a backup perspective, let’s examine the bigger picture here.

Not only does this expand the attack face from a SWATTING and DDoS perspective, it is actually quite useless unless there is a Mutual Aid and MOU agreement in place with the other agency. Without the proper authority and the radio comms infrastructure, as well as access to the CAD, there really isn’t much that those agencies can do other than answer the call and write down the information. They then need to figure out a way to get that incident to the agency that can provide service. Typically, if there is no access to the radio network of the adjacent community, or no visibility to the computer-aided dispatch or CAD system, there is little they can actually do with the information they have. Also, remember that if the call has overflowed to them in the first place, they might not even have a way of reaching the original agency using conventional methods, Where is the problem?

The Core Problem: Dedicated 911 Trunks

The existing 911 network in the US is dependent on specialized CAMA trunks. Queries for location use the Automatic Number Identification (ANI) received with the call to determine the location of the caller, and a direct peer-to-peer relationship exists between the PSAP and the local exchange carrier 911 Central Office using these single-purpose trunks.

Since these trunks are limited in number, when a non-emergency call arrives on an emergency trunk, that line becomes tied up for the duration of that call, even if the resource that handles the call is a non-emergency resource. This creates a traffic engineering problem, because now the number of trunks reserved to handle emergency calls are taking the additional non-emergency traffic, something that totally Skews the Erlang calculations used to engineer the number of circuits.

311 to the rescue?

Many believe, and cities like NYC and Philadelphia have implemented, a localized 311 non-emergency service designed to offload non-emergency calls from 911 Call centers and call takers. The call handling technology used to deliver a 311 service is similar to that in the 911 center. This allows the 311 facility itself to become a natural choice for a disaster recovery location or if a facility is needed to house a temporary relief workforce for the 911 center due to capacity or physical damage.

The fact that a 311 center exists though, does not itself provide a solution to the problem, a little more is required. The root cause of the overload issue noted earlier is that people dial 911 when they should have dialed 311. In other words, their call is arriving on the wrong network, and that wrong network has limited resources from a trunking perspective.

Are rubber bands the fix?

While fixes for critical emergency communications from the public should never use duct tape and rubber bands, “elasticity” does bring significant value. Looking back on legacy trunking, of nearly any kind, there is the limitation of a physical circuit on a pair of copper wires. If I need one, I order one. If I need 10, then I order 10. If I need 10, but I only can get 8, then I am short by 2, and there is not much I can do about it. SIP trunking, on the other hand, is delivered over a data facility. The actual bandwidth on that facility can often be dynamic and Is commonly referred to as “a pipe.”

When thinking about the characteristics of data, often it equates very nicely to water. If I need to deliver more water, I need to get a bigger pipe; if I need to deliver more data, the same concept applies. That being said, an inherent benefit of a “data pipe” is that often the delivery medium is the same regardless of the capacity or size. Now a request to the carrier can turn-up or turn-down service capacities through software or configuration. Because of this, the size of the pipe becomes elastic and flexible to my current trends and needs.

Re-engineering with new capabilities

With this new elasticity capability in our network, let’s re-engineer things a little bit to take advantage of its capabilities.

Modern NG-911 Network on Dynamic Trunks

With all of these circuits moved to intelligent SIP trunking, I now have flexibility and sizing capabilities that allow me to be more dynamic with emergency and non-emergency call center call routing. The initial overall pipe capacity reflects best guess estimations for ALL TRAFFIC, and a new control layer of communication between my premise and the carrier networks exists to communicate any changes Required in the specific trunk route sizing required.

Sending these real-time statistics and state changes to the carrier allows real-time elasticity of IP trunking size to realize the most efficient use of resources. Calls to 911 are automatically flagged as such and routed to the 911 CPE where call takers answer. Similarly, calls to 311 are automatically flagged as such and routed to the 311 CPE, where call-takers also answer those calls. By doing this, the number of simultaneous calls to each type of service is controlled by the CPE.

Should a 911 call end up being a non-emergency situation, and the call gets transferred to the 311 center for assistance, a signal is sent to the carrier to add additional bandwidth to the inbound 911 trunk group to compensate for the non-emergency call.

How bandwidth is calculated and allocated is something that now becomes totally under the control of the receiving agency. For example, let’s go back to our disaster recovery scenario. A significant natural event is impacting the local area. An anticipated  20% increase of 911 call taker staff will require 15 additional call-taker seats. In the 311 Center, 15 seats get flagged as auxiliary 911 positions and get staffed by 911 personnel. An increase in carrier bandwidth allows for the additional call volume expected.

This scenario is just another example of why the nation needs to move to NG 911 quickly. The Legacy 911 network in the US uses analog CAMA trunks that are special-purpose and fixed in their capacity. Increases must be pre-engineered and may take weeks or months to implement or sit idly unused, causing unnecessary charges to stack up to municipalities. The technology to accomplish this architecture already exists in nearly every commercial market in existence today. We should heed the lessons learned over many years and provide the same level of innovation to our most essential call centers, ones that save lives.

Mark J. Fletcher, ENP
Chief Architect – Public Safety Solutions – AVAYA

Follow me on Twitter @Fletch911
Listen to my Podcasts

Location from A to Z

911? Where is your emergency?

It is a question asked 240,000,000 times a year, according to the National Emergency Number Association (NENA). While it is indisputably the most critical piece of information that the caller has, it is also the most difficult to communicate to the 911 call taker. How can this possibly be in this age of modern cell phones containing location services?  

True, the cellular device you have in your pocket knows precisely the location of where it is. It uses radio signals from the mobile network, GPS satellite positioning information, and the thousands of unique identifiers broadcast by the public and private WiFi access points, known as Base Station Service Identifiers (BSSIDs). Think about it, if you are standing in your favorite Mall and while looking around you see Baskin Robbins, McDonald’s, Sports Authority, and Spencer Gifts, you know exactly where you are. The same logic applies to BSSIDs.

Each time you click on a EULA in an application, you likely agree to share your location data and visible BSSID information with Apple, Google, Skyhook, and other location database aggregators that have amassed billions of data points over the years. Because of this massive data set, the database has become insanely accurate and becomes more fine-tuned every day as more information points fill the database. Unfortunately, this data only captures locations in 2 planes, the Latitude and Longitude, also known as X and Y. The third plane, known as the Z plane, is also one that is critical, as it represents altitude.

In a 30-story building, there is an identical X and Y coordinate on each floor, in the event of an emergency, 1st responders would need the additional Z coordinate to determine the altitude or floor number to determine where help is needed. The Federal Communications Commission hasn’t ignored the problem and has been holding hearings on the issue for some time. This month, at the Monthly Open Meeting, an agenda item is listed as Fifth Report & Order and Fifth Further Notice of Proposed Rulemaking to discuss the issue further.

Exploration of the problem has been attempted in the past. Yet, none of the solutions have provided a workable fix for cellular phones or other endpoints such as fixed lines and MLTS telephones used in commercial businesses. One particular effort was the National Emergency Address Database (NEAD). While this may have had some initial promise for cellular, the additional data needed for MLTS positioning was always questionable in my mind.

Wireless devices are quickly becoming the conventional device being used for communication, as the cellular telephone penetration figure in the US has soared past the 100% saturation level to an astounding 130%, or 1.3 devices for every person in the country according to CTIA. But there is a dichotomy of legislative requirements being applied o this segment of the industry compared to the statutory provisions applicable to multiline telephone systems.

The legacy analog wireline database, initially used for 911 call routing in location reporting, was initially highly accurate as the telephone network engineers meticulously and painstakingly maintained the cabling data. As mobility crept into our lives, those meticulous records went by the wayside, and the much more fluid ‘as-built’ environment came to exist. Compounding the problem even further was device mobility that could now freely take place without administrative control or intervention. Given the actuality of difficulty in location tracking, wireless devices have been granted an exception, when they represent the bulk of the problem. On the other hand, wireline devices are being held to an extreme level of accuracy, at great expense mind you, that seems to profit only the keepers of those databases.

For the record, I fully admit that no location can be too accurate in the time of an emergency. But, what I do oppose, is technology requiring an over-prescriptive solution adding additional cost and complexity while providing very little actual data that is actionable, edit levels that go far beyond that required for other technologies.

Unfortunately, many of those writing legislation and regulations, have never set foot in a 9-1-1 center or control room. Many of them have never responded to an emergency as a first responder. And many of them have no idea what information it Is considered actionable to those brave enough to have taken on those jobs. Maybe it’s time to start taking a look at the mission and forgetting about the technology for a brief moment. In the event of an emergency, people need help. While ideally, assistance should come from a qualified first responder, helped can come from anyone anywhere. And by alerting other bystanders In the immediate area, they can assist in directing first responders, when they finally do arrive, to be the most appropriate location.

Are we not focusing on the human element because we have become so immersed in technology that flashing lights buzzers and bells must be part of the solution? Have we decided to ignore the value of our fellow workers, bystanders, in those not directly involved in the emergency but aware of it? Let’s regulate and legislate intelligently and effectively. Let’s utilize technology where technology can help; while not becoming mired within the technology, where the solution becomes anti-productive due to complexity.

We continue to fund the upkeep and maintenance of an antiquated, legacy infrastructure that is well past its prime. We are also siphoning valuable budget dollars away from new technology that could be put to good use to solve many of the problems that exist today. Why not use the data that we have intelligently and not in an over-prescriptive manner that will create management problems of the data making it less accurate and reliable overall?

Mark J. Fletcher, ENP
Chief Architect – Public Safety Solutions – AVAYA

Follow me on Twitter @Fletch911
Listen to my Podcasts

The Paradigm Shift in Enterprise Emergency Services

More than 50 years ago – in the small rural town of Haleyville, Alabama – history was made as the local Haleyville Telephone Company beat the giant telco conglomerate AT&T to the punch on February 16, 1968 when the very first 9-1-1 call was placed at 2:00 pm. Today, the very phone used to answer that historic call from State Rep. Rankin Fite and answered by U.S. Rep. Tom Bevill at the Haleyville police station is proudly housed and on display at the new National Law Enforcement Museum in Washington, DC for all to see as a part of Public Safety history.

NENA, the National Emergency Number Association, estimates that more than 240,000,000 times a year in the US, citizens call 9-1-1. That’s more than 7 calls each second. But, even today, potential problems can still exist. One of those issues is Direct Access to 9-1-1 from multi-line telephone systems installed in many schools, hospitals and commercial businesses. In many cases, these systems require an ‘access code’ to be dialed before any external phone number, including 9-1-1. While this is most commonly a ‘9’, it can be a 7, or an 8 or any other combination of digits.

When we go through the lengths that we do to teach children about 9-1-1, this important fact is rarely, if ever, brought up.  Kari Hunt’s 9-year old daughter Brianna found that out on December 1st, 2013 as her mother was being brutally attacked in a Marshall Texas hotel room and ultimately was murdered by her estranged husband. While Brianna knew exactly what to do, and in fact tried 4 separate times, because the MLTS system was not programmed to recognize 9-1-1 without the access code of 9, the calls went nowhere.

Four years, two months, and 15 days after that dreadful day, with the help of several folks in the industry, including Avaya, the President of the United States signed Kari’s Law into the law of the land on February 16, 2018 just before 2:00pm, nearly 50 years to the minute after that momentous, 1st 9-1-1 call in the rural northern Alabama town of Haleyville. The moment that ink was dry on that document, a 2-year clock started counting down to the effective date of February 16, 2020 when the law would go into effect for all. Just. Few short weeks after that event, the Ray Baum’s Act was also passed by Congress, and in Section 506, the FCC was required to complete a proceeding that would address dispatchable location requirements by the fall of this year.  

This past Thursday, August 1, the Federal Communications Commission concluded it’s required action at it’s Open Meeting, where I had the honor and privilege of attending this meeting in person with Hank Hunt.  Later that afternoon,  we were invited to join FCC Chairman Ajit Pai for a Podcast celebrating the event. (Listen to the Podcast here on the Avaya Podcast Network)

During the Podcast, we discussed the fact that, often, the problem of direct access to 9-1-1 is a simple one that can be easily addressed in most systems sold today. In fact, many systems sold over the last decade have this capability available and inherent in the system. Often, it is an unknown feature that is rarely activated, despite the cost point being ZERO. This was a point that I presented to the FCC when I first brought this problem to then-Commissioner Pai, when I first met with him on January 10, 2014.

It was at that meeting where the commissioner was first introduced to this problem, and the tragic story of Hank’s daughter Kari, six weeks or earlier. Soon after hearing about the issue, FCC commissioner Michael O’Reilly decided to check the FCC’s very own multi line telephone system, and quickly found that dialing 9-1-1 did not reach 9-1-1, but resulted in the message, “Your call cannot be competed as dialed, please check the number and dial again, or call your operator for assistance”. Calling out his own agency for non-compliance in his FCC blog dated June 2, 2014, was slightly embarrassing, but accentuated a point:

AWARENESS WAS NEEDED AT ALL LEVELS

Another sensitive area regarding legislation was penalties for non-compliance, as well as the financial impactof those penalties that are applicable. In any legislation, the financial impact is a taboo topic that is rarely discussed. While I had our Communications Commander-in-Chief in my grasp on a Podcast, I took advantage of the situation and probed for his opinion on this elusive topic.

“Mr. Chairman,” I asked, “does the FCC have the ability to impose a penalty?”

I held my breath, waited for the stinging sensation of taser needles hitting my back, and the sound of handcuffs being clinched around my wrists, but instead, the Chairman responded with, “Of course I need to confirm with our lawyers, but I believe we do . . . [T]he FCC does have the authority to issue fines; to go after people who don’t live up to their obligations; and we have an enforcement bureau here […] that is always willing and ready to stand up and make sure that our rules get enforced.”

That statement signaled a ‘we mean business in this issue’ and was one if the strongest statements I have heard from the Commission on the topic. The Chairman concluded with, “[I]f you’re an MLTS provider that’s not living up to the requirements of Kari’s Law, we are going to make sure that you’re held to account.”

That being said, as for the actual collection of any penalties assessed, that was an area where the Chairman admitted that gaps still exist and had been identified to Congress. While the Federal Communications Commission has the authority to enforce their rules and issue fines for certain violations, should an individual choose not to pay, the FCC’s only recourse is to solicit the Department of Justice and request that they file a lawsuit for the actual collection of the fine. Clearly not ideal with all of the other initiatives DOJ has on its plate, but none-the-less, a process exists for recourse, and if you make the DOJ mad at you, you are walking into the lion’s den wearing a pork chop body suit.

While over the past years, Enterprise administrators could take the low road, and claim ignorance on the issue of direct access to 9-1-1, on site notification that provides actionable information to 1st responders, and a ban on intercepting and answering calls internally. But Kari’s Law has brought about awareness. It shined a spotlight on the issue that almost anyone can see. While the personal cost of this enlightenment was the loss of a precious life, something most of us will never truly understand, what this incident also did was ensure that Kari’s memory will remain as a testimony of her goodness, and the ultimate sacrifice that she gave so that others would be saved. And most of all, Hank’s one and only wish was fulfilled, that Kari’s death was not in vain.


The Kari Hunt Foundation a 501c3 organization
https://karihuntfoundation.org/

Hank speaks to and aids 9-1-1 Telecommunicators by informing them of the many communication breakdowns that occurred on the day Kari was murdered. From access to 9-1-1 in the Hotel room, to the lack of awareness with the front desk staff, to the language barriers that complicated the situation, and even important information that was disseminated incorrectly during an Amber Alert that resulted after one of the children were kidnapped by the estranged father after the murder.

KARIHUNTFOUNDATION.ORG
11688 C.R. 3119, WINONA, TX 75792, US
(903) 926-1047

 

July 4th | 9‑1‑1 | Fireworks – A Perilous Combo?

Back in 1980, when I was a police dispatcher in Sparta New Jersey, I can remember that inevitably every year on July 4th at about 8:00 PM, nearly every line on the phone would light up. For the most part, the conversation would go something like this:

Me:      “Sparta Police, dispatch”
Caller:  “Uhhm . . . yeah . . .  Can you tell me what time the fireworks start?”
Me:      “Same as last year sir, at dusk, usually right around 9:00PM”
Caller:  “OK . . . Thanks”

Not every call asked this, there were some interspersed inquiries:

Me:      “Sparta Police, dispatch”
Caller:  “Uhhm . . . yeah . . .  Can you tell me where I can WATCH the fireworks?”
Me:      “Probably in the sky . . . ”
[OK, so maybe my snarky attitude wanted to say this, but of course I remained professional]

The SAME call scenario then repeated for nearly the next hour, over and over and over. Much of the time, every available line would be lit, and every caller had the same question. In a way, it was almost comical.  The residents of these 3 tiny municipalities, a total population of 30,000, were under my care, but I was unable to help them in an emergency as I was tied up answering these calls. There I sat, all by myself, hoping and praying that no one was experiencing a REAL emergency and needed a real response for help. In an effort to break up the monotony, at times, I answered the phone with:

Me:      “Sparta Police, dispatch . . . the fireworks start at dusk”z
There was usually a long silence and they would respond, slightly confused
Caller:  “Uhhm . . . Thank you?”

Eventually, just as this rash of calls started to diminish, the next wave started to come in:

Me:      “Sparta Police, dispatch”
Caller:  “OK, hi . . . so . . .  there are a bunch of kids with fireworks over on East Shore Trail”
Me:      “Ok, can you tell me what any of them are wearing or which way they are heading?”
Caller:  “Nope, but they are raising hell over here and I am trying to sleep”

But that was 40 years ago, and times were very different. The communications technology was in its infancy, and everything was written down on punch cards, and time-stamped on a time clock (ka-chunk, ka-chunk). There was no 9‑1‑1 in my center, just POTS lines on a 1A2 Key system. Heck, while 9-1-1 may have existed somewhere in NJ back then, I didn’t know of anyone in the State that had it; and as for caller ID? Yeah, right! Ha ha ha! That was still a far-off fantasy. Back then, we worked under the bare minimums. Today, with four decades of techno-babble under my belt, quite a bit of self-taught programming in BASIC, QuickBasic+ and a little bit of C+, my favorite new word has become ‘workflow’ or scripting. At the core, a program is based on a flow chart. A list of actions and decisions that happen in a logical predefined order to create some effect or outflow of data. I quickly realized that when workflow was applied to nearly any problem, the resulting solution was often both effective and innovative. I may have automated a monotonous task.

The number of times I typed:
NCICQV.NJ0191800.LIC/768KUL.LIS/NJ
to do an NCIC check, has to number in the tens of thousands. . . .

or it may have just provided consistency in the data entry. In fact, some of the most innovative ideas are simply a combination of tasks strung together to solve a problem.

This is where AI can directly lend itself to enhance any industry – through automation. There should be no great surprise, as industry has realized this back when Ford implemented the Assembly line. But, before I get too deep into this particular topic, I want to make one thing perfectly clear to my readers, while artificial intelligence can greatly assist in making decisions, we are not talking about totally autonomous AI. Realistically, we are likely still a long way off from true artificial intelligence. This is because common sense is not always a binary decision. But, one thing that we can benefit from today is the mathematic probability and the assistive advice that AI can provide. This is where we need to start to change our thinking, especially in areas of public safety or critical life affecting decisions, such as the medical field.

I’m liking this to the change in thinking that has taken place with testing in schools. When I was growing up, calculators still we’re still uncommon. Bringing one into a test would be considered ‘cheating’. Now, along with the text books that are required for a particular class, advanced engineering courses require a scientific calculator, and often suggest several models. Keeping this frame of thought in mind, let’s revisit the first example I mentioned previously in this blog, but this time, I’ll apply some assistive AI logic, and present this solution in the form of a simple flowchart:

EXMPLE JULY 4th CALL SCREENING WORKFLOW

The simplified logic here is fairly easy to understand. When a call arrives, the following decision points are considered.

• . Do I have a Call Taker Available?
• . If I do, then deliver the call. If I don’t, then determine if:
• . Is it July 4th between 20:00 and 21:00?
• . If not, que to the call takers, but if it is, intercept and play an informational message about where the fireworks are, and even direct them to the web for more information and safety tips.

Ideally this could eliminate many of the calls from tying up call takers, but those that need to speak to them are placed in queue, or routed elsewhere

This is done easily as once we play the message, we ask if they need further assistance, and disconnect, queue as needed, or even branch further to other common information resources.

Plan 9 from Outer Space?

Now, here is where we can really get a little far out with a solution.

By prompting the caller with an IVR, we can ask them if they’re calling from a mobile device?
(remember, in many markets this is a 80% – 90% of the call volume)

If the caller is on a text enabled device, we can clear them off the 9-1-1 line while offering them a more informative and interactive experience by simply pushing a web link to their device. Once the citizen clicks on the link, very simple HTML 5 technology can be embedded in the webpage that can extract their specific location, after they agree to share it, and then based on the response provide geo-targeted information that would be relevant to the caller.

This is a great transition into NG311 services, something that I’m getting asked about nearly every week. I’m convinced that the biggest success factor for a government 311 service, is the user awareness programs and publicity created by agencies. This could significantly reduce the number of  ”Information calls” into the 9‑1‑1 system, while providing a public resource, and an excellent EOC environment during disasters, as the basic premise of 9‑1‑1 call taking utilizes identical infrastructure on the backend.

I believe that this is one of the areas where Avaya brings technology to the table that a normal public safety vendor does not. They have the luxury of focusing on a very narrow use case of emergency services requests. But as communications evolve and become more multimedia in nature and omni- channel, the communications architecture embedded within public safety must involve with it or it wil lbe left behind, again. Those that want to play it safe by remaining stagnant, are actually depriving constituents of modern communications that could save lives.

To the current Sparta Chief of Police Neal Spidaletto, I remember you back in the early 80’s running around the house like a little terror, driving your Dad crazy. Congrats on your appointment as Chief, I am sure Joe is very proud of your career and accomplishments.
(https://www.njherald.com/20170606/sparta-swears-in-police-chief-promotes-3-officers)
please tell ‘Baby Face Joe’ that Fuzzy says he still looks great and as distinguished as he always did. Always a great friend, and I cherish the many shifts we worked together.

Please remember to follow me on Twitter @Fletch 911, check
out all of our other podcasts at http://www.Avaya.com/APN

Listen and subscribe on iTunes, Google Play Music, and
SoundCloud, as well as our featured content on the iHeart radio network.

Testing 1-2-3 . . . PART Three – Location

By: Mark J. Fletcher, ENP
Chief Architect Public Safety Solutions – AVAYA

In PART Two of this blog, we discussed the Emergency Call
Network, that segment of the PSTN dedicated to emergency calling and connecting the PSAPs together on a regional basis. In this section, we’ll cover the mobility that modern networks provide to Enterprise users, and clearly one of the most challenging pieces of information for 9-1-1 call takers to obtain.

We learned that the Selective Router in the E911 Tandem office was responsible for connecting callers to the right PSAP. That decision is made based on the Caller ID presented with the call. Initially, this was a very valid best practice, as the network was well documented, and changes were well controlled and performed by the service provider.

One Number – One Address
Telephone numbers rarely were co-located in multiple locations (with a few
exceptions) therefore the telephone number was an excellent data point usable for determining the location of a device, and the network was designed around this fact. In the mid 80’s, the Northern Telecom DMS 100 was introduced as a digital central office platform, and AT&T introduced the ESS 5 with similar capabilities.

With these new digital switching platforms, the layout inside the Central
Office radically changed from one that was mechanical stepper-motor-based to one that used a digital switching matrix, and with this automation fewer and fewer CO’s were staffed with technicians, as the building role became merely a wire center with a cross connection point for dial tone to street pairs. With the digital evolution these switches brought was a new series of custom calling features.

A Star is Born
Customers did however get some very new features, like Caller ID and feature ‘STAR-codes.’
Missed a call? Dial *69 to be connected with the last number that called. *72
along with a telephone number would forward any calls to the new destination, and depending on the services provisioned in the CO, various other features became available to customers. Many of these features took advantage of Caller ID information that was now available with the call. For the very first time, the called person could know the identity of the caller displayed on their telephone device. Caller ID (better known as Automatic Number Identification or ANI) now provided 911 centers with information about who was calling, or at least the number they were calling from. Now, if a silent call came in, or there was a question about the address and location, the original color could be easily reached. 911 centers also played games with the electrical properties on the phone lines, and it was common practice not to pass any answer or disconnect supervision from the PSAP. This providing for a simple way to keep the line open simply by
not hanging up on the public safety end.

Location, Location, Location
Without a service address, it’s impossible to send any help at the time of an
emergency. To solve this problem, 911 centers begin taking the ANI (phone
number) they were receiving with calls, in making a query back into the carrier network database that routed the call. This ALI Automatic Location Information added location to the context for wireline calls, however the cellular industry didn’t catch up, and continued to report only Phase 1 location information, which was the latitude and longitude of the radio tower the cell phone happened to connect through. With the white density of cell towers, compared to today, the effective service areas were quite large spending several miles. When cellular towers were installed on mountaintops they often lined up with political borders, once again exasperating the location problem if you’re located across the state lines hitting a remote tower due to height and proximity. This problem remained for many years, and only began to be solved as devices started to contain GPS radio receivers, but there was still an underlying problem at the network layer level.

Can You SEE Me Now?
As the density and placement of cellular towers increased, Basic radio
coverage and interoperability became commonplace. Carriers started to
interoperate with each other, and cellular handoff became a commonplace feature spanning the entire coast. Making a call with simple, but making a 911 call remained problematic. Don’t get me wrong, calls could be received and routed quite simply, however since the 911 network is a legacy analog based network, and no data channel exists to pass information on, 911 centers went into making a query to the cellular carrier asking them what visibility was available out of their network. Despite the device itself having an excellent location awareness, due to Wi-Fi fingerprints, access points, cellular towers, as well as a GPS signal when outside, the location of you what is the network looking in, and what the device had (known as handset-based location accuracy) was simply unavailable to the PSAPs, and no mechanism existed to communicate anything other than a voice path between the caller and the call taker.

Google Can Find Me . . .
Yes, I am well aware that Google, Domino’s Pizza, and a plethora of other
services are you able to locate your cellular device with incredible accuracy; in the first responders at 911 that are trying to save your life, cannot. The primary reason behind this is that because the device is utilizing an application. Also, the application has access to the device-based  location information held in the memory. This particular location information uses all of the data points that we discussed earlier, and that information is communicated back over the Internet to the host application. Once again, this is where the train goes way off the rails.

The information that is contained within the device is like having a trans-Atlantic Ocean liner that is landlocked in a lake in the middle of Kentucky. Regardless of the level of luxury, the number of passengers it holds, or the amazing abilities contained within the ship, without any use cases or access to the ocean, you’re going to have a rusting pile of steel in just a few years.

Unfortunately, this is the exact state at our Legacy PSTN network exists in
today. Consumer-based technology, the information age of the Internet, and the digital transformation that has occurred in commercial businesses, have connected the world at levels never before conceived. The devices we carry our hands and our pockets, are capable of blinding fast speeds and connectivity levels never dreamed of before. I can call, I can video, I can text, and I can email anyone on the planet; except 9-1-1. My daughter, halfway around the world on a beach in Waikiki with her boyfriend can transmit real-time high definition video from her handheld device to my handheld device 4,882 miles away with practically zero latency, but if she had a medical emergency and needed help, she would be stuck with a voice call and location inaccuracy about half mile or more if she called 911.

In any commercial enterprise space, despite be vast amount of digital
information we have available about the emergent event, the situational
awareness about the emergency, or even lifesaving information about the caller, no matter what the technology is at the origination point, the network in the receiving agency are relegated too low fidelity text based information. Why? I’m not sure I’ve gotten a good answer to that . . . . yet. But I know a few young entrepreneurs that took the problem head-on, and drove a paradigm shift change in an industry that was half a century old and very much stuck in its ways.

In Part Four of this series, we will dive into over-the-top applications, that
utilize the Internet in the open connectivity that exists nearly everywhere to take a short cut around the technology roadblocks that lay between citizens who need help, in the public safety first responders that can provide that help.

Please remember to follow me on Twitter @Fletch 911, check
out all of our other podcasts at http://www.Avaya.com/APN

Listen and subscribe on iTunes, Google Play Music, and
SoundCloud, as well as our featured content on the iHeart radio network.

Testing 1-2-3 . . . PART Two – 911 Networks

By: Mark J. Fletcher, ENP
Chief Architect Public Safety Solutions – AVAYA

In PART One of this blog, we talked about originating the call in the enterprise and the importance caller ID has in identifying the origination point of the call accurately to the PSAP.

Now that our emergency call has made its way out of the MLTS, navigated through the local Central Office (hopefully unmodified and intact), it has now landed within the 911 tandem Central Office where it is ready for location digestion and termination at the PSAP. The selective router, typically a Northern Telecom DMS 100, or a Lucent E5, has the specific job of providing connectivity between local area PSAP’s and the local Central office switches that serve dial tone to the public. While no hard fast rule exists, it is common to find that selective routers provide service in a specific geographic area that often (but NOT always) aligns with local calling area LATA jurisdiction. Once again, it is important to keep in mind that there is no hard fast rule here. While this legacy design has worked for years, the architecture happens to be one of the many things about the legacy network that is stifling innovation today.

Enterprise telecom providers and installers should be familiar with a few essential points here regarding the local selective router service areas. As they are often tasked with provisioning the MLTS properly. Generally speaking, the selective router tandem offices are designed in a hub and spoke fashion. They supply dial tone to PSAPs through specialized analog loop start CAMA trunks. While these trunks are in fact special, from a use perspective, the technology behind them is actually quite old, and has questionable value in today’s environment, given the changing mission and the need to include data elements and multimedia with the call.

Because CAMA trunks are analog based, loop start circuits, they are electrically no different that the POTS line that feeds your home. One important difference is that instead of normal DTMF tones, they utilize MF Tone signaling. Despite this, the most important characteristic is that they are ANALOG and NOT DIGITAL circuits. This means that any signalling between the endpoints of the circuit MUST be either voltage changes on the line (called battery), or in-band audio, leading directly to the first important point.

Caller ID / Location and E911
For calls transferred into the 911 tandem from the Local Central Office, the Caller ID takes on a level of implied authentication, and is matched against a selective router database table (SRDB) that determines the appropriate ESN or Emergency Service Number of the PSAP responsible for that physical address.

You can think of this Selective Router Service Area environment similar to a localized CENTREX model, with all of the PSAP’s interconnected by analog CAMA trunks. Calls can be transferred from one PSAP on the same selective router, to another PSAP on the same selective router simply by issuing a flash-hook on the CAMA trunk, and then dialing the ESN of the desired destination PSAP.

When this occurs, the call taker in the original PSAP can stay on the line with the call taker of the transferred to PSAP to ensure a warm handoff of the call and verbal information. This is done verbally as the interconnection is typically only voice. Once they’re no longer needed, the transferring PSAP can stay or disconnect, leaving the originating caller and the transferred to PSAP talking (now connected by the selective router).

This architecture eliminates the need for the transferring PSAP to hold the bridge on the call, which would tie up dual trunks to initiate the transfer and hold up the call connection. However, it limits where calls can be transferred, as the destination PSAP must be getting service from the same selective router as the originating PSAP. The exception to this rule would be in areas such as New Jersey, where the four selective routers servicing the state are interconnected with an SS7 network, and any PSAP can transfer to any other PSAP within the state network.

In areas where there is no inter-selective router connectivity, transfers to a PSAP that exists in a remote selective router must be accomplished using a 10 digit administrative line over the PSTN. BUT – because this call is going through the public toll network, the transferring PSAP must hold the bridge together between the caller and the transferred to PSAP.

Another downfall of PSTN based transfers is that it is often impossible to pass any data with that call (even caller ID), as these circuits are capable of voice only traffic, and the foreign exchange PSAP may not have access to the originating PSAP E911 network ANI/ALI database. Since selective router service areas never cross state borders, adjoining states with large population centers within their boundaries can find it very difficult, if not impossible, to pass calls between them efficiently.

A scenario causing a challenging problem for cellular telephones is the fact that electromagnetic radio waves never honor or limit themselves to a political border, and in fact, freely travel well beyond them. Exasperating this problem are areas where adjoining counties obtain service from different selective router facilities, such as Orange County Florida and Osceola County Florida.

A True Story that Prompted this Section
Recently, while driving west on Interstate 4, leaving NENA in Orlando, I witnessed a motor vehicle accident on the access road next to the highway. It had just happened, and were obviously going to require police assistance and a tow truck. Unknown to me, the actual location of the accident was just inside of the Osceola County border, but when I dialed 911 from my cell phone, my call was connected by the cell tower the the Orange County Sheriff’s Department 911 Center. I proceeded to explain the situation the best I could to the Orange County 911 call taker, who quickly determined that the incident was just beyond their border in Osceola County. She advised me she was transferring the call and not to hang up, and within 10 to 15 seconds, I heard the Osceola County 911 call taker come on the line. They advised them this was a transfer from a cell caller with an accident report and told me to go ahead.

I painstakingly recanted everything that I had just explained to Orange County, but the Osceola County call taker, questioned the location. I then asked if they got Phase 2 location on me, to help narrow down exactly where I was. I was then informed that because the transfer occurred as a 10-digit PSTN transfer, no ANI or ALI information was available to them.

Fortunately, both call takers were familiar with this troublesome location. Also, from the sound of it, both had their own techniques for coaxing the exact location out of the caller. However, it highlights a significant technology failure within the core E911 infrastructure, that is often masked by the hard-working dedication of our 911 call takers. Help gets to where it needs to be, despite the networking inefficiencies and technology roadblocks (like having to transfer emergency calls over the public switched telephone network) that blocks critical information from our nation’s 911 centers.

Given this example, with our cellular networks and mobility, you can only imagine the problematic environment that we’ve created in MLTS systems that’ll allow working from home with hard phones and softphones on laptops, and the connected world that we live in.

In PART Three, we’ll look at enterprise mobility, to better understand the problem, and start to explore potential fixes. Please remember to follow me on Twitter @Fletch 911, check out all of our other podcasts at http://www.Avaya.com/APN

Listen and subscribe on iTunes, Google Play Music, and SoundCloud, as well as our featured content on the iHeart radio network.

Testing 1-2-3 . . . Where is your emergency?

PART ONE – The Originating Network
By: Mark J. Fletcher, ENP
Chief Architect – Public Safety at AVAYA

At Avaya, whenever a customer decides to review the implementation of emergency calling capabilities within their corporate telephone systems, we always stress two specific things.

The Plan:
First and foremost, is the implementation plan. Deciding exactly what the workflow needs to be – based on specific customer use cases that take their facility into consideration – as well as the various actions that make up that workflow. Critical details such as the reported response area size and the complexity of the internal floorplan must be taken into consideration, as well as the anticipated population of the facility, and the number and location of area entrances and egress points that would be usable during an emergency situation.

Testing:
Another important aspect is testing of the response plan. this must be done regularly to ensure that the plan is functional and provides an appropriate level of response. Also, the system itself needs to be assessed to ensure that the appropriate level of performance is being delivered, and that the proper level of information is being delivered to the PSAP.

While I am reasonably sure that no one would intentionally program 911 incorrectly, so that calls could not be dialed or that a wrong location would be purposely reported thereby delaying emergency response personnel, it is essential that the MLTS administrator clearly understands the various components and that the system is receiving the proper data, as well as operating nominally.

The most common mistake is one where no testing is done. Under this circumstance, the MLTS administrator makes the dangerous assumption that 911 is programmed correctly, and this leads directly to my question:

How does one know for certain that 911 is provisioned properly, without actually picking up the phone and dialing 911?

While this is the ultimate test, that does tie up valuable time and resources at public safety answer points across the country. With Kari’s Law legislation pending in the upcoming months (February 16, 2020), PSAP’s could be inundated with testing requests all the while fighting their constant internal battle of being already overworked and understaffed.

Unfortunately, without actually making a call to 911, the only way to ensure proper provisioning has been a “stare and compare exercise” by an MLTS technician or an MLTS administrator. First, they would log in to your system and extract a copy of your programming. Then, the person would manually walk through the dial plan steps, one by one, ensuring that an appropriate outbound trunk facility was being selected and that the calling line ID being sent over that trunk was appropriate for a 911 call, and was what they intended it to be to reflect the proper response address and internal location as per the design plan. While this simple exercise certainly caught any major programming problems and configuration errors, it did not provide a complete level of assurance that the system was actually working correctly.

How you ask? Simple, it’s called a false positive condition, and in 911 it could be deadly.

False Positives:
A false positive is a test result that indicates that there is no problem, when, in fact, one does exist. In the MLTS world, several things exist that could trigger a false positive when testing 911. Before we dig too deep into that, let’s understand the primary components involved in a 911 call between the MLTS and the PSAP.

When 911 is dialed, the call leaves the PBX on a specific facility. There are two pieces of information associated with the call at that point:

1.) The outbound Caller ID applied to the call, and
2.) The number as dialed by the originator (the called number)

The very first culprit of a false positive could be a physical one on the trunk facility itself. The CALLED number is simply established and is likely 911. However, the caller ID could originate from several different sources.

The very first thing to mention here is that the various types of trunks have different capabilities. Many like analog POTS lines, for resiliency, however, a little known fact is that when sending your 911 calls over analog loop or ground start trunks, the caller ID that is seen by the public network is the telephone number that is associated with that specific trunk.

Because the circuit is an analog circuit, custom caller ID cannot be applied, but this is precisely what gets your call routed to the right 911 PSAP, and the index they use to retrieve location information. Therefore, if you’re reporting uses building zones or the station location itself (both of which require dynamic caller ID) it is impossible to deploy this strategy using a POTS line, as the caller ID would always be the same for any calls on this trunk facility.

To utilize dynamic caller ID and any logic that is more granular than the building street address, the call must egress from the system on a facility that is digital, such as PRI or BRI, or direct SIP. This is true as these are digital protocols that support the transmission of a device identifier (telephone number).

Next-in-line is the originating central office. The responsibility of this central office is to connect local calls to other local endpoints on the same central office, and forward all other traffic to the toll switch and onto the long-distance network. For emergency calls, the local CO typically routes calls directly to the E911 tandem, also known as a Selective Router.

At the local CO level, applicable to digital circuit facilities only, there have been instances where the local central office provisioning on the inbound trunk group has been modified for 911 emergency calls. this can create a problem.

I have personally seen cases, where the inbound caller ID was modified, based on a previous trouble ticket. It turns out that improper programming on the MLTS caused invalid caller ID for 911 calls. To correct the issue, a central office technician implemented a translation table that forced any call with a destination of 911, through a table that stripped off any, correct or not, originating caller ID – replacing it with the main billing telephone number of the business owning the trunk group. Problem fixed – Sort of.

Since technology had not advanced yet, and an MLTS typically only served a single unique location, this logic corrected that particular problem of bad caller ID. Unfortunately, this apparent “fix” now masked the actual issue and created a whole new error condition if caller ID was to be used for location identification. Even more problematic, is that documentation is rarely kept current on why changes like this are made. Now, when they rear their head, it takes an incredible amount of effort and time troubleshooting to find the proverbial needle in the haystack, creating the issue at hand.

Now that we have our call into the actual 911 network, next up in Part Two, we will analyze what the network does with our call request, and what control we have over what takes place and how.

Please remember to follow me on Twitter @Fletch 911, check out all of our other podcasts at http://www.Avaya.com/APN

Listen and subscribe on iTunes, Google Play Music, and SoundCloud, as well as our featured content on the iHeart radio network.

Kari’s Law – Countdown to Compliance

At the time I’m writing this, 477 days have passed since I stood in the Oval Office along with Hank Hunt as we witnessed Kari’s Law becoming the law of the land. While not strongly worded as such, the intent of the law was that, from that day forward, an MLTS phone system installed or put into service would be compliant with direct access to 911 without an access code, any calls to 911 would route directly to the PSAP and not be intercepted internally, and unless an upgrade was required, the system would provide some mechanism of notification that an emergency call took place.

Any existing MLTS systems that were installed prior to that date would have a two-year grace period in which to make their system compliant, with February 16, 2020 as the final date when legislatively this would be required. While system administrators and vendors have had almost 16 months to deal with the issue, many still have not. Now, with the deadline approaching quickly, the mad rush is on to secure system capabilities, and provide safe work environments for employees and guests.

Last year at the Avaya ENGAGE Event, Hank Hunt (Kari’s Dad) graciously sat down and recorded this video message:

Hank Hunt on Kari’s Law

Just a little more than a month after Kari’s Law was signed, the president signed Ray Baum’s Act, named in honor of a popular political figure that had recently passed away. The primary purpose of this act was to reauthorize the Federal Communications Commission and establish its operating budget.

With this act being a ”must pass” piece of legislation, it is popular for many other bills that will not stand on their own to become attached to it. One of those pieces of legislation is known as section 506 of the Ray Baum’s Act, and it has recently caused a bit of a stir in the MLTS community.

In this legislation, it establishes a requirement that the FCC conclude a proceeding within 18 months examining it further requirements are needed for location reporting on multi line telephone systems. The due date for that proceeding conclusion is September 23 of this year. This section calls off the need for a dispatchable location to be provided to public safety answer points when and MLTS initiates a 911 call. BUT, as I’ve said many times before, the most critical piece of any law is the definition of specific terms, and the same is applicable here.

In the Act, a dispatchable location is defined as one that, “means the street address of the calling party, and additional information such as room number, floor number, or similar information necessary to adequately identify the location of the calling party”.

Unfortunately, this is being hyped as requiring the exact room or cube number of the caller being delivered directly to the PSAP, when in fact that information is completely irrelevant without additional context. The fact that I sit in cube 2C-231, has no meaning to anyone outside of my company.

1st responders don’t know where 2C-231 is within the building, or even what floor it is on, so it has little relevance. It is very relevant, to internal first responders within the facility, and it could be provided to public safety first responders on an electronic display, and now with context, like a floor plan. This can now be provided directly with the 911 call itself, thanks to new over-the-top NG 911 technology provided by the Rapid SOS NG911 Clearinghouse.

Screen Pop information made available to internal 1st responders and now deliverable to PSAPs via the RapidSOS NG911 Clearinghouse
Additional Context Available in the Enterprise

In the past, establishing 911 database records for every station within the facility created two problems. The first, was that every single device needed a unique and dialable public telephone number in order to identify itself, and secondly a unique record for each device needed to exist in the 911 ANI/ALI database, which incurred a significant monthly recurring cost. While at the surface, this seems to be useful information, it actually creates a false sense of security, as well as an administrative management nightmare, while providing minimal useful information. This is because in legacy solutions, the ability to pass additional context such as a floorplan is next to impossible.

Is this too much work, with no time to complete it?

Depending on the size and complexity of the enterprise, the 911 plan can be quick and simple to implement, or it may become a long drawn out process. This is where a waiver can help tremendously providing some additional time, where warranted. One of the initial states to adopt legislation was the State of Texas, Kari’s home State. During various hearings that took place in Austin, I suggested that waivers be granted to those that specifically apply for them, and as part of the application, the MLTS make and model number, as well as its software release be put on file, as well as evidence that a good faith effort was made to purchase a new system.

This simple clause solved a couple of primary issues. First and foremost, it forced businesses to make an effort and investigate what their situation was, and secondly it created a list of compliant MLTS systems, and release levels, which prevented unscrupulous distributors from up selling the general public when it wasn’t warranted. The waivers were good for one year, and needed to be renewed each September.

Since 2016 when the law went into place, the number of waivers filed each year has dropped by 20%, as more and more noncompliant systems were replaced with those that were compliant. As the graph below shows, in 2016, the very first year, 630 wavers we’re granted. In 2017, that number dropped significantly to 386, and in 2018 it was further reduced to only 252. Those systems granted a waiver also needed to make sure that users of their system we’re well aware of how to dial 911, with very specific placard requirements. Obviously, any new system purchased what have to be compliant upon installation.

MLTS Waivers Issued (and projected) by Texas CSEC 2016 – 2020

911 is the most critical call you may ever have to make. As manufacturers of systems globally, we make sure that our users are well aware of this problem, and that’s why we stood behind Hank Hunt’s initiative on Kari’s Law from the very beginning.

Follow me on Twitter @Fletch911
Check out my Podcasts on APN

Powered by WordPress.com.

Up ↑