SIPPING Workgroup
   Internet Draft                                           A. van Wijk (editor)
       Internet-Draft                                  Viataal
   Category: Informational                                       AnnieS
   Expires: September 5 2006                              March 6 6, 2006                           September 7 2005

             Framework of requirements for real-time text conversation over IP using SIP

                           draft-ietf-sipping-toip-03.txt

                     draft-ietf-sipping-toip-04.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79
          [1]. 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 6, September 5, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005). (2006).

Abstract

   This document provides the a framework of requirements for real-time
          character-by-character interactive the implementation of real-
   time text conversation over the IP network using the Session
   Initiation Protocol and the Real-Time Transport Protocol. It discusses lists
   the essential requirements for real-time Text-
          over-IP as well as Text-over-IP (ToIP) and
   defines a framework for implementation of all required functions
   based on existing protocols and techniques. This includes
   interworking between Text-over-IP and existing text telephony on the
   PSTN and other networks.

       A. van Wijk, et al.     Expires 6 March 2006      [Page 1 of 28]

Table of Contents

   1. Introduction.....................................................3 Introduction...................................................3
   2. Scope............................................................4 Scope..........................................................4
   3. Terminology......................................................4 Terminology....................................................4
   4. Definitions......................................................4 Definitions....................................................4
   5. Framework Description............................................6
       5.1. Requirements...................................................6
      5.1 General requirements for ToIP..................................6
       5.1.1 General ToIP Summary..........................................8
       5.2. General Requirements ToIP..............................6
      5.2 Detailed requirements for ToIP Interworking.....................8 ToIP.............................8
         5.2.1 PSTN Interworking.............................................9 Session control and set-up requirements...............8
         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 Transport requirements................................9
         5.2.3 Cellular data channel mode...................................11 Transcoding service requirements.....................10
         5.2.4 Cellular Wireless ToIP.......................................11 Presentation and User control requirements...........11
         5.2.5 Interworking requirements............................12
            5.2.5.1 PSTN Interworking requirements..................12
            5.2.5.2 Cellular Interworking requirements..............12
            5.2.5.3 Instant Messaging Support....................................11 Interworking requirements.....13
   6. Detailed requirements for ToIP..................................11
       6.1. Pre-Session Requirements......................................12 Implementation Framework......................................13
      6.1 Framework of general implementation.......................13
      6.2 Framework of detailed implementation......................14
         6.2.1 Session control and set-up...........................14
            6.2.1.1 Pre-session setup...............................14
            6.2.1.2 Basic Point-to-Point Session Requirements......................12
       6.2.1 setup..............15
            6.2.1.3 Addressing......................................15
            6.2.1.4 Session control..............................................12 Negotiations............................15
            6.2.1.5 Additional session control......................16
         6.2.2 Text transport...............................................12 Transport............................................16
         6.2.3 Session Setup................................................13 Transcoding services.................................17
         6.2.4 Addressing...................................................13
       6.2.5 Alerting.....................................................14
       6.2.6 Session information..........................................14
       6.2.7 Session progress information.................................14
       6.2.8 Session Negotiations.........................................15
       6.2.9 Answering....................................................15
       6.2.9.1 Answering Machine..........................................15
       6.2.10 Actions During 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..................................17
       6.2.12 File storage................................................17
       6.3 Conference Session Requirements................................17
       6.4 Real-time Editing Presentation and User Alerting............................17
       6.5 Emergency services.............................................17
       6.6 User Mobility..................................................18
       6.7 Firewalls control functions..............18
            6.2.4.1 Progress and NATs.............................................18
       7. Interworking Requirements for ToIP..............................18
       7.1 ToIP status information.................18
            6.2.4.2 Alerting........................................18
            6.2.4.3 Answering Machine...............................18
            6.2.4.4 Text presentation...............................19
            6.2.4.5 File storage....................................19
         6.2.5 Interworking Gateway Services.............................18
       7.2 ToIP and PSTN/ISDN Text-Telephony Interworking.................18
       7.3 ToIP and functions...............................19
            6.2.5.1 PSTN Interworking...............................20
            6.2.5.2 Mobile Interworking.............................21
               6.2.5.2.1 Cellular Wireless ToIP................................19
       7.4 "No-gain".........................21
               6.2.5.2.2 Cellular Text Telephone Modem (CTM)........21
               6.2.5.2.3 Cellular "Baudot mode".....................22
               6.2.5.2.4 Mobile data channel mode...................22
               6.2.5.2.5 Mobile ToIP................................22
            6.2.5.3 Instant Messaging Support......................................19
       7.5 Common Text Gateway Functions..................................20
       7.5.1 Protocol support.............................................20
       7.5.2 Relay buffer storage.........................................20
       7.5.3 Emergency calls Interworking..................22
            6.2.5.4 Interworking through gateways.............................21
       7.5.4 Text Gateway Invocation......................................21
       7.6 gateways...................23
            6.2.5.5 Multi-functional Combination gateways...........24
            6.2.5.6 Character set transcoding.......................25
   7. Further recommendations for implementers and service providers25
      7.1 Access to Emergency services..............................25
      7.2 Home Gateways or Analog Terminal Adapters......................21
       7.7 Multi-functional Combination gateways..........................22

       A. van Wijk, et al.     Expires 6 March 2006      [Page 2 of 28]
       7.8 Transcoding....................................................22
       7.9 Relay Services.................................................23
       7.9.1 Basic function of the relay service..........................23
       7.9.2 Invocation of relay services.................................23 Adapters.................26
      7.3 User Mobility.............................................26
      7.4 Firewalls and NATs........................................26
   8. Security Considerations.........................................23 IANA Considerations...........................................26
   9. Authors Addresses...............................................24 Security Considerations.......................................26
   10. References.....................................................25
       10.1 Authors’ Addresses...........................................27
   11. References...................................................28
      11.1 Normative references..........................................25
       10.2 references.....................................28
      11.2 Informative references........................................27 references...................................30

1.
  Introduction

   For many years, text has been in use as a medium for conversational,
   interactive dialogue between users in a similar way to how voice
   telephony is used. Such interactive text is different from messaging
   and semi-interactive solutions like Instant Messaging in that it
   offers an equivalent conversational experience to users who cannot,
   or do not wish to, use voice. It therefore meets a different set of
   requirements from other text-
          based text-based solutions already available on IP
   networks.

   Traditionally, deaf, hard of hearing and speech-impaired people are
   amongst the most prolific users of conversational, interactive text
   but, because of its interactivity, it is becoming popular amongst
   mainstream users as well.

   This document describes how existing IETF protocols can be used to
   implement a Text-over-IP solution (ToIP). This ToIP framework is
   specifically designed to be compatible with Voice-over-IP (VoIP) and
   Multimedia-over-IP (MoIP) environments, as well as meeting the userÆs user’s
   requirements, including those of deaf, hard of hearing and speech-impaired speech-
   impaired users as described in RFC3351 [19]. [2] and mainstream users.

   The Session Initiation Protocol (SIP) [3] is the protocol of choice
   for control of Multimedia communications and Voice-over-IP (VoIP) in
   particular. It offers all the necessary control and signaling
   required for the ToIP framework.

   The Real-Time Transport Protocol (RTP) [4] is the protocol of choice
   for real-time data transmission, and its use for interactive real-time 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, multi-media services, including
   Total Conversation.

       A. van Wijk, et al.     Expires 6 March 2006      [Page 3 of 28] Conversation [6].

2.
  Scope

   This document defines a framework for the implementation of real-
          time real-time
   ToIP, either stand-alone or as a part of multimedia services,
   including Total Conversation. Conversation [6]. It defines the:

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

3.
  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14, RFC 2119 [2] [7] and indicate requirement levels for
   compliant implementations.

