Emergency Access Advisory Committee (EAAC) Report on procedures for calls between TTY users and NG9-1-1 PSAPs. - EAAC report on Procedures between TTY users and NG9-1-1 PSAPs - June, 2013 - Page 2- June 14, 2013 EAAC report on Proposed Procedures for calls between TTY users and NG9-1-1 PSAPs. Procedures for calls between TTY users and NG9-1-1 PSAPs. This document is a report to the FCC from the Emergency Access Advisory Committee (EAAC). The report is a study on suitable procedures for calls between TTY users and NG9-1-1 PSAPs. The TTY has many functional limitations compared to modern text communication and special care must be taken so that these limitations do not cause quality degradations in contact with NG9-1-1 PSAPs. The report is intended to provide material for implementation of support for these procedures in the points where conversion takes place between TTY communication and real-time text and audio communication in the PSAP equipment. It also relates to the working procedures for PSAP telecommunicators. Contents 1. Summary....................................................................................................................................................... 3 2. Scope ............................................................................................................................................................ 3 3. Background and brief outline of application................................................................................................ 3 3.1 Use of TTY text and audio to NG9-1-1 with real-time text..................................................................... 4 4. Facts and conventions about the TTY .......................................................................................................... 5 4.1 TTY technology ....................................................................................................................................... 5 4.2 DOJ and NENA TTY Procedures .............................................................................................................. 5 4.3 Conventions............................................................................................................................................ 5 5. TTY functions, limitations and risks.............................................................................................................. 6 5.1 One transmission direction at a time..................................................................................................... 6 5.2 Use of audio only when not involved in text transmission .................................................................... 6 5.3 Slowness ................................................................................................................................................. 6 5.4 Only upper case or lower case characters - not both ............................................................................ 7 5.5 Limited character set.............................................................................................................................. 7 5.6 Limited display area ............................................................................................................................... 8 5.7 Telephone network tones disturb reception ......................................................................................... 8 5.8 Risk for corruption or loss of characters ................................................................................................ 8 5.9 Risk for corruption of long series of characters ..................................................................................... 9 5.10 PSAP operators not following TTY conventions ................................................................................... 9 5.12 No way to interrupt the TTY user while typing .................................................................................... 9 5.13 Spurious characters from ambient sound............................................................................................ 9 5.14 Need to follow start, end and turn-taking conventions....................................................................... 9 5.15 Hard to automatically detect if the other party gets the transmitted text....................................... 10 6. Recommended procedures ........................................................................................................................ 10 6.1 Recommended procedures for conversion between user's TTY and RTT in NG9-1-1 PSAP. ............... 12 6.1.1 Procedure elements ...................................................................................................................... 13 6.1.1.2 Receive from TTY........................................................................................................................ 13 6.1.2 Procedures..................................................................................................................................... 14 7. Conclusions................................................................................................................................................. 15 Appendix A. Letter from DOJ filed as comment to FCC on text-to-9-1-1....................................................... 16 - EAAC report on Procedures between TTY users and NG9-1-1 PSAPs - June, 2013 - Page 3- 1. Summary The report describes a number of functionality limitations in the TTY text communication device used by some deaf, deaf-blind, hard-of-hearing and speech disabled persons to reach 9-1-1 PSAPs, and how these limitations influence the communication with NG9-1-1 PSAPs using Real-time text and audio terminals. There are many limitations, like risk for transmission collision garbling text, slow transmission introducing long delays, transmission errors garbling text, limited character set making ambiguous character replacements needed etc. Procedures limiting the collision risks are provided. The procedures are intended to be executed in the NG9-1-1 Legacy Network Gateways, or other gateways converting between TTY users and Real-Time Text PSAPs. Risks appearing from the fact that at least 5 types of text communication is specified in the NENA i3 specifications for NG9-1-1 are also discussed and approaches to keep the remaining risks low. 2. Scope This document is a report from a study made mainly theoretically for how calls with existing TTY user terminals can be made as reliable as feasible, and be made convenient to handle in the modern multimedia communication environment in NG9-1-1 PSAPs. The limitations of TTYs are presented and their effect on communication problems discussed. The study presents risks, indicates situations when the risks are most probable to appear, and proposes remedies by communication procedures executed in the NG9-1-1 LNGs. 3. Background and brief outline of application Since long, 9-1-1 emergency services in USA have had functionality to handle calls in text and voice with users of the PSTN based text telephone type called TTY. The TTY transition report from EAAC shows that the number of TTYs in use is decreasing, but it is not yet realistic to withdraw support of TTY in 9-1-1 services. The support for calls with TTYs is also included in the NG9-1-1 standards and specifications. The recommended way to handle TTY user communication in NG9-1-1 services is to convert the calls to SIP calls with audio and real-time text. In the development of new ways to communicate with 9-1-1 emergency services that offer better usability and accessibility, some text communication technologies are introduced. The short messages, SMS, of the text-to-9-1-1 service, and the real-time text medium in IP based calls are introduced. Two types of IP-based instant messaging services are also specified in the NG9-1-1 standards: The SIP MESSAGE and the MSRP. XMPP is mentioned as a possible future extension. TTY communication has some severe functional limitations compared to the modern text communication methods, but also some enhancements over the message based communication methods. The users of TTY adapt to the limitations of the TTY by applying strict turn-taking between text transmission in the different directions, and between use of text and audio. Turn-taking is managed by sending specific text tokens typed by the users. If these rules are not obeyed, there is loss and corruption of text in the calls. With the new text communication methods, text can be typed and sent in both directions simultaneously, and in cases when text and audio can be used in the same call, these media can be used simultaneously. - EAAC report on Procedures between TTY users and NG9-1-1 PSAPs - June, 2013 - Page 4- It is expected that very soon, the new ways to do text communication will dominate over use of the TTY for 9-1-1 calls. Under such circumstances it may be cumbersome for the PSAP telecommunicators to remember to follow the turn-taking rules strictly when communicating with users with TTYs, and use the higher functionality of the modern text communication methods in communication with them. Therefore it is very desirable to implement the support for TTY user communication with NG9-1-1 PSAPs in such a way that the influence of the functional limitations of the TTY is limited on the working procedures of the PSAP telecommunicators and so that risks for text loss and corruption is limited even if the telecommunicator happens to deviate from the TTY turn-taking habits. The report describes the limitations and technical procedures that are proposed to be implemented in the points of conversion between the PSTN based TTY communication with the users and the modern NG9-1-1 supported text and audio communication methods. One such point of conversion is the Legacy Network Gateway LNG, briefly described in NENA Detailed Functional and Interface Standards for the NENA i3 Solution 03-0081. DOJ has recently in a comment to FCC2 confirmed the requirements on legacy and IP based PSAPs to support TTY and modern forms of text communication in 9-1-1 calls. The comment is also attached as Appendix A. 3.1 Use of TTY text and audio to NG9-1-1 with real-time text The EAAC has reported the definition of an IP based replacement for the TTY for use of real-time text and audio. They are directly compatible with the NG9-1-1 PSAPs as defined in NENA i3. But there is an expectation that the TTYs installed in current PSAPs would be possible to use for the exchange of text and voice between the user and the PSAP telecommunicators. This is reported in the TTY transition report from the EAAC3. The solution is a real-time text terminal with possibility for simultaneous real-time text and audio in both directions. The limitations of the TTY will influence the performance of this application. The solution need to contain an automatic procedure for supporting the difference between the fully simultaneous real-time text and audio performance and the limited real-time text type interface with alternating between text and audio of the TTY. This procedure can contain parts intended to minimize the effects of the limitations. The document has the ambition to describe how to perform communication with the TTYs for this purpose. 1 NENA Detailed Functional and Interface Standards for the NENA i3 Solution http://www.nena.org/?page=i3_Stage3 2 DOJ comment to text-to-9-1-1. http://apps.fcc.gov/ecfs/document/view?id=7022129201 3 http://www.fcc.gov/document/emergency-access-advisory-committee-eaac-report-tty- transition - EAAC report on Procedures between TTY users and NG9-1-1 PSAPs - June, 2013 - Page 5- 4. Facts and conventions about the TTY 4.1 TTY technology The TTY is a technology for text transmission in the analog telephone network PSTN character by character as typed. It uses a modem and character codes and other transmission conventions standardized in TIA 825A, as well as in ITU-T Recommendation V.18 Annex A including its Addendum 1. https://www.itu.int/rec/T-REC-V.18/en When the line is not used for text transmission, it can be used for audio transmission. Users use this feature for alternating between text and voice in the call. The characters are transmitted with FSK modulation at 45.45 bits/second. The bits are thus 22 ms long. The FSK frequencies are 1400 Hz for 1 and 1800 Hz for 0. Each character contains one start bit, 5 data bits and a stop bit. The stop bit is at least 1.5 bit-times in length. The start bit has value 0, the stop bit value 1. Characters are followed with the tone for 1 up to about 300 ms or until next character is sent. See the standards for more details. 4.2 DOJ and NENA TTY Procedures DOJ has defined requirements and procedures for TTY access to 9-1-1,in "Access for 9-1-1 and Telephone Emergency Services"4. NENA have defined procedures for 9-1-1 call handling with TTYs, intended to meet the DOJ requirements. The procedures are documented in NENA 56-004 TTY/TDD Communication SOP. 5 These documents take the technological limitations of the TTY in consideration and align the operational procedures with the conventions used among TTY users. 4.3 Conventions The fact that the TTY can only transmit in one direction at a time has created a need for strict turn-taking habits. When one user wants to give turn to the other, they end their typing with " GA" for Go Ahead. The other party is waiting until this indication is received, before typing. This way of working needs to be maintained so that the PSAP gets similar working conditions with different kinds of text terminals in the user end. When calling, the convention is just as for voice calls. The answering part starts transmitting text. The caller might possibly send just a few space characters as indication that a TTY is calling, but need to keep 4 http://www.ada.gov/911ta.htm 5 http://www.nena.org/?page=TTY_TDD_SOP - EAAC report on Procedures between TTY users and NG9-1-1 PSAPs - June, 2013 - Page 6- such prompting transmissions as short as possible and stop sending them as soon as the other party sends something. The one who want to end a call types " SKGA" . "SK" stands for Stop Keying. The one who then accepts to end the call ends the text with " SKSK". Since these conventions are handled by humans, there may be variations. User might type "GASK" or "GA TO SK" instead of SKGA, and they may make a new line or a few spaces after the turn-taking token. 5. TTY functions, limitations and risks This chapter describes known functional limitations in the TTYs that may influence performance in the applications in scope. 5.1 One transmission direction at a time The TTY can only do one thing at a time. Either receive text, or transmit text or let users communicate in voice. If transmission of text is made anyway, while text is received, it is likely that text in both ways is garbled or lost during the time that concurrent transmission occurs. Users apply strict turn taking as described in section 4.3 to avoid the loss of this reason. 5.2 Use of audio only when not involved in text transmission While it is possible to alternate between use of voice and text during a call, voice transmission is cut out during periods of text transmission with the TTY. Therefore users need to agree on using the alternating voice and text mode, and then use a strict turn- taking procedure between using text vs voice so that the users are in sync with their equipment. 5.3 Slowness TTY transmission is only at a speed of around 5 characters per second. Some fast human typing persons can reach 20 characters per second. The result is that the TTY is slower than typing in many situations. When that happens, a transmission queue of characters is built up and delays occur. The delays are especially noticeable between when the typing person finishes typing and expect a response and the time when the complete text is actually delivered to the other party and composing a response can actually be started. The TTY transmission is made in parallel with the person typing, so problems will appear only when typing more rapidly than 5 characters per second. It is disturbing and cause extra delays. Influence for the TTY replacement case: Low but not neglectable. - EAAC report on Procedures between TTY users and NG9-1-1 PSAPs - June, 2013 - Page 7- 5.4 Only upper case or lower case characters - not both The TTY has a limited character set. One limitation is that only one case is used. Thus, characters are shown only as upper case or only as lower case, not both. The telecommunicators will eventually have a hard time to remember the limitations of the TTY, and not know that the user terminal has this limitation, so there is a risk that text is sent where the difference between capitals and lower case is significant for understanding and using the information. In a few types of Internet addresses are case sensitive and will not work if the case information is lost. In other cases, where a mix of lower case and capitals are used, a bit of hesitance to read and understand might occur, but usually no dangerous misunderstanding will occur. Passwords are usually case sensitive, so if there is a case when a user needs to explain a password to the other party, it can be hard and take a lot of extra time. That is however probably a very rare situation. 5.5 Limited character set The TTY has a limited character set. Only a few special characters can be expressed. The special characters that can be expressed are: 0-9, Backspace, Line Feed, Return, Space, - $ ' , ! : ( " ) = ? + . / ; Thus the following quite common characters cannot be expressed: @ # % & \ * _ < > Also characters used in some languages, such as Ñ É cannot be used. This limitation causes a risk for lost information from the telecommunicator to the user, and problems to express some items from the user to the telecommunicator. One part-wise solution is to use standardized translation of the special characters that have no representation in the TTY. Such translations are documented in ITU-T Recommendation V.18, Annex A. The recommended translations are: @ => (at) (Note: This differs from the proposal in V.18 where character X is proposed.)) # => $ % => / & => + * => . _ => space < => ( > => ) These translations can cause dangerous misunderstandings. It is e.g. not uncommon that codes needed for passing doors or calling on a door phone requires use of # and *. An instruction from the telecommunicator to the user to dial *224# would be translated to .224+ to the user, and that might not be immediately clear what that means. - EAAC report on Procedures between TTY users and NG9-1-1 PSAPs - June, 2013 - Page 8- The "@" sign is recommended to be translated to "(at)". The implementer need to keep track of the difference in number of characters in case of erasure. In transmission from the user, the lack of these characters creates problems to express items where they are used. 5.6 Limited display area The actual TTY devices usually have only two display lines with around 30 characters. When text from a PSAP arrives it can become many lines on such a display and be cumbersome to scroll in. It is especially ineffective to end messages with a new line, because that scrolls the message off the small screen. Automatic procedures in the conversion between RTT and TTY should therefore not insert unnecessary newlines. 5.7 Telephone network tones disturb reception Telephone networks sometimes inject tone signals during calls. Examples are: call recording notification tone; call waiting tone; three-party call tone. Such tones may disturb TTY reception, so that characters get lost or corrupted, especially if they contain any of the frequencies 1400 Hz and 1800 Hz. In human communication TTY to TTY, it may be manageable to handle such disturbance if it is occasional. Of the tones above, the call recording notification tone would be most destructive, because it is repeated with 12 second interval. Such call recording notification is required by law in some states. It should be checked if that law is valid and obeyed for 9-1-1 PSAPs and if it is possible to make an exception for TTY calls and if so turn it off for these calls. 5.8 Risk for corruption or loss of characters There are a number of situations when TTY transmission is not correctly received at the other end of the call. An acceptable error level is usually said to be 1% characters in error. Certain situations can cause higher percentage corruption or loss: Transmission through VoIP and VoIP gateways that causes packet loss e.g. because of jitter. Transmission through VoIP and VoIP gateways that have malfunctioning echo cancellers in presence of long tones. This is quite common. Transmission through VoIP and VoIP gateways that apply silence detection. Transmission through VoIP and VoIP gateways that apply lossy audio coding. Transmission through VoIP and VoIP gateways that do error concealment. Collision of text transmission in both directions at the same time. Disturbance of ambient audio It will be hard to automatically detect where any loss or corruption has occurred. So risk is high that corrupt text reaches the user or the PSAP, and confuses the dialogue, and causes a lot of waste of time and effort in asking for repetition and doing repetition. - EAAC report on Procedures between TTY users and NG9-1-1 PSAPs - June, 2013 - Page 9- The corruption can also hit the key characters for turn-taking, that need to be detected by the dialogue application. Missing them will cause extra delays to get the dialogue going again. 5.9 Risk for corruption of long series of characters If a TTY shift character is lost or corrupt, a whole series of up to 72 characters following it may also be corrupt because they are presented with the wrong shift state, only corrected after next time a shift character is needed. Manual TTY communication terminals usually have a shift toggle key used for testing if the other shift creates more readable text. Such operations may be beneficial also in RTT PSAP terminals to ease the reading of TTY originated text. 5.10 PSAP operators not following TTY conventions It may be hard to remember to follow the TTY conventions, with typing only one at a time and handing over turn by typing GA. If the conventions are not followed, risk for corruption because of collision increases. This risk is even more evident in the NG9-1-1 case, when the PSAP has other text communication methods to handle that do not need any formal turn taking. In order to off-load the PSAP telecommunicator from keeping track of turn, it is proposed that a procedure with automatic generation and insertion of turn- taking tokens is used. 5.12 No way to interrupt the TTY user while typing It is strictly not possible to interrupt the other party, not even for an important message. If one of the participants types something while the other party is typing, this text need to be stored to be transmitted after the typing part is ready transmitting. At that moment, the stored message may feel a bit out of context and confuse the dialogue. Long queues of messages can also be built up causing extra delays. The alternative, to drop text from the telecommunicator while the user is typing would even worse risk to create confusion and loss of important information and dialogue context. 5.13 Spurious characters from ambient sound If the microphone is on during the call, e.g. during wait time for the other party to compose a message, then ambient sounds may be transmitted on the line and decoded by the other end as valid TTY tones, and thus generate spurious characters that will be merged with the real characters and confuse the dialogue. This happens especially easy if there is music or whistling in the room. 5.14 Need to follow start, end and turn-taking conventions The TTY call has a specific set of conventions intended to make it possible to have calls even with the limitations of the technology. If these conventions are not followed, the risk for collision and confusion increases. - EAAC report on Procedures between TTY users and NG9-1-1 PSAPs - June, 2013 - Page 10- The call to the PSAP needs to start with just calling or possibly just sending a space character right after the connection. Trying to send more text together with the initial call will fail, because the telecommunicator cannot be guaranteed to look at the screen for text at that moment, but instead try to prompt the line with a TTY answer. When the answer is sent by the telecommunicator, it should be ended by letters GA to mark change of turn. Thus all messages sent by the PSAP must be ended with GA. This needs to be inserted by the dialogue application, because the NG9-1-1 telecommunicator cannot be expected to keep track of when to use the GA conventions and when not to do so. Ending is usually indicated by SKGA ( even if variations exist), and they are acknowledged by SKSK. Questions are marked by a Q before the GA. XXXX sometimes mark erasure, but otherwise a transmitted BackSpace works for erasure. 5.15 Hard to automatically detect if the other party gets the transmitted text Certain risks will result in text from one terminal being partly corrupted or lost. If it was detectable when such loss occurred, it could be possible to arrange retransmission from the application. However, it is not easily done to detect in the dialogue application when a message reached the telecommunicator and when not. So retransmissions because of transmission errors seem not feasible to arrange. 6. Recommended procedures The following procedures are designed to make risks for loss, corruption and delays as low as feasibly possible, and to let the PSAP telecommunicator with RTT have a working environment as equal as feasible for all calls containing text. The general principle is that a dialogue management application is inserted in the communication path between the TTY user and the PSAP. The most appropriate point for insertion of this application is in the Legacy Network Gateway. This dialogue management application adapts the dialogue in order to prevent the negative effects of the TTY limitations and make the dialogue as equal as possible to communication with other text terminals in the following ways: ? Transmission one way at a time. The need for text transmission in one direction at a time with the TTY is managed with best effort goals by: o Temporary storing of text coming from the PSAP while text is transmitted from the TTY user. o Transmit text from the PSAP until new line is received followed by a short pause, and then insert GA in the path towards the TTY user if the PSAP had not inserted GA at that point. - EAAC report on Procedures between TTY users and NG9-1-1 PSAPs - June, 2013 - Page 11- ? Adaptation to character set limitations The limitations in character set is managed by conversion of common characters not supported by the TTY to characters supported by the TTY, resulting in improved readability but some introduced risk for confusion. ? Remaining risks for garbling text Remaining risks for garbling is kept at a low level by making sure that a robust TTY decoder is used, no malfunctioning echo cancellers are used in the audio paths, no call recording notification tones are used in the networks, and that the importance that PSAP microphones are turned off when voice is not used in the calls is emphasized in the information to the PSAPs. ? Nothing done to the slowness The procedures cannot propose any actions against the slowness of the TTY communication. - EAAC report on Procedures between TTY users and NG9-1-1 PSAPs - June, 2013 - Page 12- 6.1 Recommended procedures for conversion between user's TTY and RTT in NG9-1-1 PSAP. Architecture TTY terminal ?? Dialogue application and RTT/TTY conversion ??PSAP RTT TERMINAL The procedures aim at maintaining the formal turn-taking procedures for the user operating the TTY, but not require the real-time text PSAP telecommunicator to apply such habits strictly. The procedures are intended to be implemented in gateways converting between TTY and RTT. The procedures insert the turn-taking tokens "GA"and "SKSK" in the transmission towards the TTY user because these tokens are not used in other text communication by the PSAP and therefore would complicate the working environment in the PSAP. However, if the PSAP telecommunicator has inserted GA or SKSK, this token is not repeated. The communication is made sequential by storing entries from the real-time text PSAP while the TTY user is typing. This method requires the procedure to insert the turn-taking tokens at points in the conversation where it can be imagined to be suitable to change turn. The procedures introduce small delays that are inevitable for finding out if the parties continue typing at specific points in the dialogue that are potential turn switching points. The procedures leave the turn-taking tokens "GA" etc. in the text sent towards the real-time text PSAP, but does not require the telecommunicator to obey the turn-taking habits strictly. This creates a different PSAP telecommunicator experience from other NG9-1-1 text communication, but can influence some knowledgeable telecommunicators to not type against turn and thereby reduce the remaining risk for loss or corruption of characters. The procedure has some drawbacks. There is no way to detect telecommunicator desire to end the call. Therefore no insertion of "SKGA" is provided. And it inserts turn-taking tokens where the telecommunicator possibly just made a pause in typing to check some information. An alternative method would be to require the real-time text PSAP telecommunicator to apply turn-taking tokens " GA", "GASK" and "SKSK", and keep strictly to the turn-taking habits. This approach does not seem feasible and does not match the ambition to provide a uniform user experience with 9-1-1 calls against legacy PSAPs and NG9-1-1 PSAPs. Therefore this approach is not developed further here even if it would have some benefits in form of lower risk for loss and garbling of text. - EAAC report on Procedures between TTY users and NG9-1-1 PSAPs - June, 2013 - Page 13- Note: The procedures are informal and not verified for correctness to be directly transferred to a technical implementation. 6.1.1 Procedure elements The following are elements of the procedures described in section 6.1.2. 6.1.1.1 Data Data: Turn to send: True or False Ending status: True or False (True= received GASK or SKSK from TTY ) Timers and default values Idle time to take turn: 3 seconds Quaratine time for regarding GA turntaking GA: 1 second Regarding complete time: 7 seconds. Idle time from TTY with message but not ended by GA or GASK or SKSK to be regarded complete and turn given to The PSAP anyway. EOM-timer 2 seconds NoTyping timer 4 seconds 6.1.1.2 Transmit to TTY ? Send text to the TTY o During transmission, check every character for validity in the TTY character table. o Convert upper case to lower case o Convert according to this table o @ => (at) o # => $ o % => / o & => + o * => . o _ => space o < => ( o > => ) o National characters to their closest companion in the a-z range. e.g. ñ => n o Unknown characters to ' o Convert to 5-bit code and add shift character if needed o Insert the current shift character (Figs or Ltrs) if 72 characters have been transmitted without any shift character in that sequence. o Transmit according to TIA 825A 6.1.1.2 Receive from TTY ? Receive text from the TTY o During reception from TTY, convert to UTF-8 according to ITU-T V.18 Annex A, Table A.1, considering the current case. o Transmit to PSAP according to RFC 4103. - EAAC report on Procedures between TTY users and NG9-1-1 PSAPs - June, 2013 - Page 14- 6.1.2 Procedures 6.1.2.1 Call initiated from TTY user 6.1.2.1.1 Audio handling ? For all cases, audio transport shall be performed when a call is established and no text transmitted. 6.1.2.1.2 On call from TTY ? Receive call from TTY terminal ? Call the RTT telecommunicator. 6.1.2.1.3 On RTT answered ( on telephone call level) ? Set " turn to send" =False. 6.1.2.1.4 On text reception from RTT terminal ? Store text for transmission to TTY ? Indicate text available for transmission to TTY 6.1.2.1.5 On text available for transmission to TTY ? Detect if possible to send to TTY (no transmission going on and no detection of incoming text ) ? If possible, send text in queue for transmission ( converting characters in need of conversion as described in 6.1.1.2 ) ? Continue sending until end of stored characters for transmission to TTY ? Start RTT idle timer ( EOM-timer if last character was newline, NoTyping-timer if last character was not newline.) 6.1.2.1.6 On RTT Idle-timer ? If no ending status, and no "GA" sent by telecommunicator, send " GA" to TTY else ending status send "SKSK" to TTY if telecommunicator has not done so ? Set "turn to send"=False 6.1.2.1.7 On text available for transmission to RTT PSAP terminal ? Transmit to RTT PSAP terminal . 6.1.2.1.8 On disconnection of the TTY in an ongoing session ? If in ending state, send normal ending progress info to RTT PSAP Terminal ? Else send non-normal ending progress info to RTT PSAP Terminal 6.2.1.9 Detection of ending with GA, SKGA (or variants GASK or GA TO SK) or SKSK need the variation with the following details. 1) Wait until 2 seconds of silent period. 2) Browse through the last 15 received chars including CR,LF, and spaces. (sometimes there are several spaces after GA thus the 15 chars is a good size). 3) Ignore any CR, LF, and spaces in this browsing. (Sometimes GA get auto CRLF in between G and A.) - EAAC report on Procedures between TTY users and NG9-1-1 PSAPs - June, 2013 - Page 15- 4) If the last two chars after this are GA or SK, it is detected end of message. 5) In order to cater for lost shift character, the end of message is detected if the last two chars are: 1) GA 2) +A 3) G- 4) +- 5) SK 6) K 7) S) 8) ) 6) If no ending detection has been found -and- silent for "message regarded complete time", it is considered okay to take conversation turn. 6.1.2.2 Call back to TTY 6.1.2.2.1 On call to TTY ? Evaluate TTY user address and validate addressability ? Call out to TTY User ? Set "turn to send "=True ? Answer call ? Wait for characters ( normally TTY user starts typing ) 7. Conclusions This study shows that there are considerable limitations with using the TTY as user terminal for NG9-1-1 calls and that there is a need to as far as feasible prevent these limitations from causing quality problems and very specific telecommunicator procedures in calls with TTY users compared to modern text communication methods. Procedures are proposed that can minimize loss because of transmission collision, and ease the operating procedures in the PSAPs. But the loss and disturbances cannot be totally eliminated. A practical test is recommended for tuning the proposed procedures for optimal call quality and minimal confusion in PSAP operating procedures. - EAAC report on Procedures between TTY users and NG9-1-1 PSAPs - June, 2013 - Page 16- Appendix A. Letter from DOJ filed as comment to FCC on text-to-9-1-1 U.S. Department of Justice Civil Rights Division Counsel to the Assistant Attorney General 950 Pennsylvania Ave, NW - RFK Washington, DC 20530 - EAAC report on Procedures between TTY users and NG9-1-1 PSAPs - June, 2013 - Page 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 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 - EAAC report on Procedures between TTY users and NG9-1-1 PSAPs - June, 2013 - Page 18- 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.6 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. 6It 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). - EAAC report on Procedures between TTY users and NG9-1-1 PSAPs - June, 2013 - Page 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