SIPPING Workgroup
   Internet Draft                                    A. van Wijk Wijk, Editor
Internet Draft                                       G. Gybels, Editor
Category: Informational                                       AnnieS
   Expires: September 5                              June 25, 2006                              March 6,
Expires: December 27, 2006

   Framework for real-time text over IP using SIP

                     draft-ietf-sipping-toip-04.txt the Session Initiation
                        Protocol (SIP)
                draft-ietf-sipping-toip-05.txt

Status of this Memo

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

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

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

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

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

  This Internet-Draft will expire on September 5, December 27, 2006.

Copyright Notice

  Copyright (C) The Internet Society (2006).

Abstract

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

Table of Contents

   1. Introduction...................................................3 Introduction....................................................2
   2. Scope..........................................................4 Scope...........................................................3
   3. Terminology....................................................4 Terminology.....................................................3
   4. Definitions....................................................4 Definitions.....................................................4
   5. Requirements...................................................6 Requirements....................................................5
     5.1 General requirements for ToIP..............................6 ToIP................................6
     5.2 Detailed requirements for ToIP.............................8 ToIP...............................7

van Wijk, et al.          Expires December 27, 2006           [Page  1]
       5.2.1 Session control and set-up requirements...............8 and control requirements..................7
       5.2.2 Transport requirements................................9 requirements...................................8
       5.2.3 Transcoding service requirements.....................10 requirements.........................9
       5.2.4 Presentation and User control requirements...........11 requirements..............10
       5.2.5 Interworking requirements............................12 requirements...............................11
         5.2.5.1 PSTN Interworking requirements..................12 requirements......................11
         5.2.5.2 Cellular Interworking requirements..............12 requirements..................12
         5.2.5.3 Instant Messaging Interworking requirements.....13 requirements.........12
   6. Implementation Framework......................................13 Framework.......................................12
     6.1 Framework of general implementation.......................13 General implementation framework............................13
     6.2 Framework of detailed implementation......................14 Detailed implementation framework...........................13
       6.2.1 Session control and set-up...........................14 set-up..............................13
         6.2.1.1 Pre-session setup...............................14 set-up..................................13
         6.2.1.2 Basic Point-to-Point Session setup..............15
            6.2.1.3 Addressing......................................15
            6.2.1.4 Session Negotiations............................15
            6.2.1.5 Additional session control......................16 Negotiations................................14
       6.2.2 Transport............................................16 Transport...............................................14
       6.2.3 Transcoding services.................................17 services....................................15
       6.2.4 Presentation and User control functions..............18 functions.................15
         6.2.4.1 Progress and status information.................18 information.....................15
         6.2.4.2 Alerting........................................18 Alerting............................................16
         6.2.4.3 Answering Machine...............................18
            6.2.4.4 Text presentation...............................19
            6.2.4.5 presentation...................................16
         6.2.4.4 File storage....................................19 storage........................................16
       6.2.5 Interworking functions...............................19 functions..................................16
         6.2.5.1 PSTN Interworking...............................20 Interworking...................................17
         6.2.5.2 Mobile Interworking.............................21 Interworking.................................18
           6.2.5.2.1 Cellular "No-gain".........................21 "No-gain"..............................19
           6.2.5.2.2 Cellular Text Telephone Modem (CTM)........21 (CTM).............19
           6.2.5.2.3 Cellular "Baudot mode".....................22 mode"..........................19
           6.2.5.2.4 Mobile data channel mode...................22 mode........................19
           6.2.5.2.5 Mobile ToIP................................22 ToIP.....................................19
         6.2.5.3 Instant Messaging Interworking..................22 Interworking......................19
         6.2.5.4 Interworking through gateways...................23
            6.2.5.5 Multi-functional Combination gateways...........24
            6.2.5.6 gateways...............21
         6.2.5.5 Character set transcoding.......................25 transcoding...........................21
   7. Further recommendations for implementers and service providers25 providers.21
     7.1 Access to Emergency services..............................25 services................................21
     7.2 Home Gateways or Analog Terminal Adapters.................26 Adapters...................22
     7.3 User Mobility.............................................26 Mobility...............................................22
     7.4 Firewalls and NATs........................................26 NATs..........................................22
   8. IANA Considerations...........................................26 Considerations............................................22
   9. Security Considerations.......................................26 Considerations........................................23
  10. Authorsí Addresses...........................................27 Authors Addresses..............................................23
  11. References...................................................28
      11.1 Contributors...................................................23
  12. References.....................................................24
    12.1 Normative references.....................................28
      11.2 references........................................24
    12.2 Informative references...................................30 references......................................25

1. Introduction

  For many years, text has been in use as a medium for conversational,
  interactive dialogue between users in a similar way to how voice
  telephony is used. Such interactive text is different from messaging
  and semi-interactive solutions like Instant Messaging in that it
  offers an equivalent conversational experience to users who cannot, or

