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.