4.
  Definitions

   Audio bridging - bridging: a function of a an audio media bridge server, gateway
   or relay service that
          enables bridges audio into a single source through
   combining audio from multiple users excluding each destination
   source’s audio and sends to each respective destination enabling an
   audio path through the service between the users involved in the
   call.

          Cellular - Telephone systems based on radio transmission to become
          wireless.

   Cellular: a telecommunication network that has wireless access and
   can support voice and data services over very large geographical
   areas. Also called Wireless or Mobile systems. Mobile.

   Full duplex - duplex: media is sent independently in both directions.

   Half duplex - duplex: media can only be sent in one direction at a time or, if
   an attempt to send information in both directions is made, errors can
   be introduced into the presented media.

   Interactive text: a term for real time transmission of text - in a
   character-by-character fashion for use in conversational services,
   often as a text equivalent to voice based conversational services.
   (Equivalent to real-time text.)

   Real-time text: a term for real time transmission of text in a
   character-by-character fashion for use in conversational services,
   often as a text equivalent to voice based conversational services.

          Textphone û
   Conversational text is defined in ITU-T F.700 Framework for
   multimedia services [25].

   Text gateway: a function that transcodes between different forms of
   real-time text transport methods, e.g., between ToIP in IP networks
   and Baudot or ITU-T V.21 text telephony in the PSTN.

   Textphone: also "text telephone". A terminal device that allows
          end-to-end end-
   to-end real-time, interactive text communication using analog
   transmission. A variety of PSTN textphone protocols exists world-
   wide. A textphone can often be combined with a voice telephone, or
   include voice communication functions for simultaneous or alternating
   use of text and voice in a call.

   Text bridging - bridging: a function of a gateway service that enables the flow
   of text through the service between the users involved in the call.

   Text gateway - a function that transcodes between different forms
          of text transport methods, e.g., between ToIP in IP networks and
          Baudot or ITU-T V.21 text telephony in the PSTN.

       A. van Wijk, et al.     Expires 6 March 2006      [Page 4 of 28]
          Text Relay Service - Service: a third-party or intermediary that enables
   communications between deaf, hard of hearing and speech-impaired
   people, and voice telephone users by translating between voice and
   real-time text in a call.

   Text telephony û Bridging: a function of the text media bridge server, gateway or
   relay service that bridges real-time text into a single source
   through combining real-time text from multiple users excluding each
   destination source’s real-time text and sends to each respective
   destination enabling a real-time text path through the service
   between the users involved in the call.

   Text telephony: analog textphone service.

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

   Transcoding Services - Services: services of a third-party user agent that
   transcodes one stream into another. Transcoding can be done by human
   operators, in an automated manner or a combination of both methods.
   Text Relay Services are examples of a transcoding service between
   real-time text and audio.

          TTY û

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

   Video Relay Service - Service: A service that enables communications between
   deaf and hard of hearing people, and hearing persons with voice
   telephones by translating between sign language and spoken language
   in a call.

   Acronyms:

   2G     Second generation cellular (mobile)
   2.5G   Enhanced second generation cellular (mobile)
   3G     Third generation cellular (mobile)
   CDMA   Code Division Multiple Access
   CLI    Calling Line Identification
   CTM    Cellular Text Telephone Modem
   ENUM   E.164 number storage in DNS (see RFC3761)
   GSM    Global System of Mobile Communication
   ISDN   Integrated Services Digital Network
   ITU-T  International Telecommunications Union-Telecommunications
          Standardisation Sector
   NAT    Network Address Translation
   PSTN   Public Switched Telephone Network
   RTP    Real Time Transport Protocol
   SDP    Session Description Protocol
   SIP    Session Initiation Protocol
   SRTP   Secure Real Time Transport Protocol
   TDD    Telecommunication Device for the Deaf
   TDMA   Time Division Multiple Access
   TTY    Analog textphone (Teletypewriter)
   ToIP   Real-time Text over Internet Protocol
   UTF-8  Universal Transfer Format-8
   VCO/HCO Voice Carry Over/Hearing Carry Over
   VoIP   Voice over Internet Protocol

       A. van Wijk, et al.     Expires 6 March 2006      [Page 5 of 28]

5. Framework Description
  Requirements

   This framework defines the requirements of a text-based conversational service that is
   the text equivalent of voice based telephony. This section describes
   the requirements that the framework is designed to meet and the
   functionality it should offer.

   Real-time text conversation can be combined with other conversational
   services like video or voice.

   ToIP also offers an IP equivalent of analog text telephony services
   as used by deaf, hard of hearing hearing, speech-impaired and mainstream
   users.

   This section (Requirements) informs implementers about WHICH
   requirements the systems and services shall meet. The next section
   (Section 6 Framework Implementation) describes HOW to do it.

5.1
   General requirements for ToIP

   Any framework for ToIP must be designed to meet the requirements of
   RFC3351 [2]. A basic requirement is that it must provide a
   standardized way for offering text-based, conversational services
   that can be used as an equivalent to voice telephony by deaf, hard of
   hearing speech-impaired
          individuals. and mainstream users.

   It is important to understand that real-time text conversations are
   significantly different from other text-based communications like
   email or instant messaging. Instant Messaging. Real-time text conversations deliver an
   equivalent mode to voice conversations by providing transmission of
   text character by character as it is entered, so that the
   conversation can be followed closely and immediate interaction takes take
   place. This provides the same mode of
          interaction as voice telephony does for hearing people.

   Store-and-forward systems like email or messaging on mobile networks
   or non-streaming systems like instant messaging are unable to provide
   that functionality. In particular, they do not allow for smooth
   communication through a Text Relay Service.

          This framework uses existing standards that are already commonly
          used for voice based conversational services on IP networks. It
          uses the Session Initiation Protocol (SIP) to set up, control and
          tear down the connections between users whilst the media is
          transported using the Real-Time Transport Protocol (RTP) as
          described in RFC4103 [5].

          This framework is designed to meet the requirements of RFC3351
          [19]. As such, it offers a standardized way for offering text-
          based, conversational services that can be used as an equivalent
          to voice telephony by deaf, hard of hearing and speech-impaired
          individuals.

          SIP allows participants to negotiate all media including real-time
          text conversation [4,5]. This is a highly desirable function for
          all IP telephony users but essential for deaf, hard of hearing, or
          speech impaired people who have limited or no use of the audio
          path of the call.

       5.1. General requirements for ToIP

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

   a. Offer real-time transport and presentation of the conversation;
   b. Provide simultaneous transmission in both directions;
   c. Support both point-to-point and multipoint communication;

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

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

          Users

   Deaf, hard-of-hearing and mainstream users may invoke ToIP services
   for many different reasons:

   - Because they are in a noisy environment, e.g., in a machine room of
   a factory where listening is difficult.
   - Because they are busy with another call and want to participate in
   two calls at the same time.
   - For implementing text and/or speech recording services (e.g., text
   documentation/ audio recording for legal/clarity/flexibility
   purposes).
   - To overcome language barriers through speech translation and/or
   transcoding services.
   - Because of hearing loss, deafness or tinnitus as a result of the
   aging process or for any other reason, thus creating a need to
   replace or complement voice with real-time text in conversational
   sessions.

          NOTE:

   In many of the above examples, text may accompany speech. The text
   could be displayed side by side, or in a manner similar to subtitling
   in broadcasting environments, or in any other suitable manner.  This
   could occur for with users who are hard of hearing and also for mixed
   media calls with both hearing and deaf people participating in the
   call.

          User Agents providing

   A ToIP functionality need user may wish to provide suitable
          alerting indications, specifically offering visual and/or tactile
          alerting call another ToIP user, or join a conference
   session involving several users or initiate or join a multimedia
   session, such as a Total Conversation session.

5.2
   Detailed requirements for deaf and hard of hearing users. ToIP

   The ability of SIP following sections lists individual requirements for ToIP. Each
   requirement has been given a uniquely identifier (R1, R2, etc).
   Section 6 (Implementation Framework) describes how to implement ToIP
   based on these requirements and using existing protocols and
   techniques.

5.2.1
     Session control and set-up requirements

   Users will set up conversation sessions from any
          location, as well as its privacy and security provisions, MUST be
          maintained a session by ToIP services.

          Where ToIP identifying the remote party or the
   service they want to connect to. However, conversations could be
   started using a mode other than the real-time text.

   Simultaneous or alternating use of voice and real-time text is used in conjunction with other media, exposure
   by a large number of
          SIP functions through the User Interface needs users who can send voice but must receive text
   (due to a hearing impairment), or who can hear but must send text
   (due to a speech impairment).

   R1: It SHOULD be done possible to start conversations in an
          equivalent manner for all supported media. In other words, where
          certain SIP call control functions are available for the audio
          media part any mode (real-
   time text, voice, video) or combination of the session, these functions modes.

   R2: It MUST also be supported possible for the users to switch to real-time text, or
   add real-time text media part of as an additional modality, during the same session. For example, call
          transfer must act on all media in
   conversation.

   R3: Systems supporting ToIP MUST allow users to select any of the session.

          T.140 real-time text
   supported conversation [4], in addition modes at any time, including mid-conversation.

   R4: Systems SHOULD allow the user to audio and
          video communications, is specify a valuable service for many users,
          including those on non-IP networks. T.140 also provides for real-
          time editing preferred mode of
   communication, with the text.

       A. van Wijk, et al.     Expires 6 March 2006      [Page 7 ability to fall back to alternatives that the
   user has indicated are acceptable.

   R5: If the user requests simultaneous use of 28]
       5.1.1 General ToIP Summary

          The general requirements for ToIP are:

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

          b. Registration procedures
   audio, and address resolutions

          c. Registration 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.

   R6: If the user preferences

          d. Negotiation procedures has expressed a preference for device capabilities

          e. Support real-time text,
   establishment of a connection including real-time text media transport using T.140 MUST have
   priority over RTP as
             described in RFC 4103 [5]

          f. Signaling other outcomes of status information, call progress and the like in
             a suitable manner, bearing in mind that session setup.

   R7: It SHOULD be possible to use the user may have a
             hearing impairment

          g. T.140 real-time text presentation mixing with voice and video

          h. T.140 real-time text conversation medium in
   conference sessions using SIP, allowing
             users to move from one place in a similar way to another

          i. User privacy and security for sessions setup, modification, how audio is handled and
             teardown as well as
   video is displayed.

   Real-time text in conferences can be used both for media transfer

          j. Routing of emergency calls according letting individual
   participants use the text medium (for example, for sidebar
   discussions in text while listening to national or regional
             policy with the same level of functionality main conference audio), as
   well as a voice call.

       5.2. General Requirements for ToIP Interworking

          This section describes the general ToIP interworking requirements
          and gives some background information to many central support of the issues.

          There is a range of existing text services. There is also a range
          of network technologies that could support text services (see
          examples below). ToIP needs to provide interoperability conference with real time text
          conversation features in other networks,
   interpretation of speech.

   R8: During session set up, it SHOULD be possible for instance the PSTN, users to
   indicate if the caller wants to use voice and with some real-time text messaging services.

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

          When communicating via a gateway to other networks
   simutaneously as part of the conversation.

   R9: Session set up and protocols, negotiation of modalities must allow users to
   specify the ToIP service SHOULD support language of the real-time text to be used. (It is
   recommended that similar functionality is provided for alternating
          or simultaneous use of modalities as offered by the destination
          network.

       A. van Wijk, et al.     Expires 6 March 2006      [Page 8 video part
   of 28]
          Address information, both called and calling, SHOULD be
          transferred, and possibly converted, when interworking between
          different networks. the conversation, i.e. to specify the sign language being used).

