1、 ATIS-0700030 ATIS Standard on - Real Time Text End-to-End Service Description Specification As a leading technology and solutions development organization, the Alliance for Telecommunications Industry Solutions (ATIS) brings together the top global ICT companies to advance the industrys most pressi
2、ng business priorities. ATIS nearly 200 member companies are currently working to address the All-IP transition, 5G, network functions virtualization, big data analytics, cloud services, device solutions, emergency services, M2M, cyber security, network evolution, quality of service, billing support
3、, operations, and much more. These priorities follow a fast-track development lifecycle from design and innovation through standards, specifications, requirements, business use cases, software toolkits, open source solutions, and interoperability testing. ATIS is accredited by the American National
4、Standards Institute (ANSI). The organization is the North American Organizational Partner for the 3rd Generation Partnership Project (3GPP), a founding Partner of the oneM2M global initiative, a member of the International Telecommunication Union (ITU), as well as a member of the Inter-American Tele
5、communication Commission (CITEL). For more information, visit www.atis.org. Notice of Disclaimer March 2013.1Ref 2 ATIS-1000068, Technical Report on Support of TTY Service over IP using Global Text Telephony.2Ref 3 TIA-825-A, A Frequency Shift Keyed Modem for Use on the Public Switched Telephone Net
6、work.3Ref 4 IETF RFC 4103, RTP Payload for Text Conversion.4Ref 5 FCC Doc-321705, Federal Communications Commission (FCC) Emergency Access Advisory Committee (EAAC) Report on Procedures for Calls between TTY Users and NG9-1-1 PSAPs; June 14, 2013.1Ref 6 FCC Doc-321704, Federal Communications Commiss
7、ion (FCC) Emergency Access Advisory Committee (EAAC) Report on Proposed Procedures for TTY as Text Terminal in Legacy PSAPs; June 14, 2013.1 1This document is available from the Federal Communications Commission. 2This document is available from the Alliance for Telecommunications Industry Solutions
8、 (ATIS). 3This document is available from the Telecommunications Industry Association. 4This document is available from the Internet Engineering Task Force (IETF). ATIS-0700030 6 Ref 7 3GPP TS 22.173, IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service and supplementary services;
9、 Stage 1.5Ref 8 TIA/EIA J-STD-034, Wireless Enhanced Emergency Services.2Ref 9 J-STD-036-C, Enhanced Wireless 9-1-1 Phase II, June 2011 including the addendum in J-STD-036-C-1, Addendum to J-STD-036-C, Enhanced Wireless 9-1-1 Phase II.2Ref 10 NENA 05-001, NENA Standard for the Implementation of the
10、Wireless Emergency Service Protocol E2 Interface.6Ref 11 NENA 08-502, NENA Generic E9-1-1 Requirements Technical Information Document (TID).6Ref 12 Americans with Disabilities Act (ADA).7Ref 13 NENA-STA-010.2, NENA Detailed Functional and Interface Standards for the NENA i3 Solution.6Ref 14 IETF RFC
11、 5369, Framework for Transcoding with the Session Initiation Protocol (SIP).4Ref 15 ATIS-0700015.v003, ATIS Standard for Implementation of 3GPP Common IMS Emergency Procedures for IMS Origination and ESInet/Legacy Selective Router Termination, Version 3.2Ref 16 3GPP TS 29.163, Interworking between t
12、he IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks.5Ref 17 3GPP TS 23.237, IP Multimedia Subsystem (IMS) Service Continuity; Stage 2.5Ref 18 ATIS-0700029, Real Time Text Mobile Device Behavior.2Ref 19 FCC 16-169, FCC Report and Order and Further Notice of Proposed R
13、ulemaking in the Matter of Transition from TTY to Real-Time Text Technology; December 15, 2016.13 Definitions, Acronyms, Stage 1, as specified in 3GPP TS 22.173 Ref 7, is applicable to RTT services. See clauses 4.1 and 4.2 of 3GPP TS 22.173 Ref 7. The interaction of Multimedia Telephony supplementar
14、y services as applied to the RTT service and Enterprise IP-PBX Supplementary Services as described in Annex D of 3GPP TS 22.173 Ref 7 is for further study. 6 End-to-End RTT Service Requirements 6.1 RTT Service Requirements 6.1.1 RTT Call Requirements Between RTT Users 1. The RTT service shall suppor
15、t call initiation, routing, and call completion with real-time text and voice. 2. The RTT service shall utilize IMS call control support for RTT calls. 6.1.2 Emergency Service Call Requirements 1. RTT communications with 9-1-1 emergency services shall be accomplished by initiating a voice emergency
16、call with an RTT media component (i.e., both audio and text media shall be offered in the establishment of the initial emergency call). 2. The dialed number for an RTT emergency call shall be the same number as a voice emergency call (e.g., 911). 3. The RTT equivalent of voice supplemental services
17、that are disabled for voice emergency calls shall also be disabled for the RTT emergency calls. 4. The location of the RTT-enabled mobile device shall be determined by emergency call location methodologies. 5. The same callback number shall be used independent of the callback call media. An overview
18、 of RTT emergency services is provided in Annex C. 6.1.3 General The RTT service shall support voice and RTT media operation in both directions of a conversation with all four media streams occurring simultaneously. RTT service shall consist of RTT and voice media. 6.1.4 Inclusion of the RTT Media I
19、t shall be possible to request inclusion of the RTT media by any party in the call initially in a call as well as during the call as defined in the RTT Mobile Device Behavior (MDB) specification Ref 16. ATIS-0700030 10 6.1.5 Removal of the RTT media It shall be possible to delete the RTT media from
20、the call at any point in the call after it has been included, when requested by the RTT-enabled mobile device, as defined in the RTT Mobile Device Behavior (MDB) specification Ref 18. 6.2 RTT Interworking with TTY 6.2.1 Use of Text and Audio Media RTT/TTY transcoding functions shall be activated in
21、RTT calls. For further detail, see ATIS-1000068 Ref 2. The IWF shall provide transcoding of signals between RTT and TTY devices and handle control of audio transmission between them. Transcoding TTY to RTT: 1. Baudot Frequency Shift Keying (FSK) received from the CS network shall be intercepted and
22、decoded. The resulting TTY text is translated to RTT-encoded text and transmitted to the RTT user in the text media. The original Baudot FSK signal shall not be transmitted to the RTT user in the audio media. Silence or comfort noise may be transmitted to the RTT user in the audio media. 2. When Bau
23、dot FSK is not being received from the CS network, the audio received shall be transmitted to the RTT user in the audio media. Transcoding RTT to TTY: 1. When FSK is detected from the TTY user, no text or audio transmission should be sent to the TTY user. 2. When no FSK is detected from the TTY devi
24、ce, and RTT media is received or available (buffered as described in clause 6.2.2), the received or available RTT media shall be transcoded and transmitted to the TTY device user. No voice media from the RTT call shall be transmitted to the TTY device during this period. 3. When no FSK is detected f
25、rom the TTY device, and no RTT text is available from the RTT service user for transcoding and transmission, the voice media received from the RTT service user shall be transmitted to the TTY device user. 6.2.2 Buffering RTT Text for TTY Transmission Text media received from the RTT user for which i
26、mmediate transcoding and transmission to the TTY device user is not possible (see clause 6.2.1) should be buffered. Buffer behavior and performance characteristics (e.g., buffer size) are based on operator policy. 6.2.3 Interworking Character Error Rate The IWF shall accurately decode and encode all
27、 Baudot FSK characters and RTT text that are received without errors or excessive noise and are supported by TTY. 6.3 Transmission Rate Transmission rate supported shall be as defined in the RTT Mobile Device Behavior (MDB) specification Ref 18. ATIS-0700030 11 Annex A (informative) Annex A: Use Cas
28、es This informative annex provides example use cases for RTT service usage on an end-to-end basis. These use cases are for illustrative purposes only to explain various potential scenarios when using RTT services. The RTT service implementations implied by the use case descriptions are illustrative
29、only for the purpose of describing the associated scenario and these implied implementations should not be interpreted as the only or the preferred implementation option. This informative annex describes the following use cases: Use Case 1 RTT Emergency Call and Call-Back Use Case 2 Establish Non-Em
30、ergency RTT Call Use Case 3 Add RTT Media During Voice Emergency Call Use Case 4 Add RTT Media During Voice Call Use Case 5 RTT Call to TTY Device User in Public Switched Telephone Network (PSTN) Use Case 6 Receive RTT Call from TTY Device User in PSTN Use Case 7 RTT Call To 711 For Legacy Text Rela
31、y Call to Voice Service User Use Case 8 Receive RTT Call From 711 Legacy Text Relay Service for Voice Service User Use Case 9 RTT Call To 711 For RTT Based Text Relay Call to Voice Service User Use Case 10 Initiation of A Three-Party RTT Call Use Case 11 RTT Call with Deaf-Blind RTT Service User A.1
32、 Use Case 1 RTT Emergency Call Steve via RTT media and David via voice media, with the text relay service CA converting between the media. ATIS-0700030 20 Normal Flow 1. Steve already has his mobile device turned on. 2. Steve decides to communicate with David using RTT service with support from the
33、text relay service. 3. Steve accesses the RTT service capability on his mobile device, enters “711” for the legacy text relay service, and clicks the button for an RTT call. 4. The request for an RTT call to a PSTN destination (711) activates an RTT / TTY interworking function to assist in facilitat
34、ing the communication. 5. The interworking function sends a short RTT text message to Steve, indicating that the call is going to the PSTN destination and if a TTY device answers, the user needs to obey the TTY conventions waiting for the turn indicator GA and ending turns with sending GA. This info
35、rmation ends with . indicating that Steve should wait for an answer. 6. The “711” text relay service receives an incoming voice call. 7. Celia, working as a CA in the text relay service answers Steves call with the TTY device integrated in the text relay system and types a greeting phrase asking who
36、 Steve wants to call, followed by GA. 8. Steve answers with Davids phone number followed by GA. 9. Celia calls Davids number and keeps Steve informed about the progress of the call. When David has answered via voice, Celia informs David by voice that it is a relayed call, and then she types Davids g
37、reeting phrase to Steve followed by GA. 10. Steve and David now take turn in typing/talking and Celia translates between them. They remember to type GA/say “Go Ahead” to indicate giving turn. 11. After some time of typing and talking, Steve and David are ready to terminate the call and say/type “bye
38、“. Steve also types SKSK. 12. Steve ends the RTT call by pressing the end of RTT call button. 13. David hangs up the phone. Alternative Flows None. A.8 Use Case 8 Receive RTT Call from 711 Legacy Text Relay Service for Voice Service User This use case is about using the legacy text relay service ava
39、ilable via dialing “711” for a relayed call with a voice service user calling and a mobile RTT service user answering. Short Description Steve is a wireless service user with a mobile device with RTT service functionality. Steve is deaf. To initiate a call to Steve, David, a hearing person, calls “7
40、11” to get support for a conversion between RTT media and voice media by a text relay service communications agent. Actors Steve Mobile device user, preferring RTT services. Celia Text relay communications agent (CA). David Voice service user unfamiliar with RTT services. ATIS-0700030 21 Pre-Conditi
41、ons Steves Service Providers networks support RTT service capabilities. Steves mobile device supports RTT service functionality. Steves mobile device does not have any active sessions (e.g., RTT call, voice call, messaging) prior to David initiating a voice call to “711”. Post-Condition Steve was ab
42、le to successfully communicate with David; Steve via RTT media and David via voice media, with the text relay service converting between the media. Normal Flow 1. Steve already has his mobile device turned on. 2. David decides to communicate with Steve by voice via the text relay service, which hand
43、les the conversion between text and speech. 3. David calls “711” for the legacy text relay. 4. The voice call arrives at the legacy text relay service, and Celia, working as a CA, answers it. 5. Celia asks David who he wants to call, and David responds verbally with Steves mobile phone number. 6. Ce
44、lia calls Steves number from the relay service. 7. Steve answers with RTT media and voice media activated. 8. The call is first established with voice media only, but Steves mobile device automatically adds RTT media when the initial RTT call is established. 9. The request by Steves mobile device to
45、 add RTT media to a voice call from a PSTN destination activates an RTT / TTY interworking function to assist in facilitating the communication. 10. The interworking function sends a short RTT text message to Steve, indicating that the call is going to the PSTN and if a TTY answers, the user needs t
46、o obey the TTY conventions of waiting for the turn indicator GA and ending turns with sending GA This message ends with GA indicating that Steve should provide an answer. 11. The “711” text relay service receives the answer. 12. Celia, working as a CA in the text relay service gets Steves answer wit
47、h the TTY device integrated in the text relay system and types a greeting phrase ending with . and continued with a greeting message from David. 13. Steve and David now take turn in typing / talking and Celia translates between them. They remember to type GA or say “Go Ahead” to indicate giving turn
48、. 14. After some time of typing and talking, Steve and David are ready to terminate the call and say/type “bye“. Steve also types SKSK. 15. Steve ends the RTT call by pressing the end of call button. 16. David hangs up the voice call. Alternative Flows None. ATIS-0700030 22 A.9 Use Case 9 RTT Call t
49、o 711 for RTT based Text Relay Call to Voice Service User This use case is about using a text relay service supporting RTT services for a relayed call with a voice service user. Short Description Steve is a wireless service user with a mobile device with RTT service functionality. Steve is deaf. To initiate a call to Steve, David, a hearing person, calls “711” to get support for conversion between RTT media and voice media by a text
