Proposed procedures for the TTY as a text terminal in legacy 9-1-1 PSAPs without IP connection - TTY PSAP Procedures report - June, 2013 - Page 2- June 14, 2013 EAAC Report on proposed procedures for TTY as 9-1-1 PSAP text terminal Procedures for the TTY as text terminal in legacy 9-1-1 PSAPs This document is a report to the FCC from the Emergency Access Advisory Committee (EAAC). It provides a mainly theoretical study on suitable procedures needed for using the TTY terminals in legacy 9-1-1 PSAPs as text terminals for more modern forms of text communication. This report especially targets the recent EAAC reports on the interim text-to-9-1-1 solution1 and its implementation through the ATIS/TIA J-STD- 1102 , as well as the replacement of user's TTYs with Real-Time text terminals (=the TTY replacement)3. The TTY has many functional limitations compared to modern text communication and there is a risk that these limitations cannot be overcome to a sufficient degree. The report is intended to provide material for making informed decisions on use of the TTY at PSAPs for these purposes, to provide background material for trials in practice, and to provide design details for the use of the TTY in these cases. The report applies to the PSAPs that do not implement newer IP-based technology that supports modern text communication technologies. An earlier version of this document was submitted to the FCC as in a reply comment to the text-to-9-1-1 proceedings. Contents 1. Summary....................................................................................................................................................... 4 2. Scope ............................................................................................................................................................ 4 3. Background and brief outline of applications .............................................................................................. 4 3.1 SMS-to-9-1-1........................................................................................................................................... 6 3.1.1 Session characteristics of SMS to 9-1-1........................................................................................... 6 3.2 Use of Real-time text and audio to 9-1-1 with TTY ................................................................................ 7 4. Facts and conventions about the TTY........................................................................................................... 7 4.1 TTY technology ....................................................................................................................................... 7 4.2 NENA TTY Procedures............................................................................................................................. 8 4.3 Conventions............................................................................................................................................ 8 5. TTY functions, limitations and risks .............................................................................................................. 8 5.1 One transmission direction at a time ..................................................................................................... 8 5.2 Use of audio only when not involved in text transmission .................................................................... 9 5.3 Slowness ................................................................................................................................................. 9 5.4 Only upper case or lower case characters - not both ............................................................................ 9 5.5 Limited character set............................................................................................................................ 10 1 Report of Emergency Access Advisory Committee (EAAC) Subcommittee 1 on Interim Text Messaging to 9-1-1. Submitted on March 7, 2013. Filed in PS Docket 11-153 on April 4, 2013. 2 ATIS/TIA J-STD-110 Joint ATIS/TIA Native SMS to 9-1-1 Requirements and Architecture Specification. http://www.atis.org/docstore/product.aspx?id=27924 3 Emergency Access Advisory Committee (EAAC) Report on TTY Transition. Submitted on March 11, 2013. Filed in PS Docket 11-153 on April 4, 2013. - TTY PSAP Procedures report - June, 2013 - Page 3- 5.6 Limited display area.............................................................................................................................. 10 5.7 Telephone network tones disturb reception........................................................................................ 11 5.8 Risk for corruption or loss of characters .............................................................................................. 11 5.9 Risk for corruption of long series of characters ................................................................................... 12 5.10 PSAP operators not following TTY conventions ................................................................................. 12 5.11 PSAP procedures to type Q for question............................................................................................ 12 5.12 No way to interrupt the TTY user while typing .................................................................................. 12 5.13 Spurious characters from ambient sound .......................................................................................... 12 5.14 Need to follow start, end and turn-taking conventions..................................................................... 12 5.15 Hard to automatically detect if a human PSAP operator has received the intended text................ 13 6. Recommended procedures ........................................................................................................................ 13 6.1 Recommended procedure for conversion between SMS and TTY....................................................... 15 6.1.1 Procedure elements ...................................................................................................................... 15 6.1.2 Procedures..................................................................................................................................... 16 6.2 Recommended procedures for conversion between user's RTT and TTY in 9-1-1 PSAP. .................... 19 6.2.1 Procedure elements ...................................................................................................................... 19 6.2.2 Procedures..................................................................................................................................... 20 6.3 TTY Conversion of text messaging in NG9-1-1 Legacy PSAP Gateway ................................................. 21 6.3.1 Procedure elements ...................................................................................................................... 22 6.3.2 Procedures..................................................................................................................................... 23 7. Conclusions................................................................................................................................................. 26 Appendix A. Letter from DOJ filed as comment to FCC on text-to-9-1-1....................................................... 27 - TTY PSAP Procedures report - June, 2013 - Page 4- 1. Summary The report describes a number of functional limitations in the TTY text communication device used in current 9-1-1 PSAPs, and how these influence three applications if used for this communication: The interim text-to-9-1-1 service based on the wireless SMS short messaging service, the TTY replacement for IP networks, using Real-time text and audio terminals and the text communication through the Legacy PSAP Gateway of the NG9-1-1 system . The influences of the following limitations are considered: · Only one transmission direction at a time. If not obeyed, character loss or garbling occurs. · No audio transmission during periods of text transmission. · Transmits only about 5 characters per second. Delays in use for messaging or with rapid typing. · Only one case for letters. Upper case or lower case, not both. · Limited set of characters. The following characters cannot be presented or sent: @ # % & \ * _ < > · Limited display area on user devices. Long texts are inconvenient to read. · Telephone network tones disturb reception. · Risk for corruption or loss of characters. · Risk for corruption of up to 72 characters in sequence from one transmission error. · Requires strict turn-taking conventions with user created text based tokens. (e.g. GA ) · No way to interrupt the other party during transmission. · Spurious characters can appear from ambient sound. Procedures limiting the risks for collision of transmission in both directions are presented. The conclusion indicates that there will be some remaining problems, and that before a decision is made on whether to use TTYs to receive text-to-9-1-1 and communications from the TTY replacement on IP networks, it is recommended to first make a brief trial. The report is valid only for communication with legacy PSAPs without IP connections used for the modern text communication applications. 2. Scope This document is a report from a study made mainly theoretically for how possible it is to use existing TTY terminals in legacy 9-1-1 PSAPs as terminals also for other text communication types than with the TTYs, especially text-to-9-1-1 and real-time text. The study presents the risks, indicates situations where the risks are most likely to appear, and discusses remedies implemented through communication procedures. Very similar risks will appear between TTYs operated by users, and real-time text terminals in new NG9-1-1 PSAPs, where similar remedies can be applied, but that case is out of scope for the present document. 3. Background and brief outline of applications 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. Of specific interest here are the short messages, SMS, of the text-to-9-1-1 service, and the real-time text service in IP networks. They have the opportunity to be implemented with their full functionality in new 9-1-1 center implementations. However, there is a very strong tradition in USA to let the 9-1-1 call be handled by the most appropriate 9- 1-1 center (PSAP) close to the caller. - TTY PSAP Procedures report - June, 2013 - Page 5- All PSAPs cannot get the new communication features installed at the same time. Users of the new technology do not want to wait until the last PSAP has installed it. It will be very confusing for users if the feature works in one county but not in another. Therefore it is very desirable to make the new communication features work also with current legacy PSAPs, even if that will be with some acceptable levels of functional limitations. Such use is briefly described both in the EAAC report on interim text-to-9-1-14 and in the EAAC report on TTY transition5, but no exact procedures are described. Clear is however, that the communication must pass an interworking function for adaptation between the different communication methods. Is search of technology for text communication already implemented in the current PSAPs that could be used for the new features text-to-9-1-1 and real-time text, the interest goes to technologies implemented for communication with persons with deafness, deaf-blindness, hard-of-hearing and speech disabilities. There is the TTY text telephone technology, using the TIA 825A standard. It is mandatory to have it implemented in all 9-1-1 PSAPs in USA. Its wide deployment makes it very compelling for this application, but it has some problematic functional limitations that will be hard to cover. The "ASCII" text telephone based on Bell 103 modem6 was raised as a possible alternative method to communicate with PSAPs instead of TTYs. . It has fewer technical limitations in speed, simultaneity and character set than the TTY for the intended use. On the other hand, it is not widely used among current PSAPs, and there is no requirement for PSAPs to support it, so it does not meet the requirement to be an alternative to be used in all PSAPs who have not upgraded to IP connection and native support of the new communication features. Therefore the "ASCII" variant is not discussed in this report, and the description focuses on using the TIA 825A TTY as text terminal for the described applications in the legacy PSAPs still on the PSTN only. The use of TIA 825A TTY Technology for this purpose should be limited to PSAPs that cannot upgrade immediately to IP. There should therefore also be an effort to arrange IP connection to the currently- analog-only PSAPs to finally eliminate the influence of the functional limitations of TTYs in these applications. The requirement to use the TTY in legacy PSAPs as text terminal for modern text communication means is stressed by DOJ in a filing to FCC, where it is said that "PSAPs must, at a minimum, use TTYs or other equally effective telecommunications systems to communicate with individuals with hearing and speech disabilities"7. This letter is also attached as Appendix A to this report. 4 Report of Emergency Access Advisory Committee (EAAC) Subcommittee 1 on Interim Text Messaging to 9-1-1. Submitted on March 7, 2013. Filed in PS Docket 11-153 on April 4, 2013. 5 Emergency Access Advisory Committee (EAAC) Report on TTY Transition. Submitted on March 11, 2013. Filed in PS Docket 11-153 on April 4, 2013. 6 Described in ITU-T Recommendation V.18, Annex D at https://www.itu.int/rec/T-REC-V.18/en 7 DOJ comment to text-to-9-1-1. http://apps.fcc.gov/ecfs/document/view?id=7022129201 - TTY PSAP Procedures report - June, 2013 - Page 6- 3.1 SMS-to-9-1-1 A service for communicating with 9-1-1 by Short Message Service SMS is on its way to be implemented in USA8. Short messages will be exchanged between a user with a mobile phone and a PSAP Telecommunicator. In case that PSAP uses TTY equipment intended for the telephone network, then they are called legacy PSAPs. The limitations of the TTY will influence performance of this application. The solution need to contain an automatic procedure for translation between the message based SMS interface and the limited real-time text type interface of the TTY. This procedure can contain parts intended to minimize the effects of the limitations. When instead the SMS exchange is with an interim PSAP or an NG9-1-1 PSAP, the performance will be different. The document has the ambition to describe the main differences and provide decision material for if it is advisable to use the TTYs for this purpose. It applies at least to the following cases: · As detailing to the interim text-to-9-1-1 procedures specified in ATIS/TIA J-STD-1109, where two routes to legacy PSAPs are described, one through a specific gateway for this purpose and the other through the Legacy PSAP Gateway of the NG9-1-1 system. · Any further use of text messaging with 9-1-1 where the PSAP text terminal is a TTY. 3.1.1 Session characteristics of SMS to 9-1-1 There is not sufficient experience in USA to tell what load the SMS -to-9-1-1 message sequences will place on the PSAPs. Therefore it might be of interest to look at experience from other countries. Sweden has had a corresponding SMS to 112 service for some years. Here are figures of experience from a few typical message sequences. The mean number of messages exchanged in a sequence was 16, varying between 6 and 26 in the observed sequences. The numbers of messages are usually close to equal from each side, even if deviations exist. The mean sequence duration was 19 minutes, varying between 14 and 23. The mean number of characters per message was 49, varying widely from 2 to 266. The mean total number of characters from the SMS user was 455 during the complete session, varying between 215 and 618. 8 http://www.fcc.gov/encyclopedia/emergency-access-advisory-committee-eaac 9 ATIS/TIA J-STD-110 Joint ATIS/TIA Native SMS to 9-1-1 Requirements and Architecture Specification. http://www.atis.org/docstore/product.aspx?id=27924 - TTY PSAP Procedures report - June, 2013 - Page 7- 3.2 Use of Real-time text and audio to 9-1-1 with TTY 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 EAAC10. 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. When instead the call is with an NG9-1-1 PSAP, the performance will be different. The document has the ambition to describe the main differences and provide material to decision makers as to whether it is advisable to use the TTYs for this purpose. 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. 10 http://www.fcc.gov/document/emergency-access-advisory-committee-eaac-report-tty-transition - TTY PSAP Procedures report - June, 2013 - Page 8- 4.2 NENA TTY Procedures 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. http://www.nena.org/?page=TTY_TDD_SOP 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 on the end user side. 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 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.) Variants GASK and GA TO SK also occur. The one who then accepts to end the call ends the text with " SKSK". It is a habit by PSAPs using TTY to end a question with " Q GA" Because this is a habit applied by humans, there may be variations in reality. The indication for desire to end the call may instead of SKGA be GASK. Sometimes spaces or new lines are typed directly after the turn-taking token etc. Transmission of the turn-taking token can also be forgotten. Therefore any effort to automatically detect turn-taking indications need to take such variations into consideration in efforts to optimize detection and minimize false detection of turn-taking indications when the turn-taking token characters are used in regular text. 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. - TTY PSAP Procedures report - June, 2013 - Page 9- 5.2 Use of audio only when not involved in text transmission Voice transmission is cut out during periods of text transmission with the TTY. 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 risk for delays feeling extra disturbing and causing delays in emergency case handling is especially in transmission of an SMS message to the PSAP TTY. Then the user first composes the whole message. That takes time. Not until it is finished and transmitted, the conversion to TTY can start, adding about 2 seconds per 10 characters to the time before the message is completely received. A message can easily be 200 characters, adding 40 seconds to the transmission time. The time lost in TTY transmission in a complete emergency message sequence of - say 8 such messages is then over 3 minutes. In the other situations, 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 still disturbing and cause extra delays. Influence for the SMS case: Very high. Looking at the typical SMS sequences in section 3.1.1, it can be expected that the sequences get an extra delay of 90 seconds because of the slow transmission. Influence for the TTY replacement case: Low but not negligible. Work around: None 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 user in emergency will usually not know that the PSAP 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 transmitted. 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 telecommunicator, it can be hard and take a lot of extra time. That is however probably a very rare situation. - TTY PSAP Procedures report - June, 2013 - Page 10- 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 user to the telecommunicator, and problems to express some items from the telecommunicator to the user. 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) (Deviates from the V.18 standard, where "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 SMS user to the telecommunicator to dial *224# would be translated to .224+ to the telecommunicator, and that might not be immediately clear what that means. The "@" sign translation to "X" in the V.18 standard does not seem to be appropriate in today's situation, it is instead proposed to be translated to "(at)" because of its often occurring presence in internet addresses. A minor complication is that the transmitting application need to convert erasure of @ with erasure of four characters to the TTY. In transmission from the telecommunicator, the lack of these characters creates problems to express items where they are used. It is possible that conventions already exist for how telecommunicators should handle such situations in the currently used communication with users of TTYs. If so, these habits should be maintained and explained to users of SMS and TTY replacements. 5.6 Limited display area The actual TTY devices usually have only two display lines with around 30 characters. Most PSAPs have the TTY function integrated in the call taking work station and have the TTY communication display embedded among other emergency information, but some PSAPs operate TTY traffic on actual TTY devices. - TTY PSAP Procedures report - June, 2013 - Page 11- When text from an SMS or TTY replacement 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 SMS and TTY and between TTY replacement 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. In communication with SMS however, corruption of characters may disturb the automatic dialogue translation process and cause delays and confusion. 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. 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. - TTY PSAP Procedures report - June, 2013 - Page 12- 5.9 Risk for corruption of long series of characters If a TTY shift character is lost or corrupt, a whole series of 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. 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, and the possibility to send response rapidly decreases. 5.11 PSAP procedures to type Q for question The telecommunicators have a procedure saying that htey shall type Q to indicate a question. It needs to be decided if this Q shall be deleted by the dialogue application or not. 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 the user types something while the telecommunicator is typing, that message must be stored to be transmitted after the telecommunicator 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 incoming messages while the telecommunicator 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. 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 is ended by letters GA to mark change of turn. - TTY PSAP Procedures report - June, 2013 - Page 13- Thus all messages sent to the PSAP must be ended with GA. This needs to be inserted by the dialogue application, because the user does not have such habits and cannot know that the PSAP has a TTY and need these conventions. Ending is indicated by SKGA, and acknowledged by SKSK. Questions are marked by a Q before the GA. XXXX sometimes mark erasure, but otherwise a transmitted BackSpace works for erasure. Asking the other party to wait is signaled by "PLEASE HOLD" or any of its variants: PLS HD, PLEASE HD, HD, HD PLS, HD PLEASE, HOLD PLEASE. 5.15 Hard to automatically detect if a human PSAP operator has received the intended text Certain risks will result in text from the user 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. A possibility would be to arrange a command language between the PSAP and the dialogue application. That will however require education about procedures that maybe hard to remember. The idea is that the procedure shall be possible to use in existing PSAPs, so implementation of system support for retransmission requests is out of scope. 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 TTY have a working environment as equal as feasible to when only TTY calls were handled. The general principle is that a dialogue management application is inserted in the communication path between the user and the PSAP. This dialogue management application adapts the dialogue in order to prevent the negative effects of the TTY limitations 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 Inserting transmitted and deleting received turn-taking tokens " GA" etc. in the path with the TTY. o Temporary storing of text coming from the user while text is transmitted from the PSAP. o For the message case (SMS) collect text from the PSAP until " GA" is received (for the normal case) or a long pause (to keep communication going for the case when the PSAP telecommunicator forgets "GA", or "GA" is garbled in communication). - TTY PSAP Procedures report - June, 2013 - Page 14- · 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. · Dialogue step insertion Steps in the dialogue are inserted to make sure that the TTY call establishment and dialogue is performed as usual, e.g. that for the message case (SMS), the first message from a user is not sent to the PSAP until the PSAP has answered the call and sent an initial greeting phrase. · 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, that will be most disturbing in the message communication from SMS to PSAP that is not paralleled with any typing. A mean extra time of 0.2 seconds per character in communication from SMS user to PSAP will still be introduced. - TTY PSAP Procedures report - June, 2013 - Page 15- 6.1 Recommended procedure for conversion between SMS and TTY Architecture SMS system ß----------à Dialogue application and Message/TTY conversion ß-------àPSAP TTY The Dialogue application and Message/TTY conversion functionality may be part of the TSS system in the TTY case for the ATIS SMS911 solution. The SMS dialogue application serializes communication with the PSAP telecommunicator and has the ambition to make the dialogue as equal as possible to the TTY dialogue for the PSAP telecommunicator. The SMS user cannot be expected to know about the turn-taking habits with TTYs. Thus, when messages from SMS have been transmitted to the PSAP TTY, " GA" is added by the application to indicate turn to the PSAP telecommunicator. However before or during typing from the PSAP, the SMS user can have transmitted yet another message. If the PSAP telecommunicator types at that moment, the message is stored until transmission is free, otherwise the message is sent (against turn) and again a " GA" turn indicator is attached. This approach has a small remaining risk for collision between beginning of the new message from the SMS user with beginning of typing response on the previous message by the PSAP telecommunicator, but it is judged to be a low risk and important to get new messages through to the PSAP. Applying strict turn-taking habits on SMS users does not seem feasible. 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 elements are part of the solution described in section 6.1.2. 6.1.1.1 Texts and data The following text strings are recommended for transmission to PSAP: · Ingress on first message: "SMS user:" · Greeting to PSAP on call back "SMS ready GA" Data: · Turn to send: True or False · Ending status: True or False (True= received GASK or SKSK from PSAP ) Timers with proposed time · Idle time to take turn when need to send aginst turn: 3 seconds · Quarantine time for regarding GA turn taking GA: 1 second · Regarding complete time: 7 seconds. Idle time from PSAP with message, but not ended by GA or GASK or SKSK to be regarded complete to send to SMS user anyway. 6.1.1.2 Detect if it is possible to send to TTY · Check if transmission to the addressed TTY is already going on. · Check if decoding of characters from the TTY is going on. - TTY PSAP Procedures report - June, 2013 - Page 16- · Check if other message already stored in queue for transmission o If none of these, it is OK to start transmission 6.1.1.3 Convert and transmit to TTY · Send the message 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 · Insert the current shift character (Figs or Ltrs) if 72 characters have been transmitted without any shift character in that sequence. · Transmit according to TIA 825A 6.1.1.4 Call the TTY Make call to the addressed PSAP over PSTN. Prompt the TTY with one space character. await answer Note: Some PSAPs have automatic initiation of TTY reception and display if 3 TTY space characters are received. But prompting may collide with answer and cause loss. 6.1.2 Procedures In this section, outlines of complete procedures for different use cases are documented. The procedures are composed of the procedure elements above collected mainly in a set of event handling procedures. 6.1.2.1 Message sequence initiated from SMS user 6.1.2.1.1 On indication of new message from SMS available · Receive message from SMS · Store in queue specific for the user sending it. · Check if from user who has session already: · If not, and first message from this user, attach SMS Ingress text in beginning of message. Call appropriate PSAP and provide identification and location information, and indicate "turn to send"=False. - TTY PSAP Procedures report - June, 2013 - Page 17- · If message was for current session, check if have turn to transmit to PSAP. a. If have turn, indicate event "got turn". b. Else, does not have turn. Set wait for turn or idle time idle before take turn. 6.1.2.1.2 On PSAP idle time expired · Set "turn to send"=True 6.1.2.1.3 On Call to PSAP answered (on phone connection level) · Send TTY Space as prompt · Set "turn to send" to False · Await TTY answer Note: It might be suitable to send up to 4 space characters about two seconds apart until TTY answer. 6.1.2.1.4 On no answer from TTY after call timeout, or error when calling PSAP · Retry once · If still problems, send progress info about PSAP call failure to SMS user. 6.1.2.1.5 On got turn to send · Check if message in queue for transmission to TTY · If so, fetch next message in queue for transmission to TTY · Detect if possible to send to TTY ( = not currently decoding incoming text ) · If not possible, store message intended for later transmission to the TTY else · Transmit to TTY ( converting characters in need of conversion etc. see 6.1.1.3 ) 6.1.2.1.6 On end of transmission of current message to TTY · Check if more message to send · If yes, indicate "turn to send" True · Else if no ending status, send " GA" and indicate PSAP turn to send. · Else in ending status send " SKSK" . 6.1.2.1.7 On connection to PSAP lost. · If connection lost during transmission, send progress info to SMS 6.1.2.1.8 On reception of characters from PSAP TTY · Store received characters in received message from TTY · Detect if ending with " GA" or " SKGA" or " SKSK" as detailed below · If yes, detect if nothing more in GA quarantine time, then Send SMS with GA or SKGA or SKSK stripped off to SMS. · Set "turn to send" True · If nothing more in "message regarded complete time", then Send SMS · If ending with "SKGA" or "SKSK", (with variations as indicated below), set ending status. Detection of ending with GA, SKGA or SKSK need the variation with the following details. - TTY PSAP Procedures report - June, 2013 - Page 18- 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.) 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.1.9 On disconnection of the TTY in an ongoing session · If in ending state, send normal ending progress info to SMS · Else send non-normal ending progress info to SMS 6.1.2.2 Call back to SMS user This procedure is intended for the case when the PSAP needs to re-establish a connection with a user. There must be a way to address the gateway, so that the call is intercepted by the gateway and the procedures can be applied. 6.1.2.2.1 On incoming call to the gateway from a TTY in PSAP · Answer call · Evaluate SMS address and validate addressability · Compose initial greeting to PSAP · Check if possible to send to TTY (=not currently decoding) · If so, send to TTY · Indicate PSAP has turn - TTY PSAP Procedures report - June, 2013 - Page 19- 6.2 Recommended procedures for conversion between user's RTT and TTY in 9-1-1 PSAP. Architecture RTT terminal ßà Dialogue application and RTT/TTY conversion ßàPSAP TTY The procedures aim at maintaining the formal turn-taking procedures for the telecommunicator operating the TTY, but not require the real-time text user to apply such habits. The procedures instead strip off the turn-taking tokens "GA", "SKGA" and "SKSK" from the transmission towards the real-time text user as the trend is to not use these tokens in communication between these users. The procedures would be implemented both by any RTT/TTY gateway used for pre-NG9-1-1 calling, and for the NG-9-1-1 Legacy PSAP Gateway for cases when RTT calls are connected with legacy PSAPs through the NG9-1-1 network. The communication is instead made sequential by storing entries from the real-time text user while the PSAP telecommunicator 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. An alternative method would be to require the real-time text user 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. A third approach would be to leave the turn-taking tokens "GA" etc. in the text sent towards the real-time text user, but not expect the real-time text user to obey the turn-taking habits. This would create a different user experience from NG9-1-1, but could influence some knowledgeable real-time text users to not type against turn and thereby reduce the remaining risk for loss or corruption of characters. Note: The procedures are informal and not verified for correctness to be directly transferred to a technical implementation. The procedures can be fine tuned keeping in mind to not introduce any locked states for long times. No support is provided for the "PLEASE HOLD" situation because of this reason. 6.2.1 Procedure elements The following are elements of the procedures described in section 6.2.2. - TTY PSAP Procedures report - June, 2013 - Page 20- 6.2.1.1 Texts and data Data: Turn to send: True or False Ending status: True or False (True= received GASK or SKSK from PSAP ) Timers and default values Idle time to take turn: 3 seconds Quaratine time for regarding GA turntaking GA: 2 second Regarding complete time: 7 seconds. Idle time from PSAP with message but not ended by GA or GASK or SKSK to be regarded complete and turn given to TTY Replacement anyway. EOM-timer 2 seconds NoTyping timer 4 seconds 6.2.1.2 Transmit to TTY · Send the message 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.2.2 Procedures 6.2.2.1 Call initiated from RTT user 6.2.2.1.1 Audio handling · For all cases, audio transport shall be performed when a call is established and no text transmitter. 6.2.2.1.2 On call from RTT system · Receive call from RTT terminal (=TTY replacement) · Call the psap TTY. 6.2.2.1.3 On TTY answered ( on telephone call level) · Set " turn to send" =False. - TTY PSAP Procedures report - June, 2013 - Page 21- 6.2.2.1.4 On text reception from RTT terminal · Store text for transmission to TTY · Indicate text available for transmission to TTY 6.2.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.2.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.2.2.1.6 On RTT Idle-timer · If no ending status, send " GA" to PSAP TTY if "GA" was not already included in text from user. else ending status send "SKSK" to PSAP TTY if "SKSK" was not already included in text from user. · Set "turn to send"=False 6.2.2.1.7 On text available for transmission to RTT terminal · Transmit to RTT terminal, except trailing "GA" or " SKGA" 6.2.2.1.8 On disconnection of the TTY in an ongoing session · If in ending state, send normal ending progress info to TTY Replacement · Else send non-normal ending progress info to TTY replacement 6.2.2.2 Call back to RTT user This procedure is intended for the case when the PSAP needs to re-establish a connection with a user. 6.2.2.2.1 On incoming call from a TTY · Answer call · Evaluate TTY Replacement address and validate addressability · Call out to TTY Replacement · Set "turn to send "=True · Wait for characters 6.2.2.3 Voice When the connection is not used for text communication, audio should be passed through. 6.3 TTY Conversion of text messaging in NG9-1-1 Legacy PSAP Gateway Architecture - TTY PSAP Procedures report - June, 2013 - Page 22- Text system, ß--------à Dialogue application and Message/TTY conversion ß-------àPSAP TTY optionally In NG9-1-1 Legacy PSAP Gateway and phone with voice The Dialogue application and Message/TTY conversion functionality is part of the NG9-1-1 Legacy PSAP Gateway system. It is for example used in the TTY case for the ATIS SMS911 solution when the most appropriate PSAP is a legacy PSAP connected to the NG9-1-1 network, and MSRP is selected for the message communication. The dialogue application serializes communication with the PSAP telecommunicator and has the ambition to make the dialogue as equal as possible to the TTY dialogue for the PSAP telecommunicator. The user cannot be expected to know about the turn-taking habits with TTYs. Thus, when messages from the messaging user have been transmitted to the PSAP TTY, " GA" is added by the application to indicate turn to the PSAP telecommunicator. However before or during typing from the PSAP, the SMS user can have transmitted yet another message. If the PSAP telecommunicator types at that moment, the message is stored until transmission is free, otherwise the message is sent (against turn) and again a " GA" turn indicator is attached. This approach has a small remaining risk for collision between beginning of the new message from the messaging user with beginning of typing response on the previous message by the PSAP telecommunicator, but it is judged to be a low risk and important to get new messages through to the PSAP. Applying strict turn-taking habits on messaging users does not seem feasible. Note: The procedures are informal and not verified for correctness to be directly transferred to a technical implementation. They may be refined. 6.3.1 Procedure elements The following elements are part of the solution described in section 6.1.2. 6.3.1.1 Texts and data The following text strings are recommended for transmission to PSAP: · Ingress on first message: "Message user:" · Greeting to PSAP on call back "Messaging ready GA" Data: · Turn to send: True or False · Ending status: True or False (True= received GASK or SKSK from PSAP ) Timers with proposed time · Idle time to take turn when need to send against turn: 4 seconds · Quarantine time for regarding GA being turn taking GA: 2 seconds · Regarding complete time: 7 seconds. Idle time from PSAP with message, but not ended by GA or GASK or SKSK to be regarded complete to send to messaging user anyway. 6.3.1.2 Detect if it is possible to send to TTY · Check if transmission to the addressed TTY is already going on. - TTY PSAP Procedures report - June, 2013 - Page 23- · Check if decoding of characters from the TTY is going on. · Check if other message already stored in queue for transmission o If none of these, it is OK to start transmission 6.3.1.3 Convert and transmit to TTY · Send the message 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 · Insert the current shift character (Figs or Ltrs) if 72 characters have been transmitted without any shift character in that sequence. · Transmit according to TIA 825A 6.3.1.4 Call the TTY Make call to the addressed PSAP over PSTN. Prompt the TTY with one space character. await answer Note: Some PSAPs have automatic initiation of TTY reception and display if 3 TTY space characters are received. But prompting may collide with answer and cause loss. 6.3.2 Procedures In this section, outlines of complete procedures for different use cases are documented. The procedures are composed of the procedure elements above collected mainly in a set of event handling procedures. 6.3.2.1 Message sequence initiated from messaging user 6.3.2.1.1 On indication of new message from message user available · Receive message from message system · Store in queue specific for the user sending it. · Check if from user who has session already: - TTY PSAP Procedures report - June, 2013 - Page 24- · If not, and first message from this user, attach messaging Ingress text in beginning of message. Call appropriate PSAP and provide identification and location information, and indicate "turn to send"=False. · If message was for current session, check if have turn to transmit to PSAP. a. If have turn, indicate event "got turn". b. Else, does not have turn. Set wait for turn or idle time idle before take turn. 6.3.2.1.2 On PSAP idle time expired · Set "turn to send"=True 6.3.2.1.3 On Call to PSAP answered (on phone connection level) · Send TTY Space as prompt · Set "turn to send" to False · Await TTY answer Note: It might be suitable to send up to 4 space characters about two seconds apart until TTY answer. 6.3.2.1.4 On no answer from TTY after call timeout, or error when calling PSAP · Retry once · If still problems, send progress info about PSAP call failure to Message user. 6.3.2.1.5 On got turn to send · Check if message in queue for transmission to TTY · If so, fetch next message in queue for transmission to TTY · Detect if possible to send to TTY ( = not currently decoding incoming text ) · If not possible, store message intended for later transmission to the TTY else · Transmit to TTY ( converting characters in need of conversion etc. see 6.1.1.3 ) 6.3.2.1.6 On end of transmission of current message to TTY · Check if more message to send · If yes, indicate "turn to send" True · Else if no ending status, send " GA" and indicate PSAP turn to send. · Else in ending status send " SKSK" . 6.3.2.1.7 On connection to PSAP lost. · If connection lost during transmission, send progress info to message user. 6.3.2.1.8 On reception of characters from PSAP TTY · Store received characters in received message from TTY · Detect if ending with " GA" or " SKGA" or " SKSK" as detailed below · If yes, detect if nothing more in GA quarantine time, then Send Message with GA or SKGA or SKSK stripped off to Message system. · Set "turn to send" True · If nothing more in "message regarded complete time", then Send Message. - TTY PSAP Procedures report - June, 2013 - Page 25- · If ending with "SKGA" or "SKSK", (with variations as indicated below), set ending status. Detection of ending with GA, SKGA 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.) 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 acceptable to take conversation turn. 6.3.2.1.9 On disconnection of the TTY in an ongoing session · If in ending state, send normal ending progress info to Message user. · Else send non-normal ending progress info to Message user. 6.3.2.2 Call back to Message user This procedure is intended for the case when the PSAP needs to re-establish a connection with a user. 6.3.2.2.1 On incoming call to the LPG from a TTY in PSAP · Evaluate Message user address and validate addressability · Call user indicating messaging and audio. · If answered, answer the call from the PSAP · Compose initial greeting to PSAP · Check if possible to send to TTY (=not currently decoding) · If so, send to TTY · Indicate PSAP has turn 6.3.2.3 Voice If audio is offered in incoming call from message system, audio connection is also established through the LPG. When text communication is not active, the audio is connected through. If on outgoing call, audio offer is acknowledged by the user's messaging system, audio connection is established through the LPG. Audio is carried through in the session when the path is not used for text communication. - TTY PSAP Procedures report - June, 2013 - Page 26- 7. Conclusions This study shows that there are considerable limitations with using the TTY as 9-1-1 terminals for the interim text-to-9-1-1 solution and for users of RTT Real-Time text technology (e.g. the TTY replacement). Text is at risk to be corrupted and lost. Delays will be introduced. Procedures are proposed that can minimize loss because of transmission collision. But the loss and disturbances cannot be eliminated. A practical test seems needed and is recommended for judging how the described limitations influence service quality in reality, and how much the described procedures protect the communication from loss and garbling. PSAPs may have reasons to stay for some time with only PSTN connection, and the TTY based solution may need to be used even if its characteristics are not favorable. Procedures derived from the ones described in this study should be used to keep loss and corruption of characters as low as feasible. - TTY PSAP Procedures report - June, 2013 - Page 27- 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 - TTY PSAP Procedures report - June, 2013 - Page 28- 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 - TTY PSAP Procedures report - June, 2013 - Page 29- 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.11 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. 11It 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). - TTY PSAP Procedures report - June, 2013 - Page 30- 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