5.2.2
     Transport requirements

   ToIP will often be used to access a relay service [I], allowing real-
   time text users to communicate with voice users. With relay services,
   it is crucial that text characters are sent as soon as possible after
   they are entered. While buffering may be done to improve efficiency,
   the delays SHOULD be kept minimal. In particular, buffering of whole
   lines of text will not meet character delay requirements.

          If the User Agents

   R10: Characters must be transmitted soon after entry of different participants indicate each
   character so that the maximum delay requirement can be met. A delay
   time of one second is regarded good, while a delay of two seconds is
   possible to use.

   R11: It must be possible to transmit characters at a rate sufficient
   to support fast human typing as well as speech to text methods of
   generating conversation text. A rate of 20 characters per second is
   regarded sufficient.

   R12: a ToIP service must be able to deal with international character
   sets.

   R13: Where it is possible, loss of real-time text during transport
   should be detected and the user should be informed.

   R14: Transport of real-time text should be as robust as possible, so
   as to minimize loss of characters.

   R15: Where possible, it must be possible to send and receive real-
   time text simultaneously.

5.2.3
     Transcoding service requirements

   If the User Agents of different participants indicate that there is
   an incompatibility between their capabilities to support certain
   media types, e.g. one terminal only offering T.140 over IP as
   described in RFC4103 [5] and the other one only supporting audio, the
   user might want to invoke a transcoding service.

          Examples

   Some users may indicate their preferred modality to be audio while
   others may indicate real-time text. In this case, transcoding
   services might be needed for text-to-speech (TTS) and speech-to-text
   (STT). Other examples of possible scenarios for including a relay
   service in the conversation are: speech-to-text (STT), text-to-speech (TTS), text bridging after conversion from
   speech, audio bridging after conversion from real-time text, etc.

          The general requirements for ToIP Interworking are:

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

          b. Discovery

   A number of requirements, motivations and implementation guidelines
   for relay service invocation of transcoding/translation services
             between the media can be found in the call

          c. Different session establishment models RFC 3351 [2].

   R16: It MUST be possible for users to invoke a transcoding service
   where such service is available.

   R17: It MUST be possible for users to indicate their preferred
   modality.

   R18: The requirements for transcoding /
             translation services invocation: Third party call control and
             conference bridge model

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

          e. Media bridging services for T.140 real-time text, as described
             in RFC4103 [5], audio and video set up the session.

   R19: Adding or removing a relay service MUST be possible without
   disrupting the current session.

   R20: When setting up a session, it MUST be possible for multipoint communications

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

          g. Buffering a user to
   determine the type of relay service requested (e.g., speech to text when interworking with media that transport
             text at different rates.

       5.2.1 PSTN Interworking

          Analog
   or text telephony is cumbersome because of incompatible
          national implementations where interworking was never considered.

       A. van Wijk, et al.     Expires 6 March 2006      [Page 9 to speech). The specification of 28]
          A large number a type of these implementations have been documented in
          ITU-T V.18 [10], which also defines relay MUST include
   a language specifier.

   R21: It SHOULD be possible to route the modem detection sequences
          for session to a preferred relay
   service even if the different text protocols. The modem type identification
          may in rare cases take considerable time depending on user
          actions.

          To resolve analog textphone incompatibilities, text telephone
          gateways are needed to transcode invokes the session from another region or
   network than that usually used.

5.2.4
     Presentation and User control requirements

   R22: User Agents for ToIP services must have alerting methods (e.g.,
   for incoming analog signals into
          T.140 sessions) that can be used by deaf and vice versa. The modem capability exchange time hard of hearing
   people or provide a range of alternative, but equivalent, alerting
   methods that can be
          reduced selected by the all users, regardless of their
   abilities.

   R23: Where real-time text telephone gateways initially assuming the
          analog text telephone protocol is used in conjunction with other media,
   exposure of user control functions through the region User Interface needs
   to be done in an equivalent manner for all supported media.

   In other words, where certain call control functions are available
   for the
          gateway is located. audio media part of a session, these functions MUST also be
   supported for the real-time text media part of the same session. For
   example, call transfer must act on all media in the USA, Baudot [III] might be
          tried as the initial protocol. session.

   R24: If negotiation for Baudot fails, present, identification of the full V.18 modem capability exchange will take place. In originating party (for example
   in the
          UK, ITU-T V.21 [II] might form of a URL or a CLI) MUST be clearly presented to the first choice.

       5.2.2 Cellular circuit switched Text-Telephony

          Cellular wireless (or Mobile) circuit switched connections provide user
   in a digital real-time transport service form suitable for voice or data. The
          access technologies include GSM, CDMA, TDMA, iDen and various 3G
          technologies.

          Alternative means of transferring the Text telephony data have
          been developed when TTY services over cellular was mandated by the
          FCC in user BEFORE the USA. They are a) "No-gain" codec solution, b) session invitation is
   answered.

   R25: When a session invitation involving ToIP originates from a PSTN
   text telephone (e.g. transcoded via a text gateway), this SHOULD be
   indicated to the
          Cellular Text Telephony Modem (CTM) solution and c) "Baudot mode"
          solution. user. The GSM and 3G standards from 3GPP make use of ToIP client MAY adjust the CTM modem in presentation of
   the voice channel for real-time text telephony. However, implementations
          also exist that use to the data channel user as a consequence.

   R26: An indication should be given to provide such
          functionality. Interworking the user when real-time text is
   available during the call, even if it is not invoked at call setup
   (e.g. when only voice and/or video is used initially).

   R27: The user MUST be informed of any change in modalities.

   R28: Users must be presented with these solutions appropriate session progress
   information at all times.

   R29: Answering machine functions SHOULD be done
          using text gateways that set up provided by the data channel connection at User
   Agent.

   R30: When the
          GSM side answering machine function is enabled on the User
   Agent, alerting of the user SHOULD still be possible and provide ToIP users SHOULD
   be able to take over control from the answering machine function at
   any time.

   R31: Users SHOULD be able to save the other side.

       5.2.2.1 Cellular "No-gain"

          The "No-gain" text telephone transporting technology uses
          specially modified EFR [13] and EVR [14] speech vocoders portion of a conversation.

   R32: The presentation of the conversation should be done in mobile
          terminals used to provide such a text telephony call. It provides full
          duplex operation and supports alternating voice and text
          ("VCO/HCO"). It
   way that users can easily identify which party generated any given
   portion of text.

5.2.5
     Interworking requirements

   There is dedicated to CDMA and TDMA mobile technologies
          and the US Baudot (i.e. 45 bit/s) type a range of existing real-time text telephones.

       5.2.2.2 Cellular Text Telephone Modem (CTM)

          CTM [15] services. There is also a technology independent modem technology that
          provides the transport
   range of text telephone characters at up to 10
          characters/sec using modem signals network technologies that can be carried by many
          voice codecs could support real-time text
   services.

   Real-time/Interactive texting facilities exist already in various
   forms and uses a highly redundant encoding technique to
          overcome on various networks. On the fading and cell changing losses.

       A. van Wijk, et al.     Expires 6 March 2006      [Page 10 of 28]
       5.2.2.3 Cellular "Baudot mode"

          This term PSTN, it is often commonly referred
   to as text telephony.

   Text gateways are used by cellular terminal suppliers for converting between different media types.
   They could be used between networks or within networks where
   different transport technologies are used.

   R33: ToIP SHOULD provide interoperability with text conversation
   features in other networks, for instance the PSTN.

   R34: When communicating via a GSM
          cellular phone mode that allows TTYs gateway to operate into a cellular
          phone other networks and to communicate with a fixed line TTY.

       5.2.3 Cellular data channel mode

          Many mobile terminals allow
   protocols, the use of ToIP service SHOULD support the data channel to
          transfer data in real-time. Data rates functionality for
   alternating or simultaneous use of 9600 bit/s are usually
          supported on modalities as offered by the mobile
   interworking network. Gateways provide interoperability
          with PSTN textphones.

       5.2.4 Cellular Wireless ToIP

          ToIP could

   R35: Address information, both called and calling, SHOULD be supported over cellular wireless packet switched
          services that interface to the Internet. For 3GPP 3G
   transferred, and possibly converted, when interworking between
   different networks.

   R36: When interworking with other networks and services, the
          support is described to use ToIP in 3G TS 26.235 [18]. Low data
          rates and additional
   service SHOULD provide buffering mechanisms to deal with delays can affect performance.

       5.2.5 Instant Messaging Support

          Many people use Instant Messaging in
   call setup, transmission speeds and/or to communicate via the Internet
          using text. Instant Messaging transfers blocks of interwork with half duplex
   services.

5.2.5.1
       PSTN Interworking requirements

   Analog text rather than
          streaming telephony is being used in many countries, mainly by
   deaf, hard of hearing and speech-impaired individuals.

   R37: ToIP services MUST provide interworking with PSTN legacy text
   telephony devices.

   R38: When interworking with PSTN legacy text telephony services,
   alternating text and voice function MAY be supported. (Called "voice
   carry over (VCO) and hearing carry over (HCO)").

5.2.5.2
       Cellular Interworking requirements

   As mobile communications have been adopted widely, various solutions
   for real-time texting while on the move have been developed. ToIP
   services should provide interworking with such services as well.

   Alternative means of transferring the Text telephony data have been
   developed when TTY services over cellular was mandated by the FCC in
   the USA. They are a) "No-gain" codec solution, b) the Cellular Text
   Telephony Modem (CTM) solution [8] and c) "Baudot mode" solution.

   The GSM and 3G standards from 3GPP make use of the CTM modem in the
   voice channel for text telephony. However, implementations also exist
   that use the data channel to provide such functionality. Interworking
   with these solutions SHOULD be done using text gateways that set up
   the data channel connection at the GSM side and provide ToIP at the
   other side.

   R39: a ToIP service SHOULD provide interworking with mobile text
   conversation services.

