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