draft-ietf-sipping-toip-00.txt   draft-ietf-sipping-toip-01.txt 
Internet Engineering Task Force SIPPING WG Internet Engineering Task Force SIPPING WG
Internet Draft Internet Draft
Document: <draft-ietf-sipping-toip-00.txt> A. van Wijk (editor) Document: <draft-ietf-sipping-toip-01.txt> A. van Wijk (editor)
October 17 2004 Viataal July 18 2005 Viataal
Expires: April 15 2005 Expires: January 17 2006
Informational Informational
Framework of requirements for real-time text conversation using SIP. Framework of requirements for real-time text conversation using SIP.
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, each author represents that any
all provisions of Section 10 of RFC 2026 [1]. applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering 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.
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been
disclosed, or will be disclosed, and any of which I become aware
will be disclosed, in accordance with RFC 3668.
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.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract Abstract
This document provides the framework of requirements for text This document provides the framework of requirements for real-time
conversation with real time character-by-character interactive character-by-character interactive text conversation over the IP
flow over the IP network using the Session Initiation Protocol. network using the Session Initiation Protocol and the Transport
The requirements for general real-time text-over-IP telephony, Protocol for Real-Time Applications. It discusses requirements for
point-to point and conference calls, transcoding, relay services, real-time Text-over-IP telephony as well as interworking between
user mobility, interworking between text-over-IP telephony and Text-over-IP telephony and existing text telephony on the PSTN and
existing text-telephony, and some special features including other networks.
instant messaging have been described.
A. van Wijk [Page 1 of 28]
Table of Contents Table of Contents
1. Introduction 3 1. Introduction 3
2. Scope 3 2. Scope 3
3. Terminology 4 3. Terminology 3
A. van Wijk [Page 1 of 37]
4. Definitions 4 4. Definitions 4
5. Background and General Requirements 5 5. Framework Description 5
6. Features in Real-time Text-over-IP 6 5.1. Background 5
7. Real-Time Multimedia Conversational Sessions using SIP 7 5.2. Requirements for ToIP 6
8. General Requirements for Real-Time Text-over-IP using SIP 9 5.3. Use of SIP and RTP 6
8.1 Pre-Call Requirements 9 5.4. Requirements for ToIP Interworking 9
8.2 Basic Point-to-Point Call Requirements 10 6. Detailed requirements for Text-over-IP 9
8.2.1 General Requirements 10 6.1. Pre-Call Requirements 10
8.2.2 Session Setup 10 6.2 Basic Point-to-Point Call Requirements 10
8.2.3 Addressing 11 6.2.1 Session Setup 10
8.2.4 Alerting 11 6.2.2 Addressing 11
8.2.5 Call Negotiations 12 6.2.3 Alerting and session progress presentation 11
8.2.6 Answering 12 6.2.4 Call Negotiations 12
8.2.7 Session progress and status presentation 12 6.2.5 Answering 12
8.2.8 Actions During Calls 13 6.2.6 Actions During Calls 13
8.2.9 Additional session control 15 6.2.7 Additional session control 14
8.2.10 File storage 15 6.2.8 File storage 15
8.3 Conference Call Requirements 15 6.3 Conference Call Requirements for ToIP User Agents 15
8.4 Transport 15 6.4 Transport via RTP 15
8.5 Character Set 16 6.5 Character Set 16
8.6 Transcoding 16 6.6 Transcoding 16
8.7 Relay Services 17 6.7 Relay Services 16
8.8 Emergency services 18 6.8 Emergency services 17
8.9 User Mobility 18 6.9 User Mobility 17
8.10 Confidentiality and Security 18 6.10 Confidentiality and Security 17
8.11 Call Scenarios 18 7. Interworking Requirements for ToIP 17
8.11.1 Call Scenarios 19 7.1 ToIP Interworking Gateway Services 17
8.11.2 Point-to-Point Call Scenarios 20 7.2 ToIP and PSTN/ISDN Text-Telephony 18
8.11.3 Conference Call Scenarios 20 7.3 ToIP and Cellular Wireless circuit switched Text-Telephony
9. Interworking Requirements for Text-over-IP 21 18
9.1 Real-Time Text-over-IP Interworking Gateway Services 21 7.3.1 "No-gain" 19
9.2 Text-over-IP and PSTN/ISDN Text-Telephony 21 7.3.2 Cellular Text Telephone Modem (CTM) 19
9.3 Text-over-IP and Cellular Wireless circuit switched Text- 7.3.3 "Baudot mode" 19
Telephony 22 7.3.4 Data channel mode 19
9.3.1 "No-gain" 22 7.3.5 Common Text Gateway Functions 19
9.3.2 Cellular Text Telephone Modem (CTM) 22 7.4 ToIP and Cellular Wireless ToIP 20
9.3.3 "Baudot mode" 23 7.5 Instant Messaging Support 20
9.3.4 Data channel mode 23 7.6 IP Telephony with Traditional RJ-11 Interfaces 21
9.3.5 Common Text Gateway Functions 23 7.7 Multi-functional gateways 22
9.4 Text-over-IP and Cellular Wireless Text-over-IP 23 7.8 ToIP interoperability with PSTN text telephones. 22
9.5 Instant Messaging Support 24 7.9 Gateway Discovery 22
9.6 IP Telephony with Traditional RJ-11 Interfaces 25 8. Afterword 23
9.7 Interworking Call Flows 25 9. Security Considerations 23
9.8 Multi-functional gateways 26 10. Authors Addresses 24
9.9 Gateway Discovery 26 11. References 25
9.10 Text Gateway in the call Scenarios 27 11.1 Normative 25
9.10.1 IP terminal calling an analogue textphone (PSTN) 27 11.2 Informative 27
9.10.2 IP terminal calling a mobile text telephone (CTM) 28
9.10.3 IP terminal calling a mobile telephone (GPRS based) 28
9.10.4 IP terminal calling a mobile telephone(UMTS) 28
9.10.5 Analogue textphone (PSTN) user calling an IP terminal using
prefix 28
A. van Wijk [Page 2 of 37]
9.10.6 Mobile text telephone (CTM) user calling an IP terminal
29
9.10.7 Mobile telephone user (GPRS) calling an IP terminal 29
9.10.8 Mobile telephone (UMTS) user calling an IP terminal 29
9.10.9 Voice over DSL user using an analogue text telephone. 29
9.10.10 VoIP user via a building telephone switch (at an apartment
building) owning an analogue text telephone. 29
9.10.11 VoIP user via a gateway/box connected to his/her own
Broadband connection owning an analogue text telephone. 29
10. Terminal Features 30
10.1 Text input 30
10.2 Text presentation 31
10.3 Call control 32
10.4 Device control 32
10.5 Alerting 32
10.6 External interfaces 33
10.7 Power 33
11. Security Considerations 33
12. Outstanding issues 33
13. Authors Addresses 34
14. Acknowledgements 35
15. Full Copyright Statement 35
16. References 35
16.1 Normative 35
16.2 Informative 37
A. van Wijk [Page 2 of 28]
1. Introduction 1. Introduction
Text-over-IP (ToIP) is becoming popular as a part of total For many years, text has been in use as a medium for
conversation among a range of users although this medium of conversational, interactive dialogue between users in a similar
communications may be the most convenient to certain categories of way as voice telephony is used. Such interactive text is different
people (e.g., deaf, hard of hearing and speech-impaired from messaging and semi-interactive solutions like Instant
individuals). The Session Initiation Protocol (SIP) has become the Messaging in that it offers an equivalent conversational
protocol of choice for control of Multimedia IP telephony and experience to users that cannot, or do not wish to, use voice. It
Voice-over-IP (VoIP) communications. Naturally, it has become therefore meets a different set of requirements than other text-
essential to define the requirements for how ToIP can be used with based solutions already available on IP networks.
SIP to allow text conversations as an equivalent to voice. This Traditionally, deaf, hard of hearing and speech-impaired people
document defines the framework of requirements for using ToIP, are amongst the most proliferate users of conversational,
either by itself or as a part of total conversation using SIP for interactive text, but because of its interactivity, it is becoming
session control. popular amongst mainstream user groups as well.
This document describes how existing IETF protocols can be used to
implement a Text-over-IP solution (ToIP). This ToIP framework is
specifically designed to be compatible with Voice-over-IP
environments, as well as meeting the userĂs requirements,
including those of deaf, hard of hearing and speech-impaired users
as described in RFC3351 [21].
The Session Initiation Protocol (SIP) is the protocol of choice
for control of Multimedia IP telephony and Voice-over-IP (VoIP)
communications. It offers all the necessary control and signaling
required for the ToIP framework.
The Real-Time Transport Protocol (RTP) is the protocol of choice
for real-time data transmission, and its use for interactive text
payloads is described in RFC4103 [5].
This document defines a framework for ToIP to be used either by
itself or as part of integrated services, including Total
Conversation.
2. Scope 2. Scope
The primary scope of this document is to define the requirements The primary scope of this document is to define a framework for
for using ToIP with SIP, either stand-alone or as a part of a the implementation of ToIP, either stand-alone or as a part of
total conversation approach. In general, the scope of the wider services, including Total Conversation. In general, the
requirements is: scope is:
a. Features in Real-Time ToIP
b. Real-time Multimedia Conversational Sessions using SIP
c. General Requirements for Real-Time ToIP using SIP
d. Interworking Requirements for ToIP
A. van Wijk [Page 3 of 37] a. Description of ToIP using SIP and RTP;
e. Text gateways to interconnect the different networks b. Requirements of Real-time, interactive text;
c. Requirements for ToIP interworking.
The subsequent sections describe those requirements in detail. The subsequent sections describe those requirements in detail.
3. Terminology 3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL In this document, the key words "MUST", "MUST NOT", "REQUIRED",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
in this document are to be interpreted as described in RFC 2119 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
[2]. described in BCP 14, RFC 2119 [2] and indicate requirement levels
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.
Full duplex - user information is sent independently in both Full duplex - media is sent independently in both directions.
directions.
Half duplex - user information can only be sent in one direction Half duplex - media can only be sent in one direction at a time
at a time or, if an attempt to send information in both directions or, if an attempt to send information in both directions is made,
is made, errors can be introduced into the user information. 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.
TTY - name for text telephone, often used in USA, see textphone. TTY ű alternative designation for a text telephone, often used in
Also called TDD, Telecommunication Device for the Deaf. USA, see textphone. Also called TDD, Telecommunication Device for
the Deaf.
Textphone - text telephone. A terminal device that allow end-to- Textphone ű also ˘text telephone÷. A terminal device that allows
end real time text communication. A variety of textphone protocols end-to-end real-time, interactive text communication. A variety of
exists world-wide, both in the PSTN and other networks. A textphone protocols exists world-wide, both in the PSTN and other
textphone can often be combined with a voice telephone, or include networks. A textphone can often be combined with a voice
voice communication functions for simultaneous or alternating use telephone, or include voice communication functions for
of text and voice in a call. simultaneous or alternating use of text and voice in a call.
Text bridging - a function of a gateway or relay service that Text bridging - a function of a gateway service that enables the
enables the flow of text through the service between the users flow of text through the service between the users involved in the
involved in the call. call.
Text gateway - a multi functional gateway that is able to Text gateway - a multi functional gateway that is able to
transcode between different forms of text transport methods. E.g. transcode between different forms of text transport methods, e.g.,
Between ToIP in IP networks and Baudot text telephony in the PSTN. between ToIP in IP networks and Baudot text telephony in the PSTN.
Text telephony - Analog textphone services Text telephony ű analog textphone services
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.
A. van Wijk [Page 4 of 37] Transcoding Services - services of a third-party user agent that
Transcoding Services - Services of a third-party user agent transcodes one stream into another. Transcoding can be done by
(human or automated) that transcodes one stream into another. human operators, in automated manner or a combination of both
methods. Text Relay Services are examples of a transcoding service
between text and audio.
Total Conversation - A multimedia service offering real time Total Conversation - A multimedia service offering real time
conversation in video, text and voice according to interoperable conversation in video, text and voice according to interoperable
standards. All media flow in real time. Further defined in ITU-T standards. All media flow in real time. Further defined in ITU-T
F.703 Multimedia conversational services description. 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 with total conversation between deaf and hard of hearing people, and hearing persons with
devices, and hearing persons with voice telephones by translating voice telephones by translating between sign language and spoken
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
CTM Cellular Text Telephone Modem CTM Cellular Text Telephone Modem
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
PSTN Public Switched Telephone Network PSTN Public Switched Telephone Network
SIP Session Initiation Protocol SIP Session Initiation Protocol
TDD Telecommunication Device for the Deaf TDD Telecommunication Device for the Deaf
TDMA Time Division Multiple Access TDMA Time Division Multiple Access
ToIP Text over Internet Protocol ToIP Text over Internet Protocol
UTF-8 Universal Transfer Format-8 UTF-8 Universal Transfer Format-8
5. Background and General Requirements 5. Framework Description
The main purpose of this document is to provide a set of 5.1. Background
requirements for real-time text conversation over the IP network
using the Session Initiation Protocol (SIP) [3]. The overall
requirement is that real-time text conversation can be part of a
conversational service like any other media. Participants can
negotiate all media including real-time text conversation[4, 5].
This is a highly desirable function for all IP telephony users,
and essential for deaf, hard of hearing, or speech impaired people
who have limited or no use of the audio path of the call.
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 take place, therefore providing the same mode of interaction takes place, thus providing the same mode of
interaction as voice telephony does. Store-and-forward systems interaction as voice telephony does for hearing people. Store-and-
like email or messaging on mobile networks or non-streaming forward systems like email or messaging on mobile networks or non-
streaming systems like instant messaging are unable to provide
A. van Wijk [Page 5 of 37] that functionality.
systems like instant messaging are unable to provide that
functionality.
One particular application where real-time text is absolutely
essential, is the use of relay services between conversational
modes, like between text and voice.
Direct text emergency service calls, where time and continuous
connection are of the essence, is another essential application.
6. Features in Real-time Text-over-IP
While real-time Text-over-IP will be used for a wide variety of
services, an important field of application will be to provide a
text equivalent to voice conversation, in particular for deaf,
hard of hearing and speech-impaired users.
As such, it is crucial that the conversational nature of this
service is maintained. Text based communications exist in a
variety of forms, some non-conversational (SMS, text paging, E-
mail, newsgroups, message boards, etc.), others conversational
(TTY/TDD, Textphone, etc).
Real-time Text-over-IP will sometimes be used in conjunction with
a relay service [I] to allow text users to communicate with voice
users. With relay services, it is crucial that text characters are
sent as soon as possible after they are entered. While buffering
MAY be done to improve efficiency, the delays SHOULD be kept as
small as possible. In particular, buffering of whole lines of text
MUST NOT be used.
In order to make Real-Time Text-over-IP the equivalent of what
voice is to hearing people, it needs to offer equivalent features
in terms of conversation as voice communications provides to
hearing people. To achieve that, real-time Text-over-IP MUST:
a. Offer Real-Time presentation of the conversation. This means 5.2. Requirements for ToIP
that text MUST be sent as soon as available, or with very small
delays. The delay MUST not be longer than 300 milliseconds,
b. Provide simultaneous transmission in both directions, In order to make ToIP the equivalent of what voice is to hearing
people, it needs to offer equivalent features in terms of
conversationality as voice telephony provides to hearing people.
To achieve that, ToIP MUST:
a. Offer real-time presentation of the conversation;
b. Provide simultaneous transmission in both directions;
c. Provide interoperability with text conversation features in c. Provide interoperability with text conversation features in
other networks, e.g. PSTN, accepting functional limitations that other networks, for instance the PSTN, accepting functional
this will lead to during interoperation. limitations that will occur during interoperation.
d. Not prevent other media, like audio and video, to be used in
d. Support a transmission rate of at least 30 characters/second. conjunction with ToIP.
e. Support suitable reliability of text transmission. A character
error rate of 0.2% is regarded good, and 1% usable.
f. Be possible to merge with video and voice transmission.
A. van Wijk [Page 6 of 37]
g. The end-to-end delay in transmission MUST be less than 2000
milliseconds.
Many users will want to use multiple modes of communication during Users might want to use multiple modes of communication during the
the conversation, either at the same time or by switching between conversation, either at the same time or by switching between
modes e.g. between real-time Text-over-IP and voice. Native real- modes, e.g., between text and audio for example. Native ToIP
time Text-over-IP systems MUST support simultaneous use of services MUST ensure that the text interface is always available.
modalities so that the text interface is always available.
When communicating via a gateway to other networks and protocols, When communicating via a gateway to other networks and protocols,
the system MUST completely support the functionality for the service SHOULD support all the functionality for alternating
alternating or simultaneous modalities as offered by the gateway. or simultaneous use of modalities as offered by the destination
network.
When voice is supported on the terminal, the terminal MUST provide ToIP will often be used to access a relay service [I], allowing
volume control. text users to communicate with voice users. With relay services,
it is crucial that text characters are sent as soon as possible
after they are entered. While buffering MAY be done to improve
efficiency, the delays SHOULD be kept as small as possible. In
particular, buffering of whole lines of text MUST NOT be used.
7. Real-Time Multimedia Conversational Sessions using SIP 5.3. Use of SIP and RTP
The Session Initiation Protocol (SIP) [3] provides mechanisms for ToIP services MUST use the Session Initiation Protocol (SIP) [3]
creating, modifying, and terminating sessions for real-time for setting up, controlling and terminating sessions for real-time
conversation with one or more participants using any combination text conversation with one or more participants and possibly
of media: Text, Video and Audio. However, participants are allowed including other media like video or audio.
to negotiate on a set of compatible media types (e.g., Text, Thus, participants are allowed to negotiate on a set of compatible
Video, Audio) with session descriptions used in SIP invitations. 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 The standardized T.140 real-time text conversation [4], in
addition to audio and video communications, will be a valuable addition to audio and video communications, will be a valuable
service to many. Real-time text can be expressed as a part of the service to many, including on non-IP networks. Real-time text can
session description in SIP and is a useful subset of the Total be expressed as a part of the session description in SIP and is a
Conversation (which is Real-time text, Video and Audio useful subset of Total Conversation.
simultaneously).
This specification describes the framework for using the T.140 The ToIP specification describes a framework for using the T.140
text conversation in SIP as a part of the multimedia session text conversation in SIP as a part of the multimedia session
establishment in real-time over a SIP network. establishment in real-time over a SIP network.
The session establishment using SIP defines procedures for how If the User Agents of different participants indicate that there
T.140 text conversation can be supported using the text/t140 RTP is an incompatibility between their capabilities to support
payload defined in RFC 2793 [5]. The performance characteristics certain media types, e.g. one terminal only offering T.140 over IP
of T.140 will be determined using RTCP. as described in RFC4103 and the other one only supporting audio,
the user might want to invoke a transcoding services.
The session will not only define procedures between the SIP Examples of possible scenarios for including a relay service in
devices having text conversation capability, but will also define the conversation are: speech-to-text (STT), text-to-speech (TTS),
how sessions in SIP can be established between the text text bridging after conversion from speech, audio bridging after
conversation and audio/video/text capable devices transparently. conversion from text, etc.
If there is any incompatibility between the terminals, e.g. T.140 The session description protocol (SDP) [6] used in SIP to describe
only and audio-only terminals, the necessary transcoding services the session is used to express these attributes of the session
will need to be invoked. This important service feature offers a (e.g., uniqueness in media mapping for conversion from one media
variety of rich capabilities in the transcoding server. For to another for each communicating party).
example, speech-to-text (STT), text-to-speech (TTS), text bridging
after conversion from speech, audio bridging after conversion from
text, and other services can also be provided by the transcoding
A. van Wijk [Page 7 of 37] Real-time text can also be presented in conjunction with other
and/or translation server. The session description protocol (SDP) media like video and audio, as for example in Total Conversation
[6] used in SIP to describe the session also needs to be capable services.
of expressing 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 video and User Agents providing ToIP functionality SHOULD provide suitable
audio. Making real-time text part of total conversation. alerting, specifically offering visual and/or tactile alerting so
that deaf and hard of hearing users can use them.
Visual and/or Tactile alerting for T.140 capable terminals should The SIP abilities to set up text conversation sessions from any
to be provided. location, as well as privacy and security provisions SHOULD be
implemented in ToIP services.
Users may set up text conversation sessions using SIP from any Where ToIP is used in conjunction with other media, exposure of
location. In addition, user privacy and security MUST be provided SIP functions through the User Interface MUST be available in
for text conversation sessions at least equal to that for voice. equivalent fashion 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.
The transcoding/translation services can be invoked in SIP using Any ToIP implementation MUST also allow invocation and use of
different session establishment models [7]: Third party call relevant transcoding services where these are available. This can
control [8] and Conference Bridge model [9]. be achieved through application of SIP techniques for different
A. van Wijk [Page 7 of 28]
session establishment models [7]: Third party call control [8] and
Conference Bridge model [9].
Both point-to-point and multipoint communication need to be Both point-to-point and multipoint communication need to be
defined for the session establishment using T.140 text defined for the session establishment using T.140 text
conversation. In addition, the interworking between T.140 text conversation. In addition, ToIP services SHOULD support
conversation and text telephony conversation [10] is needed. interworking with text telephony [10].
The general requirements for real-time text conversation using SIP The general framework for ToIP can be described as follows:
can be described as follows:
a. Session setup, modification and teardown procedures for point- a. Session setup, modification and teardown procedures for point-
to-point and multimedia calls to-point and multimedia calls
b. Registration procedures and address resolutions b. Registration procedures and address resolutions
c. Registration of user preferences c. Registration of user preferences
d. Negotiation procedures for device capabilities d. Negotiation procedures for device capabilities
e. Discovery and invocation of transcoding/translation services e. Discovery and invocation of transcoding/translation services
between the media in the call between the media in the call
f. Different session establishment models for f. Different session establishment models for transcoding /
transcoding/translation services invocation: Third party call translation services invocation: Third party call control and
control and Conference bridge model conference bridge model
g. Uniqueness in media mapping to be used in the session for g. Uniqueness in media mapping to be used in the session for
conversion from one media to another by the conversion from one media to another by the transcoding /
transcoding/translation server for each communicating party translation server for each communicating party
h. Media bridging services for T.140 real-time text, audio, and h. Media bridging services for T.140 real-time text as described
video for multipoint communications in RFC4103, audio, and video for multipoint communications
i. Transparent session setup, modification, and teardown between i. Transparent session setup, modification, and teardown between
text conversation capable and voice/video capable devices text conversation capable and voice/video capable devices
A. van Wijk [Page 8 of 37] j. Support of text media transport using T.140 over RTP as laid
j. Conversations to be carried out using T.140-over-RTP and RTCP out in RFC 4103 [4]
will provide performance report for T.140
k. Altering capability using text conversation during the session k. Signaling of status information, call progress and the like in
establishment a suitable manner, bearing in mind the user may have a hearing
impairment
l. T.140 real-time text presentation mixing with voice and video l. T.140 real-time text presentation mixing with voice and video
m. T.140 real-time text conversation sessions using SIP, allowing m. T.140 real-time text conversation sessions using SIP, allowing
users to move from one place to another users to move from one place to another
n. User privacy and security for sessions setup, modification, and n. User privacy and security for sessions setup, modification, and
teardown as well as for media transfer teardown as well as for media transfer
o. Interoperability between T.140 conversations and analogue text o. Interoperability between T.140 conversations and analogue text
telephones telephones
A. van Wijk [Page 8 of 28]
p. Routing of emergency calls according to national or regional p. Routing of emergency calls according to national or regional
policy to the same level of a voice call. policy to the same level of a voice call.
8. General Requirements for Real-Time Text-over-IP using SIP 5.4. Requirements for ToIP Interworking
The communications environments for ToIP using SIP to set up the Analog text telephony is cumbersome because of incompatible
conversation in real-time may vary from a simple point-to-point national implementations where interworking was never considered.
call to multipoint calls in addition to the fact that ToIP can be A large number of these implementations have been documented in
used in combination with other media like audio and video. In ITU-T V.18, which also defines modem detection sequences for the
order to establish the session in real-time, the communicating different text terminals. The full modem capability exchange
parties SHOULD be provided with experiences like those of normal between two wildly different terminals can take more than one
telephony call setup. There may also be some need for pre-call minute to complete if both terminals have a common text
setup e.g. storing registration information in the SIP registrar modulation.
to provide information about how a user can be contacted. This
will allow calls to be set up rapidly and with proper addressing. To resolve international analog textphone incompatibilities, text
telephone gateways MUST transcode incoming analog signals into
T.140 and vice versa. The modem capability exchange time is then
also reduced, since V.18 allows the sequence of protocol discovery
to be customized. Hence, the text telephone gateways will assume
the analog text telephone protocol used in the region the gateway
is located. For example, in the USA, Baudot might be tried as the
initial protocol. If negotiation for Baudot fails, the full modem
capability exchange will then take place. In contrast, in the UK,
ITU-T V.21 might be the first choice.
6. Detailed requirements for Text-over-IP
ToIP services MUST use SIP for call control and signaling.
A ToIP user may wish to call another ToIP user, or join a
conference call involving several users. He or she may, also, wish
to initiate or join a multimedia call, such as a Total
Conversation call.
There may be some need for pre-call setup e.g. storing
registration information in the SIP registrar to provide
information about how a user can be contacted. This will allow
calls 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 another media is preferred by a user. For call 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 prefer to use audio while others want to
use text as their preferred choice of conversational mode. In this use text as their preferred modality. In this case, transcoding
case, transcoding services will need to be invoked for text-to- services might be needed for text-to-speech (TTS) and speech-to-
speech (TTS) and speech-to-text (STT). The requirements for text (STT). The requirements for transcoding services need to be
transcoding services need to be negotiated in real-time to set up negotiated in real-time to set up the session.
the session.
The subsequent subsections describe those requirements in great The subsequent subsections describe some of these requirements in
detail. detail.
8.1 Pre-Call Requirements A. van Wijk [Page 9 of 28]
6.1. Pre-Call Requirements
The desire of the users for using ToIP as a medium of The need to use ToIP as a medium of communications can be
communications can be expressed during registration time. Two expressed by users during registration time. Two situations need
situations need to be considered in the pre-call setup to be considered in the pre-call setup environment:
environment:
A. van Wijk [Page 9 of 37]
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 in a SIP preference for ToIP by registering that preference with a SIP
server. If the user is called by other party, preferences can be server that is part of the ToIP service.
invoked by the SIP server to accept or reject the call based on
the rules defined by the user. If the rules require that a
transcoding server is needed, the call can be re-directed or
handled accordingly.
b. Server to support User Preferences: SIP servers MUST have the b. Server to support User Preferences: SIP servers that are part
capability to act on users preferences for ToIP, based on the user of ToIP services MUST have the capability to act on users
preferences defined during the pre-call setup registration time. preferences for ToIP to accept or reject the call, based on the
user preferences defined during the pre-call setup registration
time. For example, if the user is called by another party, and it
is determined that a transcoding server is needed, the call MUST
be re-directed or otherwise handled accordingly.
8.2 Basic Point-to-Point Call Requirements 6.2 Basic Point-to-Point Call Requirements
The point-to-point call will take place between two parties. The The point-to-point call will take 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 ToIP
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.
8.2.1 General Requirements 6.2.1 Session Setup
The general requirements are that ToIP will be chosen from the
available media as the preferred means of communication for the
session. However, there may be a need to invoke some underlying
capabilities in some cases, for example, a transcoding server may
be invoked if one of the users want to use a communication medium
other than ToIP.
The following features MAY need to be involved to facilitate the
session establishment using ToIP as another medium:
a. Caller Preferences: SIP headers (e.g., Contact) can be used to
show that ToIP is the medium of choice for communications.
b. Called Party Preferences: The called party being passive can
formulate a clear rule indicating how a call should be handled
either using ToIP as a preferred medium or not, and whether a
designated SIP proxy needs to handle this call or it is handled in
the SIP user agent (UA).
c. SIP Server support for User Preferences: SIP servers can also
handle the incoming calls in accordance to preferences expressed
for ToIP. The SIP Server can also enforce ToIP policy rules for
communications (e.g., use of the transcoding server for ToIP).
8.2.2 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 will want to connect to. However, conversations could
be started using a mode other than real-time Text-over-IP. For be started using a mode other than ToIP. For instance, the
instance, the conversation might be established using voice and conversation might be established using audio and the user could
the user could elect to switch to text, or add text, during the subsequently elect to switch to text, or add text as an additional
conversation. Systems supporting real-time Text-over-IP MUST allow modality, during the conversation. Systems supporting ToIP MUST
allow users to select any of the supported conversation modes at
A. van Wijk [Page 10 of 37] any time, including mid-conversation.
users to select any of the supported conversation modes at 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 voice, 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 resource management on the network, the
system MUST try to establish a text-only communication. and the system MUST try to establish a text-only communication. The user
user MUST be informed of this change throughout the process, MUST be informed of this change throughout the process, either in
either in text or in a combination of modalities that MUST include text or in a combination of modalities that MUST include text.
text.
Session setup, especially through gateways to other networks, MAY Session setup, especially through gateways to other networks, MAY
require the use of specially formatted addresses or other require the use of specially formatted addresses or other
mechanisms for invoking gateways. mechanisms for invoking gateways.
Such mechanisms MUST be supported by the terminal.
8.2.3 Addressing A. van Wijk [Page 10 of 28]
The following features MAY need to be implemented to facilitate
the session establishment using ToIP:
a. Caller Preferences: SIP headers (e.g., Contact) can be used to
show that ToIP is the medium of choice for communications.
b. Called Party Preferences: The called party being passive can
formulate a clear rule indicating how a call should be handled
either using ToIP as a preferred medium or not, and whether a
designated SIP proxy needs to handle this call or it is handled in
the SIP user agent (UA).
c. SIP Server support for User Preferences: SIP servers can also
handle the incoming calls in accordance to preferences expressed
for ToIP. The SIP Server can also enforce ToIP policy rules for
communications (e.g. use of the transcoding server for ToIP).
6.2.2 Addressing
The SIP [3] addressing schemes MUST be used for all entities. For The SIP [3] addressing schemes MUST be used for all entities. For
example SIP URL and Tel URL will be used for caller, called party, example SIP URL and Tel URL will be used for caller, called party,
user devices, and servers (e.g., SIP server, Transcoding server). 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 in the service.
8.2.4 Alerting 6.2.3 Alerting and session progress presentation
Systems supporting real-time Text-over-IP MUST have an alerting User Agents supporting ToIP MUST have an alerting method (e.g.,
method (e.g., for incoming calls) that can be used by deaf and for incoming calls) that can be used by deaf and hard of hearing
hard of hearing people or provide a range of alternative, but people or provide a range of alternative, but equivalent, alerting
equivalent, alerting methods that are suitable for all users, methods that are suitable for all users, regardless of their
regardless of their abilities and preferences. abilities and preferences.
It should be noted that general alerting systems exist, and one It should be noted that general 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 on the user equipment and Among the alerting options are alerting by the User AgentĂs User
specific alerting user agents registered to the same registrar as Interface and specific alerting user agents registered to the same
the main user agent. registrar as the main user agent.
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 CLI) MUST be clearly presented to the user
in a form suitable for the user BEFORE answering the request. When in a form suitable for the user BEFORE answering the request. When
the invitation to initiate a conversation involving real-time the invitation to initiate a conversation involving ToIP
Text-over-IP originates from a gateway, this MAY be signalled to originates from a gateway, this MAY be signaled to the user.
the user.
A. van Wijk [Page 11 of 37] During a conversation that includes ToIP, status and session
8.2.5 Call Negotiations 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]
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.
Session progress information SHOULD use simple language as much as
possible so that as many users as possible can understand it. The
use of jargon or ambiguous terminology SHOULD be avoided at all
times. It is RECOMMENDED to let text information be used together
with icons symbolising the items to be reported.
There MUST be a clear indication, both visually as well as audibly
whenever a session gets connected or disconnected. The user SHOULD
never be in doubt as to what the status of the connection is, even
if he/she is not able to use audio feedback or vision.
In summary, it SHOULD be possible to observe visual or tactile
indicators about:
- Call progress
- Availability of text, voice and video channels
- Incoming call
- Incoming text
- Typed and transmitted text
- Any loss in incoming text.
6.2.4 Call 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 ToIP as a media in the call setup.
RFC 2793 [5] provides the RTP payload type text/t140 for support RFC 4103 [5] provides the RTP payload type text/t140 for support
of ToIP which can be indicated in the SDP as a part of SDP INVITE, of ToIP which can be indicated in the SDP as a part of SDP INVITE,
OK and SIP/200/ACK for media negotiations. In addition, SIPĂs OK and SIP/200/ACK for media negotiations. In addition, SIPĂs
offer/answer model can also be used in conjunction with other offer/answer model can also be used in conjunction with other
capabilities including the use of a transcoding server for capabilities including the use of a transcoding server for
enhanced call negotiations [7,8,9]. enhanced call negotiations [7,8,9].
8.2.6 Answering 6.2.5 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 kept informed
at all times about the progress of session establishment. On all at all times about the progress of session establishment. On all
systems that both inform users of session status and support real- systems that both inform users of session status and support ToIP,
time Text-over-IP, this information MUST be available in text, and this information MUST be available in text, and MAY be provided in
may be provided in other visual media. other visual media.
8.2.6.1 Answering Machine
Systems for real-time Text-over-IP MAY support an auto-answer
function, equivalent to answering machines on telephony networks.
If an answering machine function is supported, it MUST support at
least 160 characters for the greeting message. It MUST support
incoming text message storage of a minimum of 16000 characters,
although systems MAY support much larger storage.
When the answering machine is activated, user alerting MUST still
take place. The user MUST be allowed to monitor the auto-answer
progress and MUST be allowed to intervene during any stage of the
answering machine and take control of the session.
8.2.7 Session progress and status presentation
During a conversation that includes real-time Text-over-IP, status 6.2.5.1 Answering Machine
and session 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 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. Systems for ToIP MAY support an auto-answer function, equivalent
to answering machines on telephony networks. If an answering
machine function is supported, it MUST support at least 160
characters for the greeting message. It MUST support incoming text
message storage of a minimum of 4096 characters, although systems
Session progress information MUST use simple language as much as A. van Wijk [Page 12 of 28]
possible so that it can be understood by as many users as MAY support much larger storage. It is RECOMMENDED that systems
possible. support storage of at least 20 incoming messages of up to 16000
The use of jargon or ambiguous terminology SHOULD be avoided at characters.
all times. It is RECOMMENDED to let text information be used
together with icons symbolising the items to be reported.
A. van Wijk [Page 12 of 37] When the answering machine is activated, user alerting SHOULD
There MUST be a clear indication, both visually as well as audibly still take place. The user SHOULD be allowed to monitor the auto-
whenever a session gets connected and disconnected. The user answer progress and where this is provided the user MUST be
should never be in doubt as to what the status of the connection allowed to intervene during any stage of the answering machine and
is, even if he/she is not able to use audio feedback or vision. take control of the session.
8.2.8 Actions During Calls 6.2.6 Actions During Calls
Certain actions need to be performed for the ToIP conversation Certain actions need to be performed for the ToIP conversation
during the call and these actions are describe briefly as follows: during the call and these actions are described briefly as
follows:
a. Text transmission SHALL be done character by character as a. Text transmission SHALL be done character by character as
entered, or in small groups transmitted so that no character is entered, or in small groups transmitted so that no character is
delayed between entry and transmission by more than 300 delayed between entry and transmission by more than 300
milliseconds. milliseconds.
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 speech
to text methods of generating conversation text can be supported. to text methods of generating conversation text can be supported.
c. After text connection is established, the mean end-to-end delay c. After text connection is established, the mean end-to-end delay
of characters SHALL be less than two seconds, measured between two of characters SHALL be less than two seconds, measured between two
ToIP users. This requirement is valid as long as the text input ToIP users. This requirement is valid as long as the text input
rate is lower or equal to the text reception and display rate. rate is lower or equal to the text reception and display rate.
d. The character corruption rate SHALL be less than 1% in d. The character corruption rate SHALL be less than 1% in
skipping to change at line 683 skipping to change at line 686
ITU-T F.700 Annex A.3 quality level T1. ITU-T F.700 Annex A.3 quality level T1.
e. When interoperability functions are invoked, there may be a e. When interoperability functions are invoked, there may be a
need for intermediate storage of characters before transmission to need for intermediate storage of characters before transmission to
a device receiving slower than the typing speed of the sender. a device receiving slower than the typing speed of the sender.
Such temporary storage SHALL be dimensioned to adjust for Such temporary storage SHALL be dimensioned to adjust for
receiving at 30 characters per second and transmitting at 6 receiving at 30 characters per second and transmitting at 6
characters per second during at least 4 minutes [less than 3k characters per second during at least 4 minutes [less than 3k
characters]. characters].
f. If text is detected to be missing after transmission, there f. To enable the use of international character sets the
SHALL be an indication in the text marking the loss. 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
SHALL be an indication in the text marking the loss. For 7 bit
terminals this loss MAY be marked as an apostrophe: Ă.
g. When used from a terminal designed for PSTN text telephony, or g. When used from a terminal designed for PSTN text telephony, or
in interworking with such a terminal, ToIP shall enable in interworking with such a terminal, ToIP shall enable
A. van Wijk [Page 13 of 28]
alternating between text and voice in a similar manner as the PSTN alternating between text and voice in a similar manner as the PSTN
text telephone handles this mode of operation. (This mode is often text telephone handles this mode of operation. (This mode is often
called VCO/HCO in USA). called VCO/HCO in the USA and the UK).
h. The transmission of the text conversation SHALL be made
according to an internationally suitable character set and control
protocol for text conversation as specified in ITU-T T.140.
i. When display of the conversation on end user equipment is i. When display of the conversation on end user equipment is
included in the design, display of the dialogue SHALL be made so included in the design, display of the dialogue SHALL be made so
that it is easy to read text belonging to each party in the that it is easy to read text belonging to each party in the
conversation. conversation.
A. van Wijk [Page 13 of 37] 6.2.6.1 Text and other Media Handling Between ToIP User Agents
8.2.8.1 Text and other Media Handling Between ToIP Devices
The ToIP devices do not need transcoding from speech to text and The following requirements are valid for media handling during
can communicate directly using text/t140. The following calls:
requirements are valid for media handling during calls:
a. When used between terminals 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.
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.
b. When used between terminals designed for ToIP, it SHALL be c. It SHOULD be possible to know during the call that ToIP is
possible to send and receive text simultaneously.
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 available, even if it is not invoked at call setup (only voice
and/or video is used). To disable this, the user must disable the and/or video is used for example). To disable this, the user must
use of ToIP. disable the use of ToIP. This is possible during registration at
the REGISTRAR.
8.2.8.2 General Actions
a. It SHALL be possible to establish a session with text
capabilities enabled at the beginning of a Call. Note: a call is
in this document defined as one or more sessions).
b. It SHALL be possible to place a call without text capabilities,
and to add text capabilities later in the call.
c. It SHALL be possible to transfer text at at least 30 characters
per second
d. It SHALL be possible to talk and listen simultaneously with
typing and reading.
8.2.8.3 Call Action with Native ToIP Devices 6.2.6.2 Call Action with Native ToIP User Agents
a. It SHOULD be possible to answer a call with text capabilities a. It SHOULD be possible to answer a call with text capabilities
enabled. enabled.
b. It SHOULD be possible to use video simultaneously with the b. It MAY be possible to use video simultaneously with the other
other media in the call. media in the call.
c. It SHOULD be possible to answer a call in voice or video c. It MUST be possible to answer a call in voice or video without
without text enabled, and add text later in the call. text enabled, and add text later in the call.
d. It MUST be possible to disconnect the call. d. It MUST be possible to disconnect the call.
e. It SHOULD be possible to control IVR (Interactive Voice e. It SHOULD be possible to invoke multi-party calls.
Response) services from a numeric keypad.
f. It SHOULD be possible to control ITR ( Interactive Text
Response) services from the alphanumeric keyboard.
A. van Wijk [Page 14 of 37]
g. It SHOULD be possible to invoke multi-party calls.
h. It SHALL be possible to transfer the call.
i. It MUST be possible to use text characters (numbers) instead of
DTMF tones (numbers) in interactions where the person is using a
keyboard to interact with a service and the service asks for a
number.
8.2.8.4 Audio/Visual/Tactile Indicators
It SHOULD be possible to observe visual or tactile indicators f. It MUST be possible to transfer the call.
about:
- Call progress
- Availability of text, voice and video channels.
- Incoming call.
- Incoming text.
- Typed and transmitted text.
- Any loss in incoming text.
8.2.9 Additional session control 6.2.7 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 calls, MUST
offer equivalent functionality for real-time Text-over-IP offer equivalent functionality for text calls.
functions. In addition, all these features MUST be controllable by
text users at any time, in an equivalent way as for other users.
8.2.10 File storage A. van Wijk [Page 14 of 28]
6.2.8 File storage
Systems that support real-time Text-over-IP MAY save the text Systems that support ToIP MAY save the text conversation to a
conversation to a file. This SHOULD be done using a standard file file. This SHOULD be done using a standard file format. For
format. example: UTF8 text file in XML format including record timestamp,
party and the text conversation.
8.3 Conference Call Requirements 6.3 Conference Call Requirements for ToIP User Agents
The conference call requirements deal with multipoint conferencing The conference call requirements deal with multipoint conferencing
calls where there will be at least one or more ToIP capable calls where there will be at least one or more ToIP capable
devices along with other end user devices where the total number devices along with other end user devices where the total number
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 calls,
in a similar way as video is handled and displayed. Text in in a similar way as the audio is handled and the video is
conferences can be used both for letting individual participants displayed. Text in conferences can be used both for letting
use the text medium, and for central support of the conference individual participants use the text medium (for example, for
with real time text interpretation of speech. sidebar discussions in text while listening to the main conference
audio), as well as for central support of the conference with real
time text interpretation of speech.
8.4 Transport 6.4 Transport via RTP
ToIP uses RTP as the default transport protocol for transmission ToIP uses RTP as the default transport protocol for transmission
of real-time text medium text/t140 as specified in RFC 2793 [5]. of real-time text via medium text/t140 as specified in RFC 4103
Signaling and other media will use the transport protocol [5].
A. van Wijk [Page 15 of 37]
specified in SIP [3] and/or their revised versions as specified in
standards.
The redundancy method of RFC 2198 SHOULD be used for making text The redundancy method of RFC 4103 [5] SHOULD be used for making
transmission reliable with transmission of three generations. text transmission reliable.
Text capability SHOULD be announced in SDP by a declaration in Text capability MUST be announced in SDP by a declaration in line
line with this example: with this example:
m=text 11000 RTP/AVP 98 100 m=text 11000 RTP/AVP 98 100
a=rtpmap:98 t140/1000 a=rtpmap:98 t140/1000
a=rtpmap:100 red/1000 a=rtpmap:100 red/1000
a=fmtp:100 98/98/98 a=fmtp:100 98/98/98
Characters SHOULD BE buffered for transmission and transmitted Characters SHOULD be buffered for transmission and transmitted
every 300 ms. every 300 ms.
By having this single coding and transmission scheme for real time By having this single coding and transmission scheme for real time
text defined, in the SIP call control environment, the opportunity text defined, in the SIP call control environment, the opportunity
for interoperability is optimized. for interoperability is optimized.
However, if good reasons exist, other transport mechanisms MAY be However, if good reasons exist, other transport mechanisms MAY be
offered and used for the T.140 coded text, provided that proper offered and used for the T.140 coded text, provided that proper
negotiation is introduced, and RFC 2793 transport MUST be used as negotiation is introduced, and RFC 4103 [5] transport MUST be used
the defaut fallback solution. as both the default as well as the fallback transport.
8.5 Character Set A. van Wijk [Page 15 of 28]
6.5 Character Set
a. Real-Time Text-over-IP protocols MUST use UTF-8 encoding as a. ToIP services MUST use UTF-8 encoding as specified in ITU-T
specified in ITU-T T.140 [12]. T.140 [12].
b. Real-time Text-over-IP SHOULD handle characers with editing b. ToIP SHOULD handle characters with editing effect such as new
effect such as new line, erasure and alerting during session as line, erasure and alerting during session as specified in ITU-T
specified in ITU-T T.140. T.140.
8.6 Transcoding 6.6 Transcoding
Transcoding of text may need to take place in gateways between Transcoding of text may need to take place in gateways between
ToIP and other forms of text conversation. ToIP makes use of ToIP and other forms of text conversation. For example to connect
ISO 10646 character set. to a PSTN text telephone.
Most PSTN textphones use a 7-bit character set, or a character set
that is converted to a 7-bit character set by the V.18 modem.
When transcoding between these character sets and T.140 in
gateways, special consideration MUST be paid to the national
variants of the 7 bit codes, with national characters mapping into
different codes in the ISO 10 646 code space. The national variant
to be used SHOULD be possible to select by the user per call, or
be configured as a national default for the gateway.
The missing text indicator in T.140, specified in T.140 amendment
1, cannot be represented in the 7 bit character codes. Therefore
A. van Wijk [Page 16 of 37] 6.7 Relay Services
these characters SHOULD be translated to be represented by the '
(apostrophe) character in legacy text telephone systems where this
character exists. For legacy systems where the character ' does
not exist, the character . ( full stop ) SHOULD be used instead.
8.7 Relay Services The relay service acts as an intermediary between two or more
callers using different media or different media encoding schemes.
The relay service acts as an intermediary between 2 or more The basic text relay service allows a translation of speech to
callers. text and text to speech, which enables hearing and speech impaired
The basic relay service allows a translation of speech to text and callers to communicate with hearing callers. Even though this
text to speech, which enables hearing and speech impaired callers document focuses on ToIP, we want to remind readers that there
to communicate with hearing callers. Even though this document exist other relay services like, for example, speech to sign
focuses on ToIP, we do not exclude video relay services for e.g., language and vice versa using video.
speech to sign language and vice versa and other possible relay
services. It will be possible to use ToIP simultaneously with
other relay services if desired.
It is very important for the users that a relay session is invoked It is RECOMMENDED that ToIP implementations make the invocation
as transparently as possible. It SHOULD happen automatically when and use of relay services as easy as possible. It MAY happen
the call is being set-up or by a simple user action. A transcoding automatically when the call is being set up based on any valid
framework document using SIP [7] describes invoking relay indication or negotiation of supported or preferred media types. A
services, where the relay acts as a conference bridge or uses the transcoding framework document using SIP [7] describes invoking
third party control mechanism. 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 Adding or removing a relay service MUST be possible without
disrupting the current call. disrupting the current call.
When setting up a call, the relay service MUST be able to When setting up a call, the relay service MUST be able to
determine the type of service requested (e.g. speech to text or determine the type of service requested (e.g., speech to text or
text to speech), to indicate if the caller wants voice carry over, text to speech), to indicate if the caller wants voice carry over,
the language of the text including the sign language being used. the language of the text, the sign language being used (in the
video stream), etc.
The user MUST be provided with a method to indicate which service
is desired.
Relay services MUST be reachable all the time, even if the users
are visiting networks from different operators.
It SHOULD be possible to route the call to a preferred relay It SHOULD be possible to route the call to a preferred relay
service even if the user makes the call from another region or service even if the user makes the call from another region or
network than usually used. network than usually used.
It MUST be possible to identify ToIP sessions as emergency A. van Wijk [Page 16 of 28]
sessions. 6.8 Emergency services
If it is decided that a relay service supports emergency calls,
the relay service operator MUST be able to process such a session
correctly and quickly with the following functionality:
a. The relay service operatorĂs network MUST give priority to this
incoming call.
A. van Wijk [Page 17 of 37]
b. The relay service operator MUST forward this session if they
are unable to process it to an alternative emergency relay
operator.
c. The relay service MUST label the transcoded stream as an
emergency call (in case of text to speech and/or vice versa).
d. The relay service MUST provide all session information to the
emergency centre (e.g., location information of the caller if
available).
8.8 Emergency services
a. It MUST be possible to support emergency service calls with
text only or simultaneously with voice.
b. All session information that accompanies a voice session to the
emergency centre, MUST also be provided to the emergency center if
it is a ToIP session.(e.g, phone number and location information
of the user placing the emergency call).
c. A text over IP stream MUST be labelled as an emergency stream Access to emergency services using ToIP SHOULD provide an
to ensure that the emergency service center is able to receive equivalent service to the one offered by other supported media,
this call. like audio.
8.9 User Mobility 6.9 User Mobility
ToIP terminals SHOULD use the same mechanisms as other terminals ToIP User Agents SHOULD use the same mechanisms as other SIP User
to resolve mobility issues. It is RECOMMENDED to use a SIP-adress Agents to resolve mobility issues. It is RECOMMENDED to use a SIP-
for the users, resolved by a SIP REGISTRAR, to enable basic user address for the users, resolved by a SIP REGISTRAR, to enable
mobility. Further mechanisms are defined for the 3G IP multimedia basic user mobility. Further mechanisms are defined for the 3G IP
systems. multimedia systems.
8.10 Confidentiality and Security 6.10 Confidentiality and Security
User confidentiality and privacy need to be met as described in User confidentiality and privacy need to be met as described in
SIP [3]. For example, nothing should reveal the fact that the user 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 of ToIP is a person with a disability unless the user prefers to
make this information public. If a transcoding server is being make this information public. If a transcoding server is being
used, this SHOULD be transparent. Encryption SHOULD be used on 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 end-to-end or hop-by-hop basis as described in SIP [3] and SRTP
[19] [19]
Authentication needs to be provided for users in addition to the Authentication needs to be provided for users in addition to the
message integrity and access control. message integrity and access control.
Protection against Denial-of-service (DoS) attacks needs to be Protection against Denial-of-service (DoS) attacks needs to be
provided considering the case that the ToIP users might need provided considering the case that the ToIP users might need
transcoding servers. transcoding servers.
8.11 Call Scenarios 7. Interworking Requirements for ToIP
A. van Wijk [Page 18 of 37]
ToIP is a way of establishing the real-time conversation. Call
flow for ToIP MUST be similar to session
establishment with audio and video. For example, ToIP services MAY
be invoked in the following situations (among others):
- Noisy environment (e.g., in a machine room of a factory where
listening is difficult)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
- Not hearing well or not at all (e.g., hearing loss due to aging,
hard of hearing, deaf)
NOTE: In many of the above scenarios, text may accompany speech in
a subtitling like fashion. This would occur for individuals who
are hard of hearing and also for mixed calls with a hearing and
deaf person listening to the call.
All call flows either for the point-to-point or for the multipoint
situation need to consider that ToIP services may be invoked for
many different reasons by users as explained. When the
transcoding/translation services are needed, call flows will be
shown for both session establishment models: Third-party call
control model and Conferencing bridge model.
8.11.1 Call Scenarios
There are 2 different terminal types possible:
1. The terminal itself has the intelligence to initiate a relay
service for incoming and outgoing calls (based on address book,
user preferences programmed on the terminal etc. This terminal can
be used in a conference bridge call as well as a third party
control call.
2. Dumb terminals, so that the relay service server actually
initiates the correct call handling (the dumb terminal can only
REFER the call to the relay center, which then sets up the call
using the conference bridge flow.).
The following call scenarios are shown:
- Communications between two ToIP/Multimedia capable, end user
devices using the same language.
- Communications between ToIP capable, end user devices using
translation services to provide language translation.
A. van Wijk [Page 19 of 37]
- Communications between ToIP/Multimedia capable and Audio (non-
ToIP) capable end user devices.
- Communications between ToIP/Multimedia and/or Audio (non-
ToIP)/Multimedia end user devices maintaining privacy.
8.11.2 Point-to-Point Call Scenarios
The point-to-point call scenarios will contain at least one or
both ToIP/Multimedia devices in setting up the session. The detail
call scenarios will include:
- ToIP/Multimedia devices that use the same language.
- ToIP/Multimedia devices invoke translation services for using
different languages.
* Third-party call control model.
* Conference bridge service model.
- ToIP/Multimedia devices invoke translation services for using
different languages maintaining privacy.
* Third-party call control model.
* Conference bridge service model.
- ToIP/Multimedia device and Audio (non-ToIP)/Multimedia device
invoking transcoding server.
* Call initiated by Audio (non-ToIP)/Multimedia user
- Third-party call control model.
- Conference bridge service model.
* Call initiated by ToIP user.
- Third-party call control model.
- Conference bridge service model.
- ToIP/Multimedia device and Audio (non-ToIP)/Multimedia device
invoking transcoding server maintaining privacy.
* Call initiated by Audio (non-ToIP)/Multimedia user
- Third-party call control model.
- Conference bridge service model.
* Call initiated by ToIP user.
- Third-party call control model.
- Conference bridge service model.
8.11.3 Conference Call Scenarios
The conference call scenarios only contain the multipoint
communications, and only the centralized bridge model is
considered. The following multipoint conference call scenarios
will contain at least one more ToIP/Multimedia devices:
- ToIP/Multimedia devices that use the same language.
- ToIP/Multimedia devices invoke translation services for using
different languages.
A. van Wijk [Page 20 of 37]
- ToIP/Multimedia devices invoke translation services for using
different languages maintaining privacy.
- ToIP/Multimedia device and Audio (non-ToIP)/Multimedia device
invoking transcoding server.
* Call initiated by Audio (non-ToIP)/Multimedia user.
* Call initiated by ToIP/Multimedia user.
- ToIP/Multimedia device and Audio (non-ToIP)/Multimedia device
invoking transcoding server maintaining privacy.
* Call initiated by Audio (non-ToIP)/Multimedia user.
* Call initiated by ToIP/Multimedia user.
9. Interworking Requirements for Text-over-IP
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 requirements on this
interoperability. interoperability, especially for the PSTN text telephony to ensure
full backward interoperability with ToIP.
9.1 Real-Time Text-over-IP 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. The simultaneous or alternating use of voice and text telephony.
text is used by a large number of users who can send voice, but
must receive text or who can hear but must send text due to a
speech disability.
9.2 Text-over-IP and PSTN/ISDN Text-Telephony 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
who can hear but must send text due to a speech disability.
A. van Wijk [Page 17 of 28]
7.2 ToIP and PSTN/ISDN Text-Telephony
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, DTMF, V.23 [III] and others. Many difficulties have
arisen as a result of this variety in text telephony protocols and arisen as a result of this variety in text telephony protocols and
the ITU-T V.18 [10] standard was developed to address some of the ITU-T V.18 [10] standard was developed to address some of
these issues. these issues.
ITU-T-V.18 [10] offers a native text telephony method plus it 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 Real-time Text- In order to allow systems and services based on ToIP to
over-IP to communicate with PSTN text telephones, text gateways communicate with PSTN text telephones, text gateways are the
are the recommended approach. These gateways MUST use the ITU-T recommended approach. These gateways MUST use the ITU-T V.18 [10]
V.18 [10] standard at the PSTN side. standard at the PSTN side.
Buffering MUST be used to support different transmission rates. At Buffering MUST be used to support different transmission rates. At
least 1K buffer MUST be provided. A buffer of at least 2K least 1K buffer MUST be provided. A buffer of at least 2K
characters is recommended. In addition, the gateway MUST provide a characters is RECOMMENDED. In addition, the gateway MUST provide a
A. van Wijk [Page 21 of 37]
minimum throughput of at least 30 characters/second or the highest minimum throughput of at least 30 characters/second or the highest
speed supported by the PSTN text telephony protocol side, speed supported by the PSTN text telephony protocol side,
whichever is the lowest. whichever is the lowest.
PSTN-Real-time Text-over-IP gateways MUST allow alternating use of PSTN-ToIP gateways MUST allow alternating use of text and voice.
text and voice.
PSTN and ISDN to real-time Text-over-IP gateways that receive CLI PSTN and ISDN to ToIP gateways that receive CLI information from
information from the originating party MUST pass this information the originating party MUST pass this information to the receiving
to the receiving party as soon as possible. party as soon as possible.
Priority MUST be given to calls labeled as emergency calls. Priority MUST be given to calls labeled as emergency calls.
9.3 Text-over-IP and Cellular Wireless circuit switched Text- 7.3 ToIP and Cellular Wireless circuit switched Text-Telephony
Telephony
Cellular wireless (or Mobile) circuit switched connections provide Cellular wireless (or Mobile) circuit switched connections provide
a digital real-time transport service for voice or data. a digital real-time transport service for voice or data.
The access technologies include GSM, CDMA, TDMA, iDen and various The access technologies include GSM, CDMA, TDMA, iDen and various
3G technologies. 3G technologies.
Alternative means of transferring the Text telephony data have Alternative means of transferring the Text telephony data have
been developed when TTY services over cellular was mandated by the been developed when TTY services over cellular was mandated by the
FCC in the USA. They are a) "No-gain" codec solution, b) the FCC in the USA. They are a) "No-gain" codec solution, b) the
Cellular Text Telephony Modem (CTM) solution and c) "Baudot mode" Cellular Text Telephony Modem (CTM) solution and c) "Baudot mode"
solution. solution.
The GSM and 3G standards from 3GPP make use of the CTM modem in The GSM and 3G standards from 3GPP make use of the CTM modem in
the voice channel for text telephony. the voice channel for text telephony.
However, implementations also exist that use the data channel to However, implementations also exist that use the data channel to
provide such functionality. Interworking with these solutions provide such functionality. Interworking with these solutions
SHOULD be done using text gateways that set up the data channel SHOULD be done using text gateways that set up the data channel
connection at the GSM side and provide real-time Text-over-IP at connection at the GSM side and provide ToIP at the other side.
the other side.
9.3.1 "No-gain" A. van Wijk [Page 18 of 28]
7.3.1 "No-gain"
The "No-gain" text telephone transporting technology uses The "No-gain" text telephone transporting technology uses
specially modified EFR [15] and EVR [16] speech vocoders in both specially modified EFR [15] and EVR [16] speech vocoders in both
mobile terminals used provide a text telephony call. It provides mobile terminals used to provide a text telephony call. It
full duplex operation and supports alternating voice and text.( provides full duplex operation and supports alternating voice and
"VCO/HCO"). It is dedicated to the CDMA and TDMA mobile text.( "VCO/HCO"). It is dedicated to the CDMA and TDMA mobile
technologies and the US Baudot type of text telephones. technologies and the US Baudot type of text telephones.
9.3.2 Cellular Text Telephone Modem (CTM) 7.3.2 Cellular Text Telephone Modem (CTM)
CTM [17] is a technology independent modem technology that CTM [17] is a technology independent modem technology that
provides the transport of text telephone characters at up to 10 provides the transport of text telephone characters at up to 10
characters/sec using modem signals that are at or below 1 kHz and characters/sec using modem signals that are at or below 1 kHz and
uses a highly redundant encoding technique to overcome the fading uses a highly redundant encoding technique to overcome the fading
and cell changing losses. On any interface that uses analog and cell changing losses. On any interface that uses analog
transmission, half-duplex operation must be supported as the transmission, half-duplex operation must be supported as the
"send" and "receive" modem frequencies are identical. The use of "send" and "receive" modem frequencies are identical. The use of
A. van Wijk [Page 22 of 37]
CTM may have to be modified slightly to support half-duplex CTM may have to be modified slightly to support half-duplex
operation. operation.
9.3.3 "Baudot mode" 7.3.3 "Baudot mode"
This term is often used by cellular terminal suppliers for a GSM This term is often used by cellular terminal suppliers for a GSM
cellular phone mode that allows TTYs to operate into a cellular cellular phone mode that allows TTYs to operate into a cellular
phone and to communicate with a fixed line TTY. phone and to communicate with a fixed line TTY.
9.3.4 Data channel mode 7.3.4 Data channel mode
Many mobile terminals allow the use of the data channel to Many mobile terminals allow the use of the data channel to
transfer data in real-time. Data rates of 9600 bit/s are usually transfer data in real-time. Data rates of 9600 bit/s are usually
supported on the mobile connection.Gateways or the interworking supported on the mobile network. Gateways or the interworking
function provides interoperability with PSTN textphones. function provides interoperability with PSTN textphones.
9.3.5 Common Text Gateway Functions 7.3.5 Common Text Gateway Functions
Text Gateways MUST cover the differences that result from Text gateways MUST cover the differences that result from
different text protocols. The protocols to be supported will different text protocols. The protocols to be supported will
depend on the service requirements of the Gateway. depend on the service requirements of the Gateway.
Different data rates of different protocols MAY require text Different data rates of different protocols MAY require text
buffering. buffering.
Interoperation of half-duplex and full-duplex protocols MAY Interoperation of half-duplex and full-duplex protocols MAY
require text buffering and some intelligence to determine when to require text buffering and some intelligence to determine when to
change direction when operating in half-duplex. change direction when operating in half-duplex.
Identification may be required of half-duplex operation either at Identification may be required of half-duplex operation either at
the "user" level (ie. users must inform each other) or at the the "user" level (ie. users must inform each other) or at the
"protocol" level (where an indication must be sent back to the "protocol" level (where an indication must be sent back to the
Gateway). Gateway).
A Text Gateway MUST be able to route text calls to emergency A. van Wijk [Page 19 of 28]
A text gateway MUST be able to route text calls to emergency
service providers when any of the recognised emergency numbers service providers when any of the recognised emergency numbers
that support text communications for the country or region are that support text communications for the country or region are
called eg. "911" in USA and "112" in Europe. 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 transparently on the IP side. It acts then A text gateway MUST act as a SIP User Agent on the IP side.
as a virtual end-point terminal.
9.4 Text-over-IP and Cellular Wireless Text-over-IP 7.4 ToIP and Cellular Wireless ToIP
Text-over-IP MAY be supported over the cellular wireless packet ToIP MAY be supported over the cellular wireless packet switched
switched service. It interfaces to the Internet. For 3GPP 3G service. It interfaces to the Internet. For 3GPP 3G services, the
services, the support is described to use ToIP in 3G TS 26.235 support is described to use ToIP in 3G TS 26.235 [20].
[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 into 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 are called.
A. van Wijk [Page 23 of 37] 7.5 Instant Messaging Support
9.5 Instant Messaging Support
Instant Messaging is used by many people to communicate using text Many people use Instant Messaging to communicate via the Internet
via the Internet. Instant Messaging transfers blocks of text using text. Instant Messaging transfers blocks of text rather than
rather than streaming as is used for real-time Text-over-IP. As streaming as is used by ToIP. As such, it is not a replacement for
such, it is not a replacement for real-time Text-over-IP and in ToIP and in particular does not meet the needs for real time
particular does not meet the needs for real time conversations of conversations of deaf, hard of hearing and speech-impaired users
deaf, hard of hearing and speech-impaired users. It is unsuitable as defined in RFC 3351 [21]. It is unsuitable for communications
for communications through a relay service [I]. The streaming through a relay service [I]. The streaming character of ToIP
character of real-time Text-over-IP provides a better user provides a better user experience and, when given the choice,
experience and, when given the choice, users often prefer real- users often prefer ToIP.
time Text-over-IP.
However, since some users might only have Instant Messaging However, since some users might only have Instant Messaging
available, text gateways might be developed that allow available, text gateways MAY be developed to allow interworking
interworking between Instant Messaging systems and real-time Text- between Instant Messaging systems and ToIP solutions.
over-IP solutions.
Because Instant Messaging is based on blocks of text, rather than Because Instant Messaging is based on blocks of text, rather than
on a continuous stream of characters, such gateways need to on a continuous stream of characters, such gateways need to
transform between these two formats. Text gateways for transform between these two formats. Text gateways for
interworking between Instant Messaging and real-time Text-over-IP interworking between Instant Messaging and ToIP MUST concatenate
MUST concatenate individual characters originating at the real- individual characters originating at the ToIP side into blocks of
time Text-over-IP side into blocks of text and: 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 MUST 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 character
is received from the real-time Text-over-IP side. is received from the ToIP side.
b. When a new line is received from the real-time Text-over-IP b. When a new line is received from the ToIP side, the buffered
side, the buffered characters up to that point, including the characters up to that point, including the carriage return and/or
carriage return and/or line feed characters, MUST be transmitted line feed characters, SHOULD be transmitted to the Instant
to the Instant Messaging side. Messaging side.
c. When the real-time Text-over-IP side has been idle for at least A. van Wijk [Page 20 of 28]
5 seconds, all buffered text up to that point MUST be transmitted c. When the ToIP side has been idle for at least 5 seconds, all
to the Instant Messaging side. buffered text up to that point SHOULD be transmitted to the
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.
For example, many Instant Messaging protocols signal that a user Many Instant Messaging protocols signal that a user is typing to
is typing to the other party in the conversation. Text gateways the other party in the conversation. Text gateways between such
between Instant Messaging and real-time Text-over-IP MUST provide Instant Messaging protocols and ToIP MUST provide this signaling
this signaling to the Instant Messaging side when characters start to the Instant Messaging side when characters start being
being received, or at the beginning of the conversation. received, or at the beginning of the conversation.
Also at the real-time text-over-IP side, an indicator of writing
the Instant Message MUST be present. For example, the real-time
text user will see . . . waiting for replying IM. . . And per 5
seconds a . (dot) can be shown.
Those solutions will reduce the difficulties between a streaming
versus blcoked text.
A. van Wijk [Page 24 of 37]
Even though that the text gateway can connect Instant Messaging
and real-time Text-over-IP. The best solution is to take advantage
of the fact that the user interfaces and the user communities for
instant messaging and real-time text-over-IP telephony are
extremely similar.
After all, the character input, the character display, Internet
connectivity, SIP stack, etc are the same for Instant Messaging
and real-time Text-over-IP.
Devices that implement Instant Messaging SHOULD implement real-
time text-over-IP telephony, using standard SIP and text/t140
mechanisms.
9.6 IP Telephony with Traditional RJ-11 Interfaces
Analogue adapters using SIP based IP communication and RJ-11
connectors for connecting traditional PSTN devices SHOULD enable
connection of legacy PSTN text telephones [18]. These adapters
SHOULD contain V.18 modem functionality, voice handling
functionality, and conversion functions to/from SIP based ToIP
with T.140 transported according to RFC 2793, in a similar way as
it provides interoperability for voice calls. If a 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 network at the end-
point), a method for invoking a transcoding server shall be used.
If no such server is available, the signals from the textphone MAY
be transmitted in the voice channel as audio with high quality of
service.
NOTE: It is preferred that such analogue adaptors do use RFC2793
on board and thus act as a text gateway. Sending textphone signals
over the voice channel is undesirable due posible filtering and
compression and packet loss between the end-points. Which can
result in dropping characters in the textphone conversation or
even not allowing the textphones to connect with each other.
9.7 Interworking Call Flows
The call scenarios in chapter 8.11 deal with end to end ToIP. At the ToIP side, an indicator of writing the Instant Message MUST
These call flows do not change on the IP side of the network when be present where the Instant Messaging protocol provides one. For
one end-point is actually a text gateway. The text gateway example, the real-time text user MAY see . . . waiting for
actually acts like a ToIP/Multimedia device. Separate call flows replying IM. . . And per 5 seconds that pass a . (dot) can be
will show the interworking between the ToIP/Multimedia devices [4] shown.
over the IP network and the text telephony devices [10] over the
PSTN/ISDN network using the IP-PSTN/ISDN interworking functional
(IWF) entity. It is assumed that the IWF will provide ToIP and
text telephony interworking in addition to other capabilities.
Thus acting as a Text gateway.
The point-to-point call flows will contain at least one Those solutions will reduce the difficulties between a streaming
ToIP/Multimedia and one text telephony/multimedia (or POTS) device versus blocked text.
for the following cases:
A. van Wijk [Page 25 of 37] Even though the text gateway can connect Instant Messaging and
- ToIP/Multimedia device and text telephony/multimedia device that ToIP, the best solution is to take advantage of the fact that the
use the same/different language. user interfaces and the user communities for instant messaging and
- ToIP/Multimedia device and PSTN/ISDN-based POTS/Multimedia ToIP telephony are extremely similar. After all, the character
device. input, the character display, Internet connectivity and SIP stack
are the same for Instant Messaging (SIMPLE) and ToIP.
For multipoint conferencing calls, it is assumed that only the Devices that implement Instant Messaging SHOULD implement ToIP as
centralized conferencing will be considered, and the media bridge described in this document.
is supposed to be located somewhere in the SIP network. However,
it is considered that the ToIP and text telephony interworking
function will be located in the IWF.
The multipoint conference call flows will contain at least one 7.6 IP Telephony with Traditional RJ-11 Interfaces
ToIP/Multimedia device, at least one text telephony/multimedia
device, and other devices where total number of devices will be
three or more for the following cases:
- ToIP/Multimedia and text telephony/multimedia devices that use Analogue adapters using SIP based IP communication and RJ-11
the same/different language. connectors for connecting traditional PSTN devices (ATA box)
- ToIP/Multimedia devices, telephony/multimedia devices, and/or SHOULD enable connection of legacy PSTN text telephones [18].
PSTN/ISDN-based POTS/Multimedia devices. These adapters SHOULD contain V.18 modem functionality, voice
handling functionality, and conversion functions to/from SIP based
ToIP with T.140 transported according to RFC 4103 [5], in a
similar way as it provides interoperability for voice calls. If a
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
network at the end-point), a method for invoking a transcoding
server shall be used. If no such server is available, the signals
from the textphone MAY be transmitted in the voice channel as
audio with high quality of service.
NOTE: It is preferred that such analogue adaptors do use RFC 4103
[5] on board and thus act as a text gateway. Sending textphone
signals over the voice channel is undesirable due to possible
filtering and compression and packet loss between the end-points.
This can result in dropping characters in the textphone
conversation or even not allowing the textphones to connect with
each other.
9.8 Multi-functional gateways A. van Wijk [Page 21 of 28]
7.7 Multi-functional gateways
The scenarios described in this document deal with single pairs of In practice many interworking gateways will be implemented as
interworking protocols or services. However, in practice many of gateways that combine different functions. As such, a text gateway
these interworking systems will be implemented as gateways that could be build to have modems to interwork with the PSTN and
combine different functions. As such, a text gateway could be support both Instant Messaging as well as ToIP. Such interworking
build to have modems to interwork with the PSTN and support both
Instant Messaging as well as real-time 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.
9.9 Gateway Discovery 7.8 ToIP interoperability with PSTN text telephones.
To get a smooth invocation of the text gateways, where those Gateways between the ToIP network and other networks MAY need to
gateways are transparant on the IP side, it requires a method how transcode text streams. ToIP makes use of the ISO 10646 character
and when to invoke the text gateway. As described previously in set. Most PSTN textphones use a 7-bit character set, or a
this draft. The text gateways must act as the end-terminal. The character set that is converted to a 7-bit character set by the
capabilities of the text gateway will in that call be determined V.18 modem.
by the call capabilities of the terminal that is using the
gateway. For example, a PSTN textphone is only able to receive
A. van Wijk [Page 26 of 37] When transcoding between character sets and T.140 in gateways,
voice and streaming text. Thus the text gateway will only allow special consideration MUST be given to the national variants of
ToIP and audio. the 7 bit codes, with national characters mapping into different
codes in the ISO 10 646 code space. The national variant to be
used could be selectable by the user on a per call basis, or be
configured as a national default for the gateway.
The PSTN devices or other non IP multimedia devices that require The missing text indicator in T.140, specified in T.140 amendment
the text gateways to connect to the IP must be able to locate the 1, cannot be represented in the 7 bit character codes. Therefore
text gateway, and ensure that the correct call capabilities of the these characters SHOULD be transcoded to the ' (apostrophe)
non IP multimedia device is used by the text gateway. character in legacy text telephone systems, where this character
exists. For legacy systems where the character ' does not exist,
the . ( full stop ) character SHOULD be used instead.
The following possible solutions for using the text gateway are: 7.9 Gateway Discovery
- PSTN Textphone users using a prefix number before dialing out. ToIP requires a method to invoke a text gateway. As described
- In band text dialogue, where the gateway asks the user for the previously in this draft, these text gateways MUST act as User
destination address. Agents at the IP side. The capabilities of the text gateway during
- separate text subscriptions, linked to the phone number or 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
are:
A. van Wijk [Page 22 of 28]
- PSTN textphone users dial a prefix number before dialing out.
- Separate text subscriptions, linked to the phone number or
terminal identifier/ IP address. terminal identifier/ IP address.
- text capability indicators. - Text capability indicators.
- text preference indicator. - Text preference indicator.
- listen for text activity in all calls. - Listen for V.18 modem modulation text activity in all calls.
- call transfer request by the called user. - Call transfer request by the called user.
- placing a call via the web, and use one of the methods described - Placing a call via the web, and using one of the methods
here described here
- text gateways with its own telephone number and/or SIP address. - Text gateways with its own telephone number and/or SIP address.
(this requires user interaction with the text gateway to place a (This requires user interaction with the text gateway to place a
call). call).
- ENUM address analysis and number plan - ENUM address analysis and number plan
- number or address analysis leads to the gateway for all PSTN - Number or address analysis leads to the gateway for all PSTN
calls.
- etc
9.10 Text Gateway in the call Scenarios
9.10.1 IP terminal calling an analogue textphone (PSTN)
The ToIP stream will be converted into an analogue text telephone
protocol (using the voice channel) and vice versa by the text
gateway.
The PSTN knows that it may be a textphone call thanks to the SDP
description (for example: m=text 11000 RTP/AVP 98 a=rtpmap:98
t140/1000 for T.140 text on port 11000). It can then activate text
gateway functions on the PSTN side listening for a text answer.
The PSTN will also know that all those incoming calls are only for
analogue textphones. Thus the speed of the text stream is adjusted
to the selected analogue textphone protocol.
If there is no analogue textphone on the called number, the call
setup will be terminated by the text gateway.
The text gateway can be implemented in two ways: The PSTN has its
own text gateway (the IWF), or it redirects the media stream to
the nearest IP-PSTN gateway with text transcoding abilities.
Text gateway detection: In the SIP messages.
A. van Wijk [Page 27 of 37]
9.10.2 IP terminal calling a mobile text telephone (CTM)
The ToIP stream will be converted into CTM and vice versa by the
text gateway located in the network of the cellular/mobile
operator. It is similar to the PSTN.
Text gateway detection: In the SIP messages.
9.10.3 IP terminal calling a mobile telephone (GPRS based)
A text gateway located in the mobile network converts the incoming
T.140/RTP stream into for example T.140 over TCP (T.140/TCP) or
tunnels the T.140 stream over HTTP (T.140/HTTP). Or any other
temporarily non standard solution necessary to connect the text
gateway with the text telephone client on the mobile phone.
This is necessary, since RTP over GPRS is not possible in many
mobile phones.
Note, those server-client solutions are ONLY acceptable for the
GPRS and non RTP stack phones. It is encouraged to use T.140/RTP
as soon as possible for all mobile phones.
Allowing UDP transport over the GPRS link will enable RFC2793 text
over GPRS.
Text gateway detection: In the SIP messages.
9.10.4 IP terminal calling a mobile telephone(UMTS)
No text gateway is required here since this will be end to end IP.
9.10.5 Analogue textphone (PSTN) user calling an IP terminal using
prefix
The PSTN is unable to distinguish between an analogue voice call
and an analogue textphone, both use the voice channel. The text
gateway needs to transcode the analogue textphone protocol into
T.140/RTP.
One way for a PSTN to separate an incoming voice call into text
telephony or normal voice is by using a prefix number for all
incoming text telephone calls to the PSTN. For example , the text
telephone user (e.g Boudot) places a call and enters a prefix e.g.
600 and then continues with the original number. The PSTN will
recognize all incoming 600 calls as an analogue textphone call and
redirects the call to a text gateway (unless it is a number
connecting the same PSTN).
It is undesirable to allow a PSTN to transport all the analogue
textphone tones/signals through a VoIP stream! (In band text
dialogue).
A. van Wijk [Page 28 of 37]
Text gateway detection: Prefix number for incoming textphone
calls. calls.
9.10.6 Mobile text telephone (CTM) user calling an IP terminal 8. Afterword
The voice channel of the cellular network is used. The MSC is able
to separate between the text call and voice only, it is just a
matter of redirecting the voice channel to the text gateway.
Text gateway detection: CTM signal detection.
9.10.7 Mobile telephone user (GPRS) calling an IP terminal
The text telephone client on the mobile telephone connects the
text gateway located in the network. The text gateway transcodes
the text stream into ToIP.
Text gateway detection: pre-programmed in the mobile textphone
client.
9.10.8 Mobile telephone (UMTS) user calling an IP terminal
No text gateway is required here since this will be end to end IP.
9.10.9 Voice over DSL user using an analogue text telephone.
Voice over DSL is a widespread service. When connecting analogue
text telephones to this service there is a risk that they just use
the voice channel that result in corrupted text transmission. The
VoDSL gateway located in the network of the (A)DSL operator itself
should connect with a text gateway as soon it turns into VoIP.
Text gateway detection: prefix number similar to the PSTN.
9.10.10 VoIP user via a building telephone switch (at an apartment
building) owning an analogue text telephone.
This is the case where only VoIP is possible and no other IP
traffic between the telephone switch and the apartments.
The only solution would be a forced analogue text telephone
protocol over the Voice channel, in band text dialogue . If that
must happen. Then the telephone switch MUST convert the analogue
text telephone protocol into ToIP and vice versa before the
telephone switch connects the IP network.
Note: The in band text dialogue is undesirable. This scenario
SHOULD be avoided at any cost.
Text gateway detection: prefix number or in band text signalling.
9.10.11 VoIP user via a gateway/box connected to his/her own
Broadband connection owning an analogue text telephone.
A. van Wijk [Page 29 of 37]
The gateway box should natively transcode analogue text telephony
into ToIP and vice versa when an analogue text phone is plugged in
the RJ-11 socket [18].
Text gateway detection: RJ-11 socket preconfigured by the box via
jumpers or software, or listen for textphone tones and perform
V.18 text telephone detection.
10. Terminal Features
Implementers of products that support interactive Text-over-IP
SHOULD NOT assume that all users of text are able to use
mainstream input and output devices. People with arthritis or
other dexterity problems might not be able to use very small
keyboards. Visually impaired people might not be able to use
standard sized characters on a display. Colour-blind people might
suffer from badly chosen colour-schemes. People with motor
disabilities might require specialised input devices.
Implementers SHOULD make their products as open as possible with
regard to this wide range of abilities and preferences and they
MUST use standard interfaces wherever they provide such
interfaces.
10.1 Text input
Systems that support real-time interactive Text-over-IP SHOULD
support suitable input mechanisms, either built-in or connectable
through the use of a standard interface: PS/2, USB, Bluetooth, or
virtual keyboard. In particular Braille users should be able to
connect Braille keyboards to the terminal. Terminals MAY support a
web interface for input and output of text.
It is recommended that systems that fixed terminals that support
real-time interactive Text-over-IP allow the user to enter the
standard alphanumerical characters directly, rather than through a
cycle of key presses or other indirect means. This could be done
using full-sized keyboards, smaller sized keyboards or fastap
keyboards for example. It is highly recommended to provide a
standard interface to allow attachment of an external input
device, especially for terminals that have only limited input
systems built-in.
Systems should provide means to add voice-to-text translation as
text input.
All IP phones with a display of 12 or more characters MUST support
at least text input through the regular phone keypad (and display
of any incoming text) in order to provide basic emergency text
communication from any IP phone.
A. van Wijk [Page 30 of 37]
Input devices that have automatic key repeat MUST allow the user
to specify the key-repeat rate.
10.2 Text presentation
Systems that support real-time interactive Text-over-IP SHOULD
support suitable displays, either built-in or connectable through
the use of a standard interface: S-VGA, USB, Bluetooth or IP.
Braille readers should be connectable to the terminal using a
standard interface.
Terminals MAY support a web interface for input and output of
text.
A variety of handsets and terminals might be developed for a
number of equally varied scenarios.
In the case of fixed terminals or software applications on
Personal Computers, implementers MUST:
a. Use either separate screen areas for displaying sent and
received text OR clearly indicate the difference between sent and
received text. Systems MAY allow the user to chose either on of
these presentation methodologies.
b. Provide at least 5 lines of 35 monospaced characters each for
each direction (sent and received text) OR at least 10 lines of 35
characters when sent and received text are presented together.
In the case of Mobile terminals, implementers MUST:
c. Use either separate screen areas for displaying sent and
received text OR clearly indicate the difference between sent and
received text. Systems MAY allow the user to chose either on of
these presentation methodologies.
d. Provide at least 3 lines of 20 monospaced characters each for
each direction (sent and received text) OR at least 6 lines of 20
characters when sent and received text are presented together.
On both types of terminals, scrolling back through both sent and
received text MUST be supported, even after the conversation has
ended. Lines SHOULD be wrapped at word boundaries .
There MUST be an easy-to-use function to clear the screen at any
time during the session, and if the implementation has chosen to
present sent and received text separately, clearing the screen
SHOULD be possible as a separate function for sent and received
text.
The function of the new line and erasure controls as explained in
section 9.5. MUST be supported by the presentation in the
A. van Wijk [Page 31 of 37]
consistent way described by T.140. Presentation layers MUST
support the full UTF-8 character set.
When real-time Text-over-IP is used in conjunction with other
modalities, like voice, the presentation MUST clearly indicate
this to the user in an area outside the display region for send
and received text.
Identification information for other parties in the conversation,
like URLĂs, user-friendly names from an address book, or CLI in
the case of conversations with text telephones, SHOULD be
displayed throughout the entire conversation in a region outside
the sent and received text area.
10.3 Call control
Call (Session) Control procedures MUST use the SIP protocol. Text
sessions MUST be identified in accordance with requirements
described earlier.
Text services SHOULD be part of a Total Conversation environment
in which voice, text and video sessions can be added, modified or
deleted individually.
To enable interworking with Textphones in telephone and cellular
(mobile) networks, terminals MUST be able to access Gateways
automatically when a PSTN or cellular (mobile) E.164-based
telephone number is used as the called address.
Users MUST be able to establish text sessions to emergency service
providers using the widely recognised emergency numbers in use in
the country or region of operation of the terminal eg. Š911Ă in
USA and │112│in Europe.
The ability to transfer Location information SHALL be provided if
the information is available from the terminal.
10.4 Device control
ToIP devices shall support multiple means of setting up and
performing calls as well as controlling the device itself. The
built-in controls and presentation systems shall take
accessibility aspects into account as far as possible. The device
shall include external interfaces that makes it possible to attach
user interface devices for people with needs beyond what the
built-in user interface can support. It is preferrable if such
external interfaces are wireless.
10.5 Alerting
A. van Wijk [Page 32 of 37]
The form of Alerting indication(s) provided to the user should be
selectable to suit particular users. Alerting indications MAY
include Sound, Tactile (eg. vibrational), Visual (on-screen
symbols; separate flashing light), Motion (eg. movement of
something).
The ability to send an Alerting signal to an external interface
SHOULD be provided. This will allow Alerting devices that are
specific to users requirements to be attached.
As many as possible of the following alternatives for alerting
SHOULD be provided:
* Internal flash.
* Two-pole connector for external alerting systems triggered
by contact between the two poles when a ring signal is generated
(if necessary with 1.5-9 V battery power for alerting systems
requiring electrical currents to activate).
* Bluetooth serial profile with AT command interface, sending
the "RING" message, intended for a Bluetooth alerting receiver
with flash, vibration or sound action.
* SIP connected alerting device, that get its stimuli by being
registered on the same sip address as the terminal.
10.6 External interfaces
Terminals for ToIP SHOULD provide external interfaces for the The authors want to make it clear that ToIP is a way of allowing
following functions: real-time, interactive text conversation between all users and is
* Text input. thus not only for the hearing and speech impaired users.
* Text display.
* Terminal control.
* Session control.
10.7 Power The users may invoke the ToIP services for many different reasons.
For example:
As terminals could remain active for very long periods of time, - Noisy environment (e.g., in a machine room of a factory where
the electrical power requirements of all the terminals SHOULD be listening is difficult)
as low as possible. - 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.
If the terminal is to be used for calling Emergency services or NOTE: In many of the above examples, text may accompany speech and
where the mains power supply is unreliable, back-up power systems could be displayed in a manner similar to subtitling in
SHOULD be provided for the terminal and all equipment used to broadcasting environments or any other suitable manner. This
provide the ToIP service. This can be implemented in many could occur for individuals who are hard of hearing and also for
different ways eg. via the line powering option on some Ethernet mixed calls with a hearing and deaf person listening to the call.
interfaces, or by using a "no break" power supply (a battery back-
up system with inverters that can recreate a limited amount of
mains power).
11. Security Considerations 9. Security Considerations
There are no additional security requirements other than described There are no additional security requirements other than described
earlier. earlier.
12. Outstanding issues A. van Wijk [Page 23 of 28]
10. Authors Addresses
A. van Wijk [Page 33 of 37]
A number of outstanding issues yet need to be resolved. This is
possible in this draft, or in a separate draft.
- Call flows diagrams based on the scenarios discussed in this
draft.
- Service labelling of media streams to be able to determine which
kind of service the text stream contains. For example, is it
english, spanish text? Is it an emergency text stream? Etc.
13. 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
TNO Informatie- en Communicatietechnologie
Postbus 15000
9700 CD Groningen
The Netherlands
Tel: +31 50 585 77 24
Fax: +31 50 585 77 57
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 Fax +61 (0)2 9954 6136
TTY +61 (0)2 9923 1911 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
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
EMail: guido.gybels@rnid.org.uk Email: guido.gybels@rnid.org.uk
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
Radhika R. Roy
AT&T
Room C1-2B03
200 Laurel Avenue S.
Middletown, NJ 07748
USA
Phone: +1 732 420 1580
Fax: +1 732 368 1302
Email: rrroy@att.com
Henry Sinnreich Henry Sinnreich
pulver.com
115 Broadhollow Rd
Suite 225
Melville, NY 11747
USA
Tel: +1.631.961.8950
A. van Wijk [Page 34 of 37] A. van Wijk [Page 24 of 28]
MCI
400 International Parkway
Richardson, Texas 75081
Email: henry.sinnreich@mci.com
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 gv@trace.wisc.edu
Phone +1 608 262-6966 Phone +1 608 262-6966
FAX +1 608 262-8848 FAX +1 608 262-8848
Arnoud A. T. van Wijk Arnoud A. T. van Wijk
Viataal (Dutch Institute for the Deaf) Viataal (Dutch Institute for the Deaf)
Research & Development Research & Development
Afdeling RDS 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
14. Acknowledgements 11. References
The authors wish to thank Snowshore for providing the ToIP mailing
list, which allows many discussions necessary for this draft.
15. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
16. References
16.1 Normative 11.1 Normative
1. Bradner, S., "The Internet Standards Process -- Revision 3", 1. Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996. BCP 9, RFC 2026, October 1996.
2. Bradner, S., "Key words for use in RFCs to Indicate Requirement 2. Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997 Levels", BCP 14, RFC 2119, March 1997
A. van Wijk [Page 35 of 37]
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 2793, May 5. G. Hellstrom, "RTP Payload for Text Conversation, RFC 4103,
2000. 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.
7. G.Camarillo, "Framework for Transcoding with the Session 7. G.Camarillo, "Framework for Transcoding with the Session
Initiation Protocol" IETF august 2003 - 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 Service Invocation in SIP using Third Party Call "Transcoding Services Invocation in the Session Initiation
Control," IETF, September 2004 - Work in Progress. Protocol (SIP) Using Third Party Call Control (3pcc)" RFC 4117,
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.
skipping to change at line 1935 skipping to change at line 1355
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 16. 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" 17. 3GPP TS26.226 "Cellular Text Telephone Modem Description"
(CTM). (CTM).
A. van Wijk [Page 36 of 37]
18. I. Butcher, S. Lass, D. Petrie, H. Sinnreich, and C. 18. I. Butcher, S. Lass, D. Petrie, H. Sinnreich, and C.
Stredicke, "SIP Telephony Device Requirements, Configuration and Stredicke, "SIP Telephony Device Requirements, Configuration and
Data," IETF, February 2004- Work in Progress. Data," IETF, February 2004- Work in Progress.
19 Baugher, McGrew, Carrara, Naslund, Norrman, "The Secure Real- 19. Baugher, McGrew, Carrara, Naslund, Norrman, "The Secure Real
Time Transport Protocol (SRTP)", RFC 3711, March 2004. Time Transport Protocol (SRTP)", RFC 3711, IETF, March 2004.
20. IP Multimedia default codecs. 3GPP TS 26.235 20. IP Multimedia default codecs. 3GPP TS 26.235
16.2 Informative 21. Charlton, Gasson, Gybels, Spanner, van Wijk, "User
Requirements for the Session Initiation Protocol (SIP) in Support
of Deaf, Hard of Hearing and Speech-impaired Individuals", RFC
3351, IETF, August 2002.
22. J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the
Session Description Protocol (SDP)", RFC 3624, IETF, June 2002.
A. van Wijk [Page 26 of 28]
11.2 Informative
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. 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 IV. Third Generation Partnership Project (3GPP), "Technical
Specification Group Services and System Aspects; Cellular Text Specification Group Services and System Aspects; Cellular Text
Telephone Modem; General Description (Release 5)". 3GPP TS 26.226 Telephone Modem; General Description (Release 5)". 3GPP TS 26.226
V5.0.0, V5.0.0.
A. van Wijk [Page 37 of 37] Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
A. van Wijk [Page 27 of 28]
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
A. van Wijk [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/