EAAC Report on gaps in NENA i3 NG9-1-1
specifications related to EAAC Accessibility reports
1Table of Contents
Executive Summary........................................................................................................................3
1 Overview...................................................................................................................................4
2 Background ...............................................................................................................................4
3 Gaps ..........................................................................................................................................4
3.1 Assisting service related .....................................................................................................5
3.1.1 Risk of not using terminal procedures for NG9-1-1 handling .....................................5
3.1.2 Invocation of Media Communication Line Services instead of usual relay service ....6
3.1.3 Invocation of MCLS on call transfer from Multimedia to audio-only PSAP. .............6
3.1.4 User profile handling....................................................................................................6
3.2 Multimedia call-related.......................................................................................................7
3.2.1 Media handling in multi-party multimedia calls is not well defined. ..........................7
3.2.2 XMPP Messaging and XMPP based real-time text - vaguely described .....................7
3.2.3 Maximum time for sessions of text is too short ...........................................................7
3.2.4 Usage of text together with voice and video is not explicitly specified.......................8
3.2.5 Callback details are not specified.................................................................................9
3.2.6 Method for video fast update requests .........................................................................9
3.2.7 Real-time text flow.....................................................................................................10
3.2.8 Selecting and starting text communication. ...............................................................10
3.2.9 TTY limitations and conventions...............................................................................11
3.2.10 TTY by inband audio or TTY by conversion to real-time text ................................11
3.3 Legacy PSAP related ........................................................................................................13
3.4 Related to users with TTYs. .............................................................................................13
3.4.1 Silent call procedures .................................................................................................14
3.5 Migration related ..............................................................................................................14
3.6 Testing related ..................................................................................................................14
3.6.1 Service provider validation. .......................................................................................14
23.6.2 Lack of test specification............................................................................................14
3.6.3 Inconsistency in test requirements in NENA i3 08-003.............................................14
3.6.4 Is the repetition interval of the test procedure really realistic? ..................................15
Revision History ...........................................................................................................................16
Appendix A: Department of Justice position on accepting text-to-9-1-1 via TTY calls ..............16
3EAAC, 10 July, 2013
Executive Summary
The Emergency Access Advisory Committee (EAAC) has worked since January 2011 to
provide advice on accessibility of NG9-1-1 emergency services. As part of that work, EAAC has
made efforts to foresee emergency accessibility requests and uses by persons with disabilities
when NG9-1-1 is deployed. EAAC has not constrained the examination to the functionality
included in existing specifications of NG9-1-1, but has looked at the functional requirements
and services required to support the needs of persons with disabilities.
The main document that the emergency services industry is using for developing NG9-1-
1 is NENA Detailed Functional and Interface Standards for the NENA i3 Solution 08-003,
commonly called NENA i31. EAAC recognizes that the intent of NENA i3 is to fully meet the
needs for multimedia communication for all users as requirements are identified and fully
acknowledges that this document is an important basis for accessible emergency services based
on modern multimedia communication. However, since the EAAC reports and
recommendations have been developed after the release of NENA 08-003 version 1, there are
some differences between NENA i3 and the implementation requirements identified by EAAC.
In particular, there are a number of gaps in the NENA i3 specification that need to be
addressed before the EAAC recommendations can be implemented. Areas that require further
attention include: support for interpreting, translating and other types of communications
assistance services; handling of multimedia calls, support for text-based conversations,
interoperability of voice calls, and support for TTY calls.
This report on NENA i3 gaps does not claim to be comprehensive. Rather, it focuses on
gaps that have become apparent during the work of the EAAC. NENA i3 is not the only
specification relating to NG9-1-1, and therefore there may be other existing specifications
addressing gaps identified by EAAC. Also, some issues raised in this document may be
resolved in NENA 08-003 version 2, which is pending release by NENA.
The EAAC therefore recommends that this report on gaps in NENA i3 pertaining to
accessible emergency services be taken into consideration in future revisions of NENA i3 as
well as other related specifications. EAAC also recommends analysis of all EAAC reports
during the implementation of NG9-1-1 in order to make sure that support for accessibility is
implemented from the beginning.
.
1 http://www.nena.org/?page=i3_Stage3&hhSearchTerms=08-003
41 Overview
The Federal Communications Commission’s (“FCC”) Emergency Access Advisory
Committee (EAAC) is pleased to offer the following report, evaluating the services and
technology that EAAC has identified for accessible emergency calls and the functionality found
in the NENA Detailed Functional and Interface Standards for the NENA i3 Solution 08-003,
commonly called NENA i32.
In most cases, the identified differences relate to version 1 of NENA i3, compared
against the EAAC reports, available on the FCC website3.
2 Background
The work in EAAC has focused on providing advice on accessibility of NG9-1-1
emergency services. As part of that work, EAAC has made efforts to foresee emergency
accessibility requests and uses by persons with disabilities when NG9-1-1 is deployed. EAAC
has not constrained the examination to the functionality included in existing specifications of
NG9-1-1, but has looked at the functional requirements and services required to support the
needs of persons with disabilities.
The main document that the emergency services industry is using for developing NG9-1-
1 is NENA Detailed Functional and Interface Standards for the NENA i3 Solution 08-003,
commonly called NENA i34. EAAC recognizes that the intent of NENA i3 is to fully meet the
needs for multimedia communication for all users as requirements are identified and fully
acknowledges that this document is an important basis for accessible emergency services based
on modern multimedia communication. However, since the EAAC reports and
recommendations have been developed after the release of NENA 08-003 version 1, there are
some differences between NENA i3 versus and the implementation requirements identified by
EAAC.
There are a number of gaps in NENA i3, described in the following sections, that would prevent
the implementation of an accessible NG9-1-1 system, as per the EAAC report and
recommendations, and that need to be resolved to let people with disabilities participate in NG9-
1-1. Some issues may be resolved in NENA 08-003 version 2, which is pending release by
NENA.
3 Gaps
This chapter contains an enumeration of the observed gaps, by application areas. NENA i3 08-
003 is a framework specification, and thus does not contain details of every aspect of NG9-1-1
calling. It is based on standards and refers to other standards specifications for details. In many
cases, the gaps identify areas where more detailed specifications appear to be needed. Also, in
some cases the gaps point to areas that need further specification or action to enable accessible
NG9-1-1 solutions to be developed.
Some of the identified gaps pertain to areas in the current (version 1) NENA i3 specification that
may not provide the expected functionality or reliability for accessible communications. EAAC
2 http://www.nena.org/?page=i3_Stage3&hhSearchTerms=08-003
3 http://www.fcc.gov/encyclopedia/emergency-access-advisory-committee-eaac
4 http://www.nena.org/?page=i3_Stage3&hhSearchTerms=08-003
5also wishes to point out that the NENA i3 08-003 specification represents a tremendous
tremendous accomplishment in establishing a framework for accessible NG9-1-1
communications, and that the following list of gaps in no way overshadows or diminishes the
work done to date.
In this report, any recommended solutions to the identified NENA i3 gaps should be viewed as
example solutions. It is anticipated that the appropriate standards bodies (e.g., NENA, ATIS,
IETF) should address technical solutions to solve these gaps.
3.1 Assisting service related
3.1.1 Risk of not using terminal procedures for NG9-1-1 handling
While NG9-1-1 services are based on the assumption of direct communication between callers
and PSAPs, the NENA i3 specification also addresses the scenario where a call goes to a relay
service first, and only then is connected to 9-1-1. This is described in Chapter 9 of NENA i3
version 1. IETF RFC 6881 puts requirements on user terminals to detect when users call 9-1-1,
so that location can be added, along with appropriate security and privacy measures, and
location-based routing can be used to route the call to the appropriate PSAP.
However, it appears that gaps exist with respect to describing the handling of emergency calls
made through a relay service. For example, where emergency calls are initially routed to the
relay service, it is possible that the terminal may not provide the required emergency
information (such as inclusion of location information, or location-routing headers) or that
intermediaries inspecting the signaling may not properly interpret the emergency nature of the
call.
In examining the call flows provided within NENA i3, it is noted that some of the call flows
assume that the Relay Service will refer the caller to the PSAP in order to bring up the
emergency call. Use of REFER in this manner may not be supported by some SIP UAs. In any
case, the call flows shown will not result in a conference call where the caller, interpreter and
telecommunicator will have access to all media (see also the section on Media Communication
Line Services below).
If the terminals are under relay service management, the relay services may be able to address
this situation, and establish direct 9-1-1 calls with interpretation in a three-way call if they have
clear requirements to do so. However, if the terminals are mainstream terminals not under relay
service management, then there is currently no specification saying that 9-1-1 calling procedures
shall be applied for the case when the call is made to the relay service with 9-1-1 as final
destination, as described in the next section.
Overall, there appears to be a need to provide more detail on the headers, call flows, and
expected behavior within emergency calls involving a relay service. This should cover both
terminals under relay service management as well as the use of mainstream terminals not under
relay service management.
63.1.2 Invocation of Media Communication Line Services instead of usual relay
service
An assisting service with special emergency service competence, named Media Communication
Line Services (MCLS), is specified in the EAAC Working Group 3 report5. The idea is that
MCLS shall be invoked instead of regular relay services for emergency calls requiring
interpreting and other forms of communication assistance or translation.
MCLS should be invoked automatically when needed. There is a severe risk for frustration,
delays and erroneous service, if calls are made directly to the PSAP, and the PSAP needs to try
to figure out on its own that translation services are needed, and then invoked manually.
There seems to be a need for a smooth way to route calls to relay services or MCLS for legacy
emergency services, and to three-way calls with MCLS participation for NG9-1-1. Automatic
invocation of MCLS and the transition from legacy relay services to MCLS are not described in
NENA i3, and this represents a significant gap.
3.1.3 Invocation of MCLS on call transfer from Multimedia to audio-only PSAP.
If a call is first handled by a multimedia-capable NG9-1-1 PSAP, and then there is a need to
transfer it to some other agency that only supports voice, how is that call handled? Does the first
PSAP stay on the line and act as a kind of relay service, or is a relay service or MCLS included
in the call when it is transferred? Such operational aspects need to be described somewhere.
One way this might work is if the PSAP dials out to the other agency and joins them to the
conference bridge, rather than doing a call transfer. However, rather than making specific
recommendations on these and other situations, NENA i3 tends to present a wide variety of
potential call flows. To achieve interoperability it is desirable to boil down the call flows and
requirements to a smaller set which can be tested.
3.1.4 User profile handling
MCLS describes handling of user profiles indicating user needs in terms of language and
modality supported, or specific kinds of translation services required.
Coding and use of such user profiles are not yet detailed in NENA specifications, and when
established, the use of such profiles must be made known by terminal providers. The use
should include invocation of MCLS services.
Currently, NENA i3 does not describe how language needs (e.g. ASL support) are handled in
either SIP (for call routing) or SDP (for negotiation of capabilities). This is an area where there
is a significant gap in IETF standards.
5 EAAC Working Group 3 Recommendations on Current 9-1-1 and NG 9-1-1 Media Communication Line Services
Used to Ensure Effective Communication with Callers with Disabilities.
http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-319394A1.pdf
73.2 Multimedia call-related
3.2.1 Media handling in multi-party multimedia calls is not well defined.
The NENA i3 08-003 and the NENA transition document 77-501 describe bridging for multi-
party handling of emergency calls. However, handling of media (beyond audio) in multi-party
calls is not described. This includes the details of how H.264/AVC is signaled, the RTP profile
and feedback messages to be used (e.g. RTP/AVPF), support for re-transmission and/or Forward
Error Correction (FEC), etc. In general, the under-specification of video is highly likely to result
in interoperability problems.
Standards and specifications to be used for multi-party handling of the media should be added.
This requirements exists for video, for the different ways to use text, and for pictures and data.
Multi-party MSRP chat was not defined until January 2013, so that future revisions of NENA i3
can refer to this functionality. Multi-party use of SIP MESSAGE is not thoroughly defined in
any standard. Multi-party Real-time text can be supported using standard RTP mechanisms.
3.2.2 XMPP Messaging and XMPP based real-time text - vaguely described
XMPP is a widely implemented standard for text messaging, although proprietary protocols are
also frequently used. A real-time text extension for XMPP (XEP-0301) is currently undergoing
standardization. While NENA i3 mentions that XMPP might be included in future revisions, it is
important to resolve the uncertainty about the status of XMPP within the NG9-1-1 architecture.
Will XMPP ever be natively supported by i3, or do XMPP providers need to convert XMPP to
SIP based RTT or MSRP before sending to 9-1-1? In particular, NENA i3 is not clear whether
the intent would be to support XMPP only for instant messaging and presence, or whether
Multi-User-Chat (MUC) functionality would also be used, and if so, how. If MUC is not
supported, how can MCLS be supported for people with disabilities?; conversely, if MUC is
supported, how does it interface with MCLS?
3.2.3 Maximum time for sessions of text is too short
Section 4.1.9 of NENA i3 includes text describing how to form sessions from distinct SIP
MESSAGEs. The goal is to tie distinct MESSAGEs together into one session that can be routed
to a single call taker from beginning to end so that the context of the "call" is maintained. The
recommended behavior in effect creates a “pseudo-dialog” for MESSAGE, which is not
supported by existing SIP proxies which do not establish conventional dialogs for SIP
MESSAGEs.
NENA i3 section 4.1.9 states the following:
-----Extract from NENA i3 08-003-------------------------------------------
"MESSAGEs received from the same caller within a configurable time (2-3
minutes nominally) should be considered part of the same “call”, and must be routed to the
same PSAP (and the same call taker), regardless of movement of the caller while texting. If the
origination network/device supports non session mode IM to NG9-1-1, it must assure that all
messages from the same caller within this time frame is sent to the same ESInet (same ECRF
query results). If the network/device cannot guarantee this, it must use session mode. The ESRP
8in the ESInet will also maintain a timer for this function and assure that all messages from the
same caller that route to an ESInet will route to the same PSAP."
------End of extract--------------------------------------------------------
The timeout of 2-3 minutes for tying a message to a session is too short. Typing messages on
handheld devices can take a long time. The user may not think that it is important to keep next
message within a short time. It is possible that a new message (e.g. "Now he is bleeding more")
is sent 5 minutes after the previous message. Moreover, people with mobility impairments (e.g.,
cerebral palsy) can take a long time to type out messages, and a 2-3-minute timeout risks cutting
them off.
On the other hand it is a waste of manpower to sit standby with inactive but maintained IM
sessions until they time out. A clear code of practice may be needed to indicate to the user when
the session is to be ended, in a way that keeps the service accessible to people with disabilities.
As a comparison figure, the mean time between messages in the Swedish SMS to 112 service
has been 2.5 minutes in a series of calls reported in the EAAC report on TTY usage in legacy
PSAPs. With that background, an inactivity timeout of around 10 minutes appears more suitable.
The timing issue is also noted in the EAAC report on Interim text to 9-1-1.
3.2.4 Usage of text together with voice and video is not explicitly specified
It is not evident in NENA i3 that all kinds of text communication can be used together with
voice in the same session. This is very important functionality, which is referred to in many
places in the EAAC specifications.
By not spelling out the details of joint text/voice handling clearly, the potential exists that
implementations will not support combined text and voice usage as desired. This potential risk is
present for Real-Time Text, MSRP, SIP MESSAGE as well as TTY (the functionality with TTY
is limited to alternating between using voice and text). The concern is also valid for service
providers supporting other communication methods, that need to convert to NENA i3 protocols
for 9-1-1 calling.
The same issue exists for combining text and voice with video. In doing so, it is possible (or
even likely) that audio, video and text media take different paths through the network, which can
result in the media getting out of sync, or becoming compromised. To address this issue, more
detail is needed on the expected handling of RTP streams, including audio/video multiplexing
and “lip sync”.
Not only does NENA i3 not describe how voice, text and video are used together, it does not
describe in detail how accessibility is to be provided. For example, within a multi-user chat, the
text from an interpreter might need to be handled differently than that from other users who
might cause it to scroll rapidly up the screen.
93.2.5 Callback details are not specified
Callback from the PSAP to the user is an important feature of any emergency call system.
NENA i3 includes material relating to routing of the callback. However, the media aspects are
missing.
While often the callback is made with the same media and codecs as was used in the incoming
call, the PSAP must be provided an opportunity to vary the media in the callback.
Similarly, the callback may include the same kind of assisting services as was included in the
incoming call, or was added by the PSAP, such as the MCLS. However, the PSAP also should
be allowed to change the services included in the callback.
It is also a concern for external service providers that let their 9-1-1 calls go through some
external protocol conversion, that the routing information for the callback must enable the
callback to utilize the same conversion.
An especially complex case is when the incoming call is routed to a legacy PSAP, and the text
communication method in the incoming call is converted to TTY for communication with the
PSAP. In a callback from the PSAP, there should be sufficient information to select the correct
text communication method for conversion from TTY from the calling PSAP to the user. NENA
i3 does not seem to contain guidance on this situation.
3.2.6 Method for video fast update requests
A common cause of video interoperability problems is use of different approaches for video
feedback and repair in the event of packet loss. NENA i3 does not specify the RTP profile to be
supported (e.g. RTP/AVPF), let alone which extended feedback messages (including SLI, NAK
and/or PLI) are required. Required repair mechanisms (such as FEC or re-transmission) are also
not specified. The NENA i3 specifications need to provide these details, since if
implementations use different methods, there is a risk that received video cannot be displayed,
or that quality can deteriorate during the call, potentially to the point where interpretation might
be disrupted.
One common method for sending Fast Update Requests is via a SIP INFO message with XML
contents according to RFC 5168. Another method is via RTCP, which according to RFC 5104
should be negotiated via SDP. This method is recommended by IETF for new implementations.
So a complete implementation should try to negotiate the RTCP based method, and if that fails,
use the INFO based method. This is used for both recommended video codecs for NENA i3:
H.263 and H.264. Thus, the negotiation between RTCP vs INFO methods for FIR is
recommended.
There is also an obsolete way to send it via RTCP defined in RFC 2032, originally made for
H.261. This method should not be supported for NG9-1-1.
10
3.2.7 Real-time text flow.
The goal of real-time text is to avoid the waiting times appearing in other kinds of text
communication. Therefore text shall be sent while it is typed. The RFC4103 specification
required by NENA i3 for real-time text transport recommends a transmission interval of 300 ms.
That time is selected to allow good flow in the communication and cause very little network and
endpoint load. By transmission while typing valuable time is saved, and the calling users are
kept assured that their case is actively handled. The same default transmission interval should be
recommended for use by PSAPs, so that good flow of real-time text is achieved.
Also for the presentation level of real-time text in the PSAPs, it should be specified that
characters should be made available for transmission as soon as they are typed, in order to avoid
PSAP implementations from just using real-time text transmission with a message oriented user
interface.
3.2.8 Selecting and starting text communication.
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.
Capability for RTP-based Real-time text and MSRP are indicated in call control negotiation in
SDP before it is used. But a call can also start without such capability indication, and it can be
added later in a call by re-invite.
Capability for SIP Message is not indicated in SDP. It may be indicated in the ALLOWS
parameters and METHODS tags, but there is no requirement to do so. So sending SIP Message
is commonly done by chance, just hoping that the other party handles it.
If reinvites shall be part of the solution, there must be a clear specification saying what elements
are expected to make reinvite.
11
Also, if one party specifies more than one text communication method in SDP, it must be
specified what the other party should do. Should the methods for describing alternative media in
SDP be assumed to be followed strictly, so that declaration of multiple text methods without any
indications that they are alternatives for the same stream results in them being wanted
simultaneously?
Further specification of this area is needed.
3.2.9 TTY limitations and conventions.
The more modern kinds of text communication are used, the harder it will be for the call takers
to remember to respect the limitations of the TTY and the usage conventions developed to cater
to these limitations. There may be a need for system support to the call taker to obey the
conventions.
In TTY communication a party must not transmit while the other party is transmitting.
This is controlled at user level by a formal turn-taking token "GA" in the text.
There is also a user convention on how to end a call by exchange of GASK -- SKSK.
Call takers need indications in which calls to use these conventions, for both TTY inband and
TTY converted to real-time text.
They may also need system support to not transmit while the user is transmitting.
In TTY mode, voice can only be used when no party sends text. The switching between voice
and text in these calls also needs system support.
System support for avoiding problems caused by these limitations are documented in at least
five EAAC documents: The original EAAC report, the TTY transition report6, the report about
TTYs as text terminal in legacy PSAPs7, the report about TTY user access to NG9-1-18, and the
report on interim text-to-9-1-19. These recommendations should be taken into consideration in
the detailed NG9-1-1 specification.
3.2.10 TTY by inband audio or TTY by conversion to real-time text
There are many reasons why it is complicated to maintain support for TTY inband by audio
tones. E.g. the need for multi-party bridging of calls, and transfer of calls to remote PSAPs.
Specifications are needed for how to handle these situations.
One of the two solutions described in NENA i3 says that the PSAP work stations within a PSAP
all must detect and produce TTY tones in the voice channel of SIP calls. They must be prepared
to handle TTY in that way in all calls, in three-way calls and transferred calls etc. So, with this
6 EAAC report on TTY transition. http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-319386A1.pdf
7 EAAC TTY Transition: Proposed procedures for TTY as text terminal in legacy PSAPS,
http://www.fcc.gov/document/eaac-tty-transition-proposed-procedures-tty-text-terminal-l
8 EAAC report on procedures for TTY user access to NG9-1-1,
http://transition.fcc.gov/Daily_Releases/Daily_Business/2013/db0619/DOC-321705A1.pdf
9 Report of Emergency Access Advisory Committee (EAAC) Subcommittee 1 on Interim Text Messaging to 9-1-1.
http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-319329A1.pdf
12
solution there will be VoIP-audio carried TTY calls going from one PSAP to another, and to
external assistance etc, with all the problems that transmitting TTY tones via VoIP entails. As
described in the TTY transition report, TTY in VoIP audio channels is often hurt by line echo
cancellers, jitter, packet loss, comfort noise insertion, audio coding, etc. There is a great risk for
quality problems if this option of handling TTY calls is retained in NENA i3.
This is the current section in NENA i3:
---------Extract from NENA i3 08-003--------------------------------------------------------------------
4.1.8.4 TTY (Baudot tones)
NG9-1-1 anticipates that deaf and hard of hearing callers will migrate from TTY to other forms
of communication including real time text devices and various forms of relay. Although use of
TTY is expected to decline, it cannot be assumed that TTY will be completely gone by the time
transition to NG9-1-1 is complete. Therefore, PSAPs must be capable of receiving calls from
TTYs.
It is possible to have a transcoder in the path of every voice call which would recognize baudot
tones, and replace them with RFC4103 [118] real time text on incoming (with respect to the
ESInet) RTP media, and terminate RFC4103 real time text and synthesize baudot tones for
outgoing RTP. If an ESInet can assure that ALL calls, including diverted calls, calls transferred
from another ESInet and all calls from any origination network will pass through the transcoder,
such an architecture is acceptable. The transcoder must be compliant with RFC5369 [119].
Where all calls are answered at a bridge, the bridge can provide the transcode service. It may be
practical to place a transcoder at the edge of a PSAP to serve all endpoints inside that PSAP.
For ESInets where it cannot be assured that all audio calls will transit such a transcoder, the
PSAP User Agents, conference bridges, Interactive Media Response units, etc. will need to
recognize baudot tones and display text, as well as accept typed text and generate baudot tones.
--------End of extract-----------------------------------------------------------------------------
The red marked italics text parts are the ones introducing quality risks for TTY calls and create
enormous work for technology providers to sort out the problems associated with the suggestion
to handle TTY tones in the audio channel all the way to all PSAP work stations.
A possible solution would consist of the following changes:
"It is possible" should be changed to "it is required"
"It may be practical" should be changed to "It is needed"
The paragraph beginning "For ESInets" should be deleted.
A motivation should be inserted:
"The quality of a TTY call is at risk when transported in the audio channel in an IP network."
By these changes, the reason behind having "if" and "would" in a few places in the section are
lost, so the sentences must be reformulated.
This is a proposed wording:
------------------------------------Proposed changed section-------------------------------
"4.1.8.4 TTY (Baudot tones)
NG9-1-1 anticipates that deaf and hard of hearing callers will migrate from TTY to other forms
13
of communication including real time text devices and various forms of relay. Although use of
TTY is expected to decline, it cannot be assumed that TTY will be completely gone by the time
transition to NG9-1-1 is complete. Therefore, PSAPs must be capable of receiving calls from
TTYs. The quality of a TTY call is at risk when transported in the audio channel in an IP
network.
A transcoder is therefore required in the path of every voice call which will recognize baudot
tones, and replace them with RFC4103 [118] real time text on incoming (with respect to the
ESInet) RTP media, and terminate RFC4103 real time text and synthesize baudot tones for
outgoing RTP.
An ESInet must assure that ALL calls, including diverted calls, calls transferred from another
ESInet and all calls from any origination network will pass through the transcoder. The
transcoder must be compliant with RFC5369 [119]. Where all calls are answered at a bridge,
the bridge can provide the transcoding service. It is important to place a transcoder at the edge of
a PSAP to serve all endpoints inside that PSAP.
------End of proposed changed section-------------------------------------------
3.3 Legacy PSAP related
There are many questions centering around interfacing with legacy PSAPs during the transition
to NG9-1-1. These questions take on a renewed urgency, as the Department of Justice has
clarified that PSAPs must be able to accept modern forms of text communications via TTY calls
(however, PSAPs may also use an IP system to receive SMS)10.
How far is it feasible to use the TTY + voice capability in legacy PSAPs for accessible calls
with multimedia devices?
If calls with real-time text or messages are converted to TTY, how do the functional limitations
of the TTY threat the usability of the calls, when the user has modern text features? Should such
calls rather be refused or rerouted to NG9-1-1-capable PSAPs, or only connected by voice? Can
NG9-1-1 ready PSAPs handle NG9-1-1 calls with multimedia in place of legacy PSAPs who
are originally responsible for the location where the user is?
How shall else calls be handled that would contain more media than the legacy PSAP is capable
of handling but are needed in the call for accessibility reasons?
If ways are designed for handling accessible multimedia calls with legacy PSAPs, how will then
mainstream calls with similar media combinations be handled?
See also section 3.2.9 and its references.
3.4 Related to users with TTYs.
10 DOJ Comment to FCC’s NPRM on Text-to-9-1-1. http://apps.fcc.gov/ecfs/document/view?id=7022129201,
replicated in Appendix A.
14
3.4.1 Silent call procedures
For TTY call initiation, there is currently a cumbersome procedure defined that all PSAPs must
follow for all silent calls. After some seconds of silence in the call, the call taker shall prompt
the caller with a short TTY text sequence to check if there is a TTY calling. It is possible to
initiate a call with voice only and add any of the modern text communication methods during the
call. This makes it apparent that we have a risk that the PSAP prompting procedures need to be
extended to try all 5 text communication methods. Suitable specifications should be established
to avoid the need for this kind of prompting for modern text methods in silent calls.
It should be investigated and specified if any new introduced communication methods require
prompting, and time waste on prompting and waiting for answers should be minimized.
Assistance by the technical system with the prompting and detection should be specified if such
prompting is needed.
A plan to delete the TTY prompting when TTYs have been phased out should also be included.
3.5 Migration related
How can consistent understandable information be composed about how users shall expect
accessible 9-1-1 services to work during the transition period? Will it be necessary to say in
public information on NG9-1-1: "You may be able to use text messages in the call, depending on
what capabilities the PSAP has that you get connected to?
Or "The performance of text communication with 9-1-1 will be different depending on if the
PSAP you get connected to has upgraded to NG9-1-1 or not.
3.6 Testing related
3.6.1 Service provider validation.
There are many SIP user terminals and service provider systems that have incomplete SIP
implementations. Some may malfunction when they encounter the SIP operations described in
i3. Some kind of automated test system for service providers to validate their services and user
terminals for 9-1-1 use seems to be needed. The procedure should contain actions with the new
media introduced by i3.
3.6.2 Lack of test specification.
Chapter 11 of NENA i3 08-003 v.2 specifies that testing shall be done of all media with the
method specified in RFC 6849. But that test specification is only specified for the RTP based
media : audio, video and real-time text. Message based communication by SIP Message and
MSRP is left without a test specification. A test specification for SIP Message and MSRP should
be added to chapter 11.
3.6.3 Inconsistency in test requirements in NENA i3 08-003
Section 5.6.1 says " PSAPs must support the test call interface"
Section 5.6.12 says " The PSAP may deploy the test call function as described in Section 11."
For consistency, 5.6.12 should also have a "must" requirement.
15
3.6.4 Is the repetition interval of the test procedure really realistic?
Will the test procedures create too high load? The test procedure referenced from chapter 11 is
described in RFC 6881. There it says that user terminals shall repeat the test every 30 days and
after each boot-up and location change.
Some user terminals are booted up every day, some are mobile and move, others are continually
on and stationary. Assume that the mean interval between tests will be 10 days per user terminal.
Statistics say that there are approximately 1000 days between real reasons to call 9-1-1. That
means that the number of test calls will be 100 times more than the real calls.
The media load will still be low, about 10 packets per test call compared to maybe 20 000 for a
real call. But the SIP transaction load from heavy transactions as INVITE will be approximately
100 times higher than the load from real calls. Such evaluations must have been behind the
current recommendations in RFC6881, but should maybe be revisited. If it is found that they
will generate too high a load, the requirements on user terminals need to be changed somehow.
16
Revision History
Date Version Description
5/29/2013 0.1 Initial version by Gunnar Hellström
6/7/2013 0.2 Edits by Bernard Aboba
6/10/2013 0.3 Edits by Christian Vogler
6/11/2013 0.4 Edits by Gunnar Hellström
6/11/2013 0.5 Edits by Christian Vogler and Gunnar Hellström
6/12/2013 0.6 Edits by Gunnar Hellström
6/16/2013 0.7 Edits by Bernard Aboba and cleanup by Christian Vogler
6/28/2013 0.8 Gunnar Hellström, Moved section 3.3 and inserted recent EAAC report references
7/10/2013 0.9 Inserted AT&T proposals, clarification requested by Richard Ray
Appendix A: Department of Justice position on accepting text-to-9-
1-1 via TTY calls
The following letter was filed by the Department of Justice in the FCC proceedings on text-to-9-
1-111, and is replicated in full on the next page, due to the potential impact on legacy PSAP
procedures during the transition to NG9-1-1.
11 DOJ Comment to FCC’s NPRM on Text-to-9-1-1. http://apps.fcc.gov/ecfs/document/view?id=7022129201
17
March 8, 2013
VIA ELECTRONIC FILING
Ms. Marlene H. Dortch
Office of the Secretary
Federal Communications Commission
445 12th Street, S.W.
Washington D.C. 20554
Re: In the Matter of Facilitating the Deployment of Text-to-911 and Other
Next Generation 911 Applications; Framework for Next Generation 911
Deployment, PS Docket No. 11-153, PS Docket 10-255, Further Notice of
Proposed Rulemaking, FCC 11-134, 26 FCC Rcd 13615 (rel. Dec. 13,
2012); 78 Fed. Reg. 1799 (Jan. 9, 2013).
Dear Ms. Dortch:
The U.S. Department of Justice (Department) submits these comments in response to the
Federal Communications Commission (FCC)’s Further Notice of Proposed Rulemaking,
Facilitating the Deployment of Text-to-911 and Other Next Generation 911 Applications;
Framework for Next Generation 911 Deployment, PS Docket No. 11-153, PS Docket 10-255
(FNPRM). In particular, the Department is responding to the FCC’s request in the FNPRM for
comment on whether the default preference for a Public Safety Answering Point (PSAP) should be
text-to-TTY delivery when the PSAP does not declare its text delivery option preference by a
certain date.
Title II of the Americans with Disabilities Act (ADA) applies to State and local government
entities and, in Subtitle A, protects qualified individuals with disabilities from discrimination on
the basis of disability in services, programs, and activities provided by State and local
governments. See 42 U.S.C. §§ 12131-32. Title II extends the prohibition on discrimination
established by section 504 of the Rehabilitation Act of 1973, as amended, 29
18
U.S.C. § 794, to all activities of State and local governments regardless of whether these entities
receive Federal financial assistance. 42 U.S.C. §§ 12131-65. The ADA directs the Attorney
General to promulgate regulations to implement the requirements of title II, except for certain
provisions dealing specifically with transportation. 42 U.S.C. § 12134. See 28 C.F.R. part 35.
The Department’s title II regulation requires that public entities—including PSAPs—that
communicate by telephone with applicants and beneficiaries use TTYs or another equally effective
telecommunications system to communicate with individuals who are deaf or hard of hearing or
have speech impairments—unless the entity can demonstrate that doing so would result in a
fundamental alteration in the nature of a service, program, or activity or in undue financial and
administrative burdens. 28 C.F.R. §§ 35.161(a), 35.164. Accordingly, under § 35.161(a) of the
current title II regulation, PSAPs must, at a minimum, use TTYs or other equally effective
telecommunications systems to communicate with individuals with hearing and speech
disabilities.12
The Department recognizes that many individuals with disabilities now use wireless text
devices and the Internet, rather than analog-based TTYs, as their primary modes of
telecommunications. Our understanding from the FNPRM is that PSAPs may use existing TTY-
based telecommunications systems to process text (SMS)-to-TTY calls. Therefore, in fulfillment
of their existing obligation to provide effective communication under title II of the ADA, PSAPs
must accept a call from a person with a hearing or speech disability that originates as an SMS call,
but reaches the PSAP as a TTY call. A title II entity’s obligation under § 35.161(a) to
communicate using a TTY or equally effective telecommunications system is not contingent on
how the call originates. Accordingly, a PSAP that receives a TTY call must use a TTY (or equally
effective telecommunications system) to communicate with individuals with hearing and speech
disabilities regardless of how the communication originated, unless the entity can demonstrate that
doing so would result in a fundamental alteration in the nature of a service, program, or activity or
in undue financial and administrative burdens. 28 C.F.R. §§ 35.161(a), 35.164.
12It is important to note, however, that PSAPs have a greater responsibility to individuals who use TTYs (cited as
Telecommunications Devices for the Deaf (TDDs) in the regulation) or computer modems. For these users, § 35.162
requires PSAPs to provide direct access to 9-1-1 services and, thus, PSAPs may not require TTY or computer modem
users to use relay services to call 9-1-1. In its Advance Notice of Proposed Rulemaking on the Accessibility of Next
Generation 9-1-1 services, the Department made clear its intention to maintain the direct and equal access to 9-1-1
services requirement for individuals with disabilities in any revision to its title II regulation. See 75 FR 43446 (Jul. 26,
2010).
19
The Department also recognizes that some PSAPs have upgraded their emergency
telephone systems to incorporate an Internet Protocol (IP) system. As such, some of these PSAPs
may choose to use the upgraded IP system (or stand-alone IP-ready working station) to accept
SMS-originated calls, but must still answer TTY-originated calls using a TTY. If title II entities
choose to accept SMS calls from individuals with disabilities through an IP system, the Department
would consider that as using an equally effective telecommunications system; thus, such entities
would be in compliance with § 35.161(a).
As noted above, the FCC in paragraph 145 of the FNPRM asked, “Should there be a default
preference to ensure that PSAPs that do not declare their text delivery option by a certain date are
then assumed to prefer text-to-TTY delivery, since that option should be available without further
PSAP action?” Based on the Department’s analysis above, PSAPs are required under the existing
title II regulation to accept TTY calls from persons with disabilities, even if they originate as SMS
calls, subject to the established defenses of fundamental alteration and undue financial and
administrative burdens. The Department believes that the FCC’s proposed use by wireless carriers
of a default preference for non-responding PSAPS of the SMS-to-TTY delivery option would
further the goal of facilitating PSAPs’ compliance with the Department’s implementing regulation
pursuant to title II of the ADA.
Respectfully submitted,
Eve L. Hill
Senior Counselor to the Assistant Attorney General
Civil Rights Division