idnits 2.17.1 draft-manyfolks-sipping-toip-01.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(53): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(83): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(85): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(107): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(119): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(160): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(169): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(173): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(175): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(197): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(211): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(215): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(270): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(323): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(377): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(395): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(431): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(442): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(485): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(540): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(594): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(648): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(703): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(755): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(807): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(822): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(858): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(862): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(917): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(971): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1026): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1049): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1050): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1077): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1081): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1108): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1109): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1135): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1190): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1244): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1298): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1352): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1406): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1458): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1512): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1545): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1565): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1586): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1620): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1634): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1675): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1730): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1755): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1760): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1762): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1768): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1770): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1773): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1780): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1781): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1785): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1792): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1795): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1804): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1806): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1807): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1812): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1816): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** Bad filename characters: the document name given in the document, 'draft-manyfolks-sipping-ToIP-01', contains other characters than digits, lowercase letters and dash. == Mismatching filename: the document gives the document name as 'draft-manyfolks-sipping-ToIP-01', but the file name used is 'draft-manyfolks-sipping-toip-01' == There are 95 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 555 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 272: '... MAY be done to improve effic...' RFC 2119 keyword, line 274: '... MUST NOT be used....' RFC 2119 keyword, line 281: '... that text MUST be sent as soon ...' RFC 2119 keyword, line 282: '...elays. The delay MUST not be longer th...' RFC 2119 keyword, line 288: '...ime Text-over-IP MUST support a transm...' (151 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 564 has weird spacing: '...support incom...' == Line 1141 has weird spacing: '...rovides a bet...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: In order to make Real-Time Text-over-IP the equivalent of what voice is to hearing people, it needs to offer equivalent features in terms of conversation as voice communications provides to hearing people. To achieve that, real-time Text-over-IP MUST: a. Offer Real-Time presentation of the conversation. This means that text MUST be sent as soon as available, or with very small delays. The delay MUST not be longer than 500 milliseconds, b. Provide simultaneous transmission in both directions, c. Except for the case of interworking with other networks and protocols (e.g. TTY on PSTN) allow users to interrupt/barge in at any time in the conversation. d. Except for the case of interworking with other networks and protocols, Real-Time Text-over-IP MUST support a transmission rate of at least 30 characters/second. e. Support sending redundant data as described in RFC 2793 [5]. f. Be possible to merge with video transmission. == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 19 looks like a reference -- Missing reference section? '2' on line 162 looks like a reference -- Missing reference section? '3' on line 865 looks like a reference -- Missing reference section? '4' on line 1577 looks like a reference -- Missing reference section? '5' on line 1576 looks like a reference -- Missing reference section? 'I' on line 1140 looks like a reference -- Missing reference section? '6' on line 346 looks like a reference -- Missing reference section? '7' on line 800 looks like a reference -- Missing reference section? '8' on line 548 looks like a reference -- Missing reference section? '9' on line 548 looks like a reference -- Missing reference section? '10' on line 1580 looks like a reference -- Missing reference section? '11' on line 713 looks like a reference -- Missing reference section? '12' on line 757 looks like a reference -- Missing reference section? 'II' on line 1007 looks like a reference -- Missing reference section? 'III' on line 1007 looks like a reference -- Missing reference section? '15' on line 1064 looks like a reference -- Missing reference section? '16' on line 1064 looks like a reference -- Missing reference section? '17' on line 1071 looks like a reference -- Missing reference section? '18' on line 1437 looks like a reference -- Missing reference section? 'CR' on line 1535 looks like a reference -- Missing reference section? 'LF' on line 1535 looks like a reference -- Missing reference section? 'BACKSPACE' on line 1535 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 23 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIPPING WG 3 Internet Draft G. Hellstr�m (editor) 4 Document: R. R. Roy (editor) 5 Feb 2004 A. van Wijk (editor) 6 Expires: August 2004 Omnitor, AT&T, 7 Informational Viataal 9 Framework of requirements for real-time text conversation using SIP. 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026 [1]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document provides the framework of requirements for text 34 conversation with real time character-by-character interactive 35 flow over the IP network using the Session Initiation Protocol. 36 The requirements for general real-time text-over-IP telephony, 37 point-to point and conference calls, transcoding, relay services, 38 user mobility, interworking between text-over-IP telephony and 39 existing text-telephony, and some special features including 40 instant messaging have been described. 42 Table of Contents 44 1. Introduction 3 45 2. Scope 3 46 3. Terminology 3 47 4. Definitions 4 48 5. Background and General Requirements 5 49 6. Features in Real-time Text-over-IP 5 50 7. Real-Time Multimedia Conversational Sessions using SIP 6 51 8. General Requirements for Real-Time Text-over-IP using SIP 8 53 Hellstr�m, Roy, van Wijk [Page 1 of 34] 54 8.1 Pre-Call Requirements 8 55 8.2 Basic Point-to-Point Call Requirements 9 56 8.2.1 General Requirements 9 57 8.2.2 Session Setup 9 58 8.2.3 Addressing 10 59 8.2.4 Alerting 10 60 8.2.5 Call Negotiations 10 61 8.2.6 Answering 11 62 8.2.7 Session progress and status presentation 11 63 8.2.8 Actions During Calls 12 64 8.2.9 Additional session control 13 65 8.2.10 File storage 14 66 8.3 Conference Call Requirements 14 67 8.4 Transport 14 68 8.5 Character Set 14 69 8.6 Transcoding 15 70 8.7 Relay Services 15 71 8.8 Emergency services 16 72 8.9 User Mobility 16 73 8.10 Confidentiality and Security 16 74 8.11 Call Flows 17 75 8.11.1 Call Scenarios 17 76 8.11.2 Point-to-Point Call Flows 18 77 8.11.3 Conference Call Flows 18 78 9. Interworking Requirements for Text-over-IP 19 79 9.1 Real-Time Text-over-IP Interworking Gateway Services 19 80 9.2 Text-over-IP and PSTN/ISDN Text-Telephony 19 81 9.3 Text-over-IP and Cellular Wireless circuit switched Text- 82 Telephony 20 83 9.3.1 �No-gain� 20 84 9.3.2 Cellular Text Telephone Modem (CTM) 20 85 9.3.3 �Baudot mode� 21 86 9.3.4 Data channel mode 21 87 9.3.5 Common Text Gateway Functions 21 88 9.4 Text-over-IP and Cellular Wireless Text-over-IP 21 89 9.5 Instant Messaging Support 21 90 9.6 IP Telephony with Traditional RJ-11 Interfaces 22 91 9.7 Interworking Call Flows 23 92 9.8 Multi-functional gateways 24 93 9.9 Gateway Discovery 24 94 9.10 Text Gateway in the call Scenarios 25 95 9.10.1 IP terminal calling an analogue textphone (PSTN) 25 96 9.10.2 IP terminal calling a mobile text telephone (CTM) 25 97 9.10.3 IP terminal calling a mobile telephone (GPRS based) 25 98 9.10.4 IP terminal calling a mobile telephone(UMTS) 26 99 9.10.5 Analogue textphone (PSTN) user calling an IP terminal 26 100 9.10.6 Mobile text telephone (CTM) user calling an IP terminal 26 101 9.10.7 Mobile telephone user (GPRS) calling an IP terminal 26 102 9.10.8 Mobile telephone (UMTS) user calling an IP terminal 26 103 9.10.9 Voice over DSL user using an analogue text telephone. 27 104 9.10.10 VoIP user via a building telephone switch (at an apartment 105 building) owning an analogue text telephone. 27 107 Hellstr�m, Roy, van Wijk [Page 2 of 34] 108 9.10.11 VoIP user via a gateway/box connected to his/her own 109 Broadband connection owning an analogue text telephone. 27 110 10. Terminal Features 27 111 10.1 Text input 28 112 10.2 Text presentation 28 113 10.3 Call control 29 114 10.4 Device control 30 115 10.5 Alerting 30 116 10.6 External interfaces 30 117 10.7 Power 31 118 11. Security Considerations 31 119 12. Authors� Addresses 31 120 13. Full Copyright Statement 32 121 14. References 33 122 14.1 Normative 33 123 14.2 Informative 34 125 1. Introduction 127 Text-over-IP (ToIP) is becoming popular as a part of total 128 conversation among a range of users although this medium of 129 communications may be the most convenient to certain categories of 130 people (e.g., deaf, hard of hearing and speech-impaired 131 individuals). The Session Initiation Protocol (SIP) has become the 132 protocol of choice for control of Multimedia IP telephony and 133 Voice-over-IP (VoIP) communications. Naturally, it has become 134 essential to define the requirements for how ToIP can be used with 135 SIP to allow text conversations as an equivalent to voice. This 136 document defines the framework of requirements for using ToIP, 137 either by itself or as a part of total conversation using SIP for 138 session control. 140 2. Scope 142 The primary scope of this document is to define the requirements 143 for using ToIP with SIP, either stand-alone or as a part of a 144 total conversation approach. In general, the scope of the 145 requirements is: 147 a. Features in Real-Time ToIP 148 b. Real-time Multimedia Conversational Sessions using SIP 149 c. General Requirements for Real-Time ToIP using SIP 150 d. Interworking Requirements for ToIP 151 e. Text gateways in the different networks 153 The subsequent sections describe those requirements in detail. 155 3. Terminology 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 158 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 160 Hellstr�m, Roy, van Wijk [Page 3 of 34] 161 in this document are to be interpreted as described in RFC 2119 162 [2]. 164 4. Definitions 166 Full duplex � user information is sent independently in both 167 directions. 169 Half duplex � user information can only be sent in one direction 170 at a time or, if an attempt to send information in both directions 171 is made, errors can be introduced into the user information. 173 TTY � name for text telephone, often used in USA, see textphone. 175 Textphone �text telephone. A terminal device that allow end-to-end 176 real time text communication. A variety of textphone protocols 177 exists world-wide, both in the PSTN and other networks. A 178 textphone can often be combined with a voice telephone, or include 179 voice communication functions for simultaneous or alternating use 180 of text and voice in a call. 182 Text telephony � Analog textphone services 184 Text Relay Service - A third-party or intermediary that enables 185 communications between deaf, hard of hearing and speech-impaired 186 people, and voice telephone users by translating between voice and 187 text in a call. 189 Transcoding Services - Services of a third-party user agent (human 190 or automated) that transcodes one stream into another. 192 Total Conversation - A multimedia service offering real time 193 conversation in video, text and voice according to interoperable 194 standards. All media flow in real time. Further defined in ITU-T 195 F.703 Multimedia conversational services description. 197 Text gateway � A multi functionalgateway that sits at the border 198 of a network able to transcode RFC 2793 Interactive text (ToIP) 199 into a different text medium and vice versa. E.g. ToIP into Boudot 200 and vice versa in the PSTN. 202 Acronyms: 204 2G Second generation cellular (mobile) 205 2.5G Enhanced second generation cellular (mobile) 206 3G Third generation cellular (mobile) 207 CDMA Code Division Multiple Access 208 CTM Cellular Text Telephone Modem 209 GSM Global System of Mobile Communication 210 ISDN Integrated Services Digital Network 211 ITU-T International Telecommunications Union � Telecommunications 212 standardisation Sector 213 PSTN Public Switched Telephone Network 215 Hellstr�m, Roy, van Wijk [Page 4 of 34] 216 SIP Session Initiation Protocol 217 TDD Telecommunication Device for the Deaf 218 TDMA Time Division Multiple Access 219 ToIP Text over Internet Protocol 220 UTF-8 Universal Transfer Format � 8 222 5. Background and General Requirements 224 The main purpose of this document is to provide a set of 225 requirements for real-time text conversation over the IP network 226 using the Session Initiation Protocol (SIP) [3]. The overall 227 requirements described are such that the real-time text can be 228 expressed as a part of the session description as a part of the 229 total conversation like any other media. Participants can 230 negotiate all media including real-time text conversation[4, 5]. 231 This is a highly desirable function for all IP telephony 232 users,irrespective of whether the users are or are not deaf, hard 233 of hearing, or speech impaired. 235 It is important to understand that real-time text conversations 236 are significantly different from other text based communications 237 like email or instant messaging. Real-time text conversations 238 deliver an equivalent mode to voice conversations by providing 239 transmission of text character by character as it is entered, so 240 that the conversation can be followed closely and immediate 241 interaction take place, therefore providing the same mode of 242 interaction as voice telephony does. Store-and-forward systems 243 like email or messaging on mobile networks or non-streaming 244 systems like instant messaging are unable to provide that 245 functionality. 247 One particular application where real-time text is absolutely 248 essential, is the use of relay services between conversational 249 modes, like between text and voice. 251 Direct text emergency service calls, where time and continuous 252 connection are of the essence, is another essential application. 254 6. Features in Real-time Text-over-IP 256 While real-time Text-over-IP will be used for a wide variety of 257 services, an important field of application will be to provide a 258 text equivalent to voice conversation, in particular for deaf, 259 hard of hearing and speech-impaired users. 260 As such, it is crucial that the conversational nature of this 261 service is maintained. Text based communications exist in a 262 variety of forms, some non-conversational (SMS, text paging, E- 263 mail, newsgroups, message boards, etc.), others conversational 264 (TTY/TDD, Textphone, etc). 266 Real-time Text-over-IP will sometimes be used in conjunction with 267 a relay service [I] to allow text users to communicate with voice 268 users. With relay services, it is crucial that text characters are 270 Hellstr�m, Roy, van Wijk [Page 5 of 34] 271 sent as soon as possible after they are entered. While buffering 272 MAY be done to improve efficiency, the delays SHOULD be kept as 273 small as possible. In particular, buffering of whole lines of text 274 MUST NOT be used. 276 In order to make Real-Time Text-over-IP the equivalent of what 277 voice is to hearing people, it needs to offer equivalent features 278 in terms of conversation as voice communications provides to 279 hearing people. To achieve that, real-time Text-over-IP MUST: 280 a. Offer Real-Time presentation of the conversation. This means 281 that text MUST be sent as soon as available, or with very small 282 delays. The delay MUST not be longer than 500 milliseconds, 283 b. Provide simultaneous transmission in both directions, 284 c. Except for the case of interworking with other networks and 285 protocols (e.g. TTY on PSTN) allow users to interrupt/barge in at 286 any time in the conversation. 287 d. Except for the case of interworking with other networks and 288 protocols, Real-Time Text-over-IP MUST support a transmission rate 289 of at least 30 characters/second. 290 e. Support sending redundant data as described in RFC 2793 [5]. 291 f. Be possible to merge with video transmission. 293 The end-to-end delay in transmission MUST be less than 2000 294 milliseconds. 296 Many users will want to use multiple modes of communication during 297 the conversation, either at the same time or by switching between 298 modes e.g. between real-time Text-over-IP and voice. Native real- 299 time Text-over-IP systems MUST support at least the alternate use 300 of modalities and MAY support simultaneous use of modalities. 302 When communicating via a gateway to other networks and protocols, 303 the system MUST completely support the functionality for 304 alternating or simultaneous modalities as offered by the gateway. 305 When voice is supported on the terminal, the terminal MUST provide 306 volume control. 308 7. Real-Time Multimedia Conversational Sessions using SIP 310 The Session Initiation Protocol (SIP) [3] provides mechanisms for 311 creating, modifying, and terminating sessions for real-time 312 conversation with one or more participants using any combination 313 of media: Text, Video and Audio. However, participants are allowed 314 to negotiate on a set of compatible media types (e.g., Text, 315 Video, Audio) with session descriptions used in SIP invitations. 317 The standardized T.140 real-time text conversation [4], in 318 addition to audio and video communications, will be valuable 319 services to many. Real-time text can be expressed as a part of the 320 session description in SIP and will be a useful subset of the 321 Total Conversation (e.g., Real-time text, Video and Audio). 323 Hellstr�m, Roy, van Wijk [Page 6 of 34] 324 This specification describes the framework for using the T.140 325 text conversation in SIP as a part of the multimedia session 326 establishment in real-time over a SIP network. 328 The session establishment using SIP defines procedures for how 329 T.140 text conversation can be supported using a RTP payload 330 defined in RFC 2793 [5]. The performance characteristics of T.140 331 will be determined using RTCP. 333 The session will not only define procedures between the SIP 334 devices having text conversation capability, but will also define 335 how sessions in SIP can be established between the text 336 conversation and audio/video/text capable devices transparently. 338 If there is any incompatibility between the terminals, e.g. T.140 339 only and audio-only terminals, the necessary transcoding services 340 will need to be invoked. This important service feature invites a 341 variety of rich capabilities in the transcoding server. For 342 example, speech-to-text (STT), text-to-speech (TTS), text bridging 343 after conversion from speech, audio bridging after conversion from 344 text, and other services can also be provided by the transcoding 345 and/or translation server. The session description protocol (SDP) 346 [6] used in SIP to describe the session also needs to be capable 347 of expressing these attributes of the session (e.g., uniqueness in 348 media mapping for conversion from one media to another for each 349 communicating party). 351 Real-time texts can also be presented in conjunction with video. 353 Alerting for T.140 terminals needs to be provided. Users may set 354 up text conversation sessions using SIP from any location. In 355 addition, user privacy and security MUST be provided for text 356 conversation sessions at least equal to that for voice. 358 The transcoding/translation services can be invoked in SIP using 359 different session establishment models [7]: Third party call 360 control [8] and Conference Bridge model [9]. 362 Both point-to-point and multipoint communication need to be 363 defined for the session establishment using T.140 text 364 conversation. In addition, the interworking between T.140 text 365 conversation and text telephony conversation [10] is needed. 367 The general requirements for real-time text conversation using SIP 368 can be described as follows: 370 a. Session setup, modification and teardown procedures for point- 371 to-point and multimedia calls 372 b. Registration procedures and address resolutions 373 c. Negotiation procedures for device capabilities 374 d. Discovery and invocation of transcoding/translation services 375 between the media in the call 377 Hellstr�m, Roy, van Wijk [Page 7 of 34] 378 e. Different session establishment models for 379 transcoding/translation services invocation: Third party call 380 control and Conference bridge model 381 f. Uniqueness in media mapping to be used in the session for 382 conversion from one media to another by the 383 transcoding/translation server for each communicating party 384 g. Media bridging services for T.140 real-time text, audio, and 385 video for multipoint communications 386 h. Transparent session setup, modification, and teardown between 387 text conversation capable and voice/video capable devices 388 i. Conversations to be carried out using T.140-over-RTP and RTCP 389 will provide performance report for T.140 390 j. Altering capability using text conversation during the session 391 establishment 392 k. T.140 real-time text presentation mixing with voice and video 393 l. T.140 real-time text conversation sessions using SIP, allowing 394 users to move from one place to another 395 m. Users� privacy and security for sessions setup, modification, 396 and teardown as well as for media transfer 397 n. Interoperability between T.140 conversations and text telephony 399 8. General Requirements for Real-Time Text-over-IP using SIP 401 The communications environments for ToIP using SIP to set up the 402 conversation in real-time may vary from a simple point-to-point 403 call to multipoint calls in addition to the fact that ToIP can be 404 used in combination with other media like audio and video. In 405 order to establish the session in real-time, the communicating 406 parties SHOULD be provided with experiences like those of normal 407 telephony call setup. There may also be some need for pre-call 408 setup e.g. storing registration information in the SIP registrar 409 to provide information about how a user can be contacted. This 410 will allow calls to be set up rapidly and with proper addressing. 412 Similarly, there are requirements that need to be satisfied during 413 call set up when another media is preferred by a user. For 414 instance, some users may prefer to use audio while others want to 415 use text as their preferred choice of conversational mode. In this 416 case, transcoding services will need to be invoked for text-to- 417 speech (TTS) and speech-to-text (STT). The requirements for 418 transcoding services need to be negotiated in real-time to set up 419 the session. 421 The subsequent subsections describe those requirements in great 422 detail. 424 8.1 Pre-Call Requirements 426 The desire of the users for using ToIP as a medium of 427 communications can be expressed during registration time. Two 428 situations need to be considered in the pre-call setup 429 environment: 431 Hellstr�m, Roy, van Wijk [Page 8 of 34] 432 a. User Preferences: It MUST be possible for a user to indicate a 433 preference for ToIP by registering that preference in a SIP 434 server. If the user is called by other party, preferences can be 435 invoked by the SIP server to accept or reject the call based on 436 the rules defined by the user. If the rules require that a 437 transcoding server is needed, the call can be re-directed or 438 handled accordingly. 440 b. Server to support User Preferences: SIP servers MUST have the 441 capability to act on users preferences for ToIP, based on the 442 users� preferences defined during the pre-call setup registration 443 time. 445 8.2 Basic Point-to-Point Call Requirements 447 The point-to-point call will take place between two parties. The 448 requirements are described in subsequent sub-sections. They assume 449 that one or both of the communicating parties will indicate ToIP 450 as the preferred medium for conversation using SIP in the session 451 setup. 453 8.2.1 General Requirements 455 The general requirements are that ToIP will be chosen from the 456 available media as the preferred means of communication for the 457 session. However, there may be a need to invoke some underlying 458 capabilities in some cases, for example, a transcoding server may 459 be invoked if one of the users want to use a communication medium 460 other than ToIP. 461 The following entities MAY need to be involved to facilitate the 462 session establishment using ToIP as another medium: 464 a. Caller Preferences: SIP headers (e.g., Contact) can be used to 465 show that ToIP is the medium of choice for communications. 466 b. Called Party Preferences: The called party being passive can 467 formulate a clear rule indicating how a call should be handled 468 either using ToIP as a preferred medium or not, and whether a 469 designated SIP proxy needs to handle this call or it is handled in 470 the SIP user agent (UA). 471 c. SIP Server support for User Preferences: SIP servers can also 472 handle the incoming calls in accordance to preferences expressed 473 for ToIP. The SIP Server can also enforce ToIP policy rules for 474 communications (e.g., use of the transcoding server for ToIP). 476 8.2.2 Session Setup 478 Users will set up a session by identifying the remote party or the 479 service they will want to connect to. However, conversations could 480 be started using a mode other than real-time Text-over-IP. For 481 instance, the conversation might be established using voice and 482 the user could elect to switch to text, or add text, during the 483 conversation. Systems supporting real-time Text-over-IP MUST allow 485 Hellstr�m, Roy, van Wijk [Page 9 of 34] 486 users to select any of the supported conversation modes at any 487 time, including mid-conversation. 489 Systems SHOULD allow the user to specify a preferred mode of 490 communication, with the ability to fall back to alternatives that 491 the user has indicated are acceptable. 493 If the user requests simultaneous use of text and voice, and this 494 is not possible either because the system only supports alternate 495 modalities or because of resource management on the network, the 496 system MUST try to establish a text-only communication. and the 497 user MUST be informed of this change throughout the process, 498 either in text or in a combination of modalities that MUST include 499 text. 501 Session setup, especially through gateways to other networks, MAY 502 require the use of prefixes or the use of specially formatted 503 URLs. 504 This MUST be supported by the terminal. 506 8.2.3 Addressing 508 The SIP [3] addressing schemes MUST be used for all entities. For 509 example SIP URL and Tel URL will be used for caller, called party, 510 user devices, and servers (e.g., SIP server, Transcoding server). 512 The right to include a transforming or translating service MUST 513 NOT require user registration in any specific SIP registrar. 515 8.2.4 Alerting 517 Systems supporting real-time Text-over-IP MUST have an alerting 518 method (e.g., for incoming calls and messages) that can be used by 519 deaf and hard of hearing people or provide a range of alternative, 520 but equivalent, alerting methods that are suitable for all users, 521 regardless of their abilities and preferences. 523 It should be noted that general alerting systems exist, and one 524 common interface for triggering the alerting action is a contact 525 closure between two conductors. 527 Among the alerting options are alerting on the user equipment and 528 specific alerting user agents registered to the same registrar as 529 the main user agent. 531 If present, identification of the originating party (for example 532 in the form of a URL or CLI) MUST be clearly presented to the user 533 in a form suitable for the user BEFORE answering the request. When 534 the invitation to initiate a conversation involving real-time 535 Text-over-IP originates from a gateway, this MAY be signalled to 536 the user. 538 8.2.5 Call Negotiations 540 Hellstr�m, Roy, van Wijk [Page 10 of 34] 541 The Session Description Protocol (SDP) used in SIP [3] provides 542 the capabilities to indicate ToIP as a media for the call setup. 543 RFC 2793 [5] provides the RTP payload type for support of ToIP 544 which can be indicated in the SDP as a part of SDP INVITE, OK and 545 SIP/200/ACK for media negotiations. In addition, SIP�s 546 offer/answer model can also be used in conjunction with other 547 capabilities including the use of a transcoding server for 548 enhanced call negotiations [7,8,9]. 550 8.2.6 Answering 552 Systems SHOULD provide a best-effort approach to answering 553 invitations for session set-up and users should be kept informed 554 at all times about the progress of session establishment. On all 555 systems that both inform users of session status and support real- 556 time Text-over-IP, this information MUST be available in text, and 557 may be provided in other visual media. 559 8.2.6.1 Auto-Answer 561 Systems for real-time Text-over-IP MAY support an auto-answer 562 function, equivalent to answering machines on telephony networks. 563 If an auto-answer function is supported, it MUST support at least 564 160 characters for the recorded message. It MUST support incoming 565 text message storage of a minimum of 16000 characters, although 566 systems MAY support much larger storage. 568 When the auto-answer function is activated, user alerting MUST 569 still take place. The user MUST be allowed to monitor the auto- 570 answer progress and MUST be allowed to intervene during any stage 571 of the auto-answer and take control of the session. 573 8.2.7 Session progress and status presentation 575 During a conversation that includes real-time Text-over-IP, status 576 and session progress information MUST be provided in text. That 577 information MUST be equivalent to session progress information 578 delivered in any other format, for example audio. Users MUST be 579 able to manage the session and perform all session control 580 functions based on the textual session progress information. 582 The user MUST be informed of any change in modalities. 584 Session progress information MUST use simple language as much as 585 possible so that it can be understood by as many users as 586 possible. 587 The use of jargon or ambiguous terminology SHOULD be avoided at 588 all times. It is RECOMMENDED to let text information be used 589 together with icons symbolising the items to be reported. 591 There MUST be a clear indication, both visually as well as audibly 592 whenever a session gets connected and disconnected. The user 594 Hellstr�m, Roy, van Wijk [Page 11 of 34] 595 should never be in doubt as to what the status of the connection 596 is, even if he/she is not able to use audio feedback or vision. 598 8.2.8 Actions During Calls 600 Certain actions need to be performed for the ToIP conversation 601 during the call and these actions are describe briefly as follows: 603 a. Text transmission SHALL be done character by character as 604 entered, or in small groups transmitted so that no character is 605 delayed between entry and transmission by more than 300 606 milliseconds. 607 b. The text transmission SHALL allow a rate of at least 30 608 characters per second so that human typing speed as well as speech 609 to text methods of generating conversation text can be supported. 610 c. After text connection is established, the mean end-to-end delay 611 of characters SHALL be less than two seconds, measured between two 612 ToIP users. This requirement is valid as long as the text input 613 rate is lower or equal to the text reception and display rate. 614 d. The character corruption rate SHALL be less than 1% in 615 conditions where users experience the quality of voice 616 transmission to be low but useable. This is in accordance with 617 ITU-T F.700 Annex A.3 quality level T1. 618 e. When interoperability functions are invoked, there may be a 619 need for intermediate storage of characters before transmission to 620 a device receiving slower than the typing speed of the sender. 621 Such temporary storage SHALL be dimensioned to adjust for 622 receiving at 30 characters per second and transmitting at 6 623 characters per second during at least 4 minutes [less than 3k]. 624 f. If text is detected to be missing after transmission, there 625 SHALL be an indication in the text marking the loss. 626 g. When used from a terminal designed for PSTN text telephony, or 627 in interworking with such a terminal, ToIP shall enable 628 alternating between text and voice in a similar manner as the PSTN 629 text telephone handles this mode of operation. (This mode is often 630 called VCO/HCO in USA). 631 h. The transmission of the text conversation SHALL be made 632 according to an internationally suitable character set and control 633 protocol for text conversation as specified in ITU-T T.140. 634 i. When display of the conversation on end user equipment is 635 included in the design, display of the dialogue SHALL be made so 636 that it is easy to read text belonging to each party in the 637 conversation. 639 8.2.8.1 Text and other Media Handling Between ToIP Devices 641 The native ToIP devices do not need transcoding from speech to 642 text and can communicate directly. 644 I. When used between terminals designed for native ToIP, it SHALL 645 be possible to send and receive text simultaneously with the other 646 media (text, audio and/or video) supported by the same terminals. 648 Hellstr�m, Roy, van Wijk [Page 12 of 34] 649 II. When used between terminals designed for native ToIP, it SHALL 650 be possible to send and receive text simultaneously. 652 8.2.8.2 General Actions 654 a. It SHALL be possible to establish a session with text 655 capabilities enabled at the beginning of a Call. Note: a call is 656 in this document defined as one or more sessions). 657 b. It SHALL be possible to place a call without text capabilities, 658 and to add text capabilities later in the call. 659 c. It SHALL be possible to transfer text at at least 30 characters 660 per second 661 d. It SHALL be possible to talk and listen simultaneously with 662 typing and reading. 664 8.2.8.3 Call Action with Native ToIP Devices 666 a. It SHALL be possible to answer a callwith text capabilities 667 enabled. 668 b. It SHOULD be possible to use video simultaneously with the 669 other media in the call. 670 c. It SHALL be possible to answer a callin voice or video without 671 text enabled, and add text later in the call. 672 d. It SHALL be possible to disconnect the call. 673 e. It SHOULD be possible to control IVR (Interactive Voice 674 Response) services from a numeric keypad. 675 f. It SHOULD be possible to control ITR ( Interactive Text 676 Response) services from the alphanumeric keyboard. 677 g. It SHOULD be possible to invoke multi-party calls. 678 h. It SHALL be possible to transfer the call. 679 i. It SHOULD be possible to use text characters (numbers) instead 680 of DTMF tones (numbers) in interactions where the person is using 681 a keyboard to interact with a service and the service asks for a 682 number. 684 8.2.8.4 Audio/Visual/Tactile Indicators 686 It SHALL be possible to observe visual or tactile indicators 687 about: 688 - Call progress 689 - Availability of text, voice and video channels. 690 - Incoming call. 691 - Incoming text. 692 - Typed and transmitted text. 693 - Any loss in incoming text. 695 8.2.9 Additional session control 697 Systems that support additional session control features, for 698 example call waiting, forwarding, hold etc on voice calls, MUST 699 offer equivalent functionality for real-time Text-over-IP 700 functions. In addition, all these features MUST be controllable by 701 text users at any time, in an equivalent way as for other users. 703 Hellstr�m, Roy, van Wijk [Page 13 of 34] 704 It SHOULD be possible to use text characters (numbers) instead of 705 DTMF tones (numbers) in interactions where the person is using a 706 keyboard to interact with a service and the service asks for a 707 number. 709 8.2.10 File storage 711 Systems that support real-time Text-over-IP MAY save the text 712 conversation to a file. This SHOULD be done using a standard file 713 format. It is recommended to use an xhtml [11] format. 715 8.3 Conference Call Requirements 717 The conference call requirements deal with multipoint conferencing 718 calls where there will be at least one or more ToIP capable 719 devices along with other end user devices where the total number 720 end user devices will be at least three. 722 8.4 Transport 724 ToIP SHALL use RTP as the default transport protocol for 725 transmission of real-time text as specified in RFC 2793 [5]. 726 Signaling and other media will use the transport protocol 727 specified in SIP [3] and/or their revised versions as specified in 728 standards. 730 The redundancy method of RFC 2198 SHOULD be used for making text 731 transmission reliable with transmission of three generations. 733 Text capability SHOULD be announced in SDP by a declaration in 734 line with this example: 736 m=text 11000 RTP/AVP 98 100 737 a=rtpmap:98 t140/1000 738 a=rtpmap:100 red/1000 739 a=fmtp:100 98/98 741 Characters SHOULD BE buffered for transmission and transmitted 742 every 300 ms. 744 By having this single coding and transmission scheme for real time 745 text defined, in the SIP call control environment, the opportunity 746 for interoperability is optimised. 748 However, if good reasons exist, other transport mechanisms MAY be 749 offered and used for the T.140 coded text, provided that proper 750 negotiation is introduced, and RFC 2793 transport is used as the 751 defaut fallback solution. 753 8.5 Character Set 755 Hellstr�m, Roy, van Wijk [Page 14 of 34] 756 a. Real-Time Text-over-IP protocols MUST use UTF-8 encoding as 757 specified in ITU-T T.140 [12]. A number of characters used in 758 traditional text telephony have special meanings. 759 b. Real-time Text-over-IP SHALL handle characers with editing 760 effect such as new line, erasure and alerting during session as 761 specified in ITU-T T.140. 763 8.6 Transcoding 765 Transcoding of text may need to take place in gateways between 766 ToIP and other forms of text conversation. ToIP make use of ISO 767 10646 character set. 768 Most PSTN textphones use a 7-bit character set, or a character set 769 that is converted to a 7-bit character set by the V.18 modem. 771 When transcoding between these character sets and T.140 in 772 gateways, special consideration MUST be paid to the national 773 variants of the 7 bit codes, with national characters mapping into 774 different codes in the ISO 10 646 code space. The national variant 775 to be used SHOULD be possible to select by the user per call, or 776 be configured as a national default for the gateway. 778 The missing text indicator in T.140, specified in T.140 amendment 779 1, cannot be represented in the 7 bit character codes. Therefore 780 these characters SHALL be translated to be represented by the ' 781 (apostrophe) character in legacy text telephone systems where this 782 character exists. For legacy systems where the character ' does 783 not exist, the character . ( full stop ) SHALL be used instead. 785 8.7 Relay Services 787 The relay service acts as an intermediary between 2 or more 788 callers. 789 The basic relay service allows a translation of speech to text and 790 text to speech, which enables hearing and speech impaired callers 791 to communicate with hearing callers. Even though this document 792 focuses on ToIP, we do not exclude video relay services for e.g., 793 speech to sign language and vice versa and other possible relay 794 services. It will be possible to use ToIP simultaneously with 795 other relay services if desired. 797 It is very important for the users that a relay session is invoked 798 as transparently as possible. It SHOULD happen automatically when 799 the call is being set-up or by a simple user action. A transcoding 800 framework document using SIP [7] describes invoking relay 801 services, where the relay acts as a conference bridge or uses the 802 third party control mechanism. 804 Adding or removing a relay service MUST be possible without 805 disrupting the current call. 807 Hellstr�m, Roy, van Wijk [Page 15 of 34] 808 When setting up a call, the relay service MUST be able to 809 determine the type of service requested (e.g. speech to text or 810 text to speech), to indicate if the caller wants voice carry over, 811 the language of the text including the sign language being used. 813 The user MUST be provided with a method to indicate which service 814 is desired. 816 It MUST be possible to identify ToIP sessions as emergency 817 sessions. 819 The relay service operator MUST be able to process such a session 820 correctly and quickly. 822 a. The relay service operator�s network must give priority to this 823 incoming call. 824 b. The relay service operator MUST forward this session if they 825 are unable to process it to an alternative emergency relay 826 operator. 827 c. The relay service MUST label the transcoded stream as an 828 emergency call (in case of text to speech and/or vice versa). 829 d. The relay service MUST provide all session information to the 830 emergency centre (e.g., location information of the caller if 831 available). 833 Relay services must be available all the time, even if the users 834 are roaming. 836 8.8 Emergency services 838 a. It SHALL be possible to support emergency service calls with 839 text only or simultaneously with voice. 840 b. All session information that accompanies a voice session to the 841 emergency centre, shall also be provided to the emergency centre 842 if it is a ToIP session.(e.g, phone number and location 843 information of the user placing the emergency call). 844 c. A text over IP stream must be labelled as an emergency stream 845 to ensure that the emergency service center is able to receive 846 this call. 848 8.9 User Mobility 850 ToIP terminals SHALL use the same mechanisms as other terminals to 851 resolve mobility issues. It is RECOMMENDED to use a SIP-adress for 852 the users, resolved by a SIP REGISTRAR, to enable basic user 853 mobility. Further mechanisms are defined for the 3G IP multimedia 854 systems. 856 8.10 Confidentiality and Security 858 Users� confidentiality and privacy need to be met as described in 859 SIP [3]. For example, nothing should reveal the fact that the user 860 of ToIP is a person with a disability unless the user prefers to 862 Hellstr�m, Roy, van Wijk [Page 16 of 34] 863 make this information public. If a transcoding server is being 864 used, this SHOULD be transparent. Encryption SHOULD be used on 865 end-to-end or hop-by-hop basis as described in SIP [3]. 867 Authentication needs to be provided for users in addition to the 868 message integrity and access control. 870 Protection against Denial-of-service (DoS) attacks needs to be 871 provided considering the case that the ToIP users might need 872 transcoding servers. 874 8.11 Call Flows 876 ToIP is a way of establishing the real-time conversation. Call 877 flow for ToIP SHOULD be as similar to audio and video session 878 establishment. For example, ToIP services MAY be invoked in the 879 following situations (among others): 881 - Noisy environment (e.g., in a machine room of a factory where 882 listening is difficult)Busy with another call and want to 883 participate in two calls at the same time 884 - Text and/or speech recording services (e.g., text 885 documentation/audio recording for legal/clarity/flexibility 886 purposes) 887 - Overcoming of language barriers through speech translation 888 and/or transcoding services 889 - Not hearing well or at all (e.g., hearing loss due to aging, 890 heard of hearing, deaf) 892 NOTE: In many of the above scenarios, text may accompany speech in 893 a caption like fashion. This would occur for individuals who are 894 hard of hearing and also for mixed calls with a hearing and deaf 895 person listening to the call. 897 All call flows either for the point-to-point or for the multipoint 898 need to consider that ToIP services may be invoked for many 899 different reasons by users as explained. When the 900 transcoding/translation services are needed, call flows will be 901 shown for both session establishment models: Third-party call 902 control model and Conferencing bridge model. 904 8.11.1 Call Scenarios 906 There are 2 different terminal types possible: 908 1. The terminal itself has the intelligence to initiate a relay 909 service for incoming and outgoing calls (based on address book, 910 user preferences programmed on the terminal etc. This terminal can 911 be used in a conference bridge call as well as a third party 912 control call. 914 2. Dumb terminals, so that the relay service server actually 915 initiates the correct call handling (the dumb terminal can only 917 Hellstr�m, Roy, van Wijk [Page 17 of 34] 918 REFER the call to the relay center, which then sets up the call 919 using the conference bridge flow.). 921 The following call scenarios are shown: 923 - Communications between two ToIP/Multimedia capable, end user 924 devices using the same language. 925 - Communications between ToIP capable, end user devices using 926 translation services to provide language translation. 927 - Communications between ToIP/Multimedia capable and Audio (non- 928 ToIP) capable end user devices. 929 - Communications between ToIP/Multimedia and/or Audio (non- 930 ToIP)/Multimedia end user devices maintaining privacy. 932 8.11.2 Point-to-Point Call Flows 934 The point-to-point calls will contain at least one or both 935 ToIP/Multimedia devices in setting up the session. The detail call 936 flows need to be provided in the following scenarios: 938 - ToIP/Multimedia devices that use the same language. 939 - ToIP/Multimedia devices invoke translation services for using 940 different languages. 941 * Third-party call control model. 942 * Conference bridge service model. 943 - ToIP/Multimedia devices invoke translation services for using 944 different languages maintaining privacy. 945 * Third-party call control model. 946 * Conference bridge service model. 947 - ToIP/Multimedia device and Audio (non-ToIP)/Multimedia device 948 invoking transcoding server. 949 * Call initiated by Audio (non-ToIP)/Multimedia user 950 - Third-party call control model. 951 - Conference bridge service model. 952 * Call initiated by ToIP user. 953 - Third-party call control model. 954 - Conference bridge service model. 955 - ToIP/Multimedia device and Audio (non-ToIP)/Multimedia device 956 invoking transcoding server maintaining privacy. 957 * Call initiated by Audio (non-ToIP)/Multimedia user 958 - Third-party call control model. 959 - Conference bridge service model. 960 * Call initiated by ToIP user. 961 - Third-party call control model. 962 - Conference bridge service model. 964 8.11.3 Conference Call Flows 966 Conference call flows only contain the multipoint communications 967 scenarios, and only the centralized bridge model is considered. 968 The following multipoint conference call flow scenarios will 969 contain at least one more ToIP/Multimedia devices: 971 Hellstr�m, Roy, van Wijk [Page 18 of 34] 972 - ToIP/Multimedia devices that use the same language. 973 - ToIP/Multimedia devices invoke translation services for using 974 different languages. 975 - ToIP/Multimedia devices invoke translation services for using 976 different languages maintaining privacy. 977 - ToIP/Multimedia device and Audio (non-ToIP)/Multimedia device 978 invoking transcoding server. 979 * Call initiated by Audio (non-ToIP)/Multimedia user. 980 * Call initiated by ToIP/Multimedia user. 981 - ToIP/Multimedia device and Audio (non-ToIP)/Multimedia device 982 invoking transcoding server maintaining privacy. 983 * Call initiated by Audio (non-ToIP)/Multimedia user. 984 * Call initiated by ToIP/Multimedia user. 986 9. Interworking Requirements for Text-over-IP 988 A number of systems for real time text conversation already exist 989 as well as a number of message oriented text communication 990 systems. Interoperability is of interest between ToIP and some of 991 these systems. This section describes requirements on this 992 interoperability. 994 9.1 Real-Time Text-over-IP Interworking Gateway Services 996 Interactive texting facilities exist already in various forms and 997 on various networks. On the PSTN, it is commonly referred to as 998 text telephony. The simultaneous or alternating use of voice and 999 text is used by a large number of users who can send voice, but 1000 must receive text or who can hear but must send text due to a 1001 speech disability. 1003 9.2 Text-over-IP and PSTN/ISDN Text-Telephony 1005 On PSTN networks, transmission of interactive text takes place 1006 using a variety of codings and modulations, including ITU-T V.21 1007 [II], Baudot, DTMF, V.23 [III] and others. Many difficulties have 1008 arisen as a result of this variety in text telephony protocols and 1009 the ITU-T V.18 [10] standard was developed to address some of 1010 these issues. 1012 ITU-T-V.18 [10] offers a native text telephony method plus it 1013 defines interworking with current protocols. In the interworking 1014 mode, it will recognise one of the older protocols and fall back 1015 to that transmission method when required. 1017 In order to allow systems and services based on Real-time Text- 1018 over-IP to communicate with PSTN text telephones, text gateways 1019 are the recommended approach. These gateways MUST use the ITU-T 1020 V.18 [10] standard at the PSTN side. 1022 Buffering MUST be used to support different transmission rates. At 1023 least 1K buffer MUST be provided. 2K is recommended. In addition, 1024 the gateway MUST provide a minimum throughput of at least 30 1026 Hellstr�m, Roy, van Wijk [Page 19 of 34] 1027 characters/second or the highest speed supported by the PSTN text 1028 telephony protocol side, whichever is the lowest. 1030 PSTN-Real-time Text-over-IP gateways MUST allow alternating use of 1031 text and voice. 1033 PSTN and ISDN to real-time Text-over-IP gateways that receive CLI 1034 information from the originating party MUST pass this information 1035 to the receiving party as soon as possible. 1037 Priority MUST be given to calls labeled as emergency calls. 1039 9.3 Text-over-IP and Cellular Wireless circuit switched Text- 1040 Telephony 1042 Cellular wireless (or Mobile) circuit switched connections provide 1043 a digital real-time transport service for voice or data. 1044 The access technologies include GSM, CDMA, TDMA, iDen and various 1045 3G technologies. 1047 Alternative means of transferring the Text telephony data have 1048 been developed when TTY services over cellular was mandated by the 1049 FCC in the USA. They are a) �No-gain� codec solution, b) the 1050 Cellular Text Telephony Modem (CTM) solution and c) �Baudot mode� 1051 solution. 1053 The GSM and 3G standards from 3GPP make use of the CTM modem in 1054 the voice channel for text telephony. 1055 However, implementations also exist that use the data channel to 1056 provide such functionality. Interworking with these solutions 1057 SHOULD be done using text gateways that set up the data channel 1058 connection at the GSM side and provide real-time Text-over-IP at 1059 the other side. 1061 9.3.1 �No-gain� 1063 The �No-gain� text telephone transporting technology uses 1064 specially modified EFR [15] and EVR [16] speech vocoders in both 1065 mobile terminals used provide a text telephony call. It provides 1066 full duplex operation and supports alternating voice and 1067 text.("VCO/HCO"). 1069 9.3.2 Cellular Text Telephone Modem (CTM) 1071 CTM [17] is a technology independent modem technology that 1072 provides the transport of text telephone characters at up to 10 1073 characters/sec using modem signals that are at or below 1 kHz and 1074 uses a highly redundant encoding technique to overcome the fading 1075 and cell changing losses. On any interface that uses analog 1076 transmission, half-duplex operation must be supported as the 1077 �send� and �receive� modem frequencies are identical. The use of 1078 CTM may have to be modified slightly to support half-duplex 1079 operation. 1081 Hellstr�m, Roy, van Wijk [Page 20 of 34] 1082 9.3.3 �Baudot mode� 1084 This term is often used by cellular terminal suppliers for a GSM 1085 cellular phone mode that allows TTYs to operate into a cellular 1086 phone and to communicate with a fixed line TTY. 1088 9.3.4 Data channel mode 1090 Many mobile terminals allow the use of the data channel to 1091 transfer data in real-time. Data rates of 9600 bit/s are usually 1092 supported. 1094 9.3.5 Common Text Gateway Functions 1096 Text Gateways MUST support the differences that result from 1097 different text protocols. The protocols to be supported will 1098 depend on the service requirements of the Gateway. 1100 Different data rates of different protocols MAY require text 1101 buffering. 1103 Interoperation of half-duplex and full-duplex protocols MAY 1104 require text buffering and some intelligence to determine when to 1105 change direction when operating in half-duplex. 1107 Identification may be required of half-duplex operation either at 1108 the �user� level (ie. users must inform each other) or at the 1109 �protocol� level (where an indication must be sent back to the 1110 Gateway). 1112 A Text Gateway MUST be able to route text calls to emergency 1113 service providers when any of the recognised emergency numbers 1114 that support text communications for the country are called eg. 1115 �911� in USA. 1117 A text gateway (MUST)/SHOULD act transparantly on the IP side. It 1118 acts then as a virtual end-point terminal. 1120 9.4 Text-over-IP and Cellular Wireless Text-over-IP 1122 Text-over-IP MAY be supported over the cellular wireless packet 1123 switched service. It interfaces to the Internet. 1125 A Text gateway with cellular wireless packet switched services 1126 MUST be able to route text calls into emergency service providers 1127 when any of the recognized emergency numbers that support text 1128 communication for the country are called. 1130 9.5 Instant Messaging Support 1132 Instant Messaging is used by many people to communicate using text 1133 via the Internet. Instant Messaging transfers blocks of text 1135 Hellstr�m, Roy, van Wijk [Page 21 of 34] 1136 rather than streaming as is used for real-time Text-over-IP. As 1137 such, it is not a replacement for real-time Text-over-IP and in 1138 particular does not meet the needs for real time conversations of 1139 deaf, hard of hearing and speech-impaired users. It is unsuitable 1140 for communications through a relay service [I]. The streaming 1141 character of real-time Text-over-IP provides a better user 1142 experience and, when given the choice, users often prefer real- 1143 time Text-over-IP. 1145 However, since some users might only have Instant Messaging 1146 available, text gateways might be developed that allow 1147 interworking between Instant Messaging systems and real-time Text- 1148 over-IP solutions. 1150 Because Instant Messaging is based on blocks of text, rather than 1151 on a continuous stream of characters, such gateways need to 1152 transform between these two formats. Text gateways for 1153 interworking between Instant Messaging and real-time Text-over-IP 1154 MUST concatenate individualcharacters originating at the real-time 1155 Text-over-IP side into blocks of text and: 1157 a. When the length of the concatenated message becomes longer than 1158 50 characters, the buffered text MUST be transmitted to the 1159 Instant Messaging side as soon as any non-alphanumerical character 1160 is received from the real-time Text-over-IP side. 1162 b. When a single carriage return, a single line feed, a carriage 1163 return/line feed pair or a line feed/carriage return pair is 1164 received from the real-time Text-over-IP side, the buffered 1165 characters up to that point, including the carriage return and/or 1166 line feed characters, MUST be transmitted to the Instant Messaging 1167 side. 1169 c. When the real-time Text-over-IP side has been idle for at least 1170 5 seconds, all buffered text up to that point MUST be transmitted 1171 to the Instant Messaging side. 1173 Many Instant Messaging protocols signal that a user is typing to 1174 the other party in the conversation. Text gateways between Instant 1175 Messaging and real-time Text-over-IP MAY provide this signaling to 1176 the Instant Messaging side when characters start being received, 1177 either at the beginning of the conversation. 1179 It is also possible to introduce the chat feature of certain 1180 Instant Messaging protocols. When the chat feature is selected, 1181 the IM client should use real-time text over IP. In this way, an 1182 IM client can also be used for real-time streaming text over IP. 1184 9.6 IP Telephony with Traditional RJ-11 Interfaces 1186 Analogue adapters using SIP based IP communication and RJ-11 1187 connectors for connecting traditional PSTN devices SHOULD enable 1188 connection of legacy PSTN text telephones [18]. These adapters 1190 Hellstr�m, Roy, van Wijk [Page 22 of 34] 1191 SHOULD contain V.18 modem functionality, voice handling 1192 functionality, and conversion functions to/from SIP based ToIP 1193 with T.140 transported in according to RFC 2793, in a similar way 1194 as it provides interoperability for voice calls. If a call is set 1195 up and RFC2793 capability is not declared by the endpoint (by the 1196 end-point terminal or the text gateway in the network at the end- 1197 point), a method for invoking a transcoding server shall be used. 1198 If no such server is available, the signals from the textphone MAY 1199 be transmitted in the voice channel as audio with high quality of 1200 service. 1201 NOTE: It is preferred that such analogue adaptors do use RFC2793 1202 on board and thus act as a text gateway. Sending textphone signals 1203 over the voice channel is undesirable due posible filtering and 1204 compression between the 2 end-points. Which can result in dropping 1205 characters in the textphone conversation or even not allowing the 1206 textphones to connect with each other. 1208 9.7 Interworking Call Flows 1210 << this chapter will change depending on how chapter 9.10 works 1211 out>> 1213 The call flows in chapter 8.11 deal with end to end ToIP. These 1214 call flows do not change on the IP network when one end-point is 1215 actually a text gateway. The text gateway actually acts like a 1216 ToIP/Multimedia device. Separate call flows will show the 1217 interworking between the ToIP/Multimedia devices [4] over the IP 1218 network and the text telephony devices [10] over the PSTN/ISDN 1219 network using the IP-PSTN/ISDN interworking functional (IWF) 1220 entity. It is assumed that the IWF will provide ToIP and text 1221 telephony interworking in addition to other capabilities. Thus 1222 acting as a Text gateway. 1224 �The point-to-point call flows will contain at least one 1225 ToIP/Multimedia and one text telephony/multimedia (or POTS) device 1226 for the following cases: 1228 - ToIP/Multimedia device and text telephony/multimedia device that 1229 use the same/different language. 1230 - ToIP/Multimedia device and PSTN/ISDN-based POTS/Multimedia 1231 device. 1233 For multipoint conferencing calls, it is assumed that only the 1234 centralized conferencing will be considered, and the media bridge 1235 is supposed to be located somewhere in the SIP network. However, 1236 it is considered that the ToIP and text telephony interworking 1237 function will be located in the IWF. 1239 The multipoint conference call flows will contain at least one 1240 ToIP/Multimedia, at least one text telephony/multimedia device, 1241 and other devices where total number of devices will be three or 1242 more for the following cases: 1244 Hellstr�m, Roy, van Wijk [Page 23 of 34] 1245 - ToIP/Multimedia and text telephony/multimedia devices that use 1246 the same/different language. 1247 - ToIP/Multimedia devices, telephony/multimedia devices, and/or 1248 PSTN/ISDN-based POTS/Multimedia devices.� 1250 9.8 Multi-functional gateways 1252 The scenarios described in this document deal with single pairs of 1253 interworking protocols or services. However, in practice many of 1254 these interworking systems will be implemented as gateways that 1255 combine different functions. As such, a text gateway could be 1256 build to have modems to interwork with the PSTN and support both 1257 Instant Messaging as well as real-time ToIP. Such interworking 1258 functions are called Combination gateways. 1260 Combination gateways MUST provide interworking between all of 1261 their supported text based functions. For example, a text gateway 1262 that has modems to interwork with the PSTN and that support both 1263 Instant Messaging and real-time ToIP MUST support the following 1264 interworking functions: 1266 - PSTN text telephony to real-time ToIP. 1267 - PSTN text telephony to Instant Messaging. 1268 - Instant Messaging to real-time ToIP. 1270 9.9 Gateway Discovery 1272 To get a smooth invocation of the text gateways, where those 1273 gateways are transparant on the IP side, it requires a method how 1274 and when to invoke the text gateway. As described previously in 1275 this draft. The text gateways must act as the end-terminal. The 1276 capabilities of the text gateway will in that call be determined 1277 by the call capabilities of the terminal that is using the 1278 gateway. For example, a PSTN textphone is only able to receive 1279 voice and streaming text. Thus the text gateway will only allow 1280 ToIP and, in case of VCO or HCO, audio. 1282 The PSTN devices or other non IP multimedia devices that require 1283 the text gateways to connect to the IP must be able to locate the 1284 text gateway. And ensure that the correct call capabilities of the 1285 non IP multimedia device is used by the text gateway. 1287 The following possible solutions for using the text gateway are: 1289 - PSTN Textphone users using a prefix before dialing out. 1290 - In band text dialogue. (???!!!) 1291 - separate text subscriptions, linked to the phone number or 1292 terminal identifier/ IP address. 1293 - text capability indicators. 1294 - text preference indicator. 1295 - listen for text activity in all calls. 1296 - call transfer request by the called user. 1298 Hellstr�m, Roy, van Wijk [Page 24 of 34] 1299 - placing a call via the web. 1300 - text gateways with its own telephone number and/or SIP address. 1301 (this requires user interaction with the text gateway to place a 1302 call). 1303 - ENUM. 1304 - etc 1306 9.10 Text Gateway in the call Scenarios 1308 9.10.1 IP terminal calling an analogue textphone (PSTN) 1310 The ToIP stream will be converted into an analogue text telephone 1311 protocol (using the voice channel) and vice versa by the text 1312 gateway. 1314 The PSTN knows it is a textphone call thanks to the SDP 1315 description (for example: m=text 11000 RTP/AVP 98 a=rtpmap:98 1316 t140/1000 for T.140 text on port 11000). 1318 The PSTN will also know that all those incoming calls are only for 1319 analogue textphones. Thus the speed of the text stream is adjusted 1320 to the selected analogue textphone protocol. 1321 If there is no analogue textphone on the called number, the call 1322 setup will be terminated by the text gateway. 1324 The text gateway can be implemented in 2 ways: The PSTN has its 1325 own text gateway (the IWF), or it redirects the media stream to 1326 the nearest IP-PSTN gateway with text transcoding abilities. 1328 Text gateway detection: In the SIP messages. 1330 9.10.2 IP terminal calling a mobile text telephone (CTM) 1332 The ToIP stream will be converted into CTM and vice versa by the 1333 text gateway located in the network of the cellular/mobile 1334 operator. It is similar to the PSTN. 1336 Text gateway detection: In the SIP messages. 1338 9.10.3 IP terminal calling a mobile telephone (GPRS based) 1340 A text gateway located in the mobile network converts the incoming 1341 T.140/RTP stream into for example T.140 over TCP (T.140/TCP) or 1342 tunnels the T.140 stream over HTTP (T.140/HTTP). Or any other 1343 temporarily non standard solution necessary to connect the text 1344 gateway with the text telephone client on the mobile phone. 1346 This is necessary, since RTP over GPRS is not possible (especially 1347 on GPRS phones with Symbian OS). 1348 Note, those server-client solutions are ONLY acceptable for the 1349 GPRS and non RTP stack phones. It is encouraged to use T.140/RTP 1350 as soon as possible for all mobile phones. 1352 Hellstr�m, Roy, van Wijk [Page 25 of 34] 1353 Allowing UDP transport over the GPRS link will enable RFC2793 text 1354 over GPRS. 1356 Text gateway detection: In the SIP messages. 1358 9.10.4 IP terminal calling a mobile telephone(UMTS) 1360 No text gateway is required here since this will be end to end IP. 1362 9.10.5 Analogue textphone (PSTN) user calling an IP terminal 1364 The PSTN is unable to distinguish between an analogue voice call 1365 and an analogue textphone, both use the voice channel. The text 1366 gateway needed to transcode the analogue textphone protocol into 1367 T.140/RTP needs to be invoked. 1369 The easiest way for a PSTN to separate an incoming voice call into 1370 text telephony or normal voice is by using a prefix number for all 1371 incoming text telephone calls to the PSTN. For example , the text 1372 telephone user (e.g Boudot) places a call and enters a prefix e.g. 1373 600 and then continues with the original number. The PSTN will 1374 recognize all incoming 600 calls as an analogue textphone call and 1375 redirects the call to a text gateway (unless it is a number 1376 connecting the same PSTN). 1378 It is undesirable to allow a PSTN to transport all the analogue 1379 textphone tones/signals through a VoIP stream! (In band text 1380 dialogue). 1382 Text gateway detection: Prefix number for incoming textphone 1383 calls. 1385 9.10.6 Mobile text telephone (CTM) user calling an IP terminal 1387 The voice channel of the cellular network is used. The MSC is able 1388 to separate between the text call and voice only, it is just a 1389 matter of redirecting the voice channel to the text gateway. 1391 Text gateway detection: CTM signal detection. 1393 9.10.7 Mobile telephone user (GPRS) calling an IP terminal 1395 The text telephone client on the mobile telephone connects the 1396 text gateway located in the network. The text gateway transcodes 1397 the text stream into ToIP. 1399 Text gateway detection: pre-programmed in the mobile textphone 1400 client. 1402 9.10.8 Mobile telephone (UMTS) user calling an IP terminal 1404 No text gateway is required here since this will be end to end IP. 1406 Hellstr�m, Roy, van Wijk [Page 26 of 34] 1407 9.10.9 Voice over DSL user using an analogue text telephone. 1409 In Europe, Voice over DSL is introduced. It is likely that 1410 analogue text telephones just use the voice channel. The VoDSL 1411 gateway located in the network of the (A)DSL operator itself 1412 should connect with a text gateway as soon it turns into VoIP. 1414 Text gateway detection: prefix number similar to the PSTN. 1416 9.10.10 VoIP user via a building telephone switch (at an apartment 1417 building) owning an analogue text telephone. 1419 This is the case where only VoIP is possible and no other IP 1420 traffic between the telephone switch and the apartments. The 1421 question is if this will be implemented. 1422 The only solution would be a forced analogue text telephone 1423 protocol over the Voice channel, in band text dialogue . If that 1424 must happen. Then the telephone switch MUST convert the analogue 1425 text telephone protocol into ToIP and vice versa before the 1426 telephone switch connects the IP network. 1427 Note: The in band text dialogue is undesirable. This scenario 1428 SHOULD be avoided at any cost. 1430 Text gateway detection: prefix number or in band text signalling. 1432 9.10.11 VoIP user via a gateway/box connected to his/her own 1433 Broadband connection owning an analogue text telephone. 1435 The gateway box should natively transcode analogue text telephony 1436 into ToIP and vice versa when an analogue text phone is plugged in 1437 the RJ-11 socket [18]. 1439 Text gateway detection: RJ-11 socket preconfigured by the box via 1440 jumpers or software. 1442 10. Terminal Features 1444 Implementers of products that support interactive Text-over-IP 1445 SHOULD NOT assume that all users of text are able to use 1446 mainstream input and output devices. People with arthritis or 1447 other dexterity problems might not be able to use very small 1448 keyboards. Visually impaired people might not be able to use 1449 standard sized characters on a display. Colour-blind people might 1450 suffer from badly chosen colour-schemes. People with motor 1451 disabilities might require specialised input devices. 1453 Implementers SHOULD try to make their products as open as possible 1454 with regard to this wide range of abilities and preferences and 1455 they MUST use standard interfaces wherever they provide such 1456 interfaces. 1458 Hellstr�m, Roy, van Wijk [Page 27 of 34] 1459 10.1 Text input 1461 Systems that support real-time interactive Text-over-IP SHOULD 1462 support suitable input mechanisms, either built-in or connectable 1463 through the use of a standard interface: PS/2, USB, Bluetooth, or 1464 virtual keyboard. In particular Braille users should be able to 1465 connect Braille keyboards to the terminal. Terminals MAY support a 1466 web interface for input and output of text. 1468 It is recommended that systems that fixed terminals that support 1469 real-time interactive Text-over-IP allow the user to enter the 1470 standard alphanumerical characters directly, rather than through a 1471 cycle of key presses or other indirect means. This could be done 1472 using full-sized keyboards, smaller sized keyboards or fastap 1473 keyboards for example. It is highly recommended to provide a 1474 standard interface to allow attachment of an external input 1475 device, especially for terminals that have only limited input 1476 systems built-in. 1478 All IP phones with a display of 12 or more characters MUST support 1479 at least text input through the regular phone keypad (and display 1480 of any incoming text) in order to provide basic emergency text 1481 communication from any IP phone. 1483 Input devices that have automatic key repeat MUST allow the user 1484 to specify the key-repeat rate. 1486 10.2 Text presentation 1488 Systems that support real-time interactive Text-over-IP SHOULD 1489 support suitable displays, either built-in or connectable through 1490 the use of a standard interface: S-VGA, USB, Bluetooth or IP. 1491 Braille readers should be connectable to the terminal using a 1492 standard interface. 1494 Terminals MAY support a web interface for input and output of 1495 text. 1497 While a variety of handsets and terminals might be developed for a 1498 number of equally varied scenarios, implementers MUST: 1500 In the case of fixed terminals or software applications on 1501 Personal Computers: 1503 a. Use either separate screen areas for displaying sent and 1504 received text OR clearly indicate the difference between sent and 1505 received text. Systems MAY allow the user to chose either on of 1506 these presentation methodologies. 1508 b. Provide at least 5 lines of 35 monospaced characters each for 1509 each direction (sent and received text) OR at least 10 lines of 35 1510 characters when sent and received text are presented together. 1512 Hellstr�m, Roy, van Wijk [Page 28 of 34] 1513 In the case of Mobile terminals: 1515 c. Use either separate screen areas for displaying sent and 1516 received text OR clearly indicate the difference between sent and 1517 received text. Systems MAY allow the user to chose either on of 1518 these presentation methodologies. 1520 d. Provide at least 3 lines of 20 monospaced characters each for 1521 each direction (sent and received text) OR at least 6 lines of 20 1522 characters when sent and received text are presented together. 1524 On both types of terminals, scrolling back through both sent and 1525 received text MUST be supported, including after the conversation 1526 has ended. Lines SHOULD be wrapped at word boundaries and this is 1527 strongly recommended. 1529 There MUST be an easy-to-use function to clear the screen at any 1530 time during the session, and if the implementation has chosen to 1531 present sent and received text separately, clearing the screen 1532 SHOULD be possible as a separate function for sent and received 1533 text. 1535 The function of the [CR], [LF] and [BACKSPACE] characters as 1536 explained in section 9.5. MUST be supported by the presentation. 1537 Presentation layers MUST support the full UTF-8 character set. 1539 When real-time Text-over-IP is used in conjunction with other 1540 modalities, like voice, the presentation MUST clearly indicate 1541 this to the user in an area outside the display region for send 1542 and received text. 1544 Identification information for other parties in the conversation, 1545 like URL�s, user-friendly names from an address book, or CLI in 1546 the case of conversations with text telephones, SHOULD be 1547 displayed throughout the entire conversation in a region outside 1548 the sent and received text area. 1550 10.3 Call control 1552 Call (Session) Control procedures MUST use the SIP protocol. Text 1553 sessions MUST be identified in accordance with requirements 1554 described earlier. 1556 Text services SHOULD be part of a Total Conversation environment 1557 in which voice, text and video sessions can be added, modified or 1558 deleted individually. 1560 To enable interworking with Textphones in telephone and cellular 1561 (mobile) networks, terminals MUST be able to access Gateways 1562 automatically when a PSTN or cellular (mobile) E.164-based 1563 telephone number is used as the called address. 1565 Hellstr�m, Roy, van Wijk [Page 29 of 34] 1566 Users MUST be able to establish text sessions to emergency service 1567 providers using the widely recognised emergency numbers in use in 1568 the country of operation of the terminal eg. �911� in USA. 1570 The ability to transfer Location information SHALL be provided if 1571 the information is available from the terminal. 1573 10.4 Device control 1575 ToIP will support the text protocol stack described earlier and 1576 will require the use of RFC 2793 [5]. RFC 2793 defines the use of 1577 ITU-T T.140 [4] over RTP. T.140 is a text presentation protocol 1578 that is also used in the ITU-T H.series multimedia systems 1579 including some videoconferencing systems. It is also used by ITU-T 1580 V.18 [10], the Textphone interworking specification, and by the 1581 GSM and 3GPP text conversation specifications. 1583 ToIP will be a full-duplex service. Small displays may require the 1584 users to indicate (via text indications at the user level) that a 1585 user wishes to communicate in the half-duplex mode. This will 1586 require a signal to inform the other user to proceed eg. �GA� as 1587 traditionally used by many half-duplex TTY users. 1589 10.5 Alerting 1591 The form of Alerting indication(s) provided to the user should be 1592 selectable to suit particular users. Alerting indications MAY 1593 include Sound, Tactile (eg. vibrational), Visual (on-screen 1594 symbols; separate flashing light), Motion (eg. movement of 1595 something). 1597 The ability to send an Alerting signal to an external interface 1598 SHOULD be provided. This will allow Alerting devices that are 1599 specific to users requirements to be attached. 1601 As many as possible of the following alternatives for alerting 1602 SHALL be provided: 1603 * Internal flash. 1604 * Two-pole connector for external alerting systems triggered 1605 by contact between the two poles when a ring signal is generated. 1606 * Bluetooth serial profile with AT command interface, sending 1607 the "RING" message, intended for a Bluetooth alerting receiver 1608 with flash, vibration or sound action. 1609 * SIP connected alerting device, that get its stimuli by being 1610 registered on the same sip address as the terminal. 1612 10.6 External interfaces 1614 Terminals for ToIP SHOULD provide external interfaces for the 1615 following functions: 1616 * Text input. 1617 * Text display. 1618 * Terminal control. 1620 Hellstr�m, Roy, van Wijk [Page 30 of 34] 1621 * Session control. 1623 10.7 Power 1625 As terminals could remain active for very long periods of time, 1626 the electrical power requirements of all the terminals SHOULD be 1627 as low as possible. 1629 If the terminal is to be used for calling Emergency services or 1630 where the mains power supply is unreliable, back-up power systems 1631 SHOULD be provided for the terminal and all equipment used to 1632 provide the ToIP service. This can be implemented in many 1633 different ways eg. via the line powering option on some Ethernet 1634 interfaces, or by using a �no break� power supply (a battery back- 1635 up system with inverters that can recreate a limited amount of 1636 mains power). 1638 11. Security Considerations 1640 There are no additional security requirements other than described 1641 earlier. 1643 12. Authors� Addresses 1645 The following people provided substantial technical and writing 1646 contributions to this document, listed alphabetically: 1648 Barry Dingle 1649 ACIF, 32 Walker Street 1650 North Sydney, NSW 2060 Australia 1651 Tel +61 (0)2 9959 9111 1652 Fax +61 (0)2 9954 6136 1653 TTY +61 (0)2 9923 1911 1654 Mob +61 (0)41 911 7578 1655 email barry.dingle@bigfoot.com.au 1657 Guido Gybels 1658 RNID, 19-23 Featherstone Street 1659 London EC1Y 8SL, UK 1660 Tel +44(0)20 7294 3713 1661 Txt +44(0)20 7296 8019 1662 Fax +44(0)20 7296 8069 1663 EMail: guido.gybels@rnid.org.uk 1664 Gunnar Hellstrom 1665 Omnitor AB 1666 Renathvagen 2 1667 SE 121 37 Johanneshov 1668 Sweden 1669 Phone: +46 708 204 288 / +46 8 556 002 03 1670 Fax: +46 8 556 002 06 1671 Email: gunnar.hellstrom@omnitor.se 1673 Paul E. Jones 1675 Hellstr�m, Roy, van Wijk [Page 31 of 34] 1676 Cisco Systems, Inc. 1677 7025 Kit Creek Rd. 1678 Research Triangle Park, NC 27709 1679 Phone: +1 919 392 6948 1680 E-mail: paulej@packetizer.com 1682 Radhika R. Roy 1683 AT&T 1684 Room C1-2B03 1685 200 Laurel Avenue S. 1686 Middletown, NJ 07748 1687 USA 1688 Phone: +1 732 420 1580 1689 Fax: +1 732 368 1302 1690 Email: rrroy@att.com 1692 Henry Sinnreich 1693 MCI 1694 400 International Parkway 1695 Richardson, Texas 75081 1696 Email: henry.sinnreich@mci.com 1698 Gregg C Vanderheiden 1699 University of Wisconsin-Madison 1700 Trace R & D Center 1701 1550 Engineering Dr (Rm 2107) 1702 Madison, Wi 53706 1703 USA 1704 gv@trace.wisc.edu 1705 Phone +1 608 262-6966 1706 FAX +1 608 262-8848 1708 Arnoud A. T. van Wijk 1709 Viataal (Dutch Institute for the Deaf) 1710 Research & Development 1711 Afdeling RDS 1712 Theerestraat 42 1713 5271 GD Sint-Michielsgestel 1714 The Netherlands. 1715 Email: a.vwijk@viataal.nl 1717 13. Full Copyright Statement 1719 Copyright (C) The Internet Society (1999, 2000). All Rights 1720 Reserved. This document and translations of it may be copied and 1721 furnished to others, and derivative works that comment on or 1722 otherwise explain it or assist in its implementation may be 1723 prepared, copied, published and distributed, in whole or in part, 1724 without restriction of any kind, provided that the above copyright 1725 notice and this paragraph are included on all such copies and 1726 derivative works. However, this document itself may not be 1727 modified in any way, such as by removing the copyright notice or 1728 references to the Internet Society or other Internet 1730 Hellstr�m, Roy, van Wijk [Page 32 of 34] 1731 organizations, except as needed for the purpose of developing 1732 Internet standards in which case the procedures for copyrights 1733 defined in the Internet Standards process must be followed, or as 1734 required to translate it into languages other than English. 1736 The limited permissions granted above are perpetual and will not 1737 be revoked by the Internet Society or its successors or assigns . 1738 This document and the information contained herein is provided on 1739 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1740 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1741 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1742 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1743 WARRANTIES OF MERCHANTABILITY OR FIT-NESS FOR A PARTICULAR 1744 PURPOSE." 1746 14. References 1748 14.1 Normative 1750 1. Bradner, S., "The Internet Standards Process -- Revision 3", 1751 BCP 9, RFC 2026, October 1996. 1752 2. Bradner, S., "Key words for use in RFCs to Indicate Requirement 1753 Levels", BCP 14, RFC 2119, March 1997 1754 3. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 1755 Peterson, R. Sparks, M. Handley, and E. Schooler, �SIP: Session 1756 Initiation Protocol,� RFC 3621, IETF, June 2002. 1757 4. ITU-T Recommendation T.140, �Protocol for Multimedia 1758 Application Text Conversation (February 1998) and Addendum 1 1759 (February 2000). 1760 5. G. Hellstr�m, �RTP Payload for Text Conversation, RFC 2793, May 1761 2000. 1762 6. G. Camarillo, H. Schulzrinne, and E. Burger, �The Source and 1763 Sink Attributes for the Session Description Protocol,� IETF, 1764 August 2003 - Work in Progress. 1765 7. G.Camarillo,�Framework for Transcoding with the Session 1766 Initiation Protocol� IETF august 2003 - Work in progress. 1767 8. G. Camarillo, H. Schulzrinne, E. Burger, and A. Wijk, 1768 �Transcoding Service Invocation in SIP using Third Party Call 1769 Control,� IETF, August 2003 - Work in Progress. 1770 9. G. Camarillo, �The SIP Conference Bridge Transcoding Model,� 1771 IETF, August 2003 - Work in Progress. 1772 10. ITU-T Recommendation V.18, �Operational and Interworking 1773 Requirements for DCEs operating in Text Telephone Mode,� November 1774 2000. 1775 11. "XHTML 1.0: The Extensible HyperText Markup Language: A 1776 Reformulation of HTML 4 in XML 1.0", W3C Recommendation. Available 1777 at http://www.w3.org/TR/xhtml1. 1778 12. Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1779 RFC 2279, January 1998. 1780 13. TIA/EIA/825 �A Frequency Shift Keyed Modem for Use on the 1781 Public Switched Telephone Network.� (The specification for 45.45 1782 and 50 bit/s TTY modems.) 1783 14. Bell-103 300 bit/s modem. 1785 Hellstr�m, Roy, van Wijk [Page 33 of 34] 1786 15. TIA/EIA/IS-823-A �TTY/TDD Extension to TIA/EIA-136-410 1787 Enhanced Full Rate Speech Codec (must used in conjunction with 1788 TIA/EIA/IS-840)� 1789 16. TIA/EIA/IS-127-2 �Enhanced Variable Rate Codec, Speech 1790 Service Option 3 for Wideband Spread Spectrum Digital Systems. 1791 Addendum 2.� 1792 17. 3GPP TS26.226 �Cellular Text Telephone Modem Description� 1793 (CTM). 1794 18. I. Butcher, S. Lass, D. Petrie, H. Sinnreich, and C. 1795 Stredicke, �SIP Telephony Device Requirements, Configuration and 1796 Data,� IETF, February 2004- Work in Progress. 1798 14.2 Informative 1800 I. A relay service allows the users to transcode between different 1801 modalities or languages. In the context of this document, relay 1802 services will often refer to text relays that transcode text into 1803 voice and vice-versa. See for example http://www.typetalk.org. 1804 II. International Telecommunication Union (ITU), �300 bits per 1805 second duplex modem standardized for use in the general switched 1806 telephone network�. ITU-T Recommendation V.21, November 1988. 1807 III. International Telecommunication Union (ITU), �600/1200-baud 1808 modem standardized for use in the general switched telephone 1809 network�. ITU-T Recommendation V.23, November 1988. 1810 IV. Third Generation Partnership Project (3GPP), �Technical 1811 Specification Group Services and System Aspects; Cellular Text 1812 Telephone Modem; General Description (Release 5)�. 3GPP TS 26.226 1813 V5.0.0, March 2001"SIP Telephony Device Requirements, 1814 Configuration and Data" by manyfolks,IETF, October 2003. 1816 Hellstr�m, Roy, van Wijk [Page 34 of 34]