idnits 2.17.1 draft-ietf-sipping-toip-03.txt: -(192): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(226): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(606): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(685): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(706): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(762): 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 3978, Section 5.5 on line 1465. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1440. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1456. ** 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. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 8 instances of lines with non-ascii characters in the document. 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 471 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 6 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. RFC 2119 keyword, line 355: '...ivacy and security provisions, MUST be...' RFC 2119 keyword, line 362: '... these functions MUST also be supporte...' RFC 2119 keyword, line 419: '...the ToIP service SHOULD support the fu...' RFC 2119 keyword, line 424: '...on, both called and calling, SHOULD be...' RFC 2119 keyword, line 432: '...ency, the delays SHOULD be kept minima...' (106 more instances...) 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. -- 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: Informational ---------------------------------------------------------------------------- -- Missing reference section? '19' on line 1226 looks like a reference -- Missing reference section? '5' on line 1135 looks like a reference -- Missing reference section? '2' on line 172 looks like a reference -- Missing reference section? '4' on line 813 looks like a reference -- Missing reference section? '23' on line 323 looks like a reference -- Missing reference section? 'I' on line 561 looks like a reference -- Missing reference section? '10' on line 1051 looks like a reference -- Missing reference section? 'III' on line 958 looks like a reference -- Missing reference section? 'II' on line 958 looks like a reference -- Missing reference section? '13' on line 518 looks like a reference -- Missing reference section? '14' on line 518 looks like a reference -- Missing reference section? '15' on line 526 looks like a reference -- Missing reference section? '18' on line 550 looks like a reference -- Missing reference section? '3' on line 1237 looks like a reference -- Missing reference section? '6' on line 626 looks like a reference -- Missing reference section? '24' on line 667 looks like a reference -- Missing reference section? '20' on line 762 looks like a reference -- Missing reference section? '7' on line 1206 looks like a reference -- Missing reference section? '8' on line 764 looks like a reference -- Missing reference section? '9' on line 764 looks like a reference -- Missing reference section? '12' on line 808 looks like a reference -- Missing reference section? '11' on line 877 looks like a reference -- Missing reference section? 'IV' on line 958 looks like a reference -- Missing reference section? '16' on line 1119 looks like a reference -- Missing reference section? '17' on line 1238 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 30 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Workgroup A. van Wijk (editor) 3 Internet-Draft Viataal 4 Category: Informational 5 Expires: March 6 2006 September 7 2005 7 Framework of requirements for real-time text conversation using SIP 9 draft-ietf-sipping-toip-03.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79 17 [1]. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 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. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 6, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document provides the framework of requirements for real-time 45 character-by-character interactive text conversation over the IP 46 network using the Session Initiation Protocol and the Real-Time 47 Transport Protocol. It discusses requirements for real-time Text- 48 over-IP as well as interworking between Text-over-IP and existing 49 text telephony on the PSTN and other networks. 51 A. van Wijk, et al. Expires 6 March 2006 [Page 1 of 28] 52 Table of Contents 54 1. Introduction.....................................................3 55 2. Scope............................................................4 56 3. Terminology......................................................4 57 4. Definitions......................................................4 58 5. Framework Description............................................6 59 5.1. General requirements for ToIP..................................6 60 5.1.1 General ToIP Summary..........................................8 61 5.2. General Requirements for ToIP Interworking.....................8 62 5.2.1 PSTN Interworking.............................................9 63 5.2.2 Cellular circuit switched Text-Telephony.....................10 64 5.2.2.1 Cellular "No-gain".........................................10 65 5.2.2.2 Cellular Text Telephone Modem (CTM)........................10 66 5.2.2.3 Cellular "Baudot mode".....................................11 67 5.2.3 Cellular data channel mode...................................11 68 5.2.4 Cellular Wireless ToIP.......................................11 69 5.2.5 Instant Messaging Support....................................11 70 6. Detailed requirements for ToIP..................................11 71 6.1. Pre-Session Requirements......................................12 72 6.2 Basic Point-to-Point Session Requirements......................12 73 6.2.1 Session control..............................................12 74 6.2.2 Text transport...............................................12 75 6.2.3 Session Setup................................................13 76 6.2.4 Addressing...................................................13 77 6.2.5 Alerting.....................................................14 78 6.2.6 Session information..........................................14 79 6.2.7 Session progress information.................................14 80 6.2.8 Session Negotiations.........................................15 81 6.2.9 Answering....................................................15 82 6.2.9.1 Answering Machine..........................................15 83 6.2.10 Actions During a Session....................................15 84 6.2.10.1 Text Transport............................................16 85 6.2.10.2 Handling Text and other Media.............................16 86 6.2.11 Additional session control..................................17 87 6.2.12 File storage................................................17 88 6.3 Conference Session Requirements................................17 89 6.4 Real-time Editing and User Alerting............................17 90 6.5 Emergency services.............................................17 91 6.6 User Mobility..................................................18 92 6.7 Firewalls and NATs.............................................18 93 7. Interworking Requirements for ToIP..............................18 94 7.1 ToIP Interworking Gateway Services.............................18 95 7.2 ToIP and PSTN/ISDN Text-Telephony Interworking.................18 96 7.3 ToIP and Cellular Wireless ToIP................................19 97 7.4 Instant Messaging Support......................................19 98 7.5 Common Text Gateway Functions..................................20 99 7.5.1 Protocol support.............................................20 100 7.5.2 Relay buffer storage.........................................20 101 7.5.3 Emergency calls through gateways.............................21 102 7.5.4 Text Gateway Invocation......................................21 103 7.6 Home Gateways or Analog Terminal Adapters......................21 104 7.7 Multi-functional Combination gateways..........................22 106 A. van Wijk, et al. Expires 6 March 2006 [Page 2 of 28] 107 7.8 Transcoding....................................................22 108 7.9 Relay Services.................................................23 109 7.9.1 Basic function of the relay service..........................23 110 7.9.2 Invocation of relay services.................................23 111 8. Security Considerations.........................................23 112 9. Authors Addresses...............................................24 113 10. References.....................................................25 114 10.1 Normative references..........................................25 115 10.2 Informative references........................................27 117 1. Introduction 119 For many years, text has been in use as a medium for 120 conversational, interactive dialogue between users in a similar 121 way to how voice telephony is used. Such interactive text is 122 different from messaging and semi-interactive solutions like 123 Instant Messaging in that it offers an equivalent conversational 124 experience to users who cannot, or do not wish to, use voice. It 125 therefore meets a different set of requirements from other text- 126 based solutions already available on IP networks. 128 Traditionally, deaf, hard of hearing and speech-impaired people 129 are amongst the most prolific users of conversational, interactive 130 text but, because of its interactivity, it is becoming popular 131 amongst mainstream users as well. 133 This document describes how existing IETF protocols can be used to 134 implement a Text-over-IP solution (ToIP). This ToIP framework is 135 specifically designed to be compatible with Voice-over-IP (VoIP) 136 environments, as well as meeting the user�s requirements, 137 including those of deaf, hard of hearing and speech-impaired users 138 as described in RFC3351 [19]. 140 The Session Initiation Protocol (SIP) is the protocol of choice 141 for control of Multimedia communications and Voice-over-IP (VoIP) 142 in particular. It offers all the necessary control and signaling 143 required for the ToIP framework. 145 The Real-Time Transport Protocol (RTP) is the protocol of choice 146 for real-time data transmission, and its use for interactive text 147 payloads is described in RFC4103 [5]. 149 This document defines a framework for ToIP to be used either by 150 itself or as part of integrated, multi-media services, including 151 Total Conversation. 153 A. van Wijk, et al. Expires 6 March 2006 [Page 3 of 28] 154 2. Scope 156 This document defines a framework for the implementation of real- 157 time ToIP, either stand-alone or as a part of multimedia services, 158 including Total Conversation. It defines the: 160 a. Requirements of Real-time, interactive text; 161 b. Requirements for ToIP interworking; 162 c. Description of ToIP using SIP and RTP; 163 d. Description of ToIP interworking with other text services. 165 3. Terminology 167 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 168 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 169 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 170 described in BCP 14, RFC 2119 [2] and indicate requirement levels 171 for compliant implementations. 173 4. Definitions 175 Audio bridging - a function of a gateway or relay service that 176 enables an audio path through the service between the users 177 involved in the call. 179 Cellular - Telephone systems based on radio transmission to become 180 wireless. Also called Wireless or Mobile systems. 182 Full duplex - media is sent independently in both directions. 184 Half duplex - media can only be sent in one direction at a time 185 or, if an attempt to send information in both directions is made, 186 errors can be introduced into the presented media. 188 Interactive text - a term for real time transmission of text in a 189 character-by-character fashion for use in conversational services, 190 often as a text equivalent to voice based conversational services. 192 Textphone � also "text telephone". A terminal device that allows 193 end-to-end real-time, interactive text communication using analog 194 transmission. A variety of PSTN textphone protocols exists world- 195 wide. A textphone can often be combined with a voice telephone, or 196 include voice communication functions for simultaneous or 197 alternating use of text and voice in a call. 199 Text bridging - a function of a gateway service that enables the 200 flow of text through the service between the users involved in the 201 call. 203 Text gateway - a function that transcodes between different forms 204 of text transport methods, e.g., between ToIP in IP networks and 205 Baudot or ITU-T V.21 text telephony in the PSTN. 207 A. van Wijk, et al. Expires 6 March 2006 [Page 4 of 28] 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 Text telephony � analog textphone service. 215 Total Conversation - a multimedia service offering real time 216 conversation in video, text and voice according to interoperable 217 standards. All media flow in real time. (See ITU-T F.703 218 "Multimedia conversational services".) 220 Transcoding Services - services of a third-party user agent that 221 transcodes one stream into another. Transcoding can be done by 222 human operators, in an automated manner or a combination of both 223 methods. Text Relay Services are examples of a transcoding service 224 between text and audio. 226 TTY � alternative designation for a text telephone or textphone, 227 often used in USA. Also called TDD, Telecommunication Device for 228 the Deaf. 230 Video Relay Service - A service that enables communications 231 between deaf and hard of hearing people, and hearing persons with 232 voice telephones by translating between sign language and spoken 233 language in a call. 235 Acronyms: 237 2G Second generation cellular (mobile) 238 2.5G Enhanced second generation cellular (mobile) 239 3G Third generation cellular (mobile) 240 CDMA Code Division Multiple Access 241 CLI Calling Line Identification 242 CTM Cellular Text Telephone Modem 243 ENUM E.164 number storage in DNS (see RFC3761) 244 GSM Global System of Mobile Communication 245 ISDN Integrated Services Digital Network 246 ITU-T International Telecommunications Union-Telecommunications 247 Standardisation Sector 248 NAT Network Address Translation 249 PSTN Public Switched Telephone Network 250 RTP Real Time Transport Protocol 251 SDP Session Description Protocol 252 SIP Session Initiation Protocol 253 SRTP Secure Real Time Transport Protocol 254 TDD Telecommunication Device for the Deaf 255 TDMA Time Division Multiple Access 256 TTY Analog textphone (Teletypewriter) 257 ToIP Text over Internet Protocol 258 UTF-8 Universal Transfer Format-8 259 VCO/HCO Voice Carry Over/Hearing Carry Over 260 VoIP Voice over Internet Protocol 262 A. van Wijk, et al. Expires 6 March 2006 [Page 5 of 28] 263 5. Framework Description 265 This framework defines the requirements of a text-based 266 conversational service that is the text equivalent of voice based 267 telephony. Real-time text conversation can be combined with other 268 conversational services like video or voice. 270 ToIP also offers an IP equivalent of analog text telephony 271 services as used by deaf, hard of hearing and speech-impaired 272 individuals. 274 It is important to understand that real-time text conversations 275 are significantly different from other text-based communications 276 like email or instant messaging. Real-time text conversations 277 deliver an equivalent mode to voice conversations by providing 278 transmission of text character by character as it is entered, so 279 that the conversation can be followed closely and immediate 280 interaction takes place. This provides the same mode of 281 interaction as voice telephony does for hearing people. 283 Store-and-forward systems like email or messaging on mobile 284 networks or non-streaming systems like instant messaging are 285 unable to provide that functionality. In particular, they do not 286 allow for smooth communication through a Text Relay Service. 288 This framework uses existing standards that are already commonly 289 used for voice based conversational services on IP networks. It 290 uses the Session Initiation Protocol (SIP) to set up, control and 291 tear down the connections between users whilst the media is 292 transported using the Real-Time Transport Protocol (RTP) as 293 described in RFC4103 [5]. 295 This framework is designed to meet the requirements of RFC3351 296 [19]. As such, it offers a standardized way for offering text- 297 based, conversational services that can be used as an equivalent 298 to voice telephony by deaf, hard of hearing and speech-impaired 299 individuals. 301 SIP allows participants to negotiate all media including real-time 302 text conversation [4,5]. This is a highly desirable function for 303 all IP telephony users but essential for deaf, hard of hearing, or 304 speech impaired people who have limited or no use of the audio 305 path of the call. 307 5.1. General requirements for ToIP 309 In order to make ToIP the text equivalent of voice services, it 310 needs to offer equivalent features in terms of conversationality 311 as voice telephony provides. To achieve that, ToIP needs to: 313 a. Offer real-time presentation of the conversation; 314 b. Provide simultaneous transmission in both directions; 315 c. Support both point-to-point and multipoint communication; 317 A. van Wijk, et al. Expires 6 March 2006 [Page 6 of 28] 318 d. Allow other media, like audio and video, to be used in 319 conjunction with ToIP; 320 e. Ensure that the text service is always available. 322 Real-time text is a useful subset of Total Conversation defined in 323 ITU-T F.703 [23]. Users could use multiple modes of communication 324 during the conversation, either at the same time or by switching 325 between modes, e.g., between text and audio. 327 Users may invoke ToIP services for many different reasons: 329 - Because they are in a noisy environment, e.g., in a machine room 330 of a factory where listening is difficult. 331 - Because they are busy with another call and want to participate 332 in two calls at the same time. 333 - For implementing text and/or speech recording services (e.g., 334 text documentation/ audio recording for 335 legal/clarity/flexibility purposes). 336 - To overcome language barriers through speech translation and/or 337 transcoding services. 338 - Because of hearing loss, deafness or tinnitus as a result of the 339 aging process or for any other reason, thus creating a need to 340 replace or complement voice with text in conversational 341 sessions. 343 NOTE: In many of the above examples, text may accompany speech. 344 The text could be displayed side by side, in a manner similar to 345 subtitling in broadcasting environments, or in any other suitable 346 manner. This could occur for users who are hard of hearing and 347 also for mixed media calls with both hearing and deaf people 348 participating in the call. 350 User Agents providing ToIP functionality need to provide suitable 351 alerting indications, specifically offering visual and/or tactile 352 alerting for deaf and hard of hearing users. 354 The ability of SIP to set up conversation sessions from any 355 location, as well as its privacy and security provisions, MUST be 356 maintained by ToIP services. 358 Where ToIP is used in conjunction with other media, exposure of 359 SIP functions through the User Interface needs to be done in an 360 equivalent manner for all supported media. In other words, where 361 certain SIP call control functions are available for the audio 362 media part of the session, these functions MUST also be supported 363 for the text media part of the same session. For example, call 364 transfer must act on all media in the session. 366 T.140 real-time text conversation [4], in addition to audio and 367 video communications, is a valuable service for many users, 368 including those on non-IP networks. T.140 also provides for real- 369 time editing of the text. 371 A. van Wijk, et al. Expires 6 March 2006 [Page 7 of 28] 372 5.1.1 General ToIP Summary 374 The general requirements for ToIP are: 376 a. Session setup, modification and teardown procedures for point- 377 to-point and multimedia calls 379 b. Registration procedures and address resolutions 381 c. Registration of user preferences 383 d. Negotiation procedures for device capabilities 385 e. Support of text media transport using T.140 over RTP as 386 described in RFC 4103 [5] 388 f. Signaling of status information, call progress and the like in 389 a suitable manner, bearing in mind that the user may have a 390 hearing impairment 392 g. T.140 real-time text presentation mixing with voice and video 394 h. T.140 real-time text conversation sessions using SIP, allowing 395 users to move from one place to another 397 i. User privacy and security for sessions setup, modification, and 398 teardown as well as for media transfer 400 j. Routing of emergency calls according to national or regional 401 policy with the same level of functionality as a voice call. 403 5.2. General Requirements for ToIP Interworking 405 This section describes the general ToIP interworking requirements 406 and gives some background information to many of the issues. 408 There is a range of existing text services. There is also a range 409 of network technologies that could support text services (see 410 examples below). ToIP needs to provide interoperability with text 411 conversation features in other networks, for instance the PSTN, 412 and with some text messaging services. 414 Text gateways are used for converting between different media 415 types. They could be used between networks or within networks 416 where different transport technologies are used. 418 When communicating via a gateway to other networks and protocols, 419 the ToIP service SHOULD support the functionality for alternating 420 or simultaneous use of modalities as offered by the destination 421 network. 423 A. van Wijk, et al. Expires 6 March 2006 [Page 8 of 28] 424 Address information, both called and calling, SHOULD be 425 transferred, and possibly converted, when interworking between 426 different networks. 428 ToIP will often be used to access a relay service [I], allowing 429 text users to communicate with voice users. With relay services, 430 it is crucial that text characters are sent as soon as possible 431 after they are entered. While buffering may be done to improve 432 efficiency, the delays SHOULD be kept minimal. In particular, 433 buffering of whole lines of text will not meet character delay 434 requirements. 436 If the User Agents of different participants indicate that there 437 is an incompatibility between their capabilities to support 438 certain media types, e.g. one terminal only offering T.140 over IP 439 as described in RFC4103 [5] and the other one only supporting 440 audio, the user might want to invoke a transcoding service. 442 Examples of possible scenarios for including a relay service in 443 the conversation are: speech-to-text (STT), text-to-speech (TTS), 444 text bridging after conversion from speech, audio bridging after 445 conversion from text, etc. 447 The general requirements for ToIP Interworking are: 449 a. Interoperability between T.140 conversations [4] and analog 450 text telephones 452 b. Discovery and invocation of transcoding/translation services 453 between the media in the call 455 c. Different session establishment models for transcoding / 456 translation services invocation: Third party call control and 457 conference bridge model 459 d. Uniqueness in media mapping to be used in the session for 460 conversion from one media to another by the transcoding / 461 translation server for each communicating party 463 e. Media bridging services for T.140 real-time text, as described 464 in RFC4103 [5], audio and video for multipoint communications 466 f. Transparent session setup, modification, and teardown between 467 text conversation capable devices and voice/video capable 468 devices 470 g. Buffering of text when interworking with media that transport 471 text at different rates. 473 5.2.1 PSTN Interworking 475 Analog text telephony is cumbersome because of incompatible 476 national implementations where interworking was never considered. 478 A. van Wijk, et al. Expires 6 March 2006 [Page 9 of 28] 479 A large number of these implementations have been documented in 480 ITU-T V.18 [10], which also defines the modem detection sequences 481 for the different text protocols. The modem type identification 482 may in rare cases take considerable time depending on user 483 actions. 485 To resolve analog textphone incompatibilities, text telephone 486 gateways are needed to transcode incoming analog signals into 487 T.140 and vice versa. The modem capability exchange time can be 488 reduced by the text telephone gateways initially assuming the 489 analog text telephone protocol used in the region where the 490 gateway is located. For example, in the USA, Baudot [III] might be 491 tried as the initial protocol. If negotiation for Baudot fails, 492 the full V.18 modem capability exchange will take place. In the 493 UK, ITU-T V.21 [II] might be the first choice. 495 5.2.2 Cellular circuit switched Text-Telephony 497 Cellular wireless (or Mobile) circuit switched connections provide 498 a digital real-time transport service for voice or data. The 499 access technologies include GSM, CDMA, TDMA, iDen and various 3G 500 technologies. 502 Alternative means of transferring the Text telephony data have 503 been developed when TTY services over cellular was mandated by the 504 FCC in the USA. They are a) "No-gain" codec solution, b) the 505 Cellular Text Telephony Modem (CTM) solution and c) "Baudot mode" 506 solution. 508 The GSM and 3G standards from 3GPP make use of the CTM modem in 509 the voice channel for text telephony. However, implementations 510 also exist that use the data channel to provide such 511 functionality. Interworking with these solutions SHOULD be done 512 using text gateways that set up the data channel connection at the 513 GSM side and provide ToIP at the other side. 515 5.2.2.1 Cellular "No-gain" 517 The "No-gain" text telephone transporting technology uses 518 specially modified EFR [13] and EVR [14] speech vocoders in mobile 519 terminals used to provide a text telephony call. It provides full 520 duplex operation and supports alternating voice and text 521 ("VCO/HCO"). It is dedicated to CDMA and TDMA mobile technologies 522 and the US Baudot (i.e. 45 bit/s) type of text telephones. 524 5.2.2.2 Cellular Text Telephone Modem (CTM) 526 CTM [15] is a technology independent modem technology that 527 provides the transport of text telephone characters at up to 10 528 characters/sec using modem signals that can be carried by many 529 voice codecs and uses a highly redundant encoding technique to 530 overcome the fading and cell changing losses. 532 A. van Wijk, et al. Expires 6 March 2006 [Page 10 of 28] 533 5.2.2.3 Cellular "Baudot mode" 535 This term is often used by cellular terminal suppliers for a GSM 536 cellular phone mode that allows TTYs to operate into a cellular 537 phone and to communicate with a fixed line TTY. 539 5.2.3 Cellular data channel mode 541 Many mobile terminals allow the use of the data channel to 542 transfer data in real-time. Data rates of 9600 bit/s are usually 543 supported on the mobile network. Gateways provide interoperability 544 with PSTN textphones. 546 5.2.4 Cellular Wireless ToIP 548 ToIP could be supported over cellular wireless packet switched 549 services that interface to the Internet. For 3GPP 3G services, the 550 support is described to use ToIP in 3G TS 26.235 [18]. Low data 551 rates and additional delays can affect performance. 553 5.2.5 Instant Messaging Support 555 Many people use Instant Messaging to communicate via the Internet 556 using text. Instant Messaging transfers blocks of text rather than 557 streaming as is used by ToIP. As such, it is not a replacement for 558 ToIP and in particular does not meet the needs for real time 559 conversations including those of deaf, hard of hearing and speech- 560 impaired users as defined in RFC 3351 [19]. It is unsuitable for 561 communications through a relay service [I]. The streaming nature 562 of ToIP provides a more direct conversational user experience and, 563 when given the choice, users may prefer ToIP. 565 Text gateways could be developed to allow interworking between 566 Instant Messaging systems and ToIP solutions. 568 6. Detailed requirements for ToIP 570 A ToIP user may wish to call another ToIP user, or join a 571 conference session involving several users or initiate or join a 572 multimedia session, such as a Total Conversation session. 574 There may be some need for pre-session setup e.g. storing of 575 registration information in the SIP registrar, to provide 576 information about how a user can be contacted. This will allow 577 sessions to be set up rapidly and with proper routing and 578 addressing. 580 Similarly, there are requirements that need to be satisfied during 581 session set up when other media are preferred by a user. For 582 instance, some users may indicate their preferred modality to be 583 audio while others may indicate text. In this case, transcoding 584 services might be needed for text-to-speech (TTS) and speech-to- 586 A. van Wijk, et al. Expires 6 March 2006 [Page 11 of 28] 587 text (STT). The requirements for transcoding services need to be 588 negotiated in real-time to set up the session. 590 The subsequent subsections describe some of these requirements in 591 detail. 593 6.1. Pre-Session Requirements 595 The need to use text as a medium of communications can be 596 expressed by users during registration time. Two situations need 597 to be considered in the pre-session setup environment: 599 a. User Preferences: It MUST be possible for a user to indicate a 600 preference for text by registering that preference with a SIP 601 server that is part of the ToIP service. 603 b. Server to support User Preferences: SIP servers that support 604 ToIP services MUST have the capability to act on calling user 605 preferences for text in order to accept or reject the session-, 606 based on the called user�s preferences defined as part of the 607 pre-session setup registration. For example, if the user is 608 called by another party, and it is determined that a 609 transcoding server is needed, the session MUST be re-directed 610 or otherwise handled accordingly. 612 6.2 Basic Point-to-Point Session Requirements 614 A point-to-point session takes place between two parties. The 615 requirements are described in subsequent sub-sections. They assume 616 that one or both of the communicating parties will indicate text 617 as a possible or preferred medium for conversation using SIP in 618 the session setup. 620 6.2.1 Session control 622 ToIP services MUST use the Session Initiation Protocol (SIP) [3] 623 for setting up, controlling and terminating sessions for real-time 624 text conversation with one or more participants and possibly 625 including other media like video or audio. The session description 626 protocol (SDP) [6] used in SIP to describe the session is used to 627 express the attributes of the session and to negotiate a set of 628 compatible media types. 630 6.2.2 Text transport 632 A ToIP service MUST always support at least one Text media type. 634 ToIP services MUST support the Real-Time Transport Protocol (RTP) 635 [24] according to the specification of RFC4103 [5] for the 636 transport of text between participants. 638 RFC4103 describes the transmission of T.140 [4] on IP networks. 640 A. van Wijk, et al. Expires 6 March 2006 [Page 12 of 28] 641 6.2.3 Session Setup 643 Users will set up a session by identifying the remote party or the 644 service they want to connect to. However, conversations could be 645 started using a mode other than text. For instance, the 646 conversation might be established using audio and the user could 647 subsequently elect to switch to text, or add text as an additional 648 modality, during the conversation. Systems supporting ToIP MUST 649 allow users to select any of the supported conversation modes at 650 any time, including mid-conversation. 652 Systems SHOULD allow the user to specify a preferred mode of 653 communication, with the ability to fall back to alternatives that 654 the user has indicated are acceptable. 656 If the user requests simultaneous use of text and audio, and this 657 is not possible either because the system only supports alternate 658 modalities or because of constraints in the network, the system 659 MUST try to establish communication with best effort. If the user 660 has expressed a preference for text, establishment of a connection 661 including text MUST have priority over other outcomes of the 662 session setup. 664 The following features MAY be implemented to facilitate the 665 session establishment using ToIP: 667 a. Caller Preferences: SIP headers (e.g., Contact)[24] can be used 668 to show that ToIP is the medium of choice for communications. 670 b. Called Party Preferences: The called party being passive can 671 formulate a clear rule indicating how a session should be 672 handled either using text as a preferred medium or not, and 673 whether a designated SIP proxy needs to handle this session or 674 it will be handled in the SIP user agent. 676 c. SIP Server support for User Preferences: SIP servers can also 677 handle the incoming sessions in accordance with preferences 678 expressed for ToIP. The SIP Server can also enforce ToIP policy 679 rules for communications (e.g. use of the transcoding server 680 for ToIP). 682 6.2.4 Addressing 684 The SIP [3] addressing schemes MUST be used for all entities in a 685 ToIP session. For example, SIP URL�s or Tel URL�s are used for 686 caller, called party, user devices, and servers (e.g., SIP server, 687 Transcoding server). 689 The right to include a transcoding service MUST NOT require user 690 registration in any specific SIP registrar, but MAY require 691 authorisation of the SIP registrar to invoke the service. 693 A. van Wijk, et al. Expires 6 March 2006 [Page 13 of 28] 694 6.2.5 Alerting 696 User Agents supporting ToIP MUST have an alerting method (e.g., 697 for incoming sessions) that can be used by deaf and hard of 698 hearing people or provide a range of alternative, but equivalent, 699 alerting methods that can be selected by all users, regardless of 700 their abilities. 702 It should be noted that external alerting systems exist and one 703 common interface for triggering the alerting action is a contact 704 closure between two conductors. 706 Among the alerting options are alerting by the User Agent�s User 707 Interface and specific alerting user agents registered to the same 708 registrar as the main user agent. 710 6.2.6 Session information 712 If present, identification of the originating party (for example 713 in the form of a URL or a CLI) MUST be clearly presented to the 714 user in a form suitable for the user BEFORE the session invitation 715 is answered. When a session invitation involving ToIP originates 716 from a gateway, this MAY be signaled to the user. 718 The user MUST be informed of any change in modalities. 720 6.2.7 Session progress information 722 During a conversation that includes ToIP, status and session 723 progress information MUST be provided in a textual form so users 724 can perform all session control functions. That information MUST 725 be equivalent to session progress information delivered in any 726 other format, for example audio. 728 Session progress information SHOULD use simple language so that as 729 many users as possible can understand it. The use of jargon or 730 ambiguous terminology SHOULD be avoided. It is RECOMMENDED that 731 text information be used together with icons to symbolise the 732 session progress information. 734 There MUST be a clear indication, in a modality useful to the 735 user, whenever a session is connected or disconnected. A user 736 SHOULD never be in doubt about the status of the session, even if 737 the user is unable to make use of the audio or visual indication. 738 For example, tactile indications could be used by deafblind 739 individuals. 741 In summary, it SHOULD be possible to observe indicators about: 742 - Incoming session 743 - Availability of text, voice and video channels 744 - Session progress 745 - Incoming text 746 - Any loss in incoming text 748 A. van Wijk, et al. Expires 6 March 2006 [Page 14 of 28] 749 - Typed and transmitted text. 751 For users who cannot use the audible alerter for incoming 752 sessions, it is RECOMMENDED to include a tactile as well as a 753 visual indicator. 755 6.2.8 Session Negotiations 757 The Session Description Protocol (SDP) used in SIP [3] provides 758 the capabilities to indicate text as a medium in the session 759 setup. RFC 4103 [5] uses the RTP payload type "text/t140" for 760 support of ToIP which can be indicated in the SDP as a part of the 761 SIP INVITE, OK and SIP/200/ACK media negotiations. In addition, 762 SIP�s offer/answer model [20] can also be used in conjunction with 763 other capabilities including the use of a transcoding server for 764 enhanced session negotiations [7,8,9]. 766 6.2.9 Answering 768 Systems SHOULD provide a best-effort approach to answering 769 invitations for session set-up and users SHOULD be informed when 770 the session is accepted by the other party. On all systems that 771 both inform users of session status and support ToIP, this 772 information MUST be available in textual form and MAY also be 773 provided in other media. 775 6.2.9.1 Answering Machine 777 Systems for ToIP MAY support an auto-answer function, equivalent 778 to answering machines on telephony networks. If an answering 779 machine function is supported, it MUST support at least 160 780 characters for the greeting message. It MUST support incoming text 781 message storage of a minimum of 4096 characters, although systems 782 MAY support much larger storage. It is RECOMMENDED that systems 783 support storage of at least 20 incoming messages of up to 16000 784 characters per message. 786 When the answering machine is activated, user alerting SHOULD 787 still take place. The user SHOULD be allowed to monitor the auto- 788 answer progress and where this is provided the user SHOULD be 789 allowed to intervene during any stage of the answering machine 790 procedure and take control of the session. 792 6.2.10 Actions During a Session 794 Certain actions need to be performed during ToIP conversation: 796 a. Text transmission from a terminal SHALL be performed character 797 by character as entered, or in small groups of characters, so 798 that no character is delayed from entry to transmission by more 799 than 300 milliseconds. 801 A. van Wijk, et al. Expires 6 March 2006 [Page 15 of 28] 802 b. The text transmission SHALL allow a rate of at least 30 803 characters per second so that human typing speed as well as 804 speech to text methods of generating conversation text can be 805 supported. 807 c. To enable the use of international character sets, the 808 transmission format for text conversation SHALL be UTF-8 [12], 809 in accordance with ITU-T T.140. 811 d. If text is detected to be missing after transmission, there 812 SHOULD be a "text loss" indication in the text as specified in 813 T.140 Addendum 1 [4]. 815 e. When the display of text conversation is included in the design 816 of the end user equipment, the display of the dialogue SHOULD 817 be made so that it is easy to differentiate the text belonging 818 to each party in the conversation. 820 6.2.10.1 Text Transport 822 ToIP uses RTP as the default transport protocol for the 823 transmission of real-time text via the medium "text/t140" as 824 specified in RFC 4103 [5]. 826 The redundancy method of RFC 4103 [5] SHOULD be used to 827 significantly increase the reliability of the text transmission. A 828 redundancy level using 2 generations gives very reliable results 829 and is therefore RECOMMENDED. 831 Text capability MUST be announced in SDP by a declaration similar 832 to this example: 834 m=text 11000 RTP/AVP 98 100 835 a=rtpmap:98 t140/1000 836 a=rtpmap:100 red/1000 837 a=fmtp:100 98/98/98 839 By having this single coding and transmission scheme for real time 840 text defined in the SIP session control environment, the 841 opportunity for interoperability is optimized. However, if good 842 reasons exist, other transport mechanisms MAY be offered and used 843 for the T.140 coded text provided that proper negotiation is 844 introduced, but RFC 4103 [5] transport MUST be used as both the 845 default and the fallback transport. 847 6.2.10.2 Handling Text and other Media. 849 A call is one or more related sessions. The following requirements 850 apply to media handling during a call: 852 a. When used between User Agents designed for ToIP, it SHALL be 853 possible to send and receive text simultaneously. 855 A. van Wijk, et al. Expires 6 March 2006 [Page 16 of 28] 856 b. When used between User Agents that support ToIP, it SHALL be 857 possible to send and receive text simultaneously with the other 858 media (text, audio and/or video) supported by the same 859 terminals. 861 c. It SHOULD be possible to know during a call that ToIP is 862 available, even if it is not invoked at call setup (e.g. when 863 only voice and/or video is used initially). To disable this, 864 the user MUST disable the use of ToIP. This is possible during 865 registration at the SIP registrar. 867 6.2.11 Additional session control 869 Systems that support additional session control features, for 870 example call waiting, forwarding, hold etc on voice sessions, MUST 871 offer this functionality for text sessions. 873 6.2.12 File storage 875 Systems that support ToIP MAY save the text conversation to a 876 file. This SHOULD be done using a standard file format. For 877 example: a UTF8 text file in XML format [11] including timestamps, 878 party names (or addresses) and the text conversation. 880 6.3 Conference Session Requirements 882 The conference session requirements deal with multipoint 883 conferencing sessions where there will be one or more ToIP capable 884 devices and/or other end user devices where the total number of 885 end user devices will be at least three. 887 It SHOULD be possible to use the text medium in conference 888 sessions in a similar way to how audio is handled and video is 889 displayed. Text in conferences can be used both for letting 890 individual participants use the text medium (for example, for 891 sidebar discussions in text while listening to the main conference 892 audio), as well as for central support of the conference with real 893 time text interpretation of speech. 895 6.4 Real-time Editing and User Alerting 897 ToIP SHOULD handle characters such as new line, erasure and 898 alerting during a session as specified in ITU-T T.140. 900 6.5 Emergency services 902 It MUST be possible to place an emergency call using ToIP and it 903 MUST be possible to use a relay service in such call. The 904 emergency service provided to users utilising the text medium MUST 905 be equivalent to the emergency service provided to users utilising 906 speech or other media. 908 A. van Wijk, et al. Expires 6 March 2006 [Page 17 of 28] 909 6.6 User Mobility 911 ToIP User Agents SHOULD use the same mechanisms as other SIP User 912 Agents to resolve mobility issues. It is RECOMMENDED that users 913 use a SIP-address, resolved by a SIP registrar, to enable basic 914 user mobility. Further mechanisms are defined for all session 915 types for 3G IP multimedia systems. 917 6.7 Firewalls and NATs 919 ToIP uses the same signaling and transport protocols as VoIP 920 hence, the same firewall and NAT solutions and network 921 functionality that apply to VoIP MUST also apply to ToIP. 923 7. Interworking Requirements for ToIP 925 A number of systems for real time text conversation already exist 926 as well as a number of message oriented text communication 927 systems. Interoperability is of interest between ToIP and some of 928 these systems. This section describes the interoperability 929 requirements, especially for PSTN text telephony, to ensure full 930 backward interoperability with ToIP. 932 7.1 ToIP Interworking Gateway Services 934 Interactive texting facilities exist already in various forms and 935 on various networks. On the PSTN, it is commonly referred to as 936 text telephony. 938 Simultaneous or alternating use of voice and text is used by a 939 large number of users who can send voice but must receive text 940 (due to a hearing impairment), or who can hear but must send text 941 (due to a speech impairment). 943 Session setup through gateways to other networks MAY require the 944 use of specially formatted addresses or other mechanisms for 945 invoking those gateways. 947 Different data rates of different protocols MAY require text 948 buffering. 950 Transcoding of text to and from other coding formats MAY need to 951 take place in gateways between ToIP and other forms of text 952 conversation, for example to connect to a PSTN text telephone. 954 7.2 ToIP and PSTN/ISDN Text-Telephony Interworking 956 On PSTN networks, transmission of interactive text takes place 957 using a variety of codings and modulations, including ITU-T V.21 958 [II], Baudot [III], DTMF, V.23 [IV] and others. Many difficulties 959 have arisen as a result of this variety in text telephony 960 protocols and the ITU-T V.18 [10] standard was developed to 961 address some of these issues. 963 A. van Wijk, et al. Expires 6 March 2006 [Page 18 of 28] 964 ITU-T V.18 [10] offers a native text telephony method plus it 965 defines interworking with current protocols. In the interworking 966 mode, it will recognise one of the older protocols and fall back 967 to that transmission method when required. 969 V.18 MUST be supported on the PSTN side of a PSTN-ToIP gateway. 971 PSTN-ToIP gateways MUST allow alternating use of text and voice if 972 the PSTN textphone involved at the PSTN side of the session 973 supports this. (This mode is often called VCO/HCO). 975 Calling party identification information, such as CLI, MUST be 976 passed by gateways and converted to an approapriate form if 977 required. 979 7.3 ToIP and Cellular Wireless ToIP 981 ToIP MAY be supported over the cellular wireless packet switched 982 service. It interfaces to the Internet. 984 A text gateway with cellular wireless packet switched services 985 MUST be able to route text calls to emergency service providers 986 when any of the recognized emergency numbers that support text 987 communication for the country. 989 7.4 Instant Messaging Support 991 Text gateways MAY be developed to allow interworking between 992 Instant Messaging systems and ToIP solutions. Because Instant 993 Messaging is based on blocks of text, rather than on a continuous 994 stream of characters, gateways MUST transcode between the two 995 formats. Text gateways for interworking between Instant Messaging 996 and ToIP MUST concatenate individual characters originating at the 997 ToIP side into blocks of text and: 999 a. When the length of the concatenated message becomes longer than 1000 50 characters, the buffered text SHOULD be transmitted to the 1001 Instant Messaging side as soon as any non-alphanumerical 1002 character is received from the ToIP side. 1004 b. When a new line indicator is received from the ToIP side, the 1005 buffered characters up to that point, including the carriage 1006 return and/or line feed characters, SHOULD be transmitted to 1007 the Instant Messaging side. 1009 c. When the ToIP side has been idle for at least 5 seconds, all 1010 buffered text up to that point SHOULD be transmitted to the 1011 Instant Messaging side. 1013 It is RECOMMENDED that during the session, both users are 1014 constantly updated on the progress of the text input. 1016 A. van Wijk, et al. Expires 6 March 2006 [Page 19 of 28] 1017 Many Instant Messaging protocols signal that a user is typing to 1018 the other party in the conversation. Text gateways between such 1019 Instant Messaging protocols and ToIP MUST provide this signaling 1020 to the Instant Messaging side when characters start being 1021 received, or at the beginning of the conversation. 1023 At the ToIP side, an indicator of writing the Instant Message MUST 1024 be present where the Instant Messaging protocol provides one. For 1025 example, the real-time text user MAY see ". . . waiting for 1026 replying IM. . . " and when 5 seconds have passed another . (dot) 1027 can be shown. 1029 Those solutions will reduce the difficulties between streaming and 1030 blocked text services. 1032 Even though the text gateway can connect Instant Messaging and 1033 ToIP, the best solution is to take advantage of the fact that the 1034 user interfaces and the user communities for instant messaging and 1035 ToIP telephony are very similar. After all, the character input, 1036 the character display, Internet connectivity and SIP stack are the 1037 same for Instant Messaging (SIMPLE) and ToIP. 1039 Devices that implement Instant Messaging SHOULD implement ToIP as 1040 described in this document so that a more complete text 1041 communication service can be provided. 1043 7.5 Common Text Gateway Functions 1045 Text gateways MUST allow for the differences that result from 1046 different text protocols. The protocols to be supported will 1047 depend on the service requirements of the Gateway. 1049 7.5.1 Protocol support 1051 Text gateways MUST use the ITU-T V.18 [10] standard at the PSTN 1052 side. A text gateway MUST act as a SIP User Agent on the IP side 1053 and support RFC4103 text transport. 1055 7.5.2 Relay buffer storage 1057 When text gateway functions are invoked, there will be a need for 1058 intermediate storage of characters before transmission to a device 1059 receiving text slower than the transmitting speed of the sender. 1060 Such temporary storage SHALL be dimensioned to adjust for 1061 receiving at 30 characters per second and transmitting at 6 1062 characters per second for up to 4 minutes (i.e. less than 3k 1063 characters). 1065 Interoperation of half-duplex and full-duplex protocols MAY 1066 require text buffering. Some intelligence will be needed to 1067 determine when to change direction when operating in half-duplex 1068 mode. Identification may be required of half-duplex operation 1069 either at the "user" level (ie. users must inform each other) or 1071 A. van Wijk, et al. Expires 6 March 2006 [Page 20 of 28] 1072 at the "protocol" level (where an indication must be sent back to 1073 the Gateway). 1075 7.5.3 Emergency calls through gateways 1077 A text gateway MUST be able to route text calls to emergency 1078 service providers when any of the recognised emergency numbers 1079 that support text communications for the country or region are 1080 called e.g. "911" in USA and "112" in Europe. Routing text calls 1081 to emergency services MAY require the use of a transcoding 1082 service. 1084 7.5.4 Text Gateway Invocation 1086 ToIP interworking requires a method to invoke a text gateway. As 1087 described previously in this draft, these text gateways MUST act 1088 as User Agents at the IP side. The capabilities of the text 1089 gateway during the call will be determined by the call 1090 capabilities of the terminal that is using the gateway. For 1091 example, a PSTN textphone is generally only able to receive voice 1092 and streaming text, so the text gateway will only allow ToIP and 1093 audio. 1095 Examples of possible scenarios for invocation of the text gateway 1096 are: 1098 a. PSTN textphone users dial a prefix number before dialing out. 1099 b. Separate text subscriptions, linked to the phone number or 1100 terminal identifier/ IP address. 1101 c. Text capability indicators. 1102 d. Text preference indicator. 1103 e. Listen for V.18 modem modulation text activity in all PSTN 1104 calls and routing of the call to an appropriate gateway. 1105 f. Call transfer request by the called user. 1106 g. Placing a call via the web, and using one of the methods 1107 described here 1108 h. Text gateways with its own telephone number and/or SIP address. 1109 (This requires user interaction with the text gateway to place 1110 a call). 1111 i. ENUM address analysis and number plan 1112 j. Number or address analysis leads to a gateway for all PSTN 1113 calls. 1115 7.6 Home Gateways or Analog Terminal Adapters 1117 Analog terminal adapters (ATAs) using SIP based IP communication 1118 and RJ-11 connectors for connecting traditional PSTN devices 1119 SHOULD enable connection of legacy PSTN text telephones [16]. 1121 These adapters SHOULD contain V.18 modem functionality, voice 1122 handling functionality, and conversion functions to/from SIP based 1123 ToIP with T.140 transported according to RFC 4103 [5], in a 1124 similar way as it provides interoperability for voice sessions. 1126 A. van Wijk, et al. Expires 6 March 2006 [Page 21 of 28] 1127 If a session is set up and text/t140 capability is not declared by 1128 the destination endpoint (by the end-point terminal or the text 1129 gateway in the network at the end-point), a method for invoking a 1130 transcoding server SHALL be used. If no such server is available, 1131 the signals from the textphone MAY be transmitted in the voice 1132 channel as audio with high quality of service. 1134 NOTE: It is preferred that such analog terminal adaptors do use 1135 RFC 4103 [5] on board and thus act as a text gateway. Sending 1136 textphone signals over the voice channel is undesirable due to 1137 possible filtering and compression and packet loss between the 1138 end-points. This can result in character loss in the textphone 1139 conversation or even not allowing the textphones to connect to 1140 each other. 1142 7.7 Multi-functional Combination gateways 1144 In practice many interworking gateways will be implemented as 1145 gateways that combine different functions. As such, a text gateway 1146 could be built to have modems to interwork with the PSTN and 1147 support both Instant Messaging as well as ToIP. Such interworking 1148 functions are called Combination gateways. 1150 Combination gateways MUST provide interworking between all of 1151 their supported text based functions. For example, a text gateway 1152 that has modems to interwork with the PSTN and that support both 1153 Instant Messaging and real-time ToIP MUST support the following 1154 interworking functions: 1156 - PSTN text telephony to real-time ToIP. 1157 - PSTN text telephony to Instant Messaging. 1158 - Instant Messaging to real-time ToIP. 1160 7.8 Transcoding 1162 Gateways between the ToIP network and other networks MAY need to 1163 transcode text streams. ToIP makes use of the ISO 10646 character 1164 set. Most PSTN textphones use a 7-bit character set, or a 1165 character set that is converted to a 7-bit character set by the 1166 V.18 modem. 1168 When transcoding between character sets and T.140 in gateways, 1169 special consideration MUST be given to the national variants of 1170 the 7 bit codes, with national characters mapping into different 1171 codes in the ISO 10646 code space. The national variant to be used 1172 could be selectable by the user on a per call basis, or be 1173 configured as a national default for the gateway. 1175 The indicator of missing text in T.140, specified in T.140 1176 amendment 1, cannot be represented in the 7 bit character codes. 1177 Therefore the indicator of missing text SHOULD be transcoded to 1178 the ' (apostrophe) character in legacy text telephone systems, 1180 A. van Wijk, et al. Expires 6 March 2006 [Page 22 of 28] 1181 where this character exists. For legacy systems where the 1182 character ' does not exist, the . ( full stop ) character SHOULD 1183 be used instead. 1185 7.9 Relay Services 1187 The relay service acts as an intermediary between two or more 1188 callers using different media or different media encoding schemes. 1190 7.9.1 Basic function of the relay service 1192 The basic text relay service allows a translation of speech to 1193 text and text to speech, which enables hearing and speech impaired 1194 callers to communicate with hearing callers. Even though this 1195 document focuses on ToIP, we want to remind readers that other 1196 relay services exist, like video relay services transcoding speech 1197 to sign language and vice versa where the signing is communicated 1198 using video. 1200 7.9.2 Invocation of relay services 1202 It is RECOMMENDED that ToIP implementations make the invocation 1203 and use of relay services as easy as possible. It MAY happen 1204 automatically when the session is being set up based on any valid 1205 indication or negotiation of supported or preferred media types. A 1206 transcoding framework document using SIP [7] describes invoking 1207 relay services, where the relay acts as a conference bridge or 1208 uses the third party control mechanism. ToIP implementations 1209 SHOULD support this transcoding framework. 1211 Adding or removing a relay service MUST be possible without 1212 disrupting the current session. 1214 When setting up a session, the relay service MUST be able to 1215 determine the type of service requested (e.g., speech to text or 1216 text to speech), to indicate if the caller wants voice carry over, 1217 the language of the text, the sign language being used (in the 1218 video stream), etc. 1220 It SHOULD be possible to route the session to a preferred relay 1221 service even if the user invokes the session from another region 1222 or network than that usually used. 1224 A number of requirements, motivations and implementation 1225 guidelines for relay service invocation can be found in RFC 3351 1226 [19]. 1228 8. Security Considerations 1230 User confidentiality and privacy need to be met as described in 1231 SIP [3]. For example, nothing should reveal the fact that the user 1232 of ToIP is a person with a disability unless the user prefers to 1233 make this information public. If a transcoding server is being 1235 A. van Wijk, et al. Expires 6 March 2006 [Page 23 of 28] 1236 used, this SHOULD be transparent. Encryption SHOULD be used on 1237 end-to-end or hop-by-hop basis as described in SIP [3] and SRTP 1238 [17]. 1240 Authentication needs to be provided for users in addition to the 1241 message integrity and access control. 1243 Protection against Denial-of-service (DoS) attacks needs to be 1244 provided considering the case that the ToIP users might need 1245 transcoding servers. 1247 9. Authors Addresses 1249 The following people provided substantial technical and writing 1250 contributions to this document, listed alphabetically: 1252 Willem P. Dijkstra 1253 TNO Informatie- en Communicatietechnologie 1254 Postbus 15000 1255 9700 CD Groningen 1256 The Netherlands 1257 Tel: +31 50 585 77 24 1258 Fax: +31 50 585 77 57 1259 Email: willem.dijkstra@tno.nl 1261 Barry Dingle 1262 ACIF, 32 Walker Street 1263 North Sydney, NSW 2060 Australia 1264 Tel +61 (0)2 9959 9111 1265 Mob +61 (0)41 911 7578 1266 Email barry.dingle@bigfoot.com.au 1268 Guido Gybels 1269 Department of New Technologies 1270 RNID, 19-23 Featherstone Street 1271 London EC1Y 8SL, UK 1272 Tel +44(0)20 7294 3713 1273 Txt +44(0)20 7296 8019 1274 Fax +44(0)20 7296 8069 1275 Email: guido.gybels@rnid.org.uk 1277 Gunnar Hellstrom 1278 Omnitor AB 1279 Renathvagen 2 1280 SE 121 37 Johanneshov 1281 Sweden 1282 Phone: +46 708 204 288 / +46 8 556 002 03 1283 Fax: +46 8 556 002 06 1284 Email: gunnar.hellstrom@omnitor.se 1286 A. van Wijk, et al. Expires 6 March 2006 [Page 24 of 28] 1287 Radhika R. Roy 1288 SAIC 1289 3465-B Box Hill Corporate Center Drive 1290 Abingdon, MD 21009 1291 Tel: 443 402 9041 1292 Email: Radhika.R.Roy@saic.com 1294 Henry Sinnreich 1295 pulver.com 1296 115 Broadhollow Rd 1297 Suite 225 1298 Melville, NY 11747 1299 USA 1300 Tel: +1.631.961.8950 1302 Gregg C Vanderheiden 1303 University of Wisconsin-Madison 1304 Trace R & D Center 1305 1550 Engineering Dr (Rm 2107) 1306 Madison, Wi 53706 1307 USA 1308 Phone +1 608 262-6966 1309 FAX +1 608 262-8848 1310 Email: gv@trace.wisc.edu 1312 Arnoud A. T. van Wijk 1313 Viataal 1314 Centre for R & D on sensory and communication disabilities. 1315 Theerestraat 42 1316 5271 GD Sint-Michielsgestel 1317 The Netherlands. 1318 Email: a.vwijk@viataal.nl 1320 10. References 1322 10.1 Normative references 1324 1. S. Bradner, "Intellectual Property Rights in IETF Technology 1325 ", BCP 79, RFC 3979, IETF, March 2005. 1327 2. S. Bradner, "Key words for use in RFCs to Indicate Requirement 1328 Levels", BCP 14, RFC 2119, IETF, March 1997 1330 3. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 1331 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session 1332 Initiation Protocol", RFC 3621, IETF, June 2002. 1334 4. ITU-T Recommendation T.140, "Protocol for Multimedia 1335 Application Text Conversation" (February 1998) and Addendum 1 1336 (February 2000). 1338 A. van Wijk, et al. Expires 6 March 2006 [Page 25 of 28] 1339 5. G. Hellstrom, "RTP Payload for Text Conversation", RFC 4103, 1340 IETF, June 2005. 1342 6. G. Camarillo, H. Schulzrinne, and E. Burger, "The Source and 1343 Sink Attributes for the Session Description Protocol," IETF, 1344 August 2003 - Work in Progress. 1346 7. G.Camarillo, "Framework for Transcoding with the Session 1347 Initiation Protocol" IETF June 2005 - Work in progress. 1349 8. G. Camarillo, H. Schulzrinne, E. Burger, and A. van Wijk, 1350 "Transcoding Services Invocation in the Session Initiation 1351 Protocol (SIP) Using Third Party Call Control (3pcc)" RFC 4117, 1352 IETF, June 2005. 1354 9. G. Camarillo, "The SIP Conference Bridge Transcoding Model," 1355 IETF, August 2003 - Work in Progress. 1357 10. ITU-T Recommendation V.18,"Operational and Interworking 1358 Requirements for DCEs operating in Text Telephone Mode," November 1359 2000. 1361 11. "XHTML 1.0: The Extensible HyperText Markup Language: A 1362 Reformulation of HTML 4 in XML 1.0", W3C Recommendation. Available 1363 at http://www.w3.org/TR/xhtml1. 1365 12. Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1366 RFC 2279, IETF, January 1998. 1368 13. TIA/EIA/IS-823-A "TTY/TDD Extension to TIA/EIA-136-410 1369 Enhanced Full Rate Speech Codec (must used in conjunction with 1370 TIA/EIA/IS-840)" 1372 14. TIA/EIA/IS-127-2 "Enhanced Variable Rate Codec, Speech Service 1373 Option 3 for Wideband Spread Spectrum Digital Systems. Addendum 1374 2." 1376 15. 3GPP TS26.226 "Cellular Text Telephone Modem Description" 1377 (CTM). 1379 16. H. Sinnreich, S. Lass, and C. Stredicke, "SIP Telephony 1380 Device Requirements and Configuration," IETF, June 2005 - Work in 1381 Progress. 1383 17. Baugher, McGrew, Carrara, Naslund, Norrman, "The Secure Real 1384 Time Transport Protocol (SRTP)", RFC 3711, IETF, March 2004. 1386 18. "IP Multimedia default codecs". 3GPP TS 26.235 1388 19. Charlton, Gasson, Gybels, Spanner, van Wijk, "User 1389 Requirements for the Session Initiation Protocol (SIP) in Support 1391 A. van Wijk, et al. Expires 6 March 2006 [Page 26 of 28] 1392 of Deaf, Hard of Hearing and Speech-impaired Individuals", RFC 1393 3351, IETF, August 2002. 1395 20. J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the 1396 Session Description Protocol (SDP)", RFC 3624, IETF, June 2002. 1398 21. ITU-T Recommendation F.700,"Framework Recommendation for 1399 Multimedia Services", November 2000. 1401 22. H. Schulzrinne, S.Casner, R. Frederick, V. Jacobsone, "RTP: A 1402 Transport Protocol for Real-Time Applications", RFC 3550, IETF, 1403 July 2003. 1405 23. ITU-T Recommendation F.703,"Multimedia Conversational 1406 Services", November 2000. 1408 24. J. Rosenberg, H. Schulzrinne, P. Kyzivat, "Indicating User 1409 Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 1410 3840, IETF, August 2004 1412 10.2 Informative references 1414 I. A relay service allows the users to transcode between different 1415 modalities or languages. In the context of this document, relay 1416 services will often refer to text relays that transcode text into 1417 voice and vice-versa. See for example http://www.typetalk.org. 1419 II. International Telecommunication Union (ITU), "300 bits per 1420 second duplex modem standardized for use in the general switched 1421 telephone network". ITU-T Recommendation V.21, November 1988. 1423 III. TIA/EIA/825 "A Frequency Shift Keyed Modem for Use on the 1424 Public Switched Telephone Network." (The specification for 45.45 1425 and 50 bit/s TTY modems.) 1427 IV. International Telecommunication Union (ITU), "600/1200-baud 1428 modem standardized for use in the general switched telephone 1429 network. ITU-T Recommendation V.23, November 1988. 1431 Intellectual Property Statement 1433 The IETF takes no position regarding the validity or scope of any 1434 Intellectual Property Rights or other rights that might be claimed 1435 to pertain to the implementation or use of the technology 1436 described in this document or the extent to which any license 1437 under such rights might or might not be available; nor does it 1438 represent that it has made any independent effort to identify any 1439 such rights. Information on the procedures with respect to rights 1440 in RFC documents can be found in BCP 78 and BCP 79. 1442 Copies of IPR disclosures made to the IETF Secretariat and any 1443 assurances of licenses to be made available, or the result of an 1445 A. van Wijk, et al. Expires 6 March 2006 [Page 27 of 28] 1446 attempt made to obtain a general license or permission for the use 1447 of such proprietary rights by implementers or users of this 1448 specification can be obtained from the IETF on-line IPR repository 1449 at http://www.ietf.org/ipr. 1451 The IETF invites any interested party to bring to its attention 1452 any copyrights, patents or patent applications, or other 1453 proprietary rights that may cover technology that may be required 1454 to implement this standard. Please address the information to the 1455 IETF at ietf-ipr@ietf.org. 1456 Disclaimer of Validity 1458 This document and the information contained herein are provided on 1459 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1460 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1461 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1462 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1463 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1464 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1465 PARTICULAR PURPOSE. 1467 Copyright Statement 1469 Copyright (C) The Internet Society (2005). This document is 1470 subject to the rights, licenses and restrictions contained in BCP 1471 78, and except as set forth therein, the authors retain all their 1472 rights. 1474 Acknowledgment 1476 Funding for the RFC Editor function is currently provided by the 1477 Internet Society. 1479 A. van Wijk, et al. Expires 6 March 2006 [Page 28 of 28]