5.2.5.3
       Instant Messaging Interworking requirements

   Many people use Instant Messaging to communicate via the Internet
   using text. Instant Messaging usually transfers blocks of text rather
   than streaming as is used by ToIP. Usually a specific action is
   required by the user to activate transmission, such as pressing the
   ENTER key or a send button. As such, it is not a replacement for ToIP
   and in particular does not meet the needs for real time conversations
   including those of deaf, hard of hearing and speech-
          impaired speech-impaired users as
   defined in RFC 3351 [19]. [2]. It is unsuitable for communications through
   a relay service [I]. The streaming nature of ToIP provides a more
   direct conversational user experience and, when given the choice,
   users may prefer ToIP.

          Text gateways could be developed to allow

   R39: a ToIP service MAY provide interworking between with Instant Messaging systems and ToIP solutions.
   services.

6. Detailed requirements
  Implementation Framework

   This section describes an implementation framework for ToIP

          A that
   meets the requirements and offers the functionality as set out in
   section 5. The framework presented here uses existing standards that
   are already commonly used for voice based conversational services on
   IP networks.

6.1
   Framework of general implementation

   ToIP user may wish uses the Session Initiation Protocol (SIP) [3] to call another ToIP user, or join a
          conference session involving several set up,
   control and tear down the connections between users or initiate or join a
          multimedia session, such whilst the media
   is transported using the Real-Time Transport Protocol (RTP) [4] as
   described in RFC4103 [5].

   SIP [3] allows participants to negotiate all media including real-
   time text conversation [5]. This is a Total Conversation session.

          There may be some need highly desirable function for pre-session setup e.g. storing
   all IP telephony users but essential for deaf, hard of hearing, or
   speech impaired people who have limited or no use of the audio path
   of
          registration information in the call. Even for mainstream users, media negotiations like real-
   time text are also very useful in many circumstances as described
   earlier.

   The ability of SIP registrar, to provide
          information about how a user can be contacted. This will allow
          sessions to be set up rapidly and with proper routing conversation sessions from any location,
   as well as its privacy and
          addressing.

          Similarly, there are requirements that need to security provisions, MUST be satisfied during
          session set up when other media are preferred maintained by a user. For
          instance, some users may indicate their preferred modality
   ToIP services.

   Real-time text conversation based on the presentation protocol T.140
   [9], in addition to be audio while others may indicate and video communications, is a valuable
   service for many users, including those on non-IP networks. T.140
   also provides for basic real-time editing of the text. In this case, transcoding

6.2
   Framework of detailed implementation

6.2.1
     Session control and set-up

   ToIP services might be needed MUST use the Session Initiation Protocol (SIP) [3] for text-to-speech (TTS)
   setting up, controlling and speech-to-

       A. van Wijk, et al.     Expires 6 March 2006      [Page 11 of 28] terminating sessions for real-time text (STT).
   conversation with one or more participants and possibly including
   other media like video or audio. The session description protocol
   (SDP) used in SIP to describe the session is used to express the
   attributes of the session and to negotiate a set of compatible media
   types.

6.2.1.1
       Pre-session setup

   The requirements for transcoding services need of the user to be
          negotiated reached at a consistent address
   and to store preferences for evaluation at session setup are met by
   pre-session setup actions. That includes storing of registration
   information in real-time the SIP registrar, to provide information about how a
   user can be contacted. This will allow sessions to be set up the session.

          The subsequent subsections describe some of these requirements in
          detail.

       6.1. Pre-Session Requirements rapidly
   and with proper routing and addressing.

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

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

   b. Server to support of User Preferences: SIP servers that support ToIP
   services MUST have the capability to act on calling user preferences
   for real-time text in order to accept or reject the session-, session.The
   actions taken can be based on the called userÆs user’s preferences defined
   as part of the pre-session setup registration. For example, if the
   user is called by another party, and it is determined that a
   transcoding server is needed, the session MUST should be re-directed or
   otherwise handled accordingly.

       6.2

6.2.1.2
       Basic Point-to-Point Session Requirements setup

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

       6.2.1 Session control

   The following features MAY be implemented to facilitate the session
   establishment using ToIP:

   a. Caller Preferences: SIP headers (e.g., Contact)[11] can be used to
   show that ToIP services MUST use is the Session Initiation Protocol (SIP) [3]
          for setting up, controlling and terminating sessions medium of choice for real-time
          text conversation with one or more participants and possibly
          including other media like video or audio. communications.

   b. Called Party Preferences [12]: The called party being passive can
   formulate a clear rule indicating how a session description
          protocol (SDP) [6] used in should be handled
   either using real-time text as a preferred medium or not, and whether
   a designated SIP proxy needs to describe the handle this session or it will be
   handled in the SIP user agent.

   c. SIP Server support for User Preferences: It is used to
          express RECOMMENDED that
   SIP servers also handle the attributes incoming sessions in accordance with
   preferences expressed for real-time text. The SIP Server can also
   enforce ToIP policy rules for communications (e.g. use of the session and to negotiate a set of
          compatible media types.

       6.2.2 Text transport

          A ToIP service
   transcoding server for ToIP).

6.2.1.3
       Addressing

   The SIP [3] addressing schemes MUST always support at least one Text media type. be used for all entities in a
   ToIP services MUST support the Real-Time Transport session. For example, SIP URL’s or Tel URL’s are used for
   caller, called party, user devices, and servers (e.g., SIP server,
   Transcoding server).

6.2.1.4
       Session Negotiations

   The Session Description Protocol (RTP)
          [24] according (SDP) used in SIP [3] provides the
   capabilities to indicate real-time text as a medium in the specification of RFC4103 session
   setup. RFC 4103 [5] for uses the
          transport RTP payload types "text/red" and
   "text/t140" for support of text between participants.

          RFC4103 describes ToIP which can be indicated in the transmission of T.140 [4] on IP networks.

       A. van Wijk, et al.     Expires 6 March 2006      [Page 12 of 28]
       6.2.3 Session Setup

          Users will set up SDP as
   a session by identifying part of the remote party or the
          service they want to connect to. However, conversations could SIP INVITE, OK and SIP/200/ACK media negotiations. In
   addition, SIP’s offer/answer model [13] can also be
          started using a mode used in
   conjunction with other than text. For instance, the
          conversation might be established using audio and the user could
          subsequently elect to switch to text, or add text as an additional
          modality, during capabilities including the conversation. Systems supporting ToIP MUST
          allow users to select any use of the supported conversation modes at
          any time, including mid-conversation. a
   transcoding server for enhanced session negotiations [14,15,16].

   Systems SHOULD allow the user to specify provide a preferred mode of
          communication, with the ability to fall back best-effort approach to alternatives that answering
   invitations for session set-up and users SHOULD be informed when the user has indicated are acceptable.

          If
   session is accepted by the user requests simultaneous use other party. On all systems that both
   inform users of text and audio, session status and support ToIP, this
          is not possible either because the system only supports alternate
          modalities or because of constraints information
   MUST be available in the network, the system textual form and MAY also be provided in other
   media.

6.2.1.5
       Additional session control

   Systems that support additional session control features, for example
   call waiting, forwarding, hold etc on voice sessions, MUST try offer this
   functionality for text sessions.

