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

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