We all have a fundamental understanding as to what happens when we pick up a telephone and dial 911. We expect that our call will be answered by an emergency response specialist close by and not by someone hundreds of miles away.
However, have you ever thought about how that happens? Have you thought about all the different ways that that call might be made? Does the call go through the same set of steps when it’s made from that analog telephone in your house as it does when it’s placed from a cell phone?
How is it different when the call is made from a business phone attached to your company’s PBX? What if that business phone is on a gateway halfway across the country? How does 911 work if you are in a hotel room and you make the call from a soft phone on your PC?
What happens when a deaf person makes a 911 call from a TTY device? It’s getting complicated, isn’t it?
911 consists of a several functional areas. There is the telephone you are calling from. As I mentioned above, that phone can be any number of different devices connected to the telephone network in many different ways.
Then there is the phone system that initially processes the call. That might be a PBX, a cell carrier, or the local phone provider for that landline in your house.
Next comes the 911 network components. I am lumping together all the functionally that figures out where to send the call and what information should be associated with that call (e.g. street address, the floor number of a building, a pillar number within your workplace). That location information is Automatic Location Information (ALI). The entire “lump” of network components is referred to as the 911 Tandem.
Lastly, there is the emergency response center. In 911 lingo we call that the Public Safety Answering Point (PSAP). When we hear a 911 call played back on CCN, we are listening to a conversation that occurs at the PSAP.
Now, I could go into great deal about those functional areas and how a call actually flows through them, but for this blog all you really need to know is that when a 911 call is placed, the caller is connected to a PSAP responder (they do not like to be called operators) and the information about where the caller is calling from is displayed on the responder’s computer console.
This is all fine and dandy and for the most part it works. At least it works in the confines of a system that was designed decades ago and continues to use old and often obsolete equipment and concepts. For instance, the location information about the caller is limited to 240 characters.
Additionally, that location information is often sent to the PSAP across antiquated analog CAMA trunks that use DTMF (telephone touch tones) to pulse the data in something akin to Morse code. Also, when a deaf person uses a TTY terminal to make a 911 call the data that he or she types is sent to the PSAP at 45 baud. Heck, I am a lousy typist and I bet that I can type faster than 45 baud.
All of this leads me to what I would really like to talk about – Next Generation 9-1-1 (NG9-1-1). NG9-1-1 recognizes the need to rethink how 911 calls are processed in terms of the technology and human experiences that are common today. By technology I am, of course, referring to SIP. After all, this is primarily a SIP blog. By human experience I am referring to the fact that the world has moved beyond basic telephones and TTY devices.
These days, we use our telephones for text as much as we do for voice (and if you are less than 20 years old, I would say more). We have also moved to where video applications are plentiful and easy to use. In terms of that TTY, wouldn’t it be a lot more efficient if the deaf caller could establish a video session with the emergency responder and use American Sign Language (ASL) instead of typing his or her emergency?
SIP is the ideal protocol for NG9-1-1 for a number of reasons. First, it is media agnostic. SIP can establish any kind of real time communications flow that you could possibly imagine. While voice, video, and text are the primary concerns of NG9-1-1, SIP is ready to support anything else that might be useful in the future. For example, what if you could use your smart phone to capture an injured person’s vital signs and send them to the emergency responder? Is that too farfetched to imagine? Not for me.
Second, SIP isn’t limited to 240 characters pulsed across an analog trunk after the 911 call has been answered. You can embed far more than 240 characters in a SIP message. Better yet, you can send links that can be used to access large blocks of information that may be of a dynamic nature.
Picture this, you place an NG9-1-1 call and as part of the SIP message you pass a link that can be used to retrieve the real time video from a surveillance camera. Image how much better an emergency could be handled if the responder could see what was happening at that very moment.
I could write about NG9-1-1 for hours, but the point of this blog is to simply introduce you to the topic. I think this is all pretty exciting stuff, though, and plan on returning to this topic in the near future for deeper dives into specific functional areas. As always, stay tuned for more.
Andrew – A nice taster. I’ve been part of the work in the UK on VoIP and Emergency services, one of things that has also concerned us greatly is user mobility enabled through SIP. This can cause real issues when it comes to silent calls to the emergency services. It used to be pretty easy to tie an address to a phone call. With SIP that becomes much more difficult. Yes there are location “enhancements” such as PIDF-LO, but when you interwork back to a PSAP that’s not SIP enabled… well bye bye XML location data. You might like to read the UK NICC (http://www.niccstandards.org.uk/files/current/ND1638%20V1.1.2.pdf) specification for VoIP location, we’ve come up with a creative solution – which we’re trying practically to work through at the moment. I’d welcome your thoughts in future blog entries on this part of 911/112/999.
Thank you for commenting, Neill! You are absolutely right. There are serious location problems when you cross from the IP mobile space to a TDM PSAP. This isn’t new with NG91-1-1, though. I’ve been dealing with that problem since the dawn of the IP PBX. PIDF-LO or no PIDF-LO.
I will be happy to take a look at the work you’ve been doing and come back with my thoughts. As you wrote, this blog was just a taste of 911. There is so much more to say.
Hi Andrew, I
I read the article on management of emergency calls in the UK proposed by Neil Wilkinson above and I’m wondering if here in North America the same appellations are used for equipment, such as
CLI, EHA, VPC, PIG…?
If you have such extensive technical article on the subject for North American system, I’m interested.
Thank you in advance
Thank you for reading and commenting, Ouamor. Unfortunately, I do not know that answer, but I will see if I can find someone that does. Stay tuned.
Ouamor, make sure you read Fletch’s response. He covers all that you asked about and more.
Andrew reached out to me to field your question above. The simple answer to your question is YES. There are several NENA i2 solution providers available today, however I recommend some caution on deployment of VPC services without fully understanding the pieces behind the front end.
While there are 4 primary Tier 1 VPCs (Intrado, TCS, Bandwidth and Level 3) these services are normally sold through a Tier 2 provider that bundles in extra services like Softphone Location services for remote workers and web enabled dashboards. These Tier 2 providers ALL resell the Tier 1 services, so the value add they bring is price, account management and the extras previously mentioned.
A new model that is emerging is an Over the Top NG911 model that takes the information relevant in an Enterprise model, and holds it on a local server ready to be referenced by a URI. That URI can then be sent to the PSAP via any means, including having a single static URI in the records for my building or campus, and then the detail on the server ready to be served via normal web traffic. The information can be in HELD for M2M communication, but it can also be plain text for M2Human consumption.
At this point I now have a managable connection on Port 80 where I can serve whatever data I choose, including live video from an IP camera, floor plans, or other multimedia.
Here’s a YouTube video from 2012 that was presented to FCC at an indoor location accuracy workshop: https://www.youtube.com/watch?v=5hzvPio1UTs
Another is at: https://www.youtube.com/watch?v=cAq5TQlkCxE
The most current version of the presentation I give is located here: https://www.youtube.com/watch?v=ezvEYzBshFU
Hope this helps out some.
Hi Fletch for your answer,
I note, however, that elements Andrew refers in his article are not in the article NICC ND 1638 Issue 1.1.2 (2010-03): ELIN, ERL, MSAG, etc.
these concepts are unique to the American system?
each country has historically developed their own 999/112/etc emergency services strategy, delivery mechanisms and architectures. This diversity leads to different approaches to having to solve the problem of delivering “location” information to the emergency services handling authorities. There are also EU requirements that have to be reviewed against the different EU country solutions. The UK NICC solutions are based on our own unique circumstances, which historically had two Carriers: BT & C&W acting as first contact for callers then routing them to a regional Fire/Police/Ambulance/Coastguard service for dispatch.
Hopefully that gives you some insight as to why there are differences.
The concept of ELIN, ERL, MSAG, etc. are not specific or unique to the American solution, albeit they may be Americanized names that stem from NENA. The concepts generally exist in the EU as well as the US, and there has been considerable work done to socialize the joint existence of both EENA and NENA. There are several folks that participate in both; for example I hold a position on the NENA Institute Board as well as the Co-Vice Chair of the NG112 Committee. I do everything that I can to ensure that both organizations are fulfilling their mission to be the responsible organization representing their global region, while at the same time, working towards standards that are interoperable at a global level. So while the EENA NG112 framework does maintain it’s autonomy, it is completely interoperable with the NENA NG911 08-003 Functional Specification where interoperability is needed.
While ELIN, ERL, and MSAG are not as common by name in the EU, their functionality certainly exists. As the EU embraces more functionality from the MLTS community of users, you will see an increased usage of these terms. I give a lot of credit to the many minds behind both organizations, and can tell you there is a high level of collaboration between all of us. Public Safety is a very small circle within the geographic pockets, but many of those leaders are involved globally, making the total world wide flock of folks, still a fairly small group.
I can safely say “we all know each other very well, and understand the values each of us brings to the table.” 😉