Earlier this year on March 21, an incident occurred in the Manhattan School District that prompted a call to 911. This wasn't Manhattan New York. This particular Manhattan is a small village in Will County, Illinois, about 50 miles southwest of Chicago.
Apparently two Will County kindergartners decided to take a leave of absence, and walked off the school grounds. But instead of reaching the Lincolnway Public Safety Communications Center in Frankfurt, the call was routed to an emergency call center in Canada.
The immediate question was "How could this happen?", with the initial suspect being the new VoIP system installed last December by Broadvox. As usual, the press sees "E911 failure" and "Voice over IP" in the same sentence, and they immediately draw the conclusion that the two are related. Manhattan Police Chief Howard Martin responded, "it had nothing to do with us, it was a problem at the school."
Ultimately, the children were found, however it was reported that due to the Canadian routing, emergency response was delayed by 5 minutes. Additional comments made by the Sun-Times reported that after the Broadvox system was installed, it was checked and appeared fine, however after the incident, the system was corrected so that any future 911 calls would route locally.The initial knee-jerk response is "VoIP is not compatible with E911".
The technology used by the person making the call, whether it's digital, analog, wireless, or VoIP, has little to no bearing on the network processing an E911 call.
What does matter, however, is how the system is interconnected with the PSTN. Even then, it's not as so much as how, but by who that connection is made. Traditional carriers delivering legacy circuits are well interconnected geographically with the E911 selective routers. As businesses flatten, consolidate, and extend, a VoIP solution becomes more and more attractive. Additionally, SIP trunking offers additional savings as well as consolidation benefits.
The problem with SIP trunking, is that it can be located anywhere. It's not bound by the geographical boundaries of the PSTN. This makes E911 more difficult to deal with, as the location of your trunks may not be local to the location of your users. This completely breaks the E911 model used today in North America. But fear not, there is a fix.
In the past, we have talked about VoIP Positioning Center's also known as VPC's. Think of the VPC as a new type of carrier that specifically deals with E911 call traffic. It's the VPC's responsibility to maintain connectivity to each E911 service area, and provide their customers with proper routing for emergency calls. Just like any network transporting any data, routing rules and instructions must be established. For VoIP emergency calls to a VPC, the calling number or ANI is used as a routing reference against a pre-provisioned database.
This routing mechanism is identical to the 911 selective router network, with the exception that it covers a much wider service area, typically all of North America. Based on this, we can shift the blame for this particular call incident to the VPC, right?
No, not really.
In today's legacy analog-based 911 routing, calls going to selective router make it there in some instances without the proper ANI. We know that it's a 911 call, we just can't confirm its origin. So, do we just not process the call? Of course not. The call is what is known as "default routed" to a designated PSAP where it is presented as either an ANI FAIL, or NO DATA call. This is a key indicator to the emergency call taker that they need to establish the location of the caller through a verbal inquiry.
Back to our friends in Manhattan Illinois. I'll speculate on what happened here, and openly admit that I don't have all the details. Most likely what occurred, based on the facts that we do have, is the call to 911 was presented to the VPC. For some reason, the ANI or caller ID did not exist in the VPC database, and the VPC default routed that call to an emergency call response center for manual handling. Although this did cause a delay in the emergency response, was the VPC at fault?
Again, most likely, the answer is no.
When you look at a implementation of the E911 services, there are several important steps that you must consider. The first, is how the system will operate; what exactly happens when a station dials 911, who was notified, and where the call terminates. The second, and just as important as the first, is what routing will take place within the carrier network you're presenting that call too. It doesn't matter if it's a legacy analog network, a digital PRI network, or a new modern VoIP network. If the carrier doesn't have routing instructions, the call cannot be completed, and therefore would be default routed, or even worse incorrectly routed based on invalid data.
So a step back and look at this, and you try to establish how and why this happened, based on the facts I'm not sure you can blame the school, Broadvox, or the VPC carrier. More than likely the implementation was at fault by either not testing properly, or not taking 911 into consideration at all. Keep this in mind when you're looking at your E911 solution for your enterprise. And when you're attending The Great E911 Debate, at IAUG in Boston, on Sunday may 20th. The technology exists to deal with today's highly mobile and nomadic workforce. The knowledge to implement properly is what is often in question. You don't have to become a 911 expert to purchase a 911 solution, just like you don't have to be a mechanic to purchase a car. You should know, however, how many wheels to expect of the car you're buying, and you probably should know how to drive.
I asked Bill Svien, Vice President of Corporate Strategy at 911, ETC, Inc. and a VPC provider himself what his thoughts were around this:
"The implementation process is key to the successful routing and delivery of a 911 call. Ensuring that numbers are properly provisioned within the VPC database is essential, and testing should be thoroughly completed before going live. The technology is available today to properly route 911 calls whether an organization is utilizing TDM or IP/SIP. It's the front-end provisioning of the solution that should be meticulously and professionally handled in order to avoid an outgoing 911 call with no location information attached."
So, as you can see, implementing E911 just takes a little common sense, and good testing and retesting of the implementation. Having the general knowledge of how E911 works, will help you dig through the "rhetorical technobabble" that's out there by those selling E911 to the enterprise based on Fear, Uncertainty and Doubt.
I look forward to seeing many of you in Boston where we will do our part to dispell the FUD at the Great E911 Debate on Sunday May 20th, at 3:30PM. Be sure not to miss this important panel session that will include Avaya DevConnect Technology Partners, and Select Product Partners!
Want more on E9-1-1? E9-1-1 Talk Podcast
Subscribe to my weekly E9-1-1 Talk Podcast here
Thanks for stopping by and reading the Avaya CONNECTED Blog on E9-1-1, I value your opinions, so please feel free to comment below or if you prefer, you can email me privately.
Public comments, suggestions, corrections and loose change is all graciously accepted ;-)
Until next week. . . dial carefully.
Be sure to follow me on Twitter @Fletch911
Posted 5 May 2012 at 12:10 PM