van Wijk, et al.          Expires December 27, 2006           [Page  2]
  do not wish to, use voice. It therefore meets a different set of
  requirements from other text-based solutions already available on IP
  networks.

  Traditionally, deaf, hard of hearing and speech-impaired people are
  amongst the most prolific users of conversational, interactive text
  but, because of its interactivity, it is becoming popular amongst
  mainstream users as well. Real-time text conversation can be combined
  with other conversational media like video or voice."

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

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

  The Session Initiation Protocol (SIP) [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 signalling
  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 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 [6].

2. Scope

  This document defines a framework for the implementation of real-time
  ToIP, either stand-alone or as a part of multimedia services,
  including Total Conversation [6]. It defines provides the:
  a. Requirements of Real-time requirements for real-time text;
  b. Requirements requirements for ToIP interworking;
  c. Description description of ToIP implementation using SIP and RTP;
  d. Description description of ToIP interworking with other text services.

3. Terminology

   In this document, the

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

van Wijk, et al.          Expires December 27, 2006           [Page  3]

4. Definitions

  Audio bridging: a function of an audio media bridge server, gateway or
  relay service that bridges audio into a single source through
   combining audio from multiple users excluding each destination
   sourceís audio and sends to each respective destination enabling an the combination of audio path through
  from all participants in a conference excluding the service between participant(s) at
  that destination. At the users involved in RTP level, this is an instance of the
   call. mixer
  function as defined in RFC 3550 [4].

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

  Full duplex: media is sent independently in both directions.

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

  Interactive text: a another 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.) text, as defined below.

  Real-time text: a term for real time transmission of text in a
  character-by-character fashion for use in conversational services,
  often as a text equivalent to voice based conversational services.
  Conversational text is defined in the ITU-T F.700 Framework for multimedia services
  services, Recommendation F.700 [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 real-time, interactive text communication using analog
  transmission. A variety of PSTN textphone protocols exists world-
   wide. world-wide.
  A textphone can often be combined with a voice telephone, or include
  voice communication functions for simultaneous or alternating use of
  text and voice in a call.

  Text bridging: a function of a the text media bridge server, gateway
  (including transcoding gateways) or relay service analogous to that enables the flow of
  audio bridging as defined above, except that text through the service between the users involved in is the call. medium of
  conversation.

  Text Relay Service: relay service: a third-party or intermediary that enables
  communications between deaf, hard of hearing and speech-impaired
   people,
  people and voice telephone users by translating between voice and
  real-time text in a call.

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

   Text telephony: analog textphone service.

  Total Conversation: a multimedia service offering real time
  conversation in video, real-time text and voice according to

van Wijk, et al.          Expires December 27, 2006           [Page  4]
  interoperable standards. All media streams flow in real time. (See
  ITU-T F.703 "Multimedia conversational services" [6].)

  Transcoding Services: services of service: a service provided by a third-party user agent
  that transcodes one stream into another. Transcoding can be done by
  human operators, in an automated manner manner, or by a combination of both
  methods.
   Text Relay Services are examples Within this document the term particularly applies to
  conversion between different types of media. A text relay service is
  an example of a transcoding service that converts between real-time
  text and audio.

  TTY: originally, an abbreviation for "teletype". Often used in North
  America as an alternative designation for a text telephone or textphone, often
   used in USA.
  textphone. Also called TDD, Telecommunication Device for the Deaf.

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

Acronyms:

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

5. Requirements

   This

  The framework described in section 6 defines a text-based
  conversational service that is the text equivalent of voice based

van Wijk, et al.          Expires December 27, 2006           [Page  5]
  telephony. This section describes the requirements that the framework
  is designed to meet and the functionality it should offer.

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

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

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

5.1 General requirements for ToIP

  Any framework for ToIP must be designed to meet the requirements of
  RFC3351 [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 and mainstream users.

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

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

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

  a. Offer offer real-time transport and presentation of the conversation;
  b. Provide provide simultaneous transmission in both directions;
  c. Support support both point-to-point and multipoint communication;
  d. Allow allow other media, like audio and video, to be used in conjunction
     with ToIP;
  e. Ensure ensure that the real-time text service is always available.

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

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

  - Because because they are in a noisy environment, e.g., in a machine room of
    a factory where listening is difficult. difficult;
  - Because because they are busy with another call and want to participate in
    two calls at the same time. time;
  - For for implementing text and/or speech recording services (e.g., text
    documentation/ audio recording recording) for legal purposes, for clarity or
    for legal/clarity/flexibility
   purposes). flexibility;
  - To to overcome language barriers through speech translation and/or
    transcoding services. services;

van Wijk, et al.          Expires December 27, 2006           [Page  6]
  - Because 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.

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

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

5.2 Detailed requirements for ToIP

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

  The requirements are organized under the following headings:
  - session set-up and session control;
  - transport;
  - use of transcoding services;
  - presentation and user control;
  - interworking.

5.2.1 Session control and set-up and control requirements

   Users will set up a session by identifying the remote party or the
   service they want to connect to. However, conversations

  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 by
  a large number of users people who can send voice but must receive text (due
  to a hearing impairment), or who can hear but must send text (due to a
  speech impairment).

  R1: It SHOULD be possible to start conversations in any mode (real-
  time text, voice, video) or combination of modes.

  R2: It MUST be possible for the users to switch to real-time text, or
  add real-time text as an additional modality, during the conversation.

  R3: Systems supporting ToIP MUST allow users to select any of the
  supported conversation modes at any time, including mid-conversation. in mid-
  conversation.

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

van Wijk, et al.          Expires December 27, 2006           [Page  7]
  R5: If the user requests simultaneous use of real-time text and audio,
  and this is not possible either because the system only
   supports alternate modalities or because of constraints in the network, the
  system MUST SHOULD try to establish communication with best
   effort. text only communication.

  R6: If the user has expressed a preference for real-time text,
  establishment of a connection including real-time text MUST have
  priority over other outcomes of the session setup.

  R7: It SHOULD MUST be possible to use the real-time text medium in
   conference sessions in a similar way to how audio is handled and
   video is displayed.

   Real-time text in conferences can be used both for letting as a
  medium of discussion between individual participants use the text medium (for example, for
  sidebar discussions in text while listening to the main conference audio), as
   well as
  audio) and for central support of the conference with real time text
  interpretation of speech.

  R8: During session set up, it SHOULD be possible for the users to
   indicate if the caller wants to use voice and real-time text
   simutaneously as part of the conversation.

   R9: Session set up and negotiation of modalities must MUST allow users to
  specify the language of the real-time text to be used. (It is
   recommended
  RECOMMENDED that similar functionality is be provided for the video part
  of the conversation, i.e. to specify the sign language being used).

  R9: Where certain session services are available for the audio media
  part of a session, these functions MUST also be supported for the
  real-time text media part of the same session. For example, call
  transfer must act on all media in the session.

