Internet DraftA. van WijkWijk, Editor Internet Draft G. Gybels, Editor Category: Informational AnnieS Expires: September 5June 25, 2006 March 6,Expires: December 27, 2006 Framework for real-time text over IP using SIP draft-ietf-sipping-toip-04.txtthe Session Initiation Protocol (SIP) draft-ietf-sipping-toip-05.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. 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. 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 September 5,December 27, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document provides a framework for the implementation of real- time text conversation over the IP network using the Session Initiation Protocol and the Real-Time Transport Protocol. Itlists the essential requirements for real-time Text-over-IPText- over-IP (ToIP) and defines a framework for implementation of all required functions based on existing protocolsthe Session Initiation Protocol (SIP) and techniques.the Real-Time Transport Protocol (RTP). This includes interworking between Text-over-IP and existing text telephony on the PSTN and other networks. Table of Contents 1. Introduction...................................................3Introduction....................................................2 2. Scope..........................................................4Scope...........................................................3 3. Terminology....................................................4Terminology.....................................................3 4. Definitions....................................................4Definitions.....................................................4 5. Requirements...................................................6Requirements....................................................5 5.1 General requirements for ToIP..............................6ToIP................................6 5.2 Detailed requirements for ToIP.............................8ToIP...............................7 van Wijk, et al. Expires December 27, 2006 [Page 1] 5.2.1 Session control andset-up requirements...............8and control requirements..................7 5.2.2 Transport requirements................................9requirements...................................8 5.2.3 Transcoding service requirements.....................10requirements.........................9 5.2.4 Presentation and User control requirements...........11requirements..............10 5.2.5 Interworking requirements............................12requirements...............................11 126.96.36.199 PSTN Interworking requirements..................12requirements......................11 188.8.131.52 Cellular Interworking requirements..............12requirements..................12 184.108.40.206 Instant Messaging Interworking requirements.....13requirements.........12 6. Implementation Framework......................................13Framework.......................................12 6.1 Framework of general implementation.......................13General implementation framework............................13 6.2 Framework of detailed implementation......................14Detailed implementation framework...........................13 6.2.1 Session control and set-up...........................14set-up..............................13 220.127.116.11 Pre-session setup...............................14set-up..................................13 18.104.22.168 Basic Point-to-Point Session setup..............15 22.214.171.124 Addressing......................................15 126.96.36.199Session Negotiations............................15 188.8.131.52 Additional session control......................16Negotiations................................14 6.2.2 Transport............................................16Transport...............................................14 6.2.3 Transcoding services.................................17services....................................15 6.2.4 Presentation and User control functions..............18functions.................15 184.108.40.206 Progress and status information.................18information.....................15 220.127.116.11 Alerting........................................18Alerting............................................16 18.104.22.168 Answering Machine...............................18 22.214.171.124Text presentation...............................19 126.96.36.199presentation...................................16 188.8.131.52 File storage....................................19storage........................................16 6.2.5 Interworking functions...............................19functions..................................16 184.108.40.206 PSTN Interworking...............................20Interworking...................................17 220.127.116.11 Mobile Interworking.............................21Interworking.................................18 18.104.22.168.1 Cellular "No-gain".........................21"No-gain"..............................19 22.214.171.124.2 Cellular Text Telephone Modem (CTM)........21(CTM).............19 126.96.36.199.3 Cellular "Baudot mode".....................22mode"..........................19 188.8.131.52.4 Mobile data channel mode...................22mode........................19 184.108.40.206.5 Mobile ToIP................................22ToIP.....................................19 220.127.116.11 Instant Messaging Interworking..................22Interworking......................19 18.104.22.168 Interworking through gateways...................23 22.214.171.124Multi-functional Combination gateways...........24 126.96.36.199gateways...............21 188.8.131.52 Character set transcoding.......................25transcoding...........................21 7. Further recommendations for implementers and service providers25providers.21 7.1 Access to Emergency services..............................25services................................21 7.2 Home Gateways or Analog Terminal Adapters.................26Adapters...................22 7.3 User Mobility.............................................26Mobility...............................................22 7.4 Firewalls and NATs........................................26NATs..........................................22 8. IANA Considerations...........................................26Considerations............................................22 9. Security Considerations.......................................26Considerations........................................23 10. Authorsí Addresses...........................................27Authors Addresses..............................................23 11. References...................................................28 11.1Contributors...................................................23 12. References.....................................................24 12.1 Normative references.....................................28 11.2references........................................24 12.2 Informative references...................................30references......................................25 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 van Wijk, et al. Expires December 27, 2006 [Page 2] do not wish to, use voice. It therefore meets a different set of requirements from other text-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. Real-time text conversation can be combined with other conversational media like video or voice." 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)(VoIP), Video-over-IP and Multimedia-over-IP (MoIP) environments, as well as meeting the userís requirements, including thoserequirements of deaf, hard of hearing and speech- impairedspeech-impaired users as described in RFC3351  and of mainstream users. ToIP also offers an IP equivalent of analog text telephony services as used by deaf, hard of hearing, speech-impaired 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 signalingsignalling 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 real-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 . 2. Scope This document defines a framework for the implementation of real-time ToIP, either stand-alone or as a part of multimedia services, including Total Conversation . It definesprovides the: a. Requirements of Real-timerequirements for real-time text; b. Requirementsrequirements for ToIP interworking; c. Descriptiondescription of ToIP implementation using SIP and RTP; d. Descriptiondescription of ToIP interworking with other text services. 3. Terminology In this document, theThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119  and indicate requirement levels for compliant implementations. van Wijk, et al. Expires December 27, 2006 [Page 3] 4. Definitions Audio bridging: a function of an audio media bridge server, gateway or relay service that bridges audio into a single source through combining audio from multiple users excluding each destination sourceís audio andsends to each respectivedestination enabling anthe combination of audio path throughfrom all participants in a conference excluding the service betweenparticipant(s) at that destination. At the users involved inRTP level, this is an instance of the call.mixer function as defined in RFC 3550 . Cellular: a telecommunication network that has wireless access and can support voice and data services over very large geographical areas. Also called Mobile. Full duplex: media is sent independently in both directions. Half duplex: media can only be sent simultaneously in one direction at a timeor, if an attempt to send information in both directions is made, errors canmay be introduced into the presented media. Interactive text: aanother 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 toreal-time text.)text, as defined below. 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. Conversational text is defined in the ITU-T F.700Framework for multimedia servicesservices, Recommendation F.700 . 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-end real-time, interactive text communication using analog transmission. A variety of PSTN textphone protocols exists world- wide.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: a function of athe text media bridge server, gateway (including transcoding gateways) or relay service analogous to that enables the flowof audio bridging as defined above, except that text through the service between the users involved inis the call.medium of conversation. Text Relay Service:relay service: a third-party or intermediary that enables communications between deaf, hard of hearing and speech-impaired people,people and voice telephone users by translating between voice and real-time text in a call. Text 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. Texttelephony: analog textphone service. Total Conversation: a multimedia service offering real time conversation in video, real-time text and voice according to van Wijk, et al. Expires December 27, 2006 [Page 4] interoperable standards. All media streams flow in real time. (See ITU-T F.703 "Multimedia conversational services" .) Transcoding Services: services ofservice: a service provided by a third-party user agent that transcodes one stream into another. Transcoding can be done by human operators, in an automated mannermanner, or by a combination of both methods. Text Relay Services are examplesWithin this document the term particularly applies to conversion between different types of media. A text relay service is an example of a transcoding service that converts between real-time text and audio. TTY: originally, an abbreviation for "teletype". Often used in North America as an alternative designation for a text telephone or textphone, often used in USA.textphone. Also called TDD, Telecommunication Device for the Deaf. Video Relay Service: Arelay service: a service that enables communications between deaf and hard of hearing people,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 offor Mobile CommunicationCommunications 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 5. Requirements ThisThe framework described in section 6 defines a text-based conversational service that is the text equivalent of voice based van Wijk, et al. Expires December 27, 2006 [Page 5] 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 hearing, 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 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. 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 take place. 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. In 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 those provided by voice. To achieve that, ToIP needs to: a. Offeroffer real-time transport and presentation of the conversation; b. Provideprovide simultaneous transmission in both directions; c. Supportsupport both point-to-point and multipoint communication; d. Allowallow other media, like audio and video, to be used in conjunction with ToIP; e. Ensureensure that the real-time text service is always available. Real-time text is a useful subset of Total Conversation as defined in ITU-T F.703 . Users couldTotal Conversation allows participants to 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. Deaf, hard-of-hearing and mainstream users may invoke ToIP services for many different reasons: - Becausebecause they are in a noisy environment, e.g., in a machine room of a factory where listening is difficult.difficult; - Becausebecause they are busy with another call and want to participate in two calls at the same time.time; - Forfor implementing text and/or speech recording services (e.g., text documentation/ audio recordingrecording) for legal purposes, for clarity or for legal/clarity/flexibility purposes).flexibility; - Toto overcome language barriers through speech translation and/or transcoding services.services; van Wijk, et al. Expires December 27, 2006 [Page 6] - Becausebecause of hearing loss, deafness or tinnitus as a result of the aging process or for any other reason, thuscreating a need to replace or complement voice with real-time text in conversational sessions. 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 with users who are hard of hearing and also for mixed media calls with both hearing and deaf people participating in the call. A ToIP user may wish to call another ToIP user, orjoin a conference session involving several usersusers, or initiate or join a multimedia session, such as a Total Conversation session. 5.2 Detailed requirements for ToIP The following sections listslist individual requirements for ToIP. Each requirement has been given a uniquelyunique identifier (R1, R2, etc). Section 6 (Implementation Framework) describes how to implement ToIP based on these requirements and using existing protocols and techniques. The requirements are organized under the following headings: - session set-up and session control; - transport; - use of transcoding services; - presentation and user control; - interworking. 5.2.1 Session control andset-up and control requirements Users will set up a session by identifying the remote party or the service they want to connect to. However, conversationsConversations could be started using a mode other than the real-time text. Simultaneous or alternating use ofvoice and real-time text is used by a large number of userspeople 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 possible to start conversations in any mode (real- time text, voice, video) or combination of modes. R2: It MUST be possible for the users to switch to real-time text, or add real-time text as an additional modality, during the conversation. R3: Systems supporting ToIP MUST allow users to select any of the supported conversation modes at any time, including mid-conversation.in mid- conversation. R4: Systems SHOULD allow the user to specify a preferred mode of communication,communication in each direction, with the ability to fall back to alternatives that the user has indicated are acceptable. van Wijk, et al. Expires December 27, 2006 [Page 7] R5: If the user requests simultaneous use of real-time text and audio, and this is not possible either because the system only supports alternate modalities orbecause of constraints in the network, the system MUSTSHOULD try to establish communication with best effort.text only communication. R6: If the user has expressed a preference for real-time text, establishment of a connection including real-time text MUST have priority over other outcomes of the session setup. R7: It SHOULDMUST be possible to use thereal-time text medium in conference sessions in a similar way to how audio is handled and video is displayed. Real-time textin conferences can be usedboth for lettingas a medium of discussion between individual participants use the text medium(for example, for sidebar discussions in text while listening to the main conference audio), as well asaudio) and for central support of the conference with real time text interpretation of speech. R8: During session set up, it SHOULD be possible for the users to indicate if the caller wants to use voice and real-time text simutaneously as part of the conversation. R9:Session set up and negotiation of modalities mustMUST allow users to specify the language of the real-time text to be used. (It is recommendedRECOMMENDED that similar functionality isbe provided for the video part of the conversation, i.e. to specify the sign language being used). R9: Where certain session services are available for the 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 session. 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. R10: Characters must be transmitted soon after entry of each character so that the maximum delay requirement can be met. AAn end-to-end delay time of one second is regarded as good, while a delay of two seconds is possible to use. R11: Real-time text transmission from a terminal SHALL be performed character by character as entered, or in small groups of characters, so that no character is delayed from entry to transmission by more than 300 milliseconds. R12: It must be possible to transmit characters at a rate sufficient to support fast human typing as well as speech to textspeech-to-text methods of generating conversationconversational text. A rate of 2030 characters per second is regarded as sufficient. R12: aR13: A ToIP service must be able to deal with international character sets. R13:van Wijk, et al. Expires December 27, 2006 [Page 8] R14: Where it is possible, loss of real-time text during transport should be detected and the user should be informed. R14:R15: Transport of real-time text should be as robust as possible, so as to minimize loss of characters. R15: Where possible, it mustR16: It SHOULD be possible to send and receive real- timereal-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 terminalUser Agent 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. Some 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: text bridging after conversion from speech, audio bridging after conversion from real-time text, etc. A number of requirements, motivations and implementation guidelines for relay service invocation can be found in RFC 3351 . R16:R17: It MUST be possible for users to invoke a transcoding service where such service is available. R17:R18: It MUST be possible for users to indicate their preferred modality. R18: Themodality (e.g. ToIP). R19: It MUST be possible to negotiate the requirements for transcoding services need to be negotiatedin real-time to set up the session. R19: Adding or removingreal time in the process of setting up a relay servicecall. R20: It MUST be possible without disruptingto negotiate the current session. R20:requirements for transcoding services in mid-call, for the immediate addition of those services to the call. R21: Communication between the end participants SHOULD continue after the addition or removal of a text relay service, and the effect of the change should be limited in the users' perception to the direct effect of having or not having the transcoding service in the connection. R22: When setting up a session, it MUST be possible for a user to determinespecify the type of relay service requested (e.g., speech to text or text to speech). The specification of a type of relay MUST include a language specifier. R21:van Wijk, et al. Expires December 27, 2006 [Page 9] R23: It SHOULD be possible to route the session to a preferred relay service even if the user invokes the session from another region or network than that usually used. R24: It is RECOMMENDED that ToIP implementations make the invocation and use of relay services as easy as possible. 5.2.4 Presentation and User control requirements R22:A user should never be in doubt about the status of the session, even if the user is unable to make use of the audio or visual indication. For example, tactile indications could be used by deafblind individuals. R25: User Agents for ToIP services mustMUST have alerting methods (e.g., for incoming sessions) that can be used by deaf and hard of hearing people or provide a range of alternative, but equivalent, alerting methods that can be selected by all users, regardless of their abilities. R23:R26: Where real-time text is used in conjunction with other media, exposure of user control functions through the User 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 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 transferit must act on all media inbe possible for the session. R24:user to select between audio, visual or tactile prompts, or both must be supplied. R27: If present,available, identification of the originating party (for example in the form of a URL or a CLI) MUST be clearly presented to the user in a form suitable for the user BEFORE the session invitation is answered. R25:R28: 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 user. The ToIP client MAY adjust the presentation of the real-time text to the user as a consequence. R26:R29: An indication shouldSHOULD be given to the 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:R30: The user MUST be informed of any change in modalities. R28:R31: Users mustMUST be presented with appropriate session progress information at all times. R29: Answering machine functionsR32: Systems for ToIP SHOULD be provided by the User Agent. R30: When thesupport an answering machine function, equivalent to answering machines on telephony networks. R33: If an answering machine function is enabled onsupported, it MUST support at least 160 characters for the User Agent, alertinggreeting message. It MUST support incoming real-time text message 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. R34: When the answering machine is activated, user alerting SHOULD still take place. The user SHOULD be possibleallowed to monitor the auto- answer progress and userswhere this is provided the user SHOULD be ableallowed to take over control fromintervene during any stage of the answering machine function at any time. R31: Usersprocedure and take control of the session. R35: It SHOULD be ablepossible to save the text portion of a conversation. R32:R36: The presentation of the conversation shouldSHOULD be done in such a way that users can easily identify which party generated any given portion of text. R37: ToIP SHOULD handle characters such as new line, erasure and alerting during a session as specified in ITU-T T.140 . 5.2.5 Interworking requirements There is a range of existing real-time text services. There is also a range of network technologies that could support real-time text services. Real-time/InteractiveReal-time/interactive texting facilities exist already in various forms and on various networks. OnIn the PSTN, it isthey are commonly referred to as text telephony. Text gateways are used for converting between different media types.protocols for text conversation. They couldcan be used between networks or within networks where different transport technologies are used. R33:R38: ToIP SHOULD provide interoperability with text conversation features in other networks, for instance the PSTN. R34:R39: When communicating via a gateway to other networks and protocols, the ToIP service SHOULD support the functionality for alternating or simultaneous use of modalities as offered by the interworking network. R35: AddressR40: Calling party identification information, both called and calling, SHOULDsuch as CLI, MUST be transferred,passed by gateways and possibly converted, when interworking between different networks. R36:converted to an appropriate form if required. R41: When interworking with other networks and services, the ToIP service SHOULD provide buffering mechanisms to deal with delays in call setup, differences in transmission speeds and/or to interwork with half duplex services. 184.108.40.206 PSTN Interworking requirements Analog text telephony is being used in many countries, mainly by deaf, hard of hearing and speech-impaired individuals. R37:R42: ToIP services MUST provide interworking with PSTN legacy text telephony devices. R38:R43: 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)"). 220.127.116.11 Cellular Interworking requirements As mobile communications have been adopted widely, various solutions for real-time texting while on the move have beenwere 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 waswere 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 SHOULDshould be done using text gateways that set up the data channel connection at the GSM side and provide ToIP at the other side. R39:R44: a ToIP service SHOULD provide interworking with mobile text conversation services. 18.104.22.168 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-impaired users as defined in RFC 3351 . It is unsuitableless suitable 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. R39:R45: a ToIP service MAY provide interworking with Instant Messaging services. 6. Implementation Framework This section describes an implementation framework for ToIP that 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 generalGeneral implementation ToIP usesframework This framework specifies the use of the Session Initiation Protocol (SIP)  to set up, control and tear down the connections between ToIP users whilst the media is transported using the Real-Time Transport Protocol (RTP)  as described in RFC4103 . SIP  allows participantsRFC 4504 describes how to negotiate all media including real- time text conversation . This is a highly desirable functionimplement support for all IPinteractive text in SIP 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. Even for mainstream users, media negotiations like real- time text are also very useful in many circumstances as described earlier. The ability of SIP to set up conversation sessions from any location, as well as its privacy and security provisions, MUST be maintained by ToIP services. Real-time text conversation based on the presentation protocol T.140 , in addition to audio and 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. 6.2 Framework of detailed implementation 6.2.1 Session control and set-up ToIP services MUSTdevices . 6.2 Detailed implementation framework 6.2.1 Session control and set-up ToIP services MUST use the Session Initiation Protocol (SIP)  for setting up, controlling and terminating sessions for real-time text 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. SIP  allows participants to negotiate all media including real-time text conversation . ToIP services can provide the ability to set up conversation sessions from any location as well as provision for privacy and security through the application of standard SIP techniques. 22.214.171.124 Pre-session setupset-up The requirements of the user to be reached at a consistent address and to store preferences for evaluation at session setup are met by pre-sessionpre- session setup actions. That includes storing of registration information in the SIP registrar, to provide information about how a user can be contacted. This will allow sessions to be set up rapidly 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 support 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.Thesession. The actions taken can be based on the called userísusers 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 should be re-directed or otherwise handled accordingly. 126.96.36.199 Basic Point-to-Point Session setupThe ability to include a transcoding service MUST NOT require user registration in any specific SIP registrar, but MAY require authorisation of the SIP registrar to invoke the service. A point-to-point session takes place between two parties. For 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. The following features MAY be implemented to facilitate the session establishment using ToIP: a. Caller Preferences: SIP headers (e.g., Contact)Contact)  can be used to show that ToIPreal-time text is the medium of choice for communications. b. Called Party Preferences : The called party being passive can formulate a clear rule indicating how a session should be handled either using real-time text as a preferred medium or not, and whether a designated SIP proxy needs to handle this session or it will be handled in the SIP user agent. c. SIP Server support for User Preferences: It is RECOMMENDED that SIP servers also handle the incoming 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 transcoding server for ToIP). 188.8.131.52 Addressing The SIP  addressing schemes MUST 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). 184.108.40.206.2.1.2 Session Negotiations The Session Description Protocol (SDP) used in SIP  provides the capabilities to indicate real-time text as a medium in the session setup. RFC 4103  uses the RTP payload types "text/red" and "text/t140" for support of ToIP which can be indicated in the SDP as a part of the SIP INVITE, OK and SIP/200/ACK media negotiations. In addition, SIPísSIPs offer/answer model  can also be used in conjunction with other capabilities including the use of a transcoding server for enhanced session negotiations [14,15,16]. Systems SHOULD provide a best-effort approach6.2.2 Transport ToIP services MUST support the Real-Time Transport Protocol (RTP)  according to answering invitationsthe specification of RFC4103  for session set-up and users SHOULD be informed whenthe session is accepted bytransport of text between participants. RFC4103 describes the other party. On all systems that both inform users of session status and support ToIP, this information MUST be available in textual form and MAY also be provided in other media. 220.127.116.11 Additional session control Systems that support additional session control features, for example call waiting, forwarding, hold etc on voice sessions, MUST offer 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 the specification of RFC4103  for the transport of text between participants. RFC4103 describes the transmissiontransmission of T.140  real-time text on IP networks. In order to enable the use of international character sets, the transmission format for text conversation SHALL be UTF-8 , in accordance with ITU-T T.140. If real-time text is detected to be missing after transmission, there SHOULD be a "text loss" indication in the real-time text as specified in T.140 Addendum 1 . ToIP uses RTP as the default transport protocol for the transmission of real-time text via the medium "text/t140" as specified in RFC 4103 .The redundancy method of RFC 4103  SHOULD be used to significantly increase the reliability of the real-time text transmission. A redundancy level using 2 generations gives very reliable results and is therefore strongly RECOMMENDED. Real-time text capability MUST beis announced in SDP by a declaration 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 transmission scheme for real time text defined in the SIP session control environment, the opportunity for interoperability is optimized. However, if good reasons exist, other transport mechanisms MAY be offered and used for the T.140 coded text provided that proper negotiation is introduced, but RFC 4103  transport MUST be used as both the default and the fallback transport. Real-time text transmission from a terminal SHALL be performed character by character as entered, or in small groups of characters, so that no character is delayed from entry to transmission by more than 300 milliseconds. The text transmission SHALL allow a rate of at least 30 characters per second.6.2.3 Transcoding services The right to includeInvokation of a transcoding service MUST NOT require user registration in any specific SIP registrar, butMAY require authorisation of the SIP registrar to invokehappen automatically when the service. A specific typesession is being set up based on any valid indication or negotiation of supported or preferred media types. A transcoding service in a ToIP environment is aframework document using SIP  describes invoking relay service. The relay service acts as an intermediary between two or more callers using different media or different media encoding schemes. The basic text relay service allows a translation of speech to real- time text and real-time text to speech, which enables hearing and speech impaired callers to communicate with hearing callers. Even though this document focuses on ToIP, we want to remind readers that other relay services exist, like video relay services transcoding speech to sign language and vice versa where the signing is communicated using video. It is RECOMMENDED that ToIP implementations make the invocation and use of relay services as easy as possible. It MAY happen automatically when the session is 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 theservices, where the relay acts as a conference bridge or uses the third party control mechanism. ToIP implementations SHOULD support this transcoding framework. 6.2.4 Presentation and User control functions 18.104.22.168 Progress and status information During a conversation that includes ToIP, status and session progress information MUST be provided in a textual form so users can perform all session control functions. That information MUST be equivalent to session progress information delivered in any other format, for example audio.Session progress information SHOULD use simple language so that as many users as possible can understand it. The use of jargon or ambiguous terminology SHOULD be avoided. It is RECOMMENDED that text information be used together with icons to symbolise the session progress information. There MUST be a clear indication, in a modality useful to the user, whenever a session is connected or disconnected. A user SHOULD never be in doubt about the status of the session, even if the user is unable to make use of 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 - Availability of real-time text, voice and video channels - Session progress - Incoming real-time text - Any loss in incoming real-time text - Typed and transmitted real-time text. 22.214.171.124 Alerting For users who cannot use the audible alerter for incoming sessions, it is RECOMMENDED to include a tactile as well as a visual indicator. Among the alerting options are alerting by the User AgentísAgents User Interface and specific alerting user agents registered to the same registrar as the main user agent. It should be noted that external alerting systems exist and one common interface for triggering the alerting action is a contact closure between two conductors. 126.96.36.199 Answering Machine Systems for ToIP MAY support an answering machine function, equivalentText presentation Requirement R32 requires that, in the display of text conversation, users be able to answering machines on telephony networks. If an answering machine function is supported, it MUST support at least 160 characters fordistinguish easily between different speakers. This could be done using color, positioning of the greeting message. It MUST supporttext (i.e. incoming real- time text message 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 answering machine is activated, user alerting SHOULD still take place. The user SHOULD be allowed to monitor the auto-answer progress and where this is provided the user SHOULD be allowed to intervene during any stage of the answering machine procedure and take control of the session. 188.8.131.52 Text presentation When the display of text conversation is included in the design of the end user equipment, the display of the dialogue SHOULD be made so that it is easy to differentiate the text belonging to each party in the conversation. This could be done using color, positioning of the text (i.e. incoming real-timereal-time text and outgoing real-time text in different display areas), by in-band identifiers of the parties or by a combination of any of these techniques. ToIP SHOULD handle characters such as new line, erasure and alerting during a session as specified in ITU-T T.140 . 184.108.40.206.2.4.4 File storage SystemsRequirement R31 recommends that supportToIP MAY savesystems allow the text conversationuser to a file.save text conversations. This SHOULDshould be done using a standard file format. For example: a UTF8 text file in XHTML format  including timestamps, party names (or addresses) and the text conversation. 6.2.5 Interworking functions A number of systems for real time text conversation already exist as well as a number of message oriented text communication systems. Interoperability is of interest between ToIP and some of these systems. Interoperation of half-duplex and full-duplex protocols, and between protocols MAYthat have different data rates, 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 at the "protocol" level (where an indication must be sent back to the 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 sequencesBuffering schemes should be dimensioned to adjust for the differentreceiving at 30 characters per second and transmitting at 6 characters per second for up to 4 minutes (i.e. less than 3000 characters). When converting between simultaneous voice and text on the IP side, and alternating voice and text protocols. The modem type identification may in rare cases take considerable time dependingon the other side of a gateway, a conflict can occur if the IP user actions. To resolve analog textphone incompatibilities,transmits both audio and text at the same time. In such situations, text transmission SHOULD have precedence, so that while text is transmitted, audio is lost. Transcoding of text telephone gateways are neededto transcode incoming analog signals into T.140and vice versa. The modem capability exchange time can be reduced by thefrom other coding formats may need to take place in gateways between ToIP and other forms of text telephoneconversation, for example to connect to a PSTN text telephone. Session set-up through gateways initially assumingto other networks may require the analoguse of specially formatted addresses or other mechanisms for invoking those gateways. ToIP interworking requires a method to invoke a text telephone protocol used ingateway. These text gateways act as User Agents at the region whereIP side. The capabilities of the gateway is located. For example, induring the USA, Baudot [II] mightcall will be tried asdetermined by the initial protocol. If negotiation for Baudot fails,call capabilities of the full V.18 modem capability exchange will take place. Interminal that is using the UK, ITU-T V.21 [III] might begateway. For example, a PSTN textphone is generally only able to receive voice and real-time text, so the first choice. In particular transmissiongateway will only allow ToIP and audio. Examples of interactivepossible scenarios for invocation of the text ongateway are: a. PSTN networks takes place usingtextphone users dial a 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 result of this variety inprefix number before dialing out. b. Separate real-time text telephony protocols andsubscriptions, linked to the ITU-Tphone number or terminal identifier/ IP address. c. Real-time text capability indicators. d. Real-time text preference indicator. e. Listen for V.18  standard was developed to address somemodem modulation text activity in all PSTN calls and routing of these issues. ITU-T V.18  offersthe call to an appropriate gateway. f. Call transfer request by the called user. g. Placing a native text telephony method plus it defines interworking with current protocols. Incall via the interworking mode, it will recogniseweb, and using one of the older protocols and fall back to that transmission method when required.methods described here h. Text gateways MUST use the ITU-T V.18  standard atwith its own telephone number and/or SIP address. (This requires user interaction with the PSTN side. A textgateway MUST act asto place a SIP User Agent on the IP side and support RFC4103 text transport. PSTN-ToIP gateways MUST allow alternating use of real-time textcall). i. ENUM address analysis and voice if thenumber plan j. Number or address analysis leads to a gateway for all PSTN textphone involved at thecalls. 18.104.22.168 PSTN side of 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. While ToIP allows receiving and sending real-timeInterworking Analog text simultaneously and is displayed on a split screen, many analog text telephones require users to take turns typing. Thistelephony is cumbersome because many text telephones operate strictly half duplex. Only one can transmitof 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 at a time.protocols. The users apply strict turn- taking rules. There are several text telephones which communicatemodem type identification may in full duplex, but merge transmittedrare 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 receivedvice versa. The modem capability exchange time can be reduced by the text telephone gateways initially assuming the analog text telephone protocol used in the same lineregion where the gateway is located. For example, in the same display window. And also here doUSA, Baudot [II] might be tried as the users apply strict turn taking rules. Native V.18 text telephones support full duplex and separate display from reception and transmission so thatinitial protocol. If negotiation for Baudot fails, the full duplexV.18 modem capability canexchange will take place. In the UK, ITU-T V.21 [III] might be used fully. Such devices could usethe ToIP split screen as well, but almost allfirst choice. In particular transmission of interactive text telephones useon PSTN networks takes place using a restricted character setvariety of codings and many use low text transmission speeds (4 to 7 charcters per second). That is why it is important for the ToIP user to know that he or she is connected with an analog text telephone. The "txp" media content attribute SHOULD be used to indicate that the call originates from a PSTN text telephone (e.g. via an ATA or a text gateway). 22.214.171.124 Mobile Interworking Mobile wireless (or Cellular) circuit switched connections provide a digital 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 the Internet. The following sections describe how mobile text telephony is supported. 126.96.36.199.1 Cellular "No-gain" The "No-gain" text telephone transporting technology uses specially modified EFR modulations, including ITU-T V.21 [III], Baudot [II], DTMF, V.23 [IV] and EVR  speech vocoders in mobile terminals used to provideothers. Many difficulties have arisen as a result of this variety in text telephony call. It provides full duplex operation and supports alternating voice and text ("VCO/HCO"). It is dedicated to CDMA and TDMA mobile technologiesprotocols and the US Baudot (i.e. 45 bit/s) typeITU-T V.18  standard was developed to address some of text telephones. 188.8.131.52.2 Cellular Text Telephone Modem (CTM) CTM  isthese issues. ITU-T V.18  offers a technology independent modem technology that provides the transport ofnative text telephone characters at up to 10 characters/sec using modem signals that can be carried by many voice codecs and uses a highly redundant encoding technique to overcome the fading and cell changing losses. 184.108.40.206.3 Cellular "Baudot mode" This term is often used by cellular terminal suppliers for a GSM cellular phone mode that allows TTYs to operate into a cellular phone and to communicate with a fixed line TTY. Thustelephony method plus it is a common name for the "No-Gain" and the CTM solutions when applied to the Baudot type textphones. 220.127.116.11.4 Mobile data channel mode Many mobile terminals allowdefines interworking with current protocols. In the useinterworking mode, it will recognise one of the circuit switched data channelolder protocols and fall back to transfer data in real-time. Data rates of 9600 bit/s are usually supported on the 2G mobile network. Gateways provide interoperability with PSTN textphones. 18.104.22.168.5 Mobile ToIP ToIP could be supported over mobile wireless packet switched servicesthat interface to the Internet. For 3GPP 3G services, ToIP support is described in 3G TS 26.235 . 22.214.171.124 Instant Messaging Interworkingtransmission method when required. Text gateways MAY be used 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 like ToIP, gatewaysMUST transcode betweenuse the two formats. Text gateways for interworking between Instant Messaging and ToIPITU-T V.18  standard at the PSTN side. A text gateway MUST applyact as a procedure for bridgingSIP User Agent on the different conversational formats ofIP side and support RFC4103 text transport. While ToIP allows receiving and sending real-time text versussimultaneously and is displayed on a split screen, many analog text messaging.telephones require users to take turns typing. This is because many text telephones operate strictly half duplex. Only one can transmit text at a time. The following advice may improve user experience for both partiesusers apply strict turn-taking rules. There are several text telephones which communicate in full duplex, but merge transmitted text and received text in a call through a messaging gateway. a. Concatenate individual characters originating at the ToIP side into blocks of text. b. Whenthe length ofsame line in the concatenated message becomes longer than 50 characters,same display window. And also here do the bufferedusers apply strict turn taking rules. Native V.18 text SHOULDtelephones support full duplex and separate display from reception and transmission so that the full duplex capability can be transmitted toused fully. Such devices could use the Instant Messaging side as soonToIP split screen as any non-alphanumericalwell, but almost all text telephones use a restricted character set and many use low text transmission speeds (4 to 7 characters per second). That is received from the ToIP side. c. When a new line indicatorwhy it is received fromimportant for the ToIP side, the buffered characters upuser to know that point, including the carriage return and/or line feed characters, SHOULD be transmitted to the Instant Messaging side. d. When the ToIP side has been idle for at least 5 seconds, all bufferedhe or she is connected with an analog text up to that pointtelephone. The "txp" media content attribute  SHOULD be transmitted to the Instant Messaging side. e. Text Gateways must be capableused to maintainindicate that the call originates from a PSTN text telephone (e.g. via an ATA or a text gateway). 126.96.36.199 Mobile Interworking Mobile wireless (or Cellular) circuit switched connections provide a digital real-time performancetransport service for voice or data. The access technologies include GSM, CDMA, TDMA, iDen and various 3G technologies. ToIP while providingmay be supported over the interworking services.cellular wireless packet switched service. It is RECOMMENDED that during the session, both users are constantly updated on the progress ofinterfaces to the Internet. The following sections describe how mobile text input. Many Instant Messaging protocols signal that a usertelephony is typing to the other party in the conversation. Text gateways between such Instant Messaging protocolssupported. 188.8.131.52.1 Cellular "No-gain" The "No-gain" text telephone transporting technology uses specially modified EFR  and ToIP MUST provide this signalingEVR  speech vocoders in mobile terminals used 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 protocolprovide a text telephony call. It provides one. For example, the real-timefull duplex operation and supports alternating voice and text user MAY see ". . . waiting for replying IM. . . "("VCO/HCO"). It is dedicated to CDMA and when 5 seconds have passed another . (dot) can be shown. Those solutions will reduce the difficulties between streamingTDMA mobile technologies and blockedthe US Baudot (i.e. 45 bit/s) type of text services. Even thoughtelephones. 184.108.40.206.2 Cellular Text Telephone Modem (CTM) CTM  is a technology independent modem technology that provides the transport of text gatewaytelephone characters at up to 10 characters/sec using modem signals that can connect Instant Messagingbe carried by many voice codecs and ToIP, the best solution isuses a highly redundant encoding technique to take advantage of the fact thatovercome the user interfacesfading and the user communitiescell changing losses. 220.127.116.11.3 Cellular "Baudot mode" This term is often used by cellular terminal suppliers for instant messaginga cellular phone mode that allows TTYs to operate into a cellular phone and ToIP telephony are very similar. After all, the character input,to communicate with a fixed line TTY. Thus it is a common name for the character display, Internet connectivity"No-Gain" and SIP stack can bethe same for Instant Messaging (SIMPLE) and ToIP. Thus,CTM solutions when applied to the Baudot type textphones. 18.104.22.168.4 Mobile data channel mode Many mobile terminals allow the user may simplyuse different applications for ToIP and text messagingof the circuit switched data channel to transfer data in real-time. Data rates of 9600 bit/s are usually supported on the same terminal. Devices2G mobile network. Gateways provide interoperability with PSTN textphones. 22.214.171.124.5 Mobile ToIP ToIP could be supported over mobile wireless packet switched services that implement Instant Messaging SHOULD implementinterface to the Internet. For 3GPP 3G services, ToIP assupport is described in this document so that a more complete text communication service can be provided. 126.96.36.199G TS 26.235 . 188.8.131.52 Instant Messaging Interworking throughText gateways Transcoding of text to and from other coding formatsMAY needbe used to take place in gatewaysallow interworking between ToIPInstant Messaging systems and other formsToIP solutions. Because Instant Messaging is based on blocks of text conversation, for example to connect totext, rather than on a PSTN text telephone.continuous stream of characters like ToIP, gateways MUST transcode between the two formats. Text gateways for interworking between Instant Messaging and ToIP MUST allowapply a procedure for bridging the differences that result fromdifferent conversational formats of real-time text protocols.versus text messaging. The protocols to be supported will depend on the service requirements of the Gateway. Session setupfollowing advice may improve user experience for both parties in a call through gateways to other networks MAY requirea messaging gateway. a. Concatenate individual characters originating at the use of specially formatted addresses or other mechanisms for invoking those gateways. Different data ratesToIP side into blocks of different protocols MAY require text buffering.text. b. When the length of the concatenated message becomes longer than 50 characters, the buffered text gateway functions are invoked, there willSHOULD be a need for intermediate storage of characters before transmissiontransmitted to the Instant Messaging side as soon as any non-alphanumerical character is received from the ToIP side. c. When a device receiving text slower thannew line indicator is received from the transmitting speed ofToIP side, the sender. Such temporary storage SHALLbuffered characters up to that point, including the carriage return and/or line feed characters, SHOULD be dimensionedtransmitted to adjust for receiving at 30 characters per second and transmitting at 6 characters per secondthe Instant Messaging side. d. When the ToIP side has been idle for at least 5 seconds, all buffered text up to 4 minutes (i.e. less than 3000 characters). ToIP interworking requires a methodthat point SHOULD be transmitted to invoke a text gateway. As described previously, these text gateways MUST act as User Agents atthe IPInstant Messaging side. The capabilities ofe. Text Gateways must be capable to maintain the gatewayreal-time performance for ToIP while providing the interworking services. It is RECOMMENDED that during the call willsession, both users be determined byconstantly updated on the call capabilitiesprogress of the terminaltext input. Many Instant Messaging protocols signal that is using the gateway. For example,a PSTN textphoneuser is generally only abletyping to receive voice and real-time text, sothe gateway will only allow ToIPother party in the conversation. Text gateways between such Instant Messaging protocols and audio. ExamplesToIP MUST provide this signalling to the Instant Messaging side when characters start being received, or at the beginning of possible scenarios for invocationthe 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 text gateway are: a. PSTN textphone users dial a prefix number before dialing out. b. Separatereal-time text subscriptions, linked touser MAY see ". . . waiting for replying IM. . . " and when 5 seconds have passed another . (dot) can be shown. Those solutions will reduce the phone number or terminal identifier/ IP address. c. Real-time text capability indicators. d. Real-timedifficulties between streaming and blocked text preference indicator. e. Listen for V.18 modem modulationservices. Even though the text activity in all PSTN callsgateway can connect Instant Messaging and routing ofToIP, the callbest solution is to an appropriate gateway. f. Call transfer request bytake advantage of the called user. g. Placing a call viafact that the web,user interfaces and using one ofthe methods described here h. Text gateways with its own telephone number and/or SIP address. (This requiresuser interaction withcommunities for instant messaging and ToIP telephony are very similar. After all, the gateway to place a call). i. ENUM address analysischaracter input, the character display, Internet connectivity and number plan j. Number or address analysis leads to a gatewaySIP stack can be the same for all PSTN calls. 184.108.40.206Instant 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. 220.127.116.11 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 MUSTcould provide interworking between all of their supported text based functions. For example, a Text gateway that has modems to interwork with the PSTN and that support both Instant Messaging and ToIP MUSTcould support the following interworking functions: - PSTN text telephony to ToIP. - PSTN text telephony to Instant Messaging. - Instant Messaging to ToIP. 18.104.22.168.2.5.5 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, where this character exists. For legacy systems where the ' character Ďdoes not exist, the . (full stop) character SHOULD be used instead. 7. Further recommendations for implementers and service providers 7.1 Access to Emergency services It MUSTmust be possible to place an emergency call using ToIP and it MUSTmust be possible to use a relay service in such call. The emergency service provided to users utilising the real-time text medium MUSTmust be equivalent to the emergency service provided to users utilising speech or other media. A text gateway MUSTmust be able to route real-time 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 real-time text calls to emergency services MAYmay require the use of a transcoding service. A text gateway with cellular wireless packet switched services MUSTmust be able to route real-time text calls to emergency service providers when any of the recognized emergency numbers that support real-time text communication for the country is called. 7.2 Home Gateways or Analog Terminal Adapters Analog terminal adapters (ATA) 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. If a session is set up and text/t140 capability is not declared by the destination endpoint (by the end-point terminal or the 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 a text gateway. Sending textphone signals over the voice channel is undesirable due to possible filtering and compression and packet loss between the end-points. This can result in character loss in the textphone conversation or even not allowing the textphones to connect to each other. 7.3 User Mobility ToIP User Agents SHOULD use the same mechanisms as other SIP User Agents to resolve mobility issues. It 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. 7.4 Firewalls and NATs ToIP uses the same signalingsignalling and transport protocols as VoIP. Hence, the same firewall and NAT solutions and network functionality that 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 ToIP user might be a person with a hearing or speech impairment. ToIP is after all a mainstream communication medium for all users. It is up to the ToIP user to make his or her hearing or speech impairment public. If a transcoding server is being 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. 10. AuthorsíAuthors' Addresses The following people provided substantial technical and writing contributions to this document, listed alphabetically: Willem Dijkstra TNO Informatie- en Communicatietechnologie Eemsgolaan 3 9727 DW Groningen tel : +31 50 585 77 24 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.comGuido Gybels Department of New Technologies RNID, 19-23 Featherstone Street London EC1Y 8SL, UK Tel +44(0)20 7294+44-20-7294 3713 Txt +44(0)20 7608+44-20-7608 0511 Fax +44(0)20 7296+44-20-7296 8069 Email: firstname.lastname@example.org 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: email@example.com 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: firstname.lastname@example.orgArnoud A. T. van Wijk Foundation for an Information and Communication Network for the Deaf and Hard of Hearing "AnnieS" www.annies.nlhttp://www.annies.nl/ Email: email@example.com 11. Contributors The following people contributed to preliminary drafts of this document: Willem Dijkstra, Barry Dingle, Gunnar Hellstrom, Radhika R. Roy, Henry Sinnreich and Gregg C Vanderheiden. The content and concepts within are a product of the SIPPING Working Group. Tom Taylor (Nortel) acted as independent reviewer and contributed significantly to the structure and content of this document. 12. References 11.112.1 Normative references 1. S. Bradner, "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, IETF, March 2005. 2. Charlton, Gasson, Gybels, Spanner, van Wijk, "User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals", RFC 3351, IETF, August 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 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). 10. J. Hautakorpi, G. 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 3840, IETF, August 2004 12. J. Rosenberg, H. Schulzrinne, P. 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 (SDP)", RFC 3624, IETF, June 2002. 14. G. Camarillo, "Framework for Transcoding with the Session Initiation Protocol" IETF Nov 2005 - Work in progress. 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. 16. G. Camarillo, "The SIP Conference Bridge Transcoding Model," IETF, JanJanuary 2006 - Work in Progress. 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. 19. ITU-T Recommendation V.18,"Operational and Interworking Requirements for DCEs operating in Text Telephone Mode,"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)" 21. TIA/EIA/IS-127-2 "Enhanced Variable Rate Codec, Speech Service Option 3 for Wideband Spread Spectrum Digital Systems. Addendum 2." 22. "IP Multimedia default codecs". 3GPP TS 26.235 23. H. Sinnreich, S. Lass, and C. Stredicke, "SIP" SIP Telephony Device Requirements and Configuration,"Configuration" RFC 4504, IETF, October 2005 - Work in Progress.May 2006. 24. Baugher, McGrew, Carrara, Naslund, Norrman, "The Secure Real Time Transport Protocol (SRTP)", RFC 3711, IETF, March 2004. 25. ITU-T Recommendation F.700,"Framework Recommendation for Multimedia Services", November 2000. 11.212.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. 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.) 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- TITU-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 The 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 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 ietf- firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).