draft-ietf-sipping-toip-04.txt   draft-ietf-sipping-toip-05.txt 
SIPPING Workgroup A. van Wijk, Editor
Internet Draft G. Gybels, Editor
Category: Informational June 25, 2006
Expires: December 27, 2006
SIPPING Workgroup Framework for real-time text over IP using the Session Initiation
Internet Draft A. van Wijk Protocol (SIP)
Category: Informational AnnieS draft-ietf-sipping-toip-05.txt
Expires: September 5 2006 March 6, 2006
Framework for real-time text over IP using SIP
draft-ietf-sipping-toip-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware have
have been or will be disclosed, and any of which he or she becomes been or will be disclosed, and any of which he or she becomes aware
aware will be disclosed, in accordance with Section 6 of BCP 79. will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering Task
Task Force (IETF), its areas, and its working groups. Note that Force (IETF), its areas, and its working groups. Note that other
other groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-Drafts.
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 5, 2006. This Internet-Draft will expire on December 27, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document provides a framework for the implementation of real- This document lists the essential requirements for real-time Text-
time text conversation over the IP network using the Session over-IP (ToIP) and defines a framework for implementation of all
Initiation Protocol and the Real-Time Transport Protocol. It lists required functions based on the Session Initiation Protocol (SIP) and
the essential requirements for real-time Text-over-IP (ToIP) and the Real-Time Transport Protocol (RTP). This includes interworking
defines a framework for implementation of all required functions between Text-over-IP and existing text telephony on the PSTN and other
based on existing protocols and techniques. This includes networks.
interworking between Text-over-IP and existing text telephony on the
PSTN and other networks.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction....................................................2
2. Scope..........................................................4 2. Scope...........................................................3
3. Terminology....................................................4 3. Terminology.....................................................3
4. Definitions....................................................4 4. Definitions.....................................................4
5. Requirements...................................................6 5. Requirements....................................................5
5.1 General requirements for ToIP..............................6 5.1 General requirements for ToIP................................6
5.2 Detailed requirements for ToIP.............................8 5.2 Detailed requirements for ToIP...............................7
5.2.1 Session control and set-up requirements...............8
5.2.2 Transport requirements................................9
5.2.3 Transcoding service requirements.....................10
5.2.4 Presentation and User control requirements...........11
5.2.5 Interworking requirements............................12
5.2.5.1 PSTN Interworking requirements..................12
5.2.5.2 Cellular Interworking requirements..............12
5.2.5.3 Instant Messaging Interworking requirements.....13
6. Implementation Framework......................................13
6.1 Framework of general implementation.......................13
6.2 Framework of detailed implementation......................14
6.2.1 Session control and set-up...........................14
6.2.1.1 Pre-session setup...............................14
6.2.1.2 Basic Point-to-Point Session setup..............15
6.2.1.3 Addressing......................................15
6.2.1.4 Session Negotiations............................15
6.2.1.5 Additional session control......................16
6.2.2 Transport............................................16
6.2.3 Transcoding services.................................17
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 Answering Machine...............................18
6.2.4.4 Text presentation...............................19
6.2.4.5 File storage....................................19
6.2.5 Interworking functions...............................19
6.2.5.1 PSTN Interworking...............................20
6.2.5.2 Mobile Interworking.............................21
6.2.5.2.1 Cellular "No-gain".........................21
6.2.5.2.2 Cellular Text Telephone Modem (CTM)........21
6.2.5.2.3 Cellular "Baudot mode".....................22
6.2.5.2.4 Mobile data channel mode...................22
6.2.5.2.5 Mobile ToIP................................22
6.2.5.3 Instant Messaging Interworking..................22
6.2.5.4 Interworking through gateways...................23
6.2.5.5 Multi-functional Combination gateways...........24
6.2.5.6 Character set transcoding.......................25
7. Further recommendations for implementers and service providers25
7.1 Access to Emergency services..............................25
7.2 Home Gateways or Analog Terminal Adapters.................26
7.3 User Mobility.............................................26
7.4 Firewalls and NATs........................................26
8. IANA Considerations...........................................26
9. Security Considerations.......................................26
10. Authorsí Addresses...........................................27
11. References...................................................28
11.1 Normative references.....................................28
11.2 Informative references...................................30
1. van Wijk, et al. Expires December 27, 2006 [Page 1]
Introduction 5.2.1 Session set-up and control requirements..................7
5.2.2 Transport requirements...................................8
5.2.3 Transcoding service requirements.........................9
5.2.4 Presentation and User control requirements..............10
5.2.5 Interworking requirements...............................11
5.2.5.1 PSTN Interworking requirements......................11
5.2.5.2 Cellular Interworking requirements..................12
5.2.5.3 Instant Messaging Interworking requirements.........12
6. Implementation Framework.......................................12
6.1 General implementation framework............................13
6.2 Detailed implementation framework...........................13
6.2.1 Session control and set-up..............................13
6.2.1.1 Pre-session set-up..................................13
6.2.1.2 Session Negotiations................................14
6.2.2 Transport...............................................14
6.2.3 Transcoding services....................................15
6.2.4 Presentation and User control functions.................15
6.2.4.1 Progress and status information.....................15
6.2.4.2 Alerting............................................16
6.2.4.3 Text presentation...................................16
6.2.4.4 File storage........................................16
6.2.5 Interworking functions..................................16
6.2.5.1 PSTN Interworking...................................17
6.2.5.2 Mobile Interworking.................................18
6.2.5.2.1 Cellular "No-gain"..............................19
6.2.5.2.2 Cellular Text Telephone Modem (CTM).............19
6.2.5.2.3 Cellular "Baudot mode"..........................19
6.2.5.2.4 Mobile data channel mode........................19
6.2.5.2.5 Mobile ToIP.....................................19
6.2.5.3 Instant Messaging Interworking......................19
6.2.5.4 Multi-functional Combination gateways...............21
6.2.5.5 Character set transcoding...........................21
7. Further recommendations for implementers and service providers.21
7.1 Access to Emergency services................................21
7.2 Home Gateways or Analog Terminal Adapters...................22
7.3 User Mobility...............................................22
7.4 Firewalls and NATs..........................................22
8. IANA Considerations............................................22
9. Security Considerations........................................23
10. Authors Addresses..............................................23
11. Contributors...................................................23
12. References.....................................................24
12.1 Normative references........................................24
12.2 Informative references......................................25
1. Introduction
For many years, text has been in use as a medium for conversational, For many years, text has been in use as a medium for conversational,
interactive dialogue between users in a similar way to how voice interactive dialogue between users in a similar way to how voice
telephony is used. Such interactive text is different from messaging telephony is used. Such interactive text is different from messaging
and semi-interactive solutions like Instant Messaging in that it and semi-interactive solutions like Instant Messaging in that it
offers an equivalent conversational experience to users who cannot, offers an equivalent conversational experience to users who cannot, or
or do not wish to, use voice. It therefore meets a different set of
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 requirements from other text-based solutions already available on IP
networks. networks.
Traditionally, deaf, hard of hearing and speech-impaired people are Traditionally, deaf, hard of hearing and speech-impaired people are
amongst the most prolific users of conversational, interactive text amongst the most prolific users of conversational, interactive text
but, because of its interactivity, it is becoming popular amongst but, because of its interactivity, it is becoming popular amongst
mainstream users as well. 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 This document describes how existing IETF protocols can be used to
implement a Text-over-IP solution (ToIP). This ToIP framework is implement a Text-over-IP solution (ToIP). This ToIP framework is
specifically designed to be compatible with Voice-over-IP (VoIP) and specifically designed to be compatible with Voice-over-IP (VoIP),
Multimedia-over-IP (MoIP) environments, as well as meeting the userís Video-over-IP and Multimedia-over-IP (MoIP) environments, as well as
requirements, including those of deaf, hard of hearing and speech- meeting the requirements of deaf, hard of hearing and speech-impaired
impaired users as described in RFC3351 [2] and mainstream users. 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 The Session Initiation Protocol (SIP) [3] is the protocol of choice
for control of Multimedia communications and Voice-over-IP (VoIP) in for control of Multimedia communications and Voice-over-IP (VoIP) in
particular. It offers all the necessary control and signaling particular. It offers all the necessary control and signalling
required for the ToIP framework. required for the ToIP framework.
The Real-Time Transport Protocol (RTP) [4] is the protocol of choice The Real-Time Transport Protocol (RTP) [4] is the protocol of choice
for real-time data transmission, and its use for real-time text for real-time data transmission, and its use for real-time text
payloads is described in RFC4103 [5]. payloads is described in RFC4103 [5].
This document defines a framework for ToIP to be used either by This document defines a framework for ToIP to be used either by itself
itself or as part of integrated, multi-media services, including or as part of integrated, multi-media services, including Total
Total Conversation [6]. Conversation [6].
2. 2. Scope
Scope
This document defines a framework for the implementation of real-time This document defines a framework for the implementation of real-time
ToIP, either stand-alone or as a part of multimedia services, ToIP, either stand-alone or as a part of multimedia services,
including Total Conversation [6]. It defines the: including Total Conversation [6]. 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.
a. Requirements of Real-time text; 3. Terminology
b. Requirements for ToIP interworking;
c. Description of ToIP implementation using SIP and RTP;
d. Description of ToIP interworking with other text services.
3. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Terminology "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.
In this document, the key words "MUST", "MUST NOT", "REQUIRED", van Wijk, et al. Expires December 27, 2006 [Page 3]
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [7] and indicate requirement levels for
compliant implementations.
4. 4. Definitions
Definitions
Audio bridging: a function of an audio media bridge server, gateway Audio bridging: a function of an audio media bridge server, gateway or
or relay service that bridges audio into a single source through relay service that sends to each destination the combination of audio
combining audio from multiple users excluding each destination from all participants in a conference excluding the participant(s) at
sourceís audio and sends to each respective destination enabling an that destination. At the RTP level, this is an instance of the mixer
audio path through the service between the users involved in the function as defined in RFC 3550 [4].
call.
Cellular: a telecommunication network that has wireless access and Cellular: a telecommunication network that has wireless access and can
can support voice and data services over very large geographical support voice and data services over very large geographical areas.
areas. Also called Mobile. Also called Mobile.
Full duplex: media is sent independently in both directions. Full duplex: media is sent independently in both directions.
Half duplex: media can only be sent in one direction at a time or, if Half duplex: media can only be sent simultaneously in one direction
an attempt to send information in both directions is made, errors can or, if an attempt to send information in both directions is made,
be introduced into the presented media. errors may be introduced into the presented media.
Interactive text: a term for real time transmission of text in a Interactive text: another term for real-time text, as defined below.
character-by-character fashion for use in conversational services,
often as a text equivalent to voice based conversational services.
(Equivalent to real-time text.)
Real-time text: a term for real time transmission of text in a Real-time text: a term for real time transmission of text in a
character-by-character fashion for use in conversational services, character-by-character fashion for use in conversational services,
often as a text equivalent to voice based conversational services. often as a text equivalent to voice based conversational services.
Conversational text is defined in ITU-T F.700 Framework for Conversational text is defined in the ITU-T Framework for multimedia
multimedia services [25]. services, Recommendation F.700 [25].
Text gateway: a function that transcodes between different forms of Text gateway: a function that transcodes between different forms of
real-time text transport methods, e.g., between ToIP in IP networks real-time text transport methods, e.g., between ToIP in IP networks
and Baudot or ITU-T V.21 text telephony in the PSTN. and Baudot or ITU-T V.21 text telephony in the PSTN.
Textphone: also "text telephone". A terminal device that allows end- Textphone: also "text telephone". A terminal device that allows end-
to-end real-time, interactive text communication using analog to-end real-time, interactive text communication using analog
transmission. A variety of PSTN textphone protocols exists world- transmission. A variety of PSTN textphone protocols exists world-wide.
wide. A textphone can often be combined with a voice telephone, or A textphone can often be combined with a voice telephone, or include
include voice communication functions for simultaneous or alternating voice communication functions for simultaneous or alternating use of
use of text and voice in a call. text and voice in a call.
Text bridging: a function of a gateway service that enables the flow Text bridging: a function of the text media bridge server, gateway
of text through the service between the users involved in the call. (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 Text relay service: a third-party or intermediary that enables
communications between deaf, hard of hearing and speech-impaired communications between deaf, hard of hearing and speech-impaired
people, and voice telephone users by translating between voice and people and voice telephone users by translating between voice and
real-time text in a call. 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. Text telephony: analog textphone service.
Total Conversation: a multimedia service offering real time Total Conversation: a multimedia service offering real time
conversation in video, real-time text and voice according to conversation in video, real-time text and voice according to
interoperable standards. All media flow in real time. (See ITU-T
F.703 "Multimedia conversational services" [6].)
Transcoding Services: services of a third-party user agent that van Wijk, et al. Expires December 27, 2006 [Page 4]
transcodes one stream into another. Transcoding can be done by human interoperable standards. All media streams flow in real time. (See
operators, in an automated manner or a combination of both methods. ITU-T F.703 "Multimedia conversational services" [6].)
Text Relay Services are examples of a transcoding service between
real-time text and audio.
TTY: alternative designation for a text telephone or textphone, often Transcoding service: a service provided by a third-party user agent
used in USA. Also called TDD, Telecommunication Device for the Deaf. 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.
Video Relay Service: A service that enables communications between TTY: originally, an abbreviation for "teletype". Often used in North
deaf and hard of hearing people, and hearing persons with voice America as an alternative designation for a text telephone or
telephones by translating between sign language and spoken language textphone. Also called TDD, Telecommunication Device for the Deaf.
in a call.
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: Acronyms:
2G Second generation cellular (mobile) 2G Second generation cellular (mobile)
2.5G Enhanced second generation cellular (mobile) 2.5G Enhanced second generation cellular (mobile)
3G Third generation cellular (mobile) 3G Third generation cellular (mobile)
CDMA Code Division Multiple Access CDMA Code Division Multiple Access
CLI Calling Line Identification CLI Calling Line Identification
CTM Cellular Text Telephone Modem CTM Cellular Text Telephone Modem
ENUM E.164 number storage in DNS (see RFC3761) ENUM E.164 number storage in DNS (see RFC3761)
GSM Global System of Mobile Communication GSM Global System for Mobile Communications
ISDN Integrated Services Digital Network ISDN Integrated Services Digital Network
ITU-T International Telecommunications Union-Telecommunications ITU-T International Telecommunications Union-Telecommunications
Standardisation Sector Standardisation Sector
NAT Network Address Translation NAT Network Address Translation
PSTN Public Switched Telephone Network PSTN Public Switched Telephone Network
RTP Real Time Transport Protocol RTP Real Time Transport Protocol
SDP Session Description Protocol SDP Session Description Protocol
SIP Session Initiation Protocol SIP Session Initiation Protocol
SRTP Secure Real Time Transport Protocol SRTP Secure Real Time Transport Protocol
TDD Telecommunication Device for the Deaf TDD Telecommunication Device for the Deaf
TDMA Time Division Multiple Access TDMA Time Division Multiple Access
TTY Analog textphone (Teletypewriter) TTY Analog textphone (Teletypewriter)
ToIP Real-time Text over Internet Protocol ToIP Real-time Text over Internet Protocol
UTF-8 Universal Transfer Format-8 UTF-8 Universal Transfer Format-8
VCO/HCO Voice Carry Over/Hearing Carry Over VCO/HCO Voice Carry Over/Hearing Carry Over
VoIP Voice over Internet Protocol VoIP Voice over Internet Protocol
5. 5. Requirements
Requirements
This framework defines a text-based conversational service that is
the text equivalent of voice based telephony. This section describes
the requirements that the framework is designed to meet and the
functionality it should offer.
Real-time text conversation can be combined with other conversational
services like video or voice.
ToIP also offers an IP equivalent of analog text telephony services The framework described in section 6 defines a text-based
as used by deaf, hard of hearing, speech-impaired and mainstream conversational service that is the text equivalent of voice based
users.
This section (Requirements) informs implementers about WHICH van Wijk, et al. Expires December 27, 2006 [Page 5]
requirements the systems and services shall meet. The next section telephony. This section describes the requirements that the framework
(Section 6 Framework Implementation) describes HOW to do it. is designed to meet and the functionality it should offer.
5.1 5.1 General requirements for ToIP
General requirements for ToIP
Any framework for ToIP must be designed to meet the requirements of Any framework for ToIP must be designed to meet the requirements of
RFC3351 [2]. A basic requirement is that it must provide a RFC3351 [2]. A basic requirement is that it must provide a
standardized way for offering text-based, conversational services standardized way for offering text-based, conversational services that
that can be used as an equivalent to voice telephony by deaf, hard of can be used as an equivalent to voice telephony by deaf, hard of
hearing speech-impaired and mainstream users. hearing speech-impaired and mainstream users.
It is important to understand that real-time text conversations are It is important to understand that real-time text conversations are
significantly different from other text-based communications like significantly different from other text-based communications like
email or Instant Messaging. Real-time text conversations deliver an email or Instant Messaging. Real-time text conversations deliver an
equivalent mode to voice conversations by providing transmission of equivalent mode to voice conversations by providing transmission of
text character by character as it is entered, so that the text character by character as it is entered, so that the conversation
conversation can be followed closely and immediate interaction take can be followed closely and immediate interaction take place.
place.
Store-and-forward systems like email or messaging on mobile networks Store-and-forward systems like email or messaging on mobile networks
or non-streaming systems like instant messaging are unable to provide or non-streaming systems like instant messaging are unable to provide
that functionality. In particular, they do not allow for smooth that functionality. In particular, they do not allow for smooth
communication through a Text Relay Service. communication through a Text Relay Service.
In order to make ToIP the text equivalent of voice services, it needs In order to make ToIP the text equivalent of voice services, it needs
to offer equivalent features in terms of conversationality as voice to offer equivalent features in terms of conversationality to those
telephony provides. To achieve that, ToIP needs to: provided by voice. To achieve that, ToIP needs to:
a. Offer real-time transport and presentation of the conversation; a. offer real-time transport and presentation of the conversation;
b. Provide simultaneous transmission in both directions; b. provide simultaneous transmission in both directions;
c. Support both point-to-point and multipoint communication; c. support both point-to-point and multipoint communication;
d. Allow other media, like audio and video, to be used in d. allow other media, like audio and video, to be used in conjunction
conjunction with ToIP; with ToIP;
e. Ensure that the real-time text service is always available. e. ensure that the real-time text service is always available.
Real-time text is a useful subset of Total Conversation defined in Real-time text is a useful subset of Total Conversation as defined in
ITU-T F.703 [6]. Users could use multiple modes of communication ITU-T F.703 [6]. Total Conversation allows participants to use
during the conversation, either at the same time or by switching multiple modes of communication during the conversation, either at the
between modes, e.g., between real-time text and audio. 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 Deaf, hard-of-hearing and mainstream users may invoke ToIP services
for many different reasons: for many different reasons:
- Because they are in a noisy environment, e.g., in a machine room of - because they are in a noisy environment, e.g., in a machine room of
a factory where listening is difficult. a factory where listening is difficult;
- Because they are busy with another call and want to participate in - because they are busy with another call and want to participate in
two calls at the same time. two calls at the same time;
- For implementing text and/or speech recording services (e.g., text - for implementing text and/or speech recording services (e.g., text
documentation/ audio recording for legal/clarity/flexibility documentation/ audio recording) for legal purposes, for clarity or
purposes). for flexibility;
- To overcome language barriers through speech translation and/or - to overcome language barriers through speech translation and/or
transcoding services. transcoding services;
- Because of hearing loss, deafness or tinnitus as a result of the
aging process or for any other reason, thus creating a need to van Wijk, et al. Expires December 27, 2006 [Page 6]
replace or complement voice with real-time text in conversational - because of hearing loss, deafness or tinnitus as a result of the
sessions. 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, text may accompany speech. The text 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 could be displayed side by side, or in a manner similar to subtitling
in broadcasting environments, or in any other suitable manner. This in broadcasting environments, or in any other suitable manner. This
could occur with users who are hard of hearing and also for mixed could occur with users who are hard of hearing and also for mixed
media calls with both hearing and deaf people participating in the media calls with both hearing and deaf people participating in the
call. call.
A ToIP user may wish to call another ToIP user, or join a conference A ToIP user may wish to call another ToIP user, join a conference
session involving several users or initiate or join a multimedia session involving several users, or initiate or join a multimedia
session, such as a Total Conversation session. session, such as a Total Conversation session.
5.2 5.2 Detailed requirements for ToIP
Detailed requirements for ToIP
The following sections lists individual requirements for ToIP. Each The following sections list individual requirements for ToIP. Each
requirement has been given a uniquely identifier (R1, R2, etc). requirement has been given a unique identifier (R1, R2, etc). Section
Section 6 (Implementation Framework) describes how to implement ToIP 6 (Implementation Framework) describes how to implement ToIP based on
based on these requirements and using existing protocols and these requirements and using existing protocols and techniques.
techniques.
5.2.1 The requirements are organized under the following headings:
Session control and set-up requirements - session set-up and session control;
- transport;
- use of transcoding services;
- presentation and user control;
- interworking.
Users will set up a session by identifying the remote party or the 5.2.1 Session set-up and control requirements
service they want to connect to. However, conversations could be
started using a mode other than the real-time text.
Simultaneous or alternating use of voice and real-time text is used Conversations could be started using a mode other than the real-time
by a large number of users who can send voice but must receive text text. Simultaneous or alternating voice and real-time text is used by
(due to a hearing impairment), or who can hear but must send text a large number of people who can send voice but must receive text (due
(due to a speech impairment). 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- R1: It SHOULD be possible to start conversations in any mode (real-
time text, voice, video) or combination of modes. time text, voice, video) or combination of modes.
R2: It MUST be possible for the users to switch to real-time text, or 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 add real-time text as an additional modality, during the conversation.
conversation.
R3: Systems supporting ToIP MUST allow users to select any of the R3: Systems supporting ToIP MUST allow users to select any of the
supported conversation modes at any time, including mid-conversation. supported conversation modes at any time, including in mid-
conversation.
R4: Systems SHOULD allow the user to specify a preferred mode of R4: Systems SHOULD allow the user to specify a preferred mode of
communication, with the ability to fall back to alternatives that the communication in each direction, with the ability to fall back to
user has indicated are acceptable. alternatives that the user has indicated are acceptable.
R5: If the user requests simultaneous use of real-time text and van Wijk, et al. Expires December 27, 2006 [Page 7]
audio, and this is not possible either because the system only R5: If the user requests simultaneous use of real-time text and audio,
supports alternate modalities or because of constraints in the and this is not possible because of constraints in the network, the
network, the system MUST try to establish communication with best system SHOULD try to establish text only communication.
effort.
R6: If the user has expressed a preference for real-time text, R6: If the user has expressed a preference for real-time text,
establishment of a connection including real-time text MUST have establishment of a connection including real-time text MUST have
priority over other outcomes of the session setup. priority over other outcomes of the session setup.
R7: It SHOULD be possible to use the real-time text medium in R7: It MUST be possible to use real-time text in conferences both as a
conference sessions in a similar way to how audio is handled and medium of discussion between individual participants (for example, for
video is displayed. sidebar discussions in text while listening to the main conference
audio) and for central support of the conference with real time text
Real-time text in conferences can be used both for letting individual
participants use the text medium (for example, for sidebar
discussions in text while listening to the main conference audio), as
well as for central support of the conference with real time text
interpretation of speech. interpretation of speech.
R8: During session set up, it SHOULD be possible for the users to R8: Session set up and negotiation of modalities MUST allow 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 allow users to
specify the language of the real-time text to be used. (It is specify the language of the real-time text to be used. (It is
recommended that similar functionality is provided for the video part RECOMMENDED that similar functionality be provided for the video part
of the conversation, i.e. to specify the sign language being used). of the conversation, i.e. to specify the sign language being used).
5.2.2 R9: Where certain session services are available for the audio media
Transport requirements 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- ToIP will often be used to access a relay service [I], allowing real-
time text users to communicate with voice users. With relay services, time text users to communicate with voice users. With relay services,
it is crucial that text characters are sent as soon as possible after it is crucial that text characters are sent as soon as possible after
they are entered. While buffering may be done to improve efficiency, they are entered. While buffering may be done to improve efficiency,
the delays SHOULD be kept minimal. In particular, buffering of whole the delays SHOULD be kept minimal. In particular, buffering of whole
lines of text will not meet character delay requirements. lines of text will not meet character delay requirements.
R10: Characters must be transmitted soon after entry of each R10: Characters must be transmitted soon after entry of each character
character so that the maximum delay requirement can be met. A delay so that the maximum delay requirement can be met. An end-to-end delay
time of one second is regarded good, while a delay of two seconds is time of one second is regarded as good, while a delay of two seconds
possible to use. is possible to use.
R11: It must be possible to transmit characters at a rate sufficient R11: Real-time text transmission from a terminal SHALL be performed
to support fast human typing as well as speech to text methods of character by character as entered, or in small groups of characters,
generating conversation text. A rate of 20 characters per second is so that no character is delayed from entry to transmission by more
regarded sufficient. than 300 milliseconds.
R12: a ToIP service must be able to deal with international character 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 conversational 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. sets.
R13: Where it is possible, loss of real-time text during transport 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. should be detected and the user should be informed.
R14: Transport of real-time text should be as robust as possible, so R15: Transport of real-time text should be as robust as possible, so
as to minimize loss of characters. as to minimize loss of characters.
R15: Where possible, it must be possible to send and receive real- R16: It SHOULD be possible to send and receive real-time text
time text simultaneously. simultaneously.
5.2.3 5.2.3 Transcoding service requirements
Transcoding service requirements
If the User Agents of different participants indicate that there is If the User Agents of different participants indicate that there is an
an incompatibility between their capabilities to support certain incompatibility between their capabilities to support certain media
media types, e.g. one terminal only offering T.140 over IP as types, e.g. one User Agent only offering T.140 over IP as described in
described in RFC4103 [5] and the other one only supporting audio, the RFC4103 [5] and the other one only supporting audio, the user might
user might want to invoke a transcoding service. want to invoke a transcoding service.
Some users may indicate their preferred modality to be audio while Some users may indicate their preferred modality to be audio while
others may indicate real-time text. In this case, transcoding others may indicate real-time text. In this case, transcoding services
services might be needed for text-to-speech (TTS) and speech-to-text might be needed for text-to-speech (TTS) and speech-to-text (STT).
(STT). Other examples of possible scenarios for including a relay Other examples of possible scenarios for including a relay service in
service in the conversation are: text bridging after conversion from the conversation are: text bridging after conversion from speech,
speech, audio bridging after conversion from real-time text, etc. audio bridging after conversion from real-time text, etc.
A number of requirements, motivations and implementation guidelines A number of requirements, motivations and implementation guidelines
for relay service invocation can be found in RFC 3351 [2]. for relay service invocation can be found in RFC 3351 [2].
R16: It MUST be possible for users to invoke a transcoding service R17: It MUST be possible for users to invoke a transcoding service
where such service is available. where such service is available.
R17: It MUST be possible for users to indicate their preferred R18: It MUST be possible for users to indicate their preferred
modality. modality (e.g. ToIP).
R18: The requirements for transcoding services need to be negotiated R19: It MUST be possible to negotiate the requirements for transcoding
in real-time to set up the session. services in real time in the process of setting up a call.
R19: Adding or removing a relay service MUST be possible without R20: It MUST be possible to negotiate the requirements for transcoding
disrupting the current session. services in mid-call, for the immediate addition of those services to
the call.
R20: When setting up a session, it MUST be possible for a user to R21: Communication between the end participants SHOULD continue after
determine the type of relay service requested (e.g., speech to text the addition or removal of a text relay service, and the effect of the
or text to speech). The specification of a type of relay MUST include change should be limited in the users' perception to the direct effect
a language specifier. of having or not having the transcoding service in the connection.
R21: It SHOULD be possible to route the session to a preferred relay 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 MUST include a
language specifier.
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 service even if the user invokes the session from another region or
network than that usually used. network than that usually used.
5.2.4 R24: It is RECOMMENDED that ToIP implementations make the invocation
Presentation and User control requirements and use of relay services as easy as possible.
R22: User Agents for ToIP services must have alerting methods (e.g., 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 deafblind
individuals.
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 for incoming sessions) that can be used by deaf and hard of hearing
people or provide a range of alternative, but equivalent, alerting people or provide a range of alternative, but equivalent, alerting
methods that can be selected by all users, regardless of their methods that can be selected by all users, regardless of their
abilities. abilities.
R23: Where real-time text is used in conjunction with other media, R26: Where real-time text is used in conjunction with other media,
exposure of user control functions through the User Interface needs exposure of user control functions through the User Interface needs to
to be done in an equivalent manner for all supported media. 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
In other words, where certain call control functions are available tactile prompts, or both must be supplied.
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.
R24: If present, identification of the originating party (for example R27: If available, identification of the originating party (for
in the form of a URL or a CLI) MUST be clearly presented to the user example in the form of a URL or a CLI) MUST be clearly presented to
in a form suitable for the user BEFORE the session invitation is the user in a form suitable for the user BEFORE the session invitation
answered. is answered.
R25: When a session invitation involving ToIP originates from a PSTN R28: When a session invitation involving ToIP originates from a PSTN
text telephone (e.g. transcoded via a text gateway), this SHOULD be text telephone (e.g. transcoded via a text gateway), this SHOULD be
indicated to the user. The ToIP client MAY adjust the presentation of indicated to the user. The ToIP client MAY adjust the presentation of
the real-time text to the user as a consequence. the real-time text to the user as a consequence.
R26: An indication should be given to the user when real-time text is 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 available during the call, even if it is not invoked at call setup
(e.g. when only voice and/or video is used initially). (e.g. when only voice and/or video is used initially).
R27: The user MUST be informed of any change in modalities. R30: The user MUST be informed of any change in modalities.
R28: Users must be presented with appropriate session progress R31: Users MUST be presented with appropriate session progress
information at all times. information at all times.
R29: Answering machine functions SHOULD be provided by the User R32: Systems for ToIP SHOULD support an answering machine function,
Agent. equivalent to answering machines on telephony networks.
R30: When the answering machine function is enabled on the User R33: If an answering machine function is supported, it MUST support at
Agent, alerting of the user SHOULD still be possible and users SHOULD least 160 characters for the greeting message. It MUST support
be able to take over control from the answering machine function at incoming real-time text message storage of a minimum of 4096
any time. 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.
R31: Users SHOULD be able to save the text portion of a conversation. 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.
R32: The presentation of the conversation should be done in such a R35: It SHOULD be possible to save the text portion of a conversation.
way that users can easily identify which party generated any given
portion of text.
5.2.5 R36: The presentation of the conversation SHOULD be done in such a way
Interworking requirements 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 There is a range of existing real-time text services. There is also a
range of network technologies that could support real-time text range of network technologies that could support real-time text
services. services.
Real-time/Interactive texting facilities exist already in various Real-time/interactive texting facilities exist already in various
forms and on various networks. On the PSTN, it is commonly referred forms and on various networks. In the PSTN, they are commonly referred
to as text telephony. to as text telephony.
Text gateways are used for converting between different media types. Text gateways are used for converting between different protocols for
They could be used between networks or within networks where text conversation. They can be used between networks or within
different transport technologies are used. networks where different transport technologies are used.
R33: ToIP SHOULD provide interoperability with text conversation R38: ToIP SHOULD provide interoperability with text conversation
features in other networks, for instance the PSTN. features in other networks, for instance the PSTN.
R34: When communicating via a gateway to other networks and R39: When communicating via a gateway to other networks and protocols,
protocols, the ToIP service SHOULD support the functionality for the ToIP service SHOULD support the functionality for alternating or
alternating or simultaneous use of modalities as offered by the simultaneous use of modalities as offered by the interworking network.
interworking network.
R35: Address information, both called and calling, SHOULD be R40: Calling party identification information, such as CLI, MUST be
transferred, and possibly converted, when interworking between passed by gateways and converted to an appropriate form if required.
different networks.
R36: When interworking with other networks and services, the ToIP R41: When interworking with other networks and services, the ToIP
service SHOULD provide buffering mechanisms to deal with delays in service SHOULD provide buffering mechanisms to deal with delays in
call setup, transmission speeds and/or to interwork with half duplex call setup, differences in transmission speeds and/or to interwork
services. with half duplex services.
5.2.5.1 5.2.5.1 PSTN Interworking requirements
PSTN Interworking requirements
Analog text telephony is being used in many countries, mainly by Analog text telephony is being used in many countries, mainly by deaf,
deaf, hard of hearing and speech-impaired individuals. hard of hearing and speech-impaired individuals.
R37: ToIP services MUST provide interworking with PSTN legacy text R42: ToIP services MUST provide interworking with PSTN legacy text
telephony devices. telephony devices.
R38: When interworking with PSTN legacy text telephony services, R43: When interworking with PSTN legacy text telephony services,
alternating text and voice function MAY be supported. (Called "voice alternating text and voice function MAY be supported. (Called "voice
carry over (VCO) and hearing carry over (HCO)"). carry over (VCO) and hearing carry over (HCO)").
5.2.5.2 5.2.5.2 Cellular Interworking requirements
Cellular Interworking requirements
As mobile communications have been adopted widely, various solutions As mobile communications have been adopted widely, various solutions
for real-time texting while on the move have been developed. ToIP for real-time texting while on the move were developed. ToIP services
services should provide interworking with such services as well. should provide interworking with such services as well.
Alternative means of transferring the Text telephony data have been Alternative means of transferring the Text telephony data have been
developed when TTY services over cellular was mandated by the FCC in developed when TTY services over cellular were mandated by the FCC in
the USA. They are a) "No-gain" codec solution, b) the Cellular Text the USA. They are a) "No-gain" codec solution, b) the Cellular Text
Telephony Modem (CTM) solution [8] and c) "Baudot mode" solution. 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 The GSM and 3G standards from 3GPP make use of the CTM modem in the
voice channel for text telephony. However, implementations also exist voice channel for text telephony. However, implementations also exist
that use the data channel to provide such functionality. Interworking that use the data channel to provide such functionality. Interworking
with these solutions SHOULD be done using text gateways that set up 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 the data channel connection at the GSM side and provide ToIP at the
other side. other side.
R39: a ToIP service SHOULD provide interworking with mobile text R44: a ToIP service SHOULD provide interworking with mobile text
conversation services. conversation services.
5.2.5.3 5.2.5.3 Instant Messaging Interworking requirements
Instant Messaging Interworking requirements
Many people use Instant Messaging to communicate via the Internet Many people use Instant Messaging to communicate via the Internet
using text. Instant Messaging usually transfers blocks of text rather using text. Instant Messaging usually transfers blocks of text rather
than streaming as is used by ToIP. Usually a specific action is than streaming as is used by ToIP. Usually a specific action is
required by the user to activate transmission, such as pressing the 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 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 and in particular does not meet the needs for real time conversations
including those of deaf, hard of hearing and speech-impaired users as including those of deaf, hard of hearing and speech-impaired users as
defined in RFC 3351 [2]. It is unsuitable for communications through defined in RFC 3351 [2]. It is less suitable for communications
a relay service [I]. The streaming nature of ToIP provides a more through a relay service [I].
direct conversational user experience and, when given the choice,
users may prefer ToIP.
R39: a ToIP service MAY provide interworking with Instant Messaging
services.
6. The streaming nature of ToIP provides a more direct conversational
Implementation Framework user experience and, when given the choice, users may prefer ToIP.
This section describes an implementation framework for ToIP that R45: a ToIP service MAY provide interworking with Instant Messaging
meets the requirements and offers the functionality as set out in services.
section 5. The framework presented here uses existing standards that
are already commonly used for voice based conversational services on
IP networks.
6.1 6. Implementation Framework
Framework of general implementation
ToIP uses the Session Initiation Protocol (SIP) [3] to set up, This section describes an implementation framework for ToIP that meets
control and tear down the connections between users whilst the media the requirements and offers the functionality as set out in section 5.
is transported using the Real-Time Transport Protocol (RTP) [4] as The framework presented here uses existing standards that are already
described in RFC4103 [5]. commonly used for voice based conversational services on IP networks.
SIP [3] allows participants to negotiate all media including real- 6.1 General implementation framework
time text conversation [5]. This is a highly desirable function for
all IP telephony users but essential for deaf, hard of hearing, or
speech impaired people who have limited or no use of the audio path
of the call. 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, This framework specifies the use of the Session Initiation Protocol
as well as its privacy and security provisions, MUST be maintained by (SIP) [3] to set up, control and tear down the connections between
ToIP services. ToIP users whilst the media is transported using the Real-Time
Transport Protocol (RTP) [4] as described in RFC4103 [5].
Real-time text conversation based on the presentation protocol T.140 RFC 4504 describes how to implement support for interactive text in
[9], in addition to audio and video communications, is a valuable SIP telephony devices [23].
service for many users, including those on non-IP networks. T.140
also provides for basic real-time editing of the text.
6.2 6.2 Detailed implementation framework
Framework of detailed implementation
6.2.1 6.2.1 Session control and set-up
Session control and set-up
ToIP services MUST use the Session Initiation Protocol (SIP) [3] for ToIP services MUST use the Session Initiation Protocol (SIP) [3] for
setting up, controlling and terminating sessions for real-time text setting up, controlling and terminating sessions for real-time text
conversation with one or more participants and possibly including conversation with one or more participants and possibly including
other media like video or audio. The session description protocol other media like video or audio. The session description protocol
(SDP) used in SIP to describe the session is used to express the (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 attributes of the session and to negotiate a set of compatible media
types. types.
6.2.1.1 SIP [3] allows participants to negotiate all media including real-time
Pre-session setup 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.
The requirements of the user to be reached at a consistent address 6.2.1.1 Pre-session set-up
and to store preferences for evaluation at session setup are met by
pre-session setup actions. That includes storing of registration 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 information in the SIP registrar, to provide information about how a
user can be contacted. This will allow sessions to be set up rapidly user can be contacted. This will allow sessions to be set up rapidly
and with proper routing and addressing. and with proper routing and addressing.
The need to use real-time text as a medium of communications can be The need to use real-time text as a medium of communications can be
expressed by users during registration time. Two situations need to expressed by users during registration time. Two situations need to be
be considered in the pre-session setup environment: considered in the pre-session setup environment:
a. User Preferences: It MUST be possible for a user to indicate a a. User Preferences: It MUST be possible for a user to indicate a
preference for real-time text by registering that preference with a preference for real-time text by registering that preference with a
SIP server that is part of the ToIP service. SIP server that is part of the ToIP service.
b. Server support of User Preferences: SIP servers that support ToIP b. Server support of User Preferences: SIP servers that support ToIP
services MUST have the capability to act on calling user preferences services MUST have the capability to act on calling user
for real-time text in order to accept or reject the session.The preferences for real-time text in order to accept or reject the
actions taken can be based on the called userís preferences defined session. The actions taken can be based on the called users
as part of the pre-session setup registration. For example, if the preferences defined as part of the pre-session setup registration.
user is called by another party, and it is determined that a For example, if the user is called by another party, and it is
transcoding server is needed, the session should be re-directed or determined that a transcoding server is needed, the session should
otherwise handled accordingly. be re-directed or otherwise handled accordingly.
6.2.1.2 The ability to include a transcoding service MUST NOT require user
Basic Point-to-Point Session setup 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, A point-to-point session takes place between two parties. For ToIP,
one or both of the communicating parties will indicate real-time text one or both of the communicating parties will indicate real-time text
as a possible or preferred medium for conversation using SIP in the as a possible or preferred medium for conversation using SIP in the
session setup. session setup.
The following features MAY be implemented to facilitate the session The following features MAY be implemented to facilitate the session
establishment using ToIP: establishment using ToIP:
a. Caller Preferences: SIP headers (e.g., Contact)[11] can be used to a. Caller Preferences: SIP headers (e.g., Contact)[11] can be used to
show that ToIP is the medium of choice for communications. show that real-time text is the medium of choice for
communications.
b. Called Party Preferences [12]: The called party being passive can b. Called Party Preferences [12]: The called party being passive can
formulate a clear rule indicating how a session should be handled formulate a clear rule indicating how a session should be handled
either using real-time text as a preferred medium or not, and whether either using real-time text as a preferred medium or not, and
a designated SIP proxy needs to handle this session or it will be whether a designated SIP proxy needs to handle this session or it
handled in the SIP user agent. will be handled in the SIP user agent.
c. SIP Server support for User Preferences: It is RECOMMENDED that c. SIP Server support for User Preferences: It is RECOMMENDED that SIP
SIP servers also handle the incoming sessions in accordance with servers also handle the incoming sessions in accordance with
preferences expressed for real-time text. The SIP Server can also preferences expressed for real-time text. The SIP Server can also
enforce ToIP policy rules for communications (e.g. use of the enforce ToIP policy rules for communications (e.g. use of the
transcoding server for ToIP). transcoding server for ToIP).
6.2.1.3 6.2.1.2 Session Negotiations
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
Session Negotiations
The Session Description Protocol (SDP) used in SIP [3] provides the The Session Description Protocol (SDP) used in SIP [3] provides the
capabilities to indicate real-time text as a medium in the session capabilities to indicate real-time text as a medium in the session
setup. RFC 4103 [5] uses the RTP payload types "text/red" and 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 "text/t140" for support of ToIP which can be indicated in the SDP as a
a part of the SIP INVITE, OK and SIP/200/ACK media negotiations. In part of the SIP INVITE, OK and SIP/200/ACK media negotiations. In
addition, SIPís offer/answer model [13] can also be used in addition, SIPs offer/answer model [13] can also be used in conjunction
conjunction with other capabilities including the use of a with other capabilities including the use of a transcoding server for
transcoding server for enhanced session negotiations [14,15,16]. enhanced session negotiations [14,15,16].
Systems SHOULD provide a best-effort approach to answering
invitations for session set-up and users SHOULD be informed when the
session is accepted by 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 6.2.2 Transport
type.
ToIP services MUST support the Real-Time Transport Protocol (RTP) [4] ToIP services MUST support the Real-Time Transport Protocol (RTP) [4]
according to the specification of RFC4103 [4] for the transport of according to the specification of RFC4103 [4] for the transport of
text between participants. text between participants.
RFC4103 describes the transmission of T.140 [9] real-time text on IP RFC4103 describes the transmission of T.140 [9] real-time text on IP
networks. networks.
In order to enable the use of international character sets, the In order to enable the use of international character sets, the
transmission format for text conversation SHALL be UTF-8 [17], in transmission format for text conversation SHALL be UTF-8 [17], in
accordance with ITU-T T.140. accordance with ITU-T T.140.
If real-time text is detected to be missing after transmission, there 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 SHOULD be a "text loss" indication in the real-time text as specified
in T.140 Addendum 1 [9]. 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 The redundancy method of RFC 4103 [5] SHOULD be used to significantly
increase the reliability of the real-time text transmission. A increase the reliability of the real-time text transmission. A
redundancy level using 2 generations gives very reliable results and redundancy level using 2 generations gives very reliable results and
is therefore strongly RECOMMENDED. is therefore strongly RECOMMENDED.
Real-time text capability MUST be announced in SDP by a declaration Real-time text capability is announced in SDP by a declaration similar
similar to this example: to this example:
m=text 11000 RTP/AVP 100 98 m=text 11000 RTP/AVP 100 98
a=rtpmap:98 t140/1000 a=rtpmap:98 t140/1000
a=rtpmap:100 red/1000 a=rtpmap:100 red/1000
a=fmtp:100 98/98/98 a=fmtp:100 98/98/98
By having this single coding and transmission scheme for real time By having this single coding and transmission scheme for real time
text defined in the SIP session control environment, the opportunity text defined in the SIP session control environment, the opportunity
for interoperability is optimized. However, if good reasons exist, for interoperability is optimized. However, if good reasons exist,
other transport mechanisms MAY be offered and used for the T.140 other transport mechanisms MAY be offered and used for the T.140 coded
coded text provided that proper negotiation is introduced, but RFC text provided that proper negotiation is introduced, but RFC 4103 [5]
4103 [5] transport MUST be used as both the default and the fallback transport MUST be used as both the default and the fallback transport.
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 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 specific type of transcoding service in a ToIP environment is a
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 6.2.3 Transcoding services
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 relay acts as a conference bridge or uses
the third party control mechanism. ToIP implementations SHOULD
support this transcoding framework.
6.2.4 Invokation of a transcoding service MAY happen automatically when the
Presentation and User control functions 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
relay acts as a conference bridge or uses the third party control
mechanism. ToIP implementations SHOULD support this transcoding
framework.
6.2.4.1 6.2.4 Presentation and User control functions
Progress and status information
During a conversation that includes ToIP, status and session progress 6.2.4.1 Progress and status information
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 Session progress information SHOULD use simple language so that as
many users as possible can understand it. The use of jargon or many users as possible can understand it. The use of jargon or
ambiguous terminology SHOULD be avoided. It is RECOMMENDED that text ambiguous terminology SHOULD be avoided. It is RECOMMENDED that text
information be used together with icons to symbolise the session information be used together with icons to symbolise the session
progress information. 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: In summary, it SHOULD be possible to observe indicators about:
- Incoming session - Incoming session
- Availability of real-time text, voice and video channels - Availability of real-time text, voice and video channels
- Session progress - Session progress
- Incoming real-time text - Incoming real-time text
- Any loss in incoming real-time text - Any loss in incoming real-time text
- Typed and transmitted real-time text. - Typed and transmitted real-time text.
6.2.4.2 6.2.4.2 Alerting
Alerting
For users who cannot use the audible alerter for incoming sessions, For users who cannot use the audible alerter for incoming sessions, it
it is RECOMMENDED to include a tactile as well as a visual indicator. is RECOMMENDED to include a tactile as well as a visual indicator.
Among the alerting options are alerting by the User Agentís User Among the alerting options are alerting by the User Agents User
Interface and specific alerting user agents registered to the same Interface and specific alerting user agents registered to the same
registrar as the main user agent. registrar as the main user agent.
It should be noted that external alerting systems exist and one It should be noted that external alerting systems exist and one common
common interface for triggering the alerting action is a contact interface for triggering the alerting action is a contact closure
closure between two conductors. between two conductors.
6.2.4.3
Answering Machine
Systems for ToIP MAY support an answering machine function,
equivalent to answering machines on telephony networks. If an
answering machine function is supported, it MUST support at least 160
characters for the greeting message. It MUST support incoming real-
time text 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 6.2.4.3 Text presentation
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 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 Requirement R32 requires that, in the display of text conversation,
during a session as specified in ITU-T T.140 [9]. users 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), by in-band identifiers of the parties or by a combination of
any of these techniques.
6.2.4.5 6.2.4.4 File storage
File storage
Systems that support ToIP MAY save the text conversation to a file. Requirement R31 recommends that ToIP systems allow the user to save
This SHOULD be done using a standard file format. For example: a UTF8 text conversations. This should be done using a standard file format.
text file in XHTML format [18] including timestamps, party names (or For example: a UTF8 text file in XHTML format [18] including
addresses) and the text conversation. timestamps, party names (or addresses) and the text conversation.
6.2.5 6.2.5 Interworking functions
Interworking functions
A number of systems for real time text conversation already exist as A number of systems for real time text conversation already exist as
well as a number of message oriented text communication systems. well as a number of message oriented text communication systems.
Interoperability is of interest between ToIP and some of these Interoperability is of interest between ToIP and some of these
systems. systems.
Interoperation of half-duplex and full-duplex protocols MAY require Interoperation of half-duplex and full-duplex protocols, and between
text buffering. Some intelligence will be needed to determine when to protocols that have different data rates, may require text buffering.
change direction when operating in half-duplex mode. Identification Some intelligence will be needed to determine when to change direction
may be required of half-duplex operation either at the "user" level when operating in half-duplex mode. Identification may be required of
(ie. users must inform each other) or at the "protocol" level (where half-duplex operation either at the "user" level (ie. users must
an indication must be sent back to the Gateway). However, the special inform each other) or at the "protocol" level (where an indication
care needs to be taken to provide the best possible real-time must be sent back to the Gateway). However, the special care needs to
performance. be taken to provide the best possible real-time performance.
6.2.5.1 Buffering schemes should be dimensioned to adjust for receiving at 30
PSTN Interworking 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.
Session set-up 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 indicator.
e. Listen for V.18 modem modulation text activity in all PSTN calls
and routing of the call to an appropriate gateway.
f. Call transfer request by the called user.
g. Placing a call via the web, and using one of the methods described
here
h. Text gateways with its own telephone number and/or SIP address.
(This requires user interaction with the 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 Analog text telephony is cumbersome because of incompatible national
implementations where interworking was never considered. A large implementations where interworking was never considered. A large
number of these implementations have been documented in ITU-T V.18 number of these implementations have been documented in ITU-T V.18
[19], which also defines the modem detection sequences for the [19], which also defines the modem detection sequences for the
different text protocols. The modem type identification may in rare different text protocols. The modem type identification may in rare
cases take considerable time depending on user actions. cases take considerable time depending on user actions.
To resolve analog textphone incompatibilities, text telephone To resolve analog textphone incompatibilities, text telephone gateways
gateways are needed to transcode incoming analog signals into T.140 are needed to transcode incoming analog signals into T.140 and vice
and vice versa. The modem capability exchange time can be reduced by versa. The modem capability exchange time can be reduced by the text
the text telephone gateways initially assuming the analog text telephone gateways initially assuming the analog text telephone
telephone protocol used in the region where the gateway is located. protocol used in the region where the gateway is located. For example,
For example, in the USA, Baudot [II] might be tried as the initial in the USA, Baudot [II] might be tried as the initial protocol. If
protocol. If negotiation for Baudot fails, the full V.18 modem negotiation for Baudot fails, the full V.18 modem capability exchange
capability exchange will take place. In the UK, ITU-T V.21 [III] will take place. In the UK, ITU-T V.21 [III] might be the first
might be the first choice. choice.
In particular transmission of interactive text on PSTN networks takes In particular transmission of interactive text on PSTN networks takes
place using a variety of codings and modulations, including ITU-T place using a variety of codings and modulations, including ITU-T V.21
V.21 [III], Baudot [II], DTMF, V.23 [IV] and others. Many [III], Baudot [II], DTMF, V.23 [IV] and others. Many difficulties have
difficulties have arisen as a result of this variety in text arisen as a result of this variety in text telephony protocols and the
telephony protocols and the ITU-T V.18 [19] standard was developed to ITU-T V.18 [19] standard was developed to address some of these
address some of these issues. issues.
ITU-T V.18 [19] offers a native text telephony method plus it defines ITU-T V.18 [19] offers a native text telephony method plus it defines
interworking with current protocols. In the interworking mode, it interworking with current protocols. In the interworking mode, it will
will recognise one of the older protocols and fall back to that recognise one of the older protocols and fall back to that
transmission method when required. transmission method when required.
Text gateways MUST use the ITU-T V.18 [19] standard at the PSTN side. Text gateways MUST use the ITU-T V.18 [19] standard at the PSTN side.
A text gateway MUST act as a SIP User Agent on the IP side and A text gateway MUST act as a SIP User Agent on the IP side and support
support RFC4103 text transport. RFC4103 text transport.
PSTN-ToIP gateways MUST allow alternating use of real-time text and
voice if the PSTN textphone involved at the PSTN side of the session
supports this. (This mode is often called VCO/HCO).
Calling party identification information, such as CLI, MUST be passed
by gateways and converted to an approapriate form if required.
While ToIP allows receiving and sending real-time text simultaneously While ToIP allows receiving and sending real-time text simultaneously
and is displayed on a split screen, many analog text telephones and is displayed on a split screen, many analog text telephones
require users to take turns typing. require users to take turns typing. This is because many text
This is because many text telephones operate strictly half duplex. telephones operate strictly half duplex. Only one can transmit text at
Only one can transmit text at a time. The users apply strict turn- a time. The users apply strict turn-taking rules.
taking rules.
There are several text telephones which communicate in full duplex, There are several text telephones which communicate in full duplex,
but merge transmitted text and received text in the same line in the but merge transmitted text and received text in the same line in the
same display window. And also here do the users apply strict turn same display window. And also here do the users apply strict turn
taking rules. taking rules.
Native V.18 text telephones support full duplex and separate display Native V.18 text telephones support full duplex and separate display
from reception and transmission so that the full duplex capability from reception and transmission so that the full duplex capability can
can be used fully. Such devices could use the ToIP split screen as be used fully. Such devices could use the ToIP split screen as well,
well, but almost all text telephones use a restricted character set but almost all text telephones use a restricted character set and many
and many use low text transmission speeds (4 to 7 charcters per use low text transmission speeds (4 to 7 characters per second).
second).
That is why it is important for the ToIP user to know that he or she 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 is connected with an analog text telephone. The "txp" media content
attribute [10]SHOULD be used to indicate that the call originates 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). from a PSTN text telephone (e.g. via an ATA or a text gateway).
6.2.5.2 6.2.5.2 Mobile Interworking
Mobile Interworking
Mobile wireless (or Cellular) circuit switched connections provide a Mobile wireless (or Cellular) circuit switched connections provide a
digital real-time transport service for voice or data. The access digital real-time transport service for voice or data. The access
technologies include GSM, CDMA, TDMA, iDen and various 3G technologies include GSM, CDMA, TDMA, iDen and various 3G
technologies. technologies.
ToIP may be supported over the cellular wireless packet switched ToIP may be supported over the cellular wireless packet switched
service. It interfaces to the Internet. service. It interfaces to the Internet.
The following sections describe how mobile text telephony is The following sections describe how mobile text telephony is
supported. supported.
6.2.5.2.1 6.2.5.2.1 Cellular "No-gain"
Cellular "No-gain"
The "No-gain" text telephone transporting technology uses specially The "No-gain" text telephone transporting technology uses specially
modified EFR [20] and EVR [21] speech vocoders in mobile terminals modified EFR [20] and EVR [21] speech vocoders in mobile terminals
used to provide a text telephony call. It provides full duplex used to provide a text telephony call. It provides full duplex
operation and supports alternating voice and text ("VCO/HCO"). It is operation and supports alternating voice and text ("VCO/HCO"). It is
dedicated to CDMA and TDMA mobile technologies and the US Baudot dedicated to CDMA and TDMA mobile technologies and the US Baudot (i.e.
(i.e. 45 bit/s) type of text telephones. 45 bit/s) type of text telephones.
6.2.5.2.2 6.2.5.2.2 Cellular Text Telephone Modem (CTM)
Cellular Text Telephone Modem (CTM)
CTM [8] is a technology independent modem technology that provides CTM [8] is a technology independent modem technology that provides the
the transport of text telephone characters at up to 10 characters/sec transport of text telephone characters at up to 10 characters/sec
using modem signals that can be carried by many voice codecs and uses using modem signals that can be carried by many voice codecs and uses
a highly redundant encoding technique to overcome the fading and cell a highly redundant encoding technique to overcome the fading and cell
changing losses. changing losses.
6.2.5.2.3 6.2.5.2.3 Cellular "Baudot mode"
Cellular "Baudot mode"
This term is often used by cellular terminal suppliers for a GSM This term is often used by cellular terminal suppliers for a cellular
cellular phone mode that allows TTYs to operate into a cellular phone phone mode that allows TTYs to operate into a cellular phone and to
and to communicate with a fixed line TTY. Thus it is a common name communicate with a fixed line TTY. Thus it is a common name for the
for the "No-Gain" and the CTM solutions when applied to the Baudot "No-Gain" and the CTM solutions when applied to the Baudot type
type textphones. textphones.
6.2.5.2.4 6.2.5.2.4 Mobile data channel mode
Mobile data channel mode
Many mobile terminals allow the use of the circuit switched data 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 channel to transfer data in real-time. Data rates of 9600 bit/s are
usually supported on the 2G mobile network. Gateways provide usually supported on the 2G mobile network. Gateways provide
interoperability with PSTN textphones. interoperability with PSTN textphones.
6.2.5.2.5 6.2.5.2.5 Mobile ToIP
Mobile ToIP
ToIP could be supported over mobile wireless packet switched services ToIP could be supported over mobile wireless packet switched services
that interface to the Internet. For 3GPP 3G services, ToIP support is that interface to the Internet. For 3GPP 3G services, ToIP support is
described in 3G TS 26.235 [22]. described in 3G TS 26.235 [22].
6.2.5.3 6.2.5.3 Instant Messaging Interworking
Instant Messaging Interworking
Text gateways MAY be used to allow interworking between Instant Text gateways MAY be used to allow interworking between Instant
Messaging systems and ToIP solutions. Because Instant Messaging is Messaging systems and ToIP solutions. Because Instant Messaging is
based on blocks of text, rather than on a continuous stream of based on blocks of text, rather than on a continuous stream of
characters like ToIP, gateways MUST transcode between the two characters like ToIP, gateways MUST transcode between the two formats.
formats. Text gateways for interworking between Instant Messaging and Text gateways for interworking between Instant Messaging and ToIP MUST
ToIP MUST apply a procedure for bridging the different conversational apply a procedure for bridging the different conversational formats of
formats of real-time text versus text messaging. The following advice real-time text versus text messaging. The following advice may improve
may improve user experience for both parties in a call through a user experience for both parties in a call through a messaging
messaging gateway. gateway.
a. Concatenate individual characters originating at the ToIP side a. Concatenate individual characters originating at the ToIP side into
into blocks of text. blocks of text.
b. When the length of the concatenated message becomes longer than 50 b. When the length of the concatenated message becomes longer than 50
characters, the buffered text SHOULD be transmitted to the Instant characters, the buffered text SHOULD be transmitted to the Instant
Messaging side as soon as any non-alphanumerical character is Messaging side as soon as any non-alphanumerical character is
received from the ToIP side. received from the ToIP side.
c. When a new line indicator is received from the ToIP side, the c. When a new line indicator is received from the ToIP side, the
buffered characters up to that point, including the carriage return buffered characters up to that point, including the carriage return
and/or line feed characters, SHOULD be transmitted to the Instant and/or line feed characters, SHOULD be transmitted to the Instant
Messaging side. Messaging side.
d. When the ToIP side has been idle for at least 5 seconds, all 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 buffered text up to that point SHOULD be transmitted to the Instant
Messaging side. Messaging side.
e. Text Gateways must be capable to maintain the real-time e. Text Gateways must be capable to maintain the real-time performance
performance for ToIP while providing the interworking services. for ToIP while providing the interworking services.
It is RECOMMENDED that during the session, both users are constantly It is RECOMMENDED that during the session, both users be constantly
updated on the progress of the text input. updated on the progress of the text input. Many Instant Messaging
Many Instant Messaging protocols signal that a user is typing to the protocols signal that a user is typing to the other party in the
other party in the conversation. Text gateways between such Instant conversation. Text gateways between such Instant Messaging protocols
Messaging protocols and ToIP MUST provide this signaling to the and ToIP MUST provide this signalling to the Instant Messaging side
Instant Messaging side when characters start being received, or at when characters start being received, or at the beginning of the
the beginning of the conversation. conversation.
At the ToIP side, an indicator of writing the Instant Message MUST be At the ToIP side, an indicator of writing the Instant Message MUST be
present where the Instant Messaging protocol provides one. For present where the Instant Messaging protocol provides one. For
example, the real-time text user MAY see ". . . waiting for replying example, the real-time text user MAY see ". . . waiting for replying
IM. . . " and when 5 seconds have passed another . (dot) can be IM. . . " and when 5 seconds have passed another . (dot) can be shown.
shown.
Those solutions will reduce the difficulties between streaming and Those solutions will reduce the difficulties between streaming and
blocked text services. blocked text services.
Even though the text gateway can connect Instant Messaging and ToIP, Even though the text gateway can connect Instant Messaging and ToIP,
the best solution is to take advantage of the fact that the user the best solution is to take advantage of the fact that the user
interfaces and the user communities for instant messaging and ToIP interfaces and the user communities for instant messaging and ToIP
telephony are very similar. After all, the character input, the telephony are very similar. After all, the character input, the
character display, Internet connectivity and SIP stack can be the character display, Internet connectivity and SIP stack can be the same
same for Instant Messaging (SIMPLE) and ToIP. Thus, the user may for Instant Messaging (SIMPLE) and ToIP. Thus, the user may simply use
simply use different applications for ToIP and text messaging in the different applications for ToIP and text messaging in the same
same terminal. terminal.
Devices that implement Instant Messaging SHOULD implement ToIP as Devices that implement Instant Messaging SHOULD implement ToIP as
described in this document so that a more complete text communication described in this document so that a more complete text communication
service can be provided. service can be provided.
6.2.5.4 6.2.5.4 Multi-functional Combination gateways
Interworking through gateways
Transcoding of text to and from other coding formats MAY need to take
place in gateways between ToIP and other forms of text conversation,
for example to connect to a PSTN text telephone.
Text gateways MUST allow for the differences that result from
different text protocols. The protocols to be supported will depend
on the service requirements of the Gateway.
Session setup through gateways to other networks MAY require the use
of specially formatted addresses or other mechanisms for invoking
those gateways.
Different data rates of different protocols MAY require text
buffering.
When text gateway functions are invoked, there will be a need for
intermediate storage of characters before transmission to a device
receiving text slower than the transmitting speed of the sender. Such
temporary storage SHALL be dimensioned to adjust for receiving at 30
characters per second and transmitting at 6 characters per second for
up to 4 minutes (i.e. less than 3000 characters).
ToIP interworking requires a method to invoke a text gateway. As
described previously, these text gateways MUST 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 indicator.
e. Listen for V.18 modem modulation text activity in all PSTN calls
and routing of the call to an appropriate gateway.
f. Call transfer request by the called user.
g. Placing a call via the web, and using one of the methods described
here
h. Text gateways with its own telephone number and/or SIP address.
(This requires user interaction with the 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.5
Multi-functional Combination gateways
In practice many interworking gateways will be implemented as In practice many interworking gateways will be implemented as gateways
gateways that combine different functions. As such, a text gateway that combine different functions. As such, a text gateway could be
could be built to have modems to interwork with the PSTN and support built to have modems to interwork with the PSTN and support both
both Instant Messaging as well as ToIP. Such interworking functions Instant Messaging as well as ToIP. Such interworking functions are
are called Combination gateways. called Combination gateways.
Combination gateways MUST provide interworking between all of their Combination gateways could provide interworking between all of their
supported text based functions. For example, a Text gateway that has supported text based functions. For example, a Text gateway that has
modems to interwork with the PSTN and that support both Instant modems to interwork with the PSTN and that support both Instant
Messaging and ToIP MUST support the following interworking functions: Messaging and ToIP could support the following interworking functions:
- PSTN text telephony to ToIP. - PSTN text telephony to ToIP.
- PSTN text telephony to Instant Messaging. - PSTN text telephony to Instant Messaging.
- Instant Messaging to ToIP. - Instant Messaging to ToIP.
6.2.5.6 6.2.5.5 Character set transcoding
Character set transcoding
Gateways between the ToIP network and other networks MAY need to Gateways between the ToIP network and other networks MAY need to
transcode text streams. ToIP makes use of the ISO 10646 character transcode text streams. ToIP makes use of the ISO 10646 character set.
set. Most PSTN textphones use a 7-bit character set, or a character Most PSTN textphones use a 7-bit character set, or a character set
set that is converted to a 7-bit character set by the V.18 modem. that is converted to a 7-bit character set by the V.18 modem.
When transcoding between character sets and T.140 in gateways, When transcoding between character sets and T.140 in gateways, special
special consideration MUST be given to the national variants of the 7 consideration MUST be given to the national variants of the 7 bit
bit codes, with national characters mapping into different codes in codes, with national characters mapping into different codes in the
the ISO 10646 code space. The national variant to be used could be 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 selectable by the user on a per call basis, or be configured as a
national default for the gateway. national default for the gateway.
The indicator of missing text in T.140, specified in T.140 amendment 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 1, cannot be represented in the 7 bit character codes. Therefore the
indicator of missing text SHOULD be transcoded to the Ď (apostrophe) indicator of missing text SHOULD be transcoded to the ' (apostrophe)
character in legacy text telephone systems, where this character character in legacy text telephone systems, where this character
exists. For legacy systems where the character Ď does not exist, the exists. For legacy systems where the ' character does not exist, the .
. (full stop) character SHOULD be used instead. (full stop) character SHOULD be used instead.
7. 7. Further recommendations for implementers and service providers
Further recommendations for implementers and service providers
7.1 7.1 Access to Emergency services
Access to Emergency services
It MUST be possible to place an emergency call using ToIP and it MUST It must be possible to place an emergency call using ToIP and it must
be possible to use a relay service in such call. The emergency be possible to use a relay service in such call. The emergency service
service provided to users utilising the real-time text medium MUST be provided to users utilising the real-time text medium must be
equivalent to the emergency service provided to users utilising equivalent to the emergency service provided to users utilising speech
speech or other media. or other media.
A text gateway MUST be able to route real-time text calls to A text gateway must be able to route real-time text calls to emergency
emergency service providers when any of the recognised emergency service providers when any of the recognised emergency numbers that
numbers that support text communications for the country or region support text communications for the country or region are called e.g.
are called e.g. "911" in 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 "911" in USA and "112" in Europe. Routing real-time text calls to
be able to route real-time text calls to emergency service providers emergency services may require the use of a transcoding service.
when any of the recognized emergency numbers that support real-time
text communication for the country is called.
7.2 A text gateway with cellular wireless packet switched services must be
Home Gateways or Analog Terminal Adapters 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 Analog terminal adapters (ATA) using SIP based IP communication and
RJ-11 connectors for connecting traditional PSTN devices SHOULD RJ-11 connectors for connecting traditional PSTN devices SHOULD enable
enable connection of legacy PSTN text telephones [23]. connection of legacy PSTN text telephones [23].
These adapters SHOULD contain V.18 modem functionality, voice These adapters SHOULD contain V.18 modem functionality, voice handling
handling functionality, and conversion functions to/from SIP based functionality, and conversion functions to/from SIP based ToIP with
ToIP with T.140 transported according to RFC 4103 [4], in a similar T.140 transported according to RFC 4103 [4], in a similar way as it
way as it provides interoperability for voice sessions. provides interoperability for voice sessions.
If a session is set up and text/t140 capability is not declared by If a session is set up and text/t140 capability is not declared by the
the destination endpoint (by the end-point terminal or the text destination endpoint (by the end-point terminal or the text gateway in
gateway in the network at the end-point), a method for invoking a the network at the end-point), a method for invoking a transcoding
transcoding server SHALL be used. If no such server is available, the server SHALL be used. If no such server is available, the signals from
signals from the textphone MAY be transmitted in the voice channel as the textphone MAY be transmitted in the voice channel as audio with
audio with high quality of service. high quality of service.
NOTE: It is preferred that such analog terminal adaptors do use RFC 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 4103 [5] on board and thus act as a text gateway. Sending textphone
signals over the voice channel is undesirable due to possible signals over the voice channel is undesirable due to possible
filtering and compression and packet loss between the end-points. filtering and compression and packet loss between the end-points. This
This can result in character loss in the textphone conversation or can result in character loss in the textphone conversation or even not
even not allowing the textphones to connect to each other. allowing the textphones to connect to each other.
7.3 7.3 User Mobility
User Mobility
ToIP User Agents SHOULD use the same mechanisms as other SIP User ToIP User Agents SHOULD use the same mechanisms as other SIP User
Agents to resolve mobility issues. It is RECOMMENDED that users use a Agents to resolve mobility issues. It is RECOMMENDED that users use a
SIP-address, resolved by a SIP registrar, to enable basic user SIP-address, resolved by a SIP registrar, to enable basic user
mobility. Further mechanisms are defined for all session types for 3G mobility. Further mechanisms are defined for all session types for 3G
IP multimedia systems. IP multimedia systems.
7.4 7.4 Firewalls and NATs
Firewalls and NATs
ToIP uses the same signaling and transport protocols as VoIP. Hence, ToIP uses the same signalling and transport protocols as VoIP. Hence,
the same firewall and NAT solutions and network functionality that the same firewall and NAT solutions and network functionality that
apply to VoIP MUST also apply to ToIP. apply to VoIP MUST also apply to ToIP.
8. 8. IANA Considerations
IANA Considerations
There are no IANA considerations for this specification. There are no IANA considerations for this specification.
9. 9. Security Considerations
Security Considerations
User confidentiality and privacy need to be met as described in SIP User confidentiality and privacy need to be met as described in SIP
[3]. For example, nothing should reveal the fact that the ToIP user [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 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 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 ToIP user to make his or her hearing or speech impairment public. If a
a transcoding server is being used, this SHOULD be transparent. transcoding server is being used, this SHOULD be transparent.
Encryption SHOULD be used on end-to-end or hop-by-hop basis as Encryption SHOULD be used on end-to-end or hop-by-hop basis as
described in SIP [3] and SRTP [24]. described in SIP [3] and SRTP [24].
Authentication needs to be provided for users in addition to the Authentication needs to be provided for users in addition to the
message integrity and access control. message integrity and access control.
Protection against Denial-of-service (DoS) attacks needs to be Protection against Denial-of-service (DoS) attacks needs to be
provided considering the case that the ToIP users might need provided considering the case that the ToIP users might need
transcoding servers. transcoding servers.
10. 10. Authors' Addresses
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 Guido Gybels
Department of New Technologies Department of New Technologies
RNID, 19-23 Featherstone Street RNID, 19-23 Featherstone Street
London EC1Y 8SL, UK London EC1Y 8SL, UK
Tel +44(0)20 7294 3713 Tel +44-20-7294 3713
Txt +44(0)20 7608 0511 Txt +44-20-7608 0511
Fax +44(0)20 7296 8069 Fax +44-20-7296 8069
Email: guido.gybels@rnid.org.uk 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 Arnoud A. T. van Wijk
Foundation for an Information and Communication Network for the Deaf Foundation for an Information and Communication Network for the Deaf
and Hard of Hearing and Hard of Hearing
"AnnieS" "AnnieS"
www.annies.nl http://www.annies.nl/
Email: arnoud@annies.nl Email: arnoud@annies.nl
11. 11. Contributors
References
11.1 The following people contributed to preliminary drafts of this
Normative references 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
12.1 Normative references
1. S. Bradner, "Intellectual Property Rights in IETF Technology", 1. S. Bradner, "Intellectual Property Rights in IETF Technology",
BCP 79, RFC 3979, IETF, March 2005. BCP 79, RFC 3979, IETF, March 2005.
2. Charlton, Gasson, Gybels, Spanner, van Wijk, "User Requirements 2. Charlton, Gasson, Gybels, Spanner, van Wijk, "User Requirements
for the Session Initiation Protocol (SIP) in Support of Deaf, for the Session Initiation Protocol (SIP) in Support of Deaf, Hard
Hard of Hearing and Speech-impaired Individuals", RFC 3351, of Hearing and Speech-impaired Individuals", RFC 3351, IETF,
IETF, August 2002. August 2002.
3. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 3. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session
Initiation Protocol", RFC 3621, IETF, June 2002. Initiation Protocol", RFC 3621, IETF, June 2002.
4. H. Schulzrinne, S.Casner, R. Frederick, V. Jacobsone, "RTP: A 4. H. Schulzrinne, S.Casner, R. Frederick, V. Jacobsone, "RTP: A
Transport Protocol for Real-Time Applications", RFC 3550, IETF, Transport Protocol for Real-Time Applications", RFC 3550, IETF,
July 2003. July 2003.
5. G. Hellstrom, P. Jones, "RTP Payload for Text Conversation", RFC 5. G. Hellstrom, P. Jones, "RTP Payload for Text Conversation",
4103, IETF, June 2005. RFC 4103, IETF, June 2005.
6. ITU-T Recommendation F.703,"Multimedia Conversational Services", 6. ITU-T Recommendation F.703,"Multimedia Conversational Services",
November 2000. November 2000.
7. S. Bradner, "Key words for use in RFCs to Indicate Requirement 7. S. Bradner, "Key words for use in RFCs to Indicate Requirement
8. 3GPP TS 26.226 "Cellular Text Telephone Modem Description" 8. 3GPP TS 26.226 "Cellular Text Telephone Modem Description" (CTM).
(CTM).
9. ITU-T Recommendation T.140, "Protocol for Multimedia Application 9. ITU-T Recommendation T.140, "Protocol for Multimedia Application
Text Conversation" (February 1998) and Addendum 1 (February Text Conversation" (February 1998) and Addendum 1 (February 2000).
2000).
10. J. Hautakorpi, G. Camarillo, "The SDP (Session Description 10. J. Hautakorpi, G. Camarillo, "The SDP (Session Description
Protocol) Content Attribute", IETF, February 2006 - Work in Protocol) Content Attribute", IETF, February 2006 - Work in
Progress. Progress.
11. J. Rosenberg, H. Schulzrinne, P. Kyzivat, "Indicating User Agent 11. J. Rosenberg, H. Schulzrinne, P. Kyzivat, "Indicating User Agent
Capabilities in the Session Initiation Protocol (SIP)", RFC Capabilities in the Session Initiation Protocol (SIP)", RFC 3840,
3840, IETF, August 2004 IETF, August 2004
12. J. Rosenberg, H. Schulzrinne, P. Kyzivat, "Caller Preferences 12. J. Rosenberg, H. Schulzrinne, P. Kyzivat, "Caller Preferences for
for the Session Initiation Protocol (SIP)", RFC 3841, IETF, the Session Initiation Protocol (SIP)", RFC 3841, IETF,
August 2004 August 2004
13. J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the 13. J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the
Session Description Protocol (SDP)", RFC 3624, IETF, June 2002. Session Description Protocol (SDP)", RFC 3624, IETF, June 2002.
14. G. Camarillo, "Framework for Transcoding with the Session 14. G. Camarillo, "Framework for Transcoding with the Session
Initiation Protocol" IETF Nov 2005 - Work in progress. Initiation Protocol" IETF Nov 2005 - Work in progress.
15. G. Camarillo, H. Schulzrinne, E. Burger, and A. van Wijk, 15. G. Camarillo, H. Schulzrinne, E. Burger, and A. van Wijk,
"Transcoding Services Invocation in the Session Initiation "Transcoding Services Invocation in the Session Initiation
Protocol (SIP) Using Third Party Call Control (3pcc)" RFC 4117, Protocol (SIP) Using Third Party Call Control (3pcc)" RFC 4117,
IETF, June 2005. IETF, June 2005.
16. G. Camarillo, "The SIP Conference Bridge Transcoding Model," 16. G. Camarillo, "The SIP Conference Bridge Transcoding Model," IETF,
IETF, Jan 2006 - Work in Progress. January 2006 - Work in Progress.
17. Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 17. Yergeau, F., "UTF-8, a transformation format of ISO 10646",
3629, IETF,November 2003. RFC 3629, IETF,November 2003.
18. "XHTML 1.0: The Extensible HyperText Markup Language: A 18. "XHTML 1.0: The Extensible HyperText Markup Language: A
Reformulation of HTML 4 in XML 1.0", W3C Recommendation. Reformulation of HTML 4 in XML 1.0", W3C Recommendation. Available
Available at http://www.w3.org/TR/xhtml1. at http://www.w3.org/TR/xhtml1.
19. ITU-T Recommendation V.18,"Operational and Interworking 19. ITU-T Recommendation V.18,"Operational and Interworking
Requirements for DCEs operating in Text Telephone Mode," Requirements for DCEs operating in Text Telephone Mode",
November 2000. November 2000.
20. TIA/EIA/IS-823-A "TTY/TDD Extension to TIA/EIA-136-410 Enhanced 20. TIA/EIA/IS-823-A "TTY/TDD Extension to TIA/EIA-136-410 Enhanced
Full Rate Speech Codec (must used in conjunction with Full Rate Speech Codec (must used in conjunction with
TIA/EIA/IS-840)" TIA/EIA/IS-840)"
21. TIA/EIA/IS-127-2 "Enhanced Variable Rate Codec, Speech Service 21. TIA/EIA/IS-127-2 "Enhanced Variable Rate Codec, Speech Service
Option 3 for Wideband Spread Spectrum Digital Systems. Addendum Option 3 for Wideband Spread Spectrum Digital Systems.
2." Addendum 2."
22. "IP Multimedia default codecs". 3GPP TS 26.235 22. "IP Multimedia default codecs". 3GPP TS 26.235
23. H. Sinnreich, S. Lass, and C. Stredicke, "SIP Telephony Device 23. H. Sinnreich, S. Lass, and C. Stredicke, "SIP Telephony Device
Requirements and Configuration," IETF, October 2005 - Work in Requirements and Configuration" RFC 4504, IETF, May 2006.
Progress.
24. Baugher, McGrew, Carrara, Naslund, Norrman, "The Secure Real 24. Baugher, McGrew, Carrara, Naslund, Norrman, "The Secure Real Time
Time Transport Protocol (SRTP)", RFC 3711, IETF, March 2004. Transport Protocol (SRTP)", RFC 3711, IETF, March 2004.
25. ITU-T Recommendation F.700,"Framework Recommendation for 25. ITU-T Recommendation F.700,"Framework Recommendation for
Multimedia Services", November 2000. Multimedia Services", November 2000.
11.2 12.2 Informative references
Informative references
I. A relay service allows the users to transcode between different I. A relay service allows the users to transcode between different
modalities or languages. In the context of this document, relay modalities or languages. In the context of this document, relay
services will often refer to text relays that transcode text into services will often refer to text relays that transcode text into
voice and vice-versa. See for example http://www.typetalk.org. 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 II. TIA/EIA/825 "A Frequency Shift Keyed Modem for Use on the Public
Switched Telephone Network." (The specification for 45.45 and 50 Switched Telephone Network." (The specification for 45.45 and 50
bit/s TTY modems.) bit/s TTY modems.)
III. International Telecommunication Union (ITU), "300 bits per III. International Telecommunication Union (ITU), "300 bits per second
second duplex modem standardized for use in the general switched duplex modem standardized for use in the general switched
telephone network". ITU-T Recommendation V.21, November 1988. telephone network". ITU-T Recommendation V.21, November 1988.
IV. International Telecommunication Union (ITU), "600/1200-baud modem IV. International Telecommunication Union (ITU), "600/1200-baud modem
standardized for use in the general switched telephone network". ITU- standardized for use in the general switched telephone network".
T Recommendation V.23, November 1988. ITU-T Recommendation V.23, November 1988.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on an
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be found
found in BCP 78 and BCP 79. in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this specification
specification can be obtained from the IETF on-line IPR repository at can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Acknowledgement Acknowledgement
 End of changes. 219 change blocks. 
861 lines changed or deleted 668 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/