5.2.2 Transport requirements

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

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

  R11: Real-time text transmission from a terminal SHALL be performed
  character by character as entered, or in small groups of characters,
  so that no character is delayed from entry to transmission by more
  than 300 milliseconds.

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

   R12: a

  R13: A ToIP service must be able to deal with international character
  sets.

   R13:

van Wijk, et al.          Expires December 27, 2006           [Page  8]
  R14: Where it is possible, loss of real-time text during transport
  should be detected and the user should be informed.

   R14:

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

   R15: Where possible, it must

  R16: It SHOULD be possible to send and receive real-
   time 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 User Agent 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.

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

  A number of requirements, motivations and implementation guidelines
  for relay service invocation can be found in RFC 3351 [2].

   R16:

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

   R17:

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

   R18: The
  modality (e.g. ToIP).

  R19: It MUST be possible to negotiate the requirements for transcoding
  services need to be negotiated in real-time to set up the session.

   R19: Adding or removing real time in the process of setting up a relay service call.

  R20: It MUST be possible without
   disrupting to negotiate the current session.

   R20: requirements for transcoding
  services in mid-call, for the immediate addition of those services to
  the call.

  R21: Communication between the end participants SHOULD continue after
  the addition or removal of a text relay service, and the effect of the
  change should be limited in the users' perception to the direct effect
  of having or not having the transcoding service in the connection.

  R22: When setting up a session, it MUST be possible for a user to
   determine
  specify the type of relay service requested (e.g., speech to text or
  text to speech). The specification of a type of relay MUST include a
  language specifier.

   R21:

van Wijk, et al.          Expires December 27, 2006           [Page  9]
  R23: It SHOULD be possible to route the session to a preferred relay
  service even if the user invokes the session from another region or
  network than that usually used.

  R24: It is RECOMMENDED that ToIP implementations make the invocation
  and use of relay services as easy as possible.

5.2.4 Presentation and User control requirements

   R22:

  A user should never be in doubt about the status of the session, even
  if the user is unable to make use of the audio or visual indication.
  For example, tactile indications could be used by deafblind
  individuals.

  R25: User Agents for ToIP services must MUST have alerting methods (e.g.,
  for incoming sessions) that can be used by deaf and hard of hearing
  people or provide a range of alternative, but equivalent, alerting
  methods that can be selected by all users, regardless of their
  abilities.

   R23:

  R26: Where real-time text is used in conjunction with other media,
  exposure of user control functions through the User Interface needs to
  be done in an equivalent manner for all supported media.

   In other words, where certain call control functions are available
   for the audio media part of a session, these functions MUST also be
   supported for the real-time text media part of the same session. For example, call transfer
  it must act on all media in be possible for the session.

   R24: user to select between audio, visual or
  tactile prompts, or both must be supplied.

  R27: If present, available, identification of the originating party (for
  example in the form of a URL or a CLI) MUST be clearly presented to
  the user in a form suitable for the user BEFORE the session invitation
  is answered.

   R25:

  R28: When a session invitation involving ToIP originates from a PSTN
  text telephone (e.g. transcoded via a text gateway), this SHOULD be
  indicated to the user. The ToIP client MAY adjust the presentation of
  the real-time text to the user as a consequence.

   R26:

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

   R27:

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

   R28:

  R31: Users must MUST be presented with appropriate session progress
  information at all times.

   R29: Answering machine functions

  R32: Systems for ToIP SHOULD be provided by the User
   Agent.

   R30: When the support an answering machine function,
  equivalent to answering machines on telephony networks.

  R33: If an answering machine function is enabled on supported, it MUST support at
  least 160 characters for the User
   Agent, alerting greeting message. It MUST support
  incoming real-time text message storage of a minimum of 4096
  characters, although systems MAY support much larger storage. It is
  RECOMMENDED that systems support storage of at least 20 incoming
  messages of up to 16000 characters per message.

  R34: When the answering machine is activated, user alerting SHOULD
  still take place. The user SHOULD be possible allowed to monitor the auto-
  answer progress and users where this is provided the user SHOULD be able allowed
  to take over control from intervene during any stage of the answering machine function at
   any time.

   R31: Users procedure and
  take control of the session.

  R35: It SHOULD be able possible to save the text portion of a conversation.

   R32:

  R36: The presentation of the conversation should SHOULD be done in such a way
  that users can easily identify which party generated any given portion
  of text.

  R37: ToIP SHOULD handle characters such as new line, erasure and
  alerting during a session as specified in ITU-T T.140 [9].

5.2.5 Interworking requirements

  There is a range of existing real-time text services. There is also a
  range of network technologies that could support real-time text
  services.

   Real-time/Interactive

  Real-time/interactive texting facilities exist already in various
  forms and on various networks. On In the PSTN, it is they are commonly referred
  to as text telephony.

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

   R33:

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

   R34:

  R39: When communicating via a gateway to other networks and protocols,
  the ToIP service SHOULD support the functionality for alternating or
  simultaneous use of modalities as offered by the interworking network.

   R35: Address

  R40: Calling party identification information, both called and calling, SHOULD such as CLI, MUST be
   transferred,
  passed by gateways and possibly converted, when interworking between
   different networks.

   R36: converted to an appropriate form if required.

  R41: When interworking with other networks and services, the ToIP
  service SHOULD provide buffering mechanisms to deal with delays in
  call setup, differences in transmission speeds and/or to interwork
  with half duplex services.

5.2.5.1 PSTN Interworking requirements

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

   R37:

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

   R38:

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

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 were 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 were 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 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:

  R44: 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 users as
  defined in RFC 3351 [2]. It is unsuitable less suitable for communications
  through a relay service [I].

  The streaming nature of ToIP provides a more direct conversational
  user experience and, when given the choice, users may prefer ToIP.

   R39:

  R45: a ToIP service MAY provide interworking with Instant Messaging
  services.

6. Implementation Framework

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

