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