6.2.2
     Transport

  A ToIP service MUST always support at least one real-time text media
  type.

   ToIP services MUST support the Real-Time Transport Protocol (RTP) [4]
   according to establish communication with best effort. If the user
          has expressed a preference specification of RFC4103 [4] for text, establishment the transport of a connection
          including
   text MUST have priority over other outcomes of the
          session setup.

          The following features MAY be implemented to facilitate between participants.

   RFC4103 describes the
          session establishment using ToIP:

          a. Caller Preferences: SIP headers (e.g., Contact)[24] can be used transmission of T.140 [9] real-time text on IP
   networks.

   In order to show that ToIP is enable the medium use of choice international character sets, the
   transmission format for communications.

          b. Called Party Preferences: The called party being passive can
             formulate a clear rule indicating how a session should text conversation SHALL be
             handled either using UTF-8 [17], in
   accordance with ITU-T T.140.

   If real-time text as a preferred medium or not, and
             whether a designated SIP proxy needs is detected to handle this session or
             it will be handled missing after transmission, there
   SHOULD be a "text loss" indication in the SIP user agent.

          c. SIP Server support for User Preferences: SIP servers can also
             handle the incoming sessions real-time text as specified
   in accordance with preferences
             expressed for ToIP. The SIP Server can also enforce T.140 Addendum 1 [9].

   ToIP policy
             rules uses RTP as the default transport protocol for communications (e.g. use the transmission
   of real-time text via the transcoding server
             for ToIP).

       6.2.4 Addressing medium "text/t140" as specified in RFC 4103
   [5].

   The SIP [3] addressing schemes MUST redundancy method of RFC 4103 [5] SHOULD be used for all entities in a
          ToIP session. For example, SIP URLÆs or Tel URLÆs are used for
          caller, called party, user devices, and servers (e.g., SIP server,
          Transcoding server).

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

       A. van Wijk, et al.     Expires 6 March 2006      [Page 13 of 28]
       6.2.5 Alerting

          User Agents supporting ToIP real-time text transmission. A
   redundancy level using 2 generations gives very reliable results and
   is therefore strongly RECOMMENDED.

   Real-time text capability MUST have an alerting method (e.g.,
          for incoming sessions) that can be used announced in SDP by deaf and hard of
          hearing people or provide a range of alternative, but equivalent,
          alerting methods that can be selected by all users, regardless of
          their abilities.

          It should be noted that external alerting systems exist declaration
   similar to this example:

        m=text 11000 RTP/AVP 100 98
        a=rtpmap:98 t140/1000
        a=rtpmap:100 red/1000
        a=fmtp:100 98/98/98
   By having this single coding and one
          common interface transmission scheme for triggering the alerting action is a contact
          closure between two conductors.

          Among the alerting options are alerting by the User AgentÆs User
          Interface and specific alerting user agents registered to the same
          registrar as the main user agent.

       6.2.6 Session information

          If present, identification of the originating party (for example real time
   text defined in the form of a URL or a CLI) MUST be clearly presented to SIP session control environment, the
          user in a form suitable opportunity
   for the user BEFORE the session invitation interoperability is answered. When a session invitation involving ToIP originates
          from a gateway, this optimized. However, if good reasons exist,
   other transport mechanisms MAY be signaled to offered and used for the user.

          The user MUST be informed of any change in modalities.

       6.2.7 Session progress information

          During a conversation T.140
   coded text provided that includes ToIP, status and session
          progress information proper negotiation is introduced, but RFC
   4103 [5] transport MUST be provided in used as both the default and the fallback
   transport.

   Real-time text transmission from a textual form so users
          can perform all session control functions. That information MUST terminal SHALL be equivalent to session progress information delivered performed
   character by character as entered, or in any
          other format, for example audio.

          Session progress information SHOULD use simple language small groups of characters,
   so that as
          many users as possible can understand it. The use of jargon or
          ambiguous terminology SHOULD be avoided. It no character is RECOMMENDED that
          text information be used together with icons delayed from entry to symbolise the
          session progress information.

          There MUST be a clear indication, in transmission by more
   than 300 milliseconds.

   The text transmission SHALL allow a modality useful rate of at least 30 characters
   per second.

6.2.3
     Transcoding services

   The right to the
          user, whenever include a session is connected or disconnected. A transcoding service MUST NOT require user
          SHOULD never be
   registration in doubt about the status any specific SIP registrar, but MAY require
   authorisation of the session, even if
          the user is unable SIP registrar to make use of invoke the audio or visual indication.
          For example, tactile indications could be used by deafblind
          individuals.

          In summary, it SHOULD be possible to observe indicators about:
          - Incoming session
          - Availability service.

   A specific type of text, voice and video channels
          - Session progress
          - Incoming text
          - Any loss transcoding service in incoming text

       A. van Wijk, et al.     Expires 6 March 2006      [Page 14 of 28]
          - Typed and transmitted text.

          For users who cannot use the audible alerter for incoming
          sessions, it a ToIP environment is RECOMMENDED to include a tactile as well
   relay service. The relay service acts as a
          visual indicator.

       6.2.8 Session Negotiations an intermediary between two
   or more callers using different media or different media encoding
   schemes.

   The Session Description Protocol (SDP) used in SIP [3] provides
          the capabilities to indicate basic text as relay service allows a medium in the session
          setup. RFC 4103 [5] uses the RTP payload type "text/t140" for
          support translation of ToIP speech to real-
   time text and real-time text to speech, which can be indicated in the SDP as a part of the
          SIP INVITE, OK enables hearing and SIP/200/ACK media negotiations. In addition,
          SIPÆs offer/answer model [20] can also be used in conjunction
   speech impaired callers to communicate with hearing callers. Even
   though this document focuses on ToIP, we want to remind readers that
   other capabilities including the use of a relay services exist, like video relay services transcoding server for
          enhanced session negotiations [7,8,9].

       6.2.9 Answering

          Systems SHOULD provide a best-effort approach
   speech to answering
          invitations for session set-up sign language and users SHOULD be informed when vice versa where the session signing is accepted by the other party. On all systems
   communicated using video.

   It is RECOMMENDED that
          both inform users ToIP implementations make the invocation and
   use of relay services as easy as possible. It MAY happen
   automatically when the session status and is being set up based on any valid
   indication or negotiation of supported or preferred media types. A
   transcoding framework document using SIP [14] describes invoking
   relay services, where the relay acts as a conference bridge or uses
   the third party control mechanism. ToIP implementations SHOULD
   support ToIP, this
          information MUST be available in textual form transcoding framework.

6.2.4
     Presentation and MAY also User control functions

6.2.4.1
       Progress and status information

   During a conversation that includes ToIP, status and session progress
   information MUST be provided in other media.

       6.2.9.1 Answering Machine

          Systems for ToIP MAY support an auto-answer function, a textual form so users can perform
   all session control functions. That information MUST be equivalent to answering machines on telephony networks. If an answering
          machine function is supported, it MUST support at least 160
          characters
   session progress information delivered in any other format, for the greeting message. It MUST support incoming text
          message storage of a minimum
   example audio.

   Session progress information SHOULD use simple language so that as
   many users as possible can understand it. The use of 4096 characters, although systems
          MAY support much larger storage. jargon or
   ambiguous terminology SHOULD be avoided. It is RECOMMENDED that systems
          support storage of at least 20 incoming messages of up text
   information be used together with icons to 16000
          characters per message.

          When symbolise the answering machine is activated, user alerting SHOULD
          still take place. The user SHOULD session
   progress information.

   There MUST be allowed a clear indication, in a modality useful to monitor the auto-
          answer progress and where this user,
   whenever a session is provided the connected or disconnected. A user SHOULD never
   be
          allowed to intervene during any stage of in doubt about the answering machine
          procedure and take control status of the session.

       6.2.10 Actions During a Session

          Certain actions need session, even if the user is
   unable to make use of the audio or visual indication. For example,
   tactile indications could be performed during ToIP conversation:

          a. Text transmission from a terminal SHALL be performed character used by character as entered, or in small groups of characters, so
             that no character is delayed from entry deafblind individuals.

   In summary, it SHOULD be possible to transmission by more
             than 300 milliseconds.

       A. van Wijk, et al.     Expires 6 March 2006      [Page 15 of 28]
          b. The text transmission SHALL allow a rate observe indicators about:

   - Incoming session
   - Availability of at least 30
             characters per second so that human typing speed as well as
             speech to real-time text, voice and video channels
   - Session progress
   - Incoming real-time text methods of generating conversation
   - Any loss in incoming real-time text can be
             supported.

          c. To enable the
   - Typed and transmitted real-time text.

6.2.4.2
       Alerting

   For users who cannot use of international character sets, the
             transmission format audible alerter for text conversation SHALL be UTF-8 [12],
             in accordance with ITU-T T.140.

          d. If text incoming sessions,
   it is detected RECOMMENDED to be missing after transmission, there
             SHOULD be include a "text loss" indication in the text tactile as specified in
             T.140 Addendum 1 [4].

          e. When the display of text conversation is included in well as a visual indicator.

   Among the design
             of alerting options are alerting by the end User Agent’s User
   Interface and specific alerting user equipment, agents registered to the display of same
   registrar as the dialogue SHOULD main user agent.

   It should be made so noted that it external alerting systems exist and one
   common interface for triggering the alerting action is easy a contact
   closure between two conductors.

6.2.4.3
       Answering Machine

   Systems for ToIP MAY support an answering machine function,
   equivalent to differentiate answering machines on telephony networks. If an
   answering machine function is supported, it MUST support at least 160
   characters for the greeting message. It MUST support incoming real-
   time text belonging
             to each party in the conversation.

       6.2.10.1 Text Transport

          ToIP uses RTP as the default transport protocol for the
          transmission of real-time text via message storage of a minimum of 4096 characters, although
   systems MAY support much larger storage. It is RECOMMENDED that
   systems support storage of at least 20 incoming messages of up to
   16000 characters per message.

   When the medium "text/t140" as
          specified in RFC 4103 [5]. answering machine is activated, user alerting SHOULD still
   take place. The redundancy method of RFC 4103 [5] user SHOULD be used allowed to
          significantly increase the reliability of monitor the text transmission. A
          redundancy level using 2 generations gives very reliable results auto-answer
   progress and where this is therefore RECOMMENDED.

          Text capability MUST provided the user SHOULD be announced in SDP by a declaration similar allowed 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
   intervene during any stage of the answering machine procedure and transmission scheme for real time
   take control of the session.

6.2.4.4
       Text presentation

   When the display of text defined conversation is included in the SIP session control environment, design of
   the
          opportunity for interoperability is optimized. However, if good
          reasons exist, other transport mechanisms MAY be offered and used
          for end user equipment, the T.140 coded text provided display of the dialogue SHOULD be made so
   that proper negotiation it is
          introduced, but RFC 4103 [5] transport MUST easy to differentiate the text belonging to each party in
   the conversation. This could be used as both done using color, positioning of the
          default
   text (i.e. incoming real-time text and outgoing real-time text in
   different display areas), by in-band identifiers of the fallback transport.

       6.2.10.2 Handling Text and other Media.

          A call is one parties or more related sessions. The following requirements
          apply to media handling by
   a combination of any of these techniques.

   ToIP SHOULD handle characters such as new line, erasure and alerting
   during a call:

          a. When used between User Agents designed for ToIP, it SHALL be
             possible session as specified in ITU-T T.140 [9].