6.1
   Framework of general General implementation

   ToIP uses framework

  This framework specifies the use of the Session Initiation Protocol
  (SIP) [3] to set up, control and tear down the connections between
  ToIP users whilst the media is transported using the Real-Time
  Transport Protocol (RTP) [4] as described in RFC4103 [5].

   SIP [3] allows participants

  RFC 4504 describes how to negotiate all media including real-
   time text conversation [5]. This is a highly desirable function implement support for
   all IP interactive text in
  SIP telephony users but essential for deaf, hard of hearing, or
   speech impaired people who have limited or no use of the audio path
   of the call. Even for mainstream users, media negotiations like real-
   time text are also very useful in many circumstances as described
   earlier.

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

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

6.2
   Framework of detailed implementation

6.2.1
     Session control and set-up

   ToIP services MUST devices [23].

6.2 Detailed implementation framework

6.2.1 Session control and set-up

  ToIP services MUST use the Session Initiation Protocol (SIP) [3] for
  setting up, controlling and terminating sessions for real-time text
  conversation with one or more participants and possibly including
  other media like video or audio. The session description protocol
  (SDP) used in SIP to describe the session is used to express the
  attributes of the session and to negotiate a set of compatible media
  types.

  SIP [3] allows participants to negotiate all media including real-time
  text conversation [5]. ToIP services can provide the ability to set up
  conversation sessions from any location as well as provision for
  privacy and security through the application of standard SIP
  techniques.

6.2.1.1 Pre-session setup set-up

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

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

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

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

6.2.1.2
       Basic Point-to-Point Session setup

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

  A point-to-point session takes place between two parties. For ToIP,
  one or both of the communicating parties will indicate real-time text
  as a possible or preferred medium for conversation using SIP in the
  session setup.

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

  a. Caller Preferences: SIP headers (e.g., Contact)[11] Contact) [11] can be used to
     show that ToIP real-time text is the medium of choice for
     communications.

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

  c. SIP Server support for User Preferences: It is RECOMMENDED that SIP
     servers also handle the incoming sessions in accordance with
     preferences expressed for real-time text. The SIP Server can also
     enforce ToIP policy rules for communications (e.g. use of the
     transcoding server for ToIP).

6.2.1.3
       Addressing

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

6.2.1.4

6.2.1.2 Session Negotiations

  The Session Description Protocol (SDP) used in SIP [3] provides the
  capabilities to indicate real-time text as a medium in the session
  setup. RFC 4103 [5] uses the RTP payload types "text/red" and
  "text/t140" for support of ToIP which can be indicated in the SDP as a
  part of the SIP INVITE, OK and SIP/200/ACK media negotiations. In
  addition, SIPís SIPs offer/answer model [13] can also be used in conjunction
  with other capabilities including the use of a transcoding server for
  enhanced session negotiations [14,15,16].

   Systems SHOULD provide a best-effort approach

6.2.2 Transport

  ToIP services MUST support the Real-Time Transport Protocol (RTP) [4]
  according to answering
   invitations the specification of RFC4103 [4] for session set-up and users SHOULD be informed when the
   session is accepted by transport of
  text between participants.

  RFC4103 describes the other party. On all systems that both
   inform users of session status and support ToIP, this information
   MUST be available in textual form and MAY also be provided in other
   media.

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 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 the specification of RFC4103 [4] for the transport of
   text between participants.

   RFC4103 describes the transmission transmission of T.140 [9] real-time text on IP
  networks.

  In order to enable the use of international character sets, the
  transmission format for text conversation SHALL be UTF-8 [17], in
  accordance with ITU-T T.140.

  If real-time text is detected to be missing after transmission, there
  SHOULD be a "text loss" indication in the real-time text as specified
  in T.140 Addendum 1 [9].

   ToIP uses RTP as the default transport protocol for the transmission
   of real-time text via the medium "text/t140" as specified in RFC 4103
   [5].

  The redundancy method of RFC 4103 [5] SHOULD be used to significantly
  increase the reliability of the real-time text transmission. A
  redundancy level using 2 generations gives very reliable results and
  is therefore strongly RECOMMENDED.

  Real-time text capability MUST be is announced in SDP by a declaration similar
  to this example:

  m=text 11000 RTP/AVP 100 98
  a=rtpmap:98 t140/1000
  a=rtpmap:100 red/1000
  a=fmtp:100 98/98/98

  By having this single coding and transmission scheme for real time
  text defined in the SIP session control environment, the opportunity
  for interoperability is optimized. However, if good reasons exist,
  other transport mechanisms MAY be offered and used for the T.140 coded
  text provided that proper negotiation is introduced, but RFC 4103 [5]
  transport MUST be used as both the default and the fallback transport.

   Real-time text transmission from a terminal SHALL be performed
   character by character as entered, or in small groups of characters,
   so that no character is delayed from entry to transmission by more
   than 300 milliseconds.

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

6.2.3 Transcoding services

   The right to include

  Invokation of a transcoding service MUST NOT require user
   registration in any specific SIP registrar, but MAY require
   authorisation of the SIP registrar to invoke happen automatically when the service.

   A specific type
  session is being set up based on any valid indication or negotiation
  of supported or preferred media types. A transcoding service in a ToIP environment is a framework
  document using SIP [14] describes invoking relay service. The relay service acts as an intermediary between two
   or more callers using different media or different media encoding
   schemes.

   The basic text relay service allows a translation of speech to real-
   time text and real-time text to speech, which enables hearing and
   speech impaired callers to communicate with hearing callers. Even
   though this document focuses on ToIP, we want to remind readers that
   other relay services exist, like video relay services transcoding
   speech to sign language and vice versa where the signing is
   communicated using video.

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

6.2.4 Presentation and User control functions

