idnits 2.17.1 draft-ietf-sipping-toip-08.txt: 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.1 on line 15. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1360. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1373. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 370: '... R1: It SHOULD be possible to start c...' RFC 2119 keyword, line 373: '... R2: It MUST be possible for the user...' RFC 2119 keyword, line 377: '... supporting ToIP MUST allow users to s...' RFC 2119 keyword, line 381: '... R4: Systems SHOULD allow the user to...' RFC 2119 keyword, line 387: '... system SHOULD try to establish text ...' (97 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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.) -- The document date (October 19, 2007) is 6033 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'I' on line 634 looks like a reference -- Missing reference section? '2' on line 1191 looks like a reference -- Missing reference section? '3' on line 1136 looks like a reference -- Missing reference section? '4' on line 1147 looks like a reference -- Missing reference section? '5' on line 309 looks like a reference -- Missing reference section? '6' on line 165 looks like a reference -- Missing reference section? '21' on line 192 looks like a reference -- Missing reference section? 'V' on line 635 looks like a reference -- Missing reference section? '8' on line 758 looks like a reference -- Missing reference section? '7' on line 981 looks like a reference -- Missing reference section? 'II' on line 1132 looks like a reference -- Missing reference section? '10' on line 716 looks like a reference -- Missing reference section? '11' on line 720 looks like a reference -- Missing reference section? '12' on line 739 looks like a reference -- Missing reference section? 'III' on line 785 looks like a reference -- Missing reference section? 'IV' on line 741 looks like a reference -- Missing reference section? '13' on line 741 looks like a reference -- Missing reference section? '14' on line 754 looks like a reference -- Missing reference section? '15' on line 834 looks like a reference -- Missing reference section? '16' on line 928 looks like a reference -- Missing reference section? 'VI' on line 918 looks like a reference -- Missing reference section? 'VII' on line 918 looks like a reference -- Missing reference section? 'VIII' on line 918 looks like a reference -- Missing reference section? '9' on line 952 looks like a reference -- Missing reference section? '17' on line 973 looks like a reference -- Missing reference section? '18' on line 973 looks like a reference -- Missing reference section? '19' on line 1006 looks like a reference -- Missing reference section? '20' on line 1191 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 34 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING Workgroup A. van Wijk, Editor 2 Internet Draft G. Gybels, Editor 3 Category: Informational October 19, 2007 4 Expires: April 21, 2008 6 Framework for real-time text over IP using the Session Initiation 7 Protocol (SIP) 8 draft-ietf-sipping-toip-08.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware have 14 been or will be disclosed, and any of which he or she becomes aware 15 will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering Task 18 Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 21, 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 This document lists the essential requirements for real-time Text- 41 over-IP (ToIP) and defines a framework for implementation of all 42 required functions based on the Session Initiation Protocol (SIP) and 43 the Real-Time Transport Protocol (RTP). This includes interworking 44 between Text-over-IP and existing text telephony on the PSTN and other 45 networks. 47 Table of Contents 49 1. Introduction....................................................2 50 2. Scope...........................................................3 51 3. Terminology.....................................................3 52 4. Definitions.....................................................4 53 5. Requirements....................................................6 54 5.1 General requirements for ToIP................................6 56 van Wijk, et al. Expires April 21, 2008 [Page 1] 57 5.2 Detailed requirements for ToIP...............................7 58 5.2.1 Session set-up and control requirements..................7 59 5.2.2 Transport requirements...................................8 60 5.2.3 Transcoding service requirements.........................9 61 5.2.4 Presentation and User control requirements..............10 62 5.2.5 Interworking requirements...............................11 63 5.2.5.1 PSTN Interworking requirements......................12 64 5.2.5.2 Cellular Interworking requirements..................12 65 5.2.5.3 Instant Messaging Interworking requirements.........12 66 6. Implementation Framework.......................................13 67 6.1 General implementation framework............................13 68 6.2 Detailed implementation framework...........................13 69 6.2.1 Session control and set-up..............................13 70 6.2.1.1 Pre-session set-up..................................13 71 6.2.1.2 Session Negotiations................................14 72 6.2.2 Transport...............................................15 73 6.2.3 Transcoding services....................................15 74 6.2.4 Presentation and User control functions.................16 75 6.2.4.1 Progress and status information.....................16 76 6.2.4.2 Alerting............................................16 77 6.2.4.3 Text presentation...................................16 78 6.2.4.4 File storage........................................16 79 6.2.5 Interworking functions..................................16 80 6.2.5.1 PSTN Interworking...................................18 81 6.2.5.2 Mobile Interworking.................................19 82 6.2.5.2.1 Cellular "No-gain"..............................19 83 6.2.5.2.2 Cellular Text Telephone Modem (CTM).............19 84 6.2.5.2.3 Cellular "Baudot mode"..........................19 85 6.2.5.2.4 Mobile data channel mode........................20 86 6.2.5.2.5 Mobile ToIP.....................................20 87 6.2.5.3 Instant Messaging Interworking......................20 88 6.2.5.4 Multi-functional Combination gateways...............21 89 6.2.5.5 Character set transcoding...........................21 90 7. Further recommendations for implementers and service providers.22 91 7.1 Access to Emergency services................................22 92 7.2 Home Gateways or Analog Terminal Adapters...................22 93 7.3 User Mobility...............................................23 94 7.4 Firewalls and NATs..........................................23 95 7.5 Quality of Service..........................................23 96 8. IANA Considerations............................................23 97 9. Security Considerations........................................23 98 10. Authors' Addresses.............................................24 99 11. Contributors...................................................24 100 12. References.....................................................24 101 12.1 Normative references........................................24 102 12.2 Informative references......................................26 104 1. Introduction 106 For many years, real-time text has been in use as a medium for 107 conversational, interactive dialogue between users in a similar way 108 to how voice telephony is used. Such interactive text is different 110 van Wijk, et al. Expires April 21, 2008 [Page 2] 111 from messaging and semi-interactive solutions like Instant Messaging 112 in that it offers an equivalent conversational experience to users 113 who cannot, or do not wish to, use voice. It therefore meets a 114 different set of requirements from other text-based solutions already 115 available on IP networks. 117 Traditionally, deaf, hard of hearing and speech-impaired people are 118 amongst the most prolific users of real-time, conversational, 119 text but, because of its interactivity, it is becoming popular amongst 120 mainstream users as well. Real-time text conversation can be combined 121 with other conversational media like video or voice. 123 This document describes how existing IETF protocols can be used to 124 implement a Text-over-IP solution (ToIP). This ToIP framework is 125 specifically designed to be compatible with Voice-over-IP (VoIP), 126 Video-over-IP and Multimedia-over-IP (MoIP) environments. This ToIP 127 framework also builds upon, and is compatible with, the high-level 128 user requirements of deaf, hard of hearing and speech-impaired users 129 as described in RFC3351 [I]. It also meets real-time text 130 requirements of mainstream users. 132 ToIP also offers an IP equivalent of analog text telephony services as 133 used by deaf, hard of hearing, speech-impaired and mainstream users. 135 The Session Initiation Protocol (SIP) [2] is the protocol of choice 136 for control of Multimedia communications and Voice-over-IP (VoIP) in 137 particular. It offers all the necessary control and signalling 138 required for the ToIP framework. 140 The Real-Time Transport Protocol (RTP) [3] is the protocol of choice 141 for real-time data transmission, and its use for real-time text 142 payloads is described in RFC4103 [4]. 144 This document defines a framework for ToIP to be used either by itself 145 or as part of integrated, multi-media services, including Total 146 Conversation [5]. 148 2. Scope 150 This document defines a framework for the implementation of real-time 151 ToIP, either stand-alone or as a part of multimedia services, 152 including Total Conversation [5]. It provides the: 153 a. requirements for real-time text; 154 b. requirements for ToIP interworking; 155 c. description of ToIP implementation using SIP and RTP; 156 d. description of ToIP interworking with other text services. 158 3. Terminology 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 162 "OPTIONAL" in this document are to be interpreted as described in 164 van Wijk, et al. Expires April 21, 2008 [Page 3] 165 RFC 2119 [6] and indicate requirement levels for compliant 166 implementations. 168 4. Definitions 170 Audio bridging: a function of an audio media bridge server, gateway or 171 relay service that sends to each destination the combination of audio 172 from all participants in a conference excluding the participant(s) at 173 that destination. At the RTP level, this is an instance of the mixer 174 function as defined in RFC 3550 [3]. 176 Cellular: a telecommunication network that has wireless access and can 177 support voice and data services over very large geographical areas. 178 Also called Mobile. 180 Full duplex: media is sent independently in both directions. 182 Half duplex: media can only be sent in one direction at a time or, 183 if an attempt to send information in both directions is made, errors 184 may be introduced into the presented media. 186 Interactive text: another term for real-time text, as defined below. 188 Real-time 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. 191 Conversational text is defined in the ITU-T Framework for multimedia 192 services, Recommendation F.700 [21]. 194 Text gateway: a function that transcodes between different forms of 195 text transport methods, e.g., between ToIP in IP networks and Baudot 196 or ITU-T V.21 text telephony in the PSTN. 198 Textphone: also "text telephone". A terminal device that allows end- 199 to-end real-time text communication using analog transmission. A 200 variety of PSTN textphone protocols exists world-wide. A textphone can 201 often be combined with a voice telephone, or include voice 202 communication functions for simultaneous or alternating use of text 203 and voice in a call. 205 Text bridging: a function of the text media bridge server, gateway 206 (including transcoding gateways) or relay service analogous to that of 207 audio bridging as defined above, except that text is the medium of 208 conversation. 210 Text relay service: a third-party or intermediary that enables 211 communications between deaf, hard of hearing and speech-impaired 212 people and voice telephone users by translating between voice and 213 real-time text in a call. 215 Text telephony: analog textphone service. 217 van Wijk, et al. Expires April 21, 2008 [Page 4] 218 Total Conversation: a multimedia service offering real time 219 conversation in video, real-time text and voice according to 220 interoperable standards. All media streams flow in real time. (See 221 ITU-T F.703 "Multimedia conversational services" [5].) 223 Transcoding service: a service provided by a third-party User Agent 224 that transcodes one stream into another. Transcoding can be done by 225 human operators, in an automated manner, or by a combination of both 226 methods. Within this document the term particularly applies to 227 conversion between different types of media. A text relay service is 228 an example of a transcoding service that converts between real-time 229 text and audio. 231 TTY: originally, an abbreviation for "teletype". Often used in North 232 America as an alternative designation for a text telephone or 233 textphone. Also called TDD, Telecommunication Device for the Deaf. 235 Video relay service: a service that enables communications between 236 deaf and hard of hearing people and hearing persons with voice 237 telephones by translating between sign language and spoken language in 238 a call. 240 Acronyms: 242 2G Second generation cellular (mobile) 243 2.5G Enhanced second generation cellular (mobile) 244 3G Third generation cellular (mobile) 245 ATA Analog Telephone Adaptor 246 CDMA Code Division Multiple Access 247 CLI Calling Line Identification 248 CTM Cellular Text Telephone Modem 249 ENUM E.164 number storage in DNS (see RFC3761) 250 GSM Global System for Mobile Communications 251 ISDN Integrated Services Digital Network 252 ITU-T International Telecommunications Union-Telecommunications 253 Standardisation Sector 254 NAT Network Address Translation 255 PSTN Public Switched Telephone Network 256 RTP Real Time Transport Protocol 257 SDP Session Description Protocol 258 SIP Session Initiation Protocol 259 SRTP Secure Real Time Transport Protocol 260 TDD Telecommunication Device for the Deaf 261 TDMA Time Division Multiple Access 262 TTY Analog textphone (Teletypewriter) 263 ToIP Real-time Text over Internet Protocol 264 URI Uniform Resource Identifier 265 UTF-8 Universal Transfer Format-8 266 VCO/HCO Voice Carry Over/Hearing Carry Over 267 VoIP Voice over Internet Protocol 269 van Wijk, et al. Expires April 21, 2008 [Page 5] 270 5. Requirements 272 The framework described in section 6 defines a real-time text-based 273 conversational service that is the text equivalent of voice based 274 telephony. This section describes the requirements that the framework 275 is designed to meet and the functionality it should offer. 277 5.1 General requirements for ToIP 279 Any framework for ToIP must be derived from the requirements of 280 RFC3351 [I]. A basic requirement is that it must provide a 281 standardized way for offering real-time text-based, conversational 282 services that can be used as an equivalent to voice telephony by deaf, 283 hard of hearing speech-impaired and mainstream users. 285 It is important to understand that real-time text conversations are 286 significantly different from other text-based communications like 287 email or Instant Messaging. Real-time text conversations deliver an 288 equivalent mode to voice conversations by providing transmission of 289 text character by character as it is entered, so that the conversation 290 can be followed closely and immediate interaction take place. 292 Store-and-forward systems like email or messaging on mobile networks 293 or non-streaming systems like instant messaging are unable to provide 294 that functionality. In particular, they do not allow for smooth 295 communication through a Text Relay Service. 297 In order to make ToIP the text equivalent of voice services, ToIP 298 needs to offer equivalent features in terms of conversationality to 299 those provided by voice. To achieve that, ToIP needs to: 301 a. offer real-time transport and presentation of the conversation; 302 b. provide simultaneous transmission in both directions; 303 c. support both point-to-point and multipoint communication; 304 d. allow other media, like audio and video, to be used in conjunction 305 with ToIP; 306 e. ensure that the real-time text service is always available. 308 Real-time text is a useful subset of Total Conversation as defined in 309 ITU-T F.703 [5]. Total Conversation allows participants to use 310 multiple modes of communication during the conversation, either at the 311 same time or by switching between modes, e.g., between real-time text 312 and audio. 314 Deaf, hard-of-hearing and mainstream users may invoke ToIP services 315 for many different reasons: 317 - because they are in a noisy environment, e.g., in a machine room of 318 a factory where listening is difficult; 319 - because they are busy with another call and want to participate in 320 two calls at the same time; 322 van Wijk, et al. Expires April 21, 2008 [Page 6] 323 - for implementing text and/or speech recording services (e.g., text 324 documentation/ audio recording) for legal purposes, for clarity or 325 for flexibility; 326 - to overcome language barriers through speech translation and/or 327 transcoding services; 328 - because of hearing loss, deafness or tinnitus as a result of the 329 aging process or for any other reason, creating a need to replace or 330 complement voice with real-time text in conversational sessions. 332 In many of the above examples, real-time text may accompany speech. 333 The text could be displayed side by side, or in a manner similar to 334 subtitling in broadcasting environments, or in any other suitable 335 manner. This could occur with users who are hard of hearing and also 336 for mixed media calls with both hearing and deaf people participating 337 in the call. 339 A ToIP user may wish to call another ToIP user, join a conference 340 session involving several users, or initiate or join a multimedia 341 session, such as a Total Conversation session. 343 A common scenario for multipoint real-time text is conference calling 344 with many participants. Implementers could for example use different 345 colours to render different participants' text, or could create 346 separate windows or rendering areas for each participant. 348 5.2 Detailed requirements for ToIP 350 The following sections list individual requirements for ToIP. Each 351 requirement has been given a unique identifier (R1, R2, etc). Section 352 6 (Implementation Framework) describes how to implement ToIP based on 353 these requirements and using existing protocols and techniques. 355 The requirements are organized under the following headings: 356 - session set-up and session control; 357 - transport; 358 - use of transcoding services; 359 - presentation and user control; 360 - interworking. 362 5.2.1 Session set-up and control requirements 364 Conversations could be started using a mode other than real-time text. 365 Simultaneous or alternating voice and real-time text is used by a 366 large number of people who can send voice but must receive text (due 367 to a hearing impairment), or who can hear but must send text (due to a 368 speech impairment). 370 R1: It SHOULD be possible to start conversations in any mode (real- 371 time text, voice, video) or combination of modes. 373 R2: It MUST be possible for the users to switch to real-time text, or 374 add real-time text as an additional modality, during the conversation. 376 van Wijk, et al. Expires April 21, 2008 [Page 7] 377 R3: Systems supporting ToIP MUST allow users to select any of the 378 supported conversation modes at any time, including in mid- 379 conversation. 381 R4: Systems SHOULD allow the user to specify a preferred mode of 382 communication in each direction, with the ability to fall back to 383 alternatives that the user has indicated are acceptable. 385 R5: If the user requests simultaneous use of real-time text and audio, 386 and this is not possible because of constraints in the network, the 387 system SHOULD try to establish text only communication if that is 388 what the user has specified as his/her preference. 390 R6: If the user has expressed a preference for real-time text, 391 establishment of a connection including real-time text MUST have 392 priority over other outcomes of the session setup. 394 R7: It MUST be possible to use real-time text in conferences both as a 395 medium of discussion between individual participants (for example, for 396 sidebar discussions in real-time text while listening to the main 397 conference audio) and for central support of the conference with 398 real-time text interpretation of speech. 400 R8: Session set up and negotiation of modalities MUST allow users to 401 specify the language of the real-time text to be used. (It is 402 RECOMMENDED that similar functionality be provided for the video part 403 of the conversation, i.e. to specify the sign language being used). 405 R9: Where certain session services are available for the audio media 406 part of a session, these functions MUST also be supported for the 407 real-time text media part of the same session. For example, call 408 transfer must act on all media in the session. 410 5.2.2 Transport requirements 412 ToIP will often be used to access a relay service [V], allowing real- 413 time text users to communicate with voice users. With relay services, 414 as well as in direct user-to-user conversation, it is crucial that 415 text characters are sent as soon as possible after they are entered. 416 While buffering may be done to improve efficiency, the delays SHOULD 417 be kept minimal. In particular, buffering of whole lines of text will 418 not meet character delay requirements. 420 R10: Characters must be transmitted soon after entry of each character 421 so that the maximum delay requirement can be met. An end-to-end delay 422 time of one second is regarded as good, while users note and 423 appreciate shorter delays, down to 300ms. A delay of up to two seconds 424 is possible to use. 426 R11: Real-time text transmission from a terminal SHALL be performed 427 character by character as entered, or in small groups of characters, 429 van Wijk, et al. Expires April 21, 2008 [Page 8] 430 so that no character is delayed from entry to transmission by more 431 than 300 milliseconds. 433 R12: It MUST be possible to transmit characters at a rate sufficient 434 to support fast human typing as well as speech-to-text methods of 435 generating real-time text. A rate of 30 characters per second is 436 regarded as sufficient. 438 R13: A ToIP service MUST be able to deal with international character 439 sets. 441 R14: Where it is possible, loss or corruption of real-time text during 442 transport SHOULD be detected and the user should be informed. 444 R15: Transport of real-time text SHOULD be as robust as possible, so 445 as to minimize loss of characters. 447 R16: It SHOULD be possible to send and receive real-time text 448 simultaneously. 450 5.2.3 Transcoding service requirements 452 If the User Agents of different participants indicate that there is an 453 incompatibility between their capabilities to support certain media 454 types, e.g. one User Agent only offering T.140 over IP as described in 455 RFC4103 [4] and the other one only supporting audio, the user might 456 want to invoke a transcoding service. 458 Some users may indicate their preferred modality to be audio while 459 others may indicate real-time text. In this case, transcoding services 460 might be needed for text-to-speech (TTS) and speech-to-text (STT). 461 Other examples of possible scenarios for including a relay service in 462 the conversation are: text bridging after conversion from speech, 463 audio bridging after conversion from real-time text, etc. 465 A number of requirements, motivations and implementation guidelines 466 for relay service invocation can be found in RFC 3351 [I]. 468 R17: It MUST be possible for users to invoke a transcoding service 469 where such service is available. 471 R18: It MUST be possible for users to indicate their preferred 472 modality (e.g. ToIP). 474 R19: It MUST be possible to negotiate the requirements for transcoding 475 services in real time in the process of setting up a call. 477 R20: It MUST be possible to negotiate the requirements for transcoding 478 services in mid-call, for the immediate addition of those services to 479 the call. 481 van Wijk, et al. Expires April 21, 2008 [Page 9] 482 R21: Communication between the end participants SHOULD continue after 483 the addition or removal of a text relay service, and the effect of the 484 change should be limited in the users' perception to the direct effect 485 of having or not having the transcoding service in the connection. 487 R22: When setting up a session, it MUST be possible for a user to 488 specify the type of relay service requested (e.g., speech to text or 489 text to speech). The specification of a type of relay MUST include a 490 language specifier. 492 R23: It SHOULD be possible to route the session to a preferred relay 493 service even if the user invokes the session from another region or 494 network than that usually used. 496 R24: It is RECOMMENDED that ToIP implementations make the invocation 497 and use of relay services as easy as possible. 499 5.2.4 Presentation and User control requirements 501 A user should never be in doubt about the status of the session, even 502 if the user is unable to make use of the audio or visual indication. 503 For example, tactile indications could be used by deafblind 504 individuals. 506 R25: User Agents for ToIP services MUST have alerting methods (e.g., 507 for incoming sessions) that can be used by deaf and hard of hearing 508 people or provide a range of alternative, but equivalent, alerting 509 methods that can be selected by all users, regardless of their 510 abilities. 512 R26: Where real-time text is used in conjunction with other media, 513 exposure of user control functions through the User Interface needs to 514 be done in an equivalent manner for all supported media. For example, 515 it must be possible for the user to select between audio, visual or 516 tactile prompts, or all must be supplied. 518 R27: If available, identification of the originating party (for 519 example in the form of a URI or a CLI) MUST be clearly presented to 520 the user in a form suitable for the user BEFORE the session invitation 521 is answered. 523 R28: When a session invitation involving ToIP originates from a PSTN 524 text telephone (e.g. transcoded via a text gateway), this SHOULD be 525 indicated to the user. The ToIP client MAY adjust the presentation of 526 the real-time text to the user as a consequence. 528 R29: An indication SHOULD be given to the user when real-time text is 529 available during the call, even if it is not invoked at call setup 530 (e.g. when only voice and/or video is used initially). 532 R30: The user MUST be informed of any change in modalities. 534 R31: Users MUST be presented with appropriate session progress 535 information at all times. 537 R32: Systems for ToIP SHOULD support an answering machine function, 538 equivalent to answering machines on telephony networks. 540 R33: If an answering machine function is supported, it MUST support at 541 least 160 characters for the greeting message. It MUST support 542 incoming text message storage of a minimum of 4096 characters, 543 although systems MAY support much larger storage. It is RECOMMENDED 544 that systems support storage of at least 20 incoming messages of up to 545 16000 characters per message. 547 R34: When the answering machine is activated, user alerting SHOULD 548 still take place. The user SHOULD be allowed to monitor the auto- 549 answer progress and where this is provided the user SHOULD be allowed 550 to intervene during any stage of the answering machine procedure and 551 take control of the session. 553 R35: It SHOULD be possible to save the text portion of a conversation. 555 R36: The presentation of the conversation SHOULD be done in such a way 556 that users can easily identify which party generated any given portion 557 of text. 559 R37: ToIP SHOULD handle characters such as new line, erasure and 560 alerting during a session as specified in ITU-T T.140 [8]. 562 5.2.5 Interworking requirements 564 There is a range of existing real-time text services. There is also a 565 range of network technologies that could support real-time text 566 services. 568 Real-time/interactive texting facilities exist already in various 569 forms and on various networks. In the PSTN, they are commonly referred 570 to as text telephony. 572 Text gateways are used for converting between different protocols for 573 text conversation. They can be used between networks or within 574 networks where different transport technologies are used. 576 R38: ToIP SHOULD provide interoperability with text conversation 577 features in other networks, for instance the PSTN. 579 R39: When communicating via a gateway to other networks and protocols, 580 the ToIP service SHOULD support the functionality for alternating or 581 simultaneous use of modalities as offered by the interworking network. 583 R40: Calling party identification information, such as CLI, MUST be 584 passed by gateways and converted to an appropriate form if required. 586 R41: When interworking with other networks and services, the ToIP 587 service SHOULD provide buffering mechanisms to deal with delays in 588 call setup, differences in transmission speeds and/or to interwork 589 with half duplex services. 591 5.2.5.1 PSTN Interworking requirements 593 Analog text telephony is used in many countries, mainly by deaf, hard 594 of hearing and speech-impaired individuals. 596 R42: ToIP services MUST provide interworking with PSTN legacy text 597 telephony devices. 599 R43: When interworking with PSTN legacy text telephony services, 600 alternating text and voice function MAY be supported. (Called "voice 601 carry over (VCO) and hearing carry over (HCO)"). 603 5.2.5.2 Cellular Interworking requirements 605 As mobile communications have been adopted widely, various solutions 606 for real-time texting while on the move were developed. ToIP services 607 should provide interworking with such services as well. 609 Alternative means of transferring the Text telephony data have been 610 developed when TTY services over cellular were mandated by the FCC in 611 the USA. They are the a) "No-gain" codec solution, and b) the Cellular 612 Text Telephony Modem (CTM) solution [7] both collectively called 613 "Baudot mode" solution in the USA. 615 The GSM and 3G standards from 3GPP make use of the CTM modem in the 616 voice channel for text telephony. However, implementations also exist 617 that use the data channel to provide such functionality. Interworking 618 with these solutions should be done using text gateways that set up 619 the data channel connection at the GSM side and provide ToIP at the 620 other side. 622 R44: a ToIP service SHOULD provide interworking with mobile text 623 conversation services. 625 5.2.5.3 Instant Messaging Interworking requirements 627 Many people use Instant Messaging to communicate via the Internet 628 using text. Instant Messaging usually transfers blocks of text rather 629 than streaming as is used by ToIP. Usually a specific action is 630 required by the user to activate transmission, such as pressing the 631 ENTER key or a send button. As such, it is not a replacement for ToIP 632 and in particular does not meet the needs for real time conversations 633 including those of deaf, hard of hearing and speech-impaired users as 634 defined in RFC 3351 [I]. It is less suitable for communications 635 through a relay service [V]. 637 The streaming nature of ToIP provides a more direct conversational 638 user experience and, when given the choice, users may prefer ToIP. 640 R45: a ToIP service MAY provide interworking with Instant Messaging 641 services. 643 6. Implementation Framework 645 This section describes an implementation framework for ToIP that meets 646 the requirements and offers the functionality as set out in section 5. 647 The framework presented here uses existing standards that are already 648 commonly used for voice based conversational services on IP networks. 650 6.1 General implementation framework 652 This framework specifies the use of the Session Initiation Protocol 653 (SIP) [2] to set up, control and tear down the connections between 654 ToIP users whilst the media is transported using the Real-Time 655 Transport Protocol (RTP) [3] as described in RFC 4103 [4]. 657 RFC 4504 describes how to implement support for real-time text in SIP 658 telephony devices [II]. 660 6.2 Detailed implementation framework 662 6.2.1 Session control and set-up 664 ToIP services MUST use the Session Initiation Protocol (SIP) [2] for 665 setting up, controlling and terminating sessions for real-time text 666 conversation with one or more participants and possibly including 667 other media like video or audio. The Session Description Protocol 668 (SDP) used in SIP to describe the session is used to express the 669 attributes of the session and to negotiate a set of compatible media 670 types. 672 SIP [2] allows participants to negotiate all media including real-time 673 text conversation [4]. ToIP services can provide the ability to set up 674 conversation sessions from any location as well as provision for 675 privacy and security through the application of standard SIP 676 techniques. 678 6.2.1.1 Pre-session set-up 680 The requirements of the user to be reached at a consistent address and 681 to store preferences for evaluation at session setup are met by pre- 682 session setup actions. That includes storing of registration 683 information in the SIP registrar, to provide information about how a 684 user can be contacted. This will allow sessions to be set up rapidly 685 and with proper routing and addressing. 687 The need to use real-time text as a medium of communications can be 688 expressed by users during registration time. Two situations need to be 689 considered in the pre-session setup environment: 691 a. User Preferences: It MUST be possible for a user to indicate a 692 preference for real-time text by registering that preference with a 693 SIP server that is part of the ToIP service. 695 b. Server support of User Preferences: SIP servers that support ToIP 696 services MUST have the capability to act on calling user 697 preferences for real-time text in order to accept or reject the 698 session. The actions taken can be based on the called users 699 preferences defined as part of the pre-session setup registration. 700 For example, if the user is called by another party, and it is 701 determined that a transcoding server is needed, the session should 702 be re-directed or otherwise handled accordingly. 704 The ability to include a transcoding service MUST NOT require user 705 registration in any specific SIP registrar, but MAY require 706 authorisation of the SIP registrar to invoke the service. 708 A point-to-point session takes place between two parties. For ToIP, 709 one or both of the communicating parties will indicate real-time text 710 as a possible or preferred medium for conversation using SIP in the 711 session setup. 713 The following features MAY be implemented to facilitate the session 714 establishment using ToIP: 716 a. Caller Preferences: SIP headers (e.g., Contact) [10] can be used to 717 show that real-time text is the medium of choice for 718 communications. 720 b. Called Party Preferences [11]: The called party being passive can 721 formulate a clear rule indicating how a session should be handled 722 either using real-time text as a preferred medium or not, and 723 whether a designated SIP proxy needs to handle this session or it 724 will be handled in the SIP User Agent. 726 c. SIP Server support for User Preferences: It is RECOMMENDED that SIP 727 servers also handle the incoming sessions in accordance with 728 preferences expressed for real-time text. The SIP Server can also 729 enforce ToIP policy rules for communications (e.g. use of the 730 transcoding server for ToIP). 732 6.2.1.2 Session Negotiations 734 The Session Description Protocol (SDP) used in SIP [2] provides the 735 capabilities to indicate real-time text as a medium in the session 736 setup. RFC 4103 [4] uses the RTP payload types "text/red" and 737 "text/t140" for support of ToIP which can be indicated in the SDP as a 738 part of the SIP INVITE, OK and SIP/200/ACK media negotiations. In 739 addition, SIPs offer/answer model [12] can also be used in conjunction 740 with other capabilities including the use of a transcoding server for 741 enhanced session negotiations [III,IV,13]. 743 6.2.2 Transport 745 ToIP services MUST support the Real-Time Transport Protocol (RTP) [3] 746 according to the specification of RFC 4103 [3] for the transport of 747 real-time text between participants. 749 RFC 4103 describes the transmission of T.140 [8] real-time text on IP 750 networks. 752 In order to enable the use of international character sets, the 753 transmission format for real-time text conversation SHALL be UTF-8 754 [14], in accordance with ITU-T T.140. 756 If real-time text is detected to be missing after transmission, there 757 SHOULD be a "text loss" indication in the real-time text as specified 758 in T.140 Addendum 1 [8]. 760 The redundancy method of RFC 4103 [4] SHOULD be used to significantly 761 increase the reliability of the real-time text transmission. A 762 redundancy level using 2 generations gives very reliable results and 763 is therefore strongly RECOMMENDED. 765 Real-time text capability is announced in SDP by a declaration similar 766 to this example: 768 m=text 11000 RTP/AVP 100 98 769 a=rtpmap:98 t140/1000 770 a=rtpmap:100 red/1000 771 a=fmtp:100 98/98/98 773 By having this single coding and transmission scheme for real-time 774 text defined in the SIP session control environment, the opportunity 775 for interoperability is optimized. However, if good reasons exist, 776 other transport mechanisms MAY be offered and used for the T.140 coded 777 text provided that proper negotiation is introduced, but RFC 4103 [4] 778 transport MUST be used as both the default and the fallback transport. 780 6.2.3 Transcoding services 782 Invocation of a transcoding service MAY happen automatically when the 783 session is being set up based on any valid indication or negotiation 784 of supported or preferred media types. A transcoding framework 785 document using SIP [III] describes invoking relay services, where the 786 relay acts as a conference bridge or uses the third party control 787 mechanism. ToIP implementations SHOULD support this transcoding 788 framework. 790 6.2.4 Presentation and User control functions 792 6.2.4.1 Progress and status information 794 Session progress information SHOULD use simple language so that as 795 many users as possible can understand it. The use of jargon or 796 ambiguous terminology SHOULD be avoided. It is RECOMMENDED that text 797 information be used together with icons to symbolise the session 798 progress information. 800 In summary, it SHOULD be possible to observe indicators about: 801 - Incoming session 802 - Availability of real-time text, voice and video channels 803 - Session progress 804 - Incoming real-time text 805 - Any loss in incoming real-time text 806 - Typed and transmitted real-time text. 808 6.2.4.2 Alerting 810 For users who cannot use the audible alerter for incoming sessions, it 811 is RECOMMENDED to include a tactile as well as a visual indicator. 813 Among the alerting options are alerting by the User Agent's User 814 Interface and specific alerting User Agents registered to the same 815 registrar as the main User Agent. 817 It should be noted that external alerting systems exist and one common 818 interface for triggering the alerting action is a contact closure 819 between two conductors. 821 6.2.4.3 Text presentation 823 Requirement R32 states that, in the display of text conversations, 824 users must be able to distinguish easily between different speakers. 825 This could be done using color, positioning of the text (i.e. incoming 826 real-time text and outgoing real-time text in different display 827 areas), by in-band identifiers of the parties or by a combination of 828 any of these techniques. 830 6.2.4.4 File storage 832 Requirement R31 recommends that ToIP systems allow the user to save 833 text conversations. This SHOULD be done using a standard file format. 834 For example: a UTF-8 text file in XHTML format [15] including 835 timestamps, party names (or addresses) and the conversation text. 837 6.2.5 Interworking functions 839 A number of systems for real-time text conversation already exist as 840 well as a number of message oriented text communication systems. 842 Interoperability is of interest between ToIP and some of these 843 systems. 845 Interoperation of half-duplex and full-duplex protocols, and between 846 protocols that have different data rates, may require text buffering. 847 Some intelligence will be needed to determine when to change direction 848 when operating in half-duplex mode. Identification may be required of 849 half-duplex operation either at the "user" level (ie. users must 850 inform each other) or at the "protocol" level (where an indication 851 must be sent back to the Gateway). However, special care needs to be 852 taken to provide the best possible real-time performance. 854 Buffering schemes SHOULD be dimensioned to adjust for receiving at 30 855 characters per second and transmitting at 6 characters per second for 856 up to 4 minutes (i.e. less than 3000 characters). 858 When converting between simultaneous voice and text on the IP side, 859 and alternating voice and text on the other side of a gateway, a 860 conflict can occur if the IP user transmits both audio and text at the 861 same time. In such situations, text transmission SHOULD have 862 precedence, so that while text is transmitted, audio is lost. 864 Transcoding of text to and from other coding formats may need to take 865 place in gateways between ToIP and other forms of text conversation, 866 for example to connect to a PSTN text telephone. 868 Session set-up through gateways to other networks may require the use 869 of specially formatted addresses or other mechanisms for invoking 870 those gateways. 872 ToIP interworking requires a method to invoke a text gateway. These 873 text gateways act as User Agents at the IP side. The capabilities of 874 the gateway during the call will be determined by the call 875 capabilities of the terminal that is using the gateway. For example, a 876 PSTN textphone is generally only able to receive voice and real-time 877 text, so the gateway will only allow ToIP and audio. 879 Examples of possible scenarios for invocation of the text gateway are: 881 a. PSTN textphone users dial a prefix number before dialing out. 882 b. Separate real-time text subscriptions, linked to the phone number 883 or terminal identifier/ IP address. 884 c. Real-time text capability indicators. 885 d. Real-time text preference indicators. 886 e. Listen for V.18 modem modulation text activity in all PSTN calls 887 and routing of the call to an appropriate gateway. 888 f. Call transfer request by the called user. 889 g. Placing a call via the web, and using one of the methods described 890 here 891 h. A text gateway with its own telephone number and/or SIP address. 892 (This requires user interaction with the gateway to place a call). 894 i. ENUM address analysis and number plan. 895 j. Number or address analysis leads to a gateway for all PSTN calls. 897 6.2.5.1 PSTN Interworking 899 Analog text telephony is cumbersome because of incompatible national 900 implementations where interworking was never considered. A large 901 number of these implementations have been documented in ITU-T V.18 902 [16], which also defines the modem detection sequences for the 903 different text protocols. The modem type identification may in rare 904 cases take considerable time depending on user actions. 906 To resolve analog textphone incompatibilities, text telephone gateways 907 are needed to transcode incoming analog signals into T.140 and vice 908 versa. The modem capability exchange time can be reduced by the text 909 telephone gateways initially assuming the analog text telephone 910 protocol used in the region where the gateway is located. For example, 911 in the USA, Baudot [VI] might be tried as the initial protocol. If 912 negotiation for Baudot fails, the full V.18 modem capability exchange 913 will take place. In the UK, ITU-T V.21 [VII] might be the first 914 choice. 916 In particular transmission of real-time text on PSTN networks takes 917 place using a variety of codings and modulations, including ITU-T 918 V.21 [VII], Baudot [VI], DTMF, V.23 [VIII] and others. Many 919 difficulties have arisen as a result of this variety in text 920 telephony protocols and the ITU-T V.18 [16] standard was developed to 921 address some of these issues. 923 ITU-T V.18 [16] offers a native text telephony method plus it defines 924 interworking with current protocols. In the interworking mode, it will 925 recognise one of the older protocols and fall back to that 926 transmission method when required. 928 Text gateways MUST use the ITU-T V.18 [16] standard at the PSTN side. 929 A text gateway MUST act as a SIP User Agent on the IP side and support 930 RFC 4103 real-time text transport. 932 While ToIP allows receiving and sending real-time text simultaneously 933 and is displayed on a split screen, many analog text telephones 934 require users to take turns typing. This is because many text 935 telephones operate strictly half duplex. Only one can transmit text at 936 a time. The users apply strict turn-taking rules. 938 There are several text telephones which communicate in full duplex, 939 but merge transmitted text and received text in the same line in the 940 same display window. Here too the users apply strict turn taking 941 rules. 943 Native V.18 text telephones support full duplex and separate display 944 from reception and transmission so that the full duplex capability 945 can be used fully. Such devices could use the ToIP split screen as 946 well, but almost all text telephones use a restricted character set 947 and many use low text transmission speeds (4 to 7 characters per 948 second). 950 That is why it is important for the ToIP user to know that he or she 951 is connected with an analog text telephone. The session description 952 [9] SHOULD contain an indication that the other endpoint for the call 953 is a PSTN textphone (e.g. connected via an ATA or through a text 954 gateway). This means that the textphone user may be used to formal 955 turn taking during the call. 957 6.2.5.2 Mobile Interworking 959 Mobile wireless (or Cellular) circuit switched connections provide a 960 digital real-time transport service for voice or data. The access 961 technologies include GSM, CDMA, TDMA, iDen and various 3G 962 technologies as well as WiFi or WiMAX. 964 ToIP may be supported over the cellular wireless packet switched 965 service. It interfaces to the Internet. 967 The following sections describe how mobile text telephony is 968 supported. 970 6.2.5.2.1 Cellular "No-gain" 972 The "No-gain" text telephone transporting technology uses specially 973 modified EFR [17] and EVR [18] speech vocoders in mobile terminals 974 used to provide a text telephony call. It provides full duplex 975 operation and supports alternating voice and text ("VCO/HCO"). It is 976 dedicated to CDMA and TDMA mobile technologies and the US Baudot (i.e. 977 45 bit/s) type of text telephones. 979 6.2.5.2.2 Cellular Text Telephone Modem (CTM) 981 CTM [7] is a technology independent modem technology that provides the 982 transport of text telephone characters at up to 10 characters/sec 983 using modem signals that can be carried by many voice codecs and uses 984 a highly redundant encoding technique to overcome the fading and cell 985 changing losses. 987 6.2.5.2.3 Cellular "Baudot mode" 989 This term is often used by cellular terminal suppliers for a cellular 990 phone mode that allows TTYs to operate into a cellular phone and to 991 communicate with a fixed line TTY. Thus it is a common name for the 992 "No-Gain" and the CTM solutions when applied to the Baudot type 993 textphones. 995 6.2.5.2.4 Mobile data channel mode 997 Many mobile terminals allow the use of the circuit switched data 998 channel to transfer data in real-time. Data rates of 9600 bit/s are 999 usually supported on the 2G mobile network. Gateways provide 1000 interoperability with PSTN textphones. 1002 6.2.5.2.5 Mobile ToIP 1004 ToIP could be supported over mobile wireless packet switched services 1005 that interface to the Internet. For 3GPP 3G services, ToIP support is 1006 described in 3G TS 26.235 [19]. 1008 6.2.5.3 Instant Messaging Interworking 1010 Text gateways MAY be used to allow interworking between Instant 1011 Messaging systems and ToIP solutions. Because Instant Messaging is 1012 based on blocks of text, rather than on a continuous stream of 1013 characters like ToIP, gateways MUST transcode between the two formats. 1014 Text gateways for interworking between Instant Messaging and ToIP MUST 1015 apply a procedure for bridging the different conversational formats of 1016 real-time text versus text messaging. The following advice may improve 1017 user experience for both parties in a call through a messaging 1018 gateway. 1020 a. Concatenate individual characters originating at the ToIP side into 1021 blocks of text. 1023 b. When the length of the concatenated message becomes longer than 50 1024 characters, the buffered text SHOULD be transmitted to the Instant 1025 Messaging side as soon as any non-alphanumerical character is 1026 received from the ToIP side. 1028 c. When a new line indicator is received from the ToIP side, the 1029 buffered characters up to that point, including the carriage return 1030 and/or line feed characters, SHOULD be transmitted to the Instant 1031 Messaging side. 1033 d. When the ToIP side has been idle for at least 5 seconds, all 1034 buffered text up to that point SHOULD be transmitted to the Instant 1035 Messaging side. 1037 e. Text Gateways must be capable to maintain the real-time performance 1038 for ToIP while providing the interworking services. 1040 It is RECOMMENDED that during the session, both users be constantly 1041 updated on the progress of the text input. Many Instant Messaging 1042 protocols signal that a user is typing to the other party in the 1043 conversation. Text gateways between such Instant Messaging protocols 1044 and ToIP MUST provide this signalling to the Instant Messaging side 1045 when characters start being received, or at the beginning of the 1046 conversation. 1048 At the ToIP side, an indicator of writing the Instant Message MUST be 1049 present where the Instant Messaging protocol provides one. For 1050 example, the real-time text user MAY see ". . . waiting for replying 1051 IM. . . " and when 5 seconds have passed another . (dot) can be shown. 1053 Those solutions will reduce the difficulties between streaming and 1054 blocked text services. 1056 Even though the text gateway can connect Instant Messaging and ToIP, 1057 the best solution is to take advantage of the fact that the user 1058 interfaces and the user communities for instant messaging and ToIP 1059 telephony are very similar. After all, the character input, the 1060 character display, Internet connectivity and SIP stack can be the same 1061 for Instant Messaging (SIMPLE) and ToIP. Thus, the user may simply use 1062 different applications for ToIP and text messaging in the same 1063 terminal. 1065 Devices that implement Instant Messaging SHOULD implement ToIP as 1066 described in this document so that a more complete text communication 1067 service can be provided. 1069 6.2.5.4 Multi-functional Combination gateways 1071 In practice many interworking gateways will be implemented as gateways 1072 that combine different functions. As such, a text gateway could be 1073 built to have modems to interwork with the PSTN and support both 1074 Instant Messaging as well as ToIP. Such interworking functions are 1075 called Combination gateways. 1077 Combination gateways could provide interworking between all of their 1078 supported text based functions. For example, a Text gateway that has 1079 modems to interwork with the PSTN and that support both Instant 1080 Messaging and ToIP could support the following interworking functions: 1082 - PSTN text telephony to ToIP. 1083 - PSTN text telephony to Instant Messaging. 1084 - Instant Messaging to ToIP. 1086 6.2.5.5 Character set transcoding 1088 Gateways between the ToIP network and other networks MAY need to 1089 transcode text streams. ToIP makes use of the ISO 10646 character set. 1090 Most PSTN textphones use a 7-bit character set, or a character set 1091 that is converted to a 7-bit character set by the V.18 modem. 1093 When transcoding between character sets and T.140 in gateways, special 1094 consideration MUST be given to the national variants of the 7-bit 1095 codes, with national characters mapping into different codes in the 1096 ISO 10646 code space. The national variant to be used could be 1097 selectable by the user on a per call basis, or be configured as a 1098 national default for the gateway. 1100 The indicator of missing text in T.140, specified in T.140 amendment 1101 1, cannot be represented in the 7-bit character codes. Therefore the 1102 indicator of missing text SHOULD be transcoded to the ' (apostrophe) 1103 character in legacy text telephone systems, where this character 1104 exists. For legacy systems where the ' character does not exist, the . 1105 (full stop) character SHOULD be used instead. 1107 7. Further recommendations for implementers and service providers 1109 7.1 Access to Emergency services 1111 It must be possible to place an emergency call using ToIP and it must 1112 be possible to use a relay service in such call. The emergency service 1113 provided to users utilising the real-time text medium must be 1114 equivalent to the emergency service provided to users utilising speech 1115 or other media. 1117 A text gateway must be able to route real-time text calls to emergency 1118 service providers when any of the recognised emergency numbers that 1119 support text communications for the country or region are called e.g. 1120 "911" in USA and "112" in Europe. Routing real-time text calls to 1121 emergency services may require the use of a transcoding service. 1123 A text gateway with cellular wireless packet switched services must be 1124 able to route real-time text calls to emergency service providers when 1125 any of the recognized emergency numbers that support real-time text 1126 communication for the country is called. 1128 7.2 Home Gateways or Analog Terminal Adapters 1130 Analog terminal adapters (ATA) using SIP based IP communication and 1131 RJ-11 connectors for connecting traditional PSTN devices SHOULD enable 1132 connection of legacy PSTN text telephones [II]. 1134 These adapters SHOULD contain V.18 modem functionality, voice handling 1135 functionality, and conversion functions to/from SIP based ToIP with 1136 T.140 transported according to RFC 4103 [3], in a similar way as it 1137 provides interoperability for voice sessions. 1139 If a session is set up and text/t140 capability is not declared by the 1140 destination endpoint (by the end-point terminal or the text gateway in 1141 the network at the end-point), a method for invoking a transcoding 1142 server SHALL be used. If no such server is available, the signals from 1143 the textphone MAY be transmitted in the voice channel as audio with 1144 high quality of service. 1146 NOTE: It is preferred that such analog terminal adaptors do use RFC 1147 4103 [4] on board and thus act as a text gateway. Sending textphone 1148 signals over the voice channel is undesirable due to possible 1149 filtering and compression and packet loss between the end-points. This 1150 can result in character loss in the textphone conversation or even not 1151 allowing the textphones to connect to each other. 1153 7.3 User Mobility 1155 ToIP User Agents SHOULD use the same mechanisms as other SIP User 1156 Agents to resolve mobility issues. It is RECOMMENDED that users use a 1157 SIP address, resolved by a SIP registrar, to enable basic user 1158 mobility. Further mechanisms are defined for all session types for 3G 1159 IP multimedia systems. 1161 7.4 Firewalls and NATs 1163 ToIP uses the same signalling and transport protocols as VoIP. Hence, 1164 the same firewall and NAT solutions and network functionality that 1165 apply to VoIP MUST also apply to ToIP. 1167 7.5 Quality of Service 1169 Where Quality of Service (QoS) mechanisms are used, the real-time text 1170 streams should be assigned appropriate QoS characteristics, so that 1171 the performance requirements can be met and the real-time text stream 1172 is not degraded unfavourably in comparison to voice performance in 1173 congested situations. 1175 8. IANA Considerations 1177 There are no IANA considerations for this specification. 1179 9. Security Considerations 1181 User confidentiality and privacy need to be met as described in SIP 1182 [2]. For example, nothing should reveal in an obvious way the fact 1183 that the ToIP user might be a person with a hearing or speech 1184 impairment. It is up to the ToIP user to make his or her hearing or 1185 speech impairment public. If a transcoding server is being used, 1186 this SHOULD be as transparent as possible. However, it might still be 1187 possible to discern that a user might be hearing or speech impaired 1188 based on the attributes present in SDP, although the intention is 1189 that mainstream users might also choose to use ToIP. 1190 Encryption SHOULD be used on end-to-end or hop-by-hop basis as 1191 described in SIP [2] and SRTP [20]. 1193 Authentication MUST be provided for users in addition to message 1194 integrity and access control. 1196 Protection against Denial-of-service (DoS) attacks needs to be 1197 provided considering the case that the ToIP users might need 1198 transcoding servers. 1200 10. Authors' Addresses 1202 Guido Gybels 1203 Department of New Technologies 1204 RNID, 19-23 Featherstone Street 1205 London EC1Y 8SL, UK 1206 Email: guido.gybels@rnid.org.uk 1207 Tel +44-20-7294 3713 1208 Txt +44-20-7296 8001 Ext 3713 1209 Fax +44-20-7296 8069 1211 Arnoud A. T. van Wijk 1212 RealTimeText.org 1213 http://www.realtimetext.org 1214 Email: arnoud@realtimetext.org 1216 11. Contributors 1218 The following people contributed to this document: Willem Dijkstra, 1219 Barry Dingle, Gunnar Hellstrom, Radhika R. Roy, Henry Sinnreich and 1220 Gregg C Vanderheiden. 1222 The content and concepts within are a product of the SIPPING Working 1223 Group. Tom Taylor (Nortel) acted as independent reviewer and 1224 contributed significantly to the structure and content of this 1225 document. 1227 12. References 1229 12.1 Normative references 1231 1. S. Bradner, "Intellectual Property Rights in IETF Technology", 1232 BCP 79, RFC 3979, IETF, March 2005. 1234 2. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 1235 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session 1236 Initiation Protocol", RFC 3621, IETF, June 2002. 1238 3. H. Schulzrinne, S.Casner, R. Frederick, V. Jacobsone, "RTP: A 1239 Transport Protocol for Real-Time Applications", RFC 3550, IETF, 1240 July 2003. 1242 4. G. Hellstrom, P. Jones, "RTP Payload for Text Conversation", 1243 RFC 4103, IETF, June 2005. 1245 5. ITU-T Recommendation F.703,"Multimedia Conversational Services", 1246 November 2000. 1248 6. S. Bradner, "Key words for use in RFCs to Indicate Requirement 1249 Levels", BCP 14, RFC 2119, IETF, March 1997 1251 7. 3GPP TS 26.226 "Cellular Text Telephone Modem Description" (CTM). 1253 8. ITU-T Recommendation T.140, "Protocol for Multimedia Application 1254 Text Conversation" (February 1998) and Addendum 1 (February 2000). 1256 9. M. Handley, V. Jacobson, C. Perkins, "SDP: Session Description 1257 Protocol", RFC 4566, IETF, July 2006. 1259 10. J. Rosenberg, H. Schulzrinne, P. Kyzivat, "Indicating User Agent 1260 Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, 1261 IETF, August 2004 1263 11. J. Rosenberg, H. Schulzrinne, P. Kyzivat, "Caller Preferences for 1264 the Session Initiation Protocol (SIP)", RFC 3841, IETF, 1265 August 2004 1267 12. J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the 1268 Session Description Protocol (SDP)", RFC 3624, IETF, June 2002. 1270 13. G. Camarillo, H. Schulzrinne, E. Burger, and A. van Wijk, 1271 "Transcoding Services Invocation in the Session Initiation 1272 Protocol (SIP) Using Third Party Call Control (3pcc)" RFC 4117, 1273 IETF, June 2005. 1275 14. Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1276 RFC 3629, IETF,November 2003. 1278 15. "XHTML 1.0: The Extensible HyperText Markup Language: A 1279 Reformulation of HTML 4 in XML 1.0", W3C Recommendation. Available 1280 at http://www.w3.org/TR/xhtml1. 1282 16. ITU-T Recommendation V.18,"Operational and Interworking 1283 Requirements for DCEs operating in Text Telephone Mode", 1284 November 2000. 1286 17. TIA/EIA/IS-823-A "TTY/TDD Extension to TIA/EIA-136-410 Enhanced 1287 Full Rate Speech Codec (must used in conjunction with 1288 TIA/EIA/IS-840)" 1290 18. TIA/EIA/IS-127-2 "Enhanced Variable Rate Codec, Speech Service 1291 Option 3 for Wideband Spread Spectrum Digital Systems. 1292 Addendum 2." 1294 19. "IP Multimedia default codecs". 3GPP TS 26.235 1296 20. Baugher, McGrew, Carrara, Naslund, Norrman, "The Secure Real Time 1297 Transport Protocol (SRTP)", RFC 3711, IETF, March 2004. 1299 21. ITU-T Recommendation F.700,"Framework Recommendation for 1300 Multimedia Services", November 2000. 1302 12.2 Informative references 1304 I. Charlton, Gasson, Gybels, Spanner, van Wijk, "User Requirements 1305 for the Session Initiation Protocol (SIP) in Support of Deaf, 1306 Hard of Hearing and Speech-impaired Individuals", RFC 3351, 1307 IETF, August 2002. 1309 II. H. Sinnreich, S. Lass, and C. Stredicke, "SIP Telephony Device 1310 Requirements and Configuration" RFC 4504, IETF, May 2006. 1312 III. G. Camarillo, "Framework for Transcoding with the Session 1313 Initiation Protocol", IETF, May 2006 - Work in progress. 1315 IV. G. Camarillo, "The SIP Conference Bridge Transcoding Model", 1316 IETF, January 2006 - Work in Progress. 1318 V. European Telecommunications Standards Institute (ETSI), "Human 1319 Factors (HF); Guidelines for Telecommunication Relay Services for 1320 Text Telephones". TR 101 806, June 2000. 1322 VI. TIA/EIA/825 "A Frequency Shift Keyed Modem for Use on the Public 1323 Switched Telephone Network." (The specification for 45.45 and 50 1324 bit/s TTY modems.) 1326 VII. International Telecommunication Union (ITU), "300 bits per second 1327 duplex modem standardized for use in the general switched 1328 telephone network". ITU-T Recommendation V.21, November 1988. 1330 VIII.International Telecommunication Union (ITU), "600/1200-baud modem 1331 standardized for use in the general switched telephone network". 1332 ITU-T Recommendation V.23, November 1988. 1334 Full Copyright Statement 1336 Copyright (C) The IETF Trust (2007). 1338 This document is subject to the rights, licenses and restrictions 1339 contained in BCP 78, and except as set forth therein, the authors 1340 retain all their rights. 1342 This document and the information contained herein are provided on an 1343 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1344 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, 1345 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1346 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1347 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 1348 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 1349 PURPOSE. 1351 Intellectual Property 1353 The IETF takes no position regarding the validity or scope of any 1354 Intellectual Property Rights or other rights that might be claimed to 1355 pertain to the implementation or use of the technology described in 1356 this document or the extent to which any license under such rights 1357 might or might not be available; nor does it represent that it has 1358 made any independent effort to identify any such rights. Information 1359 on the procedures with respect to rights in RFC documents can be 1360 found in BCP 78 and BCP 79. 1362 Copies of IPR disclosures made to the IETF Secretariat and any 1363 assurances of licenses to be made available, or the result of an 1364 attempt made to obtain a general license or permission for the use of 1365 such proprietary rights by implementers or users of this 1366 specification can be obtained from the IETF on-line IPR repository at 1367 http://www.ietf.org/ipr. 1369 The IETF invites any interested party to bring to its attention any 1370 copyrights, patents or patent applications, or other proprietary 1371 rights that may cover technology that may be required to implement 1372 this standard. Please address the information to the IETF at 1373 ietf-ipr@ietf.org. 1375 Acknowledgement 1377 Funding for the RFC Editor function is provided by the IETF 1378 Administrative Support Activity (IASA).