idnits 2.17.1 draft-ietf-sipping-toip-04.txt: -(129): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1224): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1226): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1518. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1529. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1536. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1542. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 11 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 26) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 378: '... R1: It SHOULD be possible to start ...' RFC 2119 keyword, line 381: '... R2: It MUST be possible for the use...' RFC 2119 keyword, line 385: '... supporting ToIP MUST allow users to s...' RFC 2119 keyword, line 388: '... R4: Systems SHOULD allow the user t...' RFC 2119 keyword, line 395: '...work, the system MUST try to establish...' (115 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (March 6, 2006) is 6619 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '2' on line 621 looks like a reference -- Missing reference section? '3' on line 1310 looks like a reference -- Missing reference section? '4' on line 1262 looks like a reference -- Missing reference section? '5' on line 1273 looks like a reference -- Missing reference section? '6' on line 325 looks like a reference -- Missing reference section? '7' on line 166 looks like a reference -- Missing reference section? '25' on line 196 looks like a reference -- Missing reference section? 'I' on line 622 looks like a reference -- Missing reference section? '8' on line 1044 looks like a reference -- Missing reference section? '9' on line 924 looks like a reference -- Missing reference section? '11' on line 715 looks like a reference -- Missing reference section? '12' on line 718 looks like a reference -- Missing reference section? '13' on line 746 looks like a reference -- Missing reference section? '14' on line 842 looks like a reference -- Missing reference section? '15' on line 748 looks like a reference -- Missing reference section? '16' on line 748 looks like a reference -- Missing reference section? '17' on line 778 looks like a reference -- Missing reference section? '18' on line 931 looks like a reference -- Missing reference section? '19' on line 983 looks like a reference -- Missing reference section? 'II' on line 973 looks like a reference -- Missing reference section? 'III' on line 973 looks like a reference -- Missing reference section? 'IV' on line 973 looks like a reference -- Missing reference section? '20' on line 1035 looks like a reference -- Missing reference section? '21' on line 1035 looks like a reference -- Missing reference section? '22' on line 1072 looks like a reference -- Missing reference section? '23' on line 1258 looks like a reference -- Missing reference section? '24' on line 1310 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 34 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Workgroup 3 Internet Draft A. van Wijk 4 Category: Informational AnnieS 5 Expires: September 5 2006 March 6, 2006 7 Framework for real-time text over IP using SIP 9 draft-ietf-sipping-toip-04.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 5, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document provides a framework for the implementation of real- 43 time text conversation over the IP network using the Session 44 Initiation Protocol and the Real-Time Transport Protocol. It lists 45 the essential requirements for real-time Text-over-IP (ToIP) and 46 defines a framework for implementation of all required functions 47 based on existing protocols and techniques. This includes 48 interworking between Text-over-IP and existing text telephony on the 49 PSTN and other networks. 51 Table of Contents 53 1. Introduction...................................................3 54 2. Scope..........................................................4 55 3. Terminology....................................................4 56 4. Definitions....................................................4 57 5. Requirements...................................................6 58 5.1 General requirements for ToIP..............................6 59 5.2 Detailed requirements for ToIP.............................8 60 5.2.1 Session control and set-up requirements...............8 61 5.2.2 Transport requirements................................9 62 5.2.3 Transcoding service requirements.....................10 63 5.2.4 Presentation and User control requirements...........11 64 5.2.5 Interworking requirements............................12 65 5.2.5.1 PSTN Interworking requirements..................12 66 5.2.5.2 Cellular Interworking requirements..............12 67 5.2.5.3 Instant Messaging Interworking requirements.....13 68 6. Implementation Framework......................................13 69 6.1 Framework of general implementation.......................13 70 6.2 Framework of detailed implementation......................14 71 6.2.1 Session control and set-up...........................14 72 6.2.1.1 Pre-session setup...............................14 73 6.2.1.2 Basic Point-to-Point Session setup..............15 74 6.2.1.3 Addressing......................................15 75 6.2.1.4 Session Negotiations............................15 76 6.2.1.5 Additional session control......................16 77 6.2.2 Transport............................................16 78 6.2.3 Transcoding services.................................17 79 6.2.4 Presentation and User control functions..............18 80 6.2.4.1 Progress and status information.................18 81 6.2.4.2 Alerting........................................18 82 6.2.4.3 Answering Machine...............................18 83 6.2.4.4 Text presentation...............................19 84 6.2.4.5 File storage....................................19 85 6.2.5 Interworking functions...............................19 86 6.2.5.1 PSTN Interworking...............................20 87 6.2.5.2 Mobile Interworking.............................21 88 6.2.5.2.1 Cellular "No-gain".........................21 89 6.2.5.2.2 Cellular Text Telephone Modem (CTM)........21 90 6.2.5.2.3 Cellular "Baudot mode".....................22 91 6.2.5.2.4 Mobile data channel mode...................22 92 6.2.5.2.5 Mobile ToIP................................22 93 6.2.5.3 Instant Messaging Interworking..................22 94 6.2.5.4 Interworking through gateways...................23 95 6.2.5.5 Multi-functional Combination gateways...........24 96 6.2.5.6 Character set transcoding.......................25 97 7. Further recommendations for implementers and service providers25 98 7.1 Access to Emergency services..............................25 99 7.2 Home Gateways or Analog Terminal Adapters.................26 100 7.3 User Mobility.............................................26 101 7.4 Firewalls and NATs........................................26 102 8. IANA Considerations...........................................26 103 9. Security Considerations.......................................26 104 10. Authors� Addresses...........................................27 105 11. References...................................................28 106 11.1 Normative references.....................................28 107 11.2 Informative references...................................30 109 1. 110 Introduction 112 For many years, text has been in use as a medium for conversational, 113 interactive dialogue between users in a similar way to how voice 114 telephony is used. Such interactive text is different from messaging 115 and semi-interactive solutions like Instant Messaging in that it 116 offers an equivalent conversational experience to users who cannot, 117 or do not wish to, use voice. It therefore meets a different set of 118 requirements from other text-based solutions already available on IP 119 networks. 121 Traditionally, deaf, hard of hearing and speech-impaired people are 122 amongst the most prolific users of conversational, interactive text 123 but, because of its interactivity, it is becoming popular amongst 124 mainstream users as well. 126 This document describes how existing IETF protocols can be used to 127 implement a Text-over-IP solution (ToIP). This ToIP framework is 128 specifically designed to be compatible with Voice-over-IP (VoIP) and 129 Multimedia-over-IP (MoIP) environments, as well as meeting the user�s 130 requirements, including those of deaf, hard of hearing and speech- 131 impaired users as described in RFC3351 [2] and mainstream users. 133 The Session Initiation Protocol (SIP) [3] is the protocol of choice 134 for control of Multimedia communications and Voice-over-IP (VoIP) in 135 particular. It offers all the necessary control and signaling 136 required for the ToIP framework. 138 The Real-Time Transport Protocol (RTP) [4] is the protocol of choice 139 for real-time data transmission, and its use for real-time text 140 payloads is described in RFC4103 [5]. 142 This document defines a framework for ToIP to be used either by 143 itself or as part of integrated, multi-media services, including 144 Total Conversation [6]. 146 2. 147 Scope 149 This document defines a framework for the implementation of real-time 150 ToIP, either stand-alone or as a part of multimedia services, 151 including Total Conversation [6]. It defines the: 153 a. Requirements of 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. 159 Terminology 161 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 162 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 163 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 164 described in BCP 14, RFC 2119 [7] and indicate requirement levels for 165 compliant implementations. 167 4. 168 Definitions 170 Audio bridging: a function of an audio media bridge server, gateway 171 or relay service that bridges audio into a single source through 172 combining audio from multiple users excluding each destination 173 source�s audio and sends to each respective destination enabling an 174 audio path through the service between the users involved in the 175 call. 177 Cellular: a telecommunication network that has wireless access and 178 can support voice and data services over very large geographical 179 areas. Also called Mobile. 181 Full duplex: media is sent independently in both directions. 183 Half duplex: media can only be sent in one direction at a time or, if 184 an attempt to send information in both directions is made, errors can 185 be introduced into the presented media. 187 Interactive text: a term for real time transmission of text in a 188 character-by-character fashion for use in conversational services, 189 often as a text equivalent to voice based conversational services. 190 (Equivalent to real-time text.) 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 ITU-T F.700 Framework for 196 multimedia services [25]. 198 Text gateway: a function that transcodes between different forms of 199 real-time text transport methods, e.g., between ToIP in IP networks 200 and Baudot 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, interactive text communication using analog 204 transmission. A variety of PSTN textphone protocols exists world- 205 wide. A textphone can often be combined with a voice telephone, or 206 include voice communication functions for simultaneous or alternating 207 use of text and voice in a call. 209 Text bridging: a function of a gateway service that enables the flow 210 of text through the service between the users involved in the call. 212 Text Relay Service: a third-party or intermediary that enables 213 communications between deaf, hard of hearing and speech-impaired 214 people, and voice telephone users by translating between voice and 215 real-time text in a call. 217 Text Bridging: a function of the text media bridge server, gateway or 218 relay service that bridges real-time text into a single source 219 through combining real-time text from multiple users excluding each 220 destination source�s real-time text and sends to each respective 221 destination enabling a real-time text path through the service 222 between the users involved in the call. 224 Text telephony: analog textphone service. 226 Total Conversation: a multimedia service offering real time 227 conversation in video, real-time text and voice according to 228 interoperable standards. All media flow in real time. (See ITU-T 229 F.703 "Multimedia conversational services" [6].) 231 Transcoding Services: services of a third-party user agent that 232 transcodes one stream into another. Transcoding can be done by human 233 operators, in an automated manner or a combination of both methods. 234 Text Relay Services are examples of a transcoding service between 235 real-time text and audio. 237 TTY: alternative designation for a text telephone or textphone, often 238 used in USA. 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 243 in 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 CDMA Code Division Multiple Access 251 CLI Calling Line Identification 252 CTM Cellular Text Telephone Modem 253 ENUM E.164 number storage in DNS (see RFC3761) 254 GSM Global System of Mobile Communication 255 ISDN Integrated Services Digital Network 256 ITU-T International Telecommunications Union-Telecommunications 257 Standardisation Sector 258 NAT Network Address Translation 259 PSTN Public Switched Telephone Network 260 RTP Real Time Transport Protocol 261 SDP Session Description Protocol 262 SIP Session Initiation Protocol 263 SRTP Secure Real Time Transport Protocol 264 TDD Telecommunication Device for the Deaf 265 TDMA Time Division Multiple Access 266 TTY Analog textphone (Teletypewriter) 267 ToIP Real-time Text over Internet Protocol 268 UTF-8 Universal Transfer Format-8 269 VCO/HCO Voice Carry Over/Hearing Carry Over 270 VoIP Voice over Internet Protocol 272 5. 273 Requirements 275 This framework defines a text-based conversational service that is 276 the text equivalent of voice based telephony. This section describes 277 the requirements that the framework is designed to meet and the 278 functionality it should offer. 280 Real-time text conversation can be combined with other conversational 281 services like video or voice. 283 ToIP also offers an IP equivalent of analog text telephony services 284 as used by deaf, hard of hearing, speech-impaired and mainstream 285 users. 287 This section (Requirements) informs implementers about WHICH 288 requirements the systems and services shall meet. The next section 289 (Section 6 Framework Implementation) describes HOW to do it. 291 5.1 292 General requirements for ToIP 294 Any framework for ToIP must be designed to meet the requirements of 295 RFC3351 [2]. A basic requirement is that it must provide a 296 standardized way for offering text-based, conversational services 297 that can be used as an equivalent to voice telephony by deaf, hard of 298 hearing speech-impaired and mainstream users. 300 It is important to understand that real-time text conversations are 301 significantly different from other text-based communications like 302 email or Instant Messaging. Real-time text conversations deliver an 303 equivalent mode to voice conversations by providing transmission of 304 text character by character as it is entered, so that the 305 conversation can be followed closely and immediate interaction take 306 place. 308 Store-and-forward systems like email or messaging on mobile networks 309 or non-streaming systems like instant messaging are unable to provide 310 that functionality. In particular, they do not allow for smooth 311 communication through a Text Relay Service. 313 In order to make ToIP the text equivalent of voice services, it needs 314 to offer equivalent features in terms of conversationality as voice 315 telephony provides. To achieve that, ToIP needs to: 317 a. Offer real-time transport and presentation of the conversation; 318 b. Provide simultaneous transmission in both directions; 319 c. Support both point-to-point and multipoint communication; 320 d. Allow other media, like audio and video, to be used in 321 conjunction with ToIP; 322 e. Ensure that the real-time text service is always available. 324 Real-time text is a useful subset of Total Conversation defined in 325 ITU-T F.703 [6]. Users could use multiple modes of communication 326 during the conversation, either at the same time or by switching 327 between modes, e.g., between real-time text and audio. 329 Deaf, hard-of-hearing and mainstream users may invoke ToIP services 330 for many different reasons: 332 - Because they are in a noisy environment, e.g., in a machine room of 333 a factory where listening is difficult. 334 - Because they are busy with another call and want to participate in 335 two calls at the same time. 336 - For implementing text and/or speech recording services (e.g., text 337 documentation/ audio recording for legal/clarity/flexibility 338 purposes). 339 - To overcome language barriers through speech translation and/or 340 transcoding services. 341 - Because of hearing loss, deafness or tinnitus as a result of the 342 aging process or for any other reason, thus creating a need to 343 replace or complement voice with real-time text in conversational 344 sessions. 346 In many of the above examples, text may accompany speech. The text 347 could be displayed side by side, or in a manner similar to subtitling 348 in broadcasting environments, or in any other suitable manner. This 349 could occur with users who are hard of hearing and also for mixed 350 media calls with both hearing and deaf people participating in the 351 call. 353 A ToIP user may wish to call another ToIP user, or join a conference 354 session involving several users or initiate or join a multimedia 355 session, such as a Total Conversation session. 357 5.2 358 Detailed requirements for ToIP 360 The following sections lists individual requirements for ToIP. Each 361 requirement has been given a uniquely identifier (R1, R2, etc). 362 Section 6 (Implementation Framework) describes how to implement ToIP 363 based on these requirements and using existing protocols and 364 techniques. 366 5.2.1 367 Session control and set-up requirements 369 Users will set up a session by identifying the remote party or the 370 service they want to connect to. However, conversations could be 371 started using a mode other than the real-time text. 373 Simultaneous or alternating use of voice and real-time text is used 374 by a large number of users who can send voice but must receive text 375 (due to a hearing impairment), or who can hear but must send text 376 (due to a speech impairment). 378 R1: It SHOULD be possible to start conversations in any mode (real- 379 time text, voice, video) or combination of modes. 381 R2: It MUST be possible for the users to switch to real-time text, or 382 add real-time text as an additional modality, during the 383 conversation. 385 R3: Systems supporting ToIP MUST allow users to select any of the 386 supported conversation modes at any time, including mid-conversation. 388 R4: Systems SHOULD allow the user to specify a preferred mode of 389 communication, with the ability to fall back to alternatives that the 390 user has indicated are acceptable. 392 R5: If the user requests simultaneous use of real-time text and 393 audio, and this is not possible either because the system only 394 supports alternate modalities or because of constraints in the 395 network, the system MUST try to establish communication with best 396 effort. 398 R6: If the user has expressed a preference for real-time text, 399 establishment of a connection including real-time text MUST have 400 priority over other outcomes of the session setup. 402 R7: It SHOULD be possible to use the real-time text medium in 403 conference sessions in a similar way to how audio is handled and 404 video is displayed. 406 Real-time text in conferences can be used both for letting individual 407 participants use the text medium (for example, for sidebar 408 discussions in text while listening to the main conference audio), as 409 well as for central support of the conference with real time text 410 interpretation of speech. 412 R8: During session set up, it SHOULD be possible for the users to 413 indicate if the caller wants to use voice and real-time text 414 simutaneously as part of the conversation. 416 R9: Session set up and negotiation of modalities must allow users to 417 specify the language of the real-time text to be used. (It is 418 recommended that similar functionality is provided for the video part 419 of the conversation, i.e. to specify the sign language being used). 421 5.2.2 422 Transport requirements 424 ToIP will often be used to access a relay service [I], allowing real- 425 time text users to communicate with voice users. With relay services, 426 it is crucial that text characters are sent as soon as possible after 427 they are entered. While buffering may be done to improve efficiency, 428 the delays SHOULD be kept minimal. In particular, buffering of whole 429 lines of text will not meet character delay requirements. 431 R10: Characters must be transmitted soon after entry of each 432 character so that the maximum delay requirement can be met. A delay 433 time of one second is regarded good, while a delay of two seconds is 434 possible to use. 436 R11: It must be possible to transmit characters at a rate sufficient 437 to support fast human typing as well as speech to text methods of 438 generating conversation text. A rate of 20 characters per second is 439 regarded sufficient. 441 R12: a ToIP service must be able to deal with international character 442 sets. 444 R13: Where it is possible, loss of real-time text during transport 445 should be detected and the user should be informed. 447 R14: Transport of real-time text should be as robust as possible, so 448 as to minimize loss of characters. 450 R15: Where possible, it must be possible to send and receive real- 451 time text simultaneously. 453 5.2.3 454 Transcoding service requirements 456 If the User Agents of different participants indicate that there is 457 an incompatibility between their capabilities to support certain 458 media types, e.g. one terminal only offering T.140 over IP as 459 described in RFC4103 [5] and the other one only supporting audio, the 460 user might want to invoke a transcoding service. 462 Some users may indicate their preferred modality to be audio while 463 others may indicate real-time text. In this case, transcoding 464 services might be needed for text-to-speech (TTS) and speech-to-text 465 (STT). Other examples of possible scenarios for including a relay 466 service in the conversation are: text bridging after conversion from 467 speech, audio bridging after conversion from real-time text, etc. 469 A number of requirements, motivations and implementation guidelines 470 for relay service invocation can be found in RFC 3351 [2]. 472 R16: It MUST be possible for users to invoke a transcoding service 473 where such service is available. 475 R17: It MUST be possible for users to indicate their preferred 476 modality. 478 R18: The requirements for transcoding services need to be negotiated 479 in real-time to set up the session. 481 R19: Adding or removing a relay service MUST be possible without 482 disrupting the current session. 484 R20: When setting up a session, it MUST be possible for a user to 485 determine the type of relay service requested (e.g., speech to text 486 or text to speech). The specification of a type of relay MUST include 487 a language specifier. 489 R21: It SHOULD be possible to route the session to a preferred relay 490 service even if the user invokes the session from another region or 491 network than that usually used. 493 5.2.4 494 Presentation and User control requirements 496 R22: User Agents for ToIP services must have alerting methods (e.g., 497 for incoming sessions) that can be used by deaf and hard of hearing 498 people or provide a range of alternative, but equivalent, alerting 499 methods that can be selected by all users, regardless of their 500 abilities. 502 R23: Where real-time text is used in conjunction with other media, 503 exposure of user control functions through the User Interface needs 504 to be done in an equivalent manner for all supported media. 506 In other words, where certain call control functions are available 507 for the audio media part of a session, these functions MUST also be 508 supported for the real-time text media part of the same session. For 509 example, call transfer must act on all media in the session. 511 R24: If present, identification of the originating party (for example 512 in the form of a URL or a CLI) MUST be clearly presented to the user 513 in a form suitable for the user BEFORE the session invitation is 514 answered. 516 R25: When a session invitation involving ToIP originates from a PSTN 517 text telephone (e.g. transcoded via a text gateway), this SHOULD be 518 indicated to the user. The ToIP client MAY adjust the presentation of 519 the real-time text to the user as a consequence. 521 R26: An indication should be given to the user when real-time text is 522 available during the call, even if it is not invoked at call setup 523 (e.g. when only voice and/or video is used initially). 525 R27: The user MUST be informed of any change in modalities. 527 R28: Users must be presented with appropriate session progress 528 information at all times. 530 R29: Answering machine functions SHOULD be provided by the User 531 Agent. 533 R30: When the answering machine function is enabled on the User 534 Agent, alerting of the user SHOULD still be possible and users SHOULD 535 be able to take over control from the answering machine function at 536 any time. 538 R31: Users SHOULD be able to save the text portion of a conversation. 540 R32: The presentation of the conversation should be done in such a 541 way that users can easily identify which party generated any given 542 portion of text. 544 5.2.5 545 Interworking requirements 547 There is a range of existing real-time text services. There is also a 548 range of network technologies that could support real-time text 549 services. 551 Real-time/Interactive texting facilities exist already in various 552 forms and on various networks. On the PSTN, it is commonly referred 553 to as text telephony. 555 Text gateways are used for converting between different media types. 556 They could be used between networks or within networks where 557 different transport technologies are used. 559 R33: ToIP SHOULD provide interoperability with text conversation 560 features in other networks, for instance the PSTN. 562 R34: When communicating via a gateway to other networks and 563 protocols, the ToIP service SHOULD support the functionality for 564 alternating or simultaneous use of modalities as offered by the 565 interworking network. 567 R35: Address information, both called and calling, SHOULD be 568 transferred, and possibly converted, when interworking between 569 different networks. 571 R36: When interworking with other networks and services, the ToIP 572 service SHOULD provide buffering mechanisms to deal with delays in 573 call setup, transmission speeds and/or to interwork with half duplex 574 services. 576 5.2.5.1 577 PSTN Interworking requirements 579 Analog text telephony is being used in many countries, mainly by 580 deaf, hard of hearing and speech-impaired individuals. 582 R37: ToIP services MUST provide interworking with PSTN legacy text 583 telephony devices. 585 R38: When interworking with PSTN legacy text telephony services, 586 alternating text and voice function MAY be supported. (Called "voice 587 carry over (VCO) and hearing carry over (HCO)"). 589 5.2.5.2 590 Cellular Interworking requirements 592 As mobile communications have been adopted widely, various solutions 593 for real-time texting while on the move have been developed. ToIP 594 services should provide interworking with such services as well. 596 Alternative means of transferring the Text telephony data have been 597 developed when TTY services over cellular was mandated by the FCC in 598 the USA. They are a) "No-gain" codec solution, b) the Cellular Text 599 Telephony Modem (CTM) solution [8] and c) "Baudot mode" solution. 601 The GSM and 3G standards from 3GPP make use of the CTM modem in the 602 voice channel for text telephony. However, implementations also exist 603 that use the data channel to provide such functionality. Interworking 604 with these solutions SHOULD be done using text gateways that set up 605 the data channel connection at the GSM side and provide ToIP at the 606 other side. 608 R39: a ToIP service SHOULD provide interworking with mobile text 609 conversation services. 611 5.2.5.3 612 Instant Messaging Interworking requirements 614 Many people use Instant Messaging to communicate via the Internet 615 using text. Instant Messaging usually transfers blocks of text rather 616 than streaming as is used by ToIP. Usually a specific action is 617 required by the user to activate transmission, such as pressing the 618 ENTER key or a send button. As such, it is not a replacement for ToIP 619 and in particular does not meet the needs for real time conversations 620 including those of deaf, hard of hearing and speech-impaired users as 621 defined in RFC 3351 [2]. It is unsuitable for communications through 622 a relay service [I]. The streaming nature of ToIP provides a more 623 direct conversational user experience and, when given the choice, 624 users may prefer ToIP. 626 R39: a ToIP service MAY provide interworking with Instant Messaging 627 services. 629 6. 630 Implementation Framework 632 This section describes an implementation framework for ToIP that 633 meets the requirements and offers the functionality as set out in 634 section 5. The framework presented here uses existing standards that 635 are already commonly used for voice based conversational services on 636 IP networks. 638 6.1 639 Framework of general implementation 641 ToIP uses the Session Initiation Protocol (SIP) [3] to set up, 642 control and tear down the connections between users whilst the media 643 is transported using the Real-Time Transport Protocol (RTP) [4] as 644 described in RFC4103 [5]. 646 SIP [3] allows participants to negotiate all media including real- 647 time text conversation [5]. This is a highly desirable function for 648 all IP telephony users but essential for deaf, hard of hearing, or 649 speech impaired people who have limited or no use of the audio path 650 of the call. Even for mainstream users, media negotiations like real- 651 time text are also very useful in many circumstances as described 652 earlier. 654 The ability of SIP to set up conversation sessions from any location, 655 as well as its privacy and security provisions, MUST be maintained by 656 ToIP services. 658 Real-time text conversation based on the presentation protocol T.140 659 [9], in addition to audio and video communications, is a valuable 660 service for many users, including those on non-IP networks. T.140 661 also provides for basic real-time editing of the text. 663 6.2 664 Framework of detailed implementation 666 6.2.1 667 Session control and set-up 669 ToIP services MUST use the Session Initiation Protocol (SIP) [3] 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 6.2.1.1 678 Pre-session setup 680 The requirements of the user to be reached at a consistent address 681 and to store preferences for evaluation at session setup are met by 682 pre-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 689 be 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 preferences 697 for real-time text in order to accept or reject the session.The 698 actions taken can be based on the called user�s preferences defined 699 as part of the pre-session setup registration. For example, if the 700 user is called by another party, and it is determined that a 701 transcoding server is needed, the session should be re-directed or 702 otherwise handled accordingly. 704 6.2.1.2 705 Basic Point-to-Point Session setup 707 A point-to-point session takes place between two parties. For ToIP, 708 one or both of the communicating parties will indicate real-time text 709 as a possible or preferred medium for conversation using SIP in the 710 session setup. 712 The following features MAY be implemented to facilitate the session 713 establishment using ToIP: 715 a. Caller Preferences: SIP headers (e.g., Contact)[11] can be used to 716 show that ToIP is the medium of choice for communications. 718 b. Called Party Preferences [12]: The called party being passive can 719 formulate a clear rule indicating how a session should be handled 720 either using real-time text as a preferred medium or not, and whether 721 a designated SIP proxy needs to handle this session or it will be 722 handled in the SIP user agent. 724 c. SIP Server support for User Preferences: It is RECOMMENDED that 725 SIP servers also handle the incoming sessions in accordance with 726 preferences expressed for real-time text. The SIP Server can also 727 enforce ToIP policy rules for communications (e.g. use of the 728 transcoding server for ToIP). 730 6.2.1.3 731 Addressing 733 The SIP [3] addressing schemes MUST be used for all entities in a 734 ToIP session. For example, SIP URL�s or Tel URL�s are used for 735 caller, called party, user devices, and servers (e.g., SIP server, 736 Transcoding server). 738 6.2.1.4 739 Session Negotiations 741 The Session Description Protocol (SDP) used in SIP [3] provides the 742 capabilities to indicate real-time text as a medium in the session 743 setup. RFC 4103 [5] uses the RTP payload types "text/red" and 744 "text/t140" for support of ToIP which can be indicated in the SDP as 745 a part of the SIP INVITE, OK and SIP/200/ACK media negotiations. In 746 addition, SIP�s offer/answer model [13] can also be used in 747 conjunction with other capabilities including the use of a 748 transcoding server for enhanced session negotiations [14,15,16]. 750 Systems SHOULD provide a best-effort approach to answering 751 invitations for session set-up and users SHOULD be informed when the 752 session is accepted by the other party. On all systems that both 753 inform users of session status and support ToIP, this information 754 MUST be available in textual form and MAY also be provided in other 755 media. 757 6.2.1.5 758 Additional session control 760 Systems that support additional session control features, for example 761 call waiting, forwarding, hold etc on voice sessions, MUST offer this 762 functionality for text sessions. 764 6.2.2 765 Transport 767 A ToIP service MUST always support at least one real-time text media 768 type. 770 ToIP services MUST support the Real-Time Transport Protocol (RTP) [4] 771 according to the specification of RFC4103 [4] for the transport of 772 text between participants. 774 RFC4103 describes the transmission of T.140 [9] real-time text on IP 775 networks. 777 In order to enable the use of international character sets, the 778 transmission format for text conversation SHALL be UTF-8 [17], in 779 accordance with ITU-T T.140. 781 If real-time text is detected to be missing after transmission, there 782 SHOULD be a "text loss" indication in the real-time text as specified 783 in T.140 Addendum 1 [9]. 785 ToIP uses RTP as the default transport protocol for the transmission 786 of real-time text via the medium "text/t140" as specified in RFC 4103 787 [5]. 789 The redundancy method of RFC 4103 [5] SHOULD be used to significantly 790 increase the reliability of the real-time text transmission. A 791 redundancy level using 2 generations gives very reliable results and 792 is therefore strongly RECOMMENDED. 794 Real-time text capability MUST be announced in SDP by a declaration 795 similar to this example: 797 m=text 11000 RTP/AVP 100 98 798 a=rtpmap:98 t140/1000 799 a=rtpmap:100 red/1000 800 a=fmtp:100 98/98/98 802 By having this single coding and transmission scheme for real time 803 text defined in the SIP session control environment, the opportunity 804 for interoperability is optimized. However, if good reasons exist, 805 other transport mechanisms MAY be offered and used for the T.140 806 coded text provided that proper negotiation is introduced, but RFC 807 4103 [5] transport MUST be used as both the default and the fallback 808 transport. 810 Real-time text transmission from a terminal SHALL be performed 811 character by character as entered, or in small groups of characters, 812 so that no character is delayed from entry to transmission by more 813 than 300 milliseconds. 815 The text transmission SHALL allow a rate of at least 30 characters 816 per second. 818 6.2.3 819 Transcoding services 821 The right to include a transcoding service MUST NOT require user 822 registration in any specific SIP registrar, but MAY require 823 authorisation of the SIP registrar to invoke the service. 825 A specific type of transcoding service in a ToIP environment is a 826 relay service. The relay service acts as an intermediary between two 827 or more callers using different media or different media encoding 828 schemes. 830 The basic text relay service allows a translation of speech to real- 831 time text and real-time text to speech, which enables hearing and 832 speech impaired callers to communicate with hearing callers. Even 833 though this document focuses on ToIP, we want to remind readers that 834 other relay services exist, like video relay services transcoding 835 speech to sign language and vice versa where the signing is 836 communicated using video. 838 It is RECOMMENDED that ToIP implementations make the invocation and 839 use of relay services as easy as possible. It MAY happen 840 automatically when the session is being set up based on any valid 841 indication or negotiation of supported or preferred media types. A 842 transcoding framework document using SIP [14] describes invoking 843 relay services, where the relay acts as a conference bridge or uses 844 the third party control mechanism. ToIP implementations SHOULD 845 support this transcoding framework. 847 6.2.4 848 Presentation and User control functions 850 6.2.4.1 851 Progress and status information 853 During a conversation that includes ToIP, status and session progress 854 information MUST be provided in a textual form so users can perform 855 all session control functions. That information MUST be equivalent to 856 session progress information delivered in any other format, for 857 example audio. 859 Session progress information SHOULD use simple language so that as 860 many users as possible can understand it. The use of jargon or 861 ambiguous terminology SHOULD be avoided. It is RECOMMENDED that text 862 information be used together with icons to symbolise the session 863 progress information. 865 There MUST be a clear indication, in a modality useful to the user, 866 whenever a session is connected or disconnected. A user SHOULD never 867 be in doubt about the status of the session, even if the user is 868 unable to make use of the audio or visual indication. For example, 869 tactile indications could be used by deafblind individuals. 871 In summary, it SHOULD be possible to observe indicators about: 873 - Incoming session 874 - Availability of real-time text, voice and video channels 875 - Session progress 876 - Incoming real-time text 877 - Any loss in incoming real-time text 878 - Typed and transmitted real-time text. 880 6.2.4.2 881 Alerting 883 For users who cannot use the audible alerter for incoming sessions, 884 it is RECOMMENDED to include a tactile as well as a visual indicator. 886 Among the alerting options are alerting by the User Agent�s User 887 Interface and specific alerting user agents registered to the same 888 registrar as the main user agent. 890 It should be noted that external alerting systems exist and one 891 common interface for triggering the alerting action is a contact 892 closure between two conductors. 894 6.2.4.3 895 Answering Machine 897 Systems for ToIP MAY support an answering machine function, 898 equivalent to answering machines on telephony networks. If an 899 answering machine function is supported, it MUST support at least 160 900 characters for the greeting message. It MUST support incoming real- 901 time text message storage of a minimum of 4096 characters, although 902 systems MAY support much larger storage. It is RECOMMENDED that 903 systems support storage of at least 20 incoming messages of up to 904 16000 characters per message. 906 When the answering machine is activated, user alerting SHOULD still 907 take place. The user SHOULD be allowed to monitor the auto-answer 908 progress and where this is provided the user SHOULD be allowed to 909 intervene during any stage of the answering machine procedure and 910 take control of the session. 912 6.2.4.4 913 Text presentation 915 When the display of text conversation is included in the design of 916 the end user equipment, the display of the dialogue SHOULD be made so 917 that it is easy to differentiate the text belonging to each party in 918 the conversation. This could be done using color, positioning of the 919 text (i.e. incoming real-time text and outgoing real-time text in 920 different display areas), by in-band identifiers of the parties or by 921 a combination of any of these techniques. 923 ToIP SHOULD handle characters such as new line, erasure and alerting 924 during a session as specified in ITU-T T.140 [9]. 926 6.2.4.5 927 File storage 929 Systems that support ToIP MAY save the text conversation to a file. 930 This SHOULD be done using a standard file format. For example: a UTF8 931 text file in XHTML format [18] including timestamps, party names (or 932 addresses) and the text conversation. 934 6.2.5 935 Interworking functions 937 A number of systems for real time text conversation already exist as 938 well as a number of message oriented text communication systems. 939 Interoperability is of interest between ToIP and some of these 940 systems. 942 Interoperation of half-duplex and full-duplex protocols MAY require 943 text buffering. Some intelligence will be needed to determine when to 944 change direction when operating in half-duplex mode. Identification 945 may be required of half-duplex operation either at the "user" level 946 (ie. users must inform each other) or at the "protocol" level (where 947 an indication must be sent back to the Gateway). However, the special 948 care needs to be taken to provide the best possible real-time 949 performance. 951 6.2.5.1 952 PSTN Interworking 954 Analog text telephony is cumbersome because of incompatible national 955 implementations where interworking was never considered. A large 956 number of these implementations have been documented in ITU-T V.18 957 [19], which also defines the modem detection sequences for the 958 different text protocols. The modem type identification may in rare 959 cases take considerable time depending on user actions. 961 To resolve analog textphone incompatibilities, text telephone 962 gateways are needed to transcode incoming analog signals into T.140 963 and vice versa. The modem capability exchange time can be reduced by 964 the text telephone gateways initially assuming the analog text 965 telephone protocol used in the region where the gateway is located. 966 For example, in the USA, Baudot [II] might be tried as the initial 967 protocol. If negotiation for Baudot fails, the full V.18 modem 968 capability exchange will take place. In the UK, ITU-T V.21 [III] 969 might be the first choice. 971 In particular transmission of interactive text on PSTN networks takes 972 place using a variety of codings and modulations, including ITU-T 973 V.21 [III], Baudot [II], DTMF, V.23 [IV] and others. Many 974 difficulties have arisen as a result of this variety in text 975 telephony protocols and the ITU-T V.18 [19] standard was developed to 976 address some of these issues. 978 ITU-T V.18 [19] offers a native text telephony method plus it defines 979 interworking with current protocols. In the interworking mode, it 980 will recognise one of the older protocols and fall back to that 981 transmission method when required. 983 Text gateways MUST use the ITU-T V.18 [19] standard at the PSTN side. 984 A text gateway MUST act as a SIP User Agent on the IP side and 985 support RFC4103 text transport. 987 PSTN-ToIP gateways MUST allow alternating use of real-time text and 988 voice if the PSTN textphone involved at the PSTN side of the session 989 supports this. (This mode is often called VCO/HCO). 991 Calling party identification information, such as CLI, MUST be passed 992 by gateways and converted to an approapriate form if required. 994 While ToIP allows receiving and sending real-time text simultaneously 995 and is displayed on a split screen, many analog text telephones 996 require users to take turns typing. 997 This is because many text telephones operate strictly half duplex. 998 Only one can transmit text at a time. The users apply strict turn- 999 taking rules. 1001 There are several text telephones which communicate in full duplex, 1002 but merge transmitted text and received text in the same line in the 1003 same display window. And also here do the users apply strict turn 1004 taking rules. 1005 Native V.18 text telephones support full duplex and separate display 1006 from reception and transmission so that the full duplex capability 1007 can be used fully. Such devices could use the ToIP split screen as 1008 well, but almost all text telephones use a restricted character set 1009 and many use low text transmission speeds (4 to 7 charcters per 1010 second). 1012 That is why it is important for the ToIP user to know that he or she 1013 is connected with an analog text telephone. The "txp" media content 1014 attribute [10]SHOULD be used to indicate that the call originates 1015 from a PSTN text telephone (e.g. via an ATA or a text gateway). 1017 6.2.5.2 1018 Mobile Interworking 1020 Mobile wireless (or Cellular) circuit switched connections provide a 1021 digital real-time transport service for voice or data. The access 1022 technologies include GSM, CDMA, TDMA, iDen and various 3G 1023 technologies. 1025 ToIP may be supported over the cellular wireless packet switched 1026 service. It interfaces to the Internet. 1028 The following sections describe how mobile text telephony is 1029 supported. 1031 6.2.5.2.1 1032 Cellular "No-gain" 1034 The "No-gain" text telephone transporting technology uses specially 1035 modified EFR [20] and EVR [21] speech vocoders in mobile terminals 1036 used to provide a text telephony call. It provides full duplex 1037 operation and supports alternating voice and text ("VCO/HCO"). It is 1038 dedicated to CDMA and TDMA mobile technologies and the US Baudot 1039 (i.e. 45 bit/s) type of text telephones. 1041 6.2.5.2.2 1042 Cellular Text Telephone Modem (CTM) 1044 CTM [8] is a technology independent modem technology that provides 1045 the transport of text telephone characters at up to 10 characters/sec 1046 using modem signals that can be carried by many voice codecs and uses 1047 a highly redundant encoding technique to overcome the fading and cell 1048 changing losses. 1050 6.2.5.2.3 1051 Cellular "Baudot mode" 1053 This term is often used by cellular terminal suppliers for a GSM 1054 cellular phone mode that allows TTYs to operate into a cellular phone 1055 and to communicate with a fixed line TTY. Thus it is a common name 1056 for the "No-Gain" and the CTM solutions when applied to the Baudot 1057 type textphones. 1059 6.2.5.2.4 1060 Mobile data channel mode 1062 Many mobile terminals allow the use of the circuit switched data 1063 channel to transfer data in real-time. Data rates of 9600 bit/s are 1064 usually supported on the 2G mobile network. Gateways provide 1065 interoperability with PSTN textphones. 1067 6.2.5.2.5 1068 Mobile ToIP 1070 ToIP could be supported over mobile wireless packet switched services 1071 that interface to the Internet. For 3GPP 3G services, ToIP support is 1072 described in 3G TS 26.235 [22]. 1074 6.2.5.3 1075 Instant Messaging Interworking 1077 Text gateways MAY be used to allow interworking between Instant 1078 Messaging systems and ToIP solutions. Because Instant Messaging is 1079 based on blocks of text, rather than on a continuous stream of 1080 characters like ToIP, gateways MUST transcode between the two 1081 formats. Text gateways for interworking between Instant Messaging and 1082 ToIP MUST apply a procedure for bridging the different conversational 1083 formats of real-time text versus text messaging. The following advice 1084 may improve user experience for both parties in a call through a 1085 messaging gateway. 1087 a. Concatenate individual characters originating at the ToIP side 1088 into blocks of text. 1090 b. When the length of the concatenated message becomes longer than 50 1091 characters, the buffered text SHOULD be transmitted to the Instant 1092 Messaging side as soon as any non-alphanumerical character is 1093 received from the ToIP side. 1095 c. When a new line indicator is received from the ToIP side, the 1096 buffered characters up to that point, including the carriage return 1097 and/or line feed characters, SHOULD be transmitted to the Instant 1098 Messaging side. 1100 d. When the ToIP side has been idle for at least 5 seconds, all 1101 buffered text up to that point SHOULD be transmitted to the Instant 1102 Messaging side. 1104 e. Text Gateways must be capable to maintain the real-time 1105 performance for ToIP while providing the interworking services. 1107 It is RECOMMENDED that during the session, both users are constantly 1108 updated on the progress of the text input. 1109 Many Instant Messaging protocols signal that a user is typing to the 1110 other party in the conversation. Text gateways between such Instant 1111 Messaging protocols and ToIP MUST provide this signaling to the 1112 Instant Messaging side when characters start being received, or at 1113 the beginning of the conversation. 1115 At the ToIP side, an indicator of writing the Instant Message MUST be 1116 present where the Instant Messaging protocol provides one. For 1117 example, the real-time text user MAY see ". . . waiting for replying 1118 IM. . . " and when 5 seconds have passed another . (dot) can be 1119 shown. 1121 Those solutions will reduce the difficulties between streaming and 1122 blocked text services. 1124 Even though the text gateway can connect Instant Messaging and ToIP, 1125 the best solution is to take advantage of the fact that the user 1126 interfaces and the user communities for instant messaging and ToIP 1127 telephony are very similar. After all, the character input, the 1128 character display, Internet connectivity and SIP stack can be the 1129 same for Instant Messaging (SIMPLE) and ToIP. Thus, the user may 1130 simply use different applications for ToIP and text messaging in the 1131 same terminal. 1133 Devices that implement Instant Messaging SHOULD implement ToIP as 1134 described in this document so that a more complete text communication 1135 service can be provided. 1137 6.2.5.4 1138 Interworking through gateways 1140 Transcoding of text to and from other coding formats MAY need to take 1141 place in gateways between ToIP and other forms of text conversation, 1142 for example to connect to a PSTN text telephone. 1144 Text gateways MUST allow for the differences that result from 1145 different text protocols. The protocols to be supported will depend 1146 on the service requirements of the Gateway. 1148 Session setup through gateways to other networks MAY require the use 1149 of specially formatted addresses or other mechanisms for invoking 1150 those gateways. 1152 Different data rates of different protocols MAY require text 1153 buffering. 1155 When text gateway functions are invoked, there will be a need for 1156 intermediate storage of characters before transmission to a device 1157 receiving text slower than the transmitting speed of the sender. Such 1158 temporary storage SHALL be dimensioned to adjust for receiving at 30 1159 characters per second and transmitting at 6 characters per second for 1160 up to 4 minutes (i.e. less than 3000 characters). 1162 ToIP interworking requires a method to invoke a text gateway. As 1163 described previously, these text gateways MUST act as User Agents at 1164 the IP side. The capabilities of the gateway during the call will be 1165 determined by the call capabilities of the terminal that is using the 1166 gateway. For example, a PSTN textphone is generally only able to 1167 receive voice and real-time text, so the gateway will only allow ToIP 1168 and audio. 1170 Examples of possible scenarios for invocation of the text gateway 1171 are: 1173 a. PSTN textphone users dial a prefix number before dialing out. 1174 b. Separate real-time text subscriptions, linked to the phone number 1175 or terminal identifier/ IP address. 1176 c. Real-time text capability indicators. 1177 d. Real-time text preference indicator. 1178 e. Listen for V.18 modem modulation text activity in all PSTN calls 1179 and routing of the call to an appropriate gateway. 1180 f. Call transfer request by the called user. 1181 g. Placing a call via the web, and using one of the methods described 1182 here 1183 h. Text gateways with its own telephone number and/or SIP address. 1184 (This requires user interaction with the gateway to place a call). 1185 i. ENUM address analysis and number plan 1186 j. Number or address analysis leads to a gateway for all PSTN calls. 1188 6.2.5.5 1189 Multi-functional Combination gateways 1191 In practice many interworking gateways will be implemented as 1192 gateways that combine different functions. As such, a text gateway 1193 could be built to have modems to interwork with the PSTN and support 1194 both Instant Messaging as well as ToIP. Such interworking functions 1195 are called Combination gateways. 1197 Combination gateways MUST provide interworking between all of their 1198 supported text based functions. For example, a Text gateway that has 1199 modems to interwork with the PSTN and that support both Instant 1200 Messaging and ToIP MUST support the following interworking functions: 1202 - PSTN text telephony to ToIP. 1203 - PSTN text telephony to Instant Messaging. 1205 - Instant Messaging to ToIP. 1207 6.2.5.6 1208 Character set transcoding 1210 Gateways between the ToIP network and other networks MAY need to 1211 transcode text streams. ToIP makes use of the ISO 10646 character 1212 set. Most PSTN textphones use a 7-bit character set, or a character 1213 set that is converted to a 7-bit character set by the V.18 modem. 1215 When transcoding between character sets and T.140 in gateways, 1216 special consideration MUST be given to the national variants of the 7 1217 bit codes, with national characters mapping into different codes in 1218 the ISO 10646 code space. The national variant to be used could be 1219 selectable by the user on a per call basis, or be configured as a 1220 national default for the gateway. 1222 The indicator of missing text in T.140, specified in T.140 amendment 1223 1, cannot be represented in the 7 bit character codes. Therefore the 1224 indicator of missing text SHOULD be transcoded to the � (apostrophe) 1225 character in legacy text telephone systems, where this character 1226 exists. For legacy systems where the character � does not exist, the 1227 . (full stop) character SHOULD be used instead. 1229 7. 1230 Further recommendations for implementers and service providers 1232 7.1 1233 Access to Emergency services 1235 It MUST be possible to place an emergency call using ToIP and it MUST 1236 be possible to use a relay service in such call. The emergency 1237 service provided to users utilising the real-time text medium MUST be 1238 equivalent to the emergency service provided to users utilising 1239 speech or other media. 1241 A text gateway MUST be able to route real-time text calls to 1242 emergency service providers when any of the recognised emergency 1243 numbers that support text communications for the country or region 1244 are called e.g. "911" in USA and "112" in Europe. Routing real-time 1245 text calls to emergency services MAY require the use of a transcoding 1246 service. 1248 A text gateway with cellular wireless packet switched services MUST 1249 be able to route real-time text calls to emergency service providers 1250 when any of the recognized emergency numbers that support real-time 1251 text communication for the country is called. 1253 7.2 1254 Home Gateways or Analog Terminal Adapters 1256 Analog terminal adapters (ATA) using SIP based IP communication and 1257 RJ-11 connectors for connecting traditional PSTN devices SHOULD 1258 enable connection of legacy PSTN text telephones [23]. 1260 These adapters SHOULD contain V.18 modem functionality, voice 1261 handling functionality, and conversion functions to/from SIP based 1262 ToIP with T.140 transported according to RFC 4103 [4], in a similar 1263 way as it provides interoperability for voice sessions. 1265 If a session is set up and text/t140 capability is not declared by 1266 the destination endpoint (by the end-point terminal or the text 1267 gateway in the network at the end-point), a method for invoking a 1268 transcoding server SHALL be used. If no such server is available, the 1269 signals from the textphone MAY be transmitted in the voice channel as 1270 audio with high quality of service. 1272 NOTE: It is preferred that such analog terminal adaptors do use RFC 1273 4103 [5] on board and thus act as a text gateway. Sending textphone 1274 signals over the voice channel is undesirable due to possible 1275 filtering and compression and packet loss between the end-points. 1276 This can result in character loss in the textphone conversation or 1277 even not allowing the textphones to connect to each other. 1279 7.3 1280 User Mobility 1282 ToIP User Agents SHOULD use the same mechanisms as other SIP User 1283 Agents to resolve mobility issues. It is RECOMMENDED that users use a 1284 SIP-address, resolved by a SIP registrar, to enable basic user 1285 mobility. Further mechanisms are defined for all session types for 3G 1286 IP multimedia systems. 1288 7.4 1289 Firewalls and NATs 1291 ToIP uses the same signaling and transport protocols as VoIP. Hence, 1292 the same firewall and NAT solutions and network functionality that 1293 apply to VoIP MUST also apply to ToIP. 1295 8. 1296 IANA Considerations 1298 There are no IANA considerations for this specification. 1300 9. 1301 Security Considerations 1303 User confidentiality and privacy need to be met as described in SIP 1304 [3]. For example, nothing should reveal the fact that the ToIP user 1305 might be a person with a hearing or speech impairment. ToIP is after 1306 all a mainstream communication medium for all users. It is up to the 1307 ToIP user to make his or her hearing or speech impairment public. If 1308 a transcoding server is being used, this SHOULD be transparent. 1309 Encryption SHOULD be used on end-to-end or hop-by-hop basis as 1310 described in SIP [3] and SRTP [24]. 1312 Authentication needs to be provided for users in addition to the 1313 message integrity and access control. 1315 Protection against Denial-of-service (DoS) attacks needs to be 1316 provided considering the case that the ToIP users might need 1317 transcoding servers. 1319 10. 1320 Authors� Addresses 1322 The following people provided substantial technical and writing 1323 contributions to this document, listed alphabetically: 1325 Willem Dijkstra 1326 TNO Informatie- en Communicatietechnologie 1327 Eemsgolaan 3 1328 9727 DW Groningen 1329 tel : +31 50 585 77 24 1330 fax : +31 50 585 77 57 1331 Email: willem.dijkstra@tno.nl 1333 Barry Dingle 1334 ACIF, 32 Walker Street 1335 North Sydney, NSW 2060 Australia 1336 Tel +61 (0)2 9959 9111 1337 Mob +61 (0)41 911 7578 1338 Email: btdingle@gmail.com 1340 Guido Gybels 1341 Department of New Technologies 1342 RNID, 19-23 Featherstone Street 1343 London EC1Y 8SL, UK 1344 Tel +44(0)20 7294 3713 1345 Txt +44(0)20 7608 0511 1346 Fax +44(0)20 7296 8069 1347 Email: guido.gybels@rnid.org.uk 1349 Gunnar Hellstrom 1350 Omnitor AB 1351 Renathvagen 2 1352 SE 121 37 Johanneshov 1353 Sweden 1354 Phone: +46 708 204 288 / +46 8 556 002 03 1355 Fax: +46 8 556 002 06 1356 Email: gunnar.hellstrom@omnitor.se 1357 Radhika R. Roy 1358 SAIC 1359 3465-B Box Hill Corporate Center Drive 1360 Abingdon, MD 21009 1361 Tel: 443 402 9041 1362 Email: Radhika.R.Roy@saic.com 1364 Henry Sinnreich 1365 pulver.com 1366 115 Broadhollow Rd 1367 Suite 225 1368 Melville, NY 11747 1369 USA 1370 Tel: +1.631.961.8950 1372 Gregg C Vanderheiden 1373 University of Wisconsin-Madison 1374 Trace R & D Center 1375 1550 Engineering Dr (Rm 2107) 1376 Madison, Wi 53706 1377 USA 1378 Phone +1 608 262-6966 1379 FAX +1 608 262-8848 1380 Email: gv@trace.wisc.edu 1382 Arnoud A. T. van Wijk 1383 Foundation for an Information and Communication Network for the Deaf 1384 and Hard of Hearing 1385 "AnnieS" 1386 www.annies.nl 1387 Email: arnoud@annies.nl 1389 11. 1390 References 1392 11.1 1393 Normative references 1395 1. S. Bradner, "Intellectual Property Rights in IETF Technology", 1396 BCP 79, RFC 3979, IETF, March 2005. 1398 2. Charlton, Gasson, Gybels, Spanner, van Wijk, "User Requirements 1399 for the Session Initiation Protocol (SIP) in Support of Deaf, 1400 Hard of Hearing and Speech-impaired Individuals", RFC 3351, 1401 IETF, August 2002. 1403 3. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 1404 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session 1405 Initiation Protocol", RFC 3621, IETF, June 2002. 1407 4. H. Schulzrinne, S.Casner, R. Frederick, V. Jacobsone, "RTP: A 1408 Transport Protocol for Real-Time Applications", RFC 3550, IETF, 1409 July 2003. 1411 5. G. Hellstrom, P. Jones, "RTP Payload for Text Conversation", RFC 1412 4103, IETF, June 2005. 1414 6. ITU-T Recommendation F.703,"Multimedia Conversational Services", 1415 November 2000. 1417 7. S. Bradner, "Key words for use in RFCs to Indicate Requirement 1418 Levels", BCP 14, RFC 2119, IETF, March 1997 1420 8. 3GPP TS 26.226 "Cellular Text Telephone Modem Description" 1421 (CTM). 1423 9. ITU-T Recommendation T.140, "Protocol for Multimedia Application 1424 Text Conversation" (February 1998) and Addendum 1 (February 1425 2000). 1427 10. J. Hautakorpi, G. Camarillo, "The SDP (Session Description 1428 Protocol) Content Attribute", IETF, February 2006 - Work in 1429 Progress. 1431 11. J. Rosenberg, H. Schulzrinne, P. Kyzivat, "Indicating User Agent 1432 Capabilities in the Session Initiation Protocol (SIP)", RFC 1433 3840, IETF, August 2004 1435 12. J. Rosenberg, H. Schulzrinne, P. Kyzivat, "Caller Preferences 1436 for the Session Initiation Protocol (SIP)", RFC 3841, IETF, 1437 August 2004 1439 13. J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the 1440 Session Description Protocol (SDP)", RFC 3624, IETF, June 2002. 1442 14. G. Camarillo, "Framework for Transcoding with the Session 1443 Initiation Protocol" IETF Nov 2005 - Work in progress. 1445 15. G. Camarillo, H. Schulzrinne, E. Burger, and A. van Wijk, 1446 "Transcoding Services Invocation in the Session Initiation 1447 Protocol (SIP) Using Third Party Call Control (3pcc)" RFC 4117, 1448 IETF, June 2005. 1450 16. G. Camarillo, "The SIP Conference Bridge Transcoding Model," 1451 IETF, Jan 2006 - Work in Progress. 1453 17. Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1454 3629, IETF,November 2003. 1456 18. "XHTML 1.0: The Extensible HyperText Markup Language: A 1457 Reformulation of HTML 4 in XML 1.0", W3C Recommendation. 1458 Available at http://www.w3.org/TR/xhtml1. 1460 19. ITU-T Recommendation V.18,"Operational and Interworking 1461 Requirements for DCEs operating in Text Telephone Mode," 1462 November 2000. 1464 20. TIA/EIA/IS-823-A "TTY/TDD Extension to TIA/EIA-136-410 Enhanced 1465 Full Rate Speech Codec (must used in conjunction with 1466 TIA/EIA/IS-840)" 1468 21. TIA/EIA/IS-127-2 "Enhanced Variable Rate Codec, Speech Service 1469 Option 3 for Wideband Spread Spectrum Digital Systems. Addendum 1470 2." 1472 22. "IP Multimedia default codecs". 3GPP TS 26.235 1474 23. H. Sinnreich, S. Lass, and C. Stredicke, "SIP Telephony Device 1475 Requirements and Configuration," IETF, October 2005 - Work in 1476 Progress. 1478 24. Baugher, McGrew, Carrara, Naslund, Norrman, "The Secure Real 1479 Time Transport Protocol (SRTP)", RFC 3711, IETF, March 2004. 1481 25. ITU-T Recommendation F.700,"Framework Recommendation for 1482 Multimedia Services", November 2000. 1484 11.2 1485 Informative references 1487 I. A relay service allows the users to transcode between different 1488 modalities or languages. In the context of this document, relay 1489 services will often refer to text relays that transcode text into 1490 voice and vice-versa. See for example http://www.typetalk.org. 1492 II. TIA/EIA/825 "A Frequency Shift Keyed Modem for Use on the Public 1493 Switched Telephone Network." (The specification for 45.45 and 50 1494 bit/s TTY modems.) 1496 III. International Telecommunication Union (ITU), "300 bits per 1497 second duplex modem standardized for use in the general switched 1498 telephone network". ITU-T Recommendation V.21, November 1988. 1500 IV. International Telecommunication Union (ITU), "600/1200-baud modem 1501 standardized for use in the general switched telephone network". ITU- 1502 T Recommendation V.23, November 1988. 1504 Full Copyright Statement 1506 Copyright (C) The Internet Society (2006). 1508 This document is subject to the rights, licenses and restrictions 1509 contained in BCP 78, and except as set forth therein, the authors 1510 retain all their rights. 1512 This document and the information contained herein are provided on 1513 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1514 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1515 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1516 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1517 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1518 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1520 Intellectual Property 1522 The IETF takes no position regarding the validity or scope of any 1523 Intellectual Property Rights or other rights that might be claimed to 1524 pertain to the implementation or use of the technology described in 1525 this document or the extent to which any license under such rights 1526 might or might not be available; nor does it represent that it has 1527 made any independent effort to identify any such rights. Information 1528 on the procedures with respect to rights in RFC documents can be 1529 found in BCP 78 and BCP 79. 1531 Copies of IPR disclosures made to the IETF Secretariat and any 1532 assurances of licenses to be made available, or the result of an 1533 attempt made to obtain a general license or permission for the use of 1534 such proprietary rights by implementers or users of this 1535 specification can be obtained from the IETF on-line IPR repository at 1536 http://www.ietf.org/ipr. 1538 The IETF invites any interested party to bring to its attention any 1539 copyrights, patents or patent applications, or other proprietary 1540 rights that may cover technology that may be required to implement 1541 this standard. Please address the information to the IETF at ietf- 1542 ipr@ietf.org. 1544 Acknowledgement 1546 Funding for the RFC Editor function is provided by the IETF 1547 Administrative Support Activity (IASA).