Getting to NG911 by Persons with Disabilities
Getting to NG911 by Persons with Disabilities by Bill MacKay
Think back over the last 10 years and of some the innovations that we now take for granted in our day-to-day lives. Technically Bluetooth has been around for a while, but now can be found in almost everything on the market. Smart Phones, Tablets, Skype, Wi-Fi, all have made their mark in the marketplace, and are changing the way in which we live and communicate. Add email, instant messages, video chat and text messages and our ability to communicate has been profoundly changed forever.
In the event of an emergency, calling 911 using some of this technology is not easy or straightforward and in most cases may result in an uncompleted call. If you have a hearing impairment or are deaf, the options available for communications in a 911 situation are even more restricted because of technology that was developed in the 1960s that is still in use today.
Ask someone under the age of 20 what an acoustic coupler is and you’re likely to get a blank stare, yet without that piece of technology a TTY (teletypewriter for those that may have forgotten) doesn’t function. In an emergency, that is the technology that must be used. It’s slow, cumbersome, and requires a protocol of conversation to signal (GA to indicate Go Ahead) to the other end of the call that you have finished.
Recently, the Federal Communications Commission’s Emergency Access Advisory Committee (EAAC) provided a report that “looked at the functional requirements and services required to support the needs of persons with disabilities.” The report is intended to identify the gaps that exist in the current NENA i3 standards that have been developed to support Next Generation 9-1-1 (NG911).
The following provide some examples of the issues NG911 is facing from the needs of the EAAC’s perspective.
There is a requirement that there be an ability to detect and produce TTY tones in the voice channel of SIP calls. Once that hurdle has been cleared, let’s transfer the call to get external assistance and include the TTY tones without any packet loss, jitter, line echo or any of the other issues associated with VoIP. That may mean the need to migrate away from TTY altogether, but the need to provide 911 will still exist.
There has been a need to develop the Media Communication Line Services in able to support NG911. This service is intended to provide direct connection to NG911 using multi-modal communication that may make video, text and or voice calls. The challenge here is to provide direct access to 911 services to qualified sign language interpreters using whatever form of communication (video, voice or text) required as determined or required by the user.
This will require the signaling needed to provide the PSAP with the preferred method of communication and perhaps any language needs. If the call is handled by a multi-media NG911 PSAP, what happens if the call is then transferred to a voice-only service? This also assumes that the voice only service is SIP-enabled.
The last section I wanted to include is the “selecting and starting text communication.” To quote directly from the report –
“Methods for selecting what text communication protocol to use, and how to start the communication need to be specified. The currently specified methods are:
-
TTY in-band
-
TTY converted to real-time text
-
RTP-based real-time text according to RFC 4103
-
MSRP text message
-
SIP Message in dialogue
-
SIP Message out of dialogue
There is also SMS converted to MSRP added by the text-to-911 activity.
It cannot be expected that the call-taker shall be required to decide among these technical methods for a callback, or for an extension of a call with more media. But automatic selection may be impossible. Some guidance is needed for what text communication method to select.
Capability for TTY inband by the user terminal is not reliably announced in any way in the call setup. It may be announced by the user typing or tapping space bar, causing transmission of TTY tones, but more often the calling TTY user is silent until a TTY response is tried by the PSAP.” *
The report also points out that if one method is chosen as a preferred platform, there needs to be a specification of what the other party needs to do and that additional specification will be required.
A number of other functional issues are identified and it underscores that getting to NG911 deployment isn’t going to be without bumps.
A full copy of the report can be found here. https://transition.fcc.gov/Daily_Releases/Daily_Business/2013/db0715/DOC-322164A1.pdf
* Source - EAAC Report on gaps in NENA i3 NG9-1-1 specifications related to EAAC Accessibility reports