idnits 2.17.1 draft-ietf-sipping-toip-00.txt: -(599): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(911): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1676): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1698): 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): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1868. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. == There are 6 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.) ** There are 640 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 1250 has weird spacing: '...rovides a bet...' == Line 1534 has weird spacing: '...necting analo...' == Line 1663 has weird spacing: '...ew line and e...' == 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: 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 300 milliseconds, -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- 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 18 looks like a reference -- Missing reference section? '2' on line 171 looks like a reference -- Missing reference section? '3' on line 955 looks like a reference -- Missing reference section? '4' on line 1337 looks like a reference -- Missing reference section? '5' on line 804 looks like a reference -- Missing reference section? 'I' on line 1249 looks like a reference -- Missing reference section? '6' on line 377 looks like a reference -- Missing reference section? '7' on line 882 looks like a reference -- Missing reference section? '8' on line 602 looks like a reference -- Missing reference section? '9' on line 602 looks like a reference -- Missing reference section? '10' on line 1338 looks like a reference -- Missing reference section? '12' on line 837 looks like a reference -- Missing reference section? '19' on line 956 looks like a reference -- Missing reference section? 'II' on line 1111 looks like a reference -- Missing reference section? 'III' on line 1111 looks like a reference -- Missing reference section? '15' on line 1169 looks like a reference -- Missing reference section? '16' on line 1169 looks like a reference -- Missing reference section? '17' on line 1177 looks like a reference -- Missing reference section? '20' on line 1233 looks like a reference -- Missing reference section? '18' on line 1563 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 9 warnings (==), 24 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force SIPPING WG 2 Internet Draft 3 Document: A. van Wijk (editor) 4 October 17 2004 Viataal 5 Expires: April 15 2005 6 Informational 8 Framework of requirements for real-time text conversation using SIP. 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026 [1]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 By submitting this Internet-Draft, I certify that any applicable 20 patent or other IPR claims of which I am aware have been 21 disclosed, or will be disclosed, and any of which I become aware 22 will be disclosed, in accordance with RFC 3668. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet-Drafts 27 as reference material or to cite them other than as "work in 28 progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document provides the framework of requirements for text 38 conversation with real time character-by-character interactive 39 flow over the IP network using the Session Initiation Protocol. 40 The requirements for general real-time text-over-IP telephony, 41 point-to point and conference calls, transcoding, relay services, 42 user mobility, interworking between text-over-IP telephony and 43 existing text-telephony, and some special features including 44 instant messaging have been described. 46 Table of Contents 48 1. Introduction 3 49 2. Scope 3 50 3. Terminology 4 52 A. van Wijk [Page 1 of 37] 53 4. Definitions 4 54 5. Background and General Requirements 5 55 6. Features in Real-time Text-over-IP 6 56 7. Real-Time Multimedia Conversational Sessions using SIP 7 57 8. General Requirements for Real-Time Text-over-IP using SIP 9 58 8.1 Pre-Call Requirements 9 59 8.2 Basic Point-to-Point Call Requirements 10 60 8.2.1 General Requirements 10 61 8.2.2 Session Setup 10 62 8.2.3 Addressing 11 63 8.2.4 Alerting 11 64 8.2.5 Call Negotiations 12 65 8.2.6 Answering 12 66 8.2.7 Session progress and status presentation 12 67 8.2.8 Actions During Calls 13 68 8.2.9 Additional session control 15 69 8.2.10 File storage 15 70 8.3 Conference Call Requirements 15 71 8.4 Transport 15 72 8.5 Character Set 16 73 8.6 Transcoding 16 74 8.7 Relay Services 17 75 8.8 Emergency services 18 76 8.9 User Mobility 18 77 8.10 Confidentiality and Security 18 78 8.11 Call Scenarios 18 79 8.11.1 Call Scenarios 19 80 8.11.2 Point-to-Point Call Scenarios 20 81 8.11.3 Conference Call Scenarios 20 82 9. Interworking Requirements for Text-over-IP 21 83 9.1 Real-Time Text-over-IP Interworking Gateway Services 21 84 9.2 Text-over-IP and PSTN/ISDN Text-Telephony 21 85 9.3 Text-over-IP and Cellular Wireless circuit switched Text- 86 Telephony 22 87 9.3.1 "No-gain" 22 88 9.3.2 Cellular Text Telephone Modem (CTM) 22 89 9.3.3 "Baudot mode" 23 90 9.3.4 Data channel mode 23 91 9.3.5 Common Text Gateway Functions 23 92 9.4 Text-over-IP and Cellular Wireless Text-over-IP 23 93 9.5 Instant Messaging Support 24 94 9.6 IP Telephony with Traditional RJ-11 Interfaces 25 95 9.7 Interworking Call Flows 25 96 9.8 Multi-functional gateways 26 97 9.9 Gateway Discovery 26 98 9.10 Text Gateway in the call Scenarios 27 99 9.10.1 IP terminal calling an analogue textphone (PSTN) 27 100 9.10.2 IP terminal calling a mobile text telephone (CTM) 28 101 9.10.3 IP terminal calling a mobile telephone (GPRS based) 28 102 9.10.4 IP terminal calling a mobile telephone(UMTS) 28 103 9.10.5 Analogue textphone (PSTN) user calling an IP terminal using 104 prefix 28 106 A. van Wijk [Page 2 of 37] 107 9.10.6 Mobile text telephone (CTM) user calling an IP terminal 108 29 109 9.10.7 Mobile telephone user (GPRS) calling an IP terminal 29 110 9.10.8 Mobile telephone (UMTS) user calling an IP terminal 29 111 9.10.9 Voice over DSL user using an analogue text telephone. 29 112 9.10.10 VoIP user via a building telephone switch (at an apartment 113 building) owning an analogue text telephone. 29 114 9.10.11 VoIP user via a gateway/box connected to his/her own 115 Broadband connection owning an analogue text telephone. 29 116 10. Terminal Features 30 117 10.1 Text input 30 118 10.2 Text presentation 31 119 10.3 Call control 32 120 10.4 Device control 32 121 10.5 Alerting 32 122 10.6 External interfaces 33 123 10.7 Power 33 124 11. Security Considerations 33 125 12. Outstanding issues 33 126 13. Authors Addresses 34 127 14. Acknowledgements 35 128 15. Full Copyright Statement 35 129 16. References 35 130 16.1 Normative 35 131 16.2 Informative 37 133 1. Introduction 135 Text-over-IP (ToIP) is becoming popular as a part of total 136 conversation among a range of users although this medium of 137 communications may be the most convenient to certain categories of 138 people (e.g., deaf, hard of hearing and speech-impaired 139 individuals). The Session Initiation Protocol (SIP) has become the 140 protocol of choice for control of Multimedia IP telephony and 141 Voice-over-IP (VoIP) communications. Naturally, it has become 142 essential to define the requirements for how ToIP can be used with 143 SIP to allow text conversations as an equivalent to voice. This 144 document defines the framework of requirements for using ToIP, 145 either by itself or as a part of total conversation using SIP for 146 session control. 148 2. Scope 150 The primary scope of this document is to define the requirements 151 for using ToIP with SIP, either stand-alone or as a part of a 152 total conversation approach. In general, the scope of the 153 requirements is: 155 a. Features in Real-Time ToIP 156 b. Real-time Multimedia Conversational Sessions using SIP 157 c. General Requirements for Real-Time ToIP using SIP 158 d. Interworking Requirements for ToIP 160 A. van Wijk [Page 3 of 37] 161 e. Text gateways to interconnect the different networks 163 The subsequent sections describe those requirements in detail. 165 3. Terminology 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 168 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 169 in this document are to be interpreted as described in RFC 2119 170 [2]. 172 4. Definitions 174 Audio bridging - a function of a gateway or relay service that 175 enables an audio path through the service between the users 176 involved in the call. 178 Full duplex - user information is sent independently in both 179 directions. 181 Half duplex - user information can only be sent in one direction 182 at a time or, if an attempt to send information in both directions 183 is made, errors can be introduced into the user information. 185 Interactive text - a term for real time transmission of text in a 186 character-by-character fashion for use in conversational services. 188 TTY - name for text telephone, often used in USA, see textphone. 189 Also called TDD, Telecommunication Device for the Deaf. 191 Textphone - text telephone. A terminal device that allow end-to- 192 end real time text communication. A variety of textphone protocols 193 exists world-wide, both in the PSTN and other networks. A 194 textphone can often be combined with a voice telephone, or include 195 voice communication functions for simultaneous or alternating use 196 of text and voice in a call. 198 Text bridging - a function of a gateway or relay service that 199 enables the flow of text through the service between the users 200 involved in the call. 202 Text gateway - a multi functional gateway that is able to 203 transcode between different forms of text transport methods. E.g. 204 Between ToIP in IP networks and Baudot text telephony in the PSTN. 206 Text telephony - Analog textphone services 208 Text Relay Service - A third-party or intermediary that enables 209 communications between deaf, hard of hearing and speech-impaired 210 people, and voice telephone users by translating between voice and 211 text in a call. 213 A. van Wijk [Page 4 of 37] 214 Transcoding Services - Services of a third-party user agent 215 (human or automated) that transcodes one stream into another. 217 Total Conversation - A multimedia service offering real time 218 conversation in video, text and voice according to interoperable 219 standards. All media flow in real time. Further defined in ITU-T 220 F.703 Multimedia conversational services description. 222 Video Relay Service - A service that enables communications 223 between deaf and hard of hearing people with total conversation 224 devices, and hearing persons with voice telephones by translating 225 between sign language and spoken language in a call. 227 Acronyms: 229 2G Second generation cellular (mobile) 230 2.5G Enhanced second generation cellular (mobile) 231 3G Third generation cellular (mobile) 232 CDMA Code Division Multiple Access 233 CTM Cellular Text Telephone Modem 234 GSM Global System of Mobile Communication 235 ISDN Integrated Services Digital Network 236 ITU-T International Telecommunications Union-Telecommunications 237 standardisation Sector 238 PSTN Public Switched Telephone Network 239 SIP Session Initiation Protocol 240 TDD Telecommunication Device for the Deaf 241 TDMA Time Division Multiple Access 242 ToIP Text over Internet Protocol 243 UTF-8 Universal Transfer Format-8 245 5. Background and General Requirements 247 The main purpose of this document is to provide a set of 248 requirements for real-time text conversation over the IP network 249 using the Session Initiation Protocol (SIP) [3]. The overall 250 requirement is that real-time text conversation can be part of a 251 conversational service like any other media. Participants can 252 negotiate all media including real-time text conversation[4, 5]. 253 This is a highly desirable function for all IP telephony users, 254 and essential for deaf, hard of hearing, or speech impaired people 255 who have limited or no use of the audio path of the call. 257 It is important to understand that real-time text conversations 258 are significantly different from other text based communications 259 like email or instant messaging. Real-time text conversations 260 deliver an equivalent mode to voice conversations by providing 261 transmission of text character by character as it is entered, so 262 that the conversation can be followed closely and immediate 263 interaction take place, therefore providing the same mode of 264 interaction as voice telephony does. Store-and-forward systems 265 like email or messaging on mobile networks or non-streaming 267 A. van Wijk [Page 5 of 37] 268 systems like instant messaging are unable to provide that 269 functionality. 271 One particular application where real-time text is absolutely 272 essential, is the use of relay services between conversational 273 modes, like between text and voice. 275 Direct text emergency service calls, where time and continuous 276 connection are of the essence, is another essential application. 278 6. Features in Real-time Text-over-IP 280 While real-time Text-over-IP will be used for a wide variety of 281 services, an important field of application will be to provide a 282 text equivalent to voice conversation, in particular for deaf, 283 hard of hearing and speech-impaired users. 284 As such, it is crucial that the conversational nature of this 285 service is maintained. Text based communications exist in a 286 variety of forms, some non-conversational (SMS, text paging, E- 287 mail, newsgroups, message boards, etc.), others conversational 288 (TTY/TDD, Textphone, etc). 290 Real-time Text-over-IP will sometimes be used in conjunction with 291 a relay service [I] to allow text users to communicate with voice 292 users. With relay services, it is crucial that text characters are 293 sent as soon as possible after they are entered. While buffering 294 MAY be done to improve efficiency, the delays SHOULD be kept as 295 small as possible. In particular, buffering of whole lines of text 296 MUST NOT be used. 298 In order to make Real-Time Text-over-IP the equivalent of what 299 voice is to hearing people, it needs to offer equivalent features 300 in terms of conversation as voice communications provides to 301 hearing people. To achieve that, real-time Text-over-IP MUST: 303 a. Offer Real-Time presentation of the conversation. This means 304 that text MUST be sent as soon as available, or with very small 305 delays. The delay MUST not be longer than 300 milliseconds, 307 b. Provide simultaneous transmission in both directions, 309 c. Provide interoperability with text conversation features in 310 other networks, e.g. PSTN, accepting functional limitations that 311 this will lead to during interoperation. 313 d. Support a transmission rate of at least 30 characters/second. 315 e. Support suitable reliability of text transmission. A character 316 error rate of 0.2% is regarded good, and 1% usable. 318 f. Be possible to merge with video and voice transmission. 320 A. van Wijk [Page 6 of 37] 321 g. The end-to-end delay in transmission MUST be less than 2000 322 milliseconds. 324 Many users will want to use multiple modes of communication during 325 the conversation, either at the same time or by switching between 326 modes e.g. between real-time Text-over-IP and voice. Native real- 327 time Text-over-IP systems MUST support simultaneous use of 328 modalities so that the text interface is always available. 330 When communicating via a gateway to other networks and protocols, 331 the system MUST completely support the functionality for 332 alternating or simultaneous modalities as offered by the gateway. 334 When voice is supported on the terminal, the terminal MUST provide 335 volume control. 337 7. Real-Time Multimedia Conversational Sessions using SIP 339 The Session Initiation Protocol (SIP) [3] provides mechanisms for 340 creating, modifying, and terminating sessions for real-time 341 conversation with one or more participants using any combination 342 of media: Text, Video and Audio. However, participants are allowed 343 to negotiate on a set of compatible media types (e.g., Text, 344 Video, Audio) with session descriptions used in SIP invitations. 346 The standardized T.140 real-time text conversation [4], in 347 addition to audio and video communications, will be a valuable 348 service to many. Real-time text can be expressed as a part of the 349 session description in SIP and is a useful subset of the Total 350 Conversation (which is Real-time text, Video and Audio 351 simultaneously). 353 This specification describes the framework for using the T.140 354 text conversation in SIP as a part of the multimedia session 355 establishment in real-time over a SIP network. 357 The session establishment using SIP defines procedures for how 358 T.140 text conversation can be supported using the text/t140 RTP 359 payload defined in RFC 2793 [5]. The performance characteristics 360 of T.140 will be determined using RTCP. 362 The session will not only define procedures between the SIP 363 devices having text conversation capability, but will also define 364 how sessions in SIP can be established between the text 365 conversation and audio/video/text capable devices transparently. 367 If there is any incompatibility between the terminals, e.g. T.140 368 only and audio-only terminals, the necessary transcoding services 369 will need to be invoked. This important service feature offers a 370 variety of rich capabilities in the transcoding server. For 371 example, speech-to-text (STT), text-to-speech (TTS), text bridging 372 after conversion from speech, audio bridging after conversion from 373 text, and other services can also be provided by the transcoding 375 A. van Wijk [Page 7 of 37] 376 and/or translation server. The session description protocol (SDP) 377 [6] used in SIP to describe the session also needs to be capable 378 of expressing these attributes of the session (e.g., uniqueness in 379 media mapping for conversion from one media to another for each 380 communicating party). 382 Real-time text can also be presented in conjunction with video and 383 audio. Making real-time text part of total conversation. 385 Visual and/or Tactile alerting for T.140 capable terminals should 386 to be provided. 388 Users may set up text conversation sessions using SIP from any 389 location. In addition, user privacy and security MUST be provided 390 for text conversation sessions at least equal to that for voice. 392 The transcoding/translation services can be invoked in SIP using 393 different session establishment models [7]: Third party call 394 control [8] and Conference Bridge model [9]. 396 Both point-to-point and multipoint communication need to be 397 defined for the session establishment using T.140 text 398 conversation. In addition, the interworking between T.140 text 399 conversation and text telephony conversation [10] is needed. 401 The general requirements for real-time text conversation using SIP 402 can be described as follows: 404 a. Session setup, modification and teardown procedures for point- 405 to-point and multimedia calls 407 b. Registration procedures and address resolutions 409 c. Registration of user preferences 411 d. Negotiation procedures for device capabilities 413 e. Discovery and invocation of transcoding/translation services 414 between the media in the call 416 f. Different session establishment models for 417 transcoding/translation services invocation: Third party call 418 control and Conference bridge model 420 g. Uniqueness in media mapping to be used in the session for 421 conversion from one media to another by the 422 transcoding/translation server for each communicating party 424 h. Media bridging services for T.140 real-time text, audio, and 425 video for multipoint communications 427 i. Transparent session setup, modification, and teardown between 428 text conversation capable and voice/video capable devices 430 A. van Wijk [Page 8 of 37] 431 j. Conversations to be carried out using T.140-over-RTP and RTCP 432 will provide performance report for T.140 434 k. Altering capability using text conversation during the session 435 establishment 437 l. T.140 real-time text presentation mixing with voice and video 439 m. T.140 real-time text conversation sessions using SIP, allowing 440 users to move from one place to another 442 n. User privacy and security for sessions setup, modification, and 443 teardown as well as for media transfer 445 o. Interoperability between T.140 conversations and analogue text 446 telephones 448 p. Routing of emergency calls according to national or regional 449 policy to the same level of a voice call. 451 8. General Requirements for Real-Time Text-over-IP using SIP 453 The communications environments for ToIP using SIP to set up the 454 conversation in real-time may vary from a simple point-to-point 455 call to multipoint calls in addition to the fact that ToIP can be 456 used in combination with other media like audio and video. In 457 order to establish the session in real-time, the communicating 458 parties SHOULD be provided with experiences like those of normal 459 telephony call setup. There may also be some need for pre-call 460 setup e.g. storing registration information in the SIP registrar 461 to provide information about how a user can be contacted. This 462 will allow calls to be set up rapidly and with proper addressing. 464 Similarly, there are requirements that need to be satisfied during 465 call set up when another media is preferred by a user. For 466 instance, some users may prefer to use audio while others want to 467 use text as their preferred choice of conversational mode. In this 468 case, transcoding services will need to be invoked for text-to- 469 speech (TTS) and speech-to-text (STT). The requirements for 470 transcoding services need to be negotiated in real-time to set up 471 the session. 473 The subsequent subsections describe those requirements in great 474 detail. 476 8.1 Pre-Call Requirements 478 The desire of the users for using ToIP as a medium of 479 communications can be expressed during registration time. Two 480 situations need to be considered in the pre-call setup 481 environment: 483 A. van Wijk [Page 9 of 37] 484 a. User Preferences: It MUST be possible for a user to indicate a 485 preference for ToIP by registering that preference in a SIP 486 server. If the user is called by other party, preferences can be 487 invoked by the SIP server to accept or reject the call based on 488 the rules defined by the user. If the rules require that a 489 transcoding server is needed, the call can be re-directed or 490 handled accordingly. 492 b. Server to support User Preferences: SIP servers MUST have the 493 capability to act on users preferences for ToIP, based on the user 494 preferences defined during the pre-call setup registration time. 496 8.2 Basic Point-to-Point Call Requirements 498 The point-to-point call will take place between two parties. The 499 requirements are described in subsequent sub-sections. They assume 500 that one or both of the communicating parties will indicate ToIP 501 as a possible or preferred medium for conversation using SIP in 502 the session setup. 504 8.2.1 General Requirements 506 The general requirements are that ToIP will be chosen from the 507 available media as the preferred means of communication for the 508 session. However, there may be a need to invoke some underlying 509 capabilities in some cases, for example, a transcoding server may 510 be invoked if one of the users want to use a communication medium 511 other than ToIP. 512 The following features MAY need to be involved to facilitate the 513 session establishment using ToIP as another medium: 515 a. Caller Preferences: SIP headers (e.g., Contact) can be used to 516 show that ToIP is the medium of choice for communications. 518 b. Called Party Preferences: The called party being passive can 519 formulate a clear rule indicating how a call should be handled 520 either using ToIP as a preferred medium or not, and whether a 521 designated SIP proxy needs to handle this call or it is handled in 522 the SIP user agent (UA). 524 c. SIP Server support for User Preferences: SIP servers can also 525 handle the incoming calls in accordance to preferences expressed 526 for ToIP. The SIP Server can also enforce ToIP policy rules for 527 communications (e.g., use of the transcoding server for ToIP). 529 8.2.2 Session Setup 531 Users will set up a session by identifying the remote party or the 532 service they will want to connect to. However, conversations could 533 be started using a mode other than real-time Text-over-IP. For 534 instance, the conversation might be established using voice and 535 the user could elect to switch to text, or add text, during the 536 conversation. Systems supporting real-time Text-over-IP MUST allow 538 A. van Wijk [Page 10 of 37] 539 users to select any of the supported conversation modes at any 540 time, including mid-conversation. 542 Systems SHOULD allow the user to specify a preferred mode of 543 communication, with the ability to fall back to alternatives that 544 the user has indicated are acceptable. 546 If the user requests simultaneous use of text and voice, and this 547 is not possible either because the system only supports alternate 548 modalities or because of resource management on the network, the 549 system MUST try to establish a text-only communication. and the 550 user MUST be informed of this change throughout the process, 551 either in text or in a combination of modalities that MUST include 552 text. 554 Session setup, especially through gateways to other networks, MAY 555 require the use of specially formatted addresses or other 556 mechanisms for invoking gateways. 557 Such mechanisms MUST be supported by the terminal. 559 8.2.3 Addressing 561 The SIP [3] addressing schemes MUST be used for all entities. For 562 example SIP URL and Tel URL will be used for caller, called party, 563 user devices, and servers (e.g., SIP server, Transcoding server). 565 The right to include a transcoding service MUST NOT require user 566 registration in any specific SIP registrar, but MAY require 567 authorisation of the SIP registrar in the service. 569 8.2.4 Alerting 571 Systems supporting real-time Text-over-IP MUST have an alerting 572 method (e.g., for incoming calls) that can be used by deaf and 573 hard of hearing people or provide a range of alternative, but 574 equivalent, alerting methods that are suitable for all users, 575 regardless of their abilities and preferences. 577 It should be noted that general alerting systems exist, and one 578 common interface for triggering the alerting action is a contact 579 closure between two conductors. 581 Among the alerting options are alerting on the user equipment and 582 specific alerting user agents registered to the same registrar as 583 the main user agent. 585 If present, identification of the originating party (for example 586 in the form of a URL or CLI) MUST be clearly presented to the user 587 in a form suitable for the user BEFORE answering the request. When 588 the invitation to initiate a conversation involving real-time 589 Text-over-IP originates from a gateway, this MAY be signalled to 590 the user. 592 A. van Wijk [Page 11 of 37] 593 8.2.5 Call Negotiations 595 The Session Description Protocol (SDP) used in SIP [3] provides 596 the capabilities to indicate ToIP as a media in the call setup. 597 RFC 2793 [5] provides the RTP payload type text/t140 for support 598 of ToIP which can be indicated in the SDP as a part of SDP INVITE, 599 OK and SIP/200/ACK for media negotiations. In addition, SIP�s 600 offer/answer model can also be used in conjunction with other 601 capabilities including the use of a transcoding server for 602 enhanced call negotiations [7,8,9]. 604 8.2.6 Answering 606 Systems SHOULD provide a best-effort approach to answering 607 invitations for session set-up and users should be kept informed 608 at all times about the progress of session establishment. On all 609 systems that both inform users of session status and support real- 610 time Text-over-IP, this information MUST be available in text, and 611 may be provided in other visual media. 613 8.2.6.1 Answering Machine 615 Systems for real-time Text-over-IP MAY support an auto-answer 616 function, equivalent to answering machines on telephony networks. 617 If an answering machine function is supported, it MUST support at 618 least 160 characters for the greeting message. It MUST support 619 incoming text message storage of a minimum of 16000 characters, 620 although systems MAY support much larger storage. 622 When the answering machine is activated, user alerting MUST still 623 take place. The user MUST be allowed to monitor the auto-answer 624 progress and MUST be allowed to intervene during any stage of the 625 answering machine and take control of the session. 627 8.2.7 Session progress and status presentation 629 During a conversation that includes real-time Text-over-IP, status 630 and session progress information MUST be provided in text. That 631 information MUST be equivalent to session progress information 632 delivered in any other format, for example audio. Users MUST be 633 able to manage the session and perform all session control 634 functions based on the textual session progress information. 636 The user MUST be informed of any change in modalities. 638 Session progress information MUST use simple language as much as 639 possible so that it can be understood by as many users as 640 possible. 641 The use of jargon or ambiguous terminology SHOULD be avoided at 642 all times. It is RECOMMENDED to let text information be used 643 together with icons symbolising the items to be reported. 645 A. van Wijk [Page 12 of 37] 646 There MUST be a clear indication, both visually as well as audibly 647 whenever a session gets connected and disconnected. The user 648 should never be in doubt as to what the status of the connection 649 is, even if he/she is not able to use audio feedback or vision. 651 8.2.8 Actions During Calls 653 Certain actions need to be performed for the ToIP conversation 654 during the call and these actions are describe briefly as follows: 656 a. Text transmission SHALL be done character by character as 657 entered, or in small groups transmitted so that no character is 658 delayed between entry and transmission by more than 300 659 milliseconds. 660 b. The text transmission SHALL allow a rate of at least 30 661 characters per second so that human typing speed as well as speech 662 to text methods of generating conversation text can be supported. 664 c. After text connection is established, the mean end-to-end delay 665 of characters SHALL be less than two seconds, measured between two 666 ToIP users. This requirement is valid as long as the text input 667 rate is lower or equal to the text reception and display rate. 669 d. The character corruption rate SHALL be less than 1% in 670 conditions where users experience the quality of voice 671 transmission to be low but useable. This is in accordance with 672 ITU-T F.700 Annex A.3 quality level T1. 674 e. When interoperability functions are invoked, there may be a 675 need for intermediate storage of characters before transmission to 676 a device receiving slower than the typing speed of the sender. 677 Such temporary storage SHALL be dimensioned to adjust for 678 receiving at 30 characters per second and transmitting at 6 679 characters per second during at least 4 minutes [less than 3k 680 characters]. 682 f. If text is detected to be missing after transmission, there 683 SHALL be an indication in the text marking the loss. 685 g. When used from a terminal designed for PSTN text telephony, or 686 in interworking with such a terminal, ToIP shall enable 687 alternating between text and voice in a similar manner as the PSTN 688 text telephone handles this mode of operation. (This mode is often 689 called VCO/HCO in USA). 691 h. The transmission of the text conversation SHALL be made 692 according to an internationally suitable character set and control 693 protocol for text conversation as specified in ITU-T T.140. 695 i. When display of the conversation on end user equipment is 696 included in the design, display of the dialogue SHALL be made so 697 that it is easy to read text belonging to each party in the 698 conversation. 700 A. van Wijk [Page 13 of 37] 701 8.2.8.1 Text and other Media Handling Between ToIP Devices 703 The ToIP devices do not need transcoding from speech to text and 704 can communicate directly using text/t140. The following 705 requirements are valid for media handling during calls: 707 a. When used between terminals designed for ToIP, it SHALL be 708 possible to send and receive text simultaneously with the other 709 media (text, audio and/or video) supported by the same terminals. 711 b. When used between terminals designed for ToIP, it SHALL be 712 possible to send and receive text simultaneously. 714 c. It should be possible to know during the call that ToIP is 715 available, even if it is not invoked at call setup (only voice 716 and/or video is used). To disable this, the user must disable the 717 use of ToIP. 719 8.2.8.2 General Actions 721 a. It SHALL be possible to establish a session with text 722 capabilities enabled at the beginning of a Call. Note: a call is 723 in this document defined as one or more sessions). 725 b. It SHALL be possible to place a call without text capabilities, 726 and to add text capabilities later in the call. 728 c. It SHALL be possible to transfer text at at least 30 characters 729 per second 731 d. It SHALL be possible to talk and listen simultaneously with 732 typing and reading. 734 8.2.8.3 Call Action with Native ToIP Devices 736 a. It SHOULD be possible to answer a call with text capabilities 737 enabled. 739 b. It SHOULD be possible to use video simultaneously with the 740 other media in the call. 742 c. It SHOULD be possible to answer a call in voice or video 743 without text enabled, and add text later in the call. 745 d. It MUST be possible to disconnect the call. 747 e. It SHOULD be possible to control IVR (Interactive Voice 748 Response) services from a numeric keypad. 750 f. It SHOULD be possible to control ITR ( Interactive Text 751 Response) services from the alphanumeric keyboard. 753 A. van Wijk [Page 14 of 37] 754 g. It SHOULD be possible to invoke multi-party calls. 756 h. It SHALL be possible to transfer the call. 758 i. It MUST be possible to use text characters (numbers) instead of 759 DTMF tones (numbers) in interactions where the person is using a 760 keyboard to interact with a service and the service asks for a 761 number. 763 8.2.8.4 Audio/Visual/Tactile Indicators 765 It SHOULD be possible to observe visual or tactile indicators 766 about: 767 - Call progress 768 - Availability of text, voice and video channels. 769 - Incoming call. 770 - Incoming text. 771 - Typed and transmitted text. 772 - Any loss in incoming text. 774 8.2.9 Additional session control 776 Systems that support additional session control features, for 777 example call waiting, forwarding, hold etc on voice calls, MUST 778 offer equivalent functionality for real-time Text-over-IP 779 functions. In addition, all these features MUST be controllable by 780 text users at any time, in an equivalent way as for other users. 782 8.2.10 File storage 784 Systems that support real-time Text-over-IP MAY save the text 785 conversation to a file. This SHOULD be done using a standard file 786 format. 788 8.3 Conference Call Requirements 790 The conference call requirements deal with multipoint conferencing 791 calls where there will be at least one or more ToIP capable 792 devices along with other end user devices where the total number 793 end user devices will be at least three. 795 It SHOULD be possible to use the text medium in conference calls, 796 in a similar way as video is handled and displayed. Text in 797 conferences can be used both for letting individual participants 798 use the text medium, and for central support of the conference 799 with real time text interpretation of speech. 801 8.4 Transport 803 ToIP uses RTP as the default transport protocol for transmission 804 of real-time text medium text/t140 as specified in RFC 2793 [5]. 805 Signaling and other media will use the transport protocol 807 A. van Wijk [Page 15 of 37] 808 specified in SIP [3] and/or their revised versions as specified in 809 standards. 811 The redundancy method of RFC 2198 SHOULD be used for making text 812 transmission reliable with transmission of three generations. 814 Text capability SHOULD be announced in SDP by a declaration in 815 line with this example: 817 m=text 11000 RTP/AVP 98 100 818 a=rtpmap:98 t140/1000 819 a=rtpmap:100 red/1000 820 a=fmtp:100 98/98/98 822 Characters SHOULD BE buffered for transmission and transmitted 823 every 300 ms. 825 By having this single coding and transmission scheme for real time 826 text defined, in the SIP call control environment, the opportunity 827 for interoperability is optimized. 829 However, if good reasons exist, other transport mechanisms MAY be 830 offered and used for the T.140 coded text, provided that proper 831 negotiation is introduced, and RFC 2793 transport MUST be used as 832 the defaut fallback solution. 834 8.5 Character Set 836 a. Real-Time Text-over-IP protocols MUST use UTF-8 encoding as 837 specified in ITU-T T.140 [12]. 839 b. Real-time Text-over-IP SHOULD handle characers with editing 840 effect such as new line, erasure and alerting during session as 841 specified in ITU-T T.140. 843 8.6 Transcoding 845 Transcoding of text may need to take place in gateways between 846 ToIP and other forms of text conversation. ToIP makes use of 847 ISO 10646 character set. 848 Most PSTN textphones use a 7-bit character set, or a character set 849 that is converted to a 7-bit character set by the V.18 modem. 851 When transcoding between these character sets and T.140 in 852 gateways, special consideration MUST be paid to the national 853 variants of the 7 bit codes, with national characters mapping into 854 different codes in the ISO 10 646 code space. The national variant 855 to be used SHOULD be possible to select by the user per call, or 856 be configured as a national default for the gateway. 858 The missing text indicator in T.140, specified in T.140 amendment 859 1, cannot be represented in the 7 bit character codes. Therefore 861 A. van Wijk [Page 16 of 37] 862 these characters SHOULD be translated to be represented by the ' 863 (apostrophe) character in legacy text telephone systems where this 864 character exists. For legacy systems where the character ' does 865 not exist, the character . ( full stop ) SHOULD be used instead. 867 8.7 Relay Services 869 The relay service acts as an intermediary between 2 or more 870 callers. 871 The basic relay service allows a translation of speech to text and 872 text to speech, which enables hearing and speech impaired callers 873 to communicate with hearing callers. Even though this document 874 focuses on ToIP, we do not exclude video relay services for e.g., 875 speech to sign language and vice versa and other possible relay 876 services. It will be possible to use ToIP simultaneously with 877 other relay services if desired. 879 It is very important for the users that a relay session is invoked 880 as transparently as possible. It SHOULD happen automatically when 881 the call is being set-up or by a simple user action. A transcoding 882 framework document using SIP [7] describes invoking relay 883 services, where the relay acts as a conference bridge or uses the 884 third party control mechanism. 886 Adding or removing a relay service MUST be possible without 887 disrupting the current call. 889 When setting up a call, the relay service MUST be able to 890 determine the type of service requested (e.g. speech to text or 891 text to speech), to indicate if the caller wants voice carry over, 892 the language of the text including the sign language being used. 894 The user MUST be provided with a method to indicate which service 895 is desired. 897 Relay services MUST be reachable all the time, even if the users 898 are visiting networks from different operators. 900 It SHOULD be possible to route the call to a preferred relay 901 service even if the user makes the call from another region or 902 network than usually used. 904 It MUST be possible to identify ToIP sessions as emergency 905 sessions. 907 If it is decided that a relay service supports emergency calls, 908 the relay service operator MUST be able to process such a session 909 correctly and quickly with the following functionality: 911 a. The relay service operator�s network MUST give priority to this 912 incoming call. 914 A. van Wijk [Page 17 of 37] 915 b. The relay service operator MUST forward this session if they 916 are unable to process it to an alternative emergency relay 917 operator. 919 c. The relay service MUST label the transcoded stream as an 920 emergency call (in case of text to speech and/or vice versa). 922 d. The relay service MUST provide all session information to the 923 emergency centre (e.g., location information of the caller if 924 available). 926 8.8 Emergency services 928 a. It MUST be possible to support emergency service calls with 929 text only or simultaneously with voice. 931 b. All session information that accompanies a voice session to the 932 emergency centre, MUST also be provided to the emergency center if 933 it is a ToIP session.(e.g, phone number and location information 934 of the user placing the emergency call). 936 c. A text over IP stream MUST be labelled as an emergency stream 937 to ensure that the emergency service center is able to receive 938 this call. 940 8.9 User Mobility 942 ToIP terminals SHOULD use the same mechanisms as other terminals 943 to resolve mobility issues. It is RECOMMENDED to use a SIP-adress 944 for the users, resolved by a SIP REGISTRAR, to enable basic user 945 mobility. Further mechanisms are defined for the 3G IP multimedia 946 systems. 948 8.10 Confidentiality and Security 950 User confidentiality and privacy need to be met as described in 951 SIP [3]. For example, nothing should reveal the fact that the user 952 of ToIP is a person with a disability unless the user prefers to 953 make this information public. If a transcoding server is being 954 used, this SHOULD be transparent. Encryption SHOULD be used on 955 end-to-end or hop-by-hop basis as described in SIP [3] and SRTP 956 [19] 958 Authentication needs to be provided for users in addition to the 959 message integrity and access control. 961 Protection against Denial-of-service (DoS) attacks needs to be 962 provided considering the case that the ToIP users might need 963 transcoding servers. 965 8.11 Call Scenarios 967 A. van Wijk [Page 18 of 37] 968 ToIP is a way of establishing the real-time conversation. Call 969 flow for ToIP MUST be similar to session 970 establishment with audio and video. For example, ToIP services MAY 971 be invoked in the following situations (among others): 973 - Noisy environment (e.g., in a machine room of a factory where 974 listening is difficult)Busy with another call and want to 975 participate in two calls at the same time. 977 - Text and/or speech recording services (e.g., text 978 documentation/audio recording for legal/clarity/flexibility 979 purposes) 980 - Overcoming of language barriers through speech translation 981 and/or transcoding services 983 - Not hearing well or not at all (e.g., hearing loss due to aging, 984 hard of hearing, deaf) 986 NOTE: In many of the above scenarios, text may accompany speech in 987 a subtitling like fashion. This would occur for individuals who 988 are hard of hearing and also for mixed calls with a hearing and 989 deaf person listening to the call. 991 All call flows either for the point-to-point or for the multipoint 992 situation need to consider that ToIP services may be invoked for 993 many different reasons by users as explained. When the 994 transcoding/translation services are needed, call flows will be 995 shown for both session establishment models: Third-party call 996 control model and Conferencing bridge model. 998 8.11.1 Call Scenarios 1000 There are 2 different terminal types possible: 1002 1. The terminal itself has the intelligence to initiate a relay 1003 service for incoming and outgoing calls (based on address book, 1004 user preferences programmed on the terminal etc. This terminal can 1005 be used in a conference bridge call as well as a third party 1006 control call. 1008 2. Dumb terminals, so that the relay service server actually 1009 initiates the correct call handling (the dumb terminal can only 1010 REFER the call to the relay center, which then sets up the call 1011 using the conference bridge flow.). 1013 The following call scenarios are shown: 1015 - Communications between two ToIP/Multimedia capable, end user 1016 devices using the same language. 1018 - Communications between ToIP capable, end user devices using 1019 translation services to provide language translation. 1021 A. van Wijk [Page 19 of 37] 1022 - Communications between ToIP/Multimedia capable and Audio (non- 1023 ToIP) capable end user devices. 1025 - Communications between ToIP/Multimedia and/or Audio (non- 1026 ToIP)/Multimedia end user devices maintaining privacy. 1028 8.11.2 Point-to-Point Call Scenarios 1030 The point-to-point call scenarios will contain at least one or 1031 both ToIP/Multimedia devices in setting up the session. The detail 1032 call scenarios will include: 1034 - ToIP/Multimedia devices that use the same language. 1036 - ToIP/Multimedia devices invoke translation services for using 1037 different languages. 1038 * Third-party call control model. 1039 * Conference bridge service model. 1041 - ToIP/Multimedia devices invoke translation services for using 1042 different languages maintaining privacy. 1043 * Third-party call control model. 1044 * Conference bridge service model. 1046 - ToIP/Multimedia device and Audio (non-ToIP)/Multimedia device 1047 invoking transcoding server. 1048 * Call initiated by Audio (non-ToIP)/Multimedia user 1049 - Third-party call control model. 1050 - Conference bridge service model. 1051 * Call initiated by ToIP user. 1052 - Third-party call control model. 1053 - Conference bridge service model. 1055 - ToIP/Multimedia device and Audio (non-ToIP)/Multimedia device 1056 invoking transcoding server maintaining privacy. 1057 * Call initiated by Audio (non-ToIP)/Multimedia user 1058 - Third-party call control model. 1059 - Conference bridge service model. 1060 * Call initiated by ToIP user. 1061 - Third-party call control model. 1062 - Conference bridge service model. 1064 8.11.3 Conference Call Scenarios 1066 The conference call scenarios only contain the multipoint 1067 communications, and only the centralized bridge model is 1068 considered. The following multipoint conference call scenarios 1069 will contain at least one more ToIP/Multimedia devices: 1071 - ToIP/Multimedia devices that use the same language. 1073 - ToIP/Multimedia devices invoke translation services for using 1074 different languages. 1076 A. van Wijk [Page 20 of 37] 1077 - ToIP/Multimedia devices invoke translation services for using 1078 different languages maintaining privacy. 1080 - ToIP/Multimedia device and Audio (non-ToIP)/Multimedia device 1081 invoking transcoding server. 1082 * Call initiated by Audio (non-ToIP)/Multimedia user. 1083 * Call initiated by ToIP/Multimedia user. 1085 - ToIP/Multimedia device and Audio (non-ToIP)/Multimedia device 1086 invoking transcoding server maintaining privacy. 1087 * Call initiated by Audio (non-ToIP)/Multimedia user. 1088 * Call initiated by ToIP/Multimedia user. 1090 9. Interworking Requirements for Text-over-IP 1092 A number of systems for real time text conversation already exist 1093 as well as a number of message oriented text communication 1094 systems. Interoperability is of interest between ToIP and some of 1095 these systems. This section describes requirements on this 1096 interoperability. 1098 9.1 Real-Time Text-over-IP Interworking Gateway Services 1100 Interactive texting facilities exist already in various forms and 1101 on various networks. On the PSTN, it is commonly referred to as 1102 text telephony. The simultaneous or alternating use of voice and 1103 text is used by a large number of users who can send voice, but 1104 must receive text or who can hear but must send text due to a 1105 speech disability. 1107 9.2 Text-over-IP and PSTN/ISDN Text-Telephony 1109 On PSTN networks, transmission of interactive text takes place 1110 using a variety of codings and modulations, including ITU-T V.21 1111 [II], Baudot, DTMF, V.23 [III] and others. Many difficulties have 1112 arisen as a result of this variety in text telephony protocols and 1113 the ITU-T V.18 [10] standard was developed to address some of 1114 these issues. 1116 ITU-T-V.18 [10] offers a native text telephony method plus it 1117 defines interworking with current protocols. In the interworking 1118 mode, it will recognise one of the older protocols and fall back 1119 to that transmission method when required. 1121 In order to allow systems and services based on Real-time Text- 1122 over-IP to communicate with PSTN text telephones, text gateways 1123 are the recommended approach. These gateways MUST use the ITU-T 1124 V.18 [10] standard at the PSTN side. 1126 Buffering MUST be used to support different transmission rates. At 1127 least 1K buffer MUST be provided. A buffer of at least 2K 1128 characters is recommended. In addition, the gateway MUST provide a 1130 A. van Wijk [Page 21 of 37] 1131 minimum throughput of at least 30 characters/second or the highest 1132 speed supported by the PSTN text telephony protocol side, 1133 whichever is the lowest. 1135 PSTN-Real-time Text-over-IP gateways MUST allow alternating use of 1136 text and voice. 1138 PSTN and ISDN to real-time Text-over-IP gateways that receive CLI 1139 information from the originating party MUST pass this information 1140 to the receiving party as soon as possible. 1142 Priority MUST be given to calls labeled as emergency calls. 1144 9.3 Text-over-IP and Cellular Wireless circuit switched Text- 1145 Telephony 1147 Cellular wireless (or Mobile) circuit switched connections provide 1148 a digital real-time transport service for voice or data. 1149 The access technologies include GSM, CDMA, TDMA, iDen and various 1150 3G technologies. 1152 Alternative means of transferring the Text telephony data have 1153 been developed when TTY services over cellular was mandated by the 1154 FCC in the USA. They are a) "No-gain" codec solution, b) the 1155 Cellular Text Telephony Modem (CTM) solution and c) "Baudot mode" 1156 solution. 1158 The GSM and 3G standards from 3GPP make use of the CTM modem in 1159 the voice channel for text telephony. 1160 However, implementations also exist that use the data channel to 1161 provide such functionality. Interworking with these solutions 1162 SHOULD be done using text gateways that set up the data channel 1163 connection at the GSM side and provide real-time Text-over-IP at 1164 the other side. 1166 9.3.1 "No-gain" 1168 The "No-gain" text telephone transporting technology uses 1169 specially modified EFR [15] and EVR [16] speech vocoders in both 1170 mobile terminals used provide a text telephony call. It provides 1171 full duplex operation and supports alternating voice and text.( 1172 "VCO/HCO"). It is dedicated to the CDMA and TDMA mobile 1173 technologies and the US Baudot type of text telephones. 1175 9.3.2 Cellular Text Telephone Modem (CTM) 1177 CTM [17] is a technology independent modem technology that 1178 provides the transport of text telephone characters at up to 10 1179 characters/sec using modem signals that are at or below 1 kHz and 1180 uses a highly redundant encoding technique to overcome the fading 1181 and cell changing losses. On any interface that uses analog 1182 transmission, half-duplex operation must be supported as the 1183 "send" and "receive" modem frequencies are identical. The use of 1185 A. van Wijk [Page 22 of 37] 1186 CTM may have to be modified slightly to support half-duplex 1187 operation. 1189 9.3.3 "Baudot mode" 1191 This term is often used by cellular terminal suppliers for a GSM 1192 cellular phone mode that allows TTYs to operate into a cellular 1193 phone and to communicate with a fixed line TTY. 1195 9.3.4 Data channel mode 1197 Many mobile terminals allow the use of the data channel to 1198 transfer data in real-time. Data rates of 9600 bit/s are usually 1199 supported on the mobile connection.Gateways or the interworking 1200 function provides interoperability with PSTN textphones. 1202 9.3.5 Common Text Gateway Functions 1204 Text Gateways MUST cover the differences that result from 1205 different text protocols. The protocols to be supported will 1206 depend on the service requirements of the Gateway. 1208 Different data rates of different protocols MAY require text 1209 buffering. 1211 Interoperation of half-duplex and full-duplex protocols MAY 1212 require text buffering and some intelligence to determine when to 1213 change direction when operating in half-duplex. 1215 Identification may be required of half-duplex operation either at 1216 the "user" level (ie. users must inform each other) or at the 1217 "protocol" level (where an indication must be sent back to the 1218 Gateway). 1220 A Text Gateway MUST be able to route text calls to emergency 1221 service providers when any of the recognised emergency numbers 1222 that support text communications for the country or region are 1223 called eg. "911" in USA and "112" in Europe. 1225 A text gateway MUST act transparently on the IP side. It acts then 1226 as a virtual end-point terminal. 1228 9.4 Text-over-IP and Cellular Wireless Text-over-IP 1230 Text-over-IP MAY be supported over the cellular wireless packet 1231 switched service. It interfaces to the Internet. For 3GPP 3G 1232 services, the support is described to use ToIP in 3G TS 26.235 1233 [20]. 1235 A Text gateway with cellular wireless packet switched services 1236 MUST be able to route text calls into emergency service providers 1237 when any of the recognized emergency numbers that support text 1238 communication for the country are called. 1240 A. van Wijk [Page 23 of 37] 1241 9.5 Instant Messaging Support 1243 Instant Messaging is used by many people to communicate using text 1244 via the Internet. Instant Messaging transfers blocks of text 1245 rather than streaming as is used for real-time Text-over-IP. As 1246 such, it is not a replacement for real-time Text-over-IP and in 1247 particular does not meet the needs for real time conversations of 1248 deaf, hard of hearing and speech-impaired users. It is unsuitable 1249 for communications through a relay service [I]. The streaming 1250 character of real-time Text-over-IP provides a better user 1251 experience and, when given the choice, users often prefer real- 1252 time Text-over-IP. 1254 However, since some users might only have Instant Messaging 1255 available, text gateways might be developed that allow 1256 interworking between Instant Messaging systems and real-time Text- 1257 over-IP solutions. 1259 Because Instant Messaging is based on blocks of text, rather than 1260 on a continuous stream of characters, such gateways need to 1261 transform between these two formats. Text gateways for 1262 interworking between Instant Messaging and real-time Text-over-IP 1263 MUST concatenate individual characters originating at the real- 1264 time Text-over-IP side into blocks of text and: 1266 a. When the length of the concatenated message becomes longer than 1267 50 characters, the buffered text MUST be transmitted to the 1268 Instant Messaging side as soon as any non-alphanumerical character 1269 is received from the real-time Text-over-IP side. 1271 b. When a new line is received from the real-time Text-over-IP 1272 side, the buffered characters up to that point, including the 1273 carriage return and/or line feed characters, MUST be transmitted 1274 to the Instant Messaging side. 1276 c. When the real-time Text-over-IP side has been idle for at least 1277 5 seconds, all buffered text up to that point MUST be transmitted 1278 to the Instant Messaging side. 1280 It is recommended that during the session, both users are 1281 constantly updated on the progress of the text input. 1282 For example, many Instant Messaging protocols signal that a user 1283 is typing to the other party in the conversation. Text gateways 1284 between Instant Messaging and real-time Text-over-IP MUST provide 1285 this signaling to the Instant Messaging side when characters start 1286 being received, or at the beginning of the conversation. 1287 Also at the real-time text-over-IP side, an indicator of writing 1288 the Instant Message MUST be present. For example, the real-time 1289 text user will see . . . waiting for replying IM. . . And per 5 1290 seconds a . (dot) can be shown. 1291 Those solutions will reduce the difficulties between a streaming 1292 versus blcoked text. 1294 A. van Wijk [Page 24 of 37] 1295 Even though that the text gateway can connect Instant Messaging 1296 and real-time Text-over-IP. The best solution is to take advantage 1297 of the fact that the user interfaces and the user communities for 1298 instant messaging and real-time text-over-IP telephony are 1299 extremely similar. 1301 After all, the character input, the character display, Internet 1302 connectivity, SIP stack, etc are the same for Instant Messaging 1303 and real-time Text-over-IP. 1305 Devices that implement Instant Messaging SHOULD implement real- 1306 time text-over-IP telephony, using standard SIP and text/t140 1307 mechanisms. 1309 9.6 IP Telephony with Traditional RJ-11 Interfaces 1311 Analogue adapters using SIP based IP communication and RJ-11 1312 connectors for connecting traditional PSTN devices SHOULD enable 1313 connection of legacy PSTN text telephones [18]. These adapters 1314 SHOULD contain V.18 modem functionality, voice handling 1315 functionality, and conversion functions to/from SIP based ToIP 1316 with T.140 transported according to RFC 2793, in a similar way as 1317 it provides interoperability for voice calls. If a call is set up 1318 and text/t140 capability is not declared by the endpoint (by the 1319 end-point terminal or the text gateway in the network at the end- 1320 point), a method for invoking a transcoding server shall be used. 1321 If no such server is available, the signals from the textphone MAY 1322 be transmitted in the voice channel as audio with high quality of 1323 service. 1324 NOTE: It is preferred that such analogue adaptors do use RFC2793 1325 on board and thus act as a text gateway. Sending textphone signals 1326 over the voice channel is undesirable due posible filtering and 1327 compression and packet loss between the end-points. Which can 1328 result in dropping characters in the textphone conversation or 1329 even not allowing the textphones to connect with each other. 1331 9.7 Interworking Call Flows 1333 The call scenarios in chapter 8.11 deal with end to end ToIP. 1334 These call flows do not change on the IP side of the network when 1335 one end-point is actually a text gateway. The text gateway 1336 actually acts like a ToIP/Multimedia device. Separate call flows 1337 will show the interworking between the ToIP/Multimedia devices [4] 1338 over the IP network and the text telephony devices [10] over the 1339 PSTN/ISDN network using the IP-PSTN/ISDN interworking functional 1340 (IWF) entity. It is assumed that the IWF will provide ToIP and 1341 text telephony interworking in addition to other capabilities. 1342 Thus acting as a Text gateway. 1344 The point-to-point call flows will contain at least one 1345 ToIP/Multimedia and one text telephony/multimedia (or POTS) device 1346 for the following cases: 1348 A. van Wijk [Page 25 of 37] 1349 - ToIP/Multimedia device and text telephony/multimedia device that 1350 use the same/different language. 1351 - ToIP/Multimedia device and PSTN/ISDN-based POTS/Multimedia 1352 device. 1354 For multipoint conferencing calls, it is assumed that only the 1355 centralized conferencing will be considered, and the media bridge 1356 is supposed to be located somewhere in the SIP network. However, 1357 it is considered that the ToIP and text telephony interworking 1358 function will be located in the IWF. 1360 The multipoint conference call flows will contain at least one 1361 ToIP/Multimedia device, at least one text telephony/multimedia 1362 device, and other devices where total number of devices will be 1363 three or more for the following cases: 1365 - ToIP/Multimedia and text telephony/multimedia devices that use 1366 the same/different language. 1367 - ToIP/Multimedia devices, telephony/multimedia devices, and/or 1368 PSTN/ISDN-based POTS/Multimedia devices. 1370 9.8 Multi-functional gateways 1372 The scenarios described in this document deal with single pairs of 1373 interworking protocols or services. However, in practice many of 1374 these interworking systems will be implemented as gateways that 1375 combine different functions. As such, a text gateway could be 1376 build to have modems to interwork with the PSTN and support both 1377 Instant Messaging as well as real-time ToIP. Such interworking 1378 functions are called Combination gateways. 1380 Combination gateways MUST provide interworking between all of 1381 their supported text based functions. For example, a text gateway 1382 that has modems to interwork with the PSTN and that support both 1383 Instant Messaging and real-time ToIP MUST support the following 1384 interworking functions: 1386 - PSTN text telephony to real-time ToIP. 1387 - PSTN text telephony to Instant Messaging. 1388 - Instant Messaging to real-time ToIP. 1390 9.9 Gateway Discovery 1392 To get a smooth invocation of the text gateways, where those 1393 gateways are transparant on the IP side, it requires a method how 1394 and when to invoke the text gateway. As described previously in 1395 this draft. The text gateways must act as the end-terminal. The 1396 capabilities of the text gateway will in that call be determined 1397 by the call capabilities of the terminal that is using the 1398 gateway. For example, a PSTN textphone is only able to receive 1400 A. van Wijk [Page 26 of 37] 1401 voice and streaming text. Thus the text gateway will only allow 1402 ToIP and audio. 1404 The PSTN devices or other non IP multimedia devices that require 1405 the text gateways to connect to the IP must be able to locate the 1406 text gateway, and ensure that the correct call capabilities of the 1407 non IP multimedia device is used by the text gateway. 1409 The following possible solutions for using the text gateway are: 1411 - PSTN Textphone users using a prefix number before dialing out. 1412 - In band text dialogue, where the gateway asks the user for the 1413 destination address. 1414 - separate text subscriptions, linked to the phone number or 1415 terminal identifier/ IP address. 1416 - text capability indicators. 1417 - text preference indicator. 1418 - listen for text activity in all calls. 1419 - call transfer request by the called user. 1420 - placing a call via the web, and use one of the methods described 1421 here 1422 - text gateways with its own telephone number and/or SIP address. 1423 (this requires user interaction with the text gateway to place a 1424 call). 1425 - ENUM address analysis and number plan 1426 - number or address analysis leads to the gateway for all PSTN 1427 calls. 1428 - etc 1430 9.10 Text Gateway in the call Scenarios 1432 9.10.1 IP terminal calling an analogue textphone (PSTN) 1434 The ToIP stream will be converted into an analogue text telephone 1435 protocol (using the voice channel) and vice versa by the text 1436 gateway. 1438 The PSTN knows that it may be a textphone call thanks to the SDP 1439 description (for example: m=text 11000 RTP/AVP 98 a=rtpmap:98 1440 t140/1000 for T.140 text on port 11000). It can then activate text 1441 gateway functions on the PSTN side listening for a text answer. 1443 The PSTN will also know that all those incoming calls are only for 1444 analogue textphones. Thus the speed of the text stream is adjusted 1445 to the selected analogue textphone protocol. 1446 If there is no analogue textphone on the called number, the call 1447 setup will be terminated by the text gateway. 1449 The text gateway can be implemented in two ways: The PSTN has its 1450 own text gateway (the IWF), or it redirects the media stream to 1451 the nearest IP-PSTN gateway with text transcoding abilities. 1453 Text gateway detection: In the SIP messages. 1455 A. van Wijk [Page 27 of 37] 1456 9.10.2 IP terminal calling a mobile text telephone (CTM) 1458 The ToIP stream will be converted into CTM and vice versa by the 1459 text gateway located in the network of the cellular/mobile 1460 operator. It is similar to the PSTN. 1462 Text gateway detection: In the SIP messages. 1464 9.10.3 IP terminal calling a mobile telephone (GPRS based) 1466 A text gateway located in the mobile network converts the incoming 1467 T.140/RTP stream into for example T.140 over TCP (T.140/TCP) or 1468 tunnels the T.140 stream over HTTP (T.140/HTTP). Or any other 1469 temporarily non standard solution necessary to connect the text 1470 gateway with the text telephone client on the mobile phone. 1472 This is necessary, since RTP over GPRS is not possible in many 1473 mobile phones. 1474 Note, those server-client solutions are ONLY acceptable for the 1475 GPRS and non RTP stack phones. It is encouraged to use T.140/RTP 1476 as soon as possible for all mobile phones. 1477 Allowing UDP transport over the GPRS link will enable RFC2793 text 1478 over GPRS. 1480 Text gateway detection: In the SIP messages. 1482 9.10.4 IP terminal calling a mobile telephone(UMTS) 1484 No text gateway is required here since this will be end to end IP. 1486 9.10.5 Analogue textphone (PSTN) user calling an IP terminal using 1487 prefix 1489 The PSTN is unable to distinguish between an analogue voice call 1490 and an analogue textphone, both use the voice channel. The text 1491 gateway needs to transcode the analogue textphone protocol into 1492 T.140/RTP. 1494 One way for a PSTN to separate an incoming voice call into text 1495 telephony or normal voice is by using a prefix number for all 1496 incoming text telephone calls to the PSTN. For example , the text 1497 telephone user (e.g Boudot) places a call and enters a prefix e.g. 1498 600 and then continues with the original number. The PSTN will 1499 recognize all incoming 600 calls as an analogue textphone call and 1500 redirects the call to a text gateway (unless it is a number 1501 connecting the same PSTN). 1503 It is undesirable to allow a PSTN to transport all the analogue 1504 textphone tones/signals through a VoIP stream! (In band text 1505 dialogue). 1507 A. van Wijk [Page 28 of 37] 1508 Text gateway detection: Prefix number for incoming textphone 1509 calls. 1511 9.10.6 Mobile text telephone (CTM) user calling an IP terminal 1513 The voice channel of the cellular network is used. The MSC is able 1514 to separate between the text call and voice only, it is just a 1515 matter of redirecting the voice channel to the text gateway. 1517 Text gateway detection: CTM signal detection. 1519 9.10.7 Mobile telephone user (GPRS) calling an IP terminal 1521 The text telephone client on the mobile telephone connects the 1522 text gateway located in the network. The text gateway transcodes 1523 the text stream into ToIP. 1525 Text gateway detection: pre-programmed in the mobile textphone 1526 client. 1528 9.10.8 Mobile telephone (UMTS) user calling an IP terminal 1530 No text gateway is required here since this will be end to end IP. 1532 9.10.9 Voice over DSL user using an analogue text telephone. 1534 Voice over DSL is a widespread service. When connecting analogue 1535 text telephones to this service there is a risk that they just use 1536 the voice channel that result in corrupted text transmission. The 1537 VoDSL gateway located in the network of the (A)DSL operator itself 1538 should connect with a text gateway as soon it turns into VoIP. 1540 Text gateway detection: prefix number similar to the PSTN. 1542 9.10.10 VoIP user via a building telephone switch (at an apartment 1543 building) owning an analogue text telephone. 1545 This is the case where only VoIP is possible and no other IP 1546 traffic between the telephone switch and the apartments. 1547 The only solution would be a forced analogue text telephone 1548 protocol over the Voice channel, in band text dialogue . If that 1549 must happen. Then the telephone switch MUST convert the analogue 1550 text telephone protocol into ToIP and vice versa before the 1551 telephone switch connects the IP network. 1552 Note: The in band text dialogue is undesirable. This scenario 1553 SHOULD be avoided at any cost. 1555 Text gateway detection: prefix number or in band text signalling. 1557 9.10.11 VoIP user via a gateway/box connected to his/her own 1558 Broadband connection owning an analogue text telephone. 1560 A. van Wijk [Page 29 of 37] 1561 The gateway box should natively transcode analogue text telephony 1562 into ToIP and vice versa when an analogue text phone is plugged in 1563 the RJ-11 socket [18]. 1565 Text gateway detection: RJ-11 socket preconfigured by the box via 1566 jumpers or software, or listen for textphone tones and perform 1567 V.18 text telephone detection. 1569 10. Terminal Features 1571 Implementers of products that support interactive Text-over-IP 1572 SHOULD NOT assume that all users of text are able to use 1573 mainstream input and output devices. People with arthritis or 1574 other dexterity problems might not be able to use very small 1575 keyboards. Visually impaired people might not be able to use 1576 standard sized characters on a display. Colour-blind people might 1577 suffer from badly chosen colour-schemes. People with motor 1578 disabilities might require specialised input devices. 1580 Implementers SHOULD make their products as open as possible with 1581 regard to this wide range of abilities and preferences and they 1582 MUST use standard interfaces wherever they provide such 1583 interfaces. 1585 10.1 Text input 1587 Systems that support real-time interactive Text-over-IP SHOULD 1588 support suitable input mechanisms, either built-in or connectable 1589 through the use of a standard interface: PS/2, USB, Bluetooth, or 1590 virtual keyboard. In particular Braille users should be able to 1591 connect Braille keyboards to the terminal. Terminals MAY support a 1592 web interface for input and output of text. 1594 It is recommended that systems that fixed terminals that support 1595 real-time interactive Text-over-IP allow the user to enter the 1596 standard alphanumerical characters directly, rather than through a 1597 cycle of key presses or other indirect means. This could be done 1598 using full-sized keyboards, smaller sized keyboards or fastap 1599 keyboards for example. It is highly recommended to provide a 1600 standard interface to allow attachment of an external input 1601 device, especially for terminals that have only limited input 1602 systems built-in. 1604 Systems should provide means to add voice-to-text translation as 1605 text input. 1607 All IP phones with a display of 12 or more characters MUST support 1608 at least text input through the regular phone keypad (and display 1609 of any incoming text) in order to provide basic emergency text 1610 communication from any IP phone. 1612 A. van Wijk [Page 30 of 37] 1613 Input devices that have automatic key repeat MUST allow the user 1614 to specify the key-repeat rate. 1616 10.2 Text presentation 1618 Systems that support real-time interactive Text-over-IP SHOULD 1619 support suitable displays, either built-in or connectable through 1620 the use of a standard interface: S-VGA, USB, Bluetooth or IP. 1621 Braille readers should be connectable to the terminal using a 1622 standard interface. 1624 Terminals MAY support a web interface for input and output of 1625 text. 1627 A variety of handsets and terminals might be developed for a 1628 number of equally varied scenarios. 1630 In the case of fixed terminals or software applications on 1631 Personal Computers, implementers MUST: 1633 a. Use either separate screen areas for displaying sent and 1634 received text OR clearly indicate the difference between sent and 1635 received text. Systems MAY allow the user to chose either on of 1636 these presentation methodologies. 1638 b. Provide at least 5 lines of 35 monospaced characters each for 1639 each direction (sent and received text) OR at least 10 lines of 35 1640 characters when sent and received text are presented together. 1642 In the case of Mobile terminals, implementers MUST: 1644 c. Use either separate screen areas for displaying sent and 1645 received text OR clearly indicate the difference between sent and 1646 received text. Systems MAY allow the user to chose either on of 1647 these presentation methodologies. 1649 d. Provide at least 3 lines of 20 monospaced characters each for 1650 each direction (sent and received text) OR at least 6 lines of 20 1651 characters when sent and received text are presented together. 1653 On both types of terminals, scrolling back through both sent and 1654 received text MUST be supported, even after the conversation has 1655 ended. Lines SHOULD be wrapped at word boundaries . 1657 There MUST be an easy-to-use function to clear the screen at any 1658 time during the session, and if the implementation has chosen to 1659 present sent and received text separately, clearing the screen 1660 SHOULD be possible as a separate function for sent and received 1661 text. 1663 The function of the new line and erasure controls as explained in 1664 section 9.5. MUST be supported by the presentation in the 1666 A. van Wijk [Page 31 of 37] 1667 consistent way described by T.140. Presentation layers MUST 1668 support the full UTF-8 character set. 1670 When real-time Text-over-IP is used in conjunction with other 1671 modalities, like voice, the presentation MUST clearly indicate 1672 this to the user in an area outside the display region for send 1673 and received text. 1675 Identification information for other parties in the conversation, 1676 like URL�s, user-friendly names from an address book, or CLI in 1677 the case of conversations with text telephones, SHOULD be 1678 displayed throughout the entire conversation in a region outside 1679 the sent and received text area. 1681 10.3 Call control 1683 Call (Session) Control procedures MUST use the SIP protocol. Text 1684 sessions MUST be identified in accordance with requirements 1685 described earlier. 1687 Text services SHOULD be part of a Total Conversation environment 1688 in which voice, text and video sessions can be added, modified or 1689 deleted individually. 1691 To enable interworking with Textphones in telephone and cellular 1692 (mobile) networks, terminals MUST be able to access Gateways 1693 automatically when a PSTN or cellular (mobile) E.164-based 1694 telephone number is used as the called address. 1696 Users MUST be able to establish text sessions to emergency service 1697 providers using the widely recognised emergency numbers in use in 1698 the country or region of operation of the terminal eg. �911� in 1699 USA and �112�in Europe. 1701 The ability to transfer Location information SHALL be provided if 1702 the information is available from the terminal. 1704 10.4 Device control 1706 ToIP devices shall support multiple means of setting up and 1707 performing calls as well as controlling the device itself. The 1708 built-in controls and presentation systems shall take 1709 accessibility aspects into account as far as possible. The device 1710 shall include external interfaces that makes it possible to attach 1711 user interface devices for people with needs beyond what the 1712 built-in user interface can support. It is preferrable if such 1713 external interfaces are wireless. 1715 10.5 Alerting 1717 A. van Wijk [Page 32 of 37] 1718 The form of Alerting indication(s) provided to the user should be 1719 selectable to suit particular users. Alerting indications MAY 1720 include Sound, Tactile (eg. vibrational), Visual (on-screen 1721 symbols; separate flashing light), Motion (eg. movement of 1722 something). 1724 The ability to send an Alerting signal to an external interface 1725 SHOULD be provided. This will allow Alerting devices that are 1726 specific to users requirements to be attached. 1728 As many as possible of the following alternatives for alerting 1729 SHOULD be provided: 1730 * Internal flash. 1731 * Two-pole connector for external alerting systems triggered 1732 by contact between the two poles when a ring signal is generated 1733 (if necessary with 1.5-9 V battery power for alerting systems 1734 requiring electrical currents to activate). 1735 * Bluetooth serial profile with AT command interface, sending 1736 the "RING" message, intended for a Bluetooth alerting receiver 1737 with flash, vibration or sound action. 1738 * SIP connected alerting device, that get its stimuli by being 1739 registered on the same sip address as the terminal. 1741 10.6 External interfaces 1743 Terminals for ToIP SHOULD provide external interfaces for the 1744 following functions: 1745 * Text input. 1746 * Text display. 1747 * Terminal control. 1748 * Session control. 1750 10.7 Power 1752 As terminals could remain active for very long periods of time, 1753 the electrical power requirements of all the terminals SHOULD be 1754 as low as possible. 1756 If the terminal is to be used for calling Emergency services or 1757 where the mains power supply is unreliable, back-up power systems 1758 SHOULD be provided for the terminal and all equipment used to 1759 provide the ToIP service. This can be implemented in many 1760 different ways eg. via the line powering option on some Ethernet 1761 interfaces, or by using a "no break" power supply (a battery back- 1762 up system with inverters that can recreate a limited amount of 1763 mains power). 1765 11. Security Considerations 1767 There are no additional security requirements other than described 1768 earlier. 1770 12. Outstanding issues 1772 A. van Wijk [Page 33 of 37] 1773 A number of outstanding issues yet need to be resolved. This is 1774 possible in this draft, or in a separate draft. 1776 - Call flows diagrams based on the scenarios discussed in this 1777 draft. 1778 - Service labelling of media streams to be able to determine which 1779 kind of service the text stream contains. For example, is it 1780 english, spanish text? Is it an emergency text stream? Etc. 1782 13. Authors Addresses 1784 The following people provided substantial technical and writing 1785 contributions to this document, listed alphabetically: 1787 Barry Dingle 1788 ACIF, 32 Walker Street 1789 North Sydney, NSW 2060 Australia 1790 Tel +61 (0)2 9959 9111 1791 Fax +61 (0)2 9954 6136 1792 TTY +61 (0)2 9923 1911 1793 Mob +61 (0)41 911 7578 1794 Email barry.dingle@bigfoot.com.au 1796 Guido Gybels 1797 RNID, 19-23 Featherstone Street 1798 London EC1Y 8SL, UK 1799 Tel +44(0)20 7294 3713 1800 Txt +44(0)20 7296 8019 1801 Fax +44(0)20 7296 8069 1802 EMail: guido.gybels@rnid.org.uk 1804 Gunnar Hellstrom 1805 Omnitor AB 1806 Renathvagen 2 1807 SE 121 37 Johanneshov 1808 Sweden 1809 Phone: +46 708 204 288 / +46 8 556 002 03 1810 Fax: +46 8 556 002 06 1811 Email: gunnar.hellstrom@omnitor.se 1813 Radhika R. Roy 1814 AT&T 1815 Room C1-2B03 1816 200 Laurel Avenue S. 1817 Middletown, NJ 07748 1818 USA 1819 Phone: +1 732 420 1580 1820 Fax: +1 732 368 1302 1821 Email: rrroy@att.com 1823 Henry Sinnreich 1825 A. van Wijk [Page 34 of 37] 1826 MCI 1827 400 International Parkway 1828 Richardson, Texas 75081 1829 Email: henry.sinnreich@mci.com 1831 Gregg C Vanderheiden 1832 University of Wisconsin-Madison 1833 Trace R & D Center 1834 1550 Engineering Dr (Rm 2107) 1835 Madison, Wi 53706 1836 USA 1837 gv@trace.wisc.edu 1838 Phone +1 608 262-6966 1839 FAX +1 608 262-8848 1841 Arnoud A. T. van Wijk 1842 Viataal (Dutch Institute for the Deaf) 1843 Research & Development 1844 Afdeling RDS 1845 Theerestraat 42 1846 5271 GD Sint-Michielsgestel 1847 The Netherlands. 1848 Email: a.vwijk@viataal.nl 1850 14. Acknowledgements 1852 The authors wish to thank Snowshore for providing the ToIP mailing 1853 list, which allows many discussions necessary for this draft. 1855 15. Full Copyright Statement 1857 Copyright (C) The Internet Society (2004). This document is 1858 subject to the rights, licenses and restrictions contained in BCP 1859 78, and except as set forth therein, the authors retain all their 1860 rights. 1861 This document and the information contained herein are provided on 1862 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1863 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1864 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1865 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1866 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1867 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1868 PARTICULAR PURPOSE. 1870 16. References 1872 16.1 Normative 1874 1. Bradner, S., "The Internet Standards Process -- Revision 3", 1875 BCP 9, RFC 2026, October 1996. 1877 2. Bradner, S., "Key words for use in RFCs to Indicate Requirement 1878 Levels", BCP 14, RFC 2119, March 1997 1880 A. van Wijk [Page 35 of 37] 1881 3. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 1882 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session 1883 Initiation Protocol, RFC 3621, IETF, June 2002. 1885 4. ITU-T Recommendation T.140, "Protocol for Multimedia 1886 Application Text Conversation (February 1998) and Addendum 1 1887 (February 2000). 1889 5. G. Hellstrom, "RTP Payload for Text Conversation, RFC 2793, May 1890 2000. 1892 6. G. Camarillo, H. Schulzrinne, and E. Burger, "The Source and 1893 Sink Attributes for the Session Description Protocol," IETF, 1894 August 2003 � Work in Progress. 1896 7. G.Camarillo, "Framework for Transcoding with the Session 1897 Initiation Protocol" IETF august 2003 - Work in progress. 1899 8. G. Camarillo, H. Schulzrinne, E. Burger, and A. van Wijk, 1900 "Transcoding Service Invocation in SIP using Third Party Call 1901 Control," IETF, September 2004 - Work in Progress. 1903 9. G. Camarillo, "The SIP Conference Bridge Transcoding Model," 1904 IETF, August 2003 - Work in Progress. 1906 10. ITU-T Recommendation V.18,"Operational and Interworking 1907 Requirements for DCEs operating in Text Telephone Mode," November 1908 2000. 1910 11. "XHTML 1.0: The Extensible HyperText Markup Language: A 1911 Reformulation of HTML 4 in XML 1.0", W3C Recommendation. Available 1912 at http://www.w3.org/TR/xhtml1. 1914 12. Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1915 RFC 2279, January 1998. 1917 13. TIA/EIA/825 "A Frequency Shift Keyed Modem for Use on the 1918 Public Switched Telephone Network." (The specification for 45.45 1919 and 50 bit/s TTY modems.) 1921 14. Bell-103 300 bit/s modem. 1923 15. TIA/EIA/IS-823-A "TTY/TDD Extension to TIA/EIA-136-410 1924 Enhanced Full Rate Speech Codec (must used in conjunction with 1925 TIA/EIA/IS-840)" 1927 16. TIA/EIA/IS-127-2 "Enhanced Variable Rate Codec, Speech Service 1928 Option 3 for Wideband Spread Spectrum Digital Systems. Addendum 1929 2." 1931 17. 3GPP TS26.226 "Cellular Text Telephone Modem Description" 1932 (CTM). 1934 A. van Wijk [Page 36 of 37] 1935 18. I. Butcher, S. Lass, D. Petrie, H. Sinnreich, and C. 1936 Stredicke, "SIP Telephony Device Requirements, Configuration and 1937 Data," IETF, February 2004- Work in Progress. 1939 19 Baugher, McGrew, Carrara, Naslund, Norrman, "The Secure Real- 1940 Time Transport Protocol (SRTP)", RFC 3711, March 2004. 1942 20. IP Multimedia default codecs. 3GPP TS 26.235 1944 16.2 Informative 1946 I. A relay service allows the users to transcode between different 1947 modalities or languages. In the context of this document, relay 1948 services will often refer to text relays that transcode text into 1949 voice and vice-versa. See for example http://www.typetalk.org. 1951 II. International Telecommunication Union (ITU), "300 bits per 1952 second duplex modem standardized for use in the general switched 1953 telephone network". ITU-T Recommendation V.21, November 1988. 1955 III. International Telecommunication Union (ITU), "600/1200-baud 1956 modem standardized for use in the general switched telephone 1957 network. ITU-T Recommendation V.23, November 1988. 1959 IV. Third Generation Partnership Project (3GPP), "Technical 1960 Specification Group Services and System Aspects; Cellular Text 1961 Telephone Modem; General Description (Release 5)". 3GPP TS 26.226 1962 V5.0.0, 1964 A. van Wijk [Page 37 of 37]