Internet Engineering Task Force
       SIPPING WG
       Internet Draft
       Document: <draft-ietf-sipping-toip-01.txt> Workgroup                               A. van Wijk (editor)
       July 18 2005
       Internet-Draft                                  Viataal
       Category: Informational
       Expires: January 17 February 21 2006
       Informational                       August 22 2005

        Framework of requirements for real-time text conversation using SIP. SIP

                           draft-ietf-sipping-toip-02.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
          [1].

          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 January 17, February 21, 2006.

       Copyright Notice

          Copyright (C) The Internet Society (2005).

       Abstract

          This document provides the framework of requirements for real-time
          character-by-character interactive text conversation over the IP
          network using the Session Initiation Protocol and the Transport
          Protocol for Real-Time Applications.
          Transport Protocol. It discusses requirements for real-time Text-over-IP telephony Text-
          over-IP as well as interworking between Text-over-IP telephony and existing
          text telephony on the PSTN and other networks.

       A. van Wijk Wijk, et al.     Expires 21 February 2006      [Page 1 of 28]
       Table of Contents

       1. Introduction                                              3 Introduction.....................................................3
       2. Scope                                                     3 Scope............................................................4
       3. Terminology                                               3 Terminology......................................................4
       4. Definitions                                               4 Definitions......................................................4
       5. Framework Description                                     5 Description............................................6
       5.1. Background                                              5
          5.2. Requirements General requirements for ToIP..................................6
       5.1.1 General ToIP                                   6
          5.3. Use of SIP and RTP                                      6
          5.4. Summary..........................................8
       5.2. General Requirements for ToIP Interworking                      9 Interworking.....................8
       5.2.1 PSTN Interworking.............................................9
       5.2.2 Cellular circuit switched Text-Telephony.....................10
       5.2.2.1 Cellular "No-gain".........................................10
       5.2.2.2 Cellular Text Telephone Modem (CTM)........................10
       5.2.2.3 Cellular "Baudot mode".....................................11
       5.2.3 Cellular data channel mode...................................11
       5.2.4 Cellular Wireless ToIP.......................................11
       5.2.5 Instant Messaging Support....................................11
       6. Detailed requirements for Text-over-IP                    9 ToIP..................................11
       6.1. Pre-Call Requirements                                   10 Pre-Session Requirements......................................12
       6.2 Basic Point-to-Point Call Requirements                   10 Session Requirements......................12
       6.2.1 Session Setup                                          10 control..............................................12
       6.2.2 Addressing                                             11 Text transport...............................................12
       6.2.3 Alerting and session progress presentation             11 Session Setup................................................13
       6.2.4 Call Negotiations                                      12 Addressing...................................................13
       6.2.5 Answering                                              12 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
       6.2.9.1 Answering Machine..........................................15
       6.2.10 Actions During Calls                                   13
          6.2.7 a Session....................................15
       6.2.10.1 Text Transport............................................16
       6.2.10.2 Handling Text and other Media.............................16
       6.2.11 Additional session control                             14
          6.2.8 control..................................17
       6.2.12 File storage                                           15 storage................................................17
       6.3 Conference Call Requirements for ToIP User Agents        15 Session Requirements................................17
       6.4 Transport via RTP                                        15 Real-time Editing and User Alerting............................17
       6.5 Character Set                                            16
          6.6 Transcoding                                              16
          6.7 Relay Services                                           16
          6.8 Emergency services                                       17
          6.9 services.............................................17
       6.6 User Mobility                                            17
          6.10 Confidentiality Mobility..................................................18
       6.7 Firewalls and Security                            17 NATs.............................................18
       7. Interworking Requirements for ToIP                        17 ToIP..............................18
       7.1 ToIP Interworking Gateway Services                       17 Services.............................18
       7.2 ToIP and PSTN/ISDN Text-Telephony                        18 Interworking.................18
       7.3 ToIP and Cellular Wireless circuit switched Text-Telephony
                                                                       18
          7.3.1 "No-gain"                                              19
          7.3.2 Cellular Text Telephone Modem (CTM)                    19
          7.3.3 "Baudot mode"                                          19
          7.3.4 Data channel mode                                      19
          7.3.5 Common Text Gateway Functions                          19 ToIP................................19
       7.4 ToIP and Cellular Wireless ToIP                          20
          7.5 Instant Messaging Support                                20 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 calls through gateways.............................21
       7.5.4 Text Gateway Invocation......................................21
       7.6 IP Telephony with Traditional RJ-11 Interfaces           21 Home Gateways or Analog Terminal Adapters......................21
       7.7 Multi-functional gateways                                22
          7.8 ToIP interoperability with PSTN text telephones.         22
          7.9 Gateway Discovery                                        22
          8. Afterword                                                 23
          9. Security Considerations                                   23
          10. Authors Addresses                                        24
          11. References                                               25
          11.1 Normative                                               25
          11.2 Informative                                             27 Combination gateways..........................22

       A. van Wijk Wijk, et al.     Expires 21 February 2006      [Page 2 of 28]
       1. Introduction

          For many
       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.................................23
       8. Security Considerations.........................................23
       9. Authors Addresses...............................................24
       10. References.....................................................25
       10.1 Normative references..........................................25
       10.2 Informative references........................................27

       1. Introduction

          For many years, text has been in use as a medium for
          conversational, interactive dialogue between users in a similar
          way as 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 that who cannot, or do not wish to, use voice. It
          therefore meets a different set of requirements than from other text-
          based solutions already available on IP networks.

          Traditionally, deaf, hard of hearing and speech-impaired people
          are amongst the most proliferate prolific users of conversational, interactive text, but
          text but, because of its interactivity, it is becoming popular
          amongst mainstream user groups 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)
          environments, as well as meeting the userĂs requirements,
          including those of deaf, hard of hearing and speech-impaired users
          as described in RFC3351 [21]. [19].

          The Session Initiation Protocol (SIP) is the protocol of choice
          for control of Multimedia IP telephony communications and Voice-over-IP (VoIP)
          communications.
          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 interactive text
          payloads is described in RFC4103 [5].

          This document defines a framework for ToIP to be used either by
          itself or as part of integrated integrated, multi-media services, including
          Total Conversation.

       A. van Wijk, et al.     Expires 21 February 2006      [Page 3 of 28]
       2. Scope

          The primary scope of this

          This document is to define defines a framework for the implementation of real-
          time ToIP, either stand-alone or as a part of
          wider multimedia services,
          including Total Conversation. In general, the
          scope is: It defines the:

             a. Requirements of Real-time, interactive text;
             b. Requirements for ToIP interworking;
             c. Description of ToIP using SIP and RTP;
          b. Requirements
             d. Description of Real-time, interactive text;
          c. Requirements for ToIP interworking.

          The subsequent sections describe those requirements in detail. 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 [2] and indicate requirement levels
          for compliant implementations.

       A. van Wijk                                           [Page 3 of 28]

       4. Definitions

          Audio bridging - a function of a gateway or relay service that
          enables an audio path through the service between the users
          involved in the call.

          Cellular - Telephone systems based on radio transmission to become
          wireless. Also called Wireless or Mobile systems.

          Full duplex - media is sent independently in both directions.

          Half 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.

          TTY ű alternative designation for a text telephone, often used in
          USA, see textphone. Also called TDD, Telecommunication Device for
          the Deaf.

          Textphone ű also ˘text telephone÷. "text telephone". A terminal device that allows
          end-to-end real-time, interactive text communication. communication using analog
          transmission. A variety of PSTN textphone protocols exists world-wide, both in the PSTN and other
          networks. 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 a gateway service that enables the
          flow of text through the service between the users involved in the
          call.

          Text gateway - a multi functional gateway function that is able to
          transcode 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.

          Text telephony ű analog textphone services

       A. van Wijk, et al.     Expires 21 February 2006      [Page 4 of 28]
          Text Relay 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
          text in a call.

          Text telephony ű analog textphone service.

          Total Conversation - a multimedia service offering real time
          conversation in video, text and voice according to interoperable
          standards. All media flow in real time. (See ITU-T F.703
          "Multimedia conversational services".)

          Transcoding 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 text and audio.

          Total Conversation

          TTY ű alternative designation for a text telephone or textphone,
          often used in USA. Also called TDD, Telecommunication Device for
          the Deaf.

          Video Relay Service - A multimedia service offering real time
          conversation in video, text and voice according to interoperable
          standards. All media flow in real time. Further defined in ITU-T
          F.703 Multimedia conversational services description.

       A. van Wijk                                           [Page 4 of 28]
          Video Relay Service - A service that enables communications
          between deaf 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
                 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   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 21 February 2006      [Page 5 of 28]
       5. Framework Description

       5.1. Background

          The main purpose of this document is to provide a

          This framework
          description for defines the implementation requirements of real-time, interactive a text-based
          conversational service that is the text equivalent of voice based
          telephony. Real-time text conversation can be combined with other
          conversational services over like video or voice.

          ToIP also offers an IP networks, known equivalent of analog text telephony
          services as Text-
          over-IP (ToIP). used by deaf, hard of hearing and speech-impaired
          individuals.

          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 takes 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. In
          particular, the ToIP framework It
          uses the Session Initiation Protocol (SIP) [3] to set up, control and
          tear down the connections between users.
          Media users whilst the media is
          transported using the Real-Time Transport Protocol (RTP)
          in the manner as
          described in RFC4103. RFC4103 [5].

          This framework allows for implementation of services that is designed to meet the
          requirement requirements of providing RFC3351
          [19]. As such, it offers a text-based standardized way for offering text-
          based, conversational service, services that can be used as an equivalent
          to voice based telephony. In particular, ToIP offers an
          IP equivalent of text telephony services as used by deaf, hard of hearing and speech-impaired
          individuals.
          In addition, real-time text conversations can be combined with
          other conversational services using different media like video or
          voice.
          By using SIP, ToIP

          SIP allows participants to negotiate all media including real-time
          text conversation[4, 5]. conversation [4,5]. This is a highly desirable function for
          all IP telephony users, 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.
          It is important to understand that real-time text conversations
          are significantly different from other text-based communications

       A. van Wijk                                           [Page 5 of 28]
          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 takes place, thus providing 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.

       5.2. Requirements

       5.1. General requirements for ToIP

          In order to make ToIP the text equivalent of what voice is to hearing
          people, services, it
          needs to offer equivalent features in terms of conversationality
          as voice telephony provides to hearing people. provides. To achieve that, ToIP MUST: needs to:

             a. Offer real-time presentation of the conversation;
             b. Provide simultaneous transmission in both directions;
             c. Provide interoperability with text conversation features in
          other networks, for instance the PSTN, accepting functional
          limitations that will occur during interoperation. Support both point-to-point and multipoint communication;

       A. van Wijk, et al.     Expires 21 February 2006      [Page 6 of 28]
             d. Not prevent Allow other media, like audio and video, to be used in
               conjunction with ToIP. ToIP;
             e. Ensure that the text service is always available.

          Real-time text is a useful subset of Total Conversation defined in
          ITU-T F.703 [23]. Users might want to could use multiple modes of communication
          during the conversation, either at the same time or by switching
          between modes, e.g., between text and audio for example. Native audio.

          Users may invoke ToIP services MUST ensure that the text interface is always available.

          When communicating via for many different reasons:

          - Because they are in a gateway to other networks noisy environment, e.g., in a machine room
            of a factory where listening is difficult.
          - Because they are busy with another call and protocols,
          the service SHOULD support all want to participate
            in two calls at the functionality same time.
          - For implementing text and/or speech recording services (e.g.,
            text documentation/ audio recording for alternating
          or simultaneous use
            legal/clarity/flexibility purposes).
          - To overcome language barriers through speech translation and/or
            transcoding services.
          - Because of modalities hearing loss, deafness or tinnitus as offered by a result of the destination
          network.

          ToIP will often be used to access
            aging process or for any other reason, thus creating a relay service [I], allowing
          text users need to communicate with
            replace or complement voice users. With relay services,
          it is crucial that with 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 as small as possible. in conversational
            sessions.

          NOTE: In
          particular, buffering of whole lines of text MUST NOT be used.

       5.3. Use many of SIP and RTP

          ToIP services MUST use the Session Initiation Protocol (SIP) [3]
          for setting up, controlling and terminating sessions for real-time above examples, text conversation with one may accompany speech.
          The text could be displayed side by side, in a manner similar to
          subtitling in broadcasting environments, or more participants and possibly
          including in any other media like video or audio.
          Thus, participants suitable
          manner.  This could occur for users who are allowed to negotiate on a set hard of compatible hearing and
          also for mixed media types calls with session descriptions used in SIP invitations. A both hearing and deaf people
          participating in the call.

          User Agents providing ToIP service MUST always support at least one Text media type.

       A. van Wijk                                           [Page 6 functionality need to provide suitable
          alerting indications, specifically offering visual and/or tactile
          alerting for deaf and hard of 28]
          ToIP services hearing users.

          The ability of SIP to set up conversation sessions from any
          location, as well as its privacy and security provisions, MUST use be
          maintained by ToIP services.

          Where ToIP is used in conjunction with other media, exposure of
          SIP functions through the Real-Time Transport Protocol (RTP)
          according User Interface needs to be done in an
          equivalent manner for all supported media. In other words, where
          certain SIP call control functions are available for the specification audio
          media part of RFC4103 the session, these functions MUST also be supported
          for the transport of text between participants, which implements T.140 media part of the same session. For example, call
          transfer must act on IP networks.

          The standardized all media in the session.

          T.140 real-time text conversation [4], in addition to audio and
          video communications, will be is a valuable service to many, for many users,
          including those on non-IP networks. Real-time text can
          be expressed as a part T.140 also provides for real-
          time editing of the session description in SIP and is a
          useful subset text.

       A. van Wijk, et al.     Expires 21 February 2006      [Page 7 of Total Conversation. 28]
       5.1.1 General ToIP Summary

          The general requirements for ToIP specification describes a framework are:

          a. Session setup, modification and teardown procedures for point-
             to-point and multimedia calls

          b. Registration procedures and address resolutions

          c. Registration of user preferences

          d. Negotiation procedures for device capabilities

          e. Support of text media transport using the T.140
          text conversation in SIP as a part of the multimedia session
          establishment in real-time over a SIP network.

          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 over RTP as
             described in RFC4103 RFC 4103 [5]

          f. Signaling of status information, call progress and the other one only supporting audio,
          the user might want to invoke a transcoding services.

          Examples of possible scenarios for including like in
             a relay service suitable manner, bearing in mind that the conversation are: speech-to-text (STT), text-to-speech (TTS), user may have a
             hearing impairment

          g. T.140 real-time text bridging after conversion from speech, audio bridging after
          conversion from text, etc.

          The session description protocol (SDP) [6] used in SIP to describe
          the session is used presentation mixing with voice and video

          h. T.140 real-time text conversation sessions using SIP, allowing
             users to express these attributes of the session
          (e.g., uniqueness in media mapping for conversion move from one media place to another

          i. User privacy and security for each communicating party).

          Real-time text can also be presented in conjunction with other
          media like video sessions setup, modification, and audio,
             teardown as well as for example in Total Conversation
          services.

          User Agents providing ToIP functionality SHOULD provide suitable
          alerting, specifically offering visual and/or tactile alerting so
          that deaf and hard media transfer

          j. Routing of hearing users can use them.

          The SIP abilities emergency calls according to set up text conversation sessions from any
          location, as well national or regional
             policy with the same level of functionality as privacy and security provisions SHOULD be
          implemented in a voice call.

       5.2. General Requirements for ToIP services.

          Where Interworking

          This section describes the general ToIP is used in conjunction with other media, exposure interworking requirements
          and gives some background information to many of
          SIP functions through the User Interface MUST be available in
          equivalent fashion for all supported media. In other words, where
          certain SIP call control functions are available for the audio
          media part issues.

          There is a range of the session, these functions MUST existing text services. There is also be supported a range
          of network technologies that could support text services (see
          examples below). ToIP needs to provide interoperability with text
          conversation features in other networks, for instance the PSTN,
          and with some text messaging services.

          Text gateways are used for converting between different media part of
          types. They could be used between networks or within networks
          where different transport technologies are used.

          When communicating via a gateway to other networks and protocols,
          the same session.

          Any ToIP implementation MUST also allow invocation and service SHOULD support the functionality for alternating
          or simultaneous use of
          relevant transcoding services where these are available. This can
          be achieved through application of SIP techniques for different modalities as offered by the destination
          network.

       A. van Wijk Wijk, et al.     Expires 21 February 2006      [Page 7 8 of 28]
          session establishment models [7]: Third party call control [8]
          Address information, both called and
          Conference Bridge model [9].

          Both point-to-point calling, SHOULD be
          transferred, and multipoint communication need to possibly converted, when interworking between
          different networks.

          ToIP will often be
          defined for the session establishment using T.140 used to access a relay service [I], allowing
          text
          conversation. In addition, ToIP services SHOULD support
          interworking users to communicate with voice users. With relay services,
          it is crucial that text telephony [10].

          The general framework for ToIP can be described characters are sent as follows:

          a. Session setup, modification and teardown procedures for point-
             to-point and multimedia calls

          b. Registration procedures and address resolutions

          c. Registration 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 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 [5] and the other one only supporting
          audio, the user preferences

          d. Negotiation procedures might want to invoke a transcoding service.

          Examples of possible scenarios for device capabilities

          e. 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 text, etc.

          The general requirements for ToIP Interworking are:

          a. Interoperability between T.140 conversations [4] and analog
             text telephones

          b. Discovery and invocation of transcoding/translation services
             between the media in the call

          f.

          c. Different session establishment models for transcoding /
             translation services invocation: Third party call control and
             conference bridge model

          g.

          d. Uniqueness in media mapping to be used in the session for
             conversion from one media to another by the transcoding /
             translation server for each communicating party

          h.

          e. Media bridging services for T.140 real-time text text, as described
             in RFC4103, audio, RFC4103 [5], audio and video for multipoint communications

          i.

          f. Transparent session setup, modification, and teardown between
             text conversation capable devices and voice/video capable
             devices

          j. Support

          g. Buffering of text when interworking with media that transport using T.140 over RTP as laid
          out in RFC 4103 [4]

          k. Signaling
             text at different rates.

       5.2.1 PSTN Interworking

          Analog text telephony is cumbersome because of status information, call progress and the like in
          a suitable manner, bearing incompatible
          national implementations where interworking was never considered.

       A. van Wijk, et al.     Expires 21 February 2006      [Page 9 of 28]
          A large number of these implementations have been documented in mind
          ITU-T V.18 [10], which also defines the user may have a hearing
          impairment

          l. T.140 real-time modem detection sequences
          for the different text presentation mixing with voice and video

          m. T.140 real-time text conversation sessions using SIP, allowing
          users to move from one place to another

          n. User privacy and security for sessions setup, modification, and
          teardown as well as for media transfer

          o. Interoperability between T.140 conversations and analogue text
          telephones

       A. van Wijk                                           [Page 8 of 28]
          p. Routing of emergency calls according to national or regional
          policy to the same level of a voice call.

       5.4. Requirements for ToIP 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 modem detection sequences for the
          different text terminals. protocols. The full modem capability exchange
          between two wildly different terminals can type identification
          may in rare cases take more than one
          minute to complete if both terminals have a common text
          modulation. considerable time depending on user
          actions.

          To resolve international analog textphone incompatibilities, text telephone
          gateways MUST are needed to transcode incoming analog signals into
          T.140 and vice versa. The modem capability exchange time is then
          also reduced, since V.18 allows the sequence of protocol discovery
          to can be customized. Hence,
          reduced by the text telephone gateways will assume initially assuming the
          analog text telephone protocol used in the region where the
          gateway is located. For example, in the USA, Baudot [III] might be
          tried as the initial protocol. If negotiation for Baudot fails,
          the full V.18 modem capability exchange will then take place. In contrast, in the
          UK, ITU-T V.21 [II] might be the first choice.

       6. Detailed requirements

       5.2.2 Cellular circuit switched Text-Telephony

          Cellular wireless (or Mobile) circuit switched connections provide
          a digital real-time transport service for Text-over-IP

          ToIP 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 MUST 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 SIP of the CTM modem in
          the voice channel for call control and signaling.

          A ToIP user may wish to call another ToIP user, or join a
          conference call involving several users. He or she may, also, wish
          to initiate or join a multimedia call, such as a Total
          Conversation call.

          There may be some need for pre-call setup e.g. storing
          registration information in the SIP registrar to provide
          information about how a user can be contacted. This will allow
          calls to be set up rapidly and with proper routing and addressing.

          Similarly, there are requirements that need to be satisfied during
          call set up when other media are preferred by a user. For
          instance, some users may prefer to use audio while others want to
          use text as their preferred modality. In this case, transcoding
          services might be needed for text-to-speech (TTS) and speech-to-
          text (STT). The requirements for transcoding services need to be
          negotiated in real-time to set up the session.

          The subsequent subsections describe some of these requirements in
          detail.

       A. van Wijk                                           [Page 9 of 28]
       6.1. Pre-Call Requirements

          The need to use ToIP as a medium of communications can be
          expressed by users during registration time. Two situations need
          to be considered in the pre-call setup environment:

          a. User Preferences: It MUST be possible for a user to indicate a
          preference for ToIP by registering that preference with a SIP
          server that is part of the ToIP service.

          b. Server to support User Preferences: SIP servers that are part
          of ToIP services MUST have the capability to act on users
          preferences for ToIP to accept or reject the call, based on the
          user preferences defined during the pre-call setup registration
          time. For example, if the user is called by another party, and it
          is determined that a transcoding server is needed, the call MUST
          be re-directed or otherwise handled accordingly.

       6.2 Basic Point-to-Point Call Requirements

          The point-to-point call will take place between two parties. The
          requirements are described in subsequent sub-sections. They assume
          that one or both of the communicating parties will indicate ToIP
          as a possible or preferred medium for conversation using SIP in
          the session setup.

       6.2.1 Session Setup

          Users will set up a session by identifying the remote party or the
          service they will want to connect to. However, conversations could
          be started using a mode other than ToIP. 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, during the conversation. Systems supporting ToIP MUST
          allow users to select any of the supported conversation modes at
          any time, including mid-conversation.

          Systems SHOULD allow the user to specify a preferred mode of
          communication, with the ability to fall back to alternatives that
          the user has indicated are acceptable.

          If the user requests simultaneous use of text and audio, and this
          is not possible either because the system only supports alternate
          modalities or because of resource management on the network, the
          system MUST try to establish a text-only communication. The user
          MUST be informed of this change throughout the process, either in
          text or in a combination of modalities that MUST include text.

          Session setup, especially through gateways to other networks, MAY
          require the use of specially formatted addresses or other
          mechanisms for invoking gateways.

       A. van Wijk                                           [Page 10 of 28]
          The following features MAY need to be implemented to facilitate
          the session establishment using ToIP:

          a. Caller Preferences: SIP headers (e.g., Contact) can be used to
          show that ToIP is the medium of choice for communications.

          b. Called Party Preferences: The called party being passive can
          formulate a clear rule indicating how a call should be handled
          either using ToIP as a preferred medium or not, and whether a
          designated SIP proxy needs to handle this call or it is handled in
          the SIP user agent (UA).

          c. SIP Server support for User Preferences: SIP servers can also
          handle the incoming calls in accordance to preferences expressed
          for ToIP. The SIP Server can also enforce ToIP policy rules for
          communications (e.g. use of the transcoding server for ToIP).

       6.2.2 Addressing

          The SIP [3] addressing schemes MUST be used for all entities. For
          example SIP URL and Tel URL will be used for caller, called party,
          user devices, and servers (e.g., SIP server, Transcoding server).

          The right to include a transcoding service MUST NOT require user
          registration in any specific SIP registrar, but MAY require
          authorisation of the SIP registrar in the service.

       6.2.3 Alerting and session progress presentation

          User Agents supporting ToIP MUST have an alerting method (e.g.,
          for incoming calls) that can be used by deaf and hard of hearing
          people or provide a range of alternative, but equivalent, alerting
          methods that are suitable for all users, regardless of their
          abilities and preferences.

          It should be noted that general alerting systems exist, and one
          common interface 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.

          If present, identification of the originating party (for example
          in the form of a URL or CLI) MUST be clearly presented to the user
          in a form suitable for the user BEFORE answering the request. When
          the invitation to initiate a conversation involving ToIP
          originates from a gateway, this MAY be signaled to the user.

          During a conversation that includes ToIP, status and session
          progress information MUST be provided in text. That information
          MUST be equivalent to session progress information delivered in
          any other format, for example audio. Users MUST be able to manage

       A. van Wijk                                           [Page 11 of 28]
          the session and perform all session control functions based on the
          textual session progress information.

          The user MUST be informed of any change in modalities.

          Session progress information SHOULD use simple language as much as
          possible so text telephony. However, implementations
          also exist that as many users as possible can understand it. The use of jargon or ambiguous terminology SHOULD be avoided at all
          times. It is RECOMMENDED to let text information be used together
          with icons symbolising the items data channel to be reported.

          There MUST be a clear indication, both visually as well as audibly
          whenever a session gets connected or disconnected. The user provide such
          functionality. Interworking with these solutions SHOULD
          never be in doubt as to what the status of done
          using text gateways that set up the data channel connection is, even
          if he/she is not able to use audio feedback or vision.

          In summary, it SHOULD be possible to observe visual or tactile
          indicators about:
          - Call progress
          - Availability of text, voice at the
          GSM side and video channels
          - Incoming call
          - Incoming provide ToIP at the other side.

       5.2.2.1 Cellular "No-gain"

          The "No-gain" text
          - Typed telephone transporting technology uses
          specially modified EFR [13] and transmitted text
          - Any loss EVR [14] speech vocoders in incoming text.

       6.2.4 Call Negotiations

          The Session Description Protocol (SDP) mobile
          terminals used in SIP [3] provides
          the capabilities to indicate ToIP as provide a media in the call setup.
          RFC 4103 [5] text telephony call. It provides the RTP payload type text/t140 for support
          of ToIP which can be indicated in the SDP as a part of SDP INVITE,
          OK full
          duplex operation and SIP/200/ACK for media negotiations. In addition, SIPĂs
          offer/answer model can also be used in conjunction with other
          capabilities including the use of a transcoding server for
          enhanced call negotiations [7,8,9].

       6.2.5 Answering

          Systems SHOULD provide a best-effort approach supports alternating voice and text
          ("VCO/HCO"). It is dedicated to answering
          invitations for session set-up CDMA and TDMA mobile technologies
          and users should be kept informed
          at all times about the progress US Baudot (i.e. 45 bit/s) type of session establishment. On all
          systems text telephones.

       5.2.2.2 Cellular Text Telephone Modem (CTM)

          CTM [15] is a technology independent modem technology that both inform users
          provides the transport of session status and support ToIP,
          this information MUST text telephone characters at up to 10
          characters/sec using modem signals that can be available in text, carried by many
          voice codecs and MAY be provided in
          other visual media.

       6.2.5.1 Answering Machine

          Systems for ToIP MAY support an auto-answer function, equivalent uses a highly redundant encoding technique to answering machines on telephony networks. If an answering
          machine function is supported, it MUST support at least 160
          characters for
          overcome the greeting message. It MUST support incoming text
          message storage of a minimum of 4096 characters, although systems fading and cell changing losses.

       A. van Wijk Wijk, et al.     Expires 21 February 2006      [Page 12 10 of 28]
          MAY support much larger storage. It
       5.2.2.3 Cellular "Baudot mode"

          This term is RECOMMENDED often used by cellular terminal suppliers for a GSM
          cellular phone mode that systems
          support storage allows TTYs to operate into a cellular
          phone and to communicate with a fixed line TTY.

       5.2.3 Cellular data channel mode

          Many mobile terminals allow the use of at least 20 incoming messages the data channel to
          transfer data in real-time. Data rates of up 9600 bit/s are usually
          supported on the mobile network. Gateways provide interoperability
          with PSTN textphones.

       5.2.4 Cellular Wireless ToIP

          ToIP could be supported over cellular wireless packet switched
          services that interface to 16000
          characters.

          When the answering machine Internet. For 3GPP 3G services, the
          support is activated, user alerting SHOULD
          still take place. The user SHOULD be allowed described to monitor the auto-
          answer progress use ToIP in 3G TS 26.235 [18]. Low data
          rates and where this is provided the user MUST be
          allowed additional delays can affect performance.

       5.2.5 Instant Messaging Support

          Many people use Instant Messaging to intervene during any stage of communicate via the answering machine and
          take control Internet
          using text. Instant Messaging transfers blocks of the session.

       6.2.6 Actions During Calls

          Certain actions need to be performed text rather than
          streaming as is used by ToIP. As such, it is not a replacement for the
          ToIP conversation
          during and in particular does not meet the call needs for real time
          conversations including those of deaf, hard of hearing and these actions are described briefly as
          follows:

          a. Text transmission SHALL be done character by character speech-
          impaired users as
          entered, or defined in small groups transmitted so that no character RFC 3351 [19]. It is
          delayed between entry and transmission by more than 300
          milliseconds.

          b. The text transmission SHALL allow unsuitable for
          communications through a rate of at least 30
          characters per second so that human typing speed as well as speech
          to text methods relay service [I]. The streaming nature
          of generating conversation text can be supported.

          c. After text connection is established, ToIP provides a more direct conversational user experience and,
          when given the mean end-to-end delay
          of characters SHALL choice, users may prefer ToIP.

          Text gateways could be less than two seconds, measured developed to allow interworking between two
          Instant Messaging systems and ToIP solutions.

       6. Detailed requirements for ToIP

          A ToIP user may wish to call another ToIP users. This requirement is valid as long as the text input
          rate is lower user, or equal to the text reception and display rate.

          d. The character corruption rate SHALL join a
          conference session involving several users or initiate or join a
          multimedia session, such as a Total Conversation session.

          There may be less than 1% some need for pre-session setup e.g. storing of
          registration information in
          conditions where users experience the quality of voice
          transmission SIP registrar, to provide
          information about how a user can be low but useable. contacted. This is in accordance will allow
          sessions to be set up rapidly and with
          ITU-T F.700 Annex A.3 quality level T1.

          e. When interoperability functions are invoked, proper routing and
          addressing.

          Similarly, there may be a are requirements that need for intermediate storage of characters before transmission to
          a device receiving slower than the typing speed of the sender.
          Such temporary storage SHALL be dimensioned satisfied during
          session set up when other media are preferred by a user. For
          instance, some users may indicate their preferred modality to adjust be
          audio while others may indicate text. In this case, transcoding
          services might be needed for
          receiving at 30 characters per second text-to-speech (TTS) and transmitting at 6
          characters per second during at least 4 minutes [less than 3k
          characters].

          f. To enable the use speech-to-

       A. van Wijk, et al.     Expires 21 February 2006      [Page 11 of international character sets the
          transmission format for 28]
          text conversation SHALL (STT). The requirements for transcoding services need to be UTF-8,
          negotiated in
          accordance with ITU-T T.140.

          g. If text is detected real-time to set up the session.

          The subsequent subsections describe some of these requirements in
          detail.

       6.1. Pre-Session Requirements

          The need to use text as a medium of communications can be missing after transmission, there
          SHALL
          expressed by users during registration time. Two situations need
          to be an indication considered in the text marking the loss. For 7 bit
          terminals this loss MAY pre-session setup environment:

          a. User Preferences: It MUST be marked as an apostrophe: Ă.

          g. When used from possible for a terminal designed user to indicate a
             preference for PSTN text telephony, or
          in interworking by registering that preference with such a terminal, ToIP shall enable

       A. van Wijk                                           [Page 13 SIP
             server that is part of 28]
          alternating between text and voice in a similar manner as the PSTN ToIP service.

          b. Server to support User Preferences: SIP servers that support
             ToIP services MUST have the capability to act on calling user
             preferences for text telephone handles this mode of operation. (This mode is often
          called VCO/HCO in order to accept or reject the USA and session-,
             based on the UK).

          i. When display called userĂs preferences defined as part of the conversation on end
             pre-session setup registration. For example, if the user equipment is
          included in the design, display of the dialogue SHALL be made so
          that
             called by another party, and it is easy to read text belonging to each party in determined that a
             transcoding server is needed, the
          conversation.

       6.2.6.1 Text and other Media Handling Between ToIP User Agents session MUST be re-directed
             or otherwise handled accordingly.

       6.2 Basic Point-to-Point Session Requirements

          A point-to-point session takes place between two parties. The following
          requirements are valid for media handling during
          calls:

          a. When used between User Agents designed for ToIP, it SHALL be
          possible to send and receive text simultaneously.

          b. When used between User Agents described in subsequent sub-sections. They assume
          that support ToIP, it SHALL be one or both of the communicating parties will indicate text
          as a possible to send or preferred medium for conversation using SIP in
          the session setup.

       6.2.1 Session control

          ToIP services MUST use the Session Initiation Protocol (SIP) [3]
          for setting up, controlling and receive terminating sessions for real-time
          text simultaneously conversation with the one or more participants and possibly
          including other media (text, audio and/or video) supported by the same terminals.

          c. It SHOULD be possible like video or audio. The session description
          protocol (SDP) [6] used in SIP to know during describe the call that ToIP is
          available, even if it is not invoked at call setup (only voice
          and/or video session is used for example). To disable this, the user must
          disable to
          express the use attributes of ToIP. This is possible during registration at the REGISTRAR.

       6.2.6.2 Call Action with Native ToIP User Agents

          a. It SHOULD be possible session and to answer negotiate a call with text capabilities
          enabled.

          b. It MAY be possible to use video simultaneously with the other set of
          compatible media in the call.

          c. It types.

       6.2.2 Text transport

          A ToIP service MUST be possible to answer a call in voice or video without
          text enabled, and add text later in the call.

          d. It always support at least one Text media type.

          ToIP services MUST be possible to disconnect support the call.

          e. It SHOULD be possible to invoke multi-party calls.

          f. It MUST be possible Real-Time Transport Protocol (RTP)
          [24] according to transfer the call.

       6.2.7 Additional session control

          Systems that support additional session control features, for
          example call waiting, forwarding, hold etc on voice calls, MUST
          offer equivalent functionality specification of RFC4103 [5] for the
          transport of text calls. between participants.

          RFC4103 describes the transmission of T.140 [4] on IP networks.

       A. van Wijk Wijk, et al.     Expires 21 February 2006      [Page 14 12 of 28]
       6.2.8 File storage

          Systems that support ToIP MAY save
       6.2.3 Session Setup

          Users will set up a session by identifying the text conversation remote party or the
          service they want to a
          file. This SHOULD connect to. However, conversations could be done
          started using a standard file format. mode other than text. For
          example: UTF8 text file in XML format including record timestamp,
          party 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, during the conversation.

       6.3 Conference Call Requirements for Systems supporting ToIP User Agents

          The conference call requirements deal with multipoint conferencing
          calls where there will be MUST
          allow users to select any of the supported conversation modes at least one or more ToIP capable
          devices along
          any time, including mid-conversation.

          Systems SHOULD allow the user to specify a preferred mode of
          communication, with other end the ability to fall back to alternatives that
          the user devices where has indicated are acceptable.

          If the total number
          end user devices will be at least three.

          It SHOULD be possible to requests simultaneous use the of text medium in conference calls, and audio, and this
          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. If the user
          has expressed a similar way as preference for text, establishment of a connection
          including text MUST have priority over other outcomes of the audio is handled and
          session setup.

          The following features MAY be implemented to facilitate the video is
          displayed. Text in conferences
          session establishment using ToIP:

          a. Caller Preferences: SIP headers (e.g., Contact)[24] can be used both for letting
          individual participants use
             to show that ToIP is the text medium (for example, of choice for
          sidebar discussions in communications.

          b. Called Party Preferences: The called party being passive can
             formulate a clear rule indicating how a session should be
             handled either using text while listening as a preferred medium or not, and
             whether a designated SIP proxy needs to handle this session or
             it will be handled in the main conference
          audio), as well as for central SIP user agent.

          c. SIP Server support of for User Preferences: SIP servers can also
             handle the conference incoming sessions in accordance with real
          time text interpretation of speech.

       6.4 Transport via RTP preferences
             expressed for ToIP. The SIP Server can also enforce ToIP uses RTP as the default transport protocol policy
             rules for transmission communications (e.g. use of real-time text via medium text/t140 as specified in RFC 4103
          [5]. the transcoding server
             for ToIP).

       6.2.4 Addressing

          The redundancy method of RFC 4103 [5] SHOULD SIP [3] addressing schemes MUST be used for making
          text transmission reliable.

          Text capability MUST be announced all entities in SDP by a declaration in line
          with 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

          Characters SHOULD be buffered for transmission and transmitted
          every 300 ms.

          By having this single coding and transmission scheme for real time
          text defined, in the
          ToIP session. For example, SIP call 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, URLĂs or Tel URLĂs are used for
          caller, called party, user devices, and RFC 4103 [5] transport servers (e.g., SIP server,
          Transcoding server).

          The right to include a transcoding service MUST be used
          as both NOT require user
          registration in any specific SIP registrar, but MAY require
          authorisation of the default as well as SIP registrar to invoke the fallback transport. service.

       A. van Wijk Wijk, et al.     Expires 21 February 2006      [Page 15 13 of 28]
       6.5 Character Set

          a.
       6.2.5 Alerting

          User Agents supporting ToIP services MUST use UTF-8 encoding as specified in ITU-T
          T.140 [12].

          b. ToIP SHOULD handle characters with editing effect such as new
          line, erasure and have an alerting during session as specified in ITU-T
          T.140.

       6.6 Transcoding

          Transcoding of text may need to take place in gateways between
          ToIP method (e.g.,
          for incoming sessions) that can be used by deaf and other forms hard of text conversation. For example to connect
          to a PSTN text telephone.

       6.7 Relay Services

          The relay service acts as an intermediary between two or more
          callers using different media
          hearing people or different media encoding schemes.

          The basic text relay service allows provide a translation range of speech to
          text and 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 alternative, but equivalent,
          alerting methods that there can be selected by all users, regardless of
          their abilities.

          It should be noted that external alerting systems exist other relay services like, for example, speech to sign
          language and vice versa using video.

          It one
          common interface for triggering the alerting action is RECOMMENDED that ToIP implementations make a contact
          closure between two conductors.

          Among the alerting options are alerting by the invocation User AgentĂs User
          Interface and use of relay services as easy specific alerting user agents registered to the same
          registrar as possible. It MAY happen
          automatically when the call is being set up based on any valid
          indication or negotiation main user agent.

       6.2.6 Session information

          If present, identification of supported or preferred media types. A
          transcoding framework document using SIP [7] describes invoking
          relay services, where the relay acts as a conference bridge or
          uses the third originating party control mechanism. ToIP implementations
          SHOULD support this transcoding framework.

          Adding (for example
          in the form of a URL or removing a relay service CLI) MUST be possible without
          disrupting clearly presented to the current call.

          When setting up
          user in a call, form suitable for the relay service MUST user BEFORE the session invitation
          is answered. When a session invitation involving ToIP originates
          from a gateway, this MAY be able signaled to
          determine the type user.

          The user MUST be informed of service requested (e.g., speech to text or
          text to speech), any change in modalities.

       6.2.7 Session progress 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 indicate if the caller wants voice carry over,
          the 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 the text, the sign language being used (in the
          video stream), etc.

          It jargon or
          ambiguous terminology SHOULD be possible avoided. It is RECOMMENDED that
          text information be used together with icons to route symbolise the call
          session progress information.

          There MUST be a clear indication, in a modality useful to the
          user, whenever a preferred relay
          service session is connected or disconnected. A user
          SHOULD never be in doubt about the status of the session, even if
          the user makes is unable to make use of the call from another region audio or
          network than usually used. 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 text, voice and video channels
          - Session progress
          - Incoming text
          - Any loss in incoming text

       A. van Wijk Wijk, et al.     Expires 21 February 2006      [Page 16 14 of 28]
       6.8 Emergency services

          Access to emergency services using ToIP SHOULD provide an
          equivalent service to the one offered by other supported media,
          like audio.

       6.9 User Mobility

          ToIP User Agents SHOULD
          - Typed and transmitted text.

          For users who cannot use the same mechanisms as other SIP User
          Agents to resolve mobility issues. It audible alerter for incoming
          sessions, it is RECOMMENDED to use include a SIP-
          address for the users, resolved by tactile as well as a
          visual indicator.

       6.2.8 Session Negotiations

          The Session Description Protocol (SDP) used in SIP REGISTRAR, to enable
          basic user mobility. Further mechanisms are defined for [3] provides
          the 3G IP
          multimedia systems.

       6.10 Confidentiality and Security

          User confidentiality and privacy need capabilities to be met indicate text as described a medium in
          SIP [3]. For example, nothing should reveal the fact that session
          setup. RFC 4103 [5] uses the user RTP payload type "text/t140" for
          support of ToIP is which can be indicated in the SDP as a person part of the
          SIP INVITE, OK and SIP/200/ACK media negotiations. In addition,
          SIPĂs offer/answer model [20] can also be used in conjunction with a disability unless
          other capabilities including the user prefers to
          make this information public. If use of a transcoding server is being
          used, this for
          enhanced session negotiations [7,8,9].

       6.2.9 Answering

          Systems SHOULD be transparent. Encryption provide a best-effort approach to answering
          invitations for session set-up and users SHOULD be used on
          end-to-end or hop-by-hop basis as described in SIP [3] informed when
          the session is accepted by the other party. On all systems that
          both inform users of session status and SRTP
          [19]

          Authentication needs to support ToIP, this
          information MUST be provided for users available in addition to the
          message integrity textual form and access control.

          Protection against Denial-of-service (DoS) attacks needs to MAY also be
          provided considering the case that the ToIP users might need
          transcoding servers.

       7. Interworking Requirements in other media.

       6.2.9.1 Answering Machine

          Systems for ToIP

          A number of systems MAY support an auto-answer function, equivalent
          to answering machines on telephony networks. If an answering
          machine function is supported, it MUST support at least 160
          characters for real time the greeting message. It MUST support incoming text conversation already exist
          as well as
          message storage of a number minimum of message oriented text communication
          systems. Interoperability 4096 characters, although systems
          MAY support much larger storage. It is RECOMMENDED that systems
          support storage of interest between ToIP and some at least 20 incoming messages of
          these systems. This section describes requirements on 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
          interoperability, especially for is provided the PSTN text telephony user SHOULD be
          allowed to ensure
          full backward interoperability with ToIP.

       7.1 ToIP Interworking Gateway Services

          Interactive texting facilities exist already in various forms intervene during any stage of the answering machine
          procedure and
          on various networks. On take control of the PSTN, it is commonly referred session.

       6.2.10 Actions During a Session

          Certain actions need to be performed during ToIP conversation:

          a. Text transmission from a terminal SHALL be performed character
             by character as
          text telephony.

          Simultaneous entered, or alternating use in small groups of voice and text characters, so
             that no character is used by a
          large number of users who can send voice, but must receive text or
          who can hear but must send text due delayed from entry to a speech disability. transmission by more
             than 300 milliseconds.

       A. van Wijk Wijk, et al.     Expires 21 February 2006      [Page 17 15 of 28]
       7.2 ToIP and PSTN/ISDN Text-Telephony

          On PSTN networks, transmission of interactive
          b. The text takes place
          using transmission SHALL allow a variety rate of codings and modulations, including ITU-T V.21
          [II], Baudot, DTMF, V.23 [III] and others. Many difficulties have
          arisen at least 30
             characters per second so that human typing speed as a result of this variety in text telephony protocols and
          the ITU-T V.18 [10] standard was developed well as
             speech to address some of
          these issues.

          ITU-T-V.18 [10] offers a native text telephony method plus it
          defines interworking with current protocols. In the interworking
          mode, it will recognise one methods of the older protocols and fall back
          to that transmission method when required.

          In order to allow systems and services based on ToIP to
          communicate with PSTN text telephones, generating conversation text gateways are can be
             supported.

          c. To enable the
          recommended approach. These gateways MUST use of international character sets, the ITU-T V.18 [10]
          standard at the PSTN side.

          Buffering MUST
             transmission format for text conversation SHALL be used UTF-8 [12],
             in accordance with ITU-T T.140.

          d. If text is detected to support different transmission rates. At
          least 1K buffer MUST be provided. A buffer missing after transmission, there
             SHOULD be a "text loss" indication in the text as specified in
             T.140 Addendum 1 [4].

          e. When the display of at least 2K
          characters text conversation is RECOMMENDED. In addition, included in the gateway MUST provide a
          minimum throughput design
             of at least 30 characters/second or the highest
          speed supported by end user equipment, the display of the dialogue SHOULD
             be made so that it is easy to differentiate the PSTN text telephony belonging
             to each party in the conversation.

       6.2.10.1 Text Transport

          ToIP uses RTP as the default transport protocol side,
          whichever is for the lowest.

          PSTN-ToIP gateways MUST allow alternating use
          transmission of real-time text and voice.

          PSTN and ISDN via the medium "text/t140" as
          specified in RFC 4103 [5].

          The redundancy method of RFC 4103 [5] SHOULD be used to ToIP gateways that receive CLI information from
          significantly increase the originating party reliability of the text transmission. A
          redundancy level using 2 generations gives very reliable results
          and is therefore RECOMMENDED.

          Text capability MUST pass this information be announced in SDP by a declaration similar
          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 coding and transmission scheme for real time
          text defined in the receiving
          party as soon as possible.

          Priority 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 [5] transport MUST be given to calls labeled used as emergency calls.

       7.3 ToIP both the
          default and Cellular Wireless circuit switched Text-Telephony

          Cellular wireless (or Mobile) circuit switched connections provide
          a digital real-time transport service for voice the fallback transport.

       6.2.10.2 Handling Text and other Media.

          A call is one or data. more related sessions. The access technologies include GSM, CDMA, TDMA, iDen following requirements
          apply to media handling during a call:

          a. When used between User Agents designed for ToIP, it SHALL be
             possible to send and various
          3G technologies.

          Alternative means receive text simultaneously.

       A. van Wijk, et al.     Expires 21 February 2006      [Page 16 of transferring 28]
          b. When used between User Agents that support ToIP, it SHALL be
             possible to send and receive text simultaneously with the Text telephony data have
          been developed when TTY services over cellular was mandated other
             media (text, audio and/or video) supported by the
          FCC in same
             terminals.

          c. It SHOULD be possible 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 video is used initially). To disable this,
             the USA. They are a) "No-gain" codec solution, b) user MUST disable the
          Cellular Text Telephony Modem (CTM) solution and c) "Baudot mode"
          solution.

          The GSM and 3G standards from 3GPP make use of ToIP. This is possible during
             registration at the CTM modem 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 channel sessions, MUST
          offer this functionality for text telephony.
          However, implementations also exist sessions.

       6.2.12 File storage

          Systems that use support ToIP MAY save the data channel text conversation to
          provide such functionality. Interworking with these solutions a
          file. This SHOULD be done using a standard file format. For
          example: a UTF8 text gateways that set up the data channel
          connection at the GSM side file in XML format [11] including timestamps,
          party names (or addresses) and provide ToIP at the text conversation.

       6.3 Conference Session Requirements

          The conference session requirements deal with multipoint
          conferencing sessions where there will be one or more ToIP capable
          devices and/or other side.

       A. van Wijk                                           [Page 18 end user devices where the total number of 28]
       7.3.1 "No-gain"

          The "No-gain"
          end user devices will be at least three.

          It SHOULD be possible to use the text telephone transporting technology uses
          specially modified EFR [15] medium in conference
          sessions in a similar way to how audio is handled and EVR [16] speech vocoders video is
          displayed. Text in both
          mobile terminals conferences can be used both for letting
          individual participants use the text medium (for example, for
          sidebar discussions in text while listening to provide a the main conference
          audio), as well as for central support of the conference with real
          time text telephony call. It
          provides full duplex operation interpretation of speech.

       6.4 Real-time Editing and supports alternating voice User Alerting

          ToIP SHOULD handle characters such as new line, erasure and
          text.( "VCO/HCO").
          alerting during a session as specified in ITU-T T.140.

       6.5 Emergency services

          It is dedicated MUST be possible to the CDMA and TDMA mobile
          technologies place an emergency call using ToIP and the US Baudot type of it
          MUST be possible to use a relay service in such call. The
          emergency service provided to users utilising the text telephones.

       7.3.2 Cellular Text Telephone Modem (CTM)

          CTM [17] is a technology independent modem technology that
          provides medium MUST
          be equivalent to the transport emergency service provided to users utilising
          speech or other media.

       A. van Wijk, et al.     Expires 21 February 2006      [Page 17 of text telephone characters at up 28]
       6.6 User Mobility

          ToIP User Agents SHOULD use the same mechanisms as other SIP User
          Agents to 10
          characters/sec using modem signals 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 at or below 1 kHz defined for all session
          types for 3G IP multimedia systems.

       6.7 Firewalls and NATs

          ToIP uses a highly redundant encoding technique to overcome the fading same signaling and cell changing losses. On any interface that uses analog
          transmission, half-duplex operation must be supported transport protocols as VoIP
          hence, the
          "send" same firewall and "receive" modem frequencies are identical. The use of
          CTM may have NAT solutions and network
          functionality that apply to be modified slightly VoIP MUST also apply to support half-duplex
          operation.

       7.3.3 "Baudot mode"

          This term is often used by cellular terminal suppliers ToIP.

       7. Interworking Requirements for ToIP

          A number of systems for real time text conversation already exist
          as well as a GSM
          cellular phone mode that allows TTYs to operate into a cellular
          phone number of message oriented text communication
          systems. Interoperability is of interest between ToIP and some of
          these systems. This section describes the interoperability
          requirements, especially for PSTN text telephony, to communicate ensure full
          backward interoperability with a fixed line TTY.

       7.3.4 Data channel mode

          Many mobile terminals allow ToIP.

       7.1 ToIP Interworking Gateway Services

          Interactive texting facilities exist already in various forms and
          on various networks. On the PSTN, it is commonly referred to as
          text telephony.

          Simultaneous or alternating use of the data channel to
          transfer data in real-time. Data rates voice and text is used by a
          large number of 9600 bit/s are usually
          supported on the mobile network. Gateways users who can send voice but must receive text
          (due to a hearing impairment), or the interworking
          function provides interoperability with PSTN textphones.

       7.3.5 Common Text Gateway Functions

          Text gateways MUST cover the differences that result from
          different who can hear but must send text protocols. The protocols
          (due to be supported will
          depend on a speech impairment).

          Session setup through gateways to other networks MAY require the service requirements
          use of the Gateway. specially formatted addresses or other mechanisms for
          invoking those gateways.

          Different data rates of different protocols MAY require text
          buffering.

          Interoperation

          Transcoding of half-duplex and full-duplex protocols MAY
          require text buffering and some intelligence to determine when and from other coding formats MAY need to
          change direction when operating
          take place in half-duplex.

          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).

       A. van Wijk                                           [Page 19 gateways between ToIP and other forms of 28]
          A text gateway MUST be able
          conversation, for example to route text calls connect to emergency
          service providers when any a PSTN text telephone.

       7.2 ToIP and PSTN/ISDN Text-Telephony Interworking

          On PSTN networks, transmission of the recognised emergency numbers
          that support interactive text communications for the country or region are
          called eg. "911" in USA takes place
          using a variety of codings and "112" modulations, including ITU-T V.21
          [II], Baudot [III], DTMF, V.23 [IV] and others. Many difficulties
          have arisen as a result of this variety in Europe. Routing text calls to
          emergency services MAY require telephony
          protocols and the use ITU-T V.18 [10] standard was developed to
          address some of these issues.

       A. van Wijk, et al.     Expires 21 February 2006      [Page 18 of 28]
          ITU-T V.18 [10] offers a transcoding service.

          A native text gateway MUST act as a SIP User Agent on telephony method plus it
          defines interworking with current protocols. In the IP side.

       7.4 ToIP interworking
          mode, it will recognise one of the older protocols and Cellular Wireless ToIP

          ToIP MAY fall back
          to that transmission method when required.

          V.18 MUST be supported over the cellular wireless packet switched
          service. It interfaces to the Internet. For 3GPP 3G services, on the
          support is described to use ToIP in 3G TS 26.235 [20].

          A text gateway with cellular wireless packet switched services PSTN side of a PSTN-ToIP gateway.

          PSTN-ToIP gateways MUST be able to route text calls into emergency service providers
          when any allow alternating use of the recognized emergency numbers that support text
          communication for and voice if
          the country are called.

       7.5 Instant Messaging Support

          Many people use Instant Messaging to communicate via PSTN textphone involved at the Internet
          using text. Instant Messaging transfers blocks PSTN side of text rather than
          streaming as the session
          supports this. (This mode is used often called VCO/HCO).

          Calling party identification information, such as CLI, MUST be
          passed by ToIP. As such, it is not a replacement for
          ToIP and in particular does not meet the needs for real time
          conversations of deaf, hard of hearing gateways and speech-impaired users
          as defined in RFC 3351 [21]. converted to an approapriate form if
          required.

       7.3 ToIP and Cellular Wireless ToIP

          ToIP MAY be supported over the cellular wireless packet switched
          service. It is unsuitable for communications
          through a relay interfaces to the Internet.

          A text gateway with cellular wireless packet switched services
          MUST be able to route text calls to emergency service [I]. The streaming character of ToIP
          provides a better user experience and, providers
          when given any of the choice,
          users often prefer ToIP.

          However, since some users might only have recognized emergency numbers that support text
          communication for the country.

       7.4 Instant Messaging
          available, text Support

          Text gateways MAY be developed 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, such gateways need to
          transform MUST transcode between these the two
          formats. Text gateways for
          interworking for interworking between Instant Messaging
          and ToIP MUST concatenate individual characters originating at the
          ToIP side into blocks of text and:

          a. 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. 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. 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.

          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 21 February 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 concatenate
          individual provide this signaling
          to the Instant Messaging side when characters originating start being
          received, or at the ToIP side into blocks beginning of
          text and:

          a. When the length conversation.

          At the ToIP side, an indicator of writing the concatenated message becomes longer than
          50 characters, Instant Message MUST
          be present where the buffered Instant Messaging protocol provides one. For
          example, the real-time text SHOULD user MAY see ". . . waiting for
          replying IM. . . " and when 5 seconds have passed another . (dot)
          can be transmitted 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 are the
          same for Instant Messaging side as soon (SIMPLE) and ToIP.

          Devices that implement Instant Messaging SHOULD implement ToIP as any non-alphanumerical character
          is received
          described in this document so that a more complete text
          communication service can be provided.

       7.5 Common Text Gateway Functions

          Text gateways MUST allow for the differences that result from
          different text protocols. The protocols to be supported will
          depend on the ToIP service requirements of the Gateway.

       7.5.1 Protocol support

          Text gateways MUST use the ITU-T V.18 [10] standard at the PSTN
          side.

          b. A text gateway MUST act as a SIP User Agent on the IP side
          and support RFC4103 text transport.

       7.5.2 Relay buffer storage

          When text gateway functions are invoked, there will be a new line is received from need for
          intermediate storage of characters before transmission to a device
          receiving text slower than the ToIP side, transmitting speed of the buffered 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 that point, including the carriage return and/or
          line feed characters, SHOULD 4 minutes (i.e. less than 3k
          characters).

          Interoperation of half-duplex and full-duplex protocols MAY
          require text buffering. Some intelligence will be transmitted needed to
          determine when to change direction when operating in half-duplex
          mode. Identification may be required of half-duplex operation
          either at the Instant
          Messaging side. "user" level (ie. users must inform each other) or

       A. van Wijk Wijk, et al.     Expires 21 February 2006      [Page 20 of 28]
          c. When the ToIP side has been idle for
          at least 5 seconds, all
          buffered text up the "protocol" level (where an indication must be sent back to that point SHOULD
          the Gateway).

       7.5.3 Emergency calls through gateways

          A text gateway MUST be transmitted able to route text calls to emergency
          service providers when any of the
          Instant Messaging side.

          It is RECOMMENDED recognised emergency numbers
          that during support text communications for the session, both users country or region are
          constantly updated on the progress of the
          called e.g. "911" in USA and "112" in Europe. Routing text input.
          Many Instant Messaging protocols signal that a user is typing calls
          to emergency services MAY require the other party in the conversation. use of a transcoding
          service.

       7.5.4 Text gateways between such
          Instant Messaging protocols and Gateway Invocation

          ToIP MUST provide interworking requires a method to invoke a text gateway. As
          described previously in this signaling
          to the Instant Messaging side when characters start being
          received, or draft, these text gateways MUST act
          as User Agents at the beginning IP side. The capabilities of the conversation.

          At the ToIP side, an indicator of writing text
          gateway during the Instant Message MUST call will be present where determined by the Instant Messaging protocol provides one. For
          example, call
          capabilities of the real-time text user MAY see . . . waiting for
          replying IM. . . And per 5 seconds terminal that pass a . (dot) can be
          shown.

          Those solutions will reduce is using the difficulties between gateway. For
          example, a PSTN textphone is generally only able to receive voice
          and streaming
          versus blocked text.

          Even though text, so the text gateway can connect Instant Messaging will only allow ToIP and
          ToIP, the best solution is to take advantage
          audio.

          Examples of possible scenarios for invocation of the fact that the
          user interfaces and text gateway
          are:

          a. PSTN textphone users dial a prefix number before dialing out.
          b. Separate text subscriptions, linked to the user communities phone number or
             terminal identifier/ IP address.
          c. Text capability indicators.
          d. Text preference indicator.
          e. Listen for instant messaging V.18 modem modulation text activity in all PSTN
             calls and
          ToIP telephony are extremely similar. After all, routing of the character
          input, call to an appropriate gateway.
          f. Call transfer request by the character display, Internet connectivity 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 stack
          are address.
             (This requires user interaction with the same for Instant Messaging (SIMPLE) text gateway to place
             a call).
          i. ENUM address analysis and ToIP.

          Devices that implement Instant Messaging SHOULD implement ToIP as
          described in this document. number plan
          j. Number or address analysis leads to a gateway for all PSTN
             calls.

       7.6 IP Telephony with Traditional RJ-11 Interfaces

          Analogue Home Gateways or Analog Terminal Adapters

          Analog terminal adapters (ATAs) using SIP based IP communication
          and RJ-11 connectors for connecting traditional PSTN devices (ATA box)
          SHOULD enable connection of legacy PSTN text telephones [18]. [16].

          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 [5], in a
          similar way as it provides interoperability for voice calls. sessions.

       A. van Wijk, et al.     Expires 21 February 2006      [Page 21 of 28]
          If a
          call 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 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 analogue analog terminal adaptors do use
          RFC 4103 [5] 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 dropping characters character loss in the textphone
          conversation or even not allowing the textphones to connect with to
          each other.

       A. van Wijk                                           [Page 21 of 28]

       7.7 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 build 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 text gateway
          that has modems to interwork with the PSTN and that support both
          Instant Messaging and real-time ToIP MUST support the following
          interworking functions:

          - PSTN text telephony to real-time ToIP.
          - PSTN text telephony to Instant Messaging.
          - Instant Messaging to real-time ToIP.

       7.8 ToIP interoperability with PSTN text telephones. 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 10 646 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 indicator in T.140, specified in T.140
          amendment 1, cannot be represented in the 7 bit character codes.
          Therefore
          these characters the indicator of missing text SHOULD be transcoded to
          the ' (apostrophe) character in legacy text telephone systems,

       A. van Wijk, et al.     Expires 21 February 2006      [Page 22 of 28]
          where this character exists. For legacy systems where the
          character ' does not exist, the . ( full stop ) character SHOULD
          be used instead.

       7.9 Gateway Discovery

          ToIP requires a method to invoke a text gateway. As described
          previously in this draft, these text gateways MUST act as User
          Agents at the IP side. The capabilities of the text gateway during
          the call will be determined by the call capabilities of the
          terminal that is using the gateway. For example, a PSTN textphone
          is only able to receive voice and streaming text, so the text
          gateway will only allow ToIP and audio.

          Examples of possible scenarios for discovery of the text gateway
          are:

       A. van Wijk                                           [Page 22 of 28]
          - PSTN textphone users dial a prefix number before dialing out.
          - Separate text subscriptions, linked to the phone number or
          terminal identifier/ IP address.
          - Text capability indicators.
          - Text preference indicator.
          - Listen for V.18 modem modulation text activity in all calls.
          - Call transfer request by the called user.
          - Placing a call via the web, and used instead.

       7.9 Relay Services

          The relay service acts as an intermediary between two or more
          callers using one different media or different media encoding schemes.

       7.9.1 Basic function of the methods
          described here
          - Text gateways with its own telephone number and/or SIP address.
          (This requires user interaction with the relay service

          The basic text gateway to place relay service allows a
          call).
          - ENUM address analysis translation of speech to
          text and number plan
          - Number or address analysis leads text to the gateway for all PSTN
          calls.

       8. Afterword

          The authors speech, which enables hearing and speech impaired
          callers to communicate with hearing callers. Even though this
          document focuses on ToIP, we want to make it clear remind readers that ToIP other
          relay services exist, like video relay services transcoding speech
          to sign language and vice versa where the signing is a way communicated
          using video.

       7.9.2 Invocation of allowing
          real-time, interactive text conversation between all users and relay services

          It is
          thus not only for RECOMMENDED that ToIP implementations make the hearing invocation
          and speech impaired users.

          The users may invoke 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 [7] describes invoking
          relay services, where the relay acts as a conference bridge or
          uses the third party control mechanism. ToIP services for many different reasons.
          For example:

          - Noisy environment (e.g., in implementations
          SHOULD support this transcoding framework.

          Adding or removing a machine room of relay service MUST be possible without
          disrupting the current session.

          When setting up a factory where
          listening is difficult)
          - Busy with another call and want session, the relay service MUST be able to participate in two calls at
          determine the same time.
          - Text and/or speech recording services type of service requested (e.g., speech to text
          documentation/audio recording for legal/clarity/flexibility
          purposes)
          - Overcoming or
          text to speech), to indicate if the caller wants voice carry over,
          the language of the text, the sign language barriers through speech translation
          and/or transcoding services.
          - Hearing loss, tinnitus or deafness due being used (in the
          video stream), etc.

          It SHOULD be possible to route the aging process session to a preferred relay
          service even if the user invokes the session from another region
          or
          any other reason.

          NOTE: In many network than that usually used.

          A number of the above examples, text may accompany speech requirements, motivations and
          could implementation
          guidelines for relay service invocation can be displayed found in a manner similar RFC 3351
          [19].

       8. Security Considerations

          User confidentiality and privacy need to subtitling be met as described in
          broadcasting environments or any other suitable manner.  This
          could occur for individuals who are hard
          SIP [3]. For example, nothing should reveal the fact that the user
          of hearing and also for
          mixed calls ToIP is a person with a hearing disability unless the user prefers to
          make this information public. If a transcoding server is being

       A. van Wijk, et al.     Expires 21 February 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 [3] and deaf person listening SRTP
          [17].

          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 call. case that the ToIP users might need
          transcoding servers.

       9. Security Considerations

          There are no additional security requirements other than described
          earlier.

       A. van Wijk                                           [Page 23 of 28]
       10. 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 CD Groningen
          The Netherlands
          Tel: +31 50 585 77 24
          Fax: +31 50 585 77 57
          Email: willem.dijkstra@tno.nl

          Barry Dingle
          ACIF, 32 Walker Street
          North Sydney, NSW 2060 Australia
          Tel +61 (0)2 9959 9111
          Fax +61 (0)2 9954 6136
          TTY +61 (0)2 9923 1911
          Mob +61 (0)41 911 7578
          Email barry.dingle@bigfoot.com.au

          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 8019
          Fax +44(0)20 7296 8069
          Email: guido.gybels@rnid.org.uk

          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: gunnar.hellstrom@omnitor.se

       A. van Wijk, et al.     Expires 21 February 2006      [Page 24 of 28]
          Henry Sinnreich
          pulver.com
          115 Broadhollow Rd
          Suite 225
          Melville, NY 11747
          USA
          Tel: +1.631.961.8950

       A. van Wijk                                           [Page 24 of 28]

          Gregg C Vanderheiden
          University of Wisconsin-Madison
          Trace R & D Center
          1550 Engineering Dr (Rm 2107)
          Madison, Wi  53706
          USA
          gv@trace.wisc.edu
          Phone +1 608 262-6966
          FAX +1 608 262-8848
          Email: gv@trace.wisc.edu

          Arnoud A. T. van Wijk
          Viataal (Dutch Institute
          Centre for the Deaf)
          Research R & Development
          Afdeling RDS D on sensory and communication disabilities.
          Theerestraat 42
          5271 GD Sint-Michielsgestel
          The Netherlands.
          Email: a.vwijk@viataal.nl

       11.

       10. References

       11.1

       10.1 Normative references

          1. S. Bradner, S., "The Internet Standards Process -- Revision 3", "Intellectual Property Rights in IETF Technology
          ", BCP 9, 79, RFC 2026, October 1996. 3979, IETF, March 2005.

          2. S. Bradner, S., "Key words for use in RFCs to Indicate Requirement
          Levels", BCP 14, RFC 2119, IETF, March 1997

          3. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J.
          Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session
          Initiation Protocol, Protocol", RFC 3621, IETF, June 2002.

          4. ITU-T Recommendation T.140, "Protocol for Multimedia
          Application Text Conversation Conversation" (February 1998) and Addendum 1
          (February 2000).

          5. G. Hellstrom, "RTP Payload for Text Conversation, Conversation", RFC 4103,
          IETF, June 2005.

          6. G. Camarillo, H. Schulzrinne, and E. Burger, "The Source and
          Sink Attributes for the Session Description Protocol," IETF,
          August 2003 - Work in Progress.

       A. van Wijk, et al.     Expires 21 February 2006      [Page 25 of 28]
          7. G.Camarillo, "Framework for Transcoding with the Session
          Initiation Protocol" IETF June 2005 -  Work in progress.

          8. 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.

       A. van Wijk                                           [Page 25 of 28]

          9. G. Camarillo, "The SIP Conference Bridge Transcoding Model,"
          IETF, August 2003 - Work in Progress.

          10. ITU-T Recommendation V.18,"Operational and Interworking
          Requirements for DCEs operating in Text Telephone Mode," November
          2000.

          11. "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. 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.)

          14. Bell-103 300 bit/s modem.

          15. 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)"

          16.

          14. TIA/EIA/IS-127-2 "Enhanced Variable Rate Codec, Speech Service
          Option 3 for Wideband Spread Spectrum Digital Systems. Addendum
          2."

          17.

          15. 3GPP TS26.226  "Cellular Text Telephone Modem Description"
          (CTM).

          18. I. Butcher, S. Lass, D. Petrie,

          16. H. Sinnreich, S. Lass,  and C. Stredicke, "SIP Telephony
          Device Requirements, Configuration Requirements and
          Data," Configuration," IETF, February 2004 June 2005 - Work in
          Progress.

          19.

          17.  Baugher, McGrew, Carrara, Naslund, Norrman, "The Secure Real
          Time Transport Protocol (SRTP)", RFC 3711, IETF, March 2004.

          20. IP

          18. "IP Multimedia default codecs. codecs". 3GPP TS 26.235

          21.

          19. 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.

          22.

          20. J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the
          Session Description Protocol (SDP)", RFC 3624, IETF, June 2002.

          21. ITU-T Recommendation F.700,"Framework Recommendation for
          Multimedia Services", November 2000.

       A. van Wijk Wijk, et al.     Expires 21 February 2006      [Page 26 of 28]
       11.2
          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.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.)

          IV. International Telecommunication Union (ITU), "600/1200-baud
          modem standardized for use in the general switched telephone
          network. ITU-T Recommendation V.23, November 1988.

          IV. Third Generation Partnership Project (3GPP), "Technical
          Specification Group Services and System Aspects; Cellular Text
          Telephone Modem; General Description (Release 5)". 3GPP TS 26.226
          V5.0.0.

       Intellectual Property Statement

          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-ipr@ietf.org.

       A. van Wijk, et al.     Expires 21 February 2006      [Page 27 of 28]
       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

       A. van Wijk                                           [Page 27 of 28]
          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.

       Acknowledgment

          Funding for the RFC Editor function is currently provided by the
          Internet Society.

       A. van Wijk Wijk, et al.     Expires 21 February 2006      [Page 28 of 28]