idnits 2.17.1 draft-ietf-sipping-toip-01.txt: -(175): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(179): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(573): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(620): 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 3979, Section 5, paragraph 1 on line 1402. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1409. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1415. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** 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: ---------------------------------------------------------------------------- == There are 7 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 476 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 296: '... services MUST ensure that the ...' RFC 2119 keyword, line 299: '... the service SHOULD support all th...' RFC 2119 keyword, line 306: '... While buffering MAY be done to improv...' RFC 2119 keyword, line 307: '...ency, the delays SHOULD be kept as sma...' RFC 2119 keyword, line 308: '... whole lines of text MUST NOT be used....' (121 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '21' on line 1036 looks like a reference -- Missing reference section? '5' on line 1110 looks like a reference -- Missing reference section? '2' on line 157 looks like a reference -- Missing reference section? '3' on line 872 looks like a reference -- Missing reference section? '4' on line 412 looks like a reference -- Missing reference section? 'I' on line 1037 looks like a reference -- Missing reference section? '6' on line 346 looks like a reference -- Missing reference section? '7' on line 832 looks like a reference -- Missing reference section? '8' on line 623 looks like a reference -- Missing reference section? '9' on line 623 looks like a reference -- Missing reference section? '10' on line 918 looks like a reference -- Missing reference section? '12' on line 804 looks like a reference -- Missing reference section? '19' on line 873 looks like a reference -- Missing reference section? 'II' on line 906 looks like a reference -- Missing reference section? 'III' on line 906 looks like a reference -- Missing reference section? '15' on line 960 looks like a reference -- Missing reference section? '16' on line 960 looks like a reference -- Missing reference section? '17' on line 968 looks like a reference -- Missing reference section? '20' on line 1022 looks like a reference -- Missing reference section? '18' on line 1098 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 26 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIPPING WG 3 Internet Draft 4 Document: A. van Wijk (editor) 5 July 18 2005 Viataal 6 Expires: January 17 2006 7 Informational 9 Framework of requirements for real-time text conversation using SIP. 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 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 17, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document provides the framework of requirements for real-time 44 character-by-character interactive text conversation over the IP 45 network using the Session Initiation Protocol and the Transport 46 Protocol for Real-Time Applications. It discusses requirements for 47 real-time Text-over-IP telephony as well as interworking between 48 Text-over-IP telephony and existing text telephony on the PSTN and 49 other networks. 51 A. van Wijk [Page 1 of 28] 52 Table of Contents 54 1. Introduction 3 55 2. Scope 3 56 3. Terminology 3 57 4. Definitions 4 58 5. Framework Description 5 59 5.1. Background 5 60 5.2. Requirements for ToIP 6 61 5.3. Use of SIP and RTP 6 62 5.4. Requirements for ToIP Interworking 9 63 6. Detailed requirements for Text-over-IP 9 64 6.1. Pre-Call Requirements 10 65 6.2 Basic Point-to-Point Call Requirements 10 66 6.2.1 Session Setup 10 67 6.2.2 Addressing 11 68 6.2.3 Alerting and session progress presentation 11 69 6.2.4 Call Negotiations 12 70 6.2.5 Answering 12 71 6.2.6 Actions During Calls 13 72 6.2.7 Additional session control 14 73 6.2.8 File storage 15 74 6.3 Conference Call Requirements for ToIP User Agents 15 75 6.4 Transport via RTP 15 76 6.5 Character Set 16 77 6.6 Transcoding 16 78 6.7 Relay Services 16 79 6.8 Emergency services 17 80 6.9 User Mobility 17 81 6.10 Confidentiality and Security 17 82 7. Interworking Requirements for ToIP 17 83 7.1 ToIP Interworking Gateway Services 17 84 7.2 ToIP and PSTN/ISDN Text-Telephony 18 85 7.3 ToIP and Cellular Wireless circuit switched Text-Telephony 86 18 87 7.3.1 "No-gain" 19 88 7.3.2 Cellular Text Telephone Modem (CTM) 19 89 7.3.3 "Baudot mode" 19 90 7.3.4 Data channel mode 19 91 7.3.5 Common Text Gateway Functions 19 92 7.4 ToIP and Cellular Wireless ToIP 20 93 7.5 Instant Messaging Support 20 94 7.6 IP Telephony with Traditional RJ-11 Interfaces 21 95 7.7 Multi-functional gateways 22 96 7.8 ToIP interoperability with PSTN text telephones. 22 97 7.9 Gateway Discovery 22 98 8. Afterword 23 99 9. Security Considerations 23 100 10. Authors Addresses 24 101 11. References 25 102 11.1 Normative 25 103 11.2 Informative 27 105 A. van Wijk [Page 2 of 28] 106 1. Introduction 108 For many years, text has been in use as a medium for 109 conversational, interactive dialogue between users in a similar 110 way as voice telephony is used. Such interactive text is different 111 from messaging and semi-interactive solutions like Instant 112 Messaging in that it offers an equivalent conversational 113 experience to users that cannot, or do not wish to, use voice. It 114 therefore meets a different set of requirements than other text- 115 based solutions already available on IP networks. 116 Traditionally, deaf, hard of hearing and speech-impaired people 117 are amongst the most proliferate users of conversational, 118 interactive text, but because of its interactivity, it is becoming 119 popular amongst mainstream user groups as well. 120 This document describes how existing IETF protocols can be used to 121 implement a Text-over-IP solution (ToIP). This ToIP framework is 122 specifically designed to be compatible with Voice-over-IP 123 environments, as well as meeting the user�s requirements, 124 including those of deaf, hard of hearing and speech-impaired users 125 as described in RFC3351 [21]. 126 The Session Initiation Protocol (SIP) is the protocol of choice 127 for control of Multimedia IP telephony and Voice-over-IP (VoIP) 128 communications. It offers all the necessary control and signaling 129 required for the ToIP framework. 130 The Real-Time Transport Protocol (RTP) is the protocol of choice 131 for real-time data transmission, and its use for interactive text 132 payloads is described in RFC4103 [5]. 133 This document defines a framework for ToIP to be used either by 134 itself or as part of integrated services, including Total 135 Conversation. 137 2. Scope 139 The primary scope of this document is to define a framework for 140 the implementation of ToIP, either stand-alone or as a part of 141 wider services, including Total Conversation. In general, the 142 scope is: 144 a. Description of ToIP using SIP and RTP; 145 b. Requirements of Real-time, interactive text; 146 c. Requirements for ToIP interworking. 148 The subsequent sections describe those requirements in detail. 150 3. Terminology 152 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 153 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 154 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 155 described in BCP 14, RFC 2119 [2] and indicate requirement levels 156 for compliant implementations. 158 A. van Wijk [Page 3 of 28] 159 4. Definitions 161 Audio bridging - a function of a gateway or relay service that 162 enables an audio path through the service between the users 163 involved in the call. 165 Full duplex - media is sent independently in both directions. 167 Half duplex - media can only be sent in one direction at a time 168 or, if an attempt to send information in both directions is made, 169 errors can be introduced into the presented media. 171 Interactive text - a term for real time transmission of text in a 172 character-by-character fashion for use in conversational services, 173 often as a text equivalent to voice based conversational services. 175 TTY � alternative designation for a text telephone, often used in 176 USA, see textphone. Also called TDD, Telecommunication Device for 177 the Deaf. 179 Textphone � also �text telephone�. A terminal device that allows 180 end-to-end real-time, interactive text communication. A variety of 181 textphone protocols exists world-wide, both in the PSTN and other 182 networks. A textphone can often be combined with a voice 183 telephone, or include voice communication functions for 184 simultaneous or alternating use of text and voice in a call. 186 Text bridging - a function of a gateway service that enables the 187 flow of text through the service between the users involved in the 188 call. 190 Text gateway - a multi functional gateway that is able to 191 transcode between different forms of text transport methods, e.g., 192 between ToIP in IP networks and Baudot text telephony in the PSTN. 194 Text telephony � analog textphone services 196 Text Relay Service - a third-party or intermediary that enables 197 communications between deaf, hard of hearing and speech-impaired 198 people, and voice telephone users by translating between voice and 199 text in a call. 201 Transcoding Services - services of a third-party user agent that 202 transcodes one stream into another. Transcoding can be done by 203 human operators, in automated manner or a combination of both 204 methods. Text Relay Services are examples of a transcoding service 205 between text and audio. 207 Total Conversation - A multimedia service offering real time 208 conversation in video, text and voice according to interoperable 209 standards. All media flow in real time. Further defined in ITU-T 210 F.703 Multimedia conversational services description. 212 A. van Wijk [Page 4 of 28] 213 Video Relay Service - A service that enables communications 214 between deaf and hard of hearing people, and hearing persons with 215 voice telephones by translating between sign language and spoken 216 language in a call. 218 Acronyms: 220 2G Second generation cellular (mobile) 221 2.5G Enhanced second generation cellular (mobile) 222 3G Third generation cellular (mobile) 223 CDMA Code Division Multiple Access 224 CTM Cellular Text Telephone Modem 225 GSM Global System of Mobile Communication 226 ISDN Integrated Services Digital Network 227 ITU-T International Telecommunications Union-Telecommunications 228 standardisation Sector 229 PSTN Public Switched Telephone Network 230 SIP Session Initiation Protocol 231 TDD Telecommunication Device for the Deaf 232 TDMA Time Division Multiple Access 233 ToIP Text over Internet Protocol 234 UTF-8 Universal Transfer Format-8 236 5. Framework Description 238 5.1. Background 240 The main purpose of this document is to provide a framework 241 description for the implementation of real-time, interactive text 242 based conversational services over IP networks, known as Text- 243 over-IP (ToIP). 244 This framework uses existing standards that are already commonly 245 used for voice based conversational services on IP networks. In 246 particular, the ToIP framework uses the Session Initiation 247 Protocol (SIP) [3] to set up, control and tear down the 248 connections between users. 249 Media is transported using the Real-Time Transport Protocol (RTP) 250 in the manner described in RFC4103. 251 This framework allows for implementation of services that meet the 252 requirement of providing a text-based conversational service, 253 equivalent to voice based telephony. In particular, ToIP offers an 254 IP equivalent of text telephony services as used by deaf, hard of 255 hearing and speech-impaired individuals. 256 In addition, real-time text conversations can be combined with 257 other conversational services using different media like video or 258 voice. 259 By using SIP, ToIP allows participants to negotiate all media 260 including real-time text conversation[4, 5]. This is a highly 261 desirable function for all IP telephony users, but essential for 262 deaf, hard of hearing, or speech impaired people who have limited 263 or no use of the audio path of the call. 264 It is important to understand that real-time text conversations 265 are significantly different from other text-based communications 267 A. van Wijk [Page 5 of 28] 268 like email or instant messaging. Real-time text conversations 269 deliver an equivalent mode to voice conversations by providing 270 transmission of text character by character as it is entered, so 271 that the conversation can be followed closely and immediate 272 interaction takes place, thus providing the same mode of 273 interaction as voice telephony does for hearing people. Store-and- 274 forward systems like email or messaging on mobile networks or non- 275 streaming systems like instant messaging are unable to provide 276 that functionality. 278 5.2. Requirements for ToIP 280 In order to make ToIP the equivalent of what voice is to hearing 281 people, it needs to offer equivalent features in terms of 282 conversationality as voice telephony provides to hearing people. 283 To achieve that, ToIP MUST: 285 a. Offer real-time presentation of the conversation; 286 b. Provide simultaneous transmission in both directions; 287 c. Provide interoperability with text conversation features in 288 other networks, for instance the PSTN, accepting functional 289 limitations that will occur during interoperation. 290 d. Not prevent other media, like audio and video, to be used in 291 conjunction with ToIP. 293 Users might want to use multiple modes of communication during the 294 conversation, either at the same time or by switching between 295 modes, e.g., between text and audio for example. Native ToIP 296 services MUST ensure that the text interface is always available. 298 When communicating via a gateway to other networks and protocols, 299 the service SHOULD support all the functionality for alternating 300 or simultaneous use of modalities as offered by the destination 301 network. 303 ToIP will often be used to access a relay service [I], allowing 304 text users to communicate with voice users. With relay services, 305 it is crucial that text characters are sent as soon as possible 306 after they are entered. While buffering MAY be done to improve 307 efficiency, the delays SHOULD be kept as small as possible. In 308 particular, buffering of whole lines of text MUST NOT be used. 310 5.3. Use of SIP and RTP 312 ToIP services MUST use the Session Initiation Protocol (SIP) [3] 313 for setting up, controlling and terminating sessions for real-time 314 text conversation with one or more participants and possibly 315 including other media like video or audio. 316 Thus, participants are allowed to negotiate on a set of compatible 317 media types with session descriptions used in SIP invitations. A 318 ToIP service MUST always support at least one Text media type. 320 A. van Wijk [Page 6 of 28] 321 ToIP services MUST use the Real-Time Transport Protocol (RTP) 322 according to the specification of RFC4103 for the transport of 323 text between participants, which implements T.140 on IP networks. 325 The standardized T.140 real-time text conversation [4], in 326 addition to audio and video communications, will be a valuable 327 service to many, including on non-IP networks. Real-time text can 328 be expressed as a part of the session description in SIP and is a 329 useful subset of Total Conversation. 331 The ToIP specification describes a framework for using the T.140 332 text conversation in SIP as a part of the multimedia session 333 establishment in real-time over a SIP network. 335 If the User Agents of different participants indicate that there 336 is an incompatibility between their capabilities to support 337 certain media types, e.g. one terminal only offering T.140 over IP 338 as described in RFC4103 and the other one only supporting audio, 339 the user might want to invoke a transcoding services. 341 Examples of possible scenarios for including a relay service in 342 the conversation are: speech-to-text (STT), text-to-speech (TTS), 343 text bridging after conversion from speech, audio bridging after 344 conversion from text, etc. 346 The session description protocol (SDP) [6] used in SIP to describe 347 the session is used to express these attributes of the session 348 (e.g., uniqueness in media mapping for conversion from one media 349 to another for each communicating party). 351 Real-time text can also be presented in conjunction with other 352 media like video and audio, as for example in Total Conversation 353 services. 355 User Agents providing ToIP functionality SHOULD provide suitable 356 alerting, specifically offering visual and/or tactile alerting so 357 that deaf and hard of hearing users can use them. 359 The SIP abilities to set up text conversation sessions from any 360 location, as well as privacy and security provisions SHOULD be 361 implemented in ToIP services. 363 Where ToIP is used in conjunction with other media, exposure of 364 SIP functions through the User Interface MUST be available in 365 equivalent fashion for all supported media. In other words, where 366 certain SIP call control functions are available for the audio 367 media part of the session, these functions MUST also be supported 368 for the text media part of the same session. 370 Any ToIP implementation MUST also allow invocation and use of 371 relevant transcoding services where these are available. This can 372 be achieved through application of SIP techniques for different 374 A. van Wijk [Page 7 of 28] 375 session establishment models [7]: Third party call control [8] and 376 Conference Bridge model [9]. 378 Both point-to-point and multipoint communication need to be 379 defined for the session establishment using T.140 text 380 conversation. In addition, ToIP services SHOULD support 381 interworking with text telephony [10]. 383 The general framework for ToIP can be described as follows: 385 a. Session setup, modification and teardown procedures for point- 386 to-point and multimedia calls 388 b. Registration procedures and address resolutions 390 c. Registration of user preferences 392 d. Negotiation procedures for device capabilities 394 e. Discovery and invocation of transcoding/translation services 395 between the media in the call 397 f. Different session establishment models for transcoding / 398 translation services invocation: Third party call control and 399 conference bridge model 401 g. Uniqueness in media mapping to be used in the session for 402 conversion from one media to another by the transcoding / 403 translation server for each communicating party 405 h. Media bridging services for T.140 real-time text as described 406 in RFC4103, audio, and video for multipoint communications 408 i. Transparent session setup, modification, and teardown between 409 text conversation capable and voice/video capable devices 411 j. Support of text media transport using T.140 over RTP as laid 412 out in RFC 4103 [4] 414 k. Signaling of status information, call progress and the like in 415 a suitable manner, bearing in mind the user may have a hearing 416 impairment 418 l. T.140 real-time text presentation mixing with voice and video 420 m. T.140 real-time text conversation sessions using SIP, allowing 421 users to move from one place to another 423 n. User privacy and security for sessions setup, modification, and 424 teardown as well as for media transfer 426 o. Interoperability between T.140 conversations and analogue text 427 telephones 429 A. van Wijk [Page 8 of 28] 430 p. Routing of emergency calls according to national or regional 431 policy to the same level of a voice call. 433 5.4. Requirements for ToIP Interworking 435 Analog text telephony is cumbersome because of incompatible 436 national implementations where interworking was never considered. 437 A large number of these implementations have been documented in 438 ITU-T V.18, which also defines modem detection sequences for the 439 different text terminals. The full modem capability exchange 440 between two wildly different terminals can take more than one 441 minute to complete if both terminals have a common text 442 modulation. 444 To resolve international analog textphone incompatibilities, text 445 telephone gateways MUST transcode incoming analog signals into 446 T.140 and vice versa. The modem capability exchange time is then 447 also reduced, since V.18 allows the sequence of protocol discovery 448 to be customized. Hence, the text telephone gateways will assume 449 the analog text telephone protocol used in the region the gateway 450 is located. For example, in the USA, Baudot might be tried as the 451 initial protocol. If negotiation for Baudot fails, the full modem 452 capability exchange will then take place. In contrast, in the UK, 453 ITU-T V.21 might be the first choice. 455 6. Detailed requirements for Text-over-IP 457 ToIP services MUST use SIP for call control and signaling. 459 A ToIP user may wish to call another ToIP user, or join a 460 conference call involving several users. He or she may, also, wish 461 to initiate or join a multimedia call, such as a Total 462 Conversation call. 464 There may be some need for pre-call setup e.g. storing 465 registration information in the SIP registrar to provide 466 information about how a user can be contacted. This will allow 467 calls to be set up rapidly and with proper routing and addressing. 469 Similarly, there are requirements that need to be satisfied during 470 call set up when other media are preferred by a user. For 471 instance, some users may prefer to use audio while others want to 472 use text as their preferred modality. In this case, transcoding 473 services might be needed for text-to-speech (TTS) and speech-to- 474 text (STT). The requirements for transcoding services need to be 475 negotiated in real-time to set up the session. 477 The subsequent subsections describe some of these requirements in 478 detail. 480 A. van Wijk [Page 9 of 28] 481 6.1. Pre-Call Requirements 483 The need to use ToIP as a medium of communications can be 484 expressed by users during registration time. Two situations need 485 to be considered in the pre-call setup environment: 487 a. User Preferences: It MUST be possible for a user to indicate a 488 preference for ToIP by registering that preference with a SIP 489 server that is part of the ToIP service. 491 b. Server to support User Preferences: SIP servers that are part 492 of ToIP services MUST have the capability to act on users 493 preferences for ToIP to accept or reject the call, based on the 494 user preferences defined during the pre-call setup registration 495 time. For example, if the user is called by another party, and it 496 is determined that a transcoding server is needed, the call MUST 497 be re-directed or otherwise handled accordingly. 499 6.2 Basic Point-to-Point Call Requirements 501 The point-to-point call will take place between two parties. The 502 requirements are described in subsequent sub-sections. They assume 503 that one or both of the communicating parties will indicate ToIP 504 as a possible or preferred medium for conversation using SIP in 505 the session setup. 507 6.2.1 Session Setup 509 Users will set up a session by identifying the remote party or the 510 service they will want to connect to. However, conversations could 511 be started using a mode other than ToIP. For instance, the 512 conversation might be established using audio and the user could 513 subsequently elect to switch to text, or add text as an additional 514 modality, during the conversation. Systems supporting ToIP MUST 515 allow users to select any of the supported conversation modes at 516 any time, including mid-conversation. 518 Systems SHOULD allow the user to specify a preferred mode of 519 communication, with the ability to fall back to alternatives that 520 the user has indicated are acceptable. 522 If the user requests simultaneous use of text and audio, and this 523 is not possible either because the system only supports alternate 524 modalities or because of resource management on the network, the 525 system MUST try to establish a text-only communication. The user 526 MUST be informed of this change throughout the process, either in 527 text or in a combination of modalities that MUST include text. 529 Session setup, especially through gateways to other networks, MAY 530 require the use of specially formatted addresses or other 531 mechanisms for invoking gateways. 533 A. van Wijk [Page 10 of 28] 534 The following features MAY need to be implemented to facilitate 535 the session establishment using ToIP: 537 a. Caller Preferences: SIP headers (e.g., Contact) can be used to 538 show that ToIP is the medium of choice for communications. 540 b. Called Party Preferences: The called party being passive can 541 formulate a clear rule indicating how a call should be handled 542 either using ToIP as a preferred medium or not, and whether a 543 designated SIP proxy needs to handle this call or it is handled in 544 the SIP user agent (UA). 546 c. SIP Server support for User Preferences: SIP servers can also 547 handle the incoming calls in accordance to preferences expressed 548 for ToIP. The SIP Server can also enforce ToIP policy rules for 549 communications (e.g. use of the transcoding server for ToIP). 551 6.2.2 Addressing 553 The SIP [3] addressing schemes MUST be used for all entities. For 554 example SIP URL and Tel URL will be used for caller, called party, 555 user devices, and servers (e.g., SIP server, Transcoding server). 557 The right to include a transcoding service MUST NOT require user 558 registration in any specific SIP registrar, but MAY require 559 authorisation of the SIP registrar in the service. 561 6.2.3 Alerting and session progress presentation 563 User Agents supporting ToIP MUST have an alerting method (e.g., 564 for incoming calls) that can be used by deaf and hard of hearing 565 people or provide a range of alternative, but equivalent, alerting 566 methods that are suitable for all users, regardless of their 567 abilities and preferences. 569 It should be noted that general alerting systems exist, and one 570 common interface for triggering the alerting action is a contact 571 closure between two conductors. 573 Among the alerting options are alerting by the User Agent�s User 574 Interface and specific alerting user agents registered to the same 575 registrar as the main user agent. 577 If present, identification of the originating party (for example 578 in the form of a URL or CLI) MUST be clearly presented to the user 579 in a form suitable for the user BEFORE answering the request. When 580 the invitation to initiate a conversation involving ToIP 581 originates from a gateway, this MAY be signaled to the user. 583 During a conversation that includes ToIP, status and session 584 progress information MUST be provided in text. That information 585 MUST be equivalent to session progress information delivered in 586 any other format, for example audio. Users MUST be able to manage 588 A. van Wijk [Page 11 of 28] 589 the session and perform all session control functions based on the 590 textual session progress information. 592 The user MUST be informed of any change in modalities. 594 Session progress information SHOULD use simple language as much as 595 possible so that as many users as possible can understand it. The 596 use of jargon or ambiguous terminology SHOULD be avoided at all 597 times. It is RECOMMENDED to let text information be used together 598 with icons symbolising the items to be reported. 600 There MUST be a clear indication, both visually as well as audibly 601 whenever a session gets connected or disconnected. The user SHOULD 602 never be in doubt as to what the status of the connection is, even 603 if he/she is not able to use audio feedback or vision. 605 In summary, it SHOULD be possible to observe visual or tactile 606 indicators about: 607 - Call progress 608 - Availability of text, voice and video channels 609 - Incoming call 610 - Incoming text 611 - Typed and transmitted text 612 - Any loss in incoming text. 614 6.2.4 Call Negotiations 616 The Session Description Protocol (SDP) used in SIP [3] provides 617 the capabilities to indicate ToIP as a media in the call setup. 618 RFC 4103 [5] provides the RTP payload type text/t140 for support 619 of ToIP which can be indicated in the SDP as a part of SDP INVITE, 620 OK and SIP/200/ACK for media negotiations. In addition, SIP�s 621 offer/answer model can also be used in conjunction with other 622 capabilities including the use of a transcoding server for 623 enhanced call negotiations [7,8,9]. 625 6.2.5 Answering 627 Systems SHOULD provide a best-effort approach to answering 628 invitations for session set-up and users should be kept informed 629 at all times about the progress of session establishment. On all 630 systems that both inform users of session status and support ToIP, 631 this information MUST be available in text, and MAY be provided in 632 other visual media. 634 6.2.5.1 Answering Machine 636 Systems for ToIP MAY support an auto-answer function, equivalent 637 to answering machines on telephony networks. If an answering 638 machine function is supported, it MUST support at least 160 639 characters for the greeting message. It MUST support incoming text 640 message storage of a minimum of 4096 characters, although systems 642 A. van Wijk [Page 12 of 28] 643 MAY support much larger storage. It is RECOMMENDED that systems 644 support storage of at least 20 incoming messages of up to 16000 645 characters. 647 When the answering machine is activated, user alerting SHOULD 648 still take place. The user SHOULD be allowed to monitor the auto- 649 answer progress and where this is provided the user MUST be 650 allowed to intervene during any stage of the answering machine and 651 take control of the session. 653 6.2.6 Actions During Calls 655 Certain actions need to be performed for the ToIP conversation 656 during the call and these actions are described briefly as 657 follows: 659 a. Text transmission SHALL be done character by character as 660 entered, or in small groups transmitted so that no character is 661 delayed between entry and transmission by more than 300 662 milliseconds. 664 b. The text transmission SHALL allow a rate of at least 30 665 characters per second so that human typing speed as well as speech 666 to text methods of generating conversation text can be supported. 668 c. After text connection is established, the mean end-to-end delay 669 of characters SHALL be less than two seconds, measured between two 670 ToIP users. This requirement is valid as long as the text input 671 rate is lower or equal to the text reception and display rate. 673 d. The character corruption rate SHALL be less than 1% in 674 conditions where users experience the quality of voice 675 transmission to be low but useable. This is in accordance with 676 ITU-T F.700 Annex A.3 quality level T1. 678 e. When interoperability functions are invoked, there may be a 679 need for intermediate storage of characters before transmission to 680 a device receiving slower than the typing speed of the sender. 681 Such temporary storage SHALL be dimensioned to adjust for 682 receiving at 30 characters per second and transmitting at 6 683 characters per second during at least 4 minutes [less than 3k 684 characters]. 686 f. To enable the use of international character sets the 687 transmission format for text conversation SHALL be UTF-8, in 688 accordance with ITU-T T.140. 690 g. If text is detected to be missing after transmission, there 691 SHALL be an indication in the text marking the loss. For 7 bit 692 terminals this loss MAY be marked as an apostrophe: �. 694 g. When used from a terminal designed for PSTN text telephony, or 695 in interworking with such a terminal, ToIP shall enable 697 A. van Wijk [Page 13 of 28] 698 alternating between text and voice in a similar manner as the PSTN 699 text telephone handles this mode of operation. (This mode is often 700 called VCO/HCO in the USA and the UK). 702 i. When display of the conversation on end user equipment is 703 included in the design, display of the dialogue SHALL be made so 704 that it is easy to read text belonging to each party in the 705 conversation. 707 6.2.6.1 Text and other Media Handling Between ToIP User Agents 709 The following requirements are valid for media handling during 710 calls: 712 a. When used between User Agents designed for ToIP, it SHALL be 713 possible to send and receive text simultaneously. 715 b. When used between User Agents that support ToIP, it SHALL be 716 possible to send and receive text simultaneously with the other 717 media (text, audio and/or video) supported by the same terminals. 719 c. It SHOULD be possible to know during the call that ToIP is 720 available, even if it is not invoked at call setup (only voice 721 and/or video is used for example). To disable this, the user must 722 disable the use of ToIP. This is possible during registration at 723 the REGISTRAR. 725 6.2.6.2 Call Action with Native ToIP User Agents 727 a. It SHOULD be possible to answer a call with text capabilities 728 enabled. 730 b. It MAY be possible to use video simultaneously with the other 731 media in the call. 733 c. It MUST be possible to answer a call in voice or video without 734 text enabled, and add text later in the call. 736 d. It MUST be possible to disconnect the call. 738 e. It SHOULD be possible to invoke multi-party calls. 740 f. It MUST be possible to transfer the call. 742 6.2.7 Additional session control 744 Systems that support additional session control features, for 745 example call waiting, forwarding, hold etc on voice calls, MUST 746 offer equivalent functionality for text calls. 748 A. van Wijk [Page 14 of 28] 749 6.2.8 File storage 751 Systems that support ToIP MAY save the text conversation to a 752 file. This SHOULD be done using a standard file format. For 753 example: UTF8 text file in XML format including record timestamp, 754 party and the text conversation. 756 6.3 Conference Call Requirements for ToIP User Agents 758 The conference call requirements deal with multipoint conferencing 759 calls where there will be at least one or more ToIP capable 760 devices along with other end user devices where the total number 761 end user devices will be at least three. 763 It SHOULD be possible to use the text medium in conference calls, 764 in a similar way as the audio is handled and the video is 765 displayed. Text in conferences can be used both for letting 766 individual participants use the text medium (for example, for 767 sidebar discussions in text while listening to the main conference 768 audio), as well as for central support of the conference with real 769 time text interpretation of speech. 771 6.4 Transport via RTP 773 ToIP uses RTP as the default transport protocol for transmission 774 of real-time text via medium text/t140 as specified in RFC 4103 775 [5]. 777 The redundancy method of RFC 4103 [5] SHOULD be used for making 778 text transmission reliable. 780 Text capability MUST be announced in SDP by a declaration in line 781 with this example: 783 m=text 11000 RTP/AVP 98 100 784 a=rtpmap:98 t140/1000 785 a=rtpmap:100 red/1000 786 a=fmtp:100 98/98/98 788 Characters SHOULD be buffered for transmission and transmitted 789 every 300 ms. 791 By having this single coding and transmission scheme for real time 792 text defined, in the SIP call control environment, the opportunity 793 for interoperability is optimized. 795 However, if good reasons exist, other transport mechanisms MAY be 796 offered and used for the T.140 coded text, provided that proper 797 negotiation is introduced, and RFC 4103 [5] transport MUST be used 798 as both the default as well as the fallback transport. 800 A. van Wijk [Page 15 of 28] 801 6.5 Character Set 803 a. ToIP services MUST use UTF-8 encoding as specified in ITU-T 804 T.140 [12]. 806 b. ToIP SHOULD handle characters with editing effect such as new 807 line, erasure and alerting during session as specified in ITU-T 808 T.140. 810 6.6 Transcoding 812 Transcoding of text may need to take place in gateways between 813 ToIP and other forms of text conversation. For example to connect 814 to a PSTN text telephone. 816 6.7 Relay Services 818 The relay service acts as an intermediary between two or more 819 callers using different media or different media encoding schemes. 821 The basic text relay service allows a translation of speech to 822 text and text to speech, which enables hearing and speech impaired 823 callers to communicate with hearing callers. Even though this 824 document focuses on ToIP, we want to remind readers that there 825 exist other relay services like, for example, speech to sign 826 language and vice versa using video. 828 It is RECOMMENDED that ToIP implementations make the invocation 829 and use of relay services as easy as possible. It MAY happen 830 automatically when the call is being set up based on any valid 831 indication or negotiation of supported or preferred media types. A 832 transcoding framework document using SIP [7] describes invoking 833 relay services, where the relay acts as a conference bridge or 834 uses the third party control mechanism. ToIP implementations 835 SHOULD support this transcoding framework. 837 Adding or removing a relay service MUST be possible without 838 disrupting the current call. 840 When setting up a call, the relay service MUST be able to 841 determine the type of service requested (e.g., speech to text or 842 text to speech), to indicate if the caller wants voice carry over, 843 the language of the text, the sign language being used (in the 844 video stream), etc. 846 It SHOULD be possible to route the call to a preferred relay 847 service even if the user makes the call from another region or 848 network than usually used. 850 A. van Wijk [Page 16 of 28] 851 6.8 Emergency services 853 Access to emergency services using ToIP SHOULD provide an 854 equivalent service to the one offered by other supported media, 855 like audio. 857 6.9 User Mobility 859 ToIP User Agents SHOULD use the same mechanisms as other SIP User 860 Agents to resolve mobility issues. It is RECOMMENDED to use a SIP- 861 address for the users, resolved by a SIP REGISTRAR, to enable 862 basic user mobility. Further mechanisms are defined for the 3G IP 863 multimedia systems. 865 6.10 Confidentiality and Security 867 User confidentiality and privacy need to be met as described in 868 SIP [3]. For example, nothing should reveal the fact that the user 869 of ToIP is a person with a disability unless the user prefers to 870 make this information public. If a transcoding server is being 871 used, this SHOULD be transparent. Encryption SHOULD be used on 872 end-to-end or hop-by-hop basis as described in SIP [3] and SRTP 873 [19] 875 Authentication needs to be provided for users in addition to the 876 message integrity and access control. 878 Protection against Denial-of-service (DoS) attacks needs to be 879 provided considering the case that the ToIP users might need 880 transcoding servers. 882 7. Interworking Requirements for ToIP 884 A number of systems for real time text conversation already exist 885 as well as a number of message oriented text communication 886 systems. Interoperability is of interest between ToIP and some of 887 these systems. This section describes requirements on this 888 interoperability, especially for the PSTN text telephony to ensure 889 full backward interoperability with ToIP. 891 7.1 ToIP Interworking Gateway Services 893 Interactive texting facilities exist already in various forms and 894 on various networks. On the PSTN, it is commonly referred to as 895 text telephony. 897 Simultaneous or alternating use of voice and text is used by a 898 large number of users who can send voice, but must receive text or 899 who can hear but must send text due to a speech disability. 901 A. van Wijk [Page 17 of 28] 902 7.2 ToIP and PSTN/ISDN Text-Telephony 904 On PSTN networks, transmission of interactive text takes place 905 using a variety of codings and modulations, including ITU-T V.21 906 [II], Baudot, DTMF, V.23 [III] and others. Many difficulties have 907 arisen as a result of this variety in text telephony protocols and 908 the ITU-T V.18 [10] standard was developed to address some of 909 these issues. 911 ITU-T-V.18 [10] offers a native text telephony method plus it 912 defines interworking with current protocols. In the interworking 913 mode, it will recognise one of the older protocols and fall back 914 to that transmission method when required. 916 In order to allow systems and services based on ToIP to 917 communicate with PSTN text telephones, text gateways are the 918 recommended approach. These gateways MUST use the ITU-T V.18 [10] 919 standard at the PSTN side. 921 Buffering MUST be used to support different transmission rates. At 922 least 1K buffer MUST be provided. A buffer of at least 2K 923 characters is RECOMMENDED. In addition, the gateway MUST provide a 924 minimum throughput of at least 30 characters/second or the highest 925 speed supported by the PSTN text telephony protocol side, 926 whichever is the lowest. 928 PSTN-ToIP gateways MUST allow alternating use of text and voice. 930 PSTN and ISDN to ToIP gateways that receive CLI information from 931 the originating party MUST pass this information to the receiving 932 party as soon as possible. 934 Priority MUST be given to calls labeled as emergency calls. 936 7.3 ToIP and Cellular Wireless circuit switched Text-Telephony 938 Cellular wireless (or Mobile) circuit switched connections provide 939 a digital real-time transport service for voice or data. 940 The access technologies include GSM, CDMA, TDMA, iDen and various 941 3G technologies. 943 Alternative means of transferring the Text telephony data have 944 been developed when TTY services over cellular was mandated by the 945 FCC in the USA. They are a) "No-gain" codec solution, b) the 946 Cellular Text Telephony Modem (CTM) solution and c) "Baudot mode" 947 solution. 949 The GSM and 3G standards from 3GPP make use of the CTM modem in 950 the voice channel for text telephony. 951 However, implementations also exist that use the data channel to 952 provide such functionality. Interworking with these solutions 953 SHOULD be done using text gateways that set up the data channel 954 connection at the GSM side and provide ToIP at the other side. 956 A. van Wijk [Page 18 of 28] 957 7.3.1 "No-gain" 959 The "No-gain" text telephone transporting technology uses 960 specially modified EFR [15] and EVR [16] speech vocoders in both 961 mobile terminals used to provide a text telephony call. It 962 provides full duplex operation and supports alternating voice and 963 text.( "VCO/HCO"). It is dedicated to the CDMA and TDMA mobile 964 technologies and the US Baudot type of text telephones. 966 7.3.2 Cellular Text Telephone Modem (CTM) 968 CTM [17] is a technology independent modem technology that 969 provides the transport of text telephone characters at up to 10 970 characters/sec using modem signals that are at or below 1 kHz and 971 uses a highly redundant encoding technique to overcome the fading 972 and cell changing losses. On any interface that uses analog 973 transmission, half-duplex operation must be supported as the 974 "send" and "receive" modem frequencies are identical. The use of 975 CTM may have to be modified slightly to support half-duplex 976 operation. 978 7.3.3 "Baudot mode" 980 This term is often used by cellular terminal suppliers for a GSM 981 cellular phone mode that allows TTYs to operate into a cellular 982 phone and to communicate with a fixed line TTY. 984 7.3.4 Data channel mode 986 Many mobile terminals allow the use of the data channel to 987 transfer data in real-time. Data rates of 9600 bit/s are usually 988 supported on the mobile network. Gateways or the interworking 989 function provides interoperability with PSTN textphones. 991 7.3.5 Common Text Gateway Functions 993 Text gateways MUST cover the differences that result from 994 different text protocols. The protocols to be supported will 995 depend on the service requirements of the Gateway. 997 Different data rates of different protocols MAY require text 998 buffering. 1000 Interoperation of half-duplex and full-duplex protocols MAY 1001 require text buffering and some intelligence to determine when to 1002 change direction when operating in half-duplex. 1004 Identification may be required of half-duplex operation either at 1005 the "user" level (ie. users must inform each other) or at the 1006 "protocol" level (where an indication must be sent back to the 1007 Gateway). 1009 A. van Wijk [Page 19 of 28] 1010 A text gateway MUST be able to route text calls to emergency 1011 service providers when any of the recognised emergency numbers 1012 that support text communications for the country or region are 1013 called eg. "911" in USA and "112" in Europe. Routing text calls to 1014 emergency services MAY require the use of a transcoding service. 1016 A text gateway MUST act as a SIP User Agent on the IP side. 1018 7.4 ToIP and Cellular Wireless ToIP 1020 ToIP MAY be supported over the cellular wireless packet switched 1021 service. It interfaces to the Internet. For 3GPP 3G services, the 1022 support is described to use ToIP in 3G TS 26.235 [20]. 1024 A text gateway with cellular wireless packet switched services 1025 MUST be able to route text calls into emergency service providers 1026 when any of the recognized emergency numbers that support text 1027 communication for the country are called. 1029 7.5 Instant Messaging Support 1031 Many people use Instant Messaging to communicate via the Internet 1032 using text. Instant Messaging transfers blocks of text rather than 1033 streaming as is used by ToIP. As such, it is not a replacement for 1034 ToIP and in particular does not meet the needs for real time 1035 conversations of deaf, hard of hearing and speech-impaired users 1036 as defined in RFC 3351 [21]. It is unsuitable for communications 1037 through a relay service [I]. The streaming character of ToIP 1038 provides a better user experience and, when given the choice, 1039 users often prefer ToIP. 1041 However, since some users might only have Instant Messaging 1042 available, text gateways MAY be developed to allow interworking 1043 between Instant Messaging systems and ToIP solutions. 1045 Because Instant Messaging is based on blocks of text, rather than 1046 on a continuous stream of characters, such gateways need to 1047 transform between these two formats. Text gateways for 1048 interworking between Instant Messaging and ToIP MUST concatenate 1049 individual characters originating at the ToIP side into blocks of 1050 text and: 1052 a. When the length of the concatenated message becomes longer than 1053 50 characters, the buffered text SHOULD be transmitted to the 1054 Instant Messaging side as soon as any non-alphanumerical character 1055 is received from the ToIP side. 1057 b. When a new line is received from the ToIP side, the buffered 1058 characters up to that point, including the carriage return and/or 1059 line feed characters, SHOULD be transmitted to the Instant 1060 Messaging side. 1062 A. van Wijk [Page 20 of 28] 1063 c. When the ToIP side has been idle for at least 5 seconds, all 1064 buffered text up to that point SHOULD be transmitted to the 1065 Instant Messaging side. 1067 It is RECOMMENDED that during the session, both users are 1068 constantly updated on the progress of the text input. 1069 Many Instant Messaging protocols signal that a user is typing to 1070 the other party in the conversation. Text gateways between such 1071 Instant Messaging protocols and ToIP MUST provide this signaling 1072 to the Instant Messaging side when characters start being 1073 received, or at the beginning of the conversation. 1075 At the ToIP side, an indicator of writing the Instant Message MUST 1076 be present where the Instant Messaging protocol provides one. For 1077 example, the real-time text user MAY see . . . waiting for 1078 replying IM. . . And per 5 seconds that pass a . (dot) can be 1079 shown. 1081 Those solutions will reduce the difficulties between a streaming 1082 versus blocked text. 1084 Even though the text gateway can connect Instant Messaging and 1085 ToIP, the best solution is to take advantage of the fact that the 1086 user interfaces and the user communities for instant messaging and 1087 ToIP telephony are extremely similar. After all, the character 1088 input, the character display, Internet connectivity and SIP stack 1089 are the same for Instant Messaging (SIMPLE) and ToIP. 1091 Devices that implement Instant Messaging SHOULD implement ToIP as 1092 described in this document. 1094 7.6 IP Telephony with Traditional RJ-11 Interfaces 1096 Analogue adapters using SIP based IP communication and RJ-11 1097 connectors for connecting traditional PSTN devices (ATA box) 1098 SHOULD enable connection of legacy PSTN text telephones [18]. 1099 These adapters SHOULD contain V.18 modem functionality, voice 1100 handling functionality, and conversion functions to/from SIP based 1101 ToIP with T.140 transported according to RFC 4103 [5], in a 1102 similar way as it provides interoperability for voice calls. If a 1103 call is set up and text/t140 capability is not declared by the 1104 endpoint (by the end-point terminal or the text gateway in the 1105 network at the end-point), a method for invoking a transcoding 1106 server shall be used. If no such server is available, the signals 1107 from the textphone MAY be transmitted in the voice channel as 1108 audio with high quality of service. 1109 NOTE: It is preferred that such analogue adaptors do use RFC 4103 1110 [5] on board and thus act as a text gateway. Sending textphone 1111 signals over the voice channel is undesirable due to possible 1112 filtering and compression and packet loss between the end-points. 1113 This can result in dropping characters in the textphone 1114 conversation or even not allowing the textphones to connect with 1115 each other. 1117 A. van Wijk [Page 21 of 28] 1118 7.7 Multi-functional gateways 1120 In practice many interworking gateways will be implemented as 1121 gateways that combine different functions. As such, a text gateway 1122 could be build to have modems to interwork with the PSTN and 1123 support both Instant Messaging as well as ToIP. Such interworking 1124 functions are called Combination gateways. 1126 Combination gateways MUST provide interworking between all of 1127 their supported text based functions. For example, a text gateway 1128 that has modems to interwork with the PSTN and that support both 1129 Instant Messaging and real-time ToIP MUST support the following 1130 interworking functions: 1132 - PSTN text telephony to real-time ToIP. 1133 - PSTN text telephony to Instant Messaging. 1134 - Instant Messaging to real-time ToIP. 1136 7.8 ToIP interoperability with PSTN text telephones. 1138 Gateways between the ToIP network and other networks MAY need to 1139 transcode text streams. ToIP makes use of the ISO 10646 character 1140 set. Most PSTN textphones use a 7-bit character set, or a 1141 character set that is converted to a 7-bit character set by the 1142 V.18 modem. 1144 When transcoding between character sets and T.140 in gateways, 1145 special consideration MUST be given to the national variants of 1146 the 7 bit codes, with national characters mapping into different 1147 codes in the ISO 10 646 code space. The national variant to be 1148 used could be selectable by the user on a per call basis, or be 1149 configured as a national default for the gateway. 1151 The missing text indicator in T.140, specified in T.140 amendment 1152 1, cannot be represented in the 7 bit character codes. Therefore 1153 these characters SHOULD be transcoded to the ' (apostrophe) 1154 character in legacy text telephone systems, where this character 1155 exists. For legacy systems where the character ' does not exist, 1156 the . ( full stop ) character SHOULD be used instead. 1158 7.9 Gateway Discovery 1160 ToIP requires a method to invoke a text gateway. As described 1161 previously in this draft, these text gateways MUST act as User 1162 Agents at the IP side. The capabilities of the text gateway during 1163 the call will be determined by the call capabilities of the 1164 terminal that is using the gateway. For example, a PSTN textphone 1165 is only able to receive voice and streaming text, so the text 1166 gateway will only allow ToIP and audio. 1168 Examples of possible scenarios for discovery of the text gateway 1169 are: 1171 A. van Wijk [Page 22 of 28] 1172 - PSTN textphone users dial a prefix number before dialing out. 1173 - Separate text subscriptions, linked to the phone number or 1174 terminal identifier/ IP address. 1175 - Text capability indicators. 1176 - Text preference indicator. 1177 - Listen for V.18 modem modulation text activity in all calls. 1178 - Call transfer request by the called user. 1179 - Placing a call via the web, and using one of the methods 1180 described here 1181 - Text gateways with its own telephone number and/or SIP address. 1182 (This requires user interaction with the text gateway to place a 1183 call). 1184 - ENUM address analysis and number plan 1185 - Number or address analysis leads to the gateway for all PSTN 1186 calls. 1188 8. Afterword 1190 The authors want to make it clear that ToIP is a way of allowing 1191 real-time, interactive text conversation between all users and is 1192 thus not only for the hearing and speech impaired users. 1194 The users may invoke the ToIP services for many different reasons. 1195 For example: 1197 - Noisy environment (e.g., in a machine room of a factory where 1198 listening is difficult) 1199 - Busy with another call and want to participate in two calls at 1200 the same time. 1201 - Text and/or speech recording services (e.g., text 1202 documentation/audio recording for legal/clarity/flexibility 1203 purposes) 1204 - Overcoming of language barriers through speech translation 1205 and/or transcoding services. 1206 - Hearing loss, tinnitus or deafness due to the aging process or 1207 any other reason. 1209 NOTE: In many of the above examples, text may accompany speech and 1210 could be displayed in a manner similar to subtitling in 1211 broadcasting environments or any other suitable manner. This 1212 could occur for individuals who are hard of hearing and also for 1213 mixed calls with a hearing and deaf person listening to the call. 1215 9. Security Considerations 1217 There are no additional security requirements other than described 1218 earlier. 1220 A. van Wijk [Page 23 of 28] 1221 10. Authors Addresses 1223 The following people provided substantial technical and writing 1224 contributions to this document, listed alphabetically: 1226 Willem P. Dijkstra 1227 TNO Informatie- en Communicatietechnologie 1228 Postbus 15000 1229 9700 CD Groningen 1230 The Netherlands 1231 Tel: +31 50 585 77 24 1232 Fax: +31 50 585 77 57 1233 Email: willem.dijkstra@tno.nl 1235 Barry Dingle 1236 ACIF, 32 Walker Street 1237 North Sydney, NSW 2060 Australia 1238 Tel +61 (0)2 9959 9111 1239 Fax +61 (0)2 9954 6136 1240 TTY +61 (0)2 9923 1911 1241 Mob +61 (0)41 911 7578 1242 Email barry.dingle@bigfoot.com.au 1244 Guido Gybels 1245 Department of New Technologies 1246 RNID, 19-23 Featherstone Street 1247 London EC1Y 8SL, UK 1248 Tel +44(0)20 7294 3713 1249 Txt +44(0)20 7296 8019 1250 Fax +44(0)20 7296 8069 1251 Email: guido.gybels@rnid.org.uk 1253 Gunnar Hellstrom 1254 Omnitor AB 1255 Renathvagen 2 1256 SE 121 37 Johanneshov 1257 Sweden 1258 Phone: +46 708 204 288 / +46 8 556 002 03 1259 Fax: +46 8 556 002 06 1260 Email: gunnar.hellstrom@omnitor.se 1262 Henry Sinnreich 1263 pulver.com 1264 115 Broadhollow Rd 1265 Suite 225 1266 Melville, NY 11747 1267 USA 1268 Tel: +1.631.961.8950 1270 A. van Wijk [Page 24 of 28] 1271 Gregg C Vanderheiden 1272 University of Wisconsin-Madison 1273 Trace R & D Center 1274 1550 Engineering Dr (Rm 2107) 1275 Madison, Wi 53706 1276 USA 1277 gv@trace.wisc.edu 1278 Phone +1 608 262-6966 1279 FAX +1 608 262-8848 1281 Arnoud A. T. van Wijk 1282 Viataal (Dutch Institute for the Deaf) 1283 Research & Development 1284 Afdeling RDS 1285 Theerestraat 42 1286 5271 GD Sint-Michielsgestel 1287 The Netherlands. 1288 Email: a.vwijk@viataal.nl 1290 11. References 1292 11.1 Normative 1294 1. Bradner, S., "The Internet Standards Process -- Revision 3", 1295 BCP 9, RFC 2026, October 1996. 1297 2. Bradner, S., "Key words for use in RFCs to Indicate Requirement 1298 Levels", BCP 14, RFC 2119, March 1997 1300 3. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 1301 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session 1302 Initiation Protocol, RFC 3621, IETF, June 2002. 1304 4. ITU-T Recommendation T.140, "Protocol for Multimedia 1305 Application Text Conversation (February 1998) and Addendum 1 1306 (February 2000). 1308 5. G. Hellstrom, "RTP Payload for Text Conversation, RFC 4103, 1309 June 2005. 1311 6. G. Camarillo, H. Schulzrinne, and E. Burger, "The Source and 1312 Sink Attributes for the Session Description Protocol," IETF, 1313 August 2003 - Work in Progress. 1315 7. G.Camarillo, "Framework for Transcoding with the Session 1316 Initiation Protocol" IETF June 2005 - Work in progress. 1318 8. G. Camarillo, H. Schulzrinne, E. Burger, and A. van Wijk, 1319 "Transcoding Services Invocation in the Session Initiation 1320 Protocol (SIP) Using Third Party Call Control (3pcc)" RFC 4117, 1321 June 2005. 1323 A. van Wijk [Page 25 of 28] 1324 9. G. Camarillo, "The SIP Conference Bridge Transcoding Model," 1325 IETF, August 2003 - Work in Progress. 1327 10. ITU-T Recommendation V.18,"Operational and Interworking 1328 Requirements for DCEs operating in Text Telephone Mode," November 1329 2000. 1331 11. "XHTML 1.0: The Extensible HyperText Markup Language: A 1332 Reformulation of HTML 4 in XML 1.0", W3C Recommendation. Available 1333 at http://www.w3.org/TR/xhtml1. 1335 12. Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1336 RFC 2279, January 1998. 1338 13. TIA/EIA/825 "A Frequency Shift Keyed Modem for Use on the 1339 Public Switched Telephone Network." (The specification for 45.45 1340 and 50 bit/s TTY modems.) 1342 14. Bell-103 300 bit/s modem. 1344 15. TIA/EIA/IS-823-A "TTY/TDD Extension to TIA/EIA-136-410 1345 Enhanced Full Rate Speech Codec (must used in conjunction with 1346 TIA/EIA/IS-840)" 1348 16. TIA/EIA/IS-127-2 "Enhanced Variable Rate Codec, Speech Service 1349 Option 3 for Wideband Spread Spectrum Digital Systems. Addendum 1350 2." 1352 17. 3GPP TS26.226 "Cellular Text Telephone Modem Description" 1353 (CTM). 1355 18. I. Butcher, S. Lass, D. Petrie, H. Sinnreich, and C. 1356 Stredicke, "SIP Telephony Device Requirements, Configuration and 1357 Data," IETF, February 2004 - Work in Progress. 1359 19. Baugher, McGrew, Carrara, Naslund, Norrman, "The Secure Real 1360 Time Transport Protocol (SRTP)", RFC 3711, IETF, March 2004. 1362 20. IP Multimedia default codecs. 3GPP TS 26.235 1364 21. Charlton, Gasson, Gybels, Spanner, van Wijk, "User 1365 Requirements for the Session Initiation Protocol (SIP) in Support 1366 of Deaf, Hard of Hearing and Speech-impaired Individuals", RFC 1367 3351, IETF, August 2002. 1369 22. J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the 1370 Session Description Protocol (SDP)", RFC 3624, IETF, June 2002. 1372 A. van Wijk [Page 26 of 28] 1373 11.2 Informative 1375 I. A relay service allows the users to transcode between different 1376 modalities or languages. In the context of this document, relay 1377 services will often refer to text relays that transcode text into 1378 voice and vice-versa. See for example http://www.typetalk.org. 1380 II. International Telecommunication Union (ITU), "300 bits per 1381 second duplex modem standardized for use in the general switched 1382 telephone network". ITU-T Recommendation V.21, November 1988. 1384 III. International Telecommunication Union (ITU), "600/1200-baud 1385 modem standardized for use in the general switched telephone 1386 network. ITU-T Recommendation V.23, November 1988. 1388 IV. Third Generation Partnership Project (3GPP), "Technical 1389 Specification Group Services and System Aspects; Cellular Text 1390 Telephone Modem; General Description (Release 5)". 3GPP TS 26.226 1391 V5.0.0. 1393 Intellectual Property Statement 1395 The IETF takes no position regarding the validity or scope of any 1396 Intellectual Property Rights or other rights that might be claimed 1397 to pertain to the implementation or use of the technology 1398 described in this document or the extent to which any license 1399 under such rights might or might not be available; nor does it 1400 represent that it has made any independent effort to identify any 1401 such rights. Information on the procedures with respect to rights 1402 in RFC documents can be found in BCP 78 and BCP 79. 1404 Copies of IPR disclosures made to the IETF Secretariat and any 1405 assurances of licenses to be made available, or the result of an 1406 attempt made to obtain a general license or permission for the use 1407 of such proprietary rights by implementers or users of this 1408 specification can be obtained from the IETF on-line IPR repository 1409 at http://www.ietf.org/ipr. 1411 The IETF invites any interested party to bring to its attention 1412 any copyrights, patents or patent applications, or other 1413 proprietary rights that may cover technology that may be required 1414 to implement this standard. Please address the information to the 1415 IETF at ietf-ipr@ietf.org. 1417 Disclaimer of Validity 1419 This document and the information contained herein are provided on 1420 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1421 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1422 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1423 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1424 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1426 A. van Wijk [Page 27 of 28] 1427 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1428 PARTICULAR PURPOSE. 1430 Copyright Statement 1432 Copyright (C) The Internet Society (2005). This document is 1433 subject to the rights, licenses and restrictions contained in BCP 1434 78, and except as set forth therein, the authors retain all their 1435 rights. 1437 Acknowledgment 1439 Funding for the RFC Editor function is currently provided by the 1440 Internet Society. 1442 A. van Wijk [Page 28 of 28]