6.2.4.5
       File storage

   Systems that support ToIP MAY save the text conversation to send a file.
   This SHOULD be done using a standard file format. For example: a UTF8
   text file in XHTML format [18] including timestamps, party names (or
   addresses) and receive the text simultaneously.

       A. van Wijk, et al.     Expires 6 March 2006      [Page 16 conversation.

6.2.5
     Interworking functions

   A number of 28]
          b. When used systems for real time text conversation already exist as
   well as a number of message oriented text communication systems.
   Interoperability is of interest between User Agents that support ToIP, it SHALL be
             possible to send ToIP and receive some of these
   systems.

   Interoperation of half-duplex and full-duplex protocols MAY require
   text simultaneously with buffering. Some intelligence will be needed to determine when to
   change direction when operating in half-duplex mode. Identification
   may be required of half-duplex operation either at the other
             media (text, audio and/or video) supported by "user" level
   (ie. users must inform each other) or at the same
             terminals.

          c. It SHOULD "protocol" level (where
   an indication must be possible sent back to know during a call that ToIP is
             available, even if it is not invoked at call setup (e.g. when
             only voice and/or video the Gateway). However, the special
   care needs to be taken to provide the best possible real-time
   performance.

6.2.5.1
       PSTN Interworking

   Analog text telephony is cumbersome because of incompatible national
   implementations where interworking was never considered. A large
   number of these implementations have been documented in ITU-T V.18
   [19], which also defines the modem detection sequences for the
   different text protocols. The modem type identification may in rare
   cases take considerable time depending on user actions.

   To resolve analog textphone incompatibilities, text telephone
   gateways are needed to transcode incoming analog signals into T.140
   and vice versa. The modem capability exchange time can be reduced by
   the text telephone gateways initially assuming the analog text
   telephone protocol used initially). To disable this, in the user MUST disable region where the use of ToIP. This gateway is possible during
             registration at located.
   For example, in the SIP registrar.

       6.2.11 Additional session control

          Systems that support additional session control features, for
          example call waiting, forwarding, hold etc on voice sessions, MUST
          offer this functionality USA, Baudot [II] might be tried as the initial
   protocol. If negotiation for text sessions.

       6.2.12 File storage

          Systems that support ToIP MAY save Baudot fails, the text conversation to a
          file. This SHOULD full V.18 modem
   capability exchange will take place. In the UK, ITU-T V.21 [III]
   might be done the first choice.

   In particular transmission of interactive text on PSTN networks takes
   place using a standard file format. For
          example: variety of codings and modulations, including ITU-T
   V.21 [III], Baudot [II], DTMF, V.23 [IV] and others. Many
   difficulties have arisen as a UTF8 text file result of this variety in XML format [11] including timestamps,
          party names (or addresses) text
   telephony protocols and the ITU-T V.18 [19] standard was developed to
   address some of these issues.

   ITU-T V.18 [19] offers a native text conversation.

       6.3 Conference Session Requirements

          The conference session requirements deal telephony method plus it defines
   interworking with multipoint
          conferencing sessions where there current protocols. In the interworking mode, it
   will be recognise one or more ToIP capable
          devices and/or other end user devices where the total number of
          end user devices will be at least three.

          It SHOULD be possible to use the text medium in conference
          sessions in a similar way to how audio is handled and video is
          displayed. older protocols and fall back to that
   transmission method when required.

   Text in conferences can be used both for letting
          individual participants gateways MUST use the text medium (for example, for
          sidebar discussions in text while listening to ITU-T V.18 [19] standard at the main conference
          audio), as well PSTN side.
   A text gateway MUST act as for central support of a SIP User Agent on the conference with real
          time IP side and
   support RFC4103 text interpretation transport.

   PSTN-ToIP gateways MUST allow alternating use of speech.

       6.4 Real-time Editing and User Alerting

          ToIP SHOULD handle characters such as new line, erasure real-time text and
          alerting during a
   voice if the PSTN textphone involved at the PSTN side of the session
   supports this. (This mode is often called VCO/HCO).

   Calling party identification information, such as specified in ITU-T T.140.

       6.5 Emergency services

          It CLI, MUST be possible passed
   by gateways and converted to place an emergency call using approapriate form if required.

   While ToIP allows receiving and it
          MUST be possible to use sending real-time text simultaneously
   and is displayed on a relay service in such call. The
          emergency service provided to users utilising the split screen, many analog text medium MUST
          be equivalent to the emergency service provided to telephones
   require users utilising
          speech or other media.

       A. van Wijk, et al.     Expires 6 March 2006      [Page 17 of 28]
       6.6 User Mobility

          ToIP User Agents SHOULD use the same mechanisms as other SIP User
          Agents to resolve mobility issues. It take turns typing.
   This is RECOMMENDED that users
          use a SIP-address, resolved by a SIP registrar, to enable basic
          user mobility. Further mechanisms are defined for all session
          types for 3G IP multimedia systems.

       6.7 Firewalls because many text telephones operate strictly half duplex.
   Only one can transmit text at a time. The users apply strict turn-
   taking rules.

   There are several text telephones which communicate in full duplex,
   but merge transmitted text and NATs

          ToIP uses received text in the same signaling and transport protocols as VoIP
          hence, line in the
   same firewall display window. And also here do the users apply strict turn
   taking rules.
   Native V.18 text telephones support full duplex and NAT solutions separate display
   from reception and network
          functionality transmission so that apply to VoIP MUST also apply to ToIP.

       7. Interworking Requirements for the full duplex capability
   can be used fully. Such devices could use the ToIP

          A number of systems for real time text conversation already exist
          as well split screen as a number of message oriented
   well, but almost all text communication
          systems. Interoperability is of interest between ToIP telephones use a restricted character set
   and some of
          these systems. This section describes the interoperability
          requirements, especially for PSTN many use low text telephony, transmission speeds (4 to ensure full
          backward interoperability with ToIP.

       7.1 ToIP Interworking Gateway Services

          Interactive texting facilities exist already in various forms and
          on various networks. On the PSTN, 7 charcters per
   second).

   That is why it is commonly referred important for the ToIP user to as
          text telephony.

          Simultaneous know that he or alternating use of voice and text she
   is used by a
          large number of users who can send voice but must receive connected with an analog text
          (due telephone. The "txp" media content
   attribute [10]SHOULD be used to indicate that the call originates
   from a hearing impairment), PSTN text telephone (e.g. via an ATA or who can hear but must send a text
          (due to gateway).

6.2.5.2
       Mobile Interworking

   Mobile wireless (or Cellular) circuit switched connections provide a speech impairment).

          Session setup through gateways
   digital real-time transport service for voice or data. The access
   technologies include GSM, CDMA, TDMA, iDen and various 3G
   technologies.

   ToIP may be supported over the cellular wireless packet switched
   service. It interfaces to other networks MAY require the
          use of specially formatted addresses or other mechanisms for
          invoking those gateways.

          Different data rates of different protocols MAY require Internet.

   The following sections describe how mobile text
          buffering.

          Transcoding of telephony is
   supported.

6.2.5.2.1
         Cellular "No-gain"

   The "No-gain" text to telephone transporting technology uses specially
   modified EFR [20] and from other coding formats MAY need to
          take place EVR [21] speech vocoders in gateways between ToIP and other forms of text
          conversation, for example to connect mobile terminals
   used to provide a PSTN text telephone.

       7.2 ToIP telephony call. It provides full duplex
   operation and supports alternating voice and PSTN/ISDN Text-Telephony Interworking

          On PSTN networks, transmission of interactive text takes place
          using a variety of codings ("VCO/HCO"). It is
   dedicated to CDMA and modulations, including ITU-T V.21
          [II], Baudot [III], DTMF, V.23 [IV] TDMA mobile technologies and others. Many difficulties
          have arisen as the US Baudot
   (i.e. 45 bit/s) type of text telephones.

6.2.5.2.2
         Cellular Text Telephone Modem (CTM)

   CTM [8] is a result technology independent modem technology that provides
   the transport of this variety in text telephony
          protocols telephone characters at up to 10 characters/sec
   using modem signals that can be carried by many voice codecs and the ITU-T V.18 [10] standard was developed uses
   a highly redundant encoding technique to
          address some of these issues.

       A. van Wijk, et al.     Expires 6 March 2006      [Page 18 of 28]
          ITU-T V.18 [10] offers overcome the fading and cell
   changing losses.

6.2.5.2.3
         Cellular "Baudot mode"

   This term is often used by cellular terminal suppliers for a native text telephony method plus it
          defines interworking GSM
   cellular phone mode that allows TTYs to operate into a cellular phone
   and to communicate with current protocols. In the interworking
          mode, a fixed line TTY. Thus it will recognise one of is a common name
   for the older protocols "No-Gain" and fall back
          to that transmission method the CTM solutions when required.

          V.18 MUST be supported on applied to the PSTN side of a PSTN-ToIP gateway.

          PSTN-ToIP gateways MUST Baudot
   type textphones.

6.2.5.2.4
         Mobile data channel mode

   Many mobile terminals allow alternating the use of text and voice if
          the PSTN textphone involved at the PSTN side circuit switched data
   channel to transfer data in real-time. Data rates of 9600 bit/s are
   usually supported on the session
          supports this. (This mode is often called VCO/HCO).

          Calling party identification information, such as CLI, MUST be
          passed by gateways and converted to an approapriate form if
          required.

       7.3 ToIP and Cellular Wireless 2G mobile network. Gateways provide
   interoperability with PSTN textphones.

