draft-ietf-sipping-toip-01.txt   draft-ietf-sipping-toip-02.txt 
Internet Engineering Task Force SIPPING WG SIPPING Workgroup A. van Wijk (editor)
Internet Draft Internet-Draft Viataal
Document: <draft-ietf-sipping-toip-01.txt> A. van Wijk (editor) Category: Informational
July 18 2005 Viataal Expires: February 21 2006 August 22 2005
Expires: January 17 2006
Informational
Framework of requirements for real-time text conversation using SIP. Framework of requirements for real-time text conversation using SIP
draft-ietf-sipping-toip-02.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 been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79
[1].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." 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 January 17, 2006. This Internet-Draft will expire on February 21, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document provides the framework of requirements for real-time This document provides the framework of requirements for real-time
character-by-character interactive text conversation over the IP character-by-character interactive text conversation over the IP
network using the Session Initiation Protocol and the Transport network using the Session Initiation Protocol and the Real-Time
Protocol for Real-Time Applications. It discusses requirements for Transport Protocol. It discusses requirements for real-time Text-
real-time Text-over-IP telephony as well as interworking between over-IP as well as interworking between Text-over-IP and existing
Text-over-IP telephony and existing text telephony on the PSTN and text telephony on the PSTN and other networks.
other networks.
A. van Wijk [Page 1 of 28] A. van Wijk, et al. Expires 21 February 2006 [Page 1 of 28]
Table of Contents Table of Contents
1. Introduction 3 1. Introduction.....................................................3
2. Scope 3 2. Scope............................................................4
3. Terminology 3 3. Terminology......................................................4
4. Definitions 4 4. Definitions......................................................4
5. Framework Description 5 5. Framework Description............................................6
5.1. Background 5 5.1. General requirements for ToIP..................................6
5.2. Requirements for ToIP 6 5.1.1 General ToIP Summary..........................................8
5.3. Use of SIP and RTP 6 5.2. General Requirements for ToIP Interworking.....................8
5.4. Requirements for ToIP Interworking 9 5.2.1 PSTN Interworking.............................................9
6. Detailed requirements for Text-over-IP 9 5.2.2 Cellular circuit switched Text-Telephony.....................10
6.1. Pre-Call Requirements 10 5.2.2.1 Cellular "No-gain".........................................10
6.2 Basic Point-to-Point Call Requirements 10 5.2.2.2 Cellular Text Telephone Modem (CTM)........................10
6.2.1 Session Setup 10 5.2.2.3 Cellular "Baudot mode".....................................11
6.2.2 Addressing 11 5.2.3 Cellular data channel mode...................................11
6.2.3 Alerting and session progress presentation 11 5.2.4 Cellular Wireless ToIP.......................................11
6.2.4 Call Negotiations 12 5.2.5 Instant Messaging Support....................................11
6.2.5 Answering 12 6. Detailed requirements for ToIP..................................11
6.2.6 Actions During Calls 13 6.1. Pre-Session Requirements......................................12
6.2.7 Additional session control 14 6.2 Basic Point-to-Point Session Requirements......................12
6.2.8 File storage 15 6.2.1 Session control..............................................12
6.3 Conference Call Requirements for ToIP User Agents 15 6.2.2 Text transport...............................................12
6.4 Transport via RTP 15 6.2.3 Session Setup................................................13
6.5 Character Set 16 6.2.4 Addressing...................................................13
6.6 Transcoding 16 6.2.5 Alerting.....................................................14
6.7 Relay Services 16 6.2.6 Session information..........................................14
6.8 Emergency services 17 6.2.7 Session progress information.................................14
6.9 User Mobility 17 6.2.8 Session Negotiations.........................................15
6.10 Confidentiality and Security 17 6.2.9 Answering....................................................15
7. Interworking Requirements for ToIP 17 6.2.9.1 Answering Machine..........................................15
7.1 ToIP Interworking Gateway Services 17 6.2.10 Actions During a Session....................................15
7.2 ToIP and PSTN/ISDN Text-Telephony 18 6.2.10.1 Text Transport............................................16
7.3 ToIP and Cellular Wireless circuit switched Text-Telephony 6.2.10.2 Handling Text and other Media.............................16
18 6.2.11 Additional session control..................................17
7.3.1 "No-gain" 19 6.2.12 File storage................................................17
7.3.2 Cellular Text Telephone Modem (CTM) 19 6.3 Conference Session Requirements................................17
7.3.3 "Baudot mode" 19 6.4 Real-time Editing and User Alerting............................17
7.3.4 Data channel mode 19 6.5 Emergency services.............................................17
7.3.5 Common Text Gateway Functions 19 6.6 User Mobility..................................................18
7.4 ToIP and Cellular Wireless ToIP 20 6.7 Firewalls and NATs.............................................18
7.5 Instant Messaging Support 20 7. Interworking Requirements for ToIP..............................18
7.6 IP Telephony with Traditional RJ-11 Interfaces 21 7.1 ToIP Interworking Gateway Services.............................18
7.7 Multi-functional gateways 22 7.2 ToIP and PSTN/ISDN Text-Telephony Interworking.................18
7.8 ToIP interoperability with PSTN text telephones. 22 7.3 ToIP and Cellular Wireless ToIP................................19
7.9 Gateway Discovery 22 7.4 Instant Messaging Support......................................19
8. Afterword 23 7.5 Common Text Gateway Functions..................................20
9. Security Considerations 23 7.5.1 Protocol support.............................................20
10. Authors Addresses 24 7.5.2 Relay buffer storage.........................................20
11. References 25 7.5.3 Emergency calls through gateways.............................21
11.1 Normative 25 7.5.4 Text Gateway Invocation......................................21
11.2 Informative 27 7.6 Home Gateways or Analog Terminal Adapters......................21
7.7 Multi-functional Combination gateways..........................22
A. van Wijk, et al. Expires 21 February 2006 [Page 2 of 28]
7.8 Transcoding....................................................22
7.9 Relay Services.................................................23
7.9.1 Basic function of the relay service..........................23
7.9.2 Invocation of relay services.................................23
8. Security Considerations.........................................23
9. Authors Addresses...............................................24
10. References.....................................................25
10.1 Normative references..........................................25
10.2 Informative references........................................27
A. van Wijk [Page 2 of 28]
1. Introduction 1. Introduction
For many years, text has been in use as a medium for For many years, text has been in use as a medium for
conversational, interactive dialogue between users in a similar conversational, interactive dialogue between users in a similar
way as voice telephony is used. Such interactive text is different way to how voice telephony is used. Such interactive text is
from messaging and semi-interactive solutions like Instant different from messaging and semi-interactive solutions like
Messaging in that it offers an equivalent conversational Instant Messaging in that it offers an equivalent conversational
experience to users that cannot, or do not wish to, use voice. It experience to users who cannot, or do not wish to, use voice. It
therefore meets a different set of requirements than other text- therefore meets a different set of requirements from other text-
based solutions already available on IP networks. based solutions already available on IP networks.
Traditionally, deaf, hard of hearing and speech-impaired people Traditionally, deaf, hard of hearing and speech-impaired people
are amongst the most proliferate users of conversational, are amongst the most prolific users of conversational, interactive
interactive text, but because of its interactivity, it is becoming text but, because of its interactivity, it is becoming popular
popular amongst mainstream user groups as well. amongst mainstream users as well.
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 specifically designed to be compatible with Voice-over-IP (VoIP)
environments, as well as meeting the userĂs requirements, environments, as well as meeting the userĂs requirements,
including those of deaf, hard of hearing and speech-impaired users including those of deaf, hard of hearing and speech-impaired users
as described in RFC3351 [21]. as described in RFC3351 [19].
The Session Initiation Protocol (SIP) is the protocol of choice The Session Initiation Protocol (SIP) is the protocol of choice
for control of Multimedia IP telephony and Voice-over-IP (VoIP) for control of Multimedia communications and Voice-over-IP (VoIP)
communications. It offers all the necessary control and signaling in particular. It offers all the necessary control and signaling
required for the ToIP framework. required for the ToIP framework.
The Real-Time Transport Protocol (RTP) is the protocol of choice The Real-Time Transport Protocol (RTP) is the protocol of choice
for real-time data transmission, and its use for interactive text for real-time data transmission, and its use for interactive 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 or as part of integrated services, including Total itself or as part of integrated, multi-media services, including
Conversation. Total Conversation.
A. van Wijk, et al. Expires 21 February 2006 [Page 3 of 28]
2. Scope 2. Scope
The primary scope of this document is to define a framework for This document defines a framework for the implementation of real-
the implementation of ToIP, either stand-alone or as a part of time ToIP, either stand-alone or as a part of multimedia services,
wider services, including Total Conversation. In general, the including Total Conversation. It defines the:
scope is:
a. Description of ToIP using SIP and RTP;
b. Requirements of Real-time, interactive text;
c. Requirements for ToIP interworking.
The subsequent sections describe those requirements in detail. a. Requirements of Real-time, interactive text;
b. Requirements for ToIP interworking;
c. Description of ToIP using SIP and RTP;
d. Description of ToIP interworking with other text services.
3. Terminology 3. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [2] and indicate requirement levels described in BCP 14, RFC 2119 [2] and indicate requirement levels
for compliant implementations. for compliant implementations.
A. van Wijk [Page 3 of 28]
4. Definitions 4. Definitions
Audio bridging - a function of a gateway or relay service that Audio bridging - a function of a gateway or relay service that
enables an audio path through the service between the users enables an audio path through the service between the users
involved in the call. involved in the call.
Cellular - Telephone systems based on radio transmission to become
wireless. Also called Wireless or Mobile systems.
Full duplex - media is sent independently in both directions. Full duplex - media is sent independently in both directions.
Half duplex - media can only be sent in one direction at a time Half duplex - media can only be sent in one direction at a time
or, if an attempt to send information in both directions is made, or, if an attempt to send information in both directions is made,
errors can be introduced into the presented media. errors can be introduced into the presented media.
Interactive text - a term for real time transmission of text in a Interactive 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.
TTY ű alternative designation for a text telephone, often used in Textphone ű also "text telephone". A terminal device that allows
USA, see textphone. Also called TDD, Telecommunication Device for end-to-end real-time, interactive text communication using analog
the Deaf. transmission. A variety of PSTN textphone protocols exists world-
wide. A textphone can often be combined with a voice telephone, or
Textphone ű also ˘text telephone÷. A terminal device that allows include voice communication functions for simultaneous or
end-to-end real-time, interactive text communication. A variety of alternating use of text and voice in a call.
textphone protocols exists world-wide, both in the PSTN and other
networks. A textphone can often be combined with a voice
telephone, or include voice communication functions for
simultaneous or alternating use of text and voice in a call.
Text bridging - a function of a gateway service that enables the Text bridging - a function of a gateway service that enables the
flow of text through the service between the users involved in the flow of text through the service between the users involved in the
call. call.
Text gateway - a multi functional gateway that is able to Text gateway - a function that transcodes between different forms
transcode between different forms of text transport methods, e.g., of text transport methods, e.g., between ToIP in IP networks and
between ToIP in IP networks and Baudot text telephony in the PSTN. Baudot or ITU-T V.21 text telephony in the PSTN.
Text telephony ű analog textphone services
A. van Wijk, et al. Expires 21 February 2006 [Page 4 of 28]
Text Relay Service - a third-party or intermediary that enables 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
text in a call. text in a call.
Text telephony ű analog textphone service.
Total Conversation - a multimedia service offering real time
conversation in video, text and voice according to interoperable
standards. All media flow in real time. (See ITU-T F.703
"Multimedia conversational services".)
Transcoding Services - services of a third-party user agent that Transcoding Services - services of a third-party user agent that
transcodes one stream into another. Transcoding can be done by transcodes one stream into another. Transcoding can be done by
human operators, in automated manner or a combination of both human operators, in an automated manner or a combination of both
methods. Text Relay Services are examples of a transcoding service methods. Text Relay Services are examples of a transcoding service
between text and audio. between text and audio.
Total Conversation - A multimedia service offering real time TTY ű alternative designation for a text telephone or textphone,
conversation in video, text and voice according to interoperable often used in USA. Also called TDD, Telecommunication Device for
standards. All media flow in real time. Further defined in ITU-T the Deaf.
F.703 Multimedia conversational services description.
A. van Wijk [Page 4 of 28]
Video Relay Service - A service that enables communications Video Relay Service - A service that enables communications
between deaf and hard of hearing people, and hearing persons with between deaf and hard of hearing people, and hearing persons with
voice telephones by translating between sign language and spoken voice telephones by translating between sign language and spoken
language in a call. 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
CTM Cellular Text Telephone Modem CTM Cellular Text Telephone Modem
ENUM E.164 number storage in DNS (see RFC3761)
GSM Global System of Mobile Communication GSM Global System of Mobile Communication
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
PSTN Public Switched Telephone Network PSTN Public Switched Telephone Network
RTP Real Time Transport Protocol
SDP Session Description Protocol
SIP Session Initiation Protocol SIP Session Initiation 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)
ToIP Text over Internet Protocol ToIP Text over Internet Protocol
UTF-8 Universal Transfer Format-8 UTF-8 Universal Transfer Format-8
VCO/HCO Voice Carry Over/Hearing Carry Over
VoIP Voice over Internet Protocol
A. van Wijk, et al. Expires 21 February 2006 [Page 5 of 28]
5. Framework Description 5. Framework Description
5.1. Background This framework defines the requirements of a text-based
conversational service that is the text equivalent of voice based
telephony. Real-time text conversation can be combined with other
conversational services like video or voice.
ToIP also offers an IP equivalent of analog text telephony
services as used by deaf, hard of hearing and speech-impaired
individuals.
The main purpose of this document is to provide a framework
description for the implementation of real-time, interactive text
based conversational services over IP networks, known as Text-
over-IP (ToIP).
This framework uses existing standards that are already commonly
used for voice based conversational services on IP networks. In
particular, the ToIP framework uses the Session Initiation
Protocol (SIP) [3] to set up, control and tear down the
connections between users.
Media is transported using the Real-Time Transport Protocol (RTP)
in the manner described in RFC4103.
This framework allows for implementation of services that meet the
requirement of providing a text-based conversational service,
equivalent to voice based telephony. In particular, ToIP offers an
IP equivalent of text telephony services as used by deaf, hard of
hearing and speech-impaired individuals.
In addition, real-time text conversations can be combined with
other conversational services using different media like video or
voice.
By using SIP, ToIP allows participants to negotiate all media
including real-time text conversation[4, 5]. This is a highly
desirable function for all IP telephony users, but essential for
deaf, hard of hearing, or speech impaired people who have limited
or no use of the audio path of the call.
It is important to understand that real-time text conversations It is important to understand that real-time text conversations
are significantly different from other text-based communications are significantly different from other text-based communications
A. van Wijk [Page 5 of 28]
like email or instant messaging. Real-time text conversations like email or instant messaging. Real-time text conversations
deliver an equivalent mode to voice conversations by providing deliver an equivalent mode to voice conversations by providing
transmission of text character by character as it is entered, so transmission of text character by character as it is entered, so
that the conversation can be followed closely and immediate that the conversation can be followed closely and immediate
interaction takes place, thus providing the same mode of interaction takes place. This provides the same mode of
interaction as voice telephony does for hearing people. Store-and- interaction as voice telephony does for hearing people.
forward systems like email or messaging on mobile networks or non-
streaming systems like instant messaging are unable to provide
that functionality.
5.2. Requirements for ToIP Store-and-forward systems like email or messaging on mobile
networks or non-streaming systems like instant messaging are
unable to provide that functionality. In particular, they do not
allow for smooth communication through a Text Relay Service.
In order to make ToIP the equivalent of what voice is to hearing This framework uses existing standards that are already commonly
people, it needs to offer equivalent features in terms of used for voice based conversational services on IP networks. It
conversationality as voice telephony provides to hearing people. uses the Session Initiation Protocol (SIP) to set up, control and
To achieve that, ToIP MUST: tear down the connections between users whilst the media is
transported using the Real-Time Transport Protocol (RTP) as
described in RFC4103 [5].
This framework is designed to meet the requirements of RFC3351
[19]. As such, it offers a standardized way for offering text-
based, conversational services that can be used as an equivalent
to voice telephony by deaf, hard of hearing and speech-impaired
individuals.
SIP allows participants to negotiate all media including real-time
text conversation [4,5]. This is a highly desirable function for
all IP telephony users but essential for deaf, hard of hearing, or
speech impaired people who have limited or no use of the audio
path of the call.
5.1. General requirements for ToIP
In order to make ToIP the text equivalent of voice services, it
needs to offer equivalent features in terms of conversationality
as voice telephony provides. To achieve that, ToIP needs to:
a. Offer real-time presentation of the conversation; a. Offer real-time presentation of the conversation;
b. Provide simultaneous transmission in both directions; b. Provide simultaneous transmission in both directions;
c. Provide interoperability with text conversation features in c. Support both point-to-point and multipoint communication;
other networks, for instance the PSTN, accepting functional
limitations that will occur during interoperation.
d. Not prevent other media, like audio and video, to be used in
conjunction with ToIP.
Users might want to use multiple modes of communication during the A. van Wijk, et al. Expires 21 February 2006 [Page 6 of 28]
conversation, either at the same time or by switching between d. Allow other media, like audio and video, to be used in
modes, e.g., between text and audio for example. Native ToIP conjunction with ToIP;
services MUST ensure that the text interface is always available. e. Ensure that the text service is always available.
Real-time text is a useful subset of Total Conversation defined in
ITU-T F.703 [23]. Users could use multiple modes of communication
during the conversation, either at the same time or by switching
between modes, e.g., between text and audio.
Users may invoke ToIP services for many different reasons:
- Because they are in a noisy environment, e.g., in a machine room
of a factory where listening is difficult.
- Because they are busy with another call and want to participate
in two calls at the same time.
- For implementing text and/or speech recording services (e.g.,
text documentation/ audio recording for
legal/clarity/flexibility purposes).
- To overcome language barriers through speech translation and/or
transcoding services.
- Because of hearing loss, deafness or tinnitus as a result of the
aging process or for any other reason, thus creating a need to
replace or complement voice with text in conversational
sessions.
NOTE: In many of the above examples, text may accompany speech.
The text could be displayed side by side, in a manner similar to
subtitling in broadcasting environments, or in any other suitable
manner. This could occur for users who are hard of hearing and
also for mixed media calls with both hearing and deaf people
participating in the call.
User Agents providing ToIP functionality need to provide suitable
alerting indications, specifically offering visual and/or tactile
alerting for deaf and hard of hearing users.
The ability of SIP to set up conversation sessions from any
location, as well as its privacy and security provisions, MUST be
maintained by ToIP services.
Where ToIP is used in conjunction with other media, exposure of
SIP functions through the User Interface needs to be done in an
equivalent manner for all supported media. In other words, where
certain SIP call control functions are available for the audio
media part of the session, these functions MUST also be supported
for the text media part of the same session. For example, call
transfer must act on all media in the session.
T.140 real-time text conversation [4], in addition to audio and
video communications, is a valuable service for many users,
including those on non-IP networks. T.140 also provides for real-
time editing of the text.
A. van Wijk, et al. Expires 21 February 2006 [Page 7 of 28]
5.1.1 General ToIP Summary
The general requirements for ToIP are:
a. Session setup, modification and teardown procedures for point-
to-point and multimedia calls
b. Registration procedures and address resolutions
c. Registration of user preferences
d. Negotiation procedures for device capabilities
e. Support of text media transport using T.140 over RTP as
described in RFC 4103 [5]
f. Signaling of status information, call progress and the like in
a suitable manner, bearing in mind that the user may have a
hearing impairment
g. T.140 real-time text presentation mixing with voice and video
h. T.140 real-time text conversation sessions using SIP, allowing
users to move from one place to another
i. User privacy and security for sessions setup, modification, and
teardown as well as for media transfer
j. Routing of emergency calls according to national or regional
policy with the same level of functionality as a voice call.
5.2. General Requirements for ToIP Interworking
This section describes the general ToIP interworking requirements
and gives some background information to many of the issues.
There is a range of existing text services. There is also a range
of network technologies that could support text services (see
examples below). ToIP needs to provide interoperability with text
conversation features in other networks, for instance the PSTN,
and with some text messaging services.
Text gateways are used for converting between different media
types. They could be used between networks or within networks
where different transport technologies are used.
When communicating via a gateway to other networks and protocols, When communicating via a gateway to other networks and protocols,
the service SHOULD support all the functionality for alternating the ToIP service SHOULD support the functionality for alternating
or simultaneous use of modalities as offered by the destination or simultaneous use of modalities as offered by the destination
network. network.
A. van Wijk, et al. Expires 21 February 2006 [Page 8 of 28]
Address information, both called and calling, SHOULD be
transferred, and possibly converted, when interworking between
different networks.
ToIP will often be used to access a relay service [I], allowing ToIP will often be used to access a relay service [I], allowing
text users to communicate with voice users. With relay services, text users to communicate with voice users. With relay services,
it is crucial that text characters are sent as soon as possible it is crucial that text characters are sent as soon as possible
after they are entered. While buffering MAY be done to improve after they are entered. While buffering may be done to improve
efficiency, the delays SHOULD be kept as small as possible. In efficiency, the delays SHOULD be kept minimal. In particular,
particular, buffering of whole lines of text MUST NOT be used. buffering of whole lines of text will not meet character delay
requirements.
5.3. Use of SIP and RTP
ToIP services MUST use the Session Initiation Protocol (SIP) [3]
for setting up, controlling and terminating sessions for real-time
text conversation with one or more participants and possibly
including other media like video or audio.
Thus, participants are allowed to negotiate on a set of compatible
media types with session descriptions used in SIP invitations. A
ToIP service MUST always support at least one Text media type.
A. van Wijk [Page 6 of 28]
ToIP services MUST use the Real-Time Transport Protocol (RTP)
according to the specification of RFC4103 for the transport of
text between participants, which implements T.140 on IP networks.
The standardized T.140 real-time text conversation [4], in
addition to audio and video communications, will be a valuable
service to many, including on non-IP networks. Real-time text can
be expressed as a part of the session description in SIP and is a
useful subset of Total Conversation.
The ToIP specification describes a framework for using the T.140
text conversation in SIP as a part of the multimedia session
establishment in real-time over a SIP network.
If the User Agents of different participants indicate that there If the User Agents of different participants indicate that there
is an incompatibility between their capabilities to support is an incompatibility between their capabilities to support
certain media types, e.g. one terminal only offering T.140 over IP certain media types, e.g. one terminal only offering T.140 over IP
as described in RFC4103 and the other one only supporting audio, as described in RFC4103 [5] and the other one only supporting
the user might want to invoke a transcoding services. audio, the user might want to invoke a transcoding service.
Examples of possible scenarios for including a relay service in Examples of possible scenarios for including a relay service in
the conversation are: speech-to-text (STT), text-to-speech (TTS), the conversation are: speech-to-text (STT), text-to-speech (TTS),
text bridging after conversion from speech, audio bridging after text bridging after conversion from speech, audio bridging after
conversion from text, etc. conversion from text, etc.
The session description protocol (SDP) [6] used in SIP to describe The general requirements for ToIP Interworking are:
the session is used to express these attributes of the session
(e.g., uniqueness in media mapping for conversion from one media
to another for each communicating party).
Real-time text can also be presented in conjunction with other a. Interoperability between T.140 conversations [4] and analog
media like video and audio, as for example in Total Conversation text telephones
services.
User Agents providing ToIP functionality SHOULD provide suitable b. Discovery and invocation of transcoding/translation services
alerting, specifically offering visual and/or tactile alerting so between the media in the call
that deaf and hard of hearing users can use them.
The SIP abilities to set up text conversation sessions from any c. Different session establishment models for transcoding /
location, as well as privacy and security provisions SHOULD be translation services invocation: Third party call control and
implemented in ToIP services. conference bridge model
Where ToIP is used in conjunction with other media, exposure of d. Uniqueness in media mapping to be used in the session for
SIP functions through the User Interface MUST be available in conversion from one media to another by the transcoding /
equivalent fashion for all supported media. In other words, where translation server for each communicating party
certain SIP call control functions are available for the audio
media part of the session, these functions MUST also be supported
for the text media part of the same session.
Any ToIP implementation MUST also allow invocation and use of e. Media bridging services for T.140 real-time text, as described
relevant transcoding services where these are available. This can in RFC4103 [5], audio and video for multipoint communications
be achieved through application of SIP techniques for different
A. van Wijk [Page 7 of 28] f. Transparent session setup, modification, and teardown between
session establishment models [7]: Third party call control [8] and text conversation capable devices and voice/video capable
Conference Bridge model [9]. devices
Both point-to-point and multipoint communication need to be g. Buffering of text when interworking with media that transport
defined for the session establishment using T.140 text text at different rates.
conversation. In addition, ToIP services SHOULD support
interworking with text telephony [10].
The general framework for ToIP can be described as follows: 5.2.1 PSTN Interworking
a. Session setup, modification and teardown procedures for point- Analog text telephony is cumbersome because of incompatible
to-point and multimedia calls national implementations where interworking was never considered.
b. Registration procedures and address resolutions A. van Wijk, et al. Expires 21 February 2006 [Page 9 of 28]
A large number of these implementations have been documented in
ITU-T V.18 [10], which also defines the modem detection sequences
for the different text protocols. The modem type identification
may in rare cases take considerable time depending on user
actions.
c. Registration of user preferences To resolve analog textphone incompatibilities, text telephone
gateways are needed to transcode incoming analog signals into
T.140 and vice versa. The modem capability exchange time can be
reduced by the text telephone gateways initially assuming the
analog text telephone protocol used in the region where the
gateway is located. For example, in the USA, Baudot [III] might be
tried as the initial protocol. If negotiation for Baudot fails,
the full V.18 modem capability exchange will take place. In the
UK, ITU-T V.21 [II] might be the first choice.
d. Negotiation procedures for device capabilities 5.2.2 Cellular circuit switched Text-Telephony
e. Discovery and invocation of transcoding/translation services Cellular wireless (or Mobile) circuit switched connections provide
between the media in the call a digital real-time transport service for voice or data. The
access technologies include GSM, CDMA, TDMA, iDen and various 3G
technologies.
f. Different session establishment models for transcoding / Alternative means of transferring the Text telephony data have
translation services invocation: Third party call control and been developed when TTY services over cellular was mandated by the
conference bridge model FCC in the USA. They are a) "No-gain" codec solution, b) the
Cellular Text Telephony Modem (CTM) solution and c) "Baudot mode"
solution.
g. Uniqueness in media mapping to be used in the session for The GSM and 3G standards from 3GPP make use of the CTM modem in
conversion from one media to another by the transcoding / the voice channel for text telephony. However, implementations
translation server for each communicating party also exist that use the data channel to provide such
functionality. Interworking with these solutions SHOULD be done
using text gateways that set up the data channel connection at the
GSM side and provide ToIP at the other side.
h. Media bridging services for T.140 real-time text as described 5.2.2.1 Cellular "No-gain"
in RFC4103, audio, and video for multipoint communications
i. Transparent session setup, modification, and teardown between The "No-gain" text telephone transporting technology uses
text conversation capable and voice/video capable devices specially modified EFR [13] and EVR [14] speech vocoders in mobile
terminals used to provide a text telephony call. It provides full
duplex operation and supports alternating voice and text
("VCO/HCO"). It is dedicated to CDMA and TDMA mobile technologies
and the US Baudot (i.e. 45 bit/s) type of text telephones.
j. Support of text media transport using T.140 over RTP as laid 5.2.2.2 Cellular Text Telephone Modem (CTM)
out in RFC 4103 [4]
k. Signaling of status information, call progress and the like in CTM [15] is a technology independent modem technology that
a suitable manner, bearing in mind the user may have a hearing provides the transport of text telephone characters at up to 10
impairment characters/sec using modem signals that can be carried by many
voice codecs and uses a highly redundant encoding technique to
overcome the fading and cell changing losses.
l. T.140 real-time text presentation mixing with voice and video A. van Wijk, et al. Expires 21 February 2006 [Page 10 of 28]
5.2.2.3 Cellular "Baudot mode"
m. T.140 real-time text conversation sessions using SIP, allowing This term is often used by cellular terminal suppliers for a GSM
users to move from one place to another cellular phone mode that allows TTYs to operate into a cellular
phone and to communicate with a fixed line TTY.
n. User privacy and security for sessions setup, modification, and 5.2.3 Cellular data channel mode
teardown as well as for media transfer
o. Interoperability between T.140 conversations and analogue text Many mobile terminals allow the use of the data channel to
telephones transfer data in real-time. Data rates of 9600 bit/s are usually
supported on the mobile network. Gateways provide interoperability
with PSTN textphones.
A. van Wijk [Page 8 of 28] 5.2.4 Cellular Wireless ToIP
p. Routing of emergency calls according to national or regional
policy to the same level of a voice call.
5.4. Requirements for ToIP Interworking ToIP could be supported over cellular wireless packet switched
services that interface to the Internet. For 3GPP 3G services, the
support is described to use ToIP in 3G TS 26.235 [18]. Low data
rates and additional delays can affect performance.
Analog text telephony is cumbersome because of incompatible 5.2.5 Instant Messaging Support
national implementations where interworking was never considered.
A large number of these implementations have been documented in
ITU-T V.18, which also defines modem detection sequences for the
different text terminals. The full modem capability exchange
between two wildly different terminals can take more than one
minute to complete if both terminals have a common text
modulation.
To resolve international analog textphone incompatibilities, text Many people use Instant Messaging to communicate via the Internet
telephone gateways MUST transcode incoming analog signals into using text. Instant Messaging transfers blocks of text rather than
T.140 and vice versa. The modem capability exchange time is then streaming as is used by ToIP. As such, it is not a replacement for
also reduced, since V.18 allows the sequence of protocol discovery ToIP and in particular does not meet the needs for real time
to be customized. Hence, the text telephone gateways will assume conversations including those of deaf, hard of hearing and speech-
the analog text telephone protocol used in the region the gateway impaired users as defined in RFC 3351 [19]. It is unsuitable for
is located. For example, in the USA, Baudot might be tried as the communications through a relay service [I]. The streaming nature
initial protocol. If negotiation for Baudot fails, the full modem of ToIP provides a more direct conversational user experience and,
capability exchange will then take place. In contrast, in the UK, when given the choice, users may prefer ToIP.
ITU-T V.21 might be the first choice.
6. Detailed requirements for Text-over-IP Text gateways could be developed to allow interworking between
Instant Messaging systems and ToIP solutions.
ToIP services MUST use SIP for call control and signaling. 6. Detailed requirements for ToIP
A ToIP user may wish to call another ToIP user, or join a A ToIP user may wish to call another ToIP user, or join a
conference call involving several users. He or she may, also, wish conference session involving several users or initiate or join a
to initiate or join a multimedia call, such as a Total multimedia session, such as a Total Conversation session.
Conversation call.
There may be some need for pre-call setup e.g. storing There may be some need for pre-session setup e.g. storing of
registration information in the SIP registrar to provide registration information in the SIP registrar, to provide
information about how a user can be contacted. This will allow information about how a user can be contacted. This will allow
calls to be set up rapidly and with proper routing and addressing. sessions to be set up rapidly and with proper routing and
addressing.
Similarly, there are requirements that need to be satisfied during Similarly, there are requirements that need to be satisfied during
call set up when other media are preferred by a user. For session set up when other media are preferred by a user. For
instance, some users may prefer to use audio while others want to instance, some users may indicate their preferred modality to be
use text as their preferred modality. In this case, transcoding audio while others may indicate text. In this case, transcoding
services might be needed for text-to-speech (TTS) and speech-to- services might be needed for text-to-speech (TTS) and speech-to-
A. van Wijk, et al. Expires 21 February 2006 [Page 11 of 28]
text (STT). The requirements for transcoding services need to be text (STT). The requirements for transcoding services need to be
negotiated in real-time to set up the session. negotiated in real-time to set up the session.
The subsequent subsections describe some of these requirements in The subsequent subsections describe some of these requirements in
detail. detail.
A. van Wijk [Page 9 of 28] 6.1. Pre-Session Requirements
6.1. Pre-Call Requirements
The need to use ToIP as a medium of communications can be The need to use text as a medium of communications can be
expressed by users during registration time. Two situations need expressed by users during registration time. Two situations need
to be considered in the pre-call setup environment: to be 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 ToIP by registering that preference with a SIP preference for text by registering that preference with a SIP
server that is part of the ToIP service. server that is part of the ToIP service.
b. Server to support User Preferences: SIP servers that are part b. Server to support User Preferences: SIP servers that support
of ToIP services MUST have the capability to act on users ToIP services MUST have the capability to act on calling user
preferences for ToIP to accept or reject the call, based on the preferences for text in order to accept or reject the session-,
user preferences defined during the pre-call setup registration based on the called userĂs preferences defined as part of the
time. For example, if the user is called by another party, and it pre-session setup registration. For example, if the user is
is determined that a transcoding server is needed, the call MUST called by another party, and it is determined that a
be re-directed or otherwise handled accordingly. transcoding server is needed, the session MUST be re-directed
or otherwise handled accordingly.
6.2 Basic Point-to-Point Call Requirements 6.2 Basic Point-to-Point Session Requirements
The point-to-point call will take place between two parties. The A point-to-point session takes place between two parties. The
requirements are described in subsequent sub-sections. They assume requirements are described in subsequent sub-sections. They assume
that one or both of the communicating parties will indicate ToIP that one or both of the communicating parties will indicate text
as a possible or preferred medium for conversation using SIP in as a possible or preferred medium for conversation using SIP in
the session setup. the session setup.
6.2.1 Session Setup 6.2.1 Session control
ToIP services MUST use the Session Initiation Protocol (SIP) [3]
for setting up, controlling and terminating sessions for real-time
text conversation with one or more participants and possibly
including other media like video or audio. The session description
protocol (SDP) [6] used in SIP to describe the session is used to
express the attributes of the session and to negotiate a set of
compatible media types.
6.2.2 Text transport
A ToIP service MUST always support at least one Text media type.
ToIP services MUST support the Real-Time Transport Protocol (RTP)
[24] according to the specification of RFC4103 [5] for the
transport of text between participants.
RFC4103 describes the transmission of T.140 [4] on IP networks.
A. van Wijk, et al. Expires 21 February 2006 [Page 12 of 28]
6.2.3 Session Setup
Users will set up a session by identifying the remote party or the Users will set up a session by identifying the remote party or the
service they will want to connect to. However, conversations could service they want to connect to. However, conversations could be
be started using a mode other than ToIP. For instance, the started using a mode other than text. For instance, the
conversation might be established using audio and the user could conversation might be established using audio and the user could
subsequently elect to switch to text, or add text as an additional subsequently elect to switch to text, or add text as an additional
modality, during the conversation. Systems supporting ToIP MUST modality, during the conversation. Systems supporting ToIP MUST
allow users to select any of the supported conversation modes at allow users to select any of the supported conversation modes at
any time, including mid-conversation. any time, including mid-conversation.
Systems SHOULD allow the user to specify a preferred mode of Systems SHOULD allow the user to specify a preferred mode of
communication, with the ability to fall back to alternatives that communication, with the ability to fall back to alternatives that
the user has indicated are acceptable. the user has indicated are acceptable.
If the user requests simultaneous use of text and audio, and this If the user requests simultaneous use of text and audio, and this
is not possible either because the system only supports alternate is not possible either because the system only supports alternate
modalities or because of resource management on the network, the modalities or because of constraints in the network, the system
system MUST try to establish a text-only communication. The user MUST try to establish communication with best effort. If the user
MUST be informed of this change throughout the process, either in has expressed a preference for text, establishment of a connection
text or in a combination of modalities that MUST include text. including text MUST have priority over other outcomes of the
session setup.
Session setup, especially through gateways to other networks, MAY
require the use of specially formatted addresses or other
mechanisms for invoking gateways.
A. van Wijk [Page 10 of 28] The following features MAY be implemented to facilitate the
The following features MAY need to be implemented to facilitate session establishment using ToIP:
the session establishment using ToIP:
a. Caller Preferences: SIP headers (e.g., Contact) can be used to a. Caller Preferences: SIP headers (e.g., Contact)[24] can be used
show that ToIP is the medium of choice for communications. to show that ToIP is the medium of choice for communications.
b. Called Party Preferences: The called party being passive can b. Called Party Preferences: The called party being passive can
formulate a clear rule indicating how a call should be handled formulate a clear rule indicating how a session should be
either using ToIP as a preferred medium or not, and whether a handled either using text as a preferred medium or not, and
designated SIP proxy needs to handle this call or it is handled in whether a designated SIP proxy needs to handle this session or
the SIP user agent (UA). it will be handled in the SIP user agent.
c. SIP Server support for User Preferences: SIP servers can also c. SIP Server support for User Preferences: SIP servers can also
handle the incoming calls in accordance to preferences expressed handle the incoming sessions in accordance with preferences
for ToIP. The SIP Server can also enforce ToIP policy rules for expressed for ToIP. The SIP Server can also enforce ToIP policy
communications (e.g. use of the transcoding server for ToIP). rules for communications (e.g. use of the transcoding server
for ToIP).
6.2.2 Addressing 6.2.4 Addressing
The SIP [3] addressing schemes MUST be used for all entities. For The SIP [3] addressing schemes MUST be used for all entities in a
example SIP URL and Tel URL will be used for caller, called party, ToIP session. For example, SIP URLĂs or Tel URLĂs are used for
user devices, and servers (e.g., SIP server, Transcoding server). caller, called party, user devices, and servers (e.g., SIP server,
Transcoding server).
The right to include a transcoding service MUST NOT require user The right to include a transcoding service MUST NOT require user
registration in any specific SIP registrar, but MAY require registration in any specific SIP registrar, but MAY require
authorisation of the SIP registrar in the service. authorisation of the SIP registrar to invoke the service.
6.2.3 Alerting and session progress presentation A. van Wijk, et al. Expires 21 February 2006 [Page 13 of 28]
6.2.5 Alerting
User Agents supporting ToIP MUST have an alerting method (e.g., User Agents supporting ToIP MUST have an alerting method (e.g.,
for incoming calls) that can be used by deaf and hard of hearing for incoming sessions) that can be used by deaf and hard of
people or provide a range of alternative, but equivalent, alerting hearing people or provide a range of alternative, but equivalent,
methods that are suitable for all users, regardless of their alerting methods that can be selected by all users, regardless of
abilities and preferences. their abilities.
It should be noted that general alerting systems exist, and one It should be noted that external alerting systems exist and one
common interface for triggering the alerting action is a contact common interface for triggering the alerting action is a contact
closure between two conductors. closure between two conductors.
Among the alerting options are alerting by the User AgentĂs User Among the alerting options are alerting by the User AgentĂs 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.
6.2.6 Session information
If present, identification of the originating party (for example If present, identification of the originating party (for example
in the form of a URL or CLI) MUST be clearly presented to the user in the form of a URL or a CLI) MUST be clearly presented to the
in a form suitable for the user BEFORE answering the request. When user in a form suitable for the user BEFORE the session invitation
the invitation to initiate a conversation involving ToIP is answered. When a session invitation involving ToIP originates
originates from a gateway, this MAY be signaled to the user. from a gateway, this MAY be signaled to the user.
During a conversation that includes ToIP, status and session The user MUST be informed of any change in modalities.
progress information MUST be provided in text. That information
MUST be equivalent to session progress information delivered in
any other format, for example audio. Users MUST be able to manage
A. van Wijk [Page 11 of 28] 6.2.7 Session progress information
the session and perform all session control functions based on the
textual session progress information.
The user MUST be informed of any change in modalities. During a conversation that includes ToIP, status and session
progress information MUST be provided in a textual form so users
can perform all session control functions. That information MUST
be equivalent to session progress information delivered in any
other format, for example audio.
Session progress information SHOULD use simple language as much as Session progress information SHOULD use simple language so that as
possible so that as many users as possible can understand it. The many users as possible can understand it. The use of jargon or
use of jargon or ambiguous terminology SHOULD be avoided at all ambiguous terminology SHOULD be avoided. It is RECOMMENDED that
times. It is RECOMMENDED to let text information be used together text information be used together with icons to symbolise the
with icons symbolising the items to be reported. session progress information.
There MUST be a clear indication, both visually as well as audibly There MUST be a clear indication, in a modality useful to the
whenever a session gets connected or disconnected. The user SHOULD user, whenever a session is connected or disconnected. A user
never be in doubt as to what the status of the connection is, even SHOULD never be in doubt about the status of the session, even if
if he/she is not able to use audio feedback or vision. 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 visual or tactile In summary, it SHOULD be possible to observe indicators about:
indicators about: - Incoming session
- Call progress
- Availability of text, voice and video channels - Availability of text, voice and video channels
- Incoming call - Session progress
- Incoming text - Incoming text
- Typed and transmitted text - Any loss in incoming text
- Any loss in incoming text.
6.2.4 Call Negotiations A. van Wijk, et al. Expires 21 February 2006 [Page 14 of 28]
- Typed and transmitted text.
For users who cannot use the audible alerter for incoming
sessions, it is RECOMMENDED to include a tactile as well as a
visual indicator.
6.2.8 Session Negotiations
The Session Description Protocol (SDP) used in SIP [3] provides The Session Description Protocol (SDP) used in SIP [3] provides
the capabilities to indicate ToIP as a media in the call setup. the capabilities to indicate text as a medium in the session
RFC 4103 [5] provides the RTP payload type text/t140 for support setup. RFC 4103 [5] uses the RTP payload type "text/t140" for
of ToIP which can be indicated in the SDP as a part of SDP INVITE, support of ToIP which can be indicated in the SDP as a part of the
OK and SIP/200/ACK for media negotiations. In addition, SIPĂs SIP INVITE, OK and SIP/200/ACK media negotiations. In addition,
offer/answer model can also be used in conjunction with other SIPĂs offer/answer model [20] can also be used in conjunction with
capabilities including the use of a transcoding server for other capabilities including the use of a transcoding server for
enhanced call negotiations [7,8,9]. enhanced session negotiations [7,8,9].
6.2.5 Answering 6.2.9 Answering
Systems SHOULD provide a best-effort approach to answering Systems SHOULD provide a best-effort approach to answering
invitations for session set-up and users should be kept informed invitations for session set-up and users SHOULD be informed when
at all times about the progress of session establishment. On all the session is accepted by the other party. On all systems that
systems that both inform users of session status and support ToIP, both inform users of session status and support ToIP, this
this information MUST be available in text, and MAY be provided in information MUST be available in textual form and MAY also be
other visual media. provided in other media.
6.2.5.1 Answering Machine 6.2.9.1 Answering Machine
Systems for ToIP MAY support an auto-answer function, equivalent Systems for ToIP MAY support an auto-answer function, equivalent
to answering machines on telephony networks. If an answering to answering machines on telephony networks. If an answering
machine function is supported, it MUST support at least 160 machine function is supported, it MUST support at least 160
characters for the greeting message. It MUST support incoming text characters for the greeting message. It MUST support incoming text
message storage of a minimum of 4096 characters, although systems message storage of a minimum of 4096 characters, although systems
A. van Wijk [Page 12 of 28]
MAY support much larger storage. It is RECOMMENDED that systems MAY support much larger storage. It is RECOMMENDED that systems
support storage of at least 20 incoming messages of up to 16000 support storage of at least 20 incoming messages of up to 16000
characters. characters per message.
When the answering machine is activated, user alerting SHOULD When the answering machine is activated, user alerting SHOULD
still take place. The user SHOULD be allowed to monitor the auto- still take place. The user SHOULD be allowed to monitor the auto-
answer progress and where this is provided the user MUST be answer progress and where this is provided the user SHOULD be
allowed to intervene during any stage of the answering machine and allowed to intervene during any stage of the answering machine
take control of the session. procedure and take control of the session.
6.2.6 Actions During Calls 6.2.10 Actions During a Session
Certain actions need to be performed for the ToIP conversation Certain actions need to be performed during ToIP conversation:
during the call and these actions are described briefly as
follows:
a. Text transmission SHALL be done character by character as a. Text transmission from a terminal SHALL be performed character
entered, or in small groups transmitted so that no character is by character as entered, or in small groups of characters, so
delayed between entry and transmission by more than 300 that no character is delayed from entry to transmission by more
milliseconds. than 300 milliseconds.
A. van Wijk, et al. Expires 21 February 2006 [Page 15 of 28]
b. The text transmission SHALL allow a rate of at least 30 b. The text transmission SHALL allow a rate of at least 30
characters per second so that human typing speed as well as speech characters per second so that human typing speed as well as
to text methods of generating conversation text can be supported. speech to text methods of generating conversation text can be
supported.
c. After text connection is established, the mean end-to-end delay c. To enable the use of international character sets, the
of characters SHALL be less than two seconds, measured between two transmission format for text conversation SHALL be UTF-8 [12],
ToIP users. This requirement is valid as long as the text input in accordance with ITU-T T.140.
rate is lower or equal to the text reception and display rate.
d. The character corruption rate SHALL be less than 1% in d. If text is detected to be missing after transmission, there
conditions where users experience the quality of voice SHOULD be a "text loss" indication in the text as specified in
transmission to be low but useable. This is in accordance with T.140 Addendum 1 [4].
ITU-T F.700 Annex A.3 quality level T1.
e. When interoperability functions are invoked, there may be a e. When the display of text conversation is included in the design
need for intermediate storage of characters before transmission to of the end user equipment, the display of the dialogue SHOULD
a device receiving slower than the typing speed of the sender. be made so that it is easy to differentiate the text belonging
Such temporary storage SHALL be dimensioned to adjust for to each party in the conversation.
receiving at 30 characters per second and transmitting at 6
characters per second during at least 4 minutes [less than 3k
characters].
f. To enable the use of international character sets the 6.2.10.1 Text Transport
transmission format for text conversation SHALL be UTF-8, in
accordance with ITU-T T.140.
g. If text is detected to be missing after transmission, there ToIP uses RTP as the default transport protocol for the
SHALL be an indication in the text marking the loss. For 7 bit transmission of real-time text via the medium "text/t140" as
terminals this loss MAY be marked as an apostrophe: Ă. specified in RFC 4103 [5].
g. When used from a terminal designed for PSTN text telephony, or The redundancy method of RFC 4103 [5] SHOULD be used to
in interworking with such a terminal, ToIP shall enable significantly increase the reliability of the text transmission. A
redundancy level using 2 generations gives very reliable results
and is therefore RECOMMENDED.
A. van Wijk [Page 13 of 28] Text capability MUST be announced in SDP by a declaration similar
alternating between text and voice in a similar manner as the PSTN to this example:
text telephone handles this mode of operation. (This mode is often
called VCO/HCO in the USA and the UK).
i. When display of the conversation on end user equipment is m=text 11000 RTP/AVP 98 100
included in the design, display of the dialogue SHALL be made so a=rtpmap:98 t140/1000
that it is easy to read text belonging to each party in the a=rtpmap:100 red/1000
conversation. a=fmtp:100 98/98/98
6.2.6.1 Text and other Media Handling Between ToIP User Agents By having this single coding and transmission scheme for real time
text defined in the SIP session control environment, the
opportunity for interoperability is optimized. However, if good
reasons exist, other transport mechanisms MAY be offered and used
for the T.140 coded text provided that proper negotiation is
introduced, but RFC 4103 [5] transport MUST be used as both the
default and the fallback transport.
The following requirements are valid for media handling during 6.2.10.2 Handling Text and other Media.
calls:
A call is one or more related sessions. The following requirements
apply to media handling during a call:
a. When used between User Agents designed for ToIP, it SHALL be a. When used between User Agents designed for ToIP, it SHALL be
possible to send and receive text simultaneously. possible to send and receive text simultaneously.
A. van Wijk, et al. Expires 21 February 2006 [Page 16 of 28]
b. When used between User Agents that support ToIP, it SHALL be b. When used between User Agents that support ToIP, it SHALL be
possible to send and receive text simultaneously with the other possible to send and receive text simultaneously with the other
media (text, audio and/or video) supported by the same terminals. media (text, audio and/or video) supported by the same
terminals.
c. It SHOULD be possible to know during the call that ToIP is
available, even if it is not invoked at call setup (only voice
and/or video is used for example). To disable this, the user must
disable the use of ToIP. This is possible during registration at
the REGISTRAR.
6.2.6.2 Call Action with Native ToIP User Agents
a. It SHOULD be possible to answer a call with text capabilities
enabled.
b. It MAY be possible to use video simultaneously with the other
media in the call.
c. It MUST be possible to answer a call in voice or video without
text enabled, and add text later in the call.
d. It MUST be possible to disconnect the call.
e. It SHOULD be possible to invoke multi-party calls.
f. It MUST be possible to transfer the call. c. It SHOULD be possible to know during a call that ToIP is
available, even if it is not invoked at call setup (e.g. when
only voice and/or video is used initially). To disable this,
the user MUST disable the use of ToIP. This is possible during
registration at the SIP registrar.
6.2.7 Additional session control 6.2.11 Additional session control
Systems that support additional session control features, for Systems that support additional session control features, for
example call waiting, forwarding, hold etc on voice calls, MUST example call waiting, forwarding, hold etc on voice sessions, MUST
offer equivalent functionality for text calls. offer this functionality for text sessions.
A. van Wijk [Page 14 of 28] 6.2.12 File storage
6.2.8 File storage
Systems that support ToIP MAY save the text conversation to a Systems that support ToIP MAY save the text conversation to a
file. This SHOULD be done using a standard file format. For file. This SHOULD be done using a standard file format. For
example: UTF8 text file in XML format including record timestamp, example: a UTF8 text file in XML format [11] including timestamps,
party and the text conversation. party names (or addresses) and the text conversation.
6.3 Conference Call Requirements for ToIP User Agents 6.3 Conference Session Requirements
The conference call requirements deal with multipoint conferencing The conference session requirements deal with multipoint
calls where there will be at least one or more ToIP capable conferencing sessions where there will be one or more ToIP capable
devices along with other end user devices where the total number devices and/or other end user devices where the total number of
end user devices will be at least three. end user devices will be at least three.
It SHOULD be possible to use the text medium in conference calls, It SHOULD be possible to use the text medium in conference
in a similar way as the audio is handled and the video is sessions in a similar way to how audio is handled and video is
displayed. Text in conferences can be used both for letting displayed. Text in conferences can be used both for letting
individual participants use the text medium (for example, for individual participants use the text medium (for example, for
sidebar discussions in text while listening to the main conference sidebar discussions in text while listening to the main conference
audio), as well as for central support of the conference with real audio), as well as for central support of the conference with real
time text interpretation of speech. time text interpretation of speech.
6.4 Transport via RTP 6.4 Real-time Editing and User Alerting
ToIP uses RTP as the default transport protocol for transmission
of real-time text via medium text/t140 as specified in RFC 4103
[5].
The redundancy method of RFC 4103 [5] SHOULD be used for making
text transmission reliable.
Text capability MUST be announced in SDP by a declaration in line
with this example:
m=text 11000 RTP/AVP 98 100
a=rtpmap:98 t140/1000
a=rtpmap:100 red/1000
a=fmtp:100 98/98/98
Characters SHOULD be buffered for transmission and transmitted
every 300 ms.
By having this single coding and transmission scheme for real time
text defined, in the SIP call control environment, the opportunity
for interoperability is optimized.
However, if good reasons exist, other transport mechanisms MAY be
offered and used for the T.140 coded text, provided that proper
negotiation is introduced, and RFC 4103 [5] transport MUST be used
as both the default as well as the fallback transport.
A. van Wijk [Page 15 of 28]
6.5 Character Set
a. ToIP services MUST use UTF-8 encoding as specified in ITU-T
T.140 [12].
b. ToIP SHOULD handle characters with editing effect such as new
line, erasure and alerting during session as specified in ITU-T
T.140.
6.6 Transcoding
Transcoding of text may need to take place in gateways between
ToIP and other forms of text conversation. For example to connect
to a PSTN text telephone.
6.7 Relay Services
The relay service acts as an intermediary between two or more
callers using different media or different media encoding schemes.
The basic text relay service allows a translation of speech to
text and text to speech, which enables hearing and speech impaired
callers to communicate with hearing callers. Even though this
document focuses on ToIP, we want to remind readers that there
exist other relay services like, for example, speech to sign
language and vice versa using video.
It is RECOMMENDED that ToIP implementations make the invocation
and use of relay services as easy as possible. It MAY happen
automatically when the call is being set up based on any valid
indication or negotiation of supported or preferred media types. A
transcoding framework document using SIP [7] describes invoking
relay services, where the relay acts as a conference bridge or
uses the third party control mechanism. ToIP implementations
SHOULD support this transcoding framework.
Adding or removing a relay service MUST be possible without
disrupting the current call.
When setting up a call, the relay service MUST be able to
determine the type of service requested (e.g., speech to text or
text to speech), to indicate if the caller wants voice carry over,
the language of the text, the sign language being used (in the
video stream), etc.
It SHOULD be possible to route the call to a preferred relay ToIP SHOULD handle characters such as new line, erasure and
service even if the user makes the call from another region or alerting during a session as specified in ITU-T T.140.
network than usually used.
A. van Wijk [Page 16 of 28] 6.5 Emergency services
6.8 Emergency services
Access to emergency services using ToIP SHOULD provide an It MUST be possible to place an emergency call using ToIP and it
equivalent service to the one offered by other supported media, MUST be possible to use a relay service in such call. The
like audio. emergency service provided to users utilising the text medium MUST
be equivalent to the emergency service provided to users utilising
speech or other media.
6.9 User Mobility A. van Wijk, et al. Expires 21 February 2006 [Page 17 of 28]
6.6 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 to use a SIP- Agents to resolve mobility issues. It is RECOMMENDED that users
address for the users, resolved by a SIP REGISTRAR, to enable use a SIP-address, resolved by a SIP registrar, to enable basic
basic user mobility. Further mechanisms are defined for the 3G IP user mobility. Further mechanisms are defined for all session
multimedia systems. types for 3G IP multimedia systems.
6.10 Confidentiality and Security
User confidentiality and privacy need to be met as described in
SIP [3]. For example, nothing should reveal the fact that the user
of ToIP is a person with a disability unless the user prefers to
make this information public. If a transcoding server is being
used, this SHOULD be transparent. Encryption SHOULD be used on
end-to-end or hop-by-hop basis as described in SIP [3] and SRTP
[19]
Authentication needs to be provided for users in addition to the 6.7 Firewalls and NATs
message integrity and access control.
Protection against Denial-of-service (DoS) attacks needs to be ToIP uses the same signaling and transport protocols as VoIP
provided considering the case that the ToIP users might need hence, the same firewall and NAT solutions and network
transcoding servers. functionality that apply to VoIP MUST also apply to ToIP.
7. Interworking Requirements for ToIP 7. Interworking Requirements for ToIP
A number of systems for real time text conversation already exist A number of systems for real time text conversation already exist
as well as a number of message oriented text communication as well as a number of message oriented text communication
systems. Interoperability is of interest between ToIP and some of systems. Interoperability is of interest between ToIP and some of
these systems. This section describes requirements on this these systems. This section describes the interoperability
interoperability, especially for the PSTN text telephony to ensure requirements, especially for PSTN text telephony, to ensure full
full backward interoperability with ToIP. backward interoperability with ToIP.
7.1 ToIP Interworking Gateway Services 7.1 ToIP Interworking Gateway Services
Interactive texting facilities exist already in various forms and Interactive texting facilities exist already in various forms and
on various networks. On the PSTN, it is commonly referred to as on various networks. On the PSTN, it is commonly referred to as
text telephony. text telephony.
Simultaneous or alternating use of voice and text is used by a Simultaneous or alternating use of voice and text is used by a
large number of users who can send voice, but must receive text or large number of users who can send voice but must receive text
who can hear but must send text due to a speech disability. (due to a hearing impairment), or who can hear but must send text
(due to a speech impairment).
A. van Wijk [Page 17 of 28] Session setup through gateways to other networks MAY require the
7.2 ToIP and PSTN/ISDN Text-Telephony use of specially formatted addresses or other mechanisms for
invoking those gateways.
Different data rates of different protocols MAY require text
buffering.
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.
7.2 ToIP and PSTN/ISDN Text-Telephony Interworking
On PSTN networks, transmission of interactive text takes place On PSTN networks, transmission of interactive text takes place
using a variety of codings and modulations, including ITU-T V.21 using a variety of codings and modulations, including ITU-T V.21
[II], Baudot, DTMF, V.23 [III] and others. Many difficulties have [II], Baudot [III], DTMF, V.23 [IV] and others. Many difficulties
arisen as a result of this variety in text telephony protocols and have arisen as a result of this variety in text telephony
the ITU-T V.18 [10] standard was developed to address some of protocols and the ITU-T V.18 [10] standard was developed to
these issues. address some of these issues.
ITU-T-V.18 [10] offers a native text telephony method plus it A. van Wijk, et al. Expires 21 February 2006 [Page 18 of 28]
ITU-T V.18 [10] offers a native text telephony method plus it
defines interworking with current protocols. In the interworking defines interworking with current protocols. In the interworking
mode, it will recognise one of the older protocols and fall back mode, it will recognise one of the older protocols and fall back
to that transmission method when required. to that transmission method when required.
In order to allow systems and services based on ToIP to V.18 MUST be supported on the PSTN side of a PSTN-ToIP gateway.
communicate with PSTN text telephones, text gateways are the
recommended approach. These gateways MUST use the ITU-T V.18 [10]
standard at the PSTN side.
Buffering MUST be used to support different transmission rates. At
least 1K buffer MUST be provided. A buffer of at least 2K
characters is RECOMMENDED. In addition, the gateway MUST provide a
minimum throughput of at least 30 characters/second or the highest
speed supported by the PSTN text telephony protocol side,
whichever is the lowest.
PSTN-ToIP gateways MUST allow alternating use of text and voice.
PSTN and ISDN to ToIP gateways that receive CLI information from
the originating party MUST pass this information to the receiving
party as soon as possible.
Priority MUST be given to calls labeled as emergency calls.
7.3 ToIP and Cellular Wireless circuit switched Text-Telephony
Cellular wireless (or Mobile) circuit switched connections provide
a digital real-time transport service for voice or data.
The access technologies include GSM, CDMA, TDMA, iDen and various
3G technologies.
Alternative means of transferring the Text telephony data have
been developed when TTY services over cellular was mandated by the
FCC in the USA. They are a) "No-gain" codec solution, b) the
Cellular Text Telephony Modem (CTM) solution and c) "Baudot mode"
solution.
The GSM and 3G standards from 3GPP make use of the CTM modem in
the voice channel for text telephony.
However, implementations also exist that use the data channel to
provide such functionality. Interworking with these solutions
SHOULD be done using text gateways that set up the data channel
connection at the GSM side and provide ToIP at the other side.
A. van Wijk [Page 18 of 28]
7.3.1 "No-gain"
The "No-gain" text telephone transporting technology uses
specially modified EFR [15] and EVR [16] speech vocoders in both
mobile terminals used to provide a text telephony call. It
provides full duplex operation and supports alternating voice and
text.( "VCO/HCO"). It is dedicated to the CDMA and TDMA mobile
technologies and the US Baudot type of text telephones.
7.3.2 Cellular Text Telephone Modem (CTM)
CTM [17] is a technology independent modem technology that
provides the transport of text telephone characters at up to 10
characters/sec using modem signals that are at or below 1 kHz and
uses a highly redundant encoding technique to overcome the fading
and cell changing losses. On any interface that uses analog
transmission, half-duplex operation must be supported as the
"send" and "receive" modem frequencies are identical. The use of
CTM may have to be modified slightly to support half-duplex
operation.
7.3.3 "Baudot mode"
This term is often used by cellular terminal suppliers for a GSM
cellular phone mode that allows TTYs to operate into a cellular
phone and to communicate with a fixed line TTY.
7.3.4 Data channel mode
Many mobile terminals allow the use of the data channel to
transfer data in real-time. Data rates of 9600 bit/s are usually
supported on the mobile network. Gateways or the interworking
function provides interoperability with PSTN textphones.
7.3.5 Common Text Gateway Functions
Text gateways MUST cover the differences that result from
different text protocols. The protocols to be supported will
depend on the service requirements of the Gateway.
Different data rates of different protocols MAY require text
buffering.
Interoperation of half-duplex and full-duplex protocols MAY
require text buffering and some intelligence to determine when to
change direction when operating in half-duplex.
Identification may be required of half-duplex operation either at
the "user" level (ie. users must inform each other) or at the
"protocol" level (where an indication must be sent back to the
Gateway).
A. van Wijk [Page 19 of 28] PSTN-ToIP gateways MUST allow alternating use of text and voice if
A text gateway MUST be able to route text calls to emergency the PSTN textphone involved at the PSTN side of the session
service providers when any of the recognised emergency numbers supports this. (This mode is often called VCO/HCO).
that support text communications for the country or region are
called eg. "911" in USA and "112" in Europe. Routing text calls to
emergency services MAY require the use of a transcoding service.
A text gateway MUST act as a SIP User Agent on the IP side. Calling party identification information, such as CLI, MUST be
passed by gateways and converted to an approapriate form if
required.
7.4 ToIP and Cellular Wireless ToIP 7.3 ToIP and Cellular Wireless ToIP
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. For 3GPP 3G services, the service. It interfaces to the Internet.
support is described to use ToIP in 3G TS 26.235 [20].
A text gateway with cellular wireless packet switched services A text gateway with cellular wireless packet switched services
MUST be able to route text calls into emergency service providers MUST be able to route text calls to emergency service providers
when any of the recognized emergency numbers that support text when any of the recognized emergency numbers that support text
communication for the country are called. communication for the country.
7.5 Instant Messaging Support
Many people use Instant Messaging to communicate via the Internet
using text. Instant Messaging transfers blocks of text rather than
streaming as is used by ToIP. As such, it is not a replacement for
ToIP and in particular does not meet the needs for real time
conversations of deaf, hard of hearing and speech-impaired users
as defined in RFC 3351 [21]. It is unsuitable for communications
through a relay service [I]. The streaming character of ToIP
provides a better user experience and, when given the choice,
users often prefer ToIP.
However, since some users might only have Instant Messaging 7.4 Instant Messaging Support
available, text gateways MAY be developed to allow interworking
between Instant Messaging systems and ToIP solutions.
Because Instant Messaging is based on blocks of text, rather than Text gateways MAY be developed to allow interworking between
on a continuous stream of characters, such gateways need to Instant Messaging systems and ToIP solutions. Because Instant
transform between these two formats. Text gateways for Messaging is based on blocks of text, rather than on a continuous
interworking between Instant Messaging and ToIP MUST concatenate stream of characters, gateways MUST transcode between the two
individual characters originating at the ToIP side into blocks of formats. Text gateways for interworking between Instant Messaging
text and: and ToIP MUST concatenate individual characters originating at the
ToIP side into blocks of text and:
a. When the length of the concatenated message becomes longer than a. When the length of the concatenated message becomes longer than
50 characters, the buffered text SHOULD be transmitted to the 50 characters, the buffered text SHOULD be transmitted to the
Instant Messaging side as soon as any non-alphanumerical character Instant Messaging side as soon as any non-alphanumerical
is received from the ToIP side. character is received from the ToIP side.
b. When a new line is received from the ToIP side, the buffered b. When a new line indicator is received from the ToIP side, the
characters up to that point, including the carriage return and/or buffered characters up to that point, including the carriage
line feed characters, SHOULD be transmitted to the Instant return and/or line feed characters, SHOULD be transmitted to
Messaging side. the Instant Messaging side.
A. van Wijk [Page 20 of 28]
c. When the ToIP side has been idle for at least 5 seconds, all c. When the ToIP side has been idle for at least 5 seconds, all
buffered text up to that point SHOULD be transmitted to the buffered text up to that point SHOULD be transmitted to the
Instant Messaging side. Instant Messaging side.
It is RECOMMENDED that during the session, both users are It is RECOMMENDED that during the session, both users are
constantly updated on the progress of the text input. constantly updated on the progress of the text input.
A. van Wijk, et al. Expires 21 February 2006 [Page 19 of 28]
Many Instant Messaging protocols signal that a user is typing to Many Instant Messaging protocols signal that a user is typing to
the other party in the conversation. Text gateways between such the other party in the conversation. Text gateways between such
Instant Messaging protocols and ToIP MUST provide this signaling Instant Messaging protocols and ToIP MUST provide this signaling
to the Instant Messaging side when characters start being to the Instant Messaging side when characters start being
received, or at the beginning of the conversation. received, or at the beginning of the conversation.
At the ToIP side, an indicator of writing the Instant Message MUST At the ToIP side, an indicator of writing the Instant Message MUST
be present where the Instant Messaging protocol provides one. For be present where the Instant Messaging protocol provides one. For
example, the real-time text user MAY see . . . waiting for example, the real-time text user MAY see ". . . waiting for
replying IM. . . And per 5 seconds that pass a . (dot) can be replying IM. . . " and when 5 seconds have passed another . (dot)
shown. can be shown.
Those solutions will reduce the difficulties between a streaming Those solutions will reduce the difficulties between streaming and
versus blocked text. blocked text services.
Even though the text gateway can connect Instant Messaging and Even though the text gateway can connect Instant Messaging and
ToIP, the best solution is to take advantage of the fact that the ToIP, the best solution is to take advantage of the fact that the
user interfaces and the user communities for instant messaging and user interfaces and the user communities for instant messaging and
ToIP telephony are extremely similar. After all, the character ToIP telephony are very similar. After all, the character input,
input, the character display, Internet connectivity and SIP stack the character display, Internet connectivity and SIP stack are the
are the same for Instant Messaging (SIMPLE) and ToIP. same for Instant Messaging (SIMPLE) and ToIP.
Devices that implement Instant Messaging SHOULD implement ToIP as Devices that implement Instant Messaging SHOULD implement ToIP as
described in this document. described in this document so that a more complete text
communication service can be provided.
7.6 IP Telephony with Traditional RJ-11 Interfaces 7.5 Common Text Gateway Functions
Text gateways MUST allow for the differences that result from
different text protocols. The protocols to be supported will
depend on the service requirements of the Gateway.
7.5.1 Protocol support
Text gateways MUST use the ITU-T V.18 [10] standard at the PSTN
side. A text gateway MUST act as a SIP User Agent on the IP side
and support RFC4103 text transport.
7.5.2 Relay buffer storage
When text gateway functions are invoked, there will be a need for
intermediate storage of characters before transmission to a device
receiving text slower than the transmitting speed of the sender.
Such temporary storage SHALL be dimensioned to adjust for
receiving at 30 characters per second and transmitting at 6
characters per second for up to 4 minutes (i.e. less than 3k
characters).
Interoperation of half-duplex and full-duplex protocols MAY
require text buffering. Some intelligence will be needed to
determine when to change direction when operating in half-duplex
mode. Identification may be required of half-duplex operation
either at the "user" level (ie. users must inform each other) or
A. van Wijk, et al. Expires 21 February 2006 [Page 20 of 28]
at the "protocol" level (where an indication must be sent back to
the Gateway).
7.5.3 Emergency calls through gateways
A text gateway MUST be able to route text calls to emergency
service providers when any of the recognised emergency numbers
that support text communications for the country or region are
called e.g. "911" in USA and "112" in Europe. Routing text calls
to emergency services MAY require the use of a transcoding
service.
7.5.4 Text Gateway Invocation
ToIP interworking requires a method to invoke a text gateway. As
described previously in this draft, these text gateways MUST act
as User Agents at the IP side. The capabilities of the text
gateway during the call will be determined by the call
capabilities of the terminal that is using the gateway. For
example, a PSTN textphone is generally only able to receive voice
and streaming text, so the text gateway will only allow ToIP and
audio.
Examples of possible scenarios for invocation of the text gateway
are:
a. PSTN textphone users dial a prefix number before dialing out.
b. Separate text subscriptions, linked to the phone number or
terminal identifier/ IP address.
c. Text capability indicators.
d. Text preference indicator.
e. Listen for V.18 modem modulation text activity in all PSTN
calls and routing of the call to an appropriate gateway.
f. Call transfer request by the called user.
g. Placing a call via the web, and using one of the methods
described here
h. Text gateways with its own telephone number and/or SIP address.
(This requires user interaction with the text gateway to place
a call).
i. ENUM address analysis and number plan
j. Number or address analysis leads to a gateway for all PSTN
calls.
7.6 Home Gateways or Analog Terminal Adapters
Analog terminal adapters (ATAs) using SIP based IP communication
and RJ-11 connectors for connecting traditional PSTN devices
SHOULD enable connection of legacy PSTN text telephones [16].
Analogue adapters using SIP based IP communication and RJ-11
connectors for connecting traditional PSTN devices (ATA box)
SHOULD enable connection of legacy PSTN text telephones [18].
These adapters SHOULD contain V.18 modem functionality, voice These adapters SHOULD contain V.18 modem functionality, voice
handling functionality, and conversion functions to/from SIP based handling functionality, and conversion functions to/from SIP based
ToIP with T.140 transported according to RFC 4103 [5], in a ToIP with T.140 transported according to RFC 4103 [5], in a
similar way as it provides interoperability for voice calls. If a similar way as it provides interoperability for voice sessions.
call is set up and text/t140 capability is not declared by the
endpoint (by the end-point terminal or the text gateway in the A. van Wijk, et al. Expires 21 February 2006 [Page 21 of 28]
network at the end-point), a method for invoking a transcoding If a session is set up and text/t140 capability is not declared by
server shall be used. If no such server is available, the signals the destination endpoint (by the end-point terminal or the text
from the textphone MAY be transmitted in the voice channel as gateway in the network at the end-point), a method for invoking a
audio with high quality of service. transcoding server SHALL be used. If no such server is available,
NOTE: It is preferred that such analogue adaptors do use RFC 4103 the signals from the textphone MAY be transmitted in the voice
[5] on board and thus act as a text gateway. Sending textphone channel as audio with high quality of service.
signals over the voice channel is undesirable due to possible
filtering and compression and packet loss between the end-points. NOTE: It is preferred that such analog terminal adaptors do use
This can result in dropping characters in the textphone RFC 4103 [5] on board and thus act as a text gateway. Sending
conversation or even not allowing the textphones to connect with textphone signals over the voice channel is undesirable due to
possible filtering and compression and packet loss between the
end-points. This can result in character loss in the textphone
conversation or even not allowing the textphones to connect to
each other. each other.
A. van Wijk [Page 21 of 28] 7.7 Multi-functional Combination gateways
7.7 Multi-functional gateways
In practice many interworking gateways will be implemented as In practice many interworking gateways will be implemented as
gateways that combine different functions. As such, a text gateway gateways that combine different functions. As such, a text gateway
could be build to have modems to interwork with the PSTN and could be built to have modems to interwork with the PSTN and
support both Instant Messaging as well as ToIP. Such interworking support both Instant Messaging as well as ToIP. Such interworking
functions are called Combination gateways. functions are called Combination gateways.
Combination gateways MUST provide interworking between all of Combination gateways MUST provide interworking between all of
their supported text based functions. For example, a text gateway their supported text based functions. For example, a text gateway
that has modems to interwork with the PSTN and that support both that has modems to interwork with the PSTN and that support both
Instant Messaging and real-time ToIP MUST support the following Instant Messaging and real-time ToIP MUST support the following
interworking functions: interworking functions:
- PSTN text telephony to real-time ToIP. - PSTN text telephony to real-time ToIP.
- PSTN text telephony to Instant Messaging. - PSTN text telephony to Instant Messaging.
- Instant Messaging to real-time ToIP. - Instant Messaging to real-time ToIP.
7.8 ToIP interoperability with PSTN text telephones. 7.8 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. Most PSTN textphones use a 7-bit character set, or a set. Most PSTN textphones use a 7-bit character set, or a
character set that is converted to a 7-bit character set by the character set that is converted to a 7-bit character set by the
V.18 modem. V.18 modem.
When transcoding between character sets and T.140 in gateways, When transcoding between character sets and T.140 in gateways,
special consideration MUST be given to the national variants of special consideration MUST be given to the national variants of
the 7 bit codes, with national characters mapping into different the 7 bit codes, with national characters mapping into different
codes in the ISO 10 646 code space. The national variant to be codes in the ISO 10646 code space. The national variant to be used
used could be selectable by the user on a per call basis, or be could be selectable by the user on a per call basis, or be
configured as a national default for the gateway. configured as a national default for the gateway.
The missing text indicator in T.140, specified in T.140 amendment The indicator of missing text in T.140, specified in T.140
1, cannot be represented in the 7 bit character codes. Therefore amendment 1, cannot be represented in the 7 bit character codes.
these characters SHOULD be transcoded to the ' (apostrophe) Therefore the indicator of missing text SHOULD be transcoded to
character in legacy text telephone systems, where this character the ' (apostrophe) character in legacy text telephone systems,
exists. For legacy systems where the character ' does not exist,
the . ( full stop ) character SHOULD be used instead.
7.9 Gateway Discovery A. van Wijk, et al. Expires 21 February 2006 [Page 22 of 28]
where this character exists. For legacy systems where the
character ' does not exist, the . ( full stop ) character SHOULD
be used instead.
ToIP requires a method to invoke a text gateway. As described 7.9 Relay Services
previously in this draft, these text gateways MUST act as User
Agents at the IP side. The capabilities of the text gateway during
the call will be determined by the call capabilities of the
terminal that is using the gateway. For example, a PSTN textphone
is only able to receive voice and streaming text, so the text
gateway will only allow ToIP and audio.
Examples of possible scenarios for discovery of the text gateway The relay service acts as an intermediary between two or more
are: callers using different media or different media encoding schemes.
A. van Wijk [Page 22 of 28] 7.9.1 Basic function of the relay service
- PSTN textphone users dial a prefix number before dialing out.
- Separate text subscriptions, linked to the phone number or
terminal identifier/ IP address.
- Text capability indicators.
- Text preference indicator.
- Listen for V.18 modem modulation text activity in all calls.
- Call transfer request by the called user.
- Placing a call via the web, and using one of the methods
described here
- Text gateways with its own telephone number and/or SIP address.
(This requires user interaction with the text gateway to place a
call).
- ENUM address analysis and number plan
- Number or address analysis leads to the gateway for all PSTN
calls.
8. Afterword The basic text relay service allows a translation of speech to
text and text to speech, which enables hearing and speech impaired
callers to communicate with hearing callers. Even though this
document focuses on ToIP, we want to remind readers that other
relay services exist, like video relay services transcoding speech
to sign language and vice versa where the signing is communicated
using video.
The authors want to make it clear that ToIP is a way of allowing 7.9.2 Invocation of relay services
real-time, interactive text conversation between all users and is
thus not only for the hearing and speech impaired users.
The users may invoke the ToIP services for many different reasons. It is RECOMMENDED that ToIP implementations make the invocation
For example: and use of relay services as easy as possible. It MAY happen
automatically when the session is being set up based on any valid
indication or negotiation of supported or preferred media types. A
transcoding framework document using SIP [7] 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.
- Noisy environment (e.g., in a machine room of a factory where Adding or removing a relay service MUST be possible without
listening is difficult) disrupting the current session.
- Busy with another call and want to participate in two calls at
the same time.
- Text and/or speech recording services (e.g., text
documentation/audio recording for legal/clarity/flexibility
purposes)
- Overcoming of language barriers through speech translation
and/or transcoding services.
- Hearing loss, tinnitus or deafness due to the aging process or
any other reason.
NOTE: In many of the above examples, text may accompany speech and When setting up a session, the relay service MUST be able to
could be displayed in a manner similar to subtitling in determine the type of service requested (e.g., speech to text or
broadcasting environments or any other suitable manner. This text to speech), to indicate if the caller wants voice carry over,
could occur for individuals who are hard of hearing and also for the language of the text, the sign language being used (in the
mixed calls with a hearing and deaf person listening to the call. video stream), etc.
9. Security Considerations It SHOULD be possible to route the session to a preferred relay
service even if the user invokes the session from another region
or network than that usually used.
There are no additional security requirements other than described A number of requirements, motivations and implementation
earlier. guidelines for relay service invocation can be found in RFC 3351
[19].
A. van Wijk [Page 23 of 28] 8. Security Considerations
10. Authors Addresses
User confidentiality and privacy need to be met as described in
SIP [3]. For example, nothing should reveal the fact that the user
of ToIP is a person with a disability unless the user prefers to
make this information public. If a transcoding server is being
A. van Wijk, et al. Expires 21 February 2006 [Page 23 of 28]
used, this SHOULD be transparent. Encryption SHOULD be used on
end-to-end or hop-by-hop basis as described in SIP [3] and SRTP
[17].
Authentication needs to be provided for users in addition to the
message integrity and access control.
Protection against Denial-of-service (DoS) attacks needs to be
provided considering the case that the ToIP users might need
transcoding servers.
9. Authors Addresses
The following people provided substantial technical and writing The following people provided substantial technical and writing
contributions to this document, listed alphabetically: contributions to this document, listed alphabetically:
Willem P. Dijkstra Willem P. Dijkstra
TNO Informatie- en Communicatietechnologie TNO Informatie- en Communicatietechnologie
Postbus 15000 Postbus 15000
9700 CD Groningen 9700 CD Groningen
The Netherlands The Netherlands
Tel: +31 50 585 77 24 Tel: +31 50 585 77 24
Fax: +31 50 585 77 57 Fax: +31 50 585 77 57
Email: willem.dijkstra@tno.nl Email: willem.dijkstra@tno.nl
Barry Dingle Barry Dingle
ACIF, 32 Walker Street ACIF, 32 Walker Street
North Sydney, NSW 2060 Australia North Sydney, NSW 2060 Australia
Tel +61 (0)2 9959 9111 Tel +61 (0)2 9959 9111
Fax +61 (0)2 9954 6136
TTY +61 (0)2 9923 1911
Mob +61 (0)41 911 7578 Mob +61 (0)41 911 7578
Email barry.dingle@bigfoot.com.au Email barry.dingle@bigfoot.com.au
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(0)20 7294 3713
Txt +44(0)20 7296 8019 Txt +44(0)20 7296 8019
Fax +44(0)20 7296 8069 Fax +44(0)20 7296 8069
skipping to change at line 1262 skipping to change at line 1286
Gunnar Hellstrom Gunnar Hellstrom
Omnitor AB Omnitor AB
Renathvagen 2 Renathvagen 2
SE 121 37 Johanneshov SE 121 37 Johanneshov
Sweden Sweden
Phone: +46 708 204 288 / +46 8 556 002 03 Phone: +46 708 204 288 / +46 8 556 002 03
Fax: +46 8 556 002 06 Fax: +46 8 556 002 06
Email: gunnar.hellstrom@omnitor.se Email: gunnar.hellstrom@omnitor.se
A. van Wijk, et al. Expires 21 February 2006 [Page 24 of 28]
Henry Sinnreich Henry Sinnreich
pulver.com pulver.com
115 Broadhollow Rd 115 Broadhollow Rd
Suite 225 Suite 225
Melville, NY 11747 Melville, NY 11747
USA USA
Tel: +1.631.961.8950 Tel: +1.631.961.8950
A. van Wijk [Page 24 of 28]
Gregg C Vanderheiden Gregg C Vanderheiden
University of Wisconsin-Madison University of Wisconsin-Madison
Trace R & D Center Trace R & D Center
1550 Engineering Dr (Rm 2107) 1550 Engineering Dr (Rm 2107)
Madison, Wi 53706 Madison, Wi 53706
USA USA
gv@trace.wisc.edu
Phone +1 608 262-6966 Phone +1 608 262-6966
FAX +1 608 262-8848 FAX +1 608 262-8848
Email: gv@trace.wisc.edu
Arnoud A. T. van Wijk Arnoud A. T. van Wijk
Viataal (Dutch Institute for the Deaf) Viataal
Research & Development Centre for R & D on sensory and communication disabilities.
Afdeling RDS
Theerestraat 42 Theerestraat 42
5271 GD Sint-Michielsgestel 5271 GD Sint-Michielsgestel
The Netherlands. The Netherlands.
Email: a.vwijk@viataal.nl Email: a.vwijk@viataal.nl
11. References 10. References
11.1 Normative 10.1 Normative references
1. Bradner, S., "The Internet Standards Process -- Revision 3", 1. S. Bradner, "Intellectual Property Rights in IETF Technology
BCP 9, RFC 2026, October 1996. ", BCP 79, RFC 3979, IETF, March 2005.
2. Bradner, S., "Key words for use in RFCs to Indicate Requirement 2. S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997 Levels", BCP 14, RFC 2119, IETF, March 1997
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. ITU-T Recommendation T.140, "Protocol for Multimedia 4. ITU-T Recommendation T.140, "Protocol for Multimedia
Application Text Conversation (February 1998) and Addendum 1 Application Text Conversation" (February 1998) and Addendum 1
(February 2000). (February 2000).
5. G. Hellstrom, "RTP Payload for Text Conversation, RFC 4103, 5. G. Hellstrom, "RTP Payload for Text Conversation", RFC 4103,
June 2005. IETF, June 2005.
6. G. Camarillo, H. Schulzrinne, and E. Burger, "The Source and 6. G. Camarillo, H. Schulzrinne, and E. Burger, "The Source and
Sink Attributes for the Session Description Protocol," IETF, Sink Attributes for the Session Description Protocol," IETF,
August 2003 - Work in Progress. August 2003 - Work in Progress.
A. van Wijk, et al. Expires 21 February 2006 [Page 25 of 28]
7. G.Camarillo, "Framework for Transcoding with the Session 7. G.Camarillo, "Framework for Transcoding with the Session
Initiation Protocol" IETF June 2005 - Work in progress. Initiation Protocol" IETF June 2005 - Work in progress.
8. G. Camarillo, H. Schulzrinne, E. Burger, and A. van Wijk, 8. 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,
June 2005. IETF, June 2005.
A. van Wijk [Page 25 of 28]
9. G. Camarillo, "The SIP Conference Bridge Transcoding Model," 9. G. Camarillo, "The SIP Conference Bridge Transcoding Model,"
IETF, August 2003 - Work in Progress. IETF, August 2003 - Work in Progress.
10. ITU-T Recommendation V.18,"Operational and Interworking 10. ITU-T Recommendation V.18,"Operational and Interworking
Requirements for DCEs operating in Text Telephone Mode," November Requirements for DCEs operating in Text Telephone Mode," November
2000. 2000.
11. "XHTML 1.0: The Extensible HyperText Markup Language: A 11. "XHTML 1.0: The Extensible HyperText Markup Language: A
Reformulation of HTML 4 in XML 1.0", W3C Recommendation. Available Reformulation of HTML 4 in XML 1.0", W3C Recommendation. Available
at http://www.w3.org/TR/xhtml1. at http://www.w3.org/TR/xhtml1.
12. Yergeau, F., "UTF-8, a transformation format of ISO 10646", 12. Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998. RFC 2279, IETF, January 1998.
13. TIA/EIA/825 "A Frequency Shift Keyed Modem for Use on the
Public Switched Telephone Network." (The specification for 45.45
and 50 bit/s TTY modems.)
14. Bell-103 300 bit/s modem.
15. TIA/EIA/IS-823-A "TTY/TDD Extension to TIA/EIA-136-410 13. TIA/EIA/IS-823-A "TTY/TDD Extension to TIA/EIA-136-410
Enhanced Full Rate Speech Codec (must used in conjunction with Enhanced Full Rate Speech Codec (must used in conjunction with
TIA/EIA/IS-840)" TIA/EIA/IS-840)"
16. TIA/EIA/IS-127-2 "Enhanced Variable Rate Codec, Speech Service 14. 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. Addendum
2." 2."
17. 3GPP TS26.226 "Cellular Text Telephone Modem Description" 15. 3GPP TS26.226 "Cellular Text Telephone Modem Description"
(CTM). (CTM).
18. I. Butcher, S. Lass, D. Petrie, H. Sinnreich, and C. 16. H. Sinnreich, S. Lass, and C. Stredicke, "SIP Telephony
Stredicke, "SIP Telephony Device Requirements, Configuration and Device Requirements and Configuration," IETF, June 2005 - Work in
Data," IETF, February 2004 - Work in Progress. Progress.
19. Baugher, McGrew, Carrara, Naslund, Norrman, "The Secure Real 17. Baugher, McGrew, Carrara, Naslund, Norrman, "The Secure Real
Time Transport Protocol (SRTP)", RFC 3711, IETF, March 2004. Time Transport Protocol (SRTP)", RFC 3711, IETF, March 2004.
20. IP Multimedia default codecs. 3GPP TS 26.235 18. "IP Multimedia default codecs". 3GPP TS 26.235
21. Charlton, Gasson, Gybels, Spanner, van Wijk, "User 19. Charlton, Gasson, Gybels, Spanner, van Wijk, "User
Requirements for the Session Initiation Protocol (SIP) in Support Requirements for the Session Initiation Protocol (SIP) in Support
of Deaf, Hard of Hearing and Speech-impaired Individuals", RFC of Deaf, Hard of Hearing and Speech-impaired Individuals", RFC
3351, IETF, August 2002. 3351, IETF, August 2002.
22. J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the 20. 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.
A. van Wijk [Page 26 of 28] 21. ITU-T Recommendation F.700,"Framework Recommendation for
11.2 Informative Multimedia Services", November 2000.
A. van Wijk, et al. Expires 21 February 2006 [Page 26 of 28]
22. H. Schulzrinne, S.Casner, R. Frederick, V. Jacobsone, "RTP: A
Transport Protocol for Real-Time Applications", RFC 3550, IETF,
July 2003.
23. ITU-T Recommendation F.703,"Multimedia Conversational
Services", November 2000.
24. J. Rosenberg, H. Schulzrinne, P. Kyzivat, "Indicating User
Agent Capabilities in the Session Initiation Protocol (SIP)", RFC
3840, IETF, August 2004
10.2 Informative references
I. A relay service allows the users to transcode between different 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. International Telecommunication Union (ITU), "300 bits per II. International Telecommunication Union (ITU), "300 bits per
second duplex modem standardized for use in the general switched second 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.
III. International Telecommunication Union (ITU), "600/1200-baud III. TIA/EIA/825 "A Frequency Shift Keyed Modem for Use on the
Public Switched Telephone Network." (The specification for 45.45
and 50 bit/s TTY modems.)
IV. International Telecommunication Union (ITU), "600/1200-baud
modem standardized for use in the general switched telephone modem standardized for use in the general switched telephone
network. ITU-T Recommendation V.23, November 1988. network. ITU-T Recommendation V.23, November 1988.
IV. Third Generation Partnership Project (3GPP), "Technical
Specification Group Services and System Aspects; Cellular Text
Telephone Modem; General Description (Release 5)". 3GPP TS 26.226
V5.0.0.
Intellectual Property Statement Intellectual Property Statement
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 Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology to pertain to the implementation or use of the technology
described in this document or the extent to which any license described in this document or the extent to which any license
under such rights might or might not be available; nor does it under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights such rights. Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79. in RFC documents can be found in BCP 78 and BCP 79.
skipping to change at line 1417 skipping to change at line 1447
of such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org. IETF at ietf-ipr@ietf.org.
A. van Wijk, et al. Expires 21 February 2006 [Page 27 of 28]
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
A. van Wijk [Page 27 of 28]
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is Copyright (C) The Internet Society (2005). This document is
subject to the rights, licenses and restrictions contained in BCP subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their 78, and except as set forth therein, the authors retain all their
rights. rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
A. van Wijk [Page 28 of 28] A. van Wijk, et al. Expires 21 February 2006 [Page 28 of 28]
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/