6.2.4.1 Progress and status information

   During a conversation that includes ToIP, status and session progress
   information MUST be provided in a textual form so users can perform
   all session control functions. That information MUST be equivalent to
   session progress information delivered in any other format, for
   example audio.

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

   There MUST be a clear indication, in a modality useful to the user,
   whenever a session is connected or disconnected. A user SHOULD never
   be in doubt about the status of the session, even if the user is
   unable to make use of the audio or visual indication. For example,
   tactile indications could be used by deafblind individuals.

  In summary, it SHOULD be possible to observe indicators about:
  - Incoming session
  - Availability of real-time text, voice and video channels
  - Session progress
  - Incoming real-time text
  - Any loss in incoming real-time text
  - Typed and transmitted real-time text.

6.2.4.2 Alerting

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

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

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

6.2.4.3
       Answering Machine

   Systems for ToIP MAY support an answering machine function,
   equivalent Text presentation

  Requirement R32 requires that, in the display of text conversation,
  users be able to answering machines on telephony networks. If an
   answering machine function is supported, it MUST support at least 160
   characters for distinguish easily between different speakers. This
  could be done using color, positioning of the greeting message. It MUST support text (i.e. incoming real-
   time text message storage of a minimum of 4096 characters, although
   systems MAY support much larger storage. It is RECOMMENDED that
   systems support storage of at least 20 incoming messages of up to
   16000 characters per message.

   When the answering machine is activated, user alerting SHOULD still
   take place. The user SHOULD be allowed to monitor the auto-answer
   progress and where this is provided the user SHOULD be allowed to
   intervene during any stage of the answering machine procedure and
   take control of the session.

6.2.4.4
       Text presentation

   When the display of text conversation is included in the design of
   the end user equipment, the display of the dialogue SHOULD be made so
   that it is easy to differentiate the text belonging to each party in
   the conversation. This could be done using color, positioning of the
   text (i.e. incoming real-time
  real-time text and outgoing real-time text in different display
  areas), by in-band identifiers of the parties or by a combination of
  any of these techniques.

   ToIP SHOULD handle characters such as new line, erasure and alerting
   during a session as specified in ITU-T T.140 [9].

6.2.4.5

6.2.4.4 File storage

   Systems

  Requirement R31 recommends that support ToIP MAY save systems allow the text conversation user to a file. save
  text conversations. This SHOULD 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 the text conversation.

6.2.5 Interworking functions

  A number of systems for real time text conversation already exist as
  well as a number of message oriented text communication systems.
  Interoperability is of interest between ToIP and some of these
  systems.

  Interoperation of half-duplex and full-duplex protocols, and between
  protocols MAY that have different data rates, may require text buffering.
  Some intelligence will be needed to determine when to change direction
  when operating in half-duplex mode. Identification may be required of
  half-duplex operation either at the "user" level (ie. users must
  inform each other) or at the "protocol" level (where an indication
  must be sent back to the Gateway). However, the special care needs to
  be taken to provide the best possible real-time performance.

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

  Buffering schemes should be dimensioned to adjust for the
   different receiving at 30
  characters per second and transmitting at 6 characters per second for
  up to 4 minutes (i.e. less than 3000 characters).

  When converting between simultaneous voice and text on the IP side,
  and alternating voice and text protocols. The modem type identification may in rare
   cases take considerable time depending on the other side of a gateway, a
  conflict can occur if the IP user actions.

   To resolve analog textphone incompatibilities, transmits both audio and text at the
  same time. In such situations, text transmission SHOULD have
  precedence, so that while text is transmitted, audio is lost.

  Transcoding of text telephone
   gateways are needed to transcode incoming analog signals into T.140 and vice versa. The modem capability exchange time can be reduced by
   the from other coding formats may need to take
  place in gateways between ToIP and other forms of text telephone conversation,
  for example to connect to a PSTN text telephone.

  Session set-up through gateways initially assuming to other networks may require the analog use
  of specially formatted addresses or other mechanisms for invoking
  those gateways.

  ToIP interworking requires a method to invoke a text
   telephone protocol used in gateway. These
  text gateways act as User Agents at the region where IP side. The capabilities of
  the gateway is located.
   For example, in during the USA, Baudot [II] might call will be tried as determined by the initial
   protocol. If negotiation for Baudot fails, call
  capabilities of the full V.18 modem
   capability exchange will take place. In terminal that is using the UK, ITU-T V.21 [III]
   might be gateway. For example, a
  PSTN textphone is generally only able to receive voice and real-time
  text, so the first choice.

   In particular transmission gateway will only allow ToIP and audio.

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

  a. PSTN networks takes
   place using textphone users dial a variety of codings and modulations, including ITU-T
   V.21 [III], Baudot [II], DTMF, V.23 [IV] and others. Many
   difficulties have arisen as a result of this variety in prefix number before dialing out.
  b. Separate real-time text
   telephony protocols and subscriptions, linked to the ITU-T phone number
     or terminal identifier/ IP address.
  c. Real-time text capability indicators.
  d. Real-time text preference indicator.
  e. Listen for V.18 [19] standard was developed to
   address some modem modulation text activity in all PSTN calls
     and routing of these issues.

   ITU-T V.18 [19] offers the call to an appropriate gateway.
  f. Call transfer request by the called user.
  g. Placing a native text telephony method plus it defines
   interworking with current protocols. In call via the interworking mode, it
   will recognise web, and using one of the older protocols and fall back to that
   transmission method when required. methods described
     here
  h. Text gateways MUST use the ITU-T V.18 [19] standard at with its own telephone number and/or SIP address.
     (This requires user interaction with the PSTN side.
   A text gateway MUST act as to place a SIP User Agent on the IP side and
   support RFC4103 text transport.

   PSTN-ToIP gateways MUST allow alternating use of real-time text call).
  i. ENUM address analysis and
   voice if the number plan
  j. Number or address analysis leads to a gateway for all PSTN textphone involved at the calls.

6.2.5.1 PSTN side of the session
   supports this. (This mode is often called VCO/HCO).

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

   While ToIP allows receiving and sending real-time Interworking

  Analog text simultaneously
   and is displayed on a split screen, many analog text telephones
   require users to take turns typing.
   This telephony is cumbersome because many text telephones operate strictly half duplex.
   Only one can transmit 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 at a time. protocols. The users apply strict turn-
   taking rules.

   There are several text telephones which communicate modem type identification may in full duplex,
   but merge transmitted 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 received vice
  versa. The modem capability exchange time can be reduced by the text
  telephone gateways initially assuming the analog text telephone
  protocol used in the same line region where the gateway is located. For example,
  in the
   same display window. And also here do USA, Baudot [II] might be tried as the users apply strict turn
   taking rules.
   Native V.18 text telephones support full duplex and separate display
   from reception and transmission so that initial protocol. If
  negotiation for Baudot fails, the full duplex V.18 modem capability
   can exchange
  will take place. In the UK, ITU-T V.21 [III] might be used fully. Such devices could use the ToIP split screen as
   well, but almost all first
  choice.

  In particular transmission of interactive text telephones use on PSTN networks takes
  place using a restricted character set variety of codings and many use low text transmission speeds (4 to 7 charcters per
   second).

   That is why it is important for the ToIP user to know that he or she
   is connected with an analog text telephone. The "txp" media content
   attribute [10]SHOULD be used to indicate that the call originates
   from a PSTN text telephone (e.g. via an ATA or a text gateway).

6.2.5.2
       Mobile Interworking

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

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

   The following sections describe how mobile text telephony is
   supported.

6.2.5.2.1
         Cellular "No-gain"

   The "No-gain" text telephone transporting technology uses specially
   modified EFR [20] modulations, including ITU-T V.21
  [III], Baudot [II], DTMF, V.23 [IV] and EVR [21] speech vocoders in mobile terminals
   used to provide others. Many difficulties have
  arisen as a result of this variety in text telephony call. It provides full duplex
   operation and supports alternating voice and text ("VCO/HCO"). It is
   dedicated to CDMA and TDMA mobile technologies protocols and the US Baudot
   (i.e. 45 bit/s) type
  ITU-T V.18 [19] standard was developed to address some of text telephones.

6.2.5.2.2
         Cellular Text Telephone Modem (CTM)

   CTM [8] is these
  issues.

  ITU-T V.18 [19] offers a technology independent modem technology that provides
   the transport of native text telephone characters at up to 10 characters/sec
   using modem signals that can be carried by many voice codecs and uses
   a highly redundant encoding technique to overcome the fading and cell
   changing losses.

6.2.5.2.3
         Cellular "Baudot mode"

   This term is often used by cellular terminal suppliers for a GSM
   cellular phone mode that allows TTYs to operate into a cellular phone
   and to communicate with a fixed line TTY. Thus telephony method plus it is a common name
   for the "No-Gain" and the CTM solutions when applied to the Baudot
   type textphones.

6.2.5.2.4
         Mobile data channel mode

   Many mobile terminals allow defines
  interworking with current protocols. In the use interworking mode, it will
  recognise one of the circuit switched data
   channel older protocols and fall back to transfer data in real-time. Data rates of 9600 bit/s are
   usually supported on the 2G mobile network. Gateways provide
   interoperability with PSTN textphones.

6.2.5.2.5
         Mobile ToIP

   ToIP could be supported over mobile wireless packet switched services that interface to the Internet. For 3GPP 3G services, ToIP support is
   described in 3G TS 26.235 [22].

6.2.5.3
       Instant Messaging Interworking
  transmission method when required.

  Text gateways MAY be used to allow interworking between Instant
   Messaging systems and ToIP solutions. Because Instant Messaging is
   based on blocks of text, rather than on a continuous stream of
   characters like ToIP, gateways MUST transcode between use the two
   formats. Text gateways for interworking between Instant Messaging and
   ToIP ITU-T V.18 [19] standard at the PSTN side.
  A text gateway MUST apply act as a procedure for bridging SIP User Agent on the different conversational
   formats of IP side and support
  RFC4103 text transport.

  While ToIP allows receiving and sending real-time text versus simultaneously
  and is displayed on a split screen, many analog text messaging. telephones
  require users to take turns typing. This is because many text
  telephones operate strictly half duplex. Only one can transmit text at
  a time. The following advice
   may improve user experience for both parties users apply strict turn-taking rules.

  There are several text telephones which communicate in full duplex,
  but merge transmitted text and received text in a call through a
   messaging gateway.

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

   b. When the length of same line in the concatenated message becomes longer than 50
   characters,
  same display window. And also here do the buffered users apply strict turn
  taking rules.

  Native V.18 text SHOULD telephones support full duplex and separate display
  from reception and transmission so that the full duplex capability can
  be transmitted to used fully. Such devices could use the Instant
   Messaging side as soon ToIP split screen as any non-alphanumerical well,
  but almost all text telephones use a restricted character set and many
  use low text transmission speeds (4 to 7 characters per second).

  That is
   received from the ToIP side.

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

   d. When the ToIP side has been idle for at least 5 seconds, all
   buffered he or she
  is connected with an analog text up to that point telephone. The "txp" media content
  attribute [10] SHOULD be transmitted to the Instant
   Messaging side.

   e. Text Gateways must be capable used to maintain indicate that the call originates
  from a PSTN text telephone (e.g. via an ATA or a text gateway).

6.2.5.2 Mobile Interworking

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

  ToIP while providing may be supported over the interworking services. cellular wireless packet switched
  service. It is RECOMMENDED that during the session, both users are constantly
   updated on the progress of interfaces to the Internet.

  The following sections describe how mobile text input.
   Many Instant Messaging protocols signal that a user telephony is typing to the
   other party in the conversation. Text gateways between such Instant
   Messaging protocols
  supported.

6.2.5.2.1 Cellular "No-gain"

  The "No-gain" text telephone transporting technology uses specially
  modified EFR [20] and ToIP MUST provide this signaling EVR [21] speech vocoders in mobile terminals
  used to the
   Instant Messaging side when characters start being received, or at
   the beginning of the conversation.

   At the ToIP side, an indicator of writing the Instant Message MUST be
   present where the Instant Messaging protocol provide a text telephony call. It provides one. For
   example, the real-time full duplex
  operation and supports alternating voice and text user MAY see ". . . waiting for replying
   IM. . . " ("VCO/HCO"). It is
  dedicated to CDMA and when 5 seconds have passed another . (dot) can be
   shown.

   Those solutions will reduce the difficulties between streaming TDMA mobile technologies and
   blocked the US Baudot (i.e.
  45 bit/s) type of text services.

   Even though telephones.

6.2.5.2.2 Cellular Text Telephone Modem (CTM)

  CTM [8] is a technology independent modem technology that provides the
  transport of text gateway telephone characters at up to 10 characters/sec
  using modem signals that can connect Instant Messaging be carried by many voice codecs and ToIP,
   the best solution is uses
  a highly redundant encoding technique to take advantage of the fact that overcome the user
   interfaces fading and the user communities cell
  changing losses.

6.2.5.2.3 Cellular "Baudot mode"

  This term is often used by cellular terminal suppliers for instant messaging a cellular
  phone mode that allows TTYs to operate into a cellular phone and ToIP
   telephony are very similar. After all, the character input, to
  communicate with a fixed line TTY. Thus it is a common name for the
   character display, Internet connectivity
  "No-Gain" and SIP stack can be the
   same for Instant Messaging (SIMPLE) and ToIP. Thus, CTM solutions when applied to the Baudot type
  textphones.

6.2.5.2.4 Mobile data channel mode

  Many mobile terminals allow the user may
   simply use different applications for ToIP and text messaging of the circuit switched data
  channel to transfer data in real-time. Data rates of 9600 bit/s are
  usually supported on the
   same terminal.

   Devices 2G mobile network. Gateways provide
  interoperability with PSTN textphones.

6.2.5.2.5 Mobile ToIP

  ToIP could be supported over mobile wireless packet switched services
  that implement Instant Messaging SHOULD implement interface to the Internet. For 3GPP 3G services, ToIP as support is
  described in this document so that a more complete text communication
   service can be provided.

6.2.5.4 3G TS 26.235 [22].

6.2.5.3 Instant Messaging Interworking through

  Text gateways

   Transcoding of text to and from other coding formats MAY need be used to take
   place in gateways allow interworking between ToIP Instant
  Messaging systems and other forms ToIP solutions. Because Instant Messaging is
  based on blocks of text conversation,
   for example to connect to text, rather than on a PSTN text telephone. continuous stream of
  characters like ToIP, gateways MUST transcode between the two formats.
  Text gateways for interworking between Instant Messaging and ToIP MUST allow
  apply a procedure for bridging the differences that result from different conversational formats of
  real-time text protocols. versus text messaging. The protocols to be supported will depend
   on the service requirements of the Gateway.

   Session setup following advice may improve
  user experience for both parties in a call through gateways to other networks MAY require a messaging
  gateway.

  a. Concatenate individual characters originating at the use
   of specially formatted addresses or other mechanisms for invoking
   those gateways.

   Different data rates ToIP side into
     blocks of different protocols MAY require text
   buffering. text.

  b. When the length of the concatenated message becomes longer than 50
     characters, the buffered text gateway functions are invoked, there will SHOULD be a need for
   intermediate storage of characters before transmission transmitted to the Instant
     Messaging side as soon as any non-alphanumerical character is
     received from the ToIP side.

  c. When a device
   receiving text slower than new line indicator is received from the transmitting speed of ToIP side, the sender. Such
   temporary storage SHALL
     buffered characters up to that point, including the carriage return
     and/or line feed characters, SHOULD be dimensioned transmitted to adjust for receiving at 30
   characters per second and transmitting at 6 characters per second the Instant
     Messaging side.

  d. When the ToIP side has been idle for at least 5 seconds, all
     buffered text up to 4 minutes (i.e. less than 3000 characters).

   ToIP interworking requires a method that point SHOULD be transmitted to invoke a text gateway. As
   described previously, these text gateways MUST act as User Agents at the IP Instant
     Messaging side. The capabilities of

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

  It is RECOMMENDED that during the call will session, both users be
   determined by constantly
  updated on the call capabilities progress of the terminal text input. Many Instant Messaging
  protocols signal that is using the
   gateway. For example, a PSTN textphone user is generally only able typing to
   receive voice and real-time text, so the gateway will only allow ToIP other party in the
  conversation. Text gateways between such Instant Messaging protocols
  and audio.

   Examples ToIP MUST provide this signalling to the Instant Messaging side
  when characters start being received, or at the beginning of possible scenarios for invocation 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 text gateway
   are:

   a. PSTN textphone users dial a prefix number before dialing out.
   b. Separate real-time text subscriptions, linked to user MAY see ". . . waiting for replying
  IM. . . " and when 5 seconds have passed another . (dot) can be shown.

  Those solutions will reduce the phone number
   or terminal identifier/ IP address.
   c. Real-time text capability indicators.
   d. Real-time difficulties between streaming and
  blocked text preference indicator.
   e. Listen for V.18 modem modulation services.

  Even though the text activity in all PSTN calls gateway can connect Instant Messaging and routing of ToIP,
  the call best solution is to an appropriate gateway.
   f. Call transfer request by take advantage of the called user.
   g. Placing a call via fact that the web, user
  interfaces 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 communities for instant messaging and ToIP
  telephony are very similar. After all, the gateway to place a call).
   i. ENUM address analysis character input, the
  character display, Internet connectivity and number plan
   j. Number or address analysis leads to a gateway SIP stack can be the same
  for all PSTN calls.

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