6.2.5.2.5
         Mobile ToIP

   ToIP MAY could be supported over the cellular wireless packet switched
          service. It interfaces to the Internet.

          A text gateway with cellular mobile wireless packet switched services
          MUST be able to route text calls
   that interface to emergency service providers
          when any of the recognized emergency numbers that Internet. For 3GPP 3G services, ToIP support text
          communication for the country.

       7.4 is
   described in 3G TS 26.235 [22].

6.2.5.3
       Instant Messaging Support Interworking

   Text gateways MAY be developed used to allow interworking between Instant
   Messaging systems and ToIP solutions. Because Instant Messaging is
   based on blocks of text, rather than on a continuous stream of characters,
   characters like ToIP, gateways MUST transcode between the two
   formats. Text gateways for interworking between Instant Messaging and
   ToIP MUST concatenate apply a procedure for bridging the different conversational
   formats of real-time text versus text messaging. The following advice
   may improve user experience for both parties in a call through a
   messaging gateway.

   a. Concatenate individual characters originating at the ToIP side
   into blocks of text and:

          a. text.

   b. When the length of the concatenated message becomes longer than 50
   characters, the buffered text SHOULD be transmitted to the Instant
   Messaging side as soon as any non-alphanumerical character is
   received from the ToIP side.

          b.

   c. When a new line indicator is received from the ToIP side, the
   buffered characters up to that point, including the carriage return
   and/or line feed characters, SHOULD be transmitted to the Instant
   Messaging side.

          c.

   d. When the ToIP side has been idle for at least 5 seconds, all
   buffered text up to that point SHOULD be transmitted to the
             Instant Messaging side. Instant
   Messaging side.

   e. Text Gateways must be capable to maintain the real-time
   performance for ToIP while providing the interworking services.

   It is RECOMMENDED that during the session, both users are constantly
   updated on the progress of the text input.

       A. van Wijk, et al.     Expires 6 March 2006      [Page 19 of 28]
   Many Instant Messaging protocols signal that a user is typing to the
   other party in the conversation. Text gateways between such Instant
   Messaging protocols and ToIP MUST provide this signaling to the
   Instant Messaging side when characters start being received, or at
   the beginning of the conversation.

   At the ToIP side, an indicator of writing the Instant Message MUST be
   present where the Instant Messaging protocol provides one. For
   example, the real-time text user MAY see ". . . waiting for replying
   IM. . . " and when 5 seconds have passed another . (dot) can be
   shown.

   Those solutions will reduce the difficulties between streaming and
   blocked text services.

   Even though the text gateway can connect Instant Messaging and ToIP,
   the best solution is to take advantage of the fact that the user
   interfaces and the user communities for instant messaging and ToIP
   telephony are very similar. After all, the character input, the
   character display, Internet connectivity and SIP stack are can be the
   same for Instant Messaging (SIMPLE) and ToIP. Thus, the user may
   simply use different applications for ToIP and text messaging in the
   same terminal.

   Devices that implement Instant Messaging SHOULD implement ToIP as
   described in this document so that a more complete text communication
   service can be provided.

       7.5 Common Text Gateway Functions

