doc: Add RFC documents

1 files changed, 1739 insertions, 0 deletions

diff --git a/doc/rfc/rfc5194.txt b/doc/rfc/rfc5194.txt
new file mode 100644
index 0000000..db6644d
--- /dev/null
+++ b/doc/rfc/rfc5194.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+Network Working Group                                   A. van Wijk, Ed.
+Request for Comments: 5194                                G. Gybels, Ed.
+Category: Informational                                        June 2008
+
+
+              Framework for Real-Time Text over IP Using
+                 the Session Initiation Protocol (SIP)
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Abstract
+
+   This document lists the essential requirements for real-time Text-
+   over-IP (ToIP) and defines a framework for implementation of all
+   required functions based on the Session Initiation Protocol (SIP) and
+   the Real-Time Transport Protocol (RTP).  This includes interworking
+   between Text-over-IP and existing text telephony on the Public
+   Switched Telephone Network (PSTN) and other networks.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+van Wijk & Gybels            Informational                      [Page 1]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Scope ...........................................................4
+   3. Terminology .....................................................4
+   4. Definitions .....................................................4
+   5. Requirements ....................................................6
+      5.1. General Requirements for ToIP ..............................6
+      5.2. Detailed Requirements for ToIP .............................8
+           5.2.1. Session Setup and Control Requirements ..............9
+           5.2.2. Transport Requirements .............................10
+           5.2.3. Transcoding Service Requirements ...................10
+           5.2.4. Presentation and User Control Requirements .........11
+           5.2.5. Interworking Requirements ..........................13
+                  5.2.5.1. PSTN Interworking Requirements ............13
+                  5.2.5.2. Cellular Interworking Requirements ........14
+                  5.2.5.3. Instant Messaging Interworking
+                           Requirements ..............................14
+   6. Implementation Framework .......................................15
+      6.1. General Implementation Framework ..........................15
+      6.2. Detailed Implementation Framework .........................15
+           6.2.1. Session Control and Setup ..........................15
+                  6.2.1.1. Pre-Session Setup .........................15
+                  6.2.1.2. Session Negotiations ......................16
+           6.2.2. Transport ..........................................17
+           6.2.3. Transcoding Services ...............................18
+           6.2.4. Presentation and User Control Functions ............18
+                  6.2.4.1. Progress and Status Information ...........18
+                  6.2.4.2. Alerting ..................................18
+                  6.2.4.3. Text Presentation .........................19
+                  6.2.4.4. File Storage ..............................19
+           6.2.5. Interworking Functions .............................19
+                  6.2.5.1. PSTN Interworking .........................20
+                  6.2.5.2. Mobile Interworking .......................22
+                           6.2.5.2.1. Cellular "No-gain" .............22
+                           6.2.5.2.2. Cellular Text Telephone
+                                      Modem (CTM) ....................22
+                           6.2.5.2.3. Cellular "Baudot mode" .........22
+                           6.2.5.2.4. Mobile Data Channel Mode .......23
+                           6.2.5.2.5. Mobile ToIP ....................23
+                  6.2.5.3. Instant Messaging Interworking ............23
+                  6.2.5.4. Multi-Functional Combination Gateways .....24
+                  6.2.5.5. Character Set Transcoding .................25
+   7. Further Recommendations for Implementers and Service
+      Providers ......................................................25
+      7.1. Access to Emergency Services ..............................25
+      7.2. Home Gateways or Analog Terminal Adapters .................25
+      7.3. User Mobility .............................................26
+
+
+
+van Wijk & Gybels            Informational                      [Page 2]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+      7.4. Firewalls and NATs ........................................26
+      7.5. Quality of Service ........................................26
+   8. Security Considerations ........................................26
+   9. Contributors ...................................................27
+   10. References ....................................................27
+      10.1. Normative References .....................................27
+      10.2. Informative References ...................................29
+
+1.  Introduction
+
+   For many years, real-time 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 solutions already
+   available on IP networks.
+
+   Traditionally, deaf, hard-of-hearing, and speech-impaired people are
+   amongst the most prolific users of real-time, conversational, 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).  Therefore, this document
+   describes how to use a set of existing components and protocols and
+   provides the requirements and rules for that resulting structure,
+   which is why it is called a "framework", fitting commonly accepted
+   dictionary definitions of that term.
+
+   This ToIP framework is specifically designed to be compatible with
+   Voice-over-IP (VoIP), Video-over-IP, and Multimedia-over-IP (MoIP)
+   environments.  This ToIP framework also builds upon, and is
+   compatible with, the high-level user requirements of deaf, hard-of-
+   hearing and speech-impaired users as described in RFC3351 [22].  It
+   also meets real-time text requirements 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) [2] is the protocol of choice
+   for control of Multimedia communications and Voice-over-IP (VoIP) in
+   particular.  It offers all the necessary control and signalling
+   required for the ToIP framework.
+
+
+
+
+van Wijk & Gybels            Informational                      [Page 3]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+   The Real-Time Transport Protocol (RTP) [3] is the protocol of choice
+   for real-time data transmission, and its use for real-time text
+   payloads is described in RFC 4103 [4].
+
+   This document defines a framework for ToIP to be used either by
+   itself or as part of integrated, multi-media services, including
+   Total Conversation [5].
+
+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 [5].  It provides the:
+
+   a. requirements for 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
+
+   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 RFC
+   2119 [6] and indicate requirement levels for compliant
+   implementations.
+
+4.  Definitions
+
+   Audio bridging: a function of an audio media bridge server, gateway,
+   or relay service that sends to each destination the combination of
+   audio from all participants in a conference, excluding the
+   participant(s) at that destination.  At the RTP level, this is an
+   instance of the mixer function as defined in RFC 3550 [3].
+
+   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 in one direction at a time, or if
+   an attempt to send information in both directions is made, errors may
+   be introduced into the presented media.
+
+
+
+
+van Wijk & Gybels            Informational                      [Page 4]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+   Interactive text: another term for real-time 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 Framework for multimedia
+   services, Recommendation F.700 [21].
+
+   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.
+
+   Textphone: also "text telephone".  A terminal device that allows
+   end-to-end real-time 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: a function of the text media bridge server, gateway
+   (including transcoding gateways), or relay service analogous to that
+   of audio bridging as defined above, except that text is the medium of
+   conversation.
+
+   Text relay service: a third-party or intermediary that enables
+   communications between deaf, hard-of-hearing, and speech-impaired
+   people and voice telephone users by translating between voice and
+   real-time text in a call.
+
+   Text telephony: analog textphone service.
+
+   Total Conversation: a multimedia service offering real-time
+   conversation in video, real-time text and voice according to
+   interoperable standards.  All media streams flow in real time.  (See
+   ITU-T F.703, "Multimedia conversational services" [5].)
+
+   Transcoding 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, or by a combination of both
+   methods.  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.  Also called TDD, Telecommunication Device for the Deaf.
+
+
+
+
+van Wijk & Gybels            Informational                      [Page 5]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+   Video relay 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)
+     ATA     Analog Telephone Adaptor
+     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 for Mobile 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
+     URI     Uniform Resource Identifier
+     UTF-8   UCS/Unicode Transformation Format-8
+     VCO/HCO Voice Carry Over/Hearing Carry Over
+     VoIP    Voice over Internet Protocol
+
+5.  Requirements
+
+   The framework described in Section 6 defines a real-time 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.
+
+5.1.  General Requirements for ToIP
+
+   Any framework for ToIP must be derived from the requirements of RFC
+   3351 [22].  A basic requirement is that it must provide a
+   standardized way for offering real-time text-based conversational
+   services that can be used as an equivalent to voice telephony by
+   deaf, hard-of-hearing, speech-impaired, and mainstream users.
+
+
+
+van Wijk & Gybels            Informational                      [Page 6]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+   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 that immediate interaction
+   takes 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, ToIP
+   needs to offer equivalent features in terms of conversationality to
+   those provided by voice.  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;
+
+   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 as defined in
+   ITU-T F.703 [5].  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 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 purposes, for clarity, or
+     for flexibility;
+
+
+
+
+
+van Wijk & Gybels            Informational                      [Page 7]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+   - 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, creating a need to replace
+     or complement voice with real-time text in conversational sessions.
+
+   In many of the above examples, real-time 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, join a conference
+   session involving several users, or initiate or join a multimedia
+   session, such as a Total Conversation session.
+
+   A common scenario for multipoint real-time text is conference calling
+   with many participants.  Implementers could, for example, use
+   different colours to render different participants' text, or could
+   create separate windows or rendering areas for each participant.
+
+5.2.  Detailed Requirements for ToIP
+
+   The following sections list individual requirements for ToIP.  Each
+   requirement has been given a unique identifier (R1, R2, etc.).
+   Section 6 (Implementation Framework) describes how to implement ToIP
+   based on these requirements by using existing protocols and
+   techniques.
+
+   The requirements are organized under the following headings:
+
+   - session setup and session control;
+
+   - transport;
+
+   - use of transcoding services;
+
+   - presentation and user control;
+
+   - interworking.
+
+
+
+
+
+
+
+
+
+van Wijk & Gybels            Informational                      [Page 8]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+5.2.1.  Session Setup and Control Requirements
+
+   Conversations could be started using a mode other than real-time
+   text.  Simultaneous or alternating voice and real-time text is used
+   by a large number of 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 in mid-
+   conversation.
+
+   R4: Systems SHOULD allow the user to specify a preferred mode of
+   communication in each direction, with the ability to fall back to
+   alternatives that the user has indicated are acceptable.
+
+   R5: If the user requests simultaneous use of real-time text and
+   audio, and this is not possible because of constraints in the
+   network, the system SHOULD try to establish text-only communication
+   if that is what the user has specified as his/her preference.
+
+   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 MUST be possible to use real-time text in conferences both as
+   a medium of discussion between individual participants (for example,
+   for sidebar discussions in real-time text while listening to the main
+   conference audio) and for central support of the conference with
+   real-time text interpretation of speech.
+
+   R8: Session setup and negotiation of modalities MUST allow users to
+   specify the language of the real-time text to be used.  (It is
+   RECOMMENDED that similar functionality 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.
+
+
+
+
+van Wijk & Gybels            Informational                      [Page 9]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+5.2.2.  Transport Requirements
+
+   ToIP will often be used to access a relay service [24], allowing
+   real-time text users to communicate with voice users.  With relay
+   services, as well as in direct user-to-user conversation, 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.  An end-
+   to-end delay time of one second is regarded as good, while users note
+   and appreciate shorter delays, down to 300ms.  A delay of up to 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 methods of
+   generating real-time text.  A rate of 30 characters per second is
+   regarded as sufficient.
+
+   R13: A ToIP service MUST be able to deal with international character
+   sets.
+
+   R14: Where it is possible, loss or corruption of real-time text
+   during transport SHOULD be detected and the user should be informed.
+
+   R15: Transport of real-time text SHOULD be as robust as possible, so
+   as to minimize loss of characters.
+
+   R16: It SHOULD 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 User Agent only offering T.140 over IP, as
+   described in RFC 4103 [4], 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
+
+
+
+van Wijk & Gybels            Informational                     [Page 10]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+   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 [22].
+
+   R17: It MUST be possible for users to invoke a transcoding service
+   where such service is available.
+
+   R18: It MUST be possible for users to indicate their preferred
+   modality (e.g., ToIP).
+
+   R19: It MUST be possible to negotiate the requirements for
+   transcoding services in real time in the process of setting up a
+   call.
+
+   R20: It MUST be possible to negotiate the 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
+   specify the type of relay service requested (e.g., speech to text or
+   text to speech).  The specification of a type of relay SHOULD include
+   a language specifier.
+
+   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
+
+   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 deaf-blind
+   individuals.
+
+
+
+
+
+van Wijk & Gybels            Informational                     [Page 11]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+   R25: User Agents for ToIP services 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.
+
+   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.  For
+   example, it must be possible for the user to select between audio,
+   visual, or tactile prompts, or all must be supplied.
+
+   R27: If available, identification of the originating party (e.g., in
+   the form of a URI or a Calling Line Identification (CLI)) MUST be
+   clearly presented to the user in a form suitable for the user BEFORE
+   the session invitation is answered.
+
+   R28: When a session invitation involving ToIP originates from a
+   Public Switched Telephone Network (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.
+
+   R29: An indication 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).
+
+   R30: The user MUST be informed of any change in modalities.
+
+   R31: Users MUST be presented with appropriate session progress
+   information at all times.
+
+   R32: Systems for ToIP SHOULD support an answering machine function,
+   equivalent to answering machines on telephony networks.
+
+   R33: If an answering machine function is supported, it MUST support
+   at least 160 characters for the greeting message.  It MUST support
+   incoming 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 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.
+
+
+
+
+van Wijk & Gybels            Informational                     [Page 12]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+   R35: It SHOULD be possible to save the text portion of a
+   conversation.
+
+   R36: The presentation of the conversation 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 [8].
+
+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 texting facilities exist already in various
+   forms and on various networks.  In the PSTN, they are commonly
+   referred to as text telephony.
+
+   Text gateways are used for converting between different protocols for
+   text conversation.  They can be used between networks or within
+   networks where different transport technologies are used.
+
+   R38: ToIP SHOULD provide interoperability with text conversation
+   features in other networks, for instance the PSTN.
+
+   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.
+
+   R40: Calling party identification information, such as CLI, MUST be
+   passed by gateways and 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 and with differences in transmission speeds, and/or to
+   interwork with half-duplex services.
+
+5.2.5.1.  PSTN Interworking Requirements
+
+   Analog text telephony is used in many countries, mainly by deaf,
+   hard-of-hearing and speech-impaired individuals.
+
+   R42: ToIP services MUST provide interworking with PSTN legacy text
+   telephony devices.
+
+
+
+
+van Wijk & Gybels            Informational                     [Page 13]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+   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 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 were mandated by the FCC in
+   the USA.  They are the a) "No-gain" codec solution, and b) the
+   Cellular Text Telephony Modem (CTM) solution [7], both collectively
+   called "Baudot mode" solution in the USA.
+
+   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.
+
+   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; in particular, it 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 [22].  It is less suitable for
+   communications through a relay service [24].
+
+   The streaming nature of ToIP provides a more direct conversational
+   user experience and, when given the choice, users may prefer ToIP.
+
+   R45: a ToIP service MAY provide interworking with Instant Messaging
+   services.
+
+
+
+
+
+
+
+
+van Wijk & Gybels            Informational                     [Page 14]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+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.  General Implementation Framework
+
+   This framework specifies the use of the Session Initiation Protocol
+   (SIP) [2] to set up, control, and tear down the connections between
+   ToIP users whilst the media is transported using the Real-Time
+   Transport Protocol (RTP) [3] as described in RFC 4103 [4].
+
+   RFC 4504 describes how to implement support for real-time text in SIP
+   telephony devices [23].
+
+6.2.  Detailed Implementation Framework
+
+6.2.1.  Session Control and Setup
+
+   ToIP services MUST use the Session Initiation Protocol (SIP) [2] 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 [2] allows participants to negotiate all media, including real-
+   time text conversation [4].  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
+
+   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 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:
+
+
+
+van Wijk & Gybels            Informational                     [Page 15]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+   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 actions taken can be based on the called 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.
+
+   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) [10] can be used
+      to show that real-time text is the medium of choice for
+      communications.
+
+   b. Called Party Preferences [11]: 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 this session needs to be handled by a designated SIP proxy
+      or 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.2.  Session Negotiations
+
+   The Session Description Protocol (SDP) used in SIP [2] provides the
+   capabilities to indicate real-time text as a medium in the session
+   setup.  RFC 4103 [4] 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
+
+
+
+van Wijk & Gybels            Informational                     [Page 16]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+   addition, SIP's offer/answer model [12] can also be used in
+   conjunction with other capabilities, including the use of a
+   transcoding server for enhanced session negotiations [28,29,13].
+
+6.2.2.  Transport
+
+   ToIP services MUST support the Real-Time Transport Protocol (RTP) [3]
+   according to the specification of RFC 4103 [4] for the transport of
+   real-time text between participants.
+
+   RFC 4103 describes the transmission of T.140 [8] real-time text on IP
+   networks.
+
+   In order to enable the use of international character sets, the
+   transmission format for real-time text conversation SHALL be UTF-8
+   [14], 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 [8].
+
+   The redundancy method of RFC 4103 [4] 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.
+
+   In order to avoid exceeding the capabilities of the sender, receiver,
+   or network (congestion), the transmission rate SHOULD be kept at or
+   below 30 characters per second, which is the default maximum rate
+   specified in RFC 4103 [4].  Lower rates MAY be negotiated when needed
+   through the "cps" parameter as specified in RFC 4103 [4].
+
+   Real-time text capability 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 the
+   RFC 4103 [4] transport MUST be used as both the default and the
+   fallback transport.
+
+
+
+
+van Wijk & Gybels            Informational                     [Page 17]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+6.2.3.  Transcoding Services
+
+   Invocation of a transcoding service 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 [28] describes invoking relay 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
+
+   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.
+
+   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 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.
+
+
+
+
+van Wijk & Gybels            Informational                     [Page 18]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+6.2.4.3.  Text Presentation
+
+   Requirement R32 states that, in the display of text conversations,
+   users must be able to distinguish easily between different speakers.
+   This could be done using color, positioning of the text (i.e.,
+   incoming real-time text and outgoing real-time text in different
+   display areas), in-band identifiers of the parties, or a combination
+   of any of these techniques.
+
+6.2.4.4.  File Storage
+
+   Requirement R31 recommends that ToIP systems allow the user to save
+   text conversations.  This SHOULD be done using a standard file
+   format.  For example: a UTF-8 text file in XHTML format [15],
+   including timestamps, party names (or addresses), and the
+   conversation text.
+
+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 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 (i.e.,
+   users must inform each other) or at the "protocol" level (where an
+   indication must be sent back to the gateway).  However, special care
+   needs to be taken to provide the best possible real-time performance.
+
+   Buffering schemes SHOULD 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 3000 characters).
+
+   When converting between simultaneous voice and text on the IP side,
+   and alternating voice and text on the other side of a gateway, a
+   conflict can occur if the IP user 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 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.
+
+
+
+
+
+van Wijk & Gybels            Informational                     [Page 19]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+   Session setup through gateways to other networks may require the use
+   of specially formatted addresses or other mechanisms for invoking
+   those gateways.
+
+   ToIP interworking requires a method to invoke a text gateway.  These
+   text gateways act as User Agents at the IP side.  The capabilities of
+   the 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 real-
+   time text, so the 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. Real-time text capability indicators.
+
+   d. Real-time text preference indicators.
+
+   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. A text gateway with its own telephone number and/or SIP address
+      (this requires user interaction with the 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.
+
+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
+   [16], which also defines the modem detection sequences for the
+   different text protocols.  In rare cases, the modem type
+   identification may take considerable time, depending on user actions.
+
+
+
+
+
+van Wijk & Gybels            Informational                     [Page 20]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+   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 in the region where the gateway is located.
+   For example, in the USA, Baudot [25] might be tried as the initial
+   protocol.  If negotiation for Baudot fails, the full V.18 modem
+   capability exchange will take place.  In the UK, ITU-T V.21 [26]
+   might be the first choice.
+
+   In particular, transmission of real-time text on PSTN networks takes
+   place using a variety of codings and modulations, including ITU-T
+   V.21 [26], Baudot [25], dual-tone multi-frequency (DTMF), V.23 [27],
+   and others.  Many difficulties have arisen as a result of this
+   variety in text telephony protocols and the ITU-T V.18 [16] standard
+   was developed to address some of these issues.
+
+   ITU-T V.18 [16] offers a native text telephony method, plus it
+   defines interworking with current protocols.  In the interworking
+   mode, it will recognise one of the older protocols and fall back to
+   that transmission method when required.
+
+   Text gateways MUST use the ITU-T V.18 [16] standard at the PSTN side.
+   A text gateway MUST act as a SIP User Agent on the IP side and
+   support RFC 4103 real-time text transport.
+
+   While ToIP allows receiving and sending real-time text simultaneously
+   and is displayed on a split screen, many analog text 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 users apply strict turn-taking rules.
+
+   There are several text telephones which communicate in full duplex,
+   but merge transmitted text and received text in the same line in the
+   same display window.  Here too the users apply strict turn taking
+   rules.
+
+   Native V.18 text telephones support full duplex and separate display
+   from reception and transmission so that the full duplex capability
+   can be used fully.  Such devices could use the ToIP split screen as
+   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 why it is important for the ToIP user to know that he or she
+   is connected with an analog text telephone.  The session description
+   [9] SHOULD contain an indication that the other endpoint for the call
+
+
+
+
+van Wijk & Gybels            Informational                     [Page 21]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+   is a PSTN textphone (e.g., connected via an ATA or through a text
+   gateway).  This means that the textphone user may be used to formal
+   turn taking during the call.
+
+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, as well as WiFi or WiMAX.
+
+   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 Enhanced Full Rate (EFR) [17] and Enhanced Variable Rate
+   (EVR) [18] speech vocoders in mobile terminals used to provide a text
+   telephony call.  It provides full duplex operation and supports
+   alternating between voice and text ("VCO/HCO").  It is dedicated to
+   CDMA and TDMA mobile technologies and the US Baudot (i.e., 45 bit/s)
+   type of text telephones.
+
+6.2.5.2.2.  Cellular Text Telephone Modem (CTM)
+
+   CTM [7] is a technology-independent modem technology that provides
+   the transport of 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 cellular
+   phone mode that allows TTYs to operate into a cellular phone and to
+   communicate with a fixed-line TTY.  Thus it is a common name for the
+   "No-Gain" and the CTM solutions when applied to the Baudot-type
+   textphones.
+
+
+
+
+
+
+
+
+
+van Wijk & Gybels            Informational                     [Page 22]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+6.2.5.2.4.  Mobile Data Channel Mode
+
+   Many mobile terminals allow the use of the circuit-switched data
+   channel 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 [19].
+
+6.2.5.3.  Instant Messaging Interworking
+
+   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 the two
+   formats.  Text gateways for interworking between Instant Messaging
+   and ToIP MUST 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.
+
+   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.
+
+   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.
+
+   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.
+
+   e. Text Gateways must be capable of maintaining the real-time
+      performance for ToIP while providing the interworking services.
+
+   It is RECOMMENDED that during the session, both users be constantly
+   updated on the progress of the text input.  Many Instant Messaging
+   protocols signal that a user is typing to the other party in the
+
+
+
+van Wijk & Gybels            Informational                     [Page 23]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+   conversation.  Text gateways between such Instant Messaging protocols
+   and ToIP MUST provide this signalling 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,
+   character display, Internet connectivity, and SIP stack 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.
+
+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 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 could support the following interworking
+   functions:
+
+   - PSTN text telephony to ToIP
+
+   - PSTN text telephony to Instant Messaging
+
+   - Instant Messaging to ToIP
+
+
+
+
+
+van Wijk & Gybels            Informational                     [Page 24]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+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 be possible to place an emergency call using ToIP and it must
+   be possible to use a relay service in such a call.  The emergency
+   service provided to users utilising the real-time text medium must be
+   equivalent to the emergency service provided to users utilising
+   speech or other media.
+
+   A text gateway 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 the USA and "112" in Europe.  Routing
+   real-time text calls to emergency services may require the use of a
+   transcoding service.
+
+   A text gateway with cellular wireless packet-switched services 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].
+
+
+
+van Wijk & Gybels            Informational                     [Page 25]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+   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 endpoint terminal or the text
+   gateway in the network at the endpoint), 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 a high quality of service.
+
+   NOTE: It is preferred that such analog terminal adaptors do use RFC
+   4103 [4] 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 endpoints.
+   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 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.
+
+7.5.  Quality of Service
+
+   Where Quality of Service (QoS) mechanisms are used, the real-time
+   text streams should be assigned appropriate QoS characteristics, so
+   that the performance requirements can be met and the real-time text
+   stream is not degraded unfavourably in comparison to voice
+   performance in congested situations.
+
+8.  Security Considerations
+
+   User confidentiality and privacy need to be met as described in SIP
+   [2].  For example, nothing should reveal in an obvious way the fact
+   that the ToIP user might be a person with a hearing or speech
+   impairment.  It is up to the ToIP user to make his or her hearing or
+   speech impairment public.  If a transcoding server is being used,
+
+
+
+van Wijk & Gybels            Informational                     [Page 26]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+   this SHOULD be as transparent as possible.  However, it might still
+   be possible to discern that a user might be hearing or speech
+   impaired based on the attributes present in SDP, although the
+   intention is that mainstream users might also choose to use ToIP.
+   Encryption SHOULD be used on an end-to-end or hop-by-hop basis as
+   described in SIP [2] and SRTP [20].
+
+   Authentication MUST be provided for users in addition to 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.  Contributors
+
+   The following people contributed to 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.
+
+10.  References
+
+10.1.  Normative References
+
+   [1]   Bradner, S., Ed., "Intellectual Property Rights in IETF
+         Technology", BCP 79, RFC 3979, March 2005.
+
+   [2]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
+         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
+         Session Initiation Protocol", RFC 3261, June 2002.
+
+   [3]   Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
+         "RTP: A Transport Protocol for Real-Time Applications", STD 64,
+         RFC 3550, July 2003.
+
+   [4]   Hellstrom, G. and P. Jones, "RTP Payload for Text
+         Conversation", RFC 4103, June 2005.
+
+   [5]   ITU-T Recommendation F.703,"Multimedia Conversational
+         Services", November 2000.
+
+   [6]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+van Wijk & Gybels            Informational                     [Page 27]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+   [7]   3GPP TS 26.226, "Cellular Text Telephone Modem Description"
+         (CTM).
+
+   [8]   ITU-T Recommendation T.140, "Protocol for Multimedia
+         Application Text Conversation" (February 1998) and Addendum 1
+         (February 2000).
+
+   [9]   Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+         Description Protocol", RFC 4566, July 2006.
+
+   [10]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
+         User Agent Capabilities in the Session Initiation Protocol
+         (SIP)", RFC 3840, August 2004.
+
+   [11]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
+         Preferences for the Session Initiation Protocol (SIP)", RFC
+         3841, August 2004.
+
+   [12]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
+         Session Description Protocol (SDP)", RFC 3264, June 2002.
+
+   [13]  Camarillo, G., Burger, E., Schulzrinne, H., and A. van Wijk,
+         "Transcoding Services Invocation in the Session Initiation
+         Protocol (SIP) Using Third Party Call Control (3pcc)", RFC
+         4117, June 2005.
+
+   [14]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
+         63, RFC 3629, November 2003.
+
+   [15]  "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.
+
+   [16]  ITU-T Recommendation V.18, "Operational and Interworking
+         Requirements for DCEs operating in Text Telephone Mode",
+         November 2000.
+
+   [17]  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)"
+
+   [18]  TIA/EIA/IS-127-2, "Enhanced Variable Rate Codec, Speech Service
+         Option 3 for Wideband Spread Spectrum Digital Systems, Addendum
+         2."
+
+   [19]  "IP Multimedia default codecs", 3GPP TS 26.235
+
+
+
+
+
+van Wijk & Gybels            Informational                     [Page 28]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+   [20]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+         Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
+         3711, March 2004.
+
+   [21]  ITU-T Recommendation F.700, "Framework Recommendation for
+         Multimedia Services", November 2000.
+
+10.2.  Informative References
+
+   [22]  Charlton, N., Gasson, M., Gybels, G., Spanner, M., and A. van
+         Wijk, "User Requirements for the Session Initiation Protocol
+         (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired
+         Individuals", RFC 3351, August 2002.
+
+   [23]  Sinnreich, H., Ed., Lass, S., and C. Stredicke, "SIP Telephony
+         Device Requirements and Configuration", RFC 4504, May 2006.
+
+   [24]  European Telecommunications Standards Institute (ETSI), "Human
+         Factors (HF); Guidelines for Telecommunication Relay Services
+         for Text Telephones". TR 101 806, June 2000.
+
+   [25]  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.)
+
+   [26]  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.
+
+   [27]  International Telecommunication Union (ITU), "600/1200-baud
+         modem standardized for use in the general switched telephone
+         network", ITU-T Recommendation V.23, November 1988.
+
+   [28]  Camarillo, G., "Framework for Transcoding with the Session
+         Initiation Protocol", Work in Progress, May 2006.
+
+   [29]  Camarillo, G., "The SIP Conference Bridge Transcoding Model",
+         Work in Progress, January 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+van Wijk & Gybels            Informational                     [Page 29]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+Authors' Addresses
+
+   Guido Gybels
+   Department of New Technologies
+   RNID, 19-23 Featherstone Street
+   London EC1Y 8SL, UK
+
+   Tel +44-20-7294 3713
+   Txt +44-20-7296 8001 Ext 3713
+   Fax +44-20-7296 8069
+   EMail: guido.gybels@rnid.org.uk
+   http://www.ictrnid.org.uk
+
+
+   Arnoud A. T. van Wijk
+   Real-Time Text Taskforce (R3TF)
+
+   EMail: arnoud@realtimetext.org
+   http://www.realtimetext.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+van Wijk & Gybels            Informational                     [Page 30]
+
+RFC 5194              Framework for TOIP using SIP             June 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   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, THE IETF TRUST 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.
+
+
+
+
+
+
+
+
+
+
+
+
+van Wijk & Gybels            Informational                     [Page 31]
+