6.2.5.4 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 could provide interworking between all of their
  supported text based functions. For example, a Text gateway that has
  modems to interwork with the PSTN and that support both Instant
  Messaging and ToIP MUST could support the following interworking functions:

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

6.2.5.6

6.2.5.5 Character set transcoding

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

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

  The indicator of missing text in T.140, specified in T.140 amendment
  1, cannot be represented in the 7 bit character codes. Therefore the
  indicator of missing text SHOULD be transcoded to the Ď ' (apostrophe)
  character in legacy text telephone systems, where this character
  exists. For legacy systems where the ' character Ď does not exist, the .
  (full stop) character SHOULD be used instead.

7. Further recommendations for implementers and service providers

7.1 Access to Emergency services

  It MUST must be possible to place an emergency call using ToIP and it MUST must
  be possible to use a relay service in such call. The emergency service
  provided to users utilising the real-time text medium MUST must be
  equivalent to the emergency service provided to users utilising speech
  or other media.

  A text gateway MUST must be able to route real-time text calls to emergency
  service providers when any of the recognised emergency numbers that
  support text communications for the country or region are called e.g.

  "911" in USA and "112" in Europe. Routing real-time text calls to
  emergency services MAY may require the use of a transcoding service.

  A text gateway with cellular wireless packet switched services MUST must be
  able to route real-time text calls to emergency service providers when
  any of the recognized emergency numbers that support real-time text
  communication for the country is called.

7.2 Home Gateways or Analog Terminal Adapters

  Analog terminal adapters (ATA) using SIP based IP communication and
  RJ-11 connectors for connecting traditional PSTN devices SHOULD enable
  connection of legacy PSTN text telephones [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 session is set up and text/t140 capability is not declared by the
  destination endpoint (by the end-point terminal or the text gateway in
  the network at the end-point), a method for invoking a transcoding
  server SHALL be used. If no such server is available, the signals from
  the textphone MAY be transmitted in the voice channel as audio with
  high quality of service.

  NOTE: It is preferred that such analog terminal adaptors do use RFC
  4103 [5] on board and thus act as a text gateway. Sending textphone
  signals over the voice channel is undesirable due to possible
  filtering and compression and packet loss between the end-points. This
  can result in character loss in the textphone conversation or even not
  allowing the textphones to connect to each other.

7.3 User Mobility

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

7.4 Firewalls and NATs

  ToIP uses the same signaling signalling and transport protocols as VoIP. Hence,
  the same firewall and NAT solutions and network functionality that
  apply to VoIP MUST also apply to ToIP.

8. IANA Considerations

  There are no IANA considerations for this specification.

9. Security Considerations

  User confidentiality and privacy need to be met as described in SIP
  [3]. For example, nothing should reveal the fact that the ToIP user
  might be a person with a hearing or speech impairment. ToIP is after
  all a mainstream communication medium for all users. It is up to the
  ToIP user to make his or her hearing or speech impairment public. If a
  transcoding server is being used, this SHOULD be transparent.
  Encryption SHOULD be used on end-to-end or hop-by-hop basis as
  described in SIP [3] and SRTP [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.

10.
   Authorsí Authors' Addresses

   The following people provided substantial technical and writing
   contributions to this document, listed alphabetically:

   Willem Dijkstra
   TNO Informatie- en Communicatietechnologie
   Eemsgolaan 3
   9727 DW Groningen
   tel  : +31 50 585 77 24
   fax  : +31 50 585 77 57
   Email: 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: btdingle@gmail.com

    Guido Gybels
    Department of New Technologies
    RNID, 19-23 Featherstone Street
    London EC1Y 8SL, UK
    Tel +44(0)20 7294 +44-20-7294 3713
    Txt +44(0)20 7608 +44-20-7608 0511
    Fax +44(0)20 7296 +44-20-7296 8069
    Email: 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
   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
    Foundation for an Information and Communication Network for the Deaf
    and Hard of Hearing
    "AnnieS"
   www.annies.nl
    http://www.annies.nl/
    Email: arnoud@annies.nl

11. Contributors

  The following people contributed to preliminary drafts of this
  document: Willem Dijkstra, Barry Dingle, Gunnar Hellstrom, Radhika R.
  Roy, Henry Sinnreich and Gregg C Vanderheiden.

  The content and concepts within are a product of the SIPPING Working
  Group. Tom Taylor (Nortel) acted as independent reviewer and
  contributed significantly to the structure and content of this
  document.

12. References

11.1

12.1 Normative references

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

   2. Charlton, Gasson, Gybels, Spanner, van Wijk, "User Requirements
      for the Session Initiation Protocol (SIP) in Support of Deaf, Hard
      of Hearing and Speech-impaired Individuals", RFC 3351, IETF,
      August 2002.

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

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

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

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

   7. S. Bradner, "Key words for use in RFCs to Indicate Requirement
   8. 3GPP TS 26.226  "Cellular Text Telephone Modem Description" (CTM).

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

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

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

  12. J. Rosenberg, H. Schulzrinne, P. Kyzivat, "Caller Preferences for
      the Session Initiation Protocol (SIP)", RFC 3841, IETF,
      August 2004

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

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

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

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

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

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

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

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

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

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

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

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

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

11.2

12.2 Informative references

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

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

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

  IV.  International Telecommunication Union (ITU), "600/1200-baud modem
       standardized for use in the general switched telephone network". ITU-
   T
       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

  The IETF takes no position regarding the validity or scope of any
  Intellectual Property Rights or other rights that might be claimed to
  pertain to the implementation or use of the technology described in
  this document or the extent to which any license under such rights
  might or might not be available; nor does it represent that it has
  made any independent effort to identify any such rights.  Information
  on the procedures with respect to rights in RFC documents can be found
  in BCP 78 and BCP 79.

  Copies of IPR disclosures made to the IETF Secretariat and any
  assurances of licenses to be made available, or the result of an
  attempt made to obtain a general license or permission for the use of
  such proprietary rights by implementers or users of this specification
  can be obtained from the IETF on-line IPR repository at
  http://www.ietf.org/ipr.

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

Acknowledgement

  Funding for the RFC Editor function is provided by the IETF
  Administrative Support Activity (IASA).