SIPPING Workgroup Internet Draft A. van Wijk
(editor) Internet-Draft ViataalCategory: Informational AnnieS Expires: September 5 2006 March 66, 2006 September 7 2005Framework of requirementsfor real-time text conversationover IP using SIP draft-ietf-sipping-toip-03.txtdraft-ietf-sipping-toip-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79 .79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 6,September 5, 2006. Copyright Notice Copyright (C) The Internet Society (2005).(2006). Abstract This document provides thea framework of requirementsfor real-time character-by-character interactivethe implementation of real- time text conversation over the IP network using the Session Initiation Protocol and the Real-Time Transport Protocol. It discusseslists the essential requirements for real-time Text- over-IP as well asText-over-IP (ToIP) and defines a framework for implementation of all required functions based on existing protocols and techniques. This includes interworking between Text-over-IP and existing text telephony on the PSTN and other networks. A. van Wijk, et al. Expires 6 March 2006 [Page 1 of 28]Table of Contents 1. Introduction.....................................................3Introduction...................................................3 2. Scope............................................................4Scope..........................................................4 3. Terminology......................................................4Terminology....................................................4 4. Definitions......................................................4Definitions....................................................4 5. Framework Description............................................6 5.1.Requirements...................................................6 5.1 General requirements for ToIP..................................6 5.1.1 General ToIP Summary..........................................8 5.2. General RequirementsToIP..............................6 5.2 Detailed requirements for ToIP Interworking.....................8ToIP.............................8 5.2.1 PSTN Interworking.............................................9Session control and set-up requirements...............8 5.2.2 Cellular circuit switched Text-Telephony.....................10 184.108.40.206 Cellular "No-gain".........................................10 220.127.116.11 Cellular Text Telephone Modem (CTM)........................10 18.104.22.168 Cellular "Baudot mode".....................................11Transport requirements................................9 5.2.3 Cellular data channel mode...................................11Transcoding service requirements.....................10 5.2.4 Cellular Wireless ToIP.......................................11Presentation and User control requirements...........11 5.2.5 Interworking requirements............................12 22.214.171.124 PSTN Interworking requirements..................12 126.96.36.199 Cellular Interworking requirements..............12 188.8.131.52 Instant Messaging Support....................................11Interworking requirements.....13 6. Detailed requirements for ToIP..................................11 6.1. Pre-Session Requirements......................................12Implementation Framework......................................13 6.1 Framework of general implementation.......................13 6.2 Framework of detailed implementation......................14 6.2.1 Session control and set-up...........................14 184.108.40.206 Pre-session setup...............................14 220.127.116.11 Basic Point-to-Point Session Requirements......................12 6.2.1setup..............15 18.104.22.168 Addressing......................................15 22.214.171.124 Session control..............................................12Negotiations............................15 126.96.36.199 Additional session control......................16 6.2.2 Text transport...............................................12Transport............................................16 6.2.3 Session Setup................................................13Transcoding services.................................17 6.2.4 Addressing...................................................13 6.2.5 Alerting.....................................................14 6.2.6 Session information..........................................14 6.2.7 Session progress information.................................14 6.2.8 Session Negotiations.........................................15 6.2.9 Answering....................................................15 188.8.131.52 Answering Machine..........................................15 6.2.10 Actions During a Session....................................15 184.108.40.206 Text Transport............................................16 220.127.116.11 Handling Text and other Media.............................16 6.2.11 Additional session control..................................17 6.2.12 File storage................................................17 6.3 Conference Session Requirements................................17 6.4 Real-time EditingPresentation and User Alerting............................17 6.5 Emergency services.............................................17 6.6 User Mobility..................................................18 6.7 Firewallscontrol functions..............18 18.104.22.168 Progress and NATs.............................................18 7. Interworking Requirements for ToIP..............................18 7.1 ToIPstatus information.................18 22.214.171.124 Alerting........................................18 126.96.36.199 Answering Machine...............................18 188.8.131.52 Text presentation...............................19 184.108.40.206 File storage....................................19 6.2.5 Interworking Gateway Services.............................18 7.2 ToIP and PSTN/ISDN Text-Telephony Interworking.................18 7.3 ToIP andfunctions...............................19 220.127.116.11 PSTN Interworking...............................20 18.104.22.168 Mobile Interworking.............................21 22.214.171.124.1 Cellular Wireless ToIP................................19 7.4"No-gain".........................21 126.96.36.199.2 Cellular Text Telephone Modem (CTM)........21 188.8.131.52.3 Cellular "Baudot mode".....................22 184.108.40.206.4 Mobile data channel mode...................22 220.127.116.11.5 Mobile ToIP................................22 18.104.22.168 Instant Messaging Support......................................19 7.5 Common Text Gateway Functions..................................20 7.5.1 Protocol support.............................................20 7.5.2 Relay buffer storage.........................................20 7.5.3 Emergency callsInterworking..................22 22.214.171.124 Interworking through gateways.............................21 7.5.4 Text Gateway Invocation......................................21 7.6gateways...................23 126.96.36.199 Multi-functional Combination gateways...........24 188.8.131.52 Character set transcoding.......................25 7. Further recommendations for implementers and service providers25 7.1 Access to Emergency services..............................25 7.2 Home Gateways or Analog Terminal Adapters......................21 7.7 Multi-functional Combination gateways..........................22 A. van Wijk, et al. Expires 6 March 2006 [Page 2 of 28] 7.8 Transcoding....................................................22 7.9 Relay Services.................................................23 7.9.1 Basic function of the relay service..........................23 7.9.2 Invocation of relay services.................................23Adapters.................26 7.3 User Mobility.............................................26 7.4 Firewalls and NATs........................................26 8. Security Considerations.........................................23IANA Considerations...........................................26 9. Authors Addresses...............................................24Security Considerations.......................................26 10. References.....................................................25 10.1Authors’ Addresses...........................................27 11. References...................................................28 11.1 Normative references..........................................25 10.2references.....................................28 11.2 Informative references........................................27references...................................30 1. Introduction For many years, text has been in use as a medium for conversational, interactive dialogue between users in a similar way to how voice telephony is used. Such interactive text is different from messaging and semi-interactive solutions like Instant Messaging in that it offers an equivalent conversational experience to users who cannot, or do not wish to, use voice. It therefore meets a different set of requirements from other text- basedtext-based solutions already available on IP networks. Traditionally, deaf, hard of hearing and speech-impaired people are amongst the most prolific users of conversational, interactive text but, because of its interactivity, it is becoming popular amongst mainstream users as well. This document describes how existing IETF protocols can be used to implement a Text-over-IP solution (ToIP). This ToIP framework is specifically designed to be compatible with Voice-over-IP (VoIP) and Multimedia-over-IP (MoIP) environments, as well as meeting the userÆsuser’s requirements, including those of deaf, hard of hearing and speech-impairedspeech- impaired users as described in RFC3351 . and mainstream users. The Session Initiation Protocol (SIP)  is the protocol of choice for control of Multimedia communications and Voice-over-IP (VoIP) in particular. It offers all the necessary control and signaling required for the ToIP framework. The Real-Time Transport Protocol (RTP)  is the protocol of choice for real-time data transmission, and its use for interactivereal-time text payloads is described in RFC4103 . This document defines a framework for ToIP to be used either by itself or as part of integrated, multi-media services, including Total Conversation. A. van Wijk, et al. Expires 6 March 2006 [Page 3 of 28]Conversation . 2. Scope This document defines a framework for the implementation of real- timereal-time ToIP, either stand-alone or as a part of multimedia services, including Total Conversation.Conversation . It defines the: a. Requirements of Real-time, interactiveReal-time text; b. Requirements for ToIP interworking; c. Description of ToIP implementation using SIP and RTP; d. Description of ToIP interworking with other text services. 3. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119  and indicate requirement levels for compliant implementations. 4. Definitions Audio bridging -bridging: a function of aan audio media bridge server, gateway or relay service that enablesbridges audio into a single source through combining audio from multiple users excluding each destination source’s audio and sends to each respective destination enabling an audio path through the service between the users involved in the call. Cellular - Telephone systems based on radio transmission to become wireless.Cellular: a telecommunication network that has wireless access and can support voice and data services over very large geographical areas. Also called Wireless or Mobile systems.Mobile. Full duplex -duplex: media is sent independently in both directions. Half duplex -duplex: media can only be sent in one direction at a time or, if an attempt to send information in both directions is made, errors can be introduced into the presented media. Interactive text: a term for real time transmission of text -in a character-by-character fashion for use in conversational services, often as a text equivalent to voice based conversational services. (Equivalent to real-time text.) Real-time text: a term for real time transmission of text in a character-by-character fashion for use in conversational services, often as a text equivalent to voice based conversational services. Textphone ûConversational text is defined in ITU-T F.700 Framework for multimedia services . Text gateway: a function that transcodes between different forms of real-time text transport methods, e.g., between ToIP in IP networks and Baudot or ITU-T V.21 text telephony in the PSTN. Textphone: also "text telephone". A terminal device that allows end-to-endend- to-end real-time, interactive text communication using analog transmission. A variety of PSTN textphone protocols exists world- wide. A textphone can often be combined with a voice telephone, or include voice communication functions for simultaneous or alternating use of text and voice in a call. Text bridging -bridging: a function of a gateway service that enables the flow of text through the service between the users involved in the call. Text gateway - a function that transcodes between different forms of text transport methods, e.g., between ToIP in IP networks and Baudot or ITU-T V.21 text telephony in the PSTN. A. van Wijk, et al. Expires 6 March 2006 [Page 4 of 28] TextRelay Service -Service: a third-party or intermediary that enables communications between deaf, hard of hearing and speech-impaired people, and voice telephone users by translating between voice and real-time text in a call. Text telephony ûBridging: a function of the text media bridge server, gateway or relay service that bridges real-time text into a single source through combining real-time text from multiple users excluding each destination source’s real-time text and sends to each respective destination enabling a real-time text path through the service between the users involved in the call. Text telephony: analog textphone service. Total Conversation -Conversation: a multimedia service offering real time conversation in video, real-time text and voice according to interoperable standards. All media flow in real time. (See ITU-T F.703 "Multimedia conversational services".)services" .) Transcoding Services -Services: services of a third-party user agent that transcodes one stream into another. Transcoding can be done by human operators, in an automated manner or a combination of both methods. Text Relay Services are examples of a transcoding service between real-time text and audio. TTY ûTTY: alternative designation for a text telephone or textphone, often used in USA. Also called TDD, Telecommunication Device for the Deaf. Video Relay Service -Service: A service that enables communications between deaf and hard of hearing people, and hearing persons with voice telephones by translating between sign language and spoken language in a call. Acronyms: 2G Second generation cellular (mobile) 2.5G Enhanced second generation cellular (mobile) 3G Third generation cellular (mobile) CDMA Code Division Multiple Access CLI Calling Line Identification CTM Cellular Text Telephone Modem ENUM E.164 number storage in DNS (see RFC3761) GSM Global System of Mobile Communication ISDN Integrated Services Digital Network ITU-T International Telecommunications Union-Telecommunications Standardisation Sector NAT Network Address Translation PSTN Public Switched Telephone Network RTP Real Time Transport Protocol SDP Session Description Protocol SIP Session Initiation Protocol SRTP Secure Real Time Transport Protocol TDD Telecommunication Device for the Deaf TDMA Time Division Multiple Access TTY Analog textphone (Teletypewriter) ToIP Real-time Text over Internet Protocol UTF-8 Universal Transfer Format-8 VCO/HCO Voice Carry Over/Hearing Carry Over VoIP Voice over Internet Protocol A. van Wijk, et al. Expires 6 March 2006 [Page 5 of 28]5. Framework DescriptionRequirements This framework defines the requirements ofa text-based conversational service that is the text equivalent of voice based telephony. This section describes the requirements that the framework is designed to meet and the functionality it should offer. Real-time text conversation can be combined with other conversational services like video or voice. ToIP also offers an IP equivalent of analog text telephony services as used by deaf, hard of hearinghearing, speech-impaired and mainstream users. This section (Requirements) informs implementers about WHICH requirements the systems and services shall meet. The next section (Section 6 Framework Implementation) describes HOW to do it. 5.1 General requirements for ToIP Any framework for ToIP must be designed to meet the requirements of RFC3351 . A basic requirement is that it must provide a standardized way for offering text-based, conversational services that can be used as an equivalent to voice telephony by deaf, hard of hearing speech-impaired individuals.and mainstream users. It is important to understand that real-time text conversations are significantly different from other text-based communications like email or instant messaging.Instant Messaging. Real-time text conversations deliver an equivalent mode to voice conversations by providing transmission of text character by character as it is entered, so that the conversation can be followed closely and immediate interaction takestake place. This provides the same mode of interaction as voice telephony does for hearing people.Store-and-forward systems like email or messaging on mobile networks or non-streaming systems like instant messaging are unable to provide that functionality. In particular, they do not allow for smooth communication through a Text Relay Service. This framework uses existing standards that are already commonly used for voice based conversational services on IP networks. It uses the Session Initiation Protocol (SIP) to set up, control and tear down the connections between users whilst the media is transported using the Real-Time Transport Protocol (RTP) as described in RFC4103 . This framework is designed to meet the requirements of RFC3351 . As such, it offers a standardized way for offering text- based, conversational services that can be used as an equivalent to voice telephony by deaf, hard of hearing and speech-impaired individuals. SIP allows participants to negotiate all media including real-time text conversation [4,5]. This is a highly desirable function for all IP telephony users but essential for deaf, hard of hearing, or speech impaired people who have limited or no use of the audio path of the call. 5.1. General requirements for ToIPIn order to make ToIP the text equivalent of voice services, it needs to offer equivalent features in terms of conversationality as voice telephony provides. To achieve that, ToIP needs to: a. Offer real-time transport and presentation of the conversation; b. Provide simultaneous transmission in both directions; c. Support both point-to-point and multipoint communication; A. van Wijk, et al. Expires 6 March 2006 [Page 6 of 28]d. Allow other media, like audio and video, to be used in conjunction with ToIP; e. Ensure that the real-time text service is always available. Real-time text is a useful subset of Total Conversation defined in ITU-T F.703 .. Users could use multiple modes of communication during the conversation, either at the same time or by switching between modes, e.g., between real-time text and audio. UsersDeaf, hard-of-hearing and mainstream users may invoke ToIP services for many different reasons: - Because they are in a noisy environment, e.g., in a machine room of a factory where listening is difficult. - Because they are busy with another call and want to participate in two calls at the same time. - For implementing text and/or speech recording services (e.g., text documentation/ audio recording for legal/clarity/flexibility purposes). - To overcome language barriers through speech translation and/or transcoding services. - Because of hearing loss, deafness or tinnitus as a result of the aging process or for any other reason, thus creating a need to replace or complement voice with real-time text in conversational sessions. NOTE:In many of the above examples, text may accompany speech. The text could be displayed side by side, or in a manner similar to subtitling in broadcasting environments, or in any other suitable manner. This could occur forwith users who are hard of hearing and also for mixed media calls with both hearing and deaf people participating in the call. User Agents providingA ToIP functionality needuser may wish to provide suitable alerting indications, specifically offering visual and/or tactile alertingcall another ToIP user, or join a conference session involving several users or initiate or join a multimedia session, such as a Total Conversation session. 5.2 Detailed requirements for deaf and hard of hearing users.ToIP The ability of SIPfollowing sections lists individual requirements for ToIP. Each requirement has been given a uniquely identifier (R1, R2, etc). Section 6 (Implementation Framework) describes how to implement ToIP based on these requirements and using existing protocols and techniques. 5.2.1 Session control and set-up requirements Users will set up conversation sessions from any location, as well as its privacy and security provisions, MUST be maintaineda session by ToIP services. Where ToIPidentifying the remote party or the service they want to connect to. However, conversations could be started using a mode other than the real-time text. Simultaneous or alternating use of voice and real-time text is used in conjunction with other media, exposureby a large number of SIP functions through the User Interface needsusers who can send voice but must receive text (due to a hearing impairment), or who can hear but must send text (due to a speech impairment). R1: It SHOULD be donepossible to start conversations in an equivalent manner for all supported media. In other words, where certain SIP call control functions are available for the audio media partany mode (real- time text, voice, video) or combination of the session, these functionsmodes. R2: It MUST alsobe supportedpossible for the users to switch to real-time text, or add real-time text media part ofas an additional modality, during the same session. For example, call transfer must act on all media inconversation. R3: Systems supporting ToIP MUST allow users to select any of the session. T.140 real-time textsupported conversation , in additionmodes at any time, including mid-conversation. R4: Systems SHOULD allow the user to audio and video communications, isspecify a valuable service for many users, including those on non-IP networks. T.140 also provides for real- time editingpreferred mode of communication, with the text. A. van Wijk, et al. Expires 6 March 2006 [Page 7ability to fall back to alternatives that the user has indicated are acceptable. R5: If the user requests simultaneous use of 28] 5.1.1 General ToIP Summary The general requirements for ToIP are: a. Session setup, modification and teardown procedures for point- to-pointreal-time text and multimedia calls b. Registration proceduresaudio, and address resolutions c. Registrationthis is not possible either because the system only supports alternate modalities or because of constraints in the network, the system MUST try to establish communication with best effort. R6: If the user preferences d. Negotiation procedureshas expressed a preference for device capabilities e. Supportreal-time text, establishment of a connection including real-time text media transport using T.140MUST have priority over RTP as described in RFC 4103  f. Signalingother outcomes of status information, call progress andthe like in a suitable manner, bearing in mind thatsession setup. R7: It SHOULD be possible to use the user may have a hearing impairment g. T.140 real-time text presentation mixing with voice and video h. T.140real-time text conversationmedium in conference sessions using SIP, allowing users to move from one placein a similar way to another i. User privacy and security for sessions setup, modification,how audio is handled and teardown as well asvideo is displayed. Real-time text in conferences can be used both for media transfer j. Routing of emergency calls accordingletting individual participants use the text medium (for example, for sidebar discussions in text while listening to national or regional policy withthe same level of functionalitymain conference audio), as well as a voice call. 5.2. General Requirementsfor ToIP Interworking This section describes the general ToIP interworking requirements and gives some background information to manycentral support of the issues. There is a range of existing text services. There is also a range of network technologies that could support text services (see examples below). ToIP needs to provide interoperabilityconference with real time text conversation features in other networks,interpretation of speech. R8: During session set up, it SHOULD be possible for instancethe PSTN,users to indicate if the caller wants to use voice and with somereal-time text messaging services. Text gateways are used for converting between different media types. They could be used between networks or within networks where different transport technologies are used. When communicating via a gateway to other networkssimutaneously as part of the conversation. R9: Session set up and protocols,negotiation of modalities must allow users to specify the ToIP service SHOULD supportlanguage of the real-time text to be used. (It is recommended that similar functionality is provided for alternating or simultaneous use of modalities as offered bythe destination network. A. van Wijk, et al. Expires 6 March 2006 [Page 8video part of 28] Address information, both called and calling, SHOULD be transferred, and possibly converted, when interworking between different networks.the conversation, i.e. to specify the sign language being used). 5.2.2 Transport requirements ToIP will often be used to access a relay service [I], allowing real- time text users to communicate with voice users. With relay services, it is crucial that text characters are sent as soon as possible after they are entered. While buffering may be done to improve efficiency, the delays SHOULD be kept minimal. In particular, buffering of whole lines of text will not meet character delay requirements. If the User AgentsR10: Characters must be transmitted soon after entry of different participants indicateeach character so that the maximum delay requirement can be met. A delay time of one second is regarded good, while a delay of two seconds is possible to use. R11: It must be possible to transmit characters at a rate sufficient to support fast human typing as well as speech to text methods of generating conversation text. A rate of 20 characters per second is regarded sufficient. R12: a ToIP service must be able to deal with international character sets. R13: Where it is possible, loss of real-time text during transport should be detected and the user should be informed. R14: Transport of real-time text should be as robust as possible, so as to minimize loss of characters. R15: Where possible, it must be possible to send and receive real- time text simultaneously. 5.2.3 Transcoding service requirements If the User Agents of different participants indicate that there is an incompatibility between their capabilities to support certain media types, e.g. one terminal only offering T.140 over IP as described in RFC4103  and the other one only supporting audio, the user might want to invoke a transcoding service. ExamplesSome users may indicate their preferred modality to be audio while others may indicate real-time text. In this case, transcoding services might be needed for text-to-speech (TTS) and speech-to-text (STT). Other examples of possible scenarios for including a relay service in the conversation are: speech-to-text (STT), text-to-speech (TTS),text bridging after conversion from speech, audio bridging after conversion from real-time text, etc. The general requirements for ToIP Interworking are: a. Interoperability between T.140 conversations  and analog text telephones b. DiscoveryA number of requirements, motivations and implementation guidelines for relay service invocation of transcoding/translation services between the mediacan be found in the call c. Different session establishment modelsRFC 3351 . R16: It MUST be possible for users to invoke a transcoding service where such service is available. R17: It MUST be possible for users to indicate their preferred modality. R18: The requirements for transcoding / translationservices invocation: Third party call control and conference bridge model d. Uniqueness in media mappingneed to be usednegotiated in the session for conversion from one mediareal-time to another by the transcoding / translation server for each communicating party e. Media bridging services for T.140 real-time text, as described in RFC4103 , audio and videoset up the session. R19: Adding or removing a relay service MUST be possible without disrupting the current session. R20: When setting up a session, it MUST be possible for multipoint communications f. Transparent session setup, modification, and teardown between text conversation capable devices and voice/video capable devices g. Bufferinga user to determine the type of relay service requested (e.g., speech to text when interworking with media that transport text at different rates. 5.2.1 PSTN Interworking Analogor text telephony is cumbersome because of incompatible national implementations where interworking was never considered. A. van Wijk, et al. Expires 6 March 2006 [Page 9to speech). The specification of 28] A large numbera type of these implementations have been documented in ITU-T V.18 , which also definesrelay MUST include a language specifier. R21: It SHOULD be possible to route the modem detection sequences forsession to a preferred relay service even if the different text protocols. The modem type identification may in rare cases take considerable time depending onuser actions. To resolve analog textphone incompatibilities, text telephone gateways are needed to transcodeinvokes the session from another region or network than that usually used. 5.2.4 Presentation and User control requirements R22: User Agents for ToIP services must have alerting methods (e.g., for incoming analog signals into T.140sessions) that can be used by deaf and vice versa. The modem capability exchange timehard of hearing people or provide a range of alternative, but equivalent, alerting methods that can be reducedselected by theall users, regardless of their abilities. R23: Where real-time text telephone gateways initially assuming the analog text telephone protocolis used in conjunction with other media, exposure of user control functions through the regionUser Interface needs to be done in an equivalent manner for all supported media. In other words, where certain call control functions are available for the gateway is located.audio media part of a session, these functions MUST also be supported for the real-time text media part of the same session. For example, call transfer must act on all media in the USA, Baudot [III] might be tried as the initial protocol.session. R24: If negotiation for Baudot fails,present, identification of the full V.18 modem capability exchange will take place. Inoriginating party (for example in the UK, ITU-T V.21 [II] mightform of a URL or a CLI) MUST be clearly presented to the first choice. 5.2.2 Cellular circuit switched Text-Telephony Cellular wireless (or Mobile) circuit switched connections provideuser in a digital real-time transport serviceform suitable for voice or data. The access technologies include GSM, CDMA, TDMA, iDen and various 3G technologies. Alternative means of transferring the Text telephony data have been developed when TTY services over cellular was mandated bythe FCC inuser BEFORE the USA. They are a) "No-gain" codec solution, b)session invitation is answered. R25: When a session invitation involving ToIP originates from a PSTN text telephone (e.g. transcoded via a text gateway), this SHOULD be indicated to the Cellular Text Telephony Modem (CTM) solution and c) "Baudot mode" solution.user. The GSM and 3G standards from 3GPP make use ofToIP client MAY adjust the CTM modem inpresentation of the voice channel forreal-time text telephony. However, implementations also exist that useto the data channeluser as a consequence. R26: An indication should be given to provide such functionality. Interworkingthe user when real-time text is available during the call, even if it is not invoked at call setup (e.g. when only voice and/or video is used initially). R27: The user MUST be informed of any change in modalities. R28: Users must be presented with these solutionsappropriate session progress information at all times. R29: Answering machine functions SHOULD be done using text gateways that set upprovided by the data channel connection atUser Agent. R30: When the GSM sideanswering machine function is enabled on the User Agent, alerting of the user SHOULD still be possible and provide ToIPusers SHOULD be able to take over control from the answering machine function at any time. R31: Users SHOULD be able to save the other side. 184.108.40.206 Cellular "No-gain" The "No-gain"text telephone transporting technology uses specially modified EFR  and EVR  speech vocodersportion of a conversation. R32: The presentation of the conversation should be done in mobile terminals used to providesuch a text telephony call. It provides full duplex operation and supports alternating voice and text ("VCO/HCO"). Itway that users can easily identify which party generated any given portion of text. 5.2.5 Interworking requirements There is dedicated to CDMA and TDMA mobile technologies and the US Baudot (i.e. 45 bit/s) typea range of existing real-time text telephones. 220.127.116.11 Cellular Text Telephone Modem (CTM) CTM services. There is also a technology independent modem technology that provides the transportrange of text telephone characters at up to 10 characters/sec using modem signalsnetwork technologies that can be carried by many voice codecscould support real-time text services. Real-time/Interactive texting facilities exist already in various forms and uses a highly redundant encoding technique to overcomeon various networks. On the fading and cell changing losses. A. van Wijk, et al. Expires 6 March 2006 [Page 10 of 28] 18.104.22.168 Cellular "Baudot mode" This termPSTN, it is oftencommonly referred to as text telephony. Text gateways are used by cellular terminal suppliersfor converting between different media types. They could be used between networks or within networks where different transport technologies are used. R33: ToIP SHOULD provide interoperability with text conversation features in other networks, for instance the PSTN. R34: When communicating via a GSM cellular phone mode that allows TTYsgateway to operate into a cellular phoneother networks and to communicate with a fixed line TTY. 5.2.3 Cellular data channel mode Many mobile terminals allowprotocols, the use ofToIP service SHOULD support the data channel to transfer data in real-time. Data ratesfunctionality for alternating or simultaneous use of 9600 bit/s are usually supported onmodalities as offered by the mobileinterworking network. Gateways provide interoperability with PSTN textphones. 5.2.4 Cellular Wireless ToIP ToIP couldR35: Address information, both called and calling, SHOULD be supported over cellular wireless packet switched services that interface to the Internet. For 3GPP 3Gtransferred, and possibly converted, when interworking between different networks. R36: When interworking with other networks and services, the support is described to useToIP in 3G TS 26.235 . Low data rates and additionalservice SHOULD provide buffering mechanisms to deal with delays can affect performance. 5.2.5 Instant Messaging Support Many people use Instant Messagingin call setup, transmission speeds and/or to communicate via the Internet using text. Instant Messaging transfers blocks ofinterwork with half duplex services. 22.214.171.124 PSTN Interworking requirements Analog text rather than streamingtelephony is being used in many countries, mainly by deaf, hard of hearing and speech-impaired individuals. R37: ToIP services MUST provide interworking with PSTN legacy text telephony devices. R38: When interworking with PSTN legacy text telephony services, alternating text and voice function MAY be supported. (Called "voice carry over (VCO) and hearing carry over (HCO)"). 126.96.36.199 Cellular Interworking requirements As mobile communications have been adopted widely, various solutions for real-time texting while on the move have been developed. ToIP services should provide interworking with such services as well. Alternative means of transferring the Text telephony data have been developed when TTY services over cellular was mandated by the FCC in the USA. They are a) "No-gain" codec solution, b) the Cellular Text Telephony Modem (CTM) solution  and c) "Baudot mode" solution. The GSM and 3G standards from 3GPP make use of the CTM modem in the voice channel for text telephony. However, implementations also exist that use the data channel to provide such functionality. Interworking with these solutions SHOULD be done using text gateways that set up the data channel connection at the GSM side and provide ToIP at the other side. R39: a ToIP service SHOULD provide interworking with mobile text conversation services. 188.8.131.52 Instant Messaging Interworking requirements Many people use Instant Messaging to communicate via the Internet using text. Instant Messaging usually transfers blocks of text rather than streaming as is used by ToIP. Usually a specific action is required by the user to activate transmission, such as pressing the ENTER key or a send button. As such, it is not a replacement for ToIP and in particular does not meet the needs for real time conversations including those of deaf, hard of hearing and speech- impairedspeech-impaired users as defined in RFC 3351 .. It is unsuitable for communications through a relay service [I]. The streaming nature of ToIP provides a more direct conversational user experience and, when given the choice, users may prefer ToIP. Text gateways could be developed to allowR39: a ToIP service MAY provide interworking betweenwith Instant Messaging systems and ToIP solutions.services. 6. Detailed requirementsImplementation Framework This section describes an implementation framework for ToIP Athat meets the requirements and offers the functionality as set out in section 5. The framework presented here uses existing standards that are already commonly used for voice based conversational services on IP networks. 6.1 Framework of general implementation ToIP user may wishuses the Session Initiation Protocol (SIP)  to call another ToIP user, or join a conference session involving severalset up, control and tear down the connections between users or initiate or join a multimedia session, suchwhilst the media is transported using the Real-Time Transport Protocol (RTP)  as described in RFC4103 . SIP  allows participants to negotiate all media including real- time text conversation . This is a Total Conversation session. There may be some needhighly desirable function for pre-session setup e.g. storingall IP telephony users but essential for deaf, hard of hearing, or speech impaired people who have limited or no use of the audio path of registration information inthe call. Even for mainstream users, media negotiations like real- time text are also very useful in many circumstances as described earlier. The ability of SIP registrar, to provide information about how a user can be contacted. This will allow sessionsto beset up rapidly and with proper routingconversation sessions from any location, as well as its privacy and addressing. Similarly, there are requirements that need tosecurity provisions, MUST be satisfied during session set up when other media are preferredmaintained by a user. For instance, some users may indicate their preferred modalityToIP services. Real-time text conversation based on the presentation protocol T.140 , in addition to beaudio while others may indicateand video communications, is a valuable service for many users, including those on non-IP networks. T.140 also provides for basic real-time editing of the text. In this case, transcoding6.2 Framework of detailed implementation 6.2.1 Session control and set-up ToIP services might be neededMUST use the Session Initiation Protocol (SIP)  for text-to-speech (TTS)setting up, controlling and speech-to- A. van Wijk, et al. Expires 6 March 2006 [Page 11 of 28]terminating sessions for real-time text (STT).conversation with one or more participants and possibly including other media like video or audio. The session description protocol (SDP) used in SIP to describe the session is used to express the attributes of the session and to negotiate a set of compatible media types. 184.108.40.206 Pre-session setup The requirements for transcoding services needof the user to be negotiatedreached at a consistent address and to store preferences for evaluation at session setup are met by pre-session setup actions. That includes storing of registration information in real-timethe SIP registrar, to provide information about how a user can be contacted. This will allow sessions to be set up the session. The subsequent subsections describe some of these requirements in detail. 6.1. Pre-Session Requirementsrapidly and with proper routing and addressing. The need to use real-time text as a medium of communications can be expressed by users during registration time. Two situations need to be considered in the pre-session setup environment: a. User Preferences: It MUST be possible for a user to indicate a preference for real-time text by registering that preference with a SIP server that is part of the ToIP service. b. Server tosupport of User Preferences: SIP servers that support ToIP services MUST have the capability to act on calling user preferences for real-time text in order to accept or reject the session-,session.The actions taken can be based on the called userÆsuser’s preferences defined as part of the pre-session setup registration. For example, if the user is called by another party, and it is determined that a transcoding server is needed, the session MUSTshould be re-directed or otherwise handled accordingly. 220.127.116.11.2 Basic Point-to-Point Session Requirementssetup A point-to-point session takes place between two parties. The requirements are described in subsequent sub-sections. They assume thatFor ToIP, one or both of the communicating parties will indicate real-time text as a possible or preferred medium for conversation using SIP in the session setup. 6.2.1 Session controlThe following features MAY be implemented to facilitate the session establishment using ToIP: a. Caller Preferences: SIP headers (e.g., Contact) can be used to show that ToIP services MUST useis the Session Initiation Protocol (SIP)  for setting up, controlling and terminating sessionsmedium of choice for real-time text conversation with one or more participants and possibly including other media like video or audio.communications. b. Called Party Preferences : The called party being passive can formulate a clear rule indicating how a session description protocol (SDP)  used inshould be handled either using real-time text as a preferred medium or not, and whether a designated SIP proxy needs to describe thehandle this session or it will be handled in the SIP user agent. c. SIP Server support for User Preferences: It is used to expressRECOMMENDED that SIP servers also handle the attributesincoming sessions in accordance with preferences expressed for real-time text. The SIP Server can also enforce ToIP policy rules for communications (e.g. use of the session and to negotiate a set of compatible media types. 6.2.2 Text transport A ToIP servicetranscoding server for ToIP). 18.104.22.168 Addressing The SIP  addressing schemes MUST always support at least one Text media type.be used for all entities in a ToIP services MUST support the Real-Time Transportsession. For example, SIP URL’s or Tel URL’s are used for caller, called party, user devices, and servers (e.g., SIP server, Transcoding server). 22.214.171.124 Session Negotiations The Session Description Protocol (RTP)  according(SDP) used in SIP  provides the capabilities to indicate real-time text as a medium in the specification of RFC4103session setup. RFC 4103  foruses the transportRTP payload types "text/red" and "text/t140" for support of text between participants. RFC4103 describesToIP which can be indicated in the transmission of T.140  on IP networks. A. van Wijk, et al. Expires 6 March 2006 [Page 12 of 28] 6.2.3 Session Setup Users will set upSDP as a session by identifyingpart of the remote party or the service they want to connect to. However, conversations couldSIP INVITE, OK and SIP/200/ACK media negotiations. In addition, SIP’s offer/answer model  can also be started using a modeused in conjunction with other than text. For instance, the conversation might be established using audio and the user could subsequently elect to switch to text, or add text as an additional modality, duringcapabilities including the conversation. Systems supporting ToIP MUST allow users to select anyuse of the supported conversation modes at any time, including mid-conversation.a transcoding server for enhanced session negotiations [14,15,16]. Systems SHOULD allow the user to specifyprovide a preferred mode of communication, with the ability to fall backbest-effort approach to alternatives thatanswering invitations for session set-up and users SHOULD be informed when the user has indicated are acceptable. Ifsession is accepted by the user requests simultaneous useother party. On all systems that both inform users of text and audio,session status and support ToIP, this is not possible either because the system only supports alternate modalities or because of constraintsinformation MUST be available in the network, the systemtextual form and MAY also be provided in other media. 126.96.36.199 Additional session control Systems that support additional session control features, for example call waiting, forwarding, hold etc on voice sessions, MUST tryoffer this functionality for text sessions. 6.2.2 Transport A ToIP service MUST always support at least one real-time text media type. ToIP services MUST support the Real-Time Transport Protocol (RTP)  according to establish communication with best effort. Ifthe user has expressed a preferencespecification of RFC4103  for text, establishmentthe transport of a connection includingtext MUST have priority over other outcomes of the session setup. The following features MAY be implemented to facilitatebetween participants. RFC4103 describes the session establishment using ToIP: a. Caller Preferences: SIP headers (e.g., Contact) can be usedtransmission of T.140  real-time text on IP networks. In order to show that ToIP isenable the mediumuse of choiceinternational character sets, the transmission format for communications. b. Called Party Preferences: The called party being passive can formulate a clear rule indicating how a session shouldtext conversation SHALL be handled either usingUTF-8 , in accordance with ITU-T T.140. If real-time text as a preferred medium or not, and whether a designated SIP proxy needsis detected to handle this session or it willbe handledmissing after transmission, there SHOULD be a "text loss" indication in the SIP user agent. c. SIP Server support for User Preferences: SIP servers can also handle the incoming sessionsreal-time text as specified in accordance with preferences expressed for ToIP. The SIP Server can also enforceT.140 Addendum 1 . ToIP policy rulesuses RTP as the default transport protocol for communications (e.g. usethe transmission of real-time text via the transcoding server for ToIP). 6.2.4 Addressingmedium "text/t140" as specified in RFC 4103 . The SIP  addressing schemes MUSTredundancy method of RFC 4103  SHOULD be used for all entities in a ToIP session. For example, SIP URLÆs or Tel URLÆs are used for caller, called party, user devices, and servers (e.g., SIP server, Transcoding server). The rightto include a transcoding service MUST NOT require user registration in any specific SIP registrar, but MAY require authorisationsignificantly increase the reliability of the SIP registrar to invoke the service. A. van Wijk, et al. Expires 6 March 2006 [Page 13 of 28] 6.2.5 Alerting User Agents supporting ToIPreal-time text transmission. A redundancy level using 2 generations gives very reliable results and is therefore strongly RECOMMENDED. Real-time text capability MUST have an alerting method (e.g., for incoming sessions) that canbe usedannounced in SDP by deaf and hard of hearing people or providea range of alternative, but equivalent, alerting methods that can be selected by all users, regardless of their abilities. It should be noted that external alerting systems existdeclaration similar to this example: m=text 11000 RTP/AVP 100 98 a=rtpmap:98 t140/1000 a=rtpmap:100 red/1000 a=fmtp:100 98/98/98 By having this single coding and one common interfacetransmission scheme for triggering the alerting action is a contact closure between two conductors. Among the alerting options are alerting by the User AgentÆs User Interface and specific alerting user agents registered to the same registrar as the main user agent. 6.2.6 Session information If present, identification of the originating party (for examplereal time text defined in the form of a URL or a CLI) MUST be clearly presented toSIP session control environment, the user in a form suitableopportunity for the user BEFORE the session invitationinteroperability is answered. When a session invitation involving ToIP originates from a gateway, thisoptimized. However, if good reasons exist, other transport mechanisms MAY be signaled tooffered and used for the user. The user MUST be informed of any change in modalities. 6.2.7 Session progress information During a conversationT.140 coded text provided that includes ToIP, status and session progress informationproper negotiation is introduced, but RFC 4103  transport MUST be provided inused as both the default and the fallback transport. Real-time text transmission from a textual form so users can perform all session control functions. That information MUSTterminal SHALL be equivalent to session progress information deliveredperformed character by character as entered, or in any other format, for example audio. Session progress information SHOULD use simple languagesmall groups of characters, so that as many users as possible can understand it. The use of jargon or ambiguous terminology SHOULD be avoided. Itno character is RECOMMENDED that text information be used together with iconsdelayed from entry to symbolise the session progress information. There MUST be a clear indication, intransmission by more than 300 milliseconds. The text transmission SHALL allow a modality usefulrate of at least 30 characters per second. 6.2.3 Transcoding services The right to the user, wheneverinclude a session is connected or disconnected. Atranscoding service MUST NOT require user SHOULD never beregistration in doubt about the statusany specific SIP registrar, but MAY require authorisation of the session, even if the user is unableSIP registrar to make use ofinvoke the audio or visual indication. For example, tactile indications could be used by deafblind individuals. In summary, it SHOULD be possible to observe indicators about: - Incoming session - Availabilityservice. A specific type of text, voice and video channels - Session progress - Incoming text - Any losstranscoding service in incoming text A. van Wijk, et al. Expires 6 March 2006 [Page 14 of 28] - Typed and transmitted text. For users who cannot use the audible alerter for incoming sessions, ita ToIP environment is RECOMMENDED to includea tactile as wellrelay service. The relay service acts as a visual indicator. 6.2.8 Session Negotiationsan intermediary between two or more callers using different media or different media encoding schemes. The Session Description Protocol (SDP) used in SIP  provides the capabilities to indicatebasic text asrelay service allows a medium in the session setup. RFC 4103  uses the RTP payload type "text/t140" for supporttranslation of ToIPspeech to real- time text and real-time text to speech, which can be indicated in the SDP as a part of the SIP INVITE, OKenables hearing and SIP/200/ACK media negotiations. In addition, SIPÆs offer/answer model  can also be used in conjunctionspeech impaired callers to communicate with hearing callers. Even though this document focuses on ToIP, we want to remind readers that other capabilities including the use of arelay services exist, like video relay services transcoding server for enhanced session negotiations [7,8,9]. 6.2.9 Answering Systems SHOULD provide a best-effort approachspeech to answering invitations for session set-upsign language and users SHOULD be informed whenvice versa where the sessionsigning is accepted by the other party. On all systemscommunicated using video. It is RECOMMENDED that both inform usersToIP implementations make the invocation and use of relay services as easy as possible. It MAY happen automatically when the session status andis being set up based on any valid indication or negotiation of supported or preferred media types. A transcoding framework document using SIP  describes invoking relay services, where the relay acts as a conference bridge or uses the third party control mechanism. ToIP implementations SHOULD support ToIP,this information MUST be available in textual formtranscoding framework. 6.2.4 Presentation and MAY alsoUser control functions 188.8.131.52 Progress and status information During a conversation that includes ToIP, status and session progress information MUST be provided in other media. 184.108.40.206 Answering Machine Systems for ToIP MAY support an auto-answer function,a textual form so users can perform all session control functions. That information MUST be equivalent to answering machines on telephony networks. If an answering machine function is supported, it MUST support at least 160 characterssession progress information delivered in any other format, for the greeting message. It MUST support incoming text message storage of a minimumexample audio. Session progress information SHOULD use simple language so that as many users as possible can understand it. The use of 4096 characters, although systems MAY support much larger storage.jargon or ambiguous terminology SHOULD be avoided. It is RECOMMENDED that systems support storage of at least 20 incoming messages of uptext information be used together with icons to 16000 characters per message. Whensymbolise the answering machine is activated, user alerting SHOULD still take place. The user SHOULDsession progress information. There MUST be alloweda clear indication, in a modality useful to monitorthe auto- answer progress and where thisuser, whenever a session is provided theconnected or disconnected. A user SHOULD never be allowed to intervene during any stage ofin doubt about the answering machine procedure and take controlstatus of the session. 6.2.10 Actions During a Session Certain actions needsession, even if the user is unable to make use of the audio or visual indication. For example, tactile indications could be performed during ToIP conversation: a. Text transmission from a terminal SHALL be performed characterused by character as entered, or in small groups of characters, so that no character is delayed from entrydeafblind individuals. In summary, it SHOULD be possible to transmission by more than 300 milliseconds. A. van Wijk, et al. Expires 6 March 2006 [Page 15 of 28] b. The text transmission SHALL allow a rateobserve indicators about: - Incoming session - Availability of at least 30 characters per second so that human typing speed as well as speech toreal-time text, voice and video channels - Session progress - Incoming real-time text methods of generating conversation- Any loss in incoming real-time text can be supported. c. To enable the- Typed and transmitted real-time text. 220.127.116.11 Alerting For users who cannot use of international character sets,the transmission formataudible alerter for text conversation SHALL be UTF-8 , in accordance with ITU-T T.140. d. If textincoming sessions, it is detectedRECOMMENDED to be missing after transmission, there SHOULD beinclude a "text loss" indication in the texttactile as specified in T.140 Addendum 1 . e. When the display of text conversation is included inwell as a visual indicator. Among the design ofalerting options are alerting by the endUser Agent’s User Interface and specific alerting user equipment,agents registered to the display ofsame registrar as the dialogue SHOULDmain user agent. It should be made sonoted that itexternal alerting systems exist and one common interface for triggering the alerting action is easya contact closure between two conductors. 18.104.22.168 Answering Machine Systems for ToIP MAY support an answering machine function, equivalent to differentiateanswering machines on telephony networks. If an answering machine function is supported, it MUST support at least 160 characters for the greeting message. It MUST support incoming real- time text belonging to each party in the conversation. 22.214.171.124 Text Transport ToIP uses RTP as the default transport protocol for the transmission of real-time text viamessage storage of a minimum of 4096 characters, although systems MAY support much larger storage. It is RECOMMENDED that systems support storage of at least 20 incoming messages of up to 16000 characters per message. When the medium "text/t140" as specified in RFC 4103 .answering machine is activated, user alerting SHOULD still take place. The redundancy method of RFC 4103 user SHOULD be usedallowed to significantly increase the reliability ofmonitor the text transmission. A redundancy level using 2 generations gives very reliable resultsauto-answer progress and where this is therefore RECOMMENDED. Text capability MUSTprovided the user SHOULD be announced in SDP by a declaration similarallowed to this example: m=text 11000 RTP/AVP 98 100 a=rtpmap:98 t140/1000 a=rtpmap:100 red/1000 a=fmtp:100 98/98/98 By having this single codingintervene during any stage of the answering machine procedure and transmission scheme for real timetake control of the session. 126.96.36.199 Text presentation When the display of text definedconversation is included in the SIP session control environment,design of the opportunity for interoperability is optimized. However, if good reasons exist, other transport mechanisms MAY be offered and used forend user equipment, the T.140 coded text provideddisplay of the dialogue SHOULD be made so that proper negotiationit is introduced, but RFC 4103  transport MUSTeasy to differentiate the text belonging to each party in the conversation. This could be used as bothdone using color, positioning of the defaulttext (i.e. incoming real-time text and outgoing real-time text in different display areas), by in-band identifiers of the fallback transport. 188.8.131.52 Handling Text and other Media. A call is oneparties or more related sessions. The following requirements apply to media handlingby a combination of any of these techniques. ToIP SHOULD handle characters such as new line, erasure and alerting during a call: a. When used between User Agents designed for ToIP, it SHALL be possiblesession as specified in ITU-T T.140 . 184.108.40.206 File storage Systems that support ToIP MAY save the text conversation to senda file. This SHOULD be done using a standard file format. For example: a UTF8 text file in XHTML format  including timestamps, party names (or addresses) and receivethe text simultaneously. A. van Wijk, et al. Expires 6 March 2006 [Page 16conversation. 6.2.5 Interworking functions A number of 28] b. When usedsystems for real time text conversation already exist as well as a number of message oriented text communication systems. Interoperability is of interest between User Agents that support ToIP, it SHALL be possible to sendToIP and receivesome of these systems. Interoperation of half-duplex and full-duplex protocols MAY require text simultaneously withbuffering. Some intelligence will be needed to determine when to change direction when operating in half-duplex mode. Identification may be required of half-duplex operation either at the other media (text, audio and/or video) supported by"user" level (ie. users must inform each other) or at the same terminals. c. It SHOULD"protocol" level (where an indication must be possiblesent back to know during a call that ToIP is available, even if it is not invoked at call setup (e.g. when only voice and/or videothe Gateway). However, the special care needs to be taken to provide the best possible real-time performance. 220.127.116.11 PSTN Interworking Analog text telephony is cumbersome because of incompatible national implementations where interworking was never considered. A large number of these implementations have been documented in ITU-T V.18 , which also defines the modem detection sequences for the different text protocols. The modem type identification may in rare cases take considerable time depending on user actions. To resolve analog textphone incompatibilities, text telephone gateways are needed to transcode incoming analog signals into T.140 and vice versa. The modem capability exchange time can be reduced by the text telephone gateways initially assuming the analog text telephone protocol used initially). To disable this,in the user MUST disableregion where the use of ToIP. Thisgateway is possible during registration atlocated. For example, in the SIP registrar. 6.2.11 Additional session control Systems that support additional session control features, for example call waiting, forwarding, hold etc on voice sessions, MUST offer this functionalityUSA, Baudot [II] might be tried as the initial protocol. If negotiation for text sessions. 6.2.12 File storage Systems that support ToIP MAY saveBaudot fails, the text conversation to a file. This SHOULDfull V.18 modem capability exchange will take place. In the UK, ITU-T V.21 [III] might be donethe first choice. In particular transmission of interactive text on PSTN networks takes place using a standard file format. For example:variety of codings and modulations, including ITU-T V.21 [III], Baudot [II], DTMF, V.23 [IV] and others. Many difficulties have arisen as a UTF8 text fileresult of this variety in XML format  including timestamps, party names (or addresses)text telephony protocols and the ITU-T V.18  standard was developed to address some of these issues. ITU-T V.18  offers a native text conversation. 6.3 Conference Session Requirements The conference session requirements dealtelephony method plus it defines interworking with multipoint conferencing sessions where therecurrent protocols. In the interworking mode, it will berecognise one or more ToIP capable devices and/or other end user devices where the total numberof end user devices will be at least three. It SHOULD be possible to usethe text medium in conference sessions in a similar way to how audio is handled and video is displayed.older protocols and fall back to that transmission method when required. Text in conferences can be used both for letting individual participantsgateways MUST use the text medium (for example, for sidebar discussions in text while listening toITU-T V.18  standard at the main conference audio), as wellPSTN side. A text gateway MUST act as for central support ofa SIP User Agent on the conference with real timeIP side and support RFC4103 text interpretationtransport. PSTN-ToIP gateways MUST allow alternating use of speech. 6.4 Real-time Editing and User Alerting ToIP SHOULD handle characters such as new line, erasurereal-time text and alerting during avoice if the PSTN textphone involved at the PSTN side of the session supports this. (This mode is often called VCO/HCO). Calling party identification information, such as specified in ITU-T T.140. 6.5 Emergency services ItCLI, MUST be possiblepassed by gateways and converted to placean emergency call usingapproapriate form if required. While ToIP allows receiving and it MUST be possible to usesending real-time text simultaneously and is displayed on a relay service in such call. The emergency service provided to users utilising thesplit screen, many analog text medium MUST be equivalent to the emergency service provided totelephones require users utilising speech or other media. A. van Wijk, et al. Expires 6 March 2006 [Page 17 of 28] 6.6 User Mobility ToIP User Agents SHOULD use the same mechanisms as other SIP User Agentsto resolve mobility issues. Ittake turns typing. This is RECOMMENDED that users use a SIP-address, resolved by a SIP registrar, to enable basic user mobility. Further mechanisms are defined for all session types for 3G IP multimedia systems. 6.7 Firewallsbecause many text telephones operate strictly half duplex. Only one can transmit text at a time. The users apply strict turn- taking rules. There are several text telephones which communicate in full duplex, but merge transmitted text and NATs ToIP usesreceived text in the same signaling and transport protocols as VoIP hence,line in the same firewalldisplay window. And also here do the users apply strict turn taking rules. Native V.18 text telephones support full duplex and NAT solutionsseparate display from reception and network functionalitytransmission so that apply to VoIP MUST also apply to ToIP. 7. Interworking Requirements forthe full duplex capability can be used fully. Such devices could use the ToIP A number of systems for real time text conversation already exist as wellsplit screen as a number of message orientedwell, but almost all text communication systems. Interoperability is of interest between ToIPtelephones use a restricted character set and some of these systems. This section describes the interoperability requirements, especially for PSTNmany use low text telephony,transmission speeds (4 to ensure full backward interoperability with ToIP. 7.1 ToIP Interworking Gateway Services Interactive texting facilities exist already in various forms and on various networks. On the PSTN,7 charcters per second). That is why it is commonly referredimportant for the ToIP user to as text telephony. Simultaneousknow that he or alternating use of voice and textshe is used by a large number of users who can send voice but must receiveconnected with an analog text (duetelephone. The "txp" media content attribute SHOULD be used to indicate that the call originates from a hearing impairment),PSTN text telephone (e.g. via an ATA or who can hear but must senda text (due togateway). 18.104.22.168 Mobile Interworking Mobile wireless (or Cellular) circuit switched connections provide a speech impairment). Session setup through gatewaysdigital real-time transport service for voice or data. The access technologies include GSM, CDMA, TDMA, iDen and various 3G technologies. ToIP may be supported over the cellular wireless packet switched service. It interfaces to other networks MAY requirethe use of specially formatted addresses or other mechanisms for invoking those gateways. Different data rates of different protocols MAY requireInternet. The following sections describe how mobile text buffering. Transcoding oftelephony is supported. 22.214.171.124.1 Cellular "No-gain" The "No-gain" text totelephone transporting technology uses specially modified EFR  and from other coding formats MAY need to take placeEVR  speech vocoders in gateways between ToIP and other forms of text conversation, for example to connectmobile terminals used to provide a PSTNtext telephone. 7.2 ToIPtelephony call. It provides full duplex operation and supports alternating voice and PSTN/ISDN Text-Telephony Interworking On PSTN networks, transmission of interactivetext takes place using a variety of codings("VCO/HCO"). It is dedicated to CDMA and modulations, including ITU-T V.21 [II], Baudot [III], DTMF, V.23 [IV]TDMA mobile technologies and others. Many difficulties have arisen asthe US Baudot (i.e. 45 bit/s) type of text telephones. 126.96.36.199.2 Cellular Text Telephone Modem (CTM) CTM  is a resulttechnology independent modem technology that provides the transport of this variety intext telephony protocolstelephone characters at up to 10 characters/sec using modem signals that can be carried by many voice codecs and the ITU-T V.18  standard was developeduses a highly redundant encoding technique to address some of these issues. A. van Wijk, et al. Expires 6 March 2006 [Page 18 of 28] ITU-T V.18  offersovercome the fading and cell changing losses. 188.8.131.52.3 Cellular "Baudot mode" This term is often used by cellular terminal suppliers for a native text telephony method plus it defines interworkingGSM cellular phone mode that allows TTYs to operate into a cellular phone and to communicate with current protocols. In the interworking mode,a fixed line TTY. Thus it will recognise one ofis a common name for the older protocols"No-Gain" and fall back to that transmission methodthe CTM solutions when required. V.18 MUST be supported onapplied to the PSTN side of a PSTN-ToIP gateway. PSTN-ToIP gateways MUSTBaudot type textphones. 184.108.40.206.4 Mobile data channel mode Many mobile terminals allow alternatingthe use of text and voice if the PSTN textphone involved atthe PSTN sidecircuit switched data channel to transfer data in real-time. Data rates of 9600 bit/s are usually supported on the session supports this. (This mode is often called VCO/HCO). Calling party identification information, such as CLI, MUST be passed by gateways and converted to an approapriate form if required. 7.3 ToIP and Cellular Wireless2G mobile network. Gateways provide interoperability with PSTN textphones. 220.127.116.11.5 Mobile ToIP ToIP MAYcould be supported over the cellular wireless packet switched service. It interfaces to the Internet. A text gateway with cellularmobile wireless packet switched services MUST be able to route text callsthat interface to emergency service providers when any ofthe recognized emergency numbers thatInternet. For 3GPP 3G services, ToIP support text communication for the country. 7.4is described in 3G TS 26.235 . 18.104.22.168 Instant Messaging SupportInterworking Text gateways MAY be developedused to allow interworking between Instant Messaging systems and ToIP solutions. Because Instant Messaging is based on blocks of text, rather than on a continuous stream of characters,characters like ToIP, gateways MUST transcode between the two formats. Text gateways for interworking between Instant Messaging and ToIP MUST concatenateapply a procedure for bridging the different conversational formats of real-time text versus text messaging. The following advice may improve user experience for both parties in a call through a messaging gateway. a. Concatenate individual characters originating at the ToIP side into blocks of text and: a.text. b. When the length of the concatenated message becomes longer than 50 characters, the buffered text SHOULD be transmitted to the Instant Messaging side as soon as any non-alphanumerical character is received from the ToIP side. b.c. When a new line indicator is received from the ToIP side, the buffered characters up to that point, including the carriage return and/or line feed characters, SHOULD be transmitted to the Instant Messaging side. c.d. When the ToIP side has been idle for at least 5 seconds, all buffered text up to that point SHOULD be transmitted to the Instant Messaging side.Instant Messaging side. e. Text Gateways must be capable to maintain the real-time performance for ToIP while providing the interworking services. It is RECOMMENDED that during the session, both users are constantly updated on the progress of the text input. A. van Wijk, et al. Expires 6 March 2006 [Page 19 of 28]Many Instant Messaging protocols signal that a user is typing to the other party in the conversation. Text gateways between such Instant Messaging protocols and ToIP MUST provide this signaling to the Instant Messaging side when characters start being received, or at the beginning of the conversation. At the ToIP side, an indicator of writing the Instant Message MUST be present where the Instant Messaging protocol provides one. For example, the real-time text user MAY see ". . . waiting for replying IM. . . " and when 5 seconds have passed another . (dot) can be shown. Those solutions will reduce the difficulties between streaming and blocked text services. Even though the text gateway can connect Instant Messaging and ToIP, the best solution is to take advantage of the fact that the user interfaces and the user communities for instant messaging and ToIP telephony are very similar. After all, the character input, the character display, Internet connectivity and SIP stack arecan be the same for Instant Messaging (SIMPLE) and ToIP. Thus, the user may simply use different applications for ToIP and text messaging in the same terminal. Devices that implement Instant Messaging SHOULD implement ToIP as described in this document so that a more complete text communication service can be provided. 7.5 Common Text Gateway Functions22.214.171.124 Interworking through gateways Transcoding of text to and from other coding formats MAY need to take place in gateways between ToIP and other forms of text conversation, for example to connect to a PSTN text telephone. Text gateways MUST allow for the differences that result from different text protocols. The protocols to be supported will depend on the service requirements of the Gateway. 7.5.1 Protocol support TextSession setup through gateways MUST use the ITU-T V.18  standard at the PSTN side. A text gateway MUST act as a SIP User Agent onto other networks MAY require the IP side and support RFC4103use of specially formatted addresses or other mechanisms for invoking those gateways. Different data rates of different protocols MAY require text transport. 7.5.2 Relay buffer storagebuffering. When text gateway functions are invoked, there will be a need for intermediate storage of characters before transmission to a device receiving text slower than the transmitting speed of the sender. Such temporary storage SHALL be dimensioned to adjust for receiving at 30 characters per second and transmitting at 6 characters per second for up to 4 minutes (i.e. less than 3k3000 characters). Interoperation of half-duplex and full-duplex protocols MAY require text buffering. Some intelligence will be needed to determine when to change direction when operating in half-duplex mode. Identification may be required of half-duplex operation either at the "user" level (ie. users must inform each other) or A. van Wijk, et al. Expires 6 March 2006 [Page 20 of 28] at the "protocol" level (where an indication must be sent back to the Gateway). 7.5.3 Emergency calls through gateways A text gateway MUST be able to route text calls to emergency service providers when any of the recognised emergency numbers that support text communications for the country or region are called e.g. "911" in USA and "112" in Europe. Routing text calls to emergency services MAY require the use of a transcoding service. 7.5.4 Text Gateway InvocationToIP interworking requires a method to invoke a text gateway. As described previously in this draft,previously, these text gateways MUST act as User Agents at the IP side. The capabilities of the textgateway during the call will be determined by the call capabilities of the terminal that is using the gateway. For example, a PSTN textphone is generally only able to receive voice and streamingreal-time text, so the textgateway will only allow ToIP and audio. Examples of possible scenarios for invocation of the text gateway are: a. PSTN textphone users dial a prefix number before dialing out. b. Separate real-time text subscriptions, linked to the phone number or terminal identifier/ IP address. c. Text capability indicators. d. Text preference indicator. e. Listen for V.18 modem modulation text activity in all PSTN calls and routing of the call to an appropriate gateway. f. Call transfer request by the called user. g. Placing a call via the web, and using one of the methods described here h. Text gateways with its own telephone number and/or SIP address. (This requires user interaction with the text gateway to place a call). i. ENUM address analysis and number plan j. Number or address analysis leads to a gateway for all PSTN calls. 7.6 Home Gateways or Analog Terminal Adapters Analog terminal adapters (ATAs) using SIP based IP communication and RJ-11 connectors for connecting traditional PSTN devices SHOULD enable connection of legacy PSTN text telephones . These adapters SHOULD contain V.18 modem functionality, voice handling functionality, and conversion functions to/from SIP based ToIP with T.140 transported according to RFC 4103 , in a similar way as it provides interoperability for voice sessions. A. van Wijk, et al. Expires 6 March 2006 [Page 21 of 28] If a session is set up and text/t140 capability is not declared by the destination endpoint (by the end-point terminal or theReal-time text gateway in the network at the end-point), a method for invoking a transcoding server SHALL be used. If no such server is available, the signals from the textphone MAY be transmitted in the voice channel as audio with high quality of service. NOTE: It is preferred that such analog terminal adaptors do use RFC 4103  on board and thus act as acapability indicators. d. Real-time text gateway. Sending textphone signals overpreference indicator. e. Listen for V.18 modem modulation text activity in all PSTN calls and routing of the voice channel is undesirable duecall to possible filtering and compression and packet loss betweenan appropriate gateway. f. Call transfer request by the end-points. This can result in character loss incalled user. g. Placing a call via the textphone conversation or even not allowingweb, and using one of the textphonesmethods described here h. Text gateways with its own telephone number and/or SIP address. (This requires user interaction with the gateway to connectplace a call). i. ENUM address analysis and number plan j. Number or address analysis leads to each other. 7.7a gateway for all PSTN calls. 126.96.36.199 Multi-functional Combination gateways In practice many interworking gateways will be implemented as gateways that combine different functions. As such, a text gateway could be built to have modems to interwork with the PSTN and support both Instant Messaging as well as ToIP. Such interworking functions are called Combination gateways. Combination gateways MUST provide interworking between all of their supported text based functions. For example, a textText gateway that has modems to interwork with the PSTN and that support both Instant Messaging and real-timeToIP MUST support the following interworking functions: - PSTN text telephony to real-timeToIP. - PSTN text telephony to Instant Messaging. - Instant Messaging to real-timeToIP. 7.8 Transcoding188.8.131.52 Character set transcoding Gateways between the ToIP network and other networks MAY need to transcode text streams. ToIP makes use of the ISO 10646 character set. Most PSTN textphones use a 7-bit character set, or a character set that is converted to a 7-bit character set by the V.18 modem. When transcoding between character sets and T.140 in gateways, special consideration MUST be given to the national variants of the 7 bit codes, with national characters mapping into different codes in the ISO 10646 code space. The national variant to be used could be selectable by the user on a per call basis, or be configured as a national default for the gateway. The indicator of missing text in T.140, specified in T.140 amendment 1, cannot be represented in the 7 bit character codes. Therefore the indicator of missing text SHOULD be transcoded to the '‘ (apostrophe) character in legacy text telephone systems, A. van Wijk, et al. Expires 6 March 2006 [Page 22 of 28]where this character exists. For legacy systems where the character '‘ does not exist, the . ( full stop )(full stop) character SHOULD be used instead. 7.9 Relay Services The relay7. Further recommendations for implementers and service acts asproviders 7.1 Access to Emergency services It MUST be possible to place an intermediary between two or more callersemergency call using different media or different media encoding schemes. 7.9.1 Basic function of theToIP and it MUST be possible to use a relay service in such call. The basic text relayemergency service allows a translation of speechprovided to users utilising the real-time text and text to speech, which enables hearing and speech impaired callersmedium MUST be equivalent to communicate with hearing callers. Even though this document focuses on ToIP, we wantthe emergency service provided to remind readers that other relay services exist, like video relay services transcodingusers utilising speech or other media. A text gateway MUST be able to sign language and vice versa where the signing is communicated using video. 7.9.2 Invocationroute real-time text calls to emergency service providers when any of relay services It is RECOMMENDEDthe recognised emergency numbers that ToIP implementations makesupport text communications for the invocationcountry or region are called e.g. "911" in USA and "112" in Europe. Routing real-time text calls to emergency services MAY require the use of relaya transcoding service. A text gateway with cellular wireless packet switched services as easy as possible. It MAY happen automaticallyMUST be able to route real-time text calls to emergency service providers when the session is being set up based onany valid indication or negotiationof supportedthe recognized emergency numbers that support real-time text communication for the country is called. 7.2 Home Gateways or preferred media types. A transcoding framework documentAnalog Terminal Adapters Analog terminal adapters (ATA) using SIP  describes invoking relay services, where the relay actsbased IP communication and RJ-11 connectors for connecting traditional PSTN devices SHOULD enable connection of legacy PSTN text telephones . These adapters SHOULD contain V.18 modem functionality, voice handling functionality, and conversion functions to/from SIP based ToIP with T.140 transported according to RFC 4103 , in a similar way as it provides interoperability for voice sessions. If a conference bridge or usessession is set up and text/t140 capability is not declared by the third party control mechanism. ToIP implementations SHOULD support this transcoding framework. Addingdestination endpoint (by the end-point terminal or removingthe text gateway in the network at the end-point), a relay service MUSTmethod for invoking a transcoding server SHALL be possible without disruptingused. If no such server is available, the current session. When setting up a session,signals from the relay service MUSTtextphone MAY be able to determinetransmitted in the typevoice channel as audio with high quality of service requested (e.g., speech to text orservice. NOTE: It is preferred that such analog terminal adaptors do use RFC 4103  on board and thus act as a text to speech), to indicate ifgateway. Sending textphone signals over the caller wantsvoice carry over, the language ofchannel is undesirable due to possible filtering and compression and packet loss between the text,end-points. This can result in character loss in the sign language being used (intextphone conversation or even not allowing the video stream), etc. It SHOULD be possibletextphones to routeconnect to each other. 7.3 User Mobility ToIP User Agents SHOULD use the sessionsame mechanisms as other SIP User Agents to resolve mobility issues. It is RECOMMENDED that users use a preferred relay service even if theSIP-address, resolved by a SIP registrar, to enable basic user invokes themobility. Further mechanisms are defined for all session from another region ortypes for 3G IP multimedia systems. 7.4 Firewalls and NATs ToIP uses the same signaling and transport protocols as VoIP. Hence, the same firewall and NAT solutions and network thanfunctionality that usually used. A number of requirements, motivations and implementation guidelines for relay service invocation can be found in RFC 3351 .apply to VoIP MUST also apply to ToIP. 8. IANA Considerations There are no IANA considerations for this specification. 9. Security Considerations User confidentiality and privacy need to be met as described in SIP . For example, nothing should reveal the fact that the user ofToIP isuser might be a person with a disability unlesshearing or speech impairment. ToIP is after all a mainstream communication medium for all users. It is up to the ToIP user prefersto make this informationhis or her hearing or speech impairment public. If a transcoding server is being A. van Wijk, et al. Expires 6 March 2006 [Page 23 of 28]used, this SHOULD be transparent. Encryption SHOULD be used on end-to-end or hop-by-hop basis as described in SIP  and SRTP .. Authentication needs to be provided for users in addition to the message integrity and access control. Protection against Denial-of-service (DoS) attacks needs to be provided considering the case that the ToIP users might need transcoding servers. 9. Authors10. Authors’ Addresses The following people provided substantial technical and writing contributions to this document, listed alphabetically: Willem P.Dijkstra TNO Informatie- en Communicatietechnologie Postbus 15000 9700 CDEemsgolaan 3 9727 DW Groningen The Netherlands Tel:tel : +31 50 585 77 24 Fax:fax : +31 50 585 77 57 Email: firstname.lastname@example.org Barry Dingle ACIF, 32 Walker Street North Sydney, NSW 2060 Australia Tel +61 (0)2 9959 9111 Mob +61 (0)41 911 7578 Email email@example.comEmail: firstname.lastname@example.org Guido Gybels Department of New Technologies RNID, 19-23 Featherstone Street London EC1Y 8SL, UK Tel +44(0)20 7294 3713 Txt +44(0)20 7296 80197608 0511 Fax +44(0)20 7296 8069 Email: email@example.com Gunnar Hellstrom Omnitor AB Renathvagen 2 SE 121 37 Johanneshov Sweden Phone: +46 708 204 288 / +46 8 556 002 03 Fax: +46 8 556 002 06 Email: firstname.lastname@example.org A. van Wijk, et al. Expires 6 March 2006 [Page 24 of 28]Radhika R. Roy SAIC 3465-B Box Hill Corporate Center Drive Abingdon, MD 21009 Tel: 443 402 9041 Email: Radhika.R.Roy@saic.com Henry Sinnreich pulver.com 115 Broadhollow Rd Suite 225 Melville, NY 11747 USA Tel: +1.631.961.8950 Gregg C Vanderheiden University of Wisconsin-Madison Trace R & D Center 1550 Engineering Dr (Rm 2107) Madison, Wi 53706 USA Phone +1 608 262-6966 FAX +1 608 262-8848 Email: email@example.com Arnoud A. T. van Wijk Viataal CentreFoundation for R & D on sensoryan Information and communication disabilities. Theerestraat 42 5271 GD Sint-Michielsgestel The Netherlands.Communication Network for the Deaf and Hard of Hearing "AnnieS" www.annies.nl Email: firstname.lastname@example.org email@example.com 11. References 10.111.1 Normative references 1. S. Bradner, "Intellectual Property Rights in IETF Technology ",Technology", BCP 79, RFC 3979, IETF, March 2005. 2. S. Bradner, "Key wordsCharlton, Gasson, Gybels, Spanner, van Wijk, "User Requirements for usethe Session Initiation Protocol (SIP) in RFCs to Indicate Requirement Levels", BCP 14,Support of Deaf, Hard of Hearing and Speech-impaired Individuals", RFC 2119,3351, IETF, March 1997August 2002. 3. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session Initiation Protocol", RFC 3621, IETF, June 2002. 4. H. Schulzrinne, S.Casner, R. Frederick, V. Jacobsone, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, IETF, July 2003. 5. G. Hellstrom, P. Jones, "RTP Payload for Text Conversation", RFC 4103, IETF, June 2005. 6. ITU-T Recommendation F.703,"Multimedia Conversational Services", November 2000. 7. S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, IETF, March 1997 8. 3GPP TS 26.226 "Cellular Text Telephone Modem Description" (CTM). 9. ITU-T Recommendation T.140, "Protocol for Multimedia Application Text Conversation" (February 1998) and Addendum 1 (February 2000). A. van Wijk, et al. Expires 6 March 2006 [Page 25 of 28] 5.10. J. Hautakorpi, G. Hellstrom, "RTP Payload for Text Conversation",Camarillo, "The SDP (Session Description Protocol) Content Attribute", IETF, February 2006 - Work in Progress. 11. J. Rosenberg, H. Schulzrinne, P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 4103,3840, IETF, June 2005. 6. G. Camarillo,August 2004 12. J. Rosenberg, H. Schulzrinne, and E. Burger, "The Source and Sink AttributesP. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, IETF, August 2004 13. J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol,"Protocol (SDP)", RFC 3624, IETF, August 2003 - Work in Progress. 7. G.Camarillo,June 2002. 14. G. Camarillo, "Framework for Transcoding with the Session Initiation Protocol" IETF JuneNov 2005 - Work in progress. 8.15. G. Camarillo, H. Schulzrinne, E. Burger, and A. van Wijk, "Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)" RFC 4117, IETF, June 2005. 9.16. G. Camarillo, "The SIP Conference Bridge Transcoding Model," IETF, August 2003Jan 2006 - Work in Progress. 10. ITU-T Recommendation V.18,"Operational and Interworking Requirements for DCEs operating in Text Telephone Mode," November 2000. 11.17. Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, IETF,November 2003. 18. "XHTML 1.0: The Extensible HyperText Markup Language: A Reformulation of HTML 4 in XML 1.0", W3C Recommendation. Available at http://www.w3.org/TR/xhtml1. 12. Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, IETF, January 1998. 13.19. ITU-T Recommendation V.18,"Operational and Interworking Requirements for DCEs operating in Text Telephone Mode," November 2000. 20. TIA/EIA/IS-823-A "TTY/TDD Extension to TIA/EIA-136-410 Enhanced Full Rate Speech Codec (must used in conjunction with TIA/EIA/IS-840)" 14.21. TIA/EIA/IS-127-2 "Enhanced Variable Rate Codec, Speech Service Option 3 for Wideband Spread Spectrum Digital Systems. Addendum 2." 15.22. "IP Multimedia default codecs". 3GPP TS26.226 "Cellular Text Telephone Modem Description" (CTM). 16.TS 26.235 23. H. Sinnreich, S. Lass, and C. Stredicke, "SIP Telephony Device Requirements and Configuration," IETF, JuneOctober 2005 - Work in Progress. 17.24. Baugher, McGrew, Carrara, Naslund, Norrman, "The Secure Real Time Transport Protocol (SRTP)", RFC 3711, IETF, March 2004. 18. "IP Multimedia default codecs". 3GPP TS 26.235 19. Charlton, Gasson, Gybels, Spanner, van Wijk, "User Requirements for the Session Initiation Protocol (SIP) in Support A. van Wijk, et al. Expires 6 March 2006 [Page 26 of 28] of Deaf, Hard of Hearing and Speech-impaired Individuals", RFC 3351, IETF, August 2002. 20. J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3624, IETF, June 2002. 21.25. ITU-T Recommendation F.700,"Framework Recommendation for Multimedia Services", November 2000. 22. H. Schulzrinne, S.Casner, R. Frederick, V. Jacobsone, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, IETF, July 2003. 23. ITU-T Recommendation F.703,"Multimedia Conversational Services", November 2000. 24. J. Rosenberg, H. Schulzrinne, P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, IETF, August 2004 10.211.2 Informative references I. A relay service allows the users to transcode between different modalities or languages. In the context of this document, relay services will often refer to text relays that transcode text into voice and vice-versa. See for example http://www.typetalk.org. II. International Telecommunication Union (ITU), "300 bits per second duplex modem standardized for use in the general switched telephone network". ITU-T Recommendation V.21, November 1988. III.TIA/EIA/825 "A Frequency Shift Keyed Modem for Use on the Public Switched Telephone Network." (The specification for 45.45 and 50 bit/s TTY modems.)45.45 and 50 bit/s TTY modems.) III. International Telecommunication Union (ITU), "300 bits per second duplex modem standardized for use in the general switched telephone network". ITU-T Recommendation V.21, November 1988. IV. International Telecommunication Union (ITU), "600/1200-baud modem standardized for use in the general switched telephone network. ITU-Tnetwork". ITU- T Recommendation V.23, November 1988. Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property StatementThe IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an A. van Wijk, et al. Expires 6 March 2006 [Page 27 of 28]attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at firstname.lastname@example.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgmentietf- email@example.com. Acknowledgement Funding for the RFC Editor function is currentlyprovided by the Internet Society. A. van Wijk, et al. Expires 6 March 2006 [Page 28 of 28]IETF Administrative Support Activity (IASA).