idnits 2.17.1 draft-vanwijk-sipping-toip-00.txt: -(130): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(455): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(510): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(619): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(941): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(982): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1193): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1194): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1222): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1256): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1257): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1738): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1760): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1825): 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 3667, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1931. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == There are 16 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 2181 lines 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.) ** The document seems to lack an Authors' Addresses Section. ** There are 666 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1292 has weird spacing: '...rovides a bet...' == Line 1590 has weird spacing: '...necting analo...' == Line 1723 has weird spacing: '...ew line and e...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: a. Offer Real-Time presentation of the conversation. This means that text MUST be sent as soon as available, or with very small delays. The delay MUST not be longer than 300 milliseconds, -- 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? '1' on line 19 looks like a reference -- Missing reference section? '2' on line 176 looks like a reference -- Missing reference section? '3' on line 987 looks like a reference -- Missing reference section? '4' on line 1385 looks like a reference -- Missing reference section? '5' on line 831 looks like a reference -- Missing reference section? 'I' on line 1291 looks like a reference -- Missing reference section? '6' on line 384 looks like a reference -- Missing reference section? '7' on line 912 looks like a reference -- Missing reference section? '8' on line 622 looks like a reference -- Missing reference section? '9' on line 622 looks like a reference -- Missing reference section? '10' on line 1386 looks like a reference -- Missing reference section? '12' on line 865 looks like a reference -- Missing reference section? '19' on line 988 looks like a reference -- Missing reference section? 'II' on line 1149 looks like a reference -- Missing reference section? 'III' on line 1149 looks like a reference -- Missing reference section? '15' on line 1208 looks like a reference -- Missing reference section? '16' on line 1208 looks like a reference -- Missing reference section? '17' on line 1216 looks like a reference -- Missing reference section? '20' on line 1273 looks like a reference -- Missing reference section? '18' on line 1621 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 9 warnings (==), 24 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 2004 Viataal 6 Expires: January 2004 7 Informational 9 Framework of requirements for real-time text conversation using SIP. 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC 2026 [1]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 By submitting this Internet-Draft, I certify that any applicable 21 patent or other IPR claims of which I am aware have been 22 disclosed, or will be disclosed, and any of which I become aware 23 will be disclosed, in accordance with RFC 3668. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document provides the framework of requirements for text 39 conversation with real time character-by-character interactive 40 flow over the IP network using the Session Initiation Protocol. 41 The requirements for general real-time text-over-IP telephony, 42 point-to point and conference calls, transcoding, relay services, 43 user mobility, interworking between text-over-IP telephony and 44 existing text-telephony, and some special features including 45 instant messaging have been described. 47 Table of Contents 49 1. Introduction 3 50 2. Scope 3 51 3. Terminology 4 53 A. van Wijk [Page 1 of 37] 54 draft-vanwijk-sipping-ToIP-00.txt July 2004 56 4. Definitions 4 57 5. Background and General Requirements 5 58 6. Features in Real-time Text-over-IP 6 59 7. Real-Time Multimedia Conversational Sessions using SIP 7 60 8. General Requirements for Real-Time Text-over-IP using SIP 9 61 8.1 Pre-Call Requirements 9 62 8.2 Basic Point-to-Point Call Requirements 10 63 8.2.1 General Requirements 10 64 8.2.2 Session Setup 10 65 8.2.3 Addressing 11 66 8.2.4 Alerting 11 67 8.2.5 Call Negotiations 11 68 8.2.6 Answering 12 69 8.2.7 Session progress and status presentation 12 70 8.2.8 Actions During Calls 13 71 8.2.9 Additional session control 15 72 8.2.10 File storage 15 73 8.3 Conference Call Requirements 15 74 8.4 Transport 15 75 8.5 Character Set 16 76 8.6 Transcoding 16 77 8.7 Relay Services 17 78 8.8 Emergency services 18 79 8.9 User Mobility 18 80 8.10 Confidentiality and Security 18 81 8.11 Call Flows 18 82 8.11.1 Call Scenarios 19 83 8.11.2 Point-to-Point Call Flows 20 84 8.11.3 Conference Call Flows 20 85 9. Interworking Requirements for Text-over-IP 21 86 9.1 Real-Time Text-over-IP Interworking Gateway Services 21 87 9.2 Text-over-IP and PSTN/ISDN Text-Telephony 21 88 9.3 Text-over-IP and Cellular Wireless circuit switched Text- 89 Telephony 22 90 9.3.1 "No-gain" 22 91 9.3.2 Cellular Text Telephone Modem (CTM) 22 92 9.3.3 "Baudot mode" 23 93 9.3.4 Data channel mode 23 94 9.3.5 Common Text Gateway Functions 23 95 9.4 Text-over-IP and Cellular Wireless Text-over-IP 23 96 9.5 Instant Messaging Support 23 97 9.6 IP Telephony with Traditional RJ-11 Interfaces 25 98 9.7 Interworking Call Flows 25 99 9.8 Multi-functional gateways 26 100 9.9 Gateway Discovery 26 101 9.10 Text Gateway in the call Scenarios 27 102 9.10.1 IP terminal calling an analogue textphone (PSTN) 27 103 9.10.2 IP terminal calling a mobile text telephone (CTM) 28 104 9.10.3 IP terminal calling a mobile telephone (GPRS based) 28 105 9.10.4 IP terminal calling a mobile telephone(UMTS) 28 106 9.10.5 Analogue textphone (PSTN) user calling an IP terminal using 107 prefix 28 109 A. van Wijk [Page 2 of 37] 110 draft-vanwijk-sipping-ToIP-00.txt July 2004 112 9.10.6 Mobile text telephone (CTM) user calling an IP terminal 113 29 114 9.10.7 Mobile telephone user (GPRS) calling an IP terminal 29 115 9.10.8 Mobile telephone (UMTS) user calling an IP terminal 29 116 9.10.9 Voice over DSL user using an analogue text telephone. 29 117 9.10.10 VoIP user via a building telephone switch (at an apartment 118 building) owning an analogue text telephone. 29 119 9.10.11 VoIP user via a gateway/box connected to his/her own 120 Broadband connection owning an analogue text telephone. 29 121 10. Terminal Features 30 122 10.1 Text input 30 123 10.2 Text presentation 31 124 10.3 Call control 32 125 10.4 Device control 32 126 10.5 Alerting 32 127 10.6 External interfaces 33 128 10.7 Power 33 129 11. Security Considerations 33 130 12. Authors� Addresses 33 131 13. Acknowledgements 35 132 14. Full Copyright Statement 35 133 15. References 35 134 15.1 Normative 35 135 15.2 Informative 37 137 1. Introduction 139 Text-over-IP (ToIP) is becoming popular as a part of total 140 conversation among a range of users although this medium of 141 communications may be the most convenient to certain categories of 142 people (e.g., deaf, hard of hearing and speech-impaired 143 individuals). The Session Initiation Protocol (SIP) has become the 144 protocol of choice for control of Multimedia IP telephony and 145 Voice-over-IP (VoIP) communications. Naturally, it has become 146 essential to define the requirements for how ToIP can be used with 147 SIP to allow text conversations as an equivalent to voice. This 148 document defines the framework of requirements for using ToIP, 149 either by itself or as a part of total conversation using SIP for 150 session control. 152 2. Scope 154 The primary scope of this document is to define the requirements 155 for using ToIP with SIP, either stand-alone or as a part of a 156 total conversation approach. In general, the scope of the 157 requirements is: 159 a. Features in Real-Time ToIP 160 b. Real-time Multimedia Conversational Sessions using SIP 161 c. General Requirements for Real-Time ToIP using SIP 162 d. Interworking Requirements for ToIP 163 e. Text gateways to interconnect the different networks 165 A. van Wijk [Page 3 of 37] 166 draft-vanwijk-sipping-ToIP-00.txt July 2004 168 The subsequent sections describe those requirements in detail. 170 3. Terminology 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 173 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 174 in this document are to be interpreted as described in RFC 2119 175 [2]. 177 4. Definitions 179 Audio bridging - a function of a gateway or relay service that 180 enables an audio path through the service between the users 181 involved in the call. 183 Full duplex - user information is sent independently in both 184 directions. 186 Half duplex - user information can only be sent in one direction 187 at a time or, if an attempt to send information in both directions 188 is made, errors can be introduced into the user information. 190 Interactive text - a term for real time transmission of text in a 191 character-by-character fashion for use in conversational services. 193 TTY - name for text telephone, often used in USA, see textphone. 194 Also called TDD, Telecommunication Device for the Deaf. 196 Textphone - text telephone. A terminal device that allow end-to- 197 end real time text communication. A variety of textphone protocols 198 exists world-wide, both in the PSTN and other networks. A 199 textphone can often be combined with a voice telephone, or include 200 voice communication functions for simultaneous or alternating use 201 of text and voice in a call. 203 Text bridging - a function of a gateway or relay service that 204 enables the flow of text through the service between the users 205 involved in the call. 207 Text gateway - a multi functional gateway that is able to 208 transcode between different forms of text transport methods. E.g. 209 Between ToIP in IP networks and Baudot text telephony in the PSTN. 211 Text telephony - Analog textphone services 213 Text Relay Service - A third-party or intermediary that enables 214 communications between deaf, hard of hearing and speech-impaired 215 people, and voice telephone users by translating between voice and 216 text in a call. 218 Transcoding Services - Services of a third-party user agent 219 (human or automated) that transcodes one stream into another. 221 A. van Wijk [Page 4 of 37] 222 draft-vanwijk-sipping-ToIP-00.txt July 2004 224 Total Conversation - A multimedia service offering real time 225 conversation in video, text and voice according to interoperable 226 standards. All media flow in real time. Further defined in ITU-T 227 F.703 Multimedia conversational services description. 229 Video Relay Service - A service that enables communications 230 between deaf and hard of hearing people with total conversation 231 devices, and hearing persons with voice telephones by translating 232 between sign language and spoken language in a call. 234 Acronyms: 236 2G Second generation cellular (mobile) 237 2.5G Enhanced second generation cellular (mobile) 238 3G Third generation cellular (mobile) 239 CDMA Code Division Multiple Access 240 CTM Cellular Text Telephone Modem 241 GSM Global System of Mobile Communication 242 ISDN Integrated Services Digital Network 243 ITU-T International Telecommunications Union-Telecommunications 244 standardisation Sector 245 PSTN Public Switched Telephone Network 246 SIP Session Initiation Protocol 247 TDD Telecommunication Device for the Deaf 248 TDMA Time Division Multiple Access 249 ToIP Text over Internet Protocol 250 UTF-8 Universal Transfer Format-8 252 5. Background and General Requirements 254 The main purpose of this document is to provide a set of 255 requirements for real-time text conversation over the IP network 256 using the Session Initiation Protocol (SIP) [3]. The overall 257 requirement is that real-time text conversation can be part of a 258 conversational service like any other media. Participants can 259 negotiate all media including real-time text conversation[4, 5]. 260 This is a highly desirable function for all IP telephony users, 261 and essential for deaf, hard of hearing, or speech impaired people 262 who have limited 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 266 like email or instant messaging. Real-time text conversations 267 deliver an equivalent mode to voice conversations by providing 268 transmission of text character by character as it is entered, so 269 that the conversation can be followed closely and immediate 270 interaction take place, therefore providing the same mode of 271 interaction as voice telephony does. Store-and-forward systems 272 like email or messaging on mobile networks or non-streaming 273 systems like instant messaging are unable to provide that 274 functionality. 276 A. van Wijk [Page 5 of 37] 277 draft-vanwijk-sipping-ToIP-00.txt July 2004 279 One particular application where real-time text is absolutely 280 essential, is the use of relay services between conversational 281 modes, like between text and voice. 283 Direct text emergency service calls, where time and continuous 284 connection are of the essence, is another essential application. 286 6. Features in Real-time Text-over-IP 288 While real-time Text-over-IP will be used for a wide variety of 289 services, an important field of application will be to provide a 290 text equivalent to voice conversation, in particular for deaf, 291 hard of hearing and speech-impaired users. 292 As such, it is crucial that the conversational nature of this 293 service is maintained. Text based communications exist in a 294 variety of forms, some non-conversational (SMS, text paging, E- 295 mail, newsgroups, message boards, etc.), others conversational 296 (TTY/TDD, Textphone, etc). 298 Real-time Text-over-IP will sometimes be used in conjunction with 299 a relay service [I] to allow text users to communicate with voice 300 users. With relay services, it is crucial that text characters are 301 sent as soon as possible after they are entered. While buffering 302 MAY be done to improve efficiency, the delays SHOULD be kept as 303 small as possible. In particular, buffering of whole lines of text 304 MUST NOT be used. 306 In order to make Real-Time Text-over-IP the equivalent of what 307 voice is to hearing people, it needs to offer equivalent features 308 in terms of conversation as voice communications provides to 309 hearing people. To achieve that, real-time Text-over-IP MUST: 311 a. Offer Real-Time presentation of the conversation. This means 312 that text MUST be sent as soon as available, or with very small 313 delays. The delay MUST not be longer than 300 milliseconds, 315 b. Provide simultaneous transmission in both directions, 317 c. Provide interoperability with text conversation features in 318 other networks, e.g. PSTN, accepting functional limitations that 319 this will lead to during interoperation. 321 d. Support a transmission rate of at least 30 characters/second. 323 e. Support suitable reliability of text transmission. A character 324 error rate of 0.2% is regarded good, and 1% usable. 326 f. Be possible to merge with video and voice transmission. 328 g. The end-to-end delay in transmission MUST be less than 2000 329 milliseconds. 331 A. van Wijk [Page 6 of 37] 332 draft-vanwijk-sipping-ToIP-00.txt July 2004 334 Many users will want to use multiple modes of communication during 335 the conversation, either at the same time or by switching between 336 modes e.g. between real-time Text-over-IP and voice. Native real- 337 time Text-over-IP systems MUST support simultaneous use of 338 modalities so that the text interface is always available. 340 When communicating via a gateway to other networks and protocols, 341 the system MUST completely support the functionality for 342 alternating or simultaneous modalities as offered by the gateway. 344 When voice is supported on the terminal, the terminal MUST provide 345 volume control. 347 7. Real-Time Multimedia Conversational Sessions using SIP 349 The Session Initiation Protocol (SIP) [3] provides mechanisms for 350 creating, modifying, and terminating sessions for real-time 351 conversation with one or more participants using any combination 352 of media: Text, Video and Audio. However, participants are allowed 353 to negotiate on a set of compatible media types (e.g., Text, 354 Video, Audio) with session descriptions used in SIP invitations. 356 The standardized T.140 real-time text conversation [4], in 357 addition to audio and video communications, will be valuable 358 services to many. Real-time text can be expressed as a part of the 359 session description in SIP and will be a useful subset of the 360 Total Conversation (e.g., Real-time text, Video and Audio). 362 This specification describes the framework for using the T.140 363 text conversation in SIP as a part of the multimedia session 364 establishment in real-time over a SIP network. 366 The session establishment using SIP defines procedures for how 367 T.140 text conversation can be supported using the text/t140RTP 368 payload defined in RFC 2793 [5]. The performance characteristics 369 of T.140 will be determined using RTCP. 371 The session will not only define procedures between the SIP 372 devices having text conversation capability, but will also define 373 how sessions in SIP can be established between the text 374 conversation and audio/video/text capable devices transparently. 376 If there is any incompatibility between the terminals, e.g. T.140 377 only and audio-only terminals, the necessary transcoding services 378 will need to be invoked. This important service feature offers a 379 variety of rich capabilities in the transcoding server. For 380 example, speech-to-text (STT), text-to-speech (TTS), text bridging 381 after conversion from speech, audio bridging after conversion from 382 text, and other services can also be provided by the transcoding 383 and/or translation server. The session description protocol (SDP) 384 [6] used in SIP to describe the session also needs to be capable 385 of expressing these attributes of the session (e.g., uniqueness in 387 A. van Wijk [Page 7 of 37] 388 draft-vanwijk-sipping-ToIP-00.txt July 2004 390 media mapping for conversion from one media to another for each 391 communicating party). 393 Real-time text can also be presented in conjunction with video and 394 audio. Making real-time text part of total conversation. 396 Visual and/or Tactile alerting for T.140 capable terminals should 397 to be provided. 399 Users may set up text conversation sessions using SIP from any 400 location. In addition, user privacy and security MUST be provided 401 for text conversation sessions at least equal to that for voice. 403 The transcoding/translation services can be invoked in SIP using 404 different session establishment models [7]: Third party call 405 control [8] and Conference Bridge model [9]. 407 Both point-to-point and multipoint communication need to be 408 defined for the session establishment using T.140 text 409 conversation. In addition, the interworking between T.140 text 410 conversation and text telephony conversation [10] is needed. 412 The general requirements for real-time text conversation using SIP 413 can be described as follows: 415 a. Session setup, modification and teardown procedures for point- 416 to-point and multimedia calls 418 b. Registration procedures and address resolutions 420 c. Registration of user preferences 422 d. Negotiation procedures for device capabilities 424 e. Discovery and invocation of transcoding/translation services 425 between the media in the call 427 f. Different session establishment models for 428 transcoding/translation services invocation: Third party call 429 control and Conference bridge model 431 g. Uniqueness in media mapping to be used in the session for 432 conversion from one media to another by the 433 transcoding/translation server for each communicating party 435 h. Media bridging services for T.140 real-time text, audio, and 436 video for multipoint communications 438 i. Transparent session setup, modification, and teardown between 439 text conversation capable and voice/video capable devices 441 j. Conversations to be carried out using T.140-over-RTP and RTCP 442 will provide performance report for T.140 444 A. van Wijk [Page 8 of 37] 445 draft-vanwijk-sipping-ToIP-00.txt July 2004 447 k. Altering capability using text conversation during the session 448 establishment 450 l. T.140 real-time text presentation mixing with voice and video 452 m. T.140 real-time text conversation sessions using SIP, allowing 453 users to move from one place to another 455 n. Users� privacy and security for sessions setup, modification, 456 and teardown as well as for media transfer 458 o. Interoperability between T.140 conversations and analogue text 459 telephones 461 p. Routing of emergency calls according to national or regional 462 policy. 464 8. General Requirements for Real-Time Text-over-IP using SIP 466 The communications environments for ToIP using SIP to set up the 467 conversation in real-time may vary from a simple point-to-point 468 call to multipoint calls in addition to the fact that ToIP can be 469 used in combination with other media like audio and video. In 470 order to establish the session in real-time, the communicating 471 parties SHOULD be provided with experiences like those of normal 472 telephony call setup. There may also be some need for pre-call 473 setup e.g. storing registration information in the SIP registrar 474 to provide information about how a user can be contacted. This 475 will allow calls to be set up rapidly and with proper addressing. 477 Similarly, there are requirements that need to be satisfied during 478 call set up when another media is preferred by a user. For 479 instance, some users may prefer to use audio while others want to 480 use text as their preferred choice of conversational mode. In this 481 case, transcoding services will need to be invoked for text-to- 482 speech (TTS) and speech-to-text (STT). The requirements for 483 transcoding services need to be negotiated in real-time to set up 484 the session. 486 The subsequent subsections describe those requirements in great 487 detail. 489 8.1 Pre-Call Requirements 491 The desire of the users for using ToIP as a medium of 492 communications can be expressed during registration time. Two 493 situations need to be considered in the pre-call setup 494 environment: 496 a. User Preferences: It MUST be possible for a user to indicate a 497 preference for ToIP by registering that preference in a SIP 498 server. If the user is called by other party, preferences can be 500 A. van Wijk [Page 9 of 37] 501 draft-vanwijk-sipping-ToIP-00.txt July 2004 503 invoked by the SIP server to accept or reject the call based on 504 the rules defined by the user. If the rules require that a 505 transcoding server is needed, the call can be re-directed or 506 handled accordingly. 508 b. Server to support User Preferences: SIP servers MUST have the 509 capability to act on users preferences for ToIP, based on the 510 users� preferences defined during the pre-call setup registration 511 time. 513 8.2 Basic Point-to-Point Call Requirements 515 The point-to-point call will take place between two parties. The 516 requirements are described in subsequent sub-sections. They assume 517 that one or both of the communicating parties will indicate ToIP 518 as a possible or preferred medium for conversation using SIP in 519 the session setup. 521 8.2.1 General Requirements 523 The general requirements are that ToIP will be chosen from the 524 available media as the preferred means of communication for the 525 session. However, there may be a need to invoke some underlying 526 capabilities in some cases, for example, a transcoding server may 527 be invoked if one of the users want to use a communication medium 528 other than ToIP. 529 The following features MAY need to be involved to facilitate the 530 session establishment using ToIP as another medium: 532 a. Caller Preferences: SIP headers (e.g., Contact) can be used to 533 show that ToIP is the medium of choice for communications. 535 b. Called Party Preferences: The called party being passive can 536 formulate a clear rule indicating how a call should be handled 537 either using ToIP as a preferred medium or not, and whether a 538 designated SIP proxy needs to handle this call or it is handled in 539 the SIP user agent (UA). 541 c. SIP Server support for User Preferences: SIP servers can also 542 handle the incoming calls in accordance to preferences expressed 543 for ToIP. The SIP Server can also enforce ToIP policy rules for 544 communications (e.g., use of the transcoding server for ToIP). 546 8.2.2 Session Setup 548 Users will set up a session by identifying the remote party or the 549 service they will want to connect to. However, conversations could 550 be started using a mode other than real-time Text-over-IP. For 551 instance, the conversation might be established using voice and 552 the user could elect to switch to text, or add text, during the 553 conversation. Systems supporting real-time Text-over-IP MUST allow 554 users to select any of the supported conversation modes at any 555 time, including mid-conversation. 557 A. van Wijk [Page 10 of 37] 558 draft-vanwijk-sipping-ToIP-00.txt July 2004 560 Systems SHOULD allow the user to specify a preferred mode of 561 communication, with the ability to fall back to alternatives that 562 the user has indicated are acceptable. 564 If the user requests simultaneous use of text and voice, and this 565 is not possible either because the system only supports alternate 566 modalities or because of resource management on the network, the 567 system MUST try to establish a text-only communication. and the 568 user MUST be informed of this change throughout the process, 569 either in text or in a combination of modalities that MUST include 570 text. 572 Session setup, especially through gateways to other networks, MAY 573 require the use of specially formatted addresses or other 574 mechanisms for invoking gateways. 575 Such mechanisms MUST be supported by the terminal. 577 8.2.3 Addressing 579 The SIP [3] addressing schemes MUST be used for all entities. For 580 example SIP URL and Tel URL will be used for caller, called party, 581 user devices, and servers (e.g., SIP server, Transcoding server). 583 The right to include a transcoding service MUST NOT require user 584 registration in any specific SIP registrar, but MAY require 585 authorisation of the SIP registrar in the service. 587 8.2.4 Alerting 589 Systems supporting real-time Text-over-IP MUST have an alerting 590 method (e.g., for incoming calls) that can be used by deaf and 591 hard of hearing people or provide a range of alternative, but 592 equivalent, alerting methods that are suitable for all users, 593 regardless of their abilities and preferences. 595 It should be noted that general alerting systems exist, and one 596 common interface for triggering the alerting action is a contact 597 closure between two conductors. 599 Among the alerting options are alerting on the user equipment and 600 specific alerting user agents registered to the same registrar as 601 the main user agent. 603 If present, identification of the originating party (for example 604 in the form of a URL or CLI) MUST be clearly presented to the user 605 in a form suitable for the user BEFORE answering the request. When 606 the invitation to initiate a conversation involving real-time 607 Text-over-IP originates from a gateway, this MAY be signalled to 608 the user. 610 8.2.5 Call Negotiations 612 A. van Wijk [Page 11 of 37] 613 draft-vanwijk-sipping-ToIP-00.txt July 2004 615 The Session Description Protocol (SDP) used in SIP [3] provides 616 the capabilities to indicate ToIP as a media in the call setup. 617 RFC 2793 [5] provides the RTP payload type text/t140 for support 618 of ToIP which can be indicated in the SDP as a part of SDP INVITE, 619 OK and SIP/200/ACK for media negotiations. In addition, SIP�s 620 offer/answer model can also be used in conjunction with other 621 capabilities including the use of a transcoding server for 622 enhanced call negotiations [7,8,9]. 624 8.2.6 Answering 626 Systems SHOULD provide a best-effort approach to answering 627 invitations for session set-up and users should be kept informed 628 at all times about the progress of session establishment. On all 629 systems that both inform users of session status and support real- 630 time Text-over-IP, this information MUST be available in text, and 631 may be provided in other visual media. 633 8.2.6.1 Answering Machine 635 Systems for real-time Text-over-IP MAY support an auto-answer 636 function, equivalent to answering machines on telephony networks. 637 If an answering machine function is supported, it MUST support at 638 least 160 characters for the greeting message. It MUST support 639 incoming text message storage of a minimum of 16000 characters, 640 although systems MAY support much larger storage. 642 When the answering machine is activated, user alerting MUST still 643 take place. The user MUST be allowed to monitor the auto-answer 644 progress and MUST be allowed to intervene during any stage of the 645 answering machine and take control of the session. 647 8.2.7 Session progress and status presentation 649 During a conversation that includes real-time Text-over-IP, status 650 and session progress information MUST be provided in text. That 651 information MUST be equivalent to session progress information 652 delivered in any other format, for example audio. Users MUST be 653 able to manage the session and perform all session control 654 functions based on the textual session progress information. 656 The user MUST be informed of any change in modalities. 658 Session progress information MUST use simple language as much as 659 possible so that it can be understood by as many users as 660 possible. 661 The use of jargon or ambiguous terminology SHOULD be avoided at 662 all times. It is RECOMMENDED to let text information be used 663 together with icons symbolising the items to be reported. 665 There MUST be a clear indication, both visually as well as audibly 666 whenever a session gets connected and disconnected. The user 668 A. van Wijk [Page 12 of 37] 669 draft-vanwijk-sipping-ToIP-00.txt July 2004 671 should never be in doubt as to what the status of the connection 672 is, even if he/she is not able to use audio feedback or vision. 674 8.2.8 Actions During Calls 676 Certain actions need to be performed for the ToIP conversation 677 during the call and these actions are describe briefly as follows: 679 a. Text transmission SHALL be done character by character as 680 entered, or in small groups transmitted so that no character is 681 delayed between entry and transmission by more than 300 682 milliseconds. 683 b. The text transmission SHALL allow a rate of at least 30 684 characters per second so that human typing speed as well as speech 685 to text methods of generating conversation text can be supported. 687 c. After text connection is established, the mean end-to-end delay 688 of characters SHALL be less than two seconds, measured between two 689 ToIP users. This requirement is valid as long as the text input 690 rate is lower or equal to the text reception and display rate. 692 d. The character corruption rate SHALL be less than 1% in 693 conditions where users experience the quality of voice 694 transmission to be low but useable. This is in accordance with 695 ITU-T F.700 Annex A.3 quality level T1. 697 e. When interoperability functions are invoked, there may be a 698 need for intermediate storage of characters before transmission to 699 a device receiving slower than the typing speed of the sender. 700 Such temporary storage SHALL be dimensioned to adjust for 701 receiving at 30 characters per second and transmitting at 6 702 characters per second during at least 4 minutes [less than 3k 703 characters]. 705 f. If text is detected to be missing after transmission, there 706 SHALL be an indication in the text marking the loss. 708 g. When used from a terminal designed for PSTN text telephony, or 709 in interworking with such a terminal, ToIP shall enable 710 alternating between text and voice in a similar manner as the PSTN 711 text telephone handles this mode of operation. (This mode is often 712 called VCO/HCO in USA). 714 h. The transmission of the text conversation SHALL be made 715 according to an internationally suitable character set and control 716 protocol for text conversation as specified in ITU-T T.140. 718 i. When display of the conversation on end user equipment is 719 included in the design, display of the dialogue SHALL be made so 720 that it is easy to read text belonging to each party in the 721 conversation. 723 8.2.8.1 Text and other Media Handling Between ToIP Devices 725 A. van Wijk [Page 13 of 37] 726 draft-vanwijk-sipping-ToIP-00.txt July 2004 728 The ToIP devices do not need transcoding from speech to text and 729 can communicate directly using text/t140. The following 730 requirements are valid for media handling during calls: 732 a. When used between terminals designed for ToIP, it SHALL be 733 possible to send and receive text simultaneously with the other 734 media (text, audio and/or video) supported by the same terminals. 736 b. When used between terminals designed for ToIP, it SHALL be 737 possible to send and receive text simultaneously. 739 c. It should be possible to know during the call that ToIP is 740 available, even if it is not invoked at call setup (only voice 741 and/or video is used). To disable this, the user must disable the 742 use of ToIP. 744 8.2.8.2 General Actions 746 a. It SHALL be possible to establish a session with text 747 capabilities enabled at the beginning of a Call. Note: a call is 748 in this document defined as one or more sessions). 750 b. It SHALL be possible to place a call without text capabilities, 751 and to add text capabilities later in the call. 753 c. It SHALL be possible to transfer text at at least 30 characters 754 per second 756 d. It SHALL be possible to talk and listen simultaneously with 757 typing and reading. 759 8.2.8.3 Call Action with Native ToIP Devices 761 a. It SHOULD be possible to answer a call with text capabilities 762 enabled. 764 b. It SHOULD be possible to use video simultaneously with the 765 other media in the call. 767 c. It SHOULD be possible to answer a call in voice or video 768 without text enabled, and add text later in the call. 770 d. It MUST be possible to disconnect the call. 772 e. It SHOULD be possible to control IVR (Interactive Voice 773 Response) services from a numeric keypad. 775 f. It SHOULD be possible to control ITR ( Interactive Text 776 Response) services from the alphanumeric keyboard. 778 g. It SHOULD be possible to invoke multi-party calls. 780 A. van Wijk [Page 14 of 37] 781 draft-vanwijk-sipping-ToIP-00.txt July 2004 783 h. It SHALL be possible to transfer the call. 785 i. It MUST be possible to use text characters (numbers) instead of 786 DTMF tones (numbers) in interactions where the person is using a 787 keyboard to interact with a service and the service asks for a 788 number. 790 8.2.8.4 Audio/Visual/Tactile Indicators 792 It SHOULD be possible to observe visual or tactile indicators 793 about: 794 - Call progress 795 - Availability of text, voice and video channels. 796 - Incoming call. 797 - Incoming text. 798 - Typed and transmitted text. 799 - Any loss in incoming text. 801 8.2.9 Additional session control 803 Systems that support additional session control features, for 804 example call waiting, forwarding, hold etc on voice calls, MUST 805 offer equivalent functionality for real-time Text-over-IP 806 functions. In addition, all these features MUST be controllable by 807 text users at any time, in an equivalent way as for other users. 809 8.2.10 File storage 811 Systems that support real-time Text-over-IP MAY save the text 812 conversation to a file. This SHOULD be done using a standard file 813 format. 815 8.3 Conference Call Requirements 817 The conference call requirements deal with multipoint conferencing 818 calls where there will be at least one or more ToIP capable 819 devices along with other end user devices where the total number 820 end user devices will be at least three. 822 It SHOULD be possible to use the text medium in conference calls, 823 in a similar way as video is handled and displayed. Text in 824 conferences can be used both for letting individual participants 825 use the text medium, and for central support of the conference 826 with real time text interpretation of speech. 828 8.4 Transport 830 ToIP uses RTP as the default transport protocol for transmission 831 of real-time text medium text/t140 as specified in RFC 2793 [5]. 832 Signaling and other media will use the transport protocol 833 specified in SIP [3] and/or their revised versions as specified in 834 standards. 836 A. van Wijk [Page 15 of 37] 837 draft-vanwijk-sipping-ToIP-00.txt July 2004 839 The redundancy method of RFC 2198 SHOULD be used for making text 840 transmission reliable with transmission of three generations. 842 Text capability SHOULD be announced in SDP by a declaration in 843 line with this example: 845 m=text 11000 RTP/AVP 98 100 846 a=rtpmap:98 t140/1000 847 a=rtpmap:100 red/1000 848 a=fmtp:100 98/98/98 850 Characters SHOULD BE buffered for transmission and transmitted 851 every 300 ms. 853 By having this single coding and transmission scheme for real time 854 text defined, in the SIP call control environment, the opportunity 855 for interoperability is optimized. 857 However, if good reasons exist, other transport mechanisms MAY be 858 offered and used for the T.140 coded text, provided that proper 859 negotiation is introduced, and RFC 2793 transport MUST be used as 860 the defaut fallback solution. 862 8.5 Character Set 864 a. Real-Time Text-over-IP protocols MUST use UTF-8 encoding as 865 specified in ITU-T T.140 [12]. 867 b. Real-time Text-over-IP SHOULD handle characers with editing 868 effect such as new line, erasure and alerting during session as 869 specified in ITU-T T.140. 871 8.6 Transcoding 873 Transcoding of text may need to take place in gateways between 874 ToIP and other forms of text conversation. ToIP makes use of 875 ISO 10646 character set. 876 Most PSTN textphones use a 7-bit character set, or a character set 877 that is converted to a 7-bit character set by the V.18 modem. 879 When transcoding between these character sets and T.140 in 880 gateways, special consideration MUST be paid to the national 881 variants of the 7 bit codes, with national characters mapping into 882 different codes in the ISO 10 646 code space. The national variant 883 to be used SHOULD be possible to select by the user per call, or 884 be configured as a national default for the gateway. 886 The missing text indicator in T.140, specified in T.140 amendment 887 1, cannot be represented in the 7 bit character codes. Therefore 888 these characters SHOULD be translated to be represented by the ' 889 (apostrophe) character in legacy text telephone systems where this 891 A. van Wijk [Page 16 of 37] 892 draft-vanwijk-sipping-ToIP-00.txt July 2004 894 character exists. For legacy systems where the character ' does 895 not exist, the character . ( full stop ) SHOULD be used instead. 897 8.7 Relay Services 899 The relay service acts as an intermediary between 2 or more 900 callers. 901 The basic relay service allows a translation of speech to text and 902 text to speech, which enables hearing and speech impaired callers 903 to communicate with hearing callers. Even though this document 904 focuses on ToIP, we do not exclude video relay services for e.g., 905 speech to sign language and vice versa and other possible relay 906 services. It will be possible to use ToIP simultaneously with 907 other relay services if desired. 909 It is very important for the users that a relay session is invoked 910 as transparently as possible. It SHOULD happen automatically when 911 the call is being set-up or by a simple user action. A transcoding 912 framework document using SIP [7] describes invoking relay 913 services, where the relay acts as a conference bridge or uses the 914 third party control mechanism. 916 Adding or removing a relay service MUST be possible without 917 disrupting the current call. 919 When setting up a call, the relay service MUST be able to 920 determine the type of service requested (e.g. speech to text or 921 text to speech), to indicate if the caller wants voice carry over, 922 the language of the text including the sign language being used. 924 The user MUST be provided with a method to indicate which service 925 is desired. 927 Relay services MUST be reachable all the time, even if the users 928 are visiting other operator?s networks. 930 It SHOULD be possible to route the call to a preferred relay 931 service even if the user makes the call from another region or 932 network than usually used. 934 It MUST be possible to identify ToIP sessions as emergency 935 sessions. 937 If it is decided that a relay service supports emergency calls, 938 the relay service operator MUST be able to process such a session 939 correctly and quickly with the following functionality: 941 a. The relay service operator�s network MUST give priority to this 942 incoming call. 944 b. The relay service operator MUST forward this session if they 945 are unable to process it to an alternative emergency relay 946 operator. 948 A. van Wijk [Page 17 of 37] 949 draft-vanwijk-sipping-ToIP-00.txt July 2004 951 c. The relay service MUST label the transcoded stream as an 952 emergency call (in case of text to speech and/or vice versa). 954 d. The relay service MUST provide all session information to the 955 emergency centre (e.g., location information of the caller if 956 available). 958 8.8 Emergency services 960 a. It SHOULD be possible to support emergency service calls with 961 text only or simultaneously with voice. 963 b. All session information that accompanies a voice session to the 964 emergency centre, should also be provided to the emergency centre 965 if it is a ToIP session.(e.g, phone number and location 966 information of the user placing the emergency call). 968 c. A text over IP stream must be labelled as an emergency stream 969 to ensure that the emergency service center is able to receive 970 this call. 972 8.9 User Mobility 974 ToIP terminals SHOULD use the same mechanisms as other terminals 975 to resolve mobility issues. It is RECOMMENDED to use a SIP-adress 976 for the users, resolved by a SIP REGISTRAR, to enable basic user 977 mobility. Further mechanisms are defined for the 3G IP multimedia 978 systems. 980 8.10 Confidentiality and Security 982 Users� confidentiality and privacy need to be met as described in 983 SIP [3]. For example, nothing should reveal the fact that the user 984 of ToIP is a person with a disability unless the user prefers to 985 make this information public. If a transcoding server is being 986 used, this SHOULD be transparent. Encryption SHOULD be used on 987 end-to-end or hop-by-hop basis as described in SIP [3] and SRTP 988 [19] 990 Authentication needs to be provided for users in addition to the 991 message integrity and access control. 993 Protection against Denial-of-service (DoS) attacks needs to be 994 provided considering the case that the ToIP users might need 995 transcoding servers. 997 8.11 Call Flows 999 ToIP is a way of establishing the real-time conversation. Call 1000 flow for ToIP SHOULD be similar to session 1001 establishment with audio and video. For example, ToIP services MAY 1002 be invoked in the following situations (among others): 1004 A. van Wijk [Page 18 of 37] 1005 draft-vanwijk-sipping-ToIP-00.txt July 2004 1007 - Noisy environment (e.g., in a machine room of a factory where 1008 listening is difficult)Busy with another call and want to 1009 participate in two calls at the same time. 1011 - Text and/or speech recording services (e.g., text 1012 documentation/audio recording for legal/clarity/flexibility 1013 purposes) 1014 - Overcoming of language barriers through speech translation 1015 and/or transcoding services 1017 - Not hearing well or not at all (e.g., hearing loss due to aging, 1018 hard of hearing, deaf) 1020 NOTE: In many of the above scenarios, text may accompany speech in 1021 a subtitling like fashion. This would occur for individuals who 1022 are hard of hearing and also for mixed calls with a hearing and 1023 deaf person listening to the call. 1025 All call flows either for the point-to-point or for the multipoint 1026 situation need to consider that ToIP services may be invoked for 1027 many different reasons by users as explained. When the 1028 transcoding/translation services are needed, call flows will be 1029 shown for both session establishment models: Third-party call 1030 control model and Conferencing bridge model. 1032 8.11.1 Call Scenarios 1034 There are 2 different terminal types possible: 1036 1. The terminal itself has the intelligence to initiate a relay 1037 service for incoming and outgoing calls (based on address book, 1038 user preferences programmed on the terminal etc. This terminal can 1039 be used in a conference bridge call as well as a third party 1040 control call. 1042 2. Dumb terminals, so that the relay service server actually 1043 initiates the correct call handling (the dumb terminal can only 1044 REFER the call to the relay center, which then sets up the call 1045 using the conference bridge flow.). 1047 The following call scenarios are shown: 1049 - Communications between two ToIP/Multimedia capable, end user 1050 devices using the same language. 1052 - Communications between ToIP capable, end user devices using 1053 translation services to provide language translation. 1055 - Communications between ToIP/Multimedia capable and Audio (non- 1056 ToIP) capable end user devices. 1058 A. van Wijk [Page 19 of 37] 1059 draft-vanwijk-sipping-ToIP-00.txt July 2004 1061 - Communications between ToIP/Multimedia and/or Audio (non- 1062 ToIP)/Multimedia end user devices maintaining privacy. 1064 8.11.2 Point-to-Point Call Flows 1066 The point-to-point calls will contain at least one or both 1067 ToIP/Multimedia devices in setting up the session. The detail call 1068 flows need to be provided in the following scenarios: 1070 - ToIP/Multimedia devices that use the same language. 1072 - ToIP/Multimedia devices invoke translation services for using 1073 different languages. 1074 * Third-party call control model. 1075 * Conference bridge service model. 1077 - ToIP/Multimedia devices invoke translation services for using 1078 different languages maintaining privacy. 1079 * Third-party call control model. 1080 * Conference bridge service model. 1082 - ToIP/Multimedia device and Audio (non-ToIP)/Multimedia device 1083 invoking transcoding server. 1084 * Call initiated by Audio (non-ToIP)/Multimedia user 1085 - Third-party call control model. 1086 - Conference bridge service model. 1087 * Call initiated by ToIP user. 1088 - Third-party call control model. 1089 - Conference bridge service model. 1091 - ToIP/Multimedia device and Audio (non-ToIP)/Multimedia device 1092 invoking transcoding server maintaining privacy. 1093 * Call initiated by Audio (non-ToIP)/Multimedia user 1094 - Third-party call control model. 1095 - Conference bridge service model. 1096 * Call initiated by ToIP user. 1097 - Third-party call control model. 1098 - Conference bridge service model. 1100 8.11.3 Conference Call Flows 1102 Conference call flows only contain the multipoint communications 1103 scenarios, and only the centralized bridge model is considered. 1104 The following multipoint conference call flow scenarios will 1105 contain at least one more ToIP/Multimedia devices: 1107 - ToIP/Multimedia devices that use the same language. 1109 - ToIP/Multimedia devices invoke translation services for using 1110 different languages. 1112 - ToIP/Multimedia devices invoke translation services for using 1113 different languages maintaining privacy. 1115 A. van Wijk [Page 20 of 37] 1116 draft-vanwijk-sipping-ToIP-00.txt July 2004 1118 - ToIP/Multimedia device and Audio (non-ToIP)/Multimedia device 1119 invoking transcoding server. 1120 * Call initiated by Audio (non-ToIP)/Multimedia user. 1121 * Call initiated by ToIP/Multimedia user. 1123 - ToIP/Multimedia device and Audio (non-ToIP)/Multimedia device 1124 invoking transcoding server maintaining privacy. 1125 * Call initiated by Audio (non-ToIP)/Multimedia user. 1126 * Call initiated by ToIP/Multimedia user. 1128 9. Interworking Requirements for Text-over-IP 1130 A number of systems for real time text conversation already exist 1131 as well as a number of message oriented text communication 1132 systems. Interoperability is of interest between ToIP and some of 1133 these systems. This section describes requirements on this 1134 interoperability. 1136 9.1 Real-Time Text-over-IP Interworking Gateway Services 1138 Interactive texting facilities exist already in various forms and 1139 on various networks. On the PSTN, it is commonly referred to as 1140 text telephony. The simultaneous or alternating use of voice and 1141 text is used by a large number of users who can send voice, but 1142 must receive text or who can hear but must send text due to a 1143 speech disability. 1145 9.2 Text-over-IP and PSTN/ISDN Text-Telephony 1147 On PSTN networks, transmission of interactive text takes place 1148 using a variety of codings and modulations, including ITU-T V.21 1149 [II], Baudot, DTMF, V.23 [III] and others. Many difficulties have 1150 arisen as a result of this variety in text telephony protocols and 1151 the ITU-T V.18 [10] standard was developed to address some of 1152 these issues. 1154 ITU-T-V.18 [10] offers a native text telephony method plus it 1155 defines interworking with current protocols. In the interworking 1156 mode, it will recognise one of the older protocols and fall back 1157 to that transmission method when required. 1159 In order to allow systems and services based on Real-time Text- 1160 over-IP to communicate with PSTN text telephones, text gateways 1161 are the recommended approach. These gateways MUST use the ITU-T 1162 V.18 [10] standard at the PSTN side. 1164 Buffering MUST be used to support different transmission rates. At 1165 least 1K buffer MUST be provided. A buffer of at least 2K 1166 characters is recommended. In addition, the gateway MUST provide a 1167 minimum throughput of at least 30 characters/second or the highest 1168 speed supported by the PSTN text telephony protocol side, 1169 whichever is the lowest. 1171 A. van Wijk [Page 21 of 37] 1172 draft-vanwijk-sipping-ToIP-00.txt July 2004 1174 PSTN-Real-time Text-over-IP gateways MUST allow alternating use of 1175 text and voice. 1177 PSTN and ISDN to real-time Text-over-IP gateways that receive CLI 1178 information from the originating party MUST pass this information 1179 to the receiving party as soon as possible. 1181 Priority MUST be given to calls labeled as emergency calls. 1183 9.3 Text-over-IP and Cellular Wireless circuit switched Text- 1184 Telephony 1186 Cellular wireless (or Mobile) circuit switched connections provide 1187 a digital real-time transport service for voice or data. 1188 The access technologies include GSM, CDMA, TDMA, iDen and various 1189 3G technologies. 1191 Alternative means of transferring the Text telephony data have 1192 been developed when TTY services over cellular was mandated by the 1193 FCC in the USA. They are a) �No-gain� codec solution, b) the 1194 Cellular Text Telephony Modem (CTM) solution and c) �Baudot mode� 1195 solution. 1197 The GSM and 3G standards from 3GPP make use of the CTM modem in 1198 the voice channel for text telephony. 1199 However, implementations also exist that use the data channel to 1200 provide such functionality. Interworking with these solutions 1201 SHOULD be done using text gateways that set up the data channel 1202 connection at the GSM side and provide real-time Text-over-IP at 1203 the other side. 1205 9.3.1 "No-gain" 1207 The "No-gain" text telephone transporting technology uses 1208 specially modified EFR [15] and EVR [16] speech vocoders in both 1209 mobile terminals used provide a text telephony call. It provides 1210 full duplex operation and supports alternating voice and text.( 1211 "VCO/HCO"). It is dedicated to the CDMA and TDMA mobile 1212 technologies and the US Baudot type of text telephones. 1214 9.3.2 Cellular Text Telephone Modem (CTM) 1216 CTM [17] is a technology independent modem technology that 1217 provides the transport of text telephone characters at up to 10 1218 characters/sec using modem signals that are at or below 1 kHz and 1219 uses a highly redundant encoding technique to overcome the fading 1220 and cell changing losses. On any interface that uses analog 1221 transmission, half-duplex operation must be supported as the 1222 �send� and �receive� modem frequencies are identical. The use of 1223 CTM may have to be modified slightly to support half-duplex 1224 operation. 1226 A. van Wijk [Page 22 of 37] 1227 draft-vanwijk-sipping-ToIP-00.txt July 2004 1229 9.3.3 "Baudot mode" 1231 This term is often used by cellular terminal suppliers for a GSM 1232 cellular phone mode that allows TTYs to operate into a cellular 1233 phone and to communicate with a fixed line TTY. 1235 9.3.4 Data channel mode 1237 Many mobile terminals allow the use of the data channel to 1238 transfer data in real-time. Data rates of 9600 bit/s are usually 1239 supported on the mobile connection.Gateways or the interworking 1240 function provides interoperability with PSTN textphones. 1242 9.3.5 Common Text Gateway Functions 1244 Text Gateways MUST cover the differences that result from 1245 different text protocols. The protocols to be supported will 1246 depend on the service requirements of the Gateway. 1248 Different data rates of different protocols MAY require text 1249 buffering. 1251 Interoperation of half-duplex and full-duplex protocols MAY 1252 require text buffering and some intelligence to determine when to 1253 change direction when operating in half-duplex. 1255 Identification may be required of half-duplex operation either at 1256 the �user� level (ie. users must inform each other) or at the 1257 �protocol� level (where an indication must be sent back to the 1258 Gateway). 1260 A Text Gateway MUST be able to route text calls to emergency 1261 service providers when any of the recognised emergency numbers 1262 that support text communications for the country or region are 1263 called eg. �911� in USA and �112� in Europe. 1265 A text gateway MUST act transparently on the IP side. It acts then 1266 as a virtual end-point terminal. 1268 9.4 Text-over-IP and Cellular Wireless Text-over-IP 1270 Text-over-IP MAY be supported over the cellular wireless packet 1271 switched service. It interfaces to the Internet. For 3GPP 3G 1272 services, the support is described to use ToIP in 3G TS 26.235 1273 [20]. 1275 A Text gateway with cellular wireless packet switched services 1276 MUST be able to route text calls into emergency service providers 1277 when any of the recognized emergency numbers that support text 1278 communication for the country are called. 1280 9.5 Instant Messaging Support 1282 A. van Wijk [Page 23 of 37] 1283 draft-vanwijk-sipping-ToIP-00.txt July 2004 1285 Instant Messaging is used by many people to communicate using text 1286 via the Internet. Instant Messaging transfers blocks of text 1287 rather than streaming as is used for real-time Text-over-IP. As 1288 such, it is not a replacement for real-time Text-over-IP and in 1289 particular does not meet the needs for real time conversations of 1290 deaf, hard of hearing and speech-impaired users. It is unsuitable 1291 for communications through a relay service [I]. The streaming 1292 character of real-time Text-over-IP provides a better user 1293 experience and, when given the choice, users often prefer real- 1294 time Text-over-IP. 1296 However, since some users might only have Instant Messaging 1297 available, text gateways might be developed that allow 1298 interworking between Instant Messaging systems and real-time Text- 1299 over-IP solutions. 1301 Because Instant Messaging is based on blocks of text, rather than 1302 on a continuous stream of characters, such gateways need to 1303 transform between these two formats. Text gateways for 1304 interworking between Instant Messaging and real-time Text-over-IP 1305 MUST concatenate individual characters originating at the real- 1306 time Text-over-IP side into blocks of text and: 1308 a. When the length of the concatenated message becomes longer than 1309 50 characters, the buffered text MUST be transmitted to the 1310 Instant Messaging side as soon as any non-alphanumerical character 1311 is received from the real-time Text-over-IP side. 1313 b. When a new line is received from the real-time Text-over-IP 1314 side, the buffered characters up to that point, including the 1315 carriage return and/or line feed characters, MUST be transmitted 1316 to the Instant Messaging side. 1318 c. When the real-time Text-over-IP side has been idle for at least 1319 5 seconds, all buffered text up to that point MUST be transmitted 1320 to the Instant Messaging side. 1322 It is recommended that during the session, both users are 1323 constantly updated on the progress of the text input. 1324 For example, many Instant Messaging protocols signal that a user 1325 is typing to the other party in the conversation. Text gateways 1326 between Instant Messaging and real-time Text-over-IP MUST provide 1327 this signaling to the Instant Messaging side when characters start 1328 being received, or at the beginning of the conversation. 1329 Also at the real-time text-over-IP side, an indicator of writing 1330 the Instant Message MUST be present. For example, the real-time 1331 text user will see . . . waiting for replying IM. . . And per 5 1332 seconds a . (dot) can be shown. 1333 Those solutions will reduce the difficulties between a streaming 1334 versus blcoked text. 1336 Even though that the text gateway can connect Instant Messaging 1337 and real-time Text-over-IP. The best solution is to take advantage 1339 A. van Wijk [Page 24 of 37] 1340 draft-vanwijk-sipping-ToIP-00.txt July 2004 1342 of the fact that the user interfaces and the user communities for 1343 instant messaging and real-time text-over-IP telephony are 1344 extremely similar. 1346 After all, the character input, the character display, Internet 1347 connectivity, SIP stack, etc are the same for Instant Messaging 1348 and real-time Text-over-IP. 1350 Devices that implement Instant Messaging SHOULD implement real- 1351 time text-over-IP telephony, using standard SIP and text/t140 1352 mechanisms. 1354 9.6 IP Telephony with Traditional RJ-11 Interfaces 1356 Analogue adapters using SIP based IP communication and RJ-11 1357 connectors for connecting traditional PSTN devices SHOULD enable 1358 connection of legacy PSTN text telephones [18]. These adapters 1359 SHOULD contain V.18 modem functionality, voice handling 1360 functionality, and conversion functions to/from SIP based ToIP 1361 with T.140 transported according to RFC 2793, in a similar way as 1362 it provides interoperability for voice calls. If a call is set up 1363 and text/t140 capability is not declared by the endpoint (by the 1364 end-point terminal or the text gateway in the network at the end- 1365 point), a method for invoking a transcoding server shall be used. 1366 If no such server is available, the signals from the textphone MAY 1367 be transmitted in the voice channel as audio with high quality of 1368 service. 1369 NOTE: It is preferred that such analogue adaptors do use RFC2793 1370 on board and thus act as a text gateway. Sending textphone signals 1371 over the voice channel is undesirable due posible filtering and 1372 compression and packet loss between the end-points. Which can 1373 result in dropping characters in the textphone conversation or 1374 even not allowing the textphones to connect with each other. 1376 9.7 Interworking Call Flows 1378 << this chapter will change depending on how chapter 9.10 works 1379 out>> 1381 The call flows in chapter 8.11 deal with end to end ToIP. These 1382 call flows do not change on the IP network when one end-point is 1383 actually a text gateway. The text gateway actually acts like a 1384 ToIP/Multimedia device. Separate call flows will show the 1385 interworking between the ToIP/Multimedia devices [4] over the IP 1386 network and the text telephony devices [10] over the PSTN/ISDN 1387 network using the IP-PSTN/ISDN interworking functional (IWF) 1388 entity. It is assumed that the IWF will provide ToIP and text 1389 telephony interworking in addition to other capabilities. Thus 1390 acting as a Text gateway. 1392 The point-to-point call flows will contain at least one 1393 ToIP/Multimedia and one text telephony/multimedia (or POTS) device 1394 for the following cases: 1396 A. van Wijk [Page 25 of 37] 1397 draft-vanwijk-sipping-ToIP-00.txt July 2004 1399 - ToIP/Multimedia device and text telephony/multimedia device that 1400 use the same/different language. 1401 - ToIP/Multimedia device and PSTN/ISDN-based POTS/Multimedia 1402 device. 1404 For multipoint conferencing calls, it is assumed that only the 1405 centralized conferencing will be considered, and the media bridge 1406 is supposed to be located somewhere in the SIP network. However, 1407 it is considered that the ToIP and text telephony interworking 1408 function will be located in the IWF. 1410 The multipoint conference call flows will contain at least one 1411 ToIP/Multimedia device, at least one text telephony/multimedia 1412 device, and other devices where total number of devices will be 1413 three or more for the following cases: 1415 - ToIP/Multimedia and text telephony/multimedia devices that use 1416 the same/different language. 1417 - ToIP/Multimedia devices, telephony/multimedia devices, and/or 1418 PSTN/ISDN-based POTS/Multimedia devices. 1420 9.8 Multi-functional gateways 1422 The scenarios described in this document deal with single pairs of 1423 interworking protocols or services. However, in practice many of 1424 these interworking systems will be implemented as gateways that 1425 combine different functions. As such, a text gateway could be 1426 build to have modems to interwork with the PSTN and support both 1427 Instant Messaging as well as real-time ToIP. Such interworking 1428 functions are called Combination gateways. 1430 Combination gateways MUST provide interworking between all of 1431 their supported text based functions. For example, a text gateway 1432 that has modems to interwork with the PSTN and that support both 1433 Instant Messaging and real-time ToIP MUST support the following 1434 interworking functions: 1436 - PSTN text telephony to real-time ToIP. 1437 - PSTN text telephony to Instant Messaging. 1438 - Instant Messaging to real-time ToIP. 1440 9.9 Gateway Discovery 1442 To get a smooth invocation of the text gateways, where those 1443 gateways are transparant on the IP side, it requires a method how 1444 and when to invoke the text gateway. As described previously in 1445 this draft. The text gateways must act as the end-terminal. The 1446 capabilities of the text gateway will in that call be determined 1447 by the call capabilities of the terminal that is using the 1448 gateway. For example, a PSTN textphone is only able to receive 1450 A. van Wijk [Page 26 of 37] 1451 draft-vanwijk-sipping-ToIP-00.txt July 2004 1453 voice and streaming text. Thus the text gateway will only allow 1454 ToIP and audio. 1456 The PSTN devices or other non IP multimedia devices that require 1457 the text gateways to connect to the IP must be able to locate the 1458 text gateway, and ensure that the correct call capabilities of the 1459 non IP multimedia device is used by the text gateway. 1461 The following possible solutions for using the text gateway are: 1463 - PSTN Textphone users using a prefix number before dialing out. 1464 - In band text dialogue, where the gateway asks the user for the 1465 destination address. 1466 - separate text subscriptions, linked to the phone number or 1467 terminal identifier/ IP address. 1468 - text capability indicators. 1469 - text preference indicator. 1470 - listen for text activity in all calls. 1471 - call transfer request by the called user. 1472 - placing a call via the web, and use one of the methods described 1473 here 1474 - text gateways with its own telephone number and/or SIP address. 1475 (this requires user interaction with the text gateway to place a 1476 call). 1477 - ENUM address analysis and number plan 1478 - number or address analysis leads to the gateway for all PSTN 1479 calls. 1480 - etc 1482 9.10 Text Gateway in the call Scenarios 1484 9.10.1 IP terminal calling an analogue textphone (PSTN) 1486 The ToIP stream will be converted into an analogue text telephone 1487 protocol (using the voice channel) and vice versa by the text 1488 gateway. 1490 The PSTN knows that it may be a textphone call thanks to the SDP 1491 description (for example: m=text 11000 RTP/AVP 98 a=rtpmap:98 1492 t140/1000 for T.140 text on port 11000). It can then activate text 1493 gateway functions on the PSTN side listening for a text answer. 1495 The PSTN will also know that all those incoming calls are only for 1496 analogue textphones. Thus the speed of the text stream is adjusted 1497 to the selected analogue textphone protocol. 1498 If there is no analogue textphone on the called number, the call 1499 setup will be terminated by the text gateway. 1501 The text gateway can be implemented in two ways: The PSTN has its 1502 own text gateway (the IWF), or it redirects the media stream to 1503 the nearest IP-PSTN gateway with text transcoding abilities. 1505 Text gateway detection: In the SIP messages. 1507 A. van Wijk [Page 27 of 37] 1508 draft-vanwijk-sipping-ToIP-00.txt July 2004 1510 9.10.2 IP terminal calling a mobile text telephone (CTM) 1512 The ToIP stream will be converted into CTM and vice versa by the 1513 text gateway located in the network of the cellular/mobile 1514 operator. It is similar to the PSTN. 1516 Text gateway detection: In the SIP messages. 1518 9.10.3 IP terminal calling a mobile telephone (GPRS based) 1520 A text gateway located in the mobile network converts the incoming 1521 T.140/RTP stream into for example T.140 over TCP (T.140/TCP) or 1522 tunnels the T.140 stream over HTTP (T.140/HTTP). Or any other 1523 temporarily non standard solution necessary to connect the text 1524 gateway with the text telephone client on the mobile phone. 1526 This is necessary, since RTP over GPRS is not possible in many 1527 mobile phones. 1528 Note, those server-client solutions are ONLY acceptable for the 1529 GPRS and non RTP stack phones. It is encouraged to use T.140/RTP 1530 as soon as possible for all mobile phones. 1531 Allowing UDP transport over the GPRS link will enable RFC2793 text 1532 over GPRS. 1534 Text gateway detection: In the SIP messages. 1536 9.10.4 IP terminal calling a mobile telephone(UMTS) 1538 No text gateway is required here since this will be end to end IP. 1540 9.10.5 Analogue textphone (PSTN) user calling an IP terminal using 1541 prefix 1543 The PSTN is unable to distinguish between an analogue voice call 1544 and an analogue textphone, both use the voice channel. The text 1545 gateway needs to transcode the analogue textphone protocol into 1546 T.140/RTP. 1548 One way for a PSTN to separate an incoming voice call into text 1549 telephony or normal voice is by using a prefix number for all 1550 incoming text telephone calls to the PSTN. For example , the text 1551 telephone user (e.g Boudot) places a call and enters a prefix e.g. 1552 600 and then continues with the original number. The PSTN will 1553 recognize all incoming 600 calls as an analogue textphone call and 1554 redirects the call to a text gateway (unless it is a number 1555 connecting the same PSTN). 1557 It is undesirable to allow a PSTN to transport all the analogue 1558 textphone tones/signals through a VoIP stream! (In band text 1559 dialogue). 1561 A. van Wijk [Page 28 of 37] 1562 draft-vanwijk-sipping-ToIP-00.txt July 2004 1564 Text gateway detection: Prefix number for incoming textphone 1565 calls. 1567 9.10.6 Mobile text telephone (CTM) user calling an IP terminal 1569 The voice channel of the cellular network is used. The MSC is able 1570 to separate between the text call and voice only, it is just a 1571 matter of redirecting the voice channel to the text gateway. 1573 Text gateway detection: CTM signal detection. 1575 9.10.7 Mobile telephone user (GPRS) calling an IP terminal 1577 The text telephone client on the mobile telephone connects the 1578 text gateway located in the network. The text gateway transcodes 1579 the text stream into ToIP. 1581 Text gateway detection: pre-programmed in the mobile textphone 1582 client. 1584 9.10.8 Mobile telephone (UMTS) user calling an IP terminal 1586 No text gateway is required here since this will be end to end IP. 1588 9.10.9 Voice over DSL user using an analogue text telephone. 1590 Voice over DSL is a widespread service. When connecting analogue 1591 text telephones to this service there is a risk that they just use 1592 the voice channel that result in corrupted text transmission. The 1593 VoDSL gateway located in the network of the (A)DSL operator itself 1594 should connect with a text gateway as soon it turns into VoIP. 1596 Text gateway detection: prefix number similar to the PSTN. 1598 9.10.10 VoIP user via a building telephone switch (at an apartment 1599 building) owning an analogue text telephone. 1601 This is the case where only VoIP is possible and no other IP 1602 traffic between the telephone switch and the apartments. 1603 The only solution would be a forced analogue text telephone 1604 protocol over the Voice channel, in band text dialogue . If that 1605 must happen. Then the telephone switch MUST convert the analogue 1606 text telephone protocol into ToIP and vice versa before the 1607 telephone switch connects the IP network. 1608 Note: The in band text dialogue is undesirable. This scenario 1609 SHOULD be avoided at any cost. 1611 Text gateway detection: prefix number or in band text signalling. 1613 9.10.11 VoIP user via a gateway/box connected to his/her own 1614 Broadband connection owning an analogue text telephone. 1616 A. van Wijk [Page 29 of 37] 1617 draft-vanwijk-sipping-ToIP-00.txt July 2004 1619 The gateway box should natively transcode analogue text telephony 1620 into ToIP and vice versa when an analogue text phone is plugged in 1621 the RJ-11 socket [18]. 1623 Text gateway detection: RJ-11 socket preconfigured by the box via 1624 jumpers or software, or listen for textphone tones and perform 1625 V.18 text telephone detection. 1627 10. Terminal Features 1629 Implementers of products that support interactive Text-over-IP 1630 SHOULD NOT assume that all users of text are able to use 1631 mainstream input and output devices. People with arthritis or 1632 other dexterity problems might not be able to use very small 1633 keyboards. Visually impaired people might not be able to use 1634 standard sized characters on a display. Colour-blind people might 1635 suffer from badly chosen colour-schemes. People with motor 1636 disabilities might require specialised input devices. 1638 Implementers SHOULD make their products as open as possible with 1639 regard to this wide range of abilities and preferences and they 1640 MUST use standard interfaces wherever they provide such 1641 interfaces. 1643 10.1 Text input 1645 Systems that support real-time interactive Text-over-IP SHOULD 1646 support suitable input mechanisms, either built-in or connectable 1647 through the use of a standard interface: PS/2, USB, Bluetooth, or 1648 virtual keyboard. In particular Braille users should be able to 1649 connect Braille keyboards to the terminal. Terminals MAY support a 1650 web interface for input and output of text. 1652 It is recommended that systems that fixed terminals that support 1653 real-time interactive Text-over-IP allow the user to enter the 1654 standard alphanumerical characters directly, rather than through a 1655 cycle of key presses or other indirect means. This could be done 1656 using full-sized keyboards, smaller sized keyboards or fastap 1657 keyboards for example. It is highly recommended to provide a 1658 standard interface to allow attachment of an external input 1659 device, especially for terminals that have only limited input 1660 systems built-in. 1662 Systems should provide means to add voice-to-text translation as 1663 text input. 1665 All IP phones with a display of 12 or more characters MUST support 1666 at least text input through the regular phone keypad (and display 1667 of any incoming text) in order to provide basic emergency text 1668 communication from any IP phone. 1670 A. van Wijk [Page 30 of 37] 1671 draft-vanwijk-sipping-ToIP-00.txt July 2004 1673 Input devices that have automatic key repeat MUST allow the user 1674 to specify the key-repeat rate. 1676 10.2 Text presentation 1678 Systems that support real-time interactive Text-over-IP SHOULD 1679 support suitable displays, either built-in or connectable through 1680 the use of a standard interface: S-VGA, USB, Bluetooth or IP. 1681 Braille readers should be connectable to the terminal using a 1682 standard interface. 1684 Terminals MAY support a web interface for input and output of 1685 text. 1687 A variety of handsets and terminals might be developed for a 1688 number of equally varied scenarios. 1690 In the case of fixed terminals or software applications on 1691 Personal Computers, implementers MUST: 1693 a. Use either separate screen areas for displaying sent and 1694 received text OR clearly indicate the difference between sent and 1695 received text. Systems MAY allow the user to chose either on of 1696 these presentation methodologies. 1698 b. Provide at least 5 lines of 35 monospaced characters each for 1699 each direction (sent and received text) OR at least 10 lines of 35 1700 characters when sent and received text are presented together. 1702 In the case of Mobile terminals, implementers MUST: 1704 c. Use either separate screen areas for displaying sent and 1705 received text OR clearly indicate the difference between sent and 1706 received text. Systems MAY allow the user to chose either on of 1707 these presentation methodologies. 1709 d. Provide at least 3 lines of 20 monospaced characters each for 1710 each direction (sent and received text) OR at least 6 lines of 20 1711 characters when sent and received text are presented together. 1713 On both types of terminals, scrolling back through both sent and 1714 received text MUST be supported, even after the conversation has 1715 ended. Lines SHOULD be wrapped at word boundaries . 1717 There MUST be an easy-to-use function to clear the screen at any 1718 time during the session, and if the implementation has chosen to 1719 present sent and received text separately, clearing the screen 1720 SHOULD be possible as a separate function for sent and received 1721 text. 1723 The function of the new line and erasure controls as explained in 1724 section 9.5. MUST be supported by the presentation in the 1726 A. van Wijk [Page 31 of 37] 1727 draft-vanwijk-sipping-ToIP-00.txt July 2004 1729 consistent way described by T.140. Presentation layers MUST 1730 support the full UTF-8 character set. 1732 When real-time Text-over-IP is used in conjunction with other 1733 modalities, like voice, the presentation MUST clearly indicate 1734 this to the user in an area outside the display region for send 1735 and received text. 1737 Identification information for other parties in the conversation, 1738 like URL�s, user-friendly names from an address book, or CLI in 1739 the case of conversations with text telephones, SHOULD be 1740 displayed throughout the entire conversation in a region outside 1741 the sent and received text area. 1743 10.3 Call control 1745 Call (Session) Control procedures MUST use the SIP protocol. Text 1746 sessions MUST be identified in accordance with requirements 1747 described earlier. 1749 Text services SHOULD be part of a Total Conversation environment 1750 in which voice, text and video sessions can be added, modified or 1751 deleted individually. 1753 To enable interworking with Textphones in telephone and cellular 1754 (mobile) networks, terminals MUST be able to access Gateways 1755 automatically when a PSTN or cellular (mobile) E.164-based 1756 telephone number is used as the called address. 1758 Users MUST be able to establish text sessions to emergency service 1759 providers using the widely recognised emergency numbers in use in 1760 the country or region of operation of the terminal eg. �911� in 1761 USA and ?112?in Europe. 1763 The ability to transfer Location information SHALL be provided if 1764 the information is available from the terminal. 1766 10.4 Device control 1768 ToIP devices shall support multiple means of setting up and 1769 performing calls as well as controlling the device itself. The 1770 built-in controls and presentation systems shall take 1771 accessibility aspects into account as far as possible. The device 1772 shall include external interfaces that makes it possible to attach 1773 user interface devices for people with needs beyond what the 1774 built-in user interface can support. It is preferrable if such 1775 external interfaces are wireless. 1777 10.5 Alerting 1779 A. van Wijk [Page 32 of 37] 1780 draft-vanwijk-sipping-ToIP-00.txt July 2004 1782 The form of Alerting indication(s) provided to the user should be 1783 selectable to suit particular users. Alerting indications MAY 1784 include Sound, Tactile (eg. vibrational), Visual (on-screen 1785 symbols; separate flashing light), Motion (eg. movement of 1786 something). 1788 The ability to send an Alerting signal to an external interface 1789 SHOULD be provided. This will allow Alerting devices that are 1790 specific to users requirements to be attached. 1792 As many as possible of the following alternatives for alerting 1793 SHOULD be provided: 1794 * Internal flash. 1795 * Two-pole connector for external alerting systems triggered 1796 by contact between the two poles when a ring signal is generated 1797 (if necessary with 1.5-9 V battery power for alerting systems 1798 requiring electrical currents to activate). 1799 * Bluetooth serial profile with AT command interface, sending 1800 the "RING" message, intended for a Bluetooth alerting receiver 1801 with flash, vibration or sound action. 1802 * SIP connected alerting device, that get its stimuli by being 1803 registered on the same sip address as the terminal. 1805 10.6 External interfaces 1807 Terminals for ToIP SHOULD provide external interfaces for the 1808 following functions: 1809 * Text input. 1810 * Text display. 1811 * Terminal control. 1812 * Session control. 1814 10.7 Power 1816 As terminals could remain active for very long periods of time, 1817 the electrical power requirements of all the terminals SHOULD be 1818 as low as possible. 1820 If the terminal is to be used for calling Emergency services or 1821 where the mains power supply is unreliable, back-up power systems 1822 SHOULD be provided for the terminal and all equipment used to 1823 provide the ToIP service. This can be implemented in many 1824 different ways eg. via the line powering option on some Ethernet 1825 interfaces, or by using a �no break� power supply (a battery back- 1826 up system with inverters that can recreate a limited amount of 1827 mains power). 1829 11. Security Considerations 1831 There are no additional security requirements other than described 1832 earlier. 1834 12. Authors� Addresses 1836 A. van Wijk [Page 33 of 37] 1837 draft-vanwijk-sipping-ToIP-00.txt July 2004 1839 The following people provided substantial technical and writing 1840 contributions to this document, listed alphabetically: 1842 Barry Dingle 1843 ACIF, 32 Walker Street 1844 North Sydney, NSW 2060 Australia 1845 Tel +61 (0)2 9959 9111 1846 Fax +61 (0)2 9954 6136 1847 TTY +61 (0)2 9923 1911 1848 Mob +61 (0)41 911 7578 1849 email barry.dingle@bigfoot.com.au 1851 Guido Gybels 1852 RNID, 19-23 Featherstone Street 1853 London EC1Y 8SL, UK 1854 Tel +44(0)20 7294 3713 1855 Txt +44(0)20 7296 8019 1856 Fax +44(0)20 7296 8069 1857 EMail: guido.gybels@rnid.org.uk 1859 Gunnar Hellstrom 1860 Omnitor AB 1861 Renathvagen 2 1862 SE 121 37 Johanneshov 1863 Sweden 1864 Phone: +46 708 204 288 / +46 8 556 002 03 1865 Fax: +46 8 556 002 06 1866 Email: gunnar.hellstrom@omnitor.se 1868 Paul E. Jones 1869 Cisco Systems, Inc. 1870 7025 Kit Creek Rd. 1871 Research Triangle Park, NC 27709 1872 Phone: +1 919 392 6948 1873 E-mail: paulej@packetizer.com 1875 Radhika R. Roy 1876 AT&T 1877 Room C1-2B03 1878 200 Laurel Avenue S. 1879 Middletown, NJ 07748 1880 USA 1881 Phone: +1 732 420 1580 1882 Fax: +1 732 368 1302 1883 Email: rrroy@att.com 1885 Henry Sinnreich 1886 MCI 1887 400 International Parkway 1888 Richardson, Texas 75081 1889 Email: henry.sinnreich@mci.com 1891 A. van Wijk [Page 34 of 37] 1892 draft-vanwijk-sipping-ToIP-00.txt July 2004 1894 Gregg C Vanderheiden 1895 University of Wisconsin-Madison 1896 Trace R & D Center 1897 1550 Engineering Dr (Rm 2107) 1898 Madison, Wi 53706 1899 USA 1900 gv@trace.wisc.edu 1901 Phone +1 608 262-6966 1902 FAX +1 608 262-8848 1904 Arnoud A. T. van Wijk 1905 Viataal (Dutch Institute for the Deaf) 1906 Research & Development 1907 Afdeling RDS 1908 Theerestraat 42 1909 5271 GD Sint-Michielsgestel 1910 The Netherlands. 1911 Email: a.vwijk@viataal.nl 1913 13. Acknowledgements 1915 The authors wish to thank Snowshore for providing the ToIP mailing 1916 list, which allows many discussions necessary for this draft. 1918 14. Full Copyright Statement 1920 Copyright (C) The Internet Society (2004). This document is 1921 subject to the rights, licenses and restrictions contained in BCP 1922 78, and except as set forth therein, the authors retain all their 1923 rights. 1924 This document and the information contained herein are provided on 1925 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1926 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1927 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1928 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1929 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1930 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1931 PARTICULAR PURPOSE. 1933 15. References 1935 15.1 Normative 1937 1. Bradner, S., "The Internet Standards Process -- Revision 3", 1938 BCP 9, RFC 2026, October 1996. 1940 2. Bradner, S., "Key words for use in RFCs to Indicate Requirement 1941 Levels", BCP 14, RFC 2119, March 1997 1943 3. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 1944 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session 1945 Initiation Protocol, RFC 3621, IETF, June 2002. 1947 A. van Wijk [Page 35 of 37] 1948 draft-vanwijk-sipping-ToIP-00.txt July 2004 1950 4. ITU-T Recommendation T.140, "Protocol for Multimedia 1951 Application Text Conversation (February 1998) and Addendum 1 1952 (February 2000). 1954 5. G. Hellstr?m, "RTP Payload for Text Conversation, RFC 2793, May 1955 2000. 1957 6. G. Camarillo, H. Schulzrinne, and E. Burger, "The Source and 1958 Sink Attributes for the Session Description Protocol," IETF, 1959 August 2003 - Work in Progress. 1961 7. G.Camarillo, "Framework for Transcoding with the Session 1962 Initiation Protocol" IETF august 2003 - Work in progress. 1964 8. G. Camarillo, H. Schulzrinne, E. Burger, and A. Wijk, 1965 "Transcoding Service Invocation in SIP using Third Party Call 1966 Control," IETF, August 2003 - Work in Progress. 1968 9. G. Camarillo, "The SIP Conference Bridge Transcoding Model," 1969 IETF, August 2003 - Work in Progress. 1971 10. ITU-T Recommendation V.18,"Operational and Interworking 1972 Requirements for DCEs operating in Text Telephone Mode," November 1973 2000. 1975 11. "XHTML 1.0: The Extensible HyperText Markup Language: A 1976 Reformulation of HTML 4 in XML 1.0", W3C Recommendation. Available 1977 at http://www.w3.org/TR/xhtml1. 1979 12. Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1980 RFC 2279, January 1998. 1982 13. TIA/EIA/825 "A Frequency Shift Keyed Modem for Use on the 1983 Public Switched Telephone Network." (The specification for 45.45 1984 and 50 bit/s TTY modems.) 1986 14. Bell-103 300 bit/s modem. 1988 15. TIA/EIA/IS-823-A "TTY/TDD Extension to TIA/EIA-136-410 1989 Enhanced Full Rate Speech Codec (must used in conjunction with 1990 TIA/EIA/IS-840)" 1992 16. TIA/EIA/IS-127-2 "Enhanced Variable Rate Codec, Speech Service 1993 Option 3 for Wideband Spread Spectrum Digital Systems. Addendum 1994 2." 1996 17. 3GPP TS26.226 "Cellular Text Telephone Modem Description" 1997 (CTM). 1999 18. I. Butcher, S. Lass, D. Petrie, H. Sinnreich, and C. 2000 Stredicke, "SIP Telephony Device Requirements, Configuration and 2001 Data," IETF, February 2004- Work in Progress. 2003 A. van Wijk [Page 36 of 37] 2004 draft-vanwijk-sipping-ToIP-00.txt July 2004 2006 19 Baugher, McGrew, Carrara, Naslund, Norrman, "The Secure Real- 2007 Time Transport Protocol (SRTP)", RFC 3711, March 2004. 2009 20. IP Multimedia default codecs. 3GPP TS 26.235 2011 15.2 Informative 2013 I. A relay service allows the users to transcode between different 2014 modalities or languages. In the context of this document, relay 2015 services will often refer to text relays that transcode text into 2016 voice and vice-versa. See for example http://www.typetalk.org. 2018 II. International Telecommunication Union (ITU), "300 bits per 2019 second duplex modem standardized for use in the general switched 2020 telephone network". ITU-T Recommendation V.21, November 1988. 2022 III. International Telecommunication Union (ITU), "600/1200-baud 2023 modem standardized for use in the general switched telephone 2024 network. ITU-T Recommendation V.23, November 1988. 2026 IV. Third Generation Partnership Project (3GPP), "Technical 2027 Specification Group Services and System Aspects; Cellular Text 2028 Telephone Modem; General Description (Release 5)". 3GPP TS 26.226 2029 V5.0.0, 2031 A. van Wijk [Page 37 of 37]