6.2.5.4
       Interworking through gateways

   Transcoding of text to and from other coding formats MAY need to take
   place in gateways between ToIP and other forms of text conversation,
   for example to connect to a PSTN text telephone.

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

       7.5.1 Protocol support

          Text

   Session setup through gateways MUST use the ITU-T V.18 [10] standard at the PSTN
          side. A text gateway MUST act as a SIP User Agent on to other networks MAY require the IP side
          and support RFC4103 use
   of specially formatted addresses or other mechanisms for invoking
   those gateways.

   Different data rates of different protocols MAY require text transport.

       7.5.2 Relay buffer storage
   buffering.

   When text gateway functions are invoked, there will be a need for
   intermediate storage of characters before transmission to a device
   receiving text slower than the transmitting speed of the sender. Such
   temporary storage SHALL be dimensioned to adjust for receiving at 30
   characters per second and transmitting at 6 characters per second for
   up to 4 minutes (i.e. less than 3k 3000 characters).

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

       A. van Wijk, et al.     Expires 6 March 2006      [Page 20 of 28]
          at the "protocol" level (where an indication must be sent back to
          the Gateway).

       7.5.3 Emergency calls through gateways

          A text gateway MUST be able to route text calls to emergency
          service providers when any of the recognised emergency numbers
          that support text communications for the country or region are
          called e.g. "911" in USA and "112" in Europe. Routing text calls
          to emergency services MAY require the use of a transcoding
          service.

       7.5.4 Text Gateway Invocation

   ToIP interworking requires a method to invoke a text gateway. As
   described previously in this draft, previously, these text gateways MUST act as User Agents at
   the IP side. The capabilities of the 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 generally only able to
   receive voice and streaming real-time text, so the text gateway will only allow ToIP
   and audio.

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

   a. PSTN textphone users dial a prefix number before dialing out.
   b. Separate real-time text subscriptions, linked to the phone number
   or terminal identifier/ IP address.
   c. Text capability indicators.
          d. Text preference indicator.
          e. Listen for V.18 modem modulation text activity in all PSTN
             calls and routing of the call to an appropriate gateway.
          f. Call transfer request by the called user.
          g. Placing a call via the web, and using one of the methods
             described here
          h. Text gateways with its own telephone number and/or SIP address.
             (This requires user interaction with the text gateway to place
             a call).
          i. ENUM address analysis and number plan
          j. Number or address analysis leads to a gateway for all PSTN
             calls.

       7.6 Home Gateways or Analog Terminal Adapters

          Analog terminal adapters (ATAs) using SIP based IP communication
          and RJ-11 connectors for connecting traditional PSTN devices
          SHOULD enable connection of legacy PSTN text telephones [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 sessions.

       A. van Wijk, et al.     Expires 6 March 2006      [Page 21 of 28]
          If a session is set up and text/t140 capability is not declared by
          the destination endpoint (by the end-point terminal or the Real-time text
          gateway in the network at the end-point), a method for invoking a
          transcoding server SHALL be used. If no such server is available,
          the signals from the textphone MAY be transmitted in the voice
          channel as audio with high quality of service.

          NOTE: It is preferred that such analog terminal adaptors do use
          RFC 4103 [5] on board and thus act as a capability indicators.
   d. Real-time text gateway. Sending
          textphone signals over preference indicator.
   e. Listen for V.18 modem modulation text activity in all PSTN calls
   and routing of the voice channel is undesirable due call to
          possible filtering and compression and packet loss between an appropriate gateway.
   f. Call transfer request by the
          end-points. This can result in character loss in called user.
   g. Placing a call via the textphone
          conversation or even not allowing web, and using one of the textphones methods described
   here
   h. Text gateways with its own telephone number and/or SIP address.
   (This requires user interaction with the gateway to connect place a call).
   i. ENUM address analysis and number plan
   j. Number or address analysis leads to
          each other.

       7.7 a gateway for all PSTN calls.

6.2.5.5
       Multi-functional Combination gateways

   In practice many interworking gateways will be implemented as
   gateways that combine different functions. As such, a text gateway
   could be built to have modems to interwork with the PSTN and support
   both Instant Messaging as well as ToIP. Such interworking functions
   are called Combination gateways.

   Combination gateways MUST provide interworking between all of their
   supported text based functions. For example, a text 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 Transcoding

6.2.5.6
       Character set transcoding

   Gateways between the ToIP network and other networks MAY need to
   transcode text streams. ToIP makes use of the ISO 10646 character
   set. Most PSTN textphones use a 7-bit character set, or a character
   set that is converted to a 7-bit character set by the V.18 modem.

   When transcoding between character sets and T.140 in gateways,
   special consideration MUST be given to the national variants of the 7
   bit codes, with national characters mapping into different codes in
   the ISO 10646 code space. The national variant to be used could be
   selectable by the user on a per call basis, or be configured as a
   national default for the gateway.

   The indicator of missing text in T.140, specified in T.140 amendment
   1, cannot be represented in the 7 bit character codes. Therefore the
   indicator of missing text SHOULD be transcoded to the '  (apostrophe)
   character in legacy text telephone systems,

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

       7.9 Relay Services

          The relay

7.
  Further recommendations for implementers and service acts as providers

7.1
   Access to Emergency services

   It MUST be possible to place an intermediary between two or more
          callers emergency call using different media or different media encoding schemes.

       7.9.1 Basic function of the ToIP and it MUST
   be possible to use a relay service in such call. The basic text relay emergency
   service allows a translation of speech provided to users utilising the real-time text and text to speech, which enables hearing and speech impaired
          callers medium MUST be
   equivalent to communicate with hearing callers. Even though this
          document focuses on ToIP, we want the emergency service provided to remind readers that other
          relay services exist, like video relay services transcoding users utilising
   speech or other media.

   A text gateway MUST be able to sign language and vice versa where the signing is communicated
          using video.

       7.9.2 Invocation route real-time text calls to
   emergency service providers when any of relay services

          It is RECOMMENDED the recognised emergency
   numbers that ToIP implementations make support text communications for the invocation country or region
   are called e.g. "911" in USA and "112" in Europe. Routing real-time
   text calls to emergency services MAY require the use of relay a transcoding
   service.

   A text gateway with cellular wireless packet switched services as easy as possible. It MAY happen
          automatically MUST
   be able to route real-time text calls to emergency service providers
   when the session is being set up based on any valid
          indication or negotiation of supported the recognized emergency numbers that support real-time
   text communication for the country is called.

7.2
   Home Gateways or preferred media types. A
          transcoding framework document Analog Terminal Adapters

   Analog terminal adapters (ATA) using SIP [7] describes invoking
          relay services, where the relay acts based IP communication and
   RJ-11 connectors for connecting traditional PSTN devices SHOULD
   enable connection of legacy PSTN text telephones [23].

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

   If a conference bridge or
          uses session is set up and text/t140 capability is not declared by
   the third party control mechanism. ToIP implementations
          SHOULD support this transcoding framework.

          Adding destination endpoint (by the end-point terminal or removing the text
   gateway in the network at the end-point), a relay service MUST method for invoking a
   transcoding server SHALL be possible without
          disrupting used. If no such server is available, the current session.

          When setting up a session,
   signals from the relay service MUST textphone MAY be able to
          determine transmitted in the type voice channel as
   audio with high quality of service requested (e.g., speech to text or service.

   NOTE: It is preferred that such analog terminal adaptors do use RFC
   4103 [5] on board and thus act as a text to speech), to indicate if gateway. Sending textphone
   signals over the caller wants voice carry over,
          the language of channel is undesirable due to possible
   filtering and compression and packet loss between the text, end-points.
   This can result in character loss in the sign language being used (in textphone conversation or
   even not allowing the
          video stream), etc.

          It SHOULD be possible textphones to route connect to each other.

7.3
   User Mobility

   ToIP User Agents SHOULD use the session same mechanisms as other SIP User
   Agents to resolve mobility issues. It is RECOMMENDED that users use a preferred relay
          service even if the
   SIP-address, resolved by a SIP registrar, to enable basic user invokes the
   mobility. Further mechanisms are defined for all session from another region
          or types for 3G
   IP multimedia systems.

7.4
   Firewalls and NATs

   ToIP uses the same signaling and transport protocols as VoIP. Hence,
   the same firewall and NAT solutions and network than functionality that usually used.

          A number of requirements, motivations and implementation
          guidelines for relay service invocation can be found in RFC 3351
          [19].
   apply to VoIP MUST also apply to ToIP.

8.
  IANA Considerations

   There are no IANA considerations for this specification.

9.
  Security Considerations

   User confidentiality and privacy need to be met as described in SIP
   [3]. For example, nothing should reveal the fact that the user
          of ToIP is user
   might be a person with a disability unless hearing or speech impairment. ToIP is after
   all a mainstream communication medium for all users. It is up to the
   ToIP user prefers to make this information his or her hearing or speech impairment public. If
   a transcoding server is being

       A. van Wijk, et al.     Expires 6 March 2006      [Page 23 of 28] used, this SHOULD be transparent.
   Encryption SHOULD be used on end-to-end or hop-by-hop basis as
   described in SIP [3] and SRTP
          [17]. [24].

   Authentication needs to be provided for users in addition to the
   message integrity and access control.

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

       9. Authors

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
   Eemsgolaan 3
   9727 DW Groningen
          The Netherlands
          Tel:
   tel  : +31 50 585 77 24
          Fax:
   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
   Mob +61 (0)41 911 7578
          Email barry.dingle@bigfoot.com.au
   Email: btdingle@gmail.com

   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 7608 0511
   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 6 March 2006      [Page 24 of 28]
   Radhika R. Roy
   SAIC
   3465-B Box Hill Corporate Center Drive
   Abingdon, MD 21009
   Tel: 443 402 9041
   Email: Radhika.R.Roy@saic.com

   Henry Sinnreich
   pulver.com
   115 Broadhollow Rd
   Suite 225
   Melville, NY 11747
   USA
   Tel: +1.631.961.8950

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

   Arnoud A. T. van Wijk
          Viataal
          Centre
   Foundation for R & D on sensory an Information and communication disabilities.
          Theerestraat 42
          5271 GD Sint-Michielsgestel
          The Netherlands. Communication Network for the Deaf
   and Hard of Hearing
   "AnnieS"
   www.annies.nl
   Email: a.vwijk@viataal.nl

       10. arnoud@annies.nl

11.
   References

       10.1

11.1
    Normative references

   1.  S. Bradner, "Intellectual Property Rights in IETF Technology
          ", Technology",
       BCP 79, RFC 3979, IETF, March 2005.

   2. S. Bradner, "Key words  Charlton, Gasson, Gybels, Spanner, van Wijk, "User Requirements
       for use the Session Initiation Protocol (SIP) in RFCs to Indicate Requirement
          Levels", BCP 14, Support of Deaf,
       Hard of Hearing and Speech-impaired Individuals", RFC 2119, 3351,
       IETF, March 1997 August 2002.

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

   4.  H. Schulzrinne, S.Casner, R. Frederick, V. Jacobsone, "RTP: A
       Transport Protocol for Real-Time Applications", RFC 3550, IETF,
       July 2003.

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

   6.  ITU-T Recommendation F.703,"Multimedia Conversational Services",
       November 2000.

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

   8.  3GPP TS 26.226  "Cellular Text Telephone Modem Description"
       (CTM).

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

       A. van Wijk, et al.     Expires 6 March 2006      [Page 25 of 28]
          5.

   10. J. Hautakorpi, G. Hellstrom, "RTP Payload for Text Conversation", Camarillo, "The SDP (Session Description
       Protocol) Content Attribute", IETF, February 2006 - Work in
       Progress.

   11. J. Rosenberg, H. Schulzrinne, P. Kyzivat, "Indicating User Agent
       Capabilities in the Session Initiation Protocol (SIP)", RFC 4103,
       3840, IETF, June 2005.

          6. G. Camarillo, August 2004

   12. J. Rosenberg, H. Schulzrinne, and E. Burger, "The Source and
          Sink Attributes P. Kyzivat, "Caller Preferences
       for the Session Initiation Protocol (SIP)", RFC 3841, IETF,
       August 2004

   13. J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the
       Session Description Protocol," Protocol (SDP)", RFC 3624, IETF,
          August 2003 - Work in Progress.

          7. G.Camarillo, June 2002.

   14. G. Camarillo, "Framework for Transcoding with the Session
       Initiation Protocol" IETF June Nov 2005 -  Work in progress.

          8.

   15. G. Camarillo, H. Schulzrinne, E. Burger, and A. van Wijk,
       "Transcoding Services Invocation in the Session Initiation
       Protocol (SIP) Using Third Party Call Control (3pcc)" RFC 4117,
       IETF, June 2005.

          9.

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

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

          11.

   17. Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
       3629, IETF,November 2003.

   18. "XHTML 1.0: The Extensible HyperText Markup Language: A
       Reformulation of HTML 4 in XML 1.0", W3C Recommendation.
       Available at http://www.w3.org/TR/xhtml1.

          12. Yergeau, F., "UTF-8, a transformation format of ISO 10646",
          RFC 2279, IETF, January 1998.

          13.

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

   20. TIA/EIA/IS-823-A  "TTY/TDD Extension to TIA/EIA-136-410 Enhanced
       Full Rate Speech Codec (must used in conjunction with
       TIA/EIA/IS-840)"

          14.

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

          15.

   22. "IP Multimedia default codecs". 3GPP TS26.226  "Cellular Text Telephone Modem Description"
          (CTM).

          16. TS 26.235

   23. H. Sinnreich, S. Lass,  and C. Stredicke, "SIP Telephony Device
       Requirements and Configuration," IETF, June October 2005 - Work in
       Progress.

          17.

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

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

          19. Charlton, Gasson, Gybels, Spanner, van Wijk, "User
          Requirements for the Session Initiation Protocol (SIP) in Support

       A. van Wijk, et al.     Expires 6 March 2006      [Page 26 of 28]
          of Deaf, Hard of Hearing and Speech-impaired Individuals", RFC
          3351, IETF, August 2002.

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

          21.

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

          22. H. Schulzrinne, S.Casner, R. Frederick, V. Jacobsone, "RTP: A
          Transport Protocol for Real-Time Applications", RFC 3550, IETF,
          July 2003.

          23. ITU-T Recommendation F.703,"Multimedia Conversational
          Services", November 2000.

          24. J. Rosenberg, H. Schulzrinne, P. Kyzivat, "Indicating User
          Agent Capabilities in the Session Initiation Protocol (SIP)", RFC
          3840, IETF, August 2004

       10.2

11.2
    Informative references

   I. A relay service allows the users to transcode between different
   modalities or languages. In the context of this document, relay
   services will often refer to text relays that transcode text into
   voice and vice-versa. See for example http://www.typetalk.org.

   II. International Telecommunication Union (ITU), "300 bits per
          second duplex modem standardized for use in the general switched
          telephone network". ITU-T Recommendation V.21, November 1988.

          III. TIA/EIA/825 "A Frequency Shift Keyed Modem for Use on the Public
   Switched Telephone Network." (The specification for 45.45
          and 50 bit/s TTY modems.) 45.45 and 50
   bit/s TTY modems.)

   III. International Telecommunication Union (ITU), "300 bits per
   second duplex modem standardized for use in the general switched
   telephone network". ITU-T Recommendation V.21, November 1988.

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

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 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

       A. van Wijk, et al.     Expires 6 March 2006      [Page 27 of 28]
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-ipr@ietf.org.
       Disclaimer of Validity

          This document and the information contained herein are provided on
          an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
          REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
          THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
          EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
          THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
          ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
          PARTICULAR PURPOSE.

       Copyright Statement

          Copyright (C) The Internet Society (2005).  This document is
          subject to the rights, licenses and restrictions contained in BCP
          78, and except as set forth therein, the authors retain all their
          rights.

       Acknowledgment ietf-
   ipr@ietf.org.

Acknowledgement

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

       A. van Wijk, et al.     Expires 6 March 2006      [Page 28 of 28] IETF
   Administrative Support Activity (IASA).