draft-ietf-sipping-toip-07.txt   draft-ietf-sipping-toip-08.txt 
SIPPING Workgroup A. van Wijk, Editor SIPPING Workgroup A. van Wijk, Editor
Internet Draft G. Gybels, Editor Internet Draft G. Gybels, Editor
Category: Informational August 30, 2006 Category: Informational October 19, 2007
Expires: March 3, 2007 Expires: April 21, 2008
Framework for real-time text over IP using the Session Initiation Framework for real-time text over IP using the Session Initiation
Protocol (SIP) Protocol (SIP)
draft-ietf-sipping-toip-07.txt draft-ietf-sipping-toip-08.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 have applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware 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. will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 10, line ? skipping to change at page 10, line ?
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 3, 2007. This Internet-Draft will expire on April 21, 2008.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document lists the essential requirements for real-time Text- This document lists the essential requirements for real-time Text-
over-IP (ToIP) and defines a framework for implementation of all over-IP (ToIP) and defines a framework for implementation of all
required functions based on the Session Initiation Protocol (SIP) and required functions based on the Session Initiation Protocol (SIP) and
the Real-Time Transport Protocol (RTP). This includes interworking the Real-Time Transport Protocol (RTP). This includes interworking
between Text-over-IP and existing text telephony on the PSTN and other between Text-over-IP and existing text telephony on the PSTN and other
networks. networks.
Table of Contents Table of Contents
1. Introduction....................................................2 1. Introduction....................................................2
2. Scope...........................................................3 2. Scope...........................................................3
3. Terminology.....................................................3 3. Terminology.....................................................3
4. Definitions.....................................................4 4. Definitions.....................................................4
5. Requirements....................................................6 5. Requirements....................................................6
5.1 General requirements for ToIP................................6 5.1 General requirements for ToIP................................6
5.2 Detailed requirements for ToIP...............................7
van Wijk, et al. Expires March 3, 2007 [Page 1] van Wijk, et al. Expires April 21, 2008 [Page 1]
5.2 Detailed requirements for ToIP...............................7
5.2.1 Session set-up and control requirements..................7 5.2.1 Session set-up and control requirements..................7
5.2.2 Transport requirements...................................8 5.2.2 Transport requirements...................................8
5.2.3 Transcoding service requirements.........................9 5.2.3 Transcoding service requirements.........................9
5.2.4 Presentation and User control requirements..............10 5.2.4 Presentation and User control requirements..............10
5.2.5 Interworking requirements...............................11 5.2.5 Interworking requirements...............................11
5.2.5.1 PSTN Interworking requirements......................12 5.2.5.1 PSTN Interworking requirements......................12
5.2.5.2 Cellular Interworking requirements..................12 5.2.5.2 Cellular Interworking requirements..................12
5.2.5.3 Instant Messaging Interworking requirements.........12 5.2.5.3 Instant Messaging Interworking requirements.........12
6. Implementation Framework.......................................13 6. Implementation Framework.......................................13
6.1 General implementation framework............................13 6.1 General implementation framework............................13
skipping to change at page 10, line ? skipping to change at page 10, line ?
6.2.4.1 Progress and status information.....................16 6.2.4.1 Progress and status information.....................16
6.2.4.2 Alerting............................................16 6.2.4.2 Alerting............................................16
6.2.4.3 Text presentation...................................16 6.2.4.3 Text presentation...................................16
6.2.4.4 File storage........................................16 6.2.4.4 File storage........................................16
6.2.5 Interworking functions..................................16 6.2.5 Interworking functions..................................16
6.2.5.1 PSTN Interworking...................................18 6.2.5.1 PSTN Interworking...................................18
6.2.5.2 Mobile Interworking.................................19 6.2.5.2 Mobile Interworking.................................19
6.2.5.2.1 Cellular "No-gain"..............................19 6.2.5.2.1 Cellular "No-gain"..............................19
6.2.5.2.2 Cellular Text Telephone Modem (CTM).............19 6.2.5.2.2 Cellular Text Telephone Modem (CTM).............19
6.2.5.2.3 Cellular "Baudot mode"..........................19 6.2.5.2.3 Cellular "Baudot mode"..........................19
6.2.5.2.4 Mobile data channel mode........................19 6.2.5.2.4 Mobile data channel mode........................20
6.2.5.2.5 Mobile ToIP.....................................20 6.2.5.2.5 Mobile ToIP.....................................20
6.2.5.3 Instant Messaging Interworking......................20 6.2.5.3 Instant Messaging Interworking......................20
6.2.5.4 Multi-functional Combination gateways...............21 6.2.5.4 Multi-functional Combination gateways...............21
6.2.5.5 Character set transcoding...........................21 6.2.5.5 Character set transcoding...........................21
7. Further recommendations for implementers and service providers.22 7. Further recommendations for implementers and service providers.22
7.1 Access to Emergency services................................22 7.1 Access to Emergency services................................22
7.2 Home Gateways or Analog Terminal Adapters...................22 7.2 Home Gateways or Analog Terminal Adapters...................22
7.3 User Mobility...............................................23 7.3 User Mobility...............................................23
7.4 Firewalls and NATs..........................................23 7.4 Firewalls and NATs..........................................23
7.5 Quality of Service..........................................23 7.5 Quality of Service..........................................23
8. IANA Considerations............................................23 8. IANA Considerations............................................23
9. Security Considerations........................................23 9. Security Considerations........................................23
10. Authors' Addresses.............................................23 10. Authors' Addresses.............................................24
11. Contributors...................................................24 11. Contributors...................................................24
12. References.....................................................24 12. References.....................................................24
12.1 Normative references........................................24 12.1 Normative references........................................24
12.2 Informative references......................................26 12.2 Informative references......................................26
1. Introduction 1. Introduction
For many years, real-time text has been in use as a medium for For many years, real-time text has been in use as a medium for
conversational, interactive dialogue between users in a similar way conversational, interactive dialogue between users in a similar way
to how voice telephony is used. Such interactive text is different to how voice telephony is used. Such interactive text is different
from messaging and semi-interactive solutions like Instant Messaging
van Wijk, et al. Expires March 3, 2007 [Page 2] van Wijk, et al. Expires April 21, 2008 [Page 2]
from messaging and semi-interactive solutions like Instant Messaging
in that it offers an equivalent conversational experience to users in that it offers an equivalent conversational experience to users
who cannot, or do not wish to, use voice. It therefore meets a who cannot, or do not wish to, use voice. It therefore meets a
different set of requirements from other text-based solutions already different set of requirements from other text-based solutions already
available on IP networks. available on IP networks.
Traditionally, deaf, hard of hearing and speech-impaired people are Traditionally, deaf, hard of hearing and speech-impaired people are
amongst the most prolific users of real-time, conversational, amongst the most prolific users of real-time, conversational,
text but, because of its interactivity, it is becoming popular amongst text but, because of its interactivity, it is becoming popular amongst
mainstream users as well. Real-time text conversation can be combined mainstream users as well. Real-time text conversation can be combined
with other conversational media like video or voice. with other conversational media like video or voice.
This document describes how existing IETF protocols can be used to This document describes how existing IETF protocols can be used to
implement a Text-over-IP solution (ToIP). This ToIP framework is implement a Text-over-IP solution (ToIP). This ToIP framework is
specifically designed to be compatible with Voice-over-IP (VoIP), specifically designed to be compatible with Voice-over-IP (VoIP),
Video-over-IP and Multimedia-over-IP (MoIP) environments, as well as Video-over-IP and Multimedia-over-IP (MoIP) environments. This ToIP
meeting the requirements of deaf, hard of hearing and speech-impaired framework also builds upon, and is compatible with, the high-level
users as described in RFC3351 [2] and of mainstream users. user requirements of deaf, hard of hearing and speech-impaired users
as described in RFC3351 [I]. It also meets real-time text
requirements of mainstream users.
ToIP also offers an IP equivalent of analog text telephony services as ToIP also offers an IP equivalent of analog text telephony services as
used by deaf, hard of hearing, speech-impaired and mainstream users. used by deaf, hard of hearing, speech-impaired and mainstream users.
The Session Initiation Protocol (SIP) [3] is the protocol of choice The Session Initiation Protocol (SIP) [2] is the protocol of choice
for control of Multimedia communications and Voice-over-IP (VoIP) in for control of Multimedia communications and Voice-over-IP (VoIP) in
particular. It offers all the necessary control and signalling particular. It offers all the necessary control and signalling
required for the ToIP framework. required for the ToIP framework.
The Real-Time Transport Protocol (RTP) [4] is the protocol of choice The Real-Time Transport Protocol (RTP) [3] is the protocol of choice
for real-time data transmission, and its use for real-time text for real-time data transmission, and its use for real-time text
payloads is described in RFC4103 [5]. payloads is described in RFC4103 [4].
This document defines a framework for ToIP to be used either by itself This document defines a framework for ToIP to be used either by itself
or as part of integrated, multi-media services, including Total or as part of integrated, multi-media services, including Total
Conversation [6]. Conversation [5].
2. Scope 2. Scope
This document defines a framework for the implementation of real-time This document defines a framework for the implementation of real-time
ToIP, either stand-alone or as a part of multimedia services, ToIP, either stand-alone or as a part of multimedia services,
including Total Conversation [6]. It provides the: including Total Conversation [5]. It provides the:
a. requirements for real-time text; a. requirements for real-time text;
b. requirements for ToIP interworking; b. requirements for ToIP interworking;
c. description of ToIP implementation 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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14, RFC 2119 [7] and indicate requirement levels for compliant
implementations.
van Wijk, et al. Expires March 3, 2007 [Page 3] van Wijk, et al. Expires April 21, 2008 [Page 3]
RFC 2119 [6] and indicate requirement levels for compliant
implementations.
4. Definitions 4. Definitions
Audio bridging: a function of an audio media bridge server, gateway or Audio bridging: a function of an audio media bridge server, gateway or
relay service that sends to each destination the combination of audio relay service that sends to each destination the combination of audio
from all participants in a conference excluding the participant(s) at from all participants in a conference excluding the participant(s) at
that destination. At the RTP level, this is an instance of the mixer that destination. At the RTP level, this is an instance of the mixer
function as defined in RFC 3550 [4]. function as defined in RFC 3550 [3].
Cellular: a telecommunication network that has wireless access and can Cellular: a telecommunication network that has wireless access and can
support voice and data services over very large geographical areas. support voice and data services over very large geographical areas.
Also called Mobile. Also called Mobile.
Full duplex: media is sent independently in both directions. Full duplex: media is sent independently in both directions.
Half duplex: media can only be sent in one direction at a time or, Half duplex: media can only be sent in one direction at a time or,
if an attempt to send information in both directions is made, errors if an attempt to send information in both directions is made, errors
may be introduced into the presented media. may be introduced into the presented media.
Interactive text: another term for real-time text, as defined below. Interactive text: another term for real-time text, as defined below.
Real-time text: a term for real time transmission of text in a Real-time text: a term for real time transmission of text in a
character-by-character fashion for use in conversational services, character-by-character fashion for use in conversational services,
often as a text equivalent to voice based conversational services. often as a text equivalent to voice based conversational services.
Conversational text is defined in the ITU-T Framework for multimedia Conversational text is defined in the ITU-T Framework for multimedia
services, Recommendation F.700 [25]. services, Recommendation F.700 [21].
Text gateway: a function that transcodes between different forms of Text gateway: a function that transcodes between different forms of
text transport methods, e.g., between ToIP in IP networks and Baudot text transport methods, e.g., between ToIP in IP networks and Baudot
or ITU-T V.21 text telephony in the PSTN. or ITU-T V.21 text telephony in the PSTN.
Textphone: also "text telephone". A terminal device that allows end- Textphone: also "text telephone". A terminal device that allows end-
to-end real-time text communication using analog transmission. A to-end real-time text communication using analog transmission. A
variety of PSTN textphone protocols exists world-wide. A textphone can variety of PSTN textphone protocols exists world-wide. A textphone can
often be combined with a voice telephone, or include voice often be combined with a voice telephone, or include voice
communication functions for simultaneous or alternating use of text communication functions for simultaneous or alternating use of text
skipping to change at page 10, line ? skipping to change at page 10, line ?
audio bridging as defined above, except that text is the medium of audio bridging as defined above, except that text is the medium of
conversation. conversation.
Text relay service: a third-party or intermediary that enables Text relay service: a third-party or intermediary that enables
communications between deaf, hard of hearing and speech-impaired communications between deaf, hard of hearing and speech-impaired
people and voice telephone users by translating between voice and people and voice telephone users by translating between voice and
real-time text in a call. real-time text in a call.
Text telephony: analog textphone service. Text telephony: analog textphone service.
van Wijk, et al. Expires April 21, 2008 [Page 4]
Total Conversation: a multimedia service offering real time Total Conversation: a multimedia service offering real time
conversation in video, real-time text and voice according to conversation in video, real-time text and voice according to
van Wijk, et al. Expires March 3, 2007 [Page 4]
interoperable standards. All media streams flow in real time. (See interoperable standards. All media streams flow in real time. (See
ITU-T F.703 "Multimedia conversational services" [6].) ITU-T F.703 "Multimedia conversational services" [5].)
Transcoding service: a service provided by a third-party User Agent Transcoding service: a service provided by a third-party User Agent
that transcodes one stream into another. Transcoding can be done by that transcodes one stream into another. Transcoding can be done by
human operators, in an automated manner, or by a combination of both human operators, in an automated manner, or by a combination of both
methods. Within this document the term particularly applies to methods. Within this document the term particularly applies to
conversion between different types of media. A text relay service is conversion between different types of media. A text relay service is
an example of a transcoding service that converts between real-time an example of a transcoding service that converts between real-time
text and audio. text and audio.
TTY: originally, an abbreviation for "teletype". Often used in North TTY: originally, an abbreviation for "teletype". Often used in North
skipping to change at page 10, line ? skipping to change at page 10, line ?
SRTP Secure Real Time Transport Protocol SRTP Secure Real Time Transport Protocol
TDD Telecommunication Device for the Deaf TDD Telecommunication Device for the Deaf
TDMA Time Division Multiple Access TDMA Time Division Multiple Access
TTY Analog textphone (Teletypewriter) TTY Analog textphone (Teletypewriter)
ToIP Real-time Text over Internet Protocol ToIP Real-time Text over Internet Protocol
URI Uniform Resource Identifier URI Uniform Resource Identifier
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
van Wijk, et al. Expires March 3, 2007 [Page 5] van Wijk, et al. Expires April 21, 2008 [Page 5]
5. Requirements 5. Requirements
The framework described in section 6 defines a real-time text-based The framework described in section 6 defines a real-time text-based
conversational service that is the text equivalent of voice based conversational service that is the text equivalent of voice based
telephony. This section describes the requirements that the framework telephony. This section describes the requirements that the framework
is designed to meet and the functionality it should offer. is designed to meet and the functionality it should offer.
5.1 General requirements for ToIP 5.1 General requirements for ToIP
Any framework for ToIP must be designed to meet the requirements of Any framework for ToIP must be derived from the requirements of
RFC3351 [2]. A basic requirement is that it must provide a RFC3351 [I]. A basic requirement is that it must provide a
standardized way for offering real-time text-based, conversational standardized way for offering real-time text-based, conversational
services that can be used as an equivalent to voice telephony by deaf, services that can be used as an equivalent to voice telephony by deaf,
hard of hearing speech-impaired and mainstream users. hard of hearing speech-impaired and mainstream users.
It is important to understand that real-time text conversations are It is important to understand that real-time text conversations are
significantly different from other text-based communications like significantly different from other text-based communications like
email or Instant Messaging. Real-time text conversations deliver an email or Instant Messaging. Real-time text conversations deliver an
equivalent mode to voice conversations by providing transmission of equivalent mode to voice conversations by providing transmission of
text character by character as it is entered, so that the conversation text character by character as it is entered, so that the conversation
can be followed closely and immediate interaction take place. can be followed closely and immediate interaction take place.
skipping to change at page 10, line ? skipping to change at page 10, line ?
those provided by voice. To achieve that, ToIP needs to: those provided by voice. To achieve that, ToIP needs to:
a. offer real-time transport and presentation of the conversation; a. offer real-time transport and presentation of the conversation;
b. provide simultaneous transmission in both directions; b. provide simultaneous transmission in both directions;
c. support both point-to-point and multipoint communication; c. support both point-to-point and multipoint communication;
d. allow other media, like audio and video, to be used in conjunction d. allow other media, like audio and video, to be used in conjunction
with ToIP; with ToIP;
e. ensure that the real-time text service is always available. e. ensure that the real-time text service is always available.
Real-time text is a useful subset of Total Conversation as defined in Real-time text is a useful subset of Total Conversation as defined in
ITU-T F.703 [6]. Total Conversation allows participants to use ITU-T F.703 [5]. Total Conversation allows participants to use
multiple modes of communication during the conversation, either at the multiple modes of communication during the conversation, either at the
same time or by switching between modes, e.g., between real-time text same time or by switching between modes, e.g., between real-time text
and audio. and audio.
Deaf, hard-of-hearing and mainstream users may invoke ToIP services Deaf, hard-of-hearing and mainstream users may invoke ToIP services
for many different reasons: for many different reasons:
- because they are in a noisy environment, e.g., in a machine room of - because they are in a noisy environment, e.g., in a machine room of
a factory where listening is difficult; a factory where listening is difficult;
- because they are busy with another call and want to participate in - because they are busy with another call and want to participate in
two calls at the same time; two calls at the same time;
van Wijk, et al. Expires March 3, 2007 [Page 6] van Wijk, et al. Expires April 21, 2008 [Page 6]
- for implementing text and/or speech recording services (e.g., text - for implementing text and/or speech recording services (e.g., text
documentation/ audio recording) for legal purposes, for clarity or documentation/ audio recording) for legal purposes, for clarity or
for flexibility; for flexibility;
- to overcome language barriers through speech translation and/or - to overcome language barriers through speech translation and/or
transcoding services; transcoding services;
- because of hearing loss, deafness or tinnitus as a result of the - because of hearing loss, deafness or tinnitus as a result of the
aging process or for any other reason, creating a need to replace or aging process or for any other reason, creating a need to replace or
complement voice with real-time text in conversational sessions. complement voice with real-time text in conversational sessions.
In many of the above examples, real-time text may accompany speech. In many of the above examples, real-time text may accompany speech.
The text could be displayed side by side, or in a manner similar to The text could be displayed side by side, or in a manner similar to
subtitling in broadcasting environments, or in any other suitable subtitling in broadcasting environments, or in any other suitable
manner. This could occur with users who are hard of hearing and also manner. This could occur with users who are hard of hearing and also
for mixed media calls with both hearing and deaf people participating for mixed media calls with both hearing and deaf people participating
in the call. in the call.
A ToIP user may wish to call another ToIP user, join a conference A ToIP user may wish to call another ToIP user, join a conference
session involving several users, or initiate or join a multimedia session involving several users, or initiate or join a multimedia
session, such as a Total Conversation session. session, such as a Total Conversation session.
A common scenario for multipoint real-time text is conference calling
with many participants. Implementers could for example use different
colours to render different participants' text, or could create
separate windows or rendering areas for each participant.
5.2 Detailed requirements for ToIP 5.2 Detailed requirements for ToIP
The following sections list individual requirements for ToIP. Each The following sections list individual requirements for ToIP. Each
requirement has been given a unique identifier (R1, R2, etc). Section requirement has been given a unique identifier (R1, R2, etc). Section
6 (Implementation Framework) describes how to implement ToIP based on 6 (Implementation Framework) describes how to implement ToIP based on
these requirements and using existing protocols and techniques. these requirements and using existing protocols and techniques.
The requirements are organized under the following headings: The requirements are organized under the following headings:
- session set-up and session control; - session set-up and session control;
- transport; - transport;
skipping to change at page 10, line ? skipping to change at page 10, line ?
large number of people who can send voice but must receive text (due large number of people who can send voice but must receive text (due
to a hearing impairment), or who can hear but must send text (due to a to a hearing impairment), or who can hear but must send text (due to a
speech impairment). speech impairment).
R1: It SHOULD be possible to start conversations in any mode (real- R1: It SHOULD be possible to start conversations in any mode (real-
time text, voice, video) or combination of modes. time text, voice, video) or combination of modes.
R2: It MUST be possible for the users to switch to real-time text, or R2: It MUST be possible for the users to switch to real-time text, or
add real-time text as an additional modality, during the conversation. add real-time text as an additional modality, during the conversation.
van Wijk, et al. Expires April 21, 2008 [Page 7]
R3: Systems supporting ToIP MUST allow users to select any of the R3: Systems supporting ToIP MUST allow users to select any of the
supported conversation modes at any time, including in mid- supported conversation modes at any time, including in mid-
conversation. conversation.
van Wijk, et al. Expires March 3, 2007 [Page 7]
R4: Systems SHOULD allow the user to specify a preferred mode of R4: Systems SHOULD allow the user to specify a preferred mode of
communication in each direction, with the ability to fall back to communication in each direction, with the ability to fall back to
alternatives that the user has indicated are acceptable. alternatives that the user has indicated are acceptable.
R5: If the user requests simultaneous use of real-time text and audio, R5: If the user requests simultaneous use of real-time text and audio,
and this is not possible because of constraints in the network, the and this is not possible because of constraints in the network, the
system SHOULD try to establish text only communication. system SHOULD try to establish text only communication if that is
what the user has specified as his/her preference.
R6: If the user has expressed a preference for real-time text, R6: If the user has expressed a preference for real-time text,
establishment of a connection including real-time text MUST have establishment of a connection including real-time text MUST have
priority over other outcomes of the session setup. priority over other outcomes of the session setup.
R7: It MUST be possible to use real-time text in conferences both as a R7: It MUST be possible to use real-time text in conferences both as a
medium of discussion between individual participants (for example, for medium of discussion between individual participants (for example, for
sidebar discussions in real-time text while listening to the main sidebar discussions in real-time text while listening to the main
conference audio) and for central support of the conference with conference audio) and for central support of the conference with
real-time text interpretation of speech. real-time text interpretation of speech.
skipping to change at page 10, line ? skipping to change at page 10, line ?
RECOMMENDED that similar functionality be provided for the video part RECOMMENDED that similar functionality be provided for the video part
of the conversation, i.e. to specify the sign language being used). of the conversation, i.e. to specify the sign language being used).
R9: Where certain session services are available for the audio media R9: Where certain session services are available for the audio media
part of a session, these functions MUST also be supported for the part of a session, these functions MUST also be supported for the
real-time text media part of the same session. For example, call real-time text media part of the same session. For example, call
transfer must act on all media in the session. transfer must act on all media in the session.
5.2.2 Transport requirements 5.2.2 Transport requirements
ToIP will often be used to access a relay service [I], allowing real- ToIP will often be used to access a relay service [V], allowing real-
time text users to communicate with voice users. With relay services, time text users to communicate with voice users. With relay services,
as well as in direct user-to-user conversation, it is crucial that as well as in direct user-to-user conversation, it is crucial that
text characters are sent as soon as possible after they are entered. text characters are sent as soon as possible after they are entered.
While buffering may be done to improve efficiency, the delays SHOULD While buffering may be done to improve efficiency, the delays SHOULD
be kept minimal. In particular, buffering of whole lines of text will be kept minimal. In particular, buffering of whole lines of text will
not meet character delay requirements. not meet character delay requirements.
R10: Characters must be transmitted soon after entry of each character R10: Characters must be transmitted soon after entry of each character
so that the maximum delay requirement can be met. An end-to-end delay so that the maximum delay requirement can be met. An end-to-end delay
time of one second is regarded as good, while users note and time of one second is regarded as good, while users note and
appreciate shorter delays, down to 300ms. A delay of up to two seconds appreciate shorter delays, down to 300ms. A delay of up to two seconds
is possible to use. is possible to use.
R11: Real-time text transmission from a terminal SHALL be performed R11: Real-time text transmission from a terminal SHALL be performed
character by character as entered, or in small groups of characters, character by character as entered, or in small groups of characters,
van Wijk, et al. Expires April 21, 2008 [Page 8]
so that no character is delayed from entry to transmission by more so that no character is delayed from entry to transmission by more
than 300 milliseconds. than 300 milliseconds.
R12: It MUST be possible to transmit characters at a rate sufficient R12: It MUST be possible to transmit characters at a rate sufficient
to support fast human typing as well as speech-to-text methods of to support fast human typing as well as speech-to-text methods of
van Wijk, et al. Expires March 3, 2007 [Page 8]
generating real-time text. A rate of 30 characters per second is generating real-time text. A rate of 30 characters per second is
regarded as sufficient. regarded as sufficient.
R13: A ToIP service MUST be able to deal with international character R13: A ToIP service MUST be able to deal with international character
sets. sets.
R14: Where it is possible, loss or corruption of real-time text during R14: Where it is possible, loss or corruption of real-time text during
transport SHOULD be detected and the user should be informed. transport SHOULD be detected and the user should be informed.
R15: Transport of real-time text SHOULD be as robust as possible, so R15: Transport of real-time text SHOULD be as robust as possible, so
as to minimize loss of characters. as to minimize loss of characters.
R16: It SHOULD be possible to send and receive real-time text R16: It SHOULD be possible to send and receive real-time text
simultaneously. simultaneously.
5.2.3 Transcoding service requirements 5.2.3 Transcoding service requirements
If the User Agents of different participants indicate that there is an If the User Agents of different participants indicate that there is an
incompatibility between their capabilities to support certain media incompatibility between their capabilities to support certain media
types, e.g. one User Agent only offering T.140 over IP as described in types, e.g. one User Agent only offering T.140 over IP as described in
RFC4103 [5] and the other one only supporting audio, the user might RFC4103 [4] and the other one only supporting audio, the user might
want to invoke a transcoding service. want to invoke a transcoding service.
Some users may indicate their preferred modality to be audio while Some users may indicate their preferred modality to be audio while
others may indicate real-time text. In this case, transcoding services others may indicate real-time text. In this case, transcoding services
might be needed for text-to-speech (TTS) and speech-to-text (STT). might be needed for text-to-speech (TTS) and speech-to-text (STT).
Other examples of possible scenarios for including a relay service in Other examples of possible scenarios for including a relay service in
the conversation are: text bridging after conversion from speech, the conversation are: text bridging after conversion from speech,
audio bridging after conversion from real-time text, etc. audio bridging after conversion from real-time text, etc.
A number of requirements, motivations and implementation guidelines A number of requirements, motivations and implementation guidelines
for relay service invocation can be found in RFC 3351 [2]. for relay service invocation can be found in RFC 3351 [I].
R17: It MUST be possible for users to invoke a transcoding service R17: It MUST be possible for users to invoke a transcoding service
where such service is available. where such service is available.
R18: It MUST be possible for users to indicate their preferred R18: It MUST be possible for users to indicate their preferred
modality (e.g. ToIP). modality (e.g. ToIP).
R19: It MUST be possible to negotiate the requirements for transcoding R19: It MUST be possible to negotiate the requirements for transcoding
services in real time in the process of setting up a call. services in real time in the process of setting up a call.
R20: It MUST be possible to negotiate the requirements for transcoding R20: It MUST be possible to negotiate the requirements for transcoding
services in mid-call, for the immediate addition of those services to services in mid-call, for the immediate addition of those services to
the call. the call.
van Wijk, et al. Expires April 21, 2008 [Page 9]
R21: Communication between the end participants SHOULD continue after R21: Communication between the end participants SHOULD continue after
the addition or removal of a text relay service, and the effect of the the addition or removal of a text relay service, and the effect of the
change should be limited in the users' perception to the direct effect change should be limited in the users' perception to the direct effect
of having or not having the transcoding service in the connection. of having or not having the transcoding service in the connection.
van Wijk, et al. Expires March 3, 2007 [Page 9]
R22: When setting up a session, it MUST be possible for a user to R22: When setting up a session, it MUST be possible for a user to
specify the type of relay service requested (e.g., speech to text or specify the type of relay service requested (e.g., speech to text or
text to speech). The specification of a type of relay MUST include a text to speech). The specification of a type of relay MUST include a
language specifier. language specifier.
R23: It SHOULD be possible to route the session to a preferred relay R23: It SHOULD be possible to route the session to a preferred relay
service even if the user invokes the session from another region or service even if the user invokes the session from another region or
network than that usually used. network than that usually used.
R24: It is RECOMMENDED that ToIP implementations make the invocation R24: It is RECOMMENDED that ToIP implementations make the invocation
skipping to change at page 11, line 25 skipping to change at page 11, line 31
to intervene during any stage of the answering machine procedure and to intervene during any stage of the answering machine procedure and
take control of the session. take control of the session.
R35: It SHOULD be possible to save the text portion of a conversation. R35: It SHOULD be possible to save the text portion of a conversation.
R36: The presentation of the conversation SHOULD be done in such a way R36: The presentation of the conversation SHOULD be done in such a way
that users can easily identify which party generated any given portion that users can easily identify which party generated any given portion
of text. of text.
R37: ToIP SHOULD handle characters such as new line, erasure and R37: ToIP SHOULD handle characters such as new line, erasure and
alerting during a session as specified in ITU-T T.140 [9]. alerting during a session as specified in ITU-T T.140 [8].
5.2.5 Interworking requirements 5.2.5 Interworking requirements
There is a range of existing real-time text services. There is also a There is a range of existing real-time text services. There is also a
range of network technologies that could support real-time text range of network technologies that could support real-time text
services. services.
Real-time/interactive texting facilities exist already in various Real-time/interactive texting facilities exist already in various
forms and on various networks. In the PSTN, they are commonly referred forms and on various networks. In the PSTN, they are commonly referred
to as text telephony. to as text telephony.
skipping to change at page 12, line 26 skipping to change at page 12, line 31
5.2.5.2 Cellular Interworking requirements 5.2.5.2 Cellular Interworking requirements
As mobile communications have been adopted widely, various solutions As mobile communications have been adopted widely, various solutions
for real-time texting while on the move were developed. ToIP services for real-time texting while on the move were developed. ToIP services
should provide interworking with such services as well. should provide interworking with such services as well.
Alternative means of transferring the Text telephony data have been Alternative means of transferring the Text telephony data have been
developed when TTY services over cellular were mandated by the FCC in developed when TTY services over cellular were mandated by the FCC in
the USA. They are the a) "No-gain" codec solution, and b) the Cellular the USA. They are the a) "No-gain" codec solution, and b) the Cellular
Text Telephony Modem (CTM) solution [8] both collectively called Text Telephony Modem (CTM) solution [7] both collectively called
"Baudot mode" solution in the USA. "Baudot mode" solution in the USA.
The GSM and 3G standards from 3GPP make use of the CTM modem in the The GSM and 3G standards from 3GPP make use of the CTM modem in the
voice channel for text telephony. However, implementations also exist voice channel for text telephony. However, implementations also exist
that use the data channel to provide such functionality. Interworking that use the data channel to provide such functionality. Interworking
with these solutions should be done using text gateways that set up with these solutions should be done using text gateways that set up
the data channel connection at the GSM side and provide ToIP at the the data channel connection at the GSM side and provide ToIP at the
other side. other side.
R44: a ToIP service SHOULD provide interworking with mobile text R44: a ToIP service SHOULD provide interworking with mobile text
skipping to change at page 12, line 48 skipping to change at page 12, line 53
5.2.5.3 Instant Messaging Interworking requirements 5.2.5.3 Instant Messaging Interworking requirements
Many people use Instant Messaging to communicate via the Internet Many people use Instant Messaging to communicate via the Internet
using text. Instant Messaging usually transfers blocks of text rather using text. Instant Messaging usually transfers blocks of text rather
than streaming as is used by ToIP. Usually a specific action is than streaming as is used by ToIP. Usually a specific action is
required by the user to activate transmission, such as pressing the required by the user to activate transmission, such as pressing the
ENTER key or a send button. As such, it is not a replacement for ToIP ENTER key or a send button. As such, it is not a replacement for ToIP
and in particular does not meet the needs for real time conversations and in particular does not meet the needs for real time conversations
including those of deaf, hard of hearing and speech-impaired users as including those of deaf, hard of hearing and speech-impaired users as
defined in RFC 3351 [2]. It is less suitable for communications defined in RFC 3351 [I]. It is less suitable for communications
through a relay service [I]. through a relay service [V].
The streaming nature of ToIP provides a more direct conversational The streaming nature of ToIP provides a more direct conversational
user experience and, when given the choice, users may prefer ToIP. user experience and, when given the choice, users may prefer ToIP.
R45: a ToIP service MAY provide interworking with Instant Messaging R45: a ToIP service MAY provide interworking with Instant Messaging
services. services.
6. Implementation Framework 6. Implementation Framework
This section describes an implementation framework for ToIP that meets This section describes an implementation framework for ToIP that meets
the requirements and offers the functionality as set out in section 5. the requirements and offers the functionality as set out in section 5.
The framework presented here uses existing standards that are already The framework presented here uses existing standards that are already
commonly used for voice based conversational services on IP networks. commonly used for voice based conversational services on IP networks.
6.1 General implementation framework 6.1 General implementation framework
This framework specifies the use of the Session Initiation Protocol This framework specifies the use of the Session Initiation Protocol
(SIP) [3] to set up, control and tear down the connections between (SIP) [2] to set up, control and tear down the connections between
ToIP users whilst the media is transported using the Real-Time ToIP users whilst the media is transported using the Real-Time
Transport Protocol (RTP) [4] as described in RFC 4103 [5]. Transport Protocol (RTP) [3] as described in RFC 4103 [4].
RFC 4504 describes how to implement support for real-time text in SIP RFC 4504 describes how to implement support for real-time text in SIP
telephony devices [23]. telephony devices [II].
6.2 Detailed implementation framework 6.2 Detailed implementation framework
6.2.1 Session control and set-up 6.2.1 Session control and set-up
ToIP services MUST use the Session Initiation Protocol (SIP) [3] for ToIP services MUST use the Session Initiation Protocol (SIP) [2] for
setting up, controlling and terminating sessions for real-time text setting up, controlling and terminating sessions for real-time text
conversation with one or more participants and possibly including conversation with one or more participants and possibly including
other media like video or audio. The session description protocol other media like video or audio. The Session Description Protocol
(SDP) used in SIP to describe the session is used to express the (SDP) used in SIP to describe the session is used to express the
attributes of the session and to negotiate a set of compatible media attributes of the session and to negotiate a set of compatible media
types. types.
SIP [3] allows participants to negotiate all media including real-time SIP [2] allows participants to negotiate all media including real-time
text conversation [5]. ToIP services can provide the ability to set up text conversation [4]. ToIP services can provide the ability to set up
conversation sessions from any location as well as provision for conversation sessions from any location as well as provision for
privacy and security through the application of standard SIP privacy and security through the application of standard SIP
techniques. techniques.
6.2.1.1 Pre-session set-up 6.2.1.1 Pre-session set-up
The requirements of the user to be reached at a consistent address and 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- to store preferences for evaluation at session setup are met by pre-
session setup actions. That includes storing of registration session setup actions. That includes storing of registration
information in the SIP registrar, to provide information about how a information in the SIP registrar, to provide information about how a
skipping to change at page 14, line 26 skipping to change at page 14, line 34
authorisation of the SIP registrar to invoke the service. authorisation of the SIP registrar to invoke the service.
A point-to-point session takes place between two parties. For ToIP, A point-to-point session takes place between two parties. For ToIP,
one or both of the communicating parties will indicate real-time text one or both of the communicating parties will indicate real-time text
as a possible or preferred medium for conversation using SIP in the as a possible or preferred medium for conversation using SIP in the
session setup. session setup.
The following features MAY be implemented to facilitate the session The following features MAY be implemented to facilitate the session
establishment using ToIP: establishment using ToIP:
a. Caller Preferences: SIP headers (e.g., Contact) [11] can be used to a. Caller Preferences: SIP headers (e.g., Contact) [10] can be used to
show that real-time text is the medium of choice for show that real-time text is the medium of choice for
communications. communications.
b. Called Party Preferences [12]: The called party being passive can b. Called Party Preferences [11]: The called party being passive can
formulate a clear rule indicating how a session should be handled formulate a clear rule indicating how a session should be handled
either using real-time text as a preferred medium or not, and either using real-time text as a preferred medium or not, and
whether a designated SIP proxy needs to handle this session or it whether a designated SIP proxy needs to handle this session or it
will be handled in the SIP User Agent. will be handled in the SIP User Agent.
c. SIP Server support for User Preferences: It is RECOMMENDED that SIP c. SIP Server support for User Preferences: It is RECOMMENDED that SIP
servers also handle the incoming sessions in accordance with servers also handle the incoming sessions in accordance with
preferences expressed for real-time text. The SIP Server can also preferences expressed for real-time text. The SIP Server can also
enforce ToIP policy rules for communications (e.g. use of the enforce ToIP policy rules for communications (e.g. use of the
transcoding server for ToIP). transcoding server for ToIP).
6.2.1.2 Session Negotiations 6.2.1.2 Session Negotiations
The Session Description Protocol (SDP) used in SIP [3] provides the The Session Description Protocol (SDP) used in SIP [2] provides the
capabilities to indicate real-time text as a medium in the session capabilities to indicate real-time text as a medium in the session
setup. RFC 4103 [5] uses the RTP payload types "text/red" and setup. RFC 4103 [4] uses the RTP payload types "text/red" and
"text/t140" for support of ToIP which can be indicated in the SDP as a "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 part of the SIP INVITE, OK and SIP/200/ACK media negotiations. In
addition, SIPs offer/answer model [13] can also be used in conjunction addition, SIPs offer/answer model [12] can also be used in conjunction
with other capabilities including the use of a transcoding server for with other capabilities including the use of a transcoding server for
enhanced session negotiations [14,15,16]. enhanced session negotiations [III,IV,13].
6.2.2 Transport 6.2.2 Transport
ToIP services MUST support the Real-Time Transport Protocol (RTP) [4] ToIP services MUST support the Real-Time Transport Protocol (RTP) [3]
according to the specification of RFC 4103 [4] for the transport of according to the specification of RFC 4103 [3] for the transport of
real-time text between participants. real-time text between participants.
RFC 4103 describes the transmission of T.140 [9] real-time text on IP RFC 4103 describes the transmission of T.140 [8] real-time text on IP
networks. networks.
In order to enable the use of international character sets, the In order to enable the use of international character sets, the
transmission format for real-time text conversation SHALL be UTF-8 transmission format for real-time text conversation SHALL be UTF-8
[17], in accordance with ITU-T T.140. [14], in accordance with ITU-T T.140.
If real-time text is detected to be missing after transmission, there If real-time text is detected to be missing after transmission, there
SHOULD be a "text loss" indication in the real-time text as specified SHOULD be a "text loss" indication in the real-time text as specified
in T.140 Addendum 1 [9]. in T.140 Addendum 1 [8].
The redundancy method of RFC 4103 [5] SHOULD be used to significantly The redundancy method of RFC 4103 [4] SHOULD be used to significantly
increase the reliability of the real-time text transmission. A increase the reliability of the real-time text transmission. A
redundancy level using 2 generations gives very reliable results and redundancy level using 2 generations gives very reliable results and
is therefore strongly RECOMMENDED. is therefore strongly RECOMMENDED.
Real-time text capability is announced in SDP by a declaration similar Real-time text capability is announced in SDP by a declaration similar
to this example: to this example:
m=text 11000 RTP/AVP 100 98 m=text 11000 RTP/AVP 100 98
a=rtpmap:98 t140/1000 a=rtpmap:98 t140/1000
a=rtpmap:100 red/1000 a=rtpmap:100 red/1000
a=fmtp:100 98/98/98 a=fmtp:100 98/98/98
By having this single coding and transmission scheme for real-time By having this single coding and transmission scheme for real-time
text defined in the SIP session control environment, the opportunity text defined in the SIP session control environment, the opportunity
for interoperability is optimized. However, if good reasons exist, for interoperability is optimized. However, if good reasons exist,
other transport mechanisms MAY be offered and used for the T.140 coded other transport mechanisms MAY be offered and used for the T.140 coded
text provided that proper negotiation is introduced, but RFC 4103 [5] text provided that proper negotiation is introduced, but RFC 4103 [4]
transport MUST be used as both the default and the fallback transport. transport MUST be used as both the default and the fallback transport.
6.2.3 Transcoding services 6.2.3 Transcoding services
Invocation of a transcoding service MAY happen automatically when the Invocation of a transcoding service MAY happen automatically when the
session is being set up based on any valid indication or negotiation session is being set up based on any valid indication or negotiation
of supported or preferred media types. A transcoding framework of supported or preferred media types. A transcoding framework
document using SIP [14] describes invoking relay services, where the document using SIP [III] describes invoking relay services, where the
relay acts as a conference bridge or uses the third party control relay acts as a conference bridge or uses the third party control
mechanism. ToIP implementations SHOULD support this transcoding mechanism. ToIP implementations SHOULD support this transcoding
framework. framework.
6.2.4 Presentation and User control functions 6.2.4 Presentation and User control functions
6.2.4.1 Progress and status information 6.2.4.1 Progress and status information
Session progress information SHOULD use simple language so that as Session progress information SHOULD use simple language so that as
many users as possible can understand it. The use of jargon or many users as possible can understand it. The use of jargon or
skipping to change at page 16, line 49 skipping to change at page 16, line 49
users must be able to distinguish easily between different speakers. users must be able to distinguish easily between different speakers.
This could be done using color, positioning of the text (i.e. incoming This could be done using color, positioning of the text (i.e. incoming
real-time text and outgoing real-time text in different display real-time text and outgoing real-time text in different display
areas), by in-band identifiers of the parties or by a combination of areas), by in-band identifiers of the parties or by a combination of
any of these techniques. any of these techniques.
6.2.4.4 File storage 6.2.4.4 File storage
Requirement R31 recommends that ToIP systems allow the user to save Requirement R31 recommends that ToIP systems allow the user to save
text conversations. This SHOULD be done using a standard file format. text conversations. This SHOULD be done using a standard file format.
For example: a UTF-8 text file in XHTML format [18] including For example: a UTF-8 text file in XHTML format [15] including
timestamps, party names (or addresses) and the conversation text. timestamps, party names (or addresses) and the conversation text.
6.2.5 Interworking functions 6.2.5 Interworking functions
A number of systems for real-time text conversation already exist as A number of systems for real-time text conversation already exist as
well as a number of message oriented text communication systems. well as a number of message oriented text communication systems.
Interoperability is of interest between ToIP and some of these Interoperability is of interest between ToIP and some of these
systems. systems.
skipping to change at page 18, line 13 skipping to change at page 18, line 13
(This requires user interaction with the gateway to place a call). (This requires user interaction with the gateway to place 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 calls. j. Number or address analysis leads to a gateway for all PSTN calls.
6.2.5.1 PSTN Interworking 6.2.5.1 PSTN Interworking
Analog text telephony is cumbersome because of incompatible national Analog text telephony is cumbersome because of incompatible national
implementations where interworking was never considered. A large implementations where interworking was never considered. A large
number of these implementations have been documented in ITU-T V.18 number of these implementations have been documented in ITU-T V.18
[19], which also defines the modem detection sequences for the [16], which also defines the modem detection sequences for the
different text protocols. The modem type identification may in rare different text protocols. The modem type identification may in rare
cases take considerable time depending on user actions. cases take considerable time depending on user actions.
To resolve analog textphone incompatibilities, text telephone gateways To resolve analog textphone incompatibilities, text telephone gateways
are needed to transcode incoming analog signals into T.140 and vice are needed to transcode incoming analog signals into T.140 and vice
versa. The modem capability exchange time can be reduced by the text versa. The modem capability exchange time can be reduced by the text
telephone gateways initially assuming the analog text telephone telephone gateways initially assuming the analog text telephone
protocol used in the region where the gateway is located. For example, 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 in the USA, Baudot [VI] might be tried as the initial protocol. If
negotiation for Baudot fails, the full V.18 modem capability exchange 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 will take place. In the UK, ITU-T V.21 [VII] might be the first
choice. choice.
In particular transmission of real-time text on PSTN networks takes In particular transmission of real-time text on PSTN networks takes
place using a variety of codings and modulations, including ITU-T V.21 place using a variety of codings and modulations, including ITU-T
[III], Baudot [II], DTMF, V.23 [IV] and others. Many difficulties have V.21 [VII], Baudot [VI], DTMF, V.23 [VIII] and others. Many
arisen as a result of this variety in text telephony protocols and the difficulties have arisen as a result of this variety in text
ITU-T V.18 [19] standard was developed to address some of these telephony protocols and the ITU-T V.18 [16] standard was developed to
issues. address some of these issues.
ITU-T V.18 [19] offers a native text telephony method plus it defines ITU-T V.18 [16] offers a native text telephony method plus it defines
interworking with current protocols. In the interworking mode, it will interworking with current protocols. In the interworking mode, it will
recognise one of the older protocols and fall back to that recognise one of the older protocols and fall back to that
transmission method when required. transmission method when required.
Text gateways MUST use the ITU-T V.18 [19] standard at the PSTN side. Text gateways MUST use the ITU-T V.18 [16] standard at the PSTN side.
A text gateway MUST act as a SIP User Agent on the IP side and support A text gateway MUST act as a SIP User Agent on the IP side and support
RFC 4103 real-time text transport. RFC 4103 real-time text transport.
While ToIP allows receiving and sending real-time text simultaneously While ToIP allows receiving and sending real-time text simultaneously
and is displayed on a split screen, many analog text telephones and is displayed on a split screen, many analog text telephones
require users to take turns typing. This is because many text require users to take turns typing. This is because many text
telephones operate strictly half duplex. Only one can transmit text at telephones operate strictly half duplex. Only one can transmit text at
a time. The users apply strict turn-taking rules. a time. The users apply strict turn-taking rules.
There are several text telephones which communicate in full duplex, There are several text telephones which communicate in full duplex,
but merge transmitted text and received text in the same line in the but merge transmitted text and received text in the same line in the
same display window. Here too the users apply strict turn taking same display window. Here too the users apply strict turn taking
rules. rules.
Native V.18 text telephones support full duplex and separate display Native V.18 text telephones support full duplex and separate display
from reception and transmission so that the full duplex capability can from reception and transmission so that the full duplex capability
be used fully. Such devices could use the ToIP split screen as well, can be used fully. Such devices could use the ToIP split screen as
but almost all text telephones use a restricted character set and many well, but almost all text telephones use a restricted character set
use low text transmission speeds (4 to 7 characters per second). and many use low text transmission speeds (4 to 7 characters per
second).
That is why it is important for the ToIP user to know that he or she That is why it is important for the ToIP user to know that he or she
is connected with an analog text telephone. The session description is connected with an analog text telephone. The session description
[10] SHOULD contain an indication that the other endpoint for the call [9] SHOULD contain an indication that the other endpoint for the call
is a PSTN textphone (e.g. connected via an ATA or through a text is a PSTN textphone (e.g. connected via an ATA or through a text
gateway). This means that the textphone user may be used to formal gateway). This means that the textphone user may be used to formal
turn taking during the call. turn taking during the call.
6.2.5.2 Mobile Interworking 6.2.5.2 Mobile Interworking
Mobile wireless (or Cellular) circuit switched connections provide a Mobile wireless (or Cellular) circuit switched connections provide a
digital real-time transport service for voice or data. The access digital real-time transport service for voice or data. The access
technologies include GSM, CDMA, TDMA, iDen and various 3G technologies include GSM, CDMA, TDMA, iDen and various 3G
technologies as well as WiFi or WiMAX. technologies as well as WiFi or WiMAX.
ToIP may be supported over the cellular wireless packet switched ToIP may be supported over the cellular wireless packet switched
service. It interfaces to the Internet. service. It interfaces to the Internet.
The following sections describe how mobile text telephony is The following sections describe how mobile text telephony is
supported. supported.
6.2.5.2.1 Cellular "No-gain" 6.2.5.2.1 Cellular "No-gain"
The "No-gain" text telephone transporting technology uses specially The "No-gain" text telephone transporting technology uses specially
modified EFR [20] and EVR [21] speech vocoders in mobile terminals modified EFR [17] and EVR [18] speech vocoders in mobile terminals
used to provide a text telephony call. It provides full duplex used to provide a text telephony call. It provides full duplex
operation and supports alternating voice and text ("VCO/HCO"). It is operation and supports alternating voice and text ("VCO/HCO"). It is
dedicated to CDMA and TDMA mobile technologies and the US Baudot (i.e. dedicated to CDMA and TDMA mobile technologies and the US Baudot (i.e.
45 bit/s) type of text telephones. 45 bit/s) type of text telephones.
6.2.5.2.2 Cellular Text Telephone Modem (CTM) 6.2.5.2.2 Cellular Text Telephone Modem (CTM)
CTM [8] is a technology independent modem technology that provides the CTM [7] is a technology independent modem technology that provides the
transport of text telephone characters at up to 10 characters/sec transport of text telephone characters at up to 10 characters/sec
using modem signals that can be carried by many voice codecs and uses using modem signals that can be carried by many voice codecs and uses
a highly redundant encoding technique to overcome the fading and cell a highly redundant encoding technique to overcome the fading and cell
changing losses. changing losses.
6.2.5.2.3 Cellular "Baudot mode" 6.2.5.2.3 Cellular "Baudot mode"
This term is often used by cellular terminal suppliers for a cellular This term is often used by cellular terminal suppliers for a cellular
phone mode that allows TTYs to operate into a cellular phone and to 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 communicate with a fixed line TTY. Thus it is a common name for the
skipping to change at page 20, line 11 skipping to change at page 20, line 16
Many mobile terminals allow the use of the circuit switched data Many mobile terminals allow the use of the circuit switched data
channel to transfer data in real-time. Data rates of 9600 bit/s are channel to transfer data in real-time. Data rates of 9600 bit/s are
usually supported on the 2G mobile network. Gateways provide usually supported on the 2G mobile network. Gateways provide
interoperability with PSTN textphones. interoperability with PSTN textphones.
6.2.5.2.5 Mobile ToIP 6.2.5.2.5 Mobile ToIP
ToIP could be supported over mobile wireless packet switched services ToIP could be supported over mobile wireless packet switched services
that interface to the Internet. For 3GPP 3G services, ToIP support is that interface to the Internet. For 3GPP 3G services, ToIP support is
described in 3G TS 26.235 [22]. described in 3G TS 26.235 [19].
6.2.5.3 Instant Messaging Interworking 6.2.5.3 Instant Messaging Interworking
Text gateways MAY be used to allow interworking between Instant Text gateways MAY be used to allow interworking between Instant
Messaging systems and ToIP solutions. Because Instant Messaging is Messaging systems and ToIP solutions. Because Instant Messaging is
based on blocks of text, rather than on a continuous stream of based on blocks of text, rather than on a continuous stream of
characters like ToIP, gateways MUST transcode between the two formats. characters like ToIP, gateways MUST transcode between the two formats.
Text gateways for interworking between Instant Messaging and ToIP MUST Text gateways for interworking between Instant Messaging and ToIP MUST
apply a procedure for bridging the different conversational formats of apply a procedure for bridging the different conversational formats of
real-time text versus text messaging. The following advice may improve real-time text versus text messaging. The following advice may improve
skipping to change at page 21, line 48 skipping to change at page 21, line 51
- Instant Messaging to ToIP. - Instant Messaging to ToIP.
6.2.5.5 Character set transcoding 6.2.5.5 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 set. transcode text streams. ToIP makes use of the ISO 10646 character set.
Most PSTN textphones use a 7-bit character set, or a character set Most PSTN textphones use a 7-bit character set, or a character set
that is converted to a 7-bit character set by the V.18 modem. that is converted to a 7-bit character set by the V.18 modem.
When transcoding between character sets and T.140 in gateways, special When transcoding between character sets and T.140 in gateways, special
consideration MUST be given to the national variants of the 7 bit consideration MUST be given to the national variants of the 7-bit
codes, with national characters mapping into different codes in the codes, with national characters mapping into different codes in the
ISO 10646 code space. The national variant to be used could be ISO 10646 code space. The national variant to be used could be
selectable by the user on a per call basis, or be configured as a selectable by the user on a per call basis, or be configured as a
national default for the gateway. national default for the gateway.
The indicator of missing text in T.140, specified in T.140 amendment The indicator of missing text in T.140, specified in T.140 amendment
1, cannot be represented in the 7 bit character codes. Therefore the 1, cannot be represented in the 7-bit character codes. Therefore the
indicator of missing text SHOULD be transcoded to the ' (apostrophe) indicator of missing text SHOULD be transcoded to the ' (apostrophe)
character in legacy text telephone systems, where this character character in legacy text telephone systems, where this character
exists. For legacy systems where the ' character does not exist, the . exists. For legacy systems where the ' character does not exist, the .
(full stop) character SHOULD be used instead. (full stop) character SHOULD be used instead.
7. Further recommendations for implementers and service providers 7. Further recommendations for implementers and service providers
7.1 Access to Emergency services 7.1 Access to Emergency services
It must be possible to place an emergency call using ToIP and it must It must be possible to place an emergency call using ToIP and it must
skipping to change at page 22, line 34 skipping to change at page 22, line 37
A text gateway with cellular wireless packet switched services must be A text gateway with cellular wireless packet switched services must be
able to route real-time text calls to emergency service providers when able to route real-time text calls to emergency service providers when
any of the recognized emergency numbers that support real-time text any of the recognized emergency numbers that support real-time text
communication for the country is called. communication for the country is called.
7.2 Home Gateways or Analog Terminal Adapters 7.2 Home Gateways or Analog Terminal Adapters
Analog terminal adapters (ATA) using SIP based IP communication and Analog terminal adapters (ATA) using SIP based IP communication and
RJ-11 connectors for connecting traditional PSTN devices SHOULD enable RJ-11 connectors for connecting traditional PSTN devices SHOULD enable
connection of legacy PSTN text telephones [23]. connection of legacy PSTN text telephones [II].
These adapters SHOULD contain V.18 modem functionality, voice handling These adapters SHOULD contain V.18 modem functionality, voice handling
functionality, and conversion functions to/from SIP based ToIP with functionality, and conversion functions to/from SIP based ToIP with
T.140 transported according to RFC 4103 [4], in a similar way as it T.140 transported according to RFC 4103 [3], in a similar way as it
provides interoperability for voice sessions. provides interoperability for voice sessions.
If a session is set up and text/t140 capability is not declared by the 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 destination endpoint (by the end-point terminal or the text gateway in
the network at the end-point), a method for invoking a transcoding 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 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 the textphone MAY be transmitted in the voice channel as audio with
high quality of service. high quality of service.
NOTE: It is preferred that such analog terminal adaptors do use RFC NOTE: It is preferred that such analog terminal adaptors do use RFC
4103 [5] on board and thus act as a text gateway. Sending textphone 4103 [4] on board and thus act as a text gateway. Sending textphone
signals over the voice channel is undesirable due to possible signals over the voice channel is undesirable due to possible
filtering and compression and packet loss between the end-points. This filtering and compression and packet loss between the end-points. This
can result in character loss in the textphone conversation or even not can result in character loss in the textphone conversation or even not
allowing the textphones to connect to each other. allowing the textphones to connect to each other.
7.3 User Mobility 7.3 User Mobility
ToIP User Agents SHOULD use the same mechanisms as other SIP User ToIP User Agents SHOULD use the same mechanisms as other SIP User
Agents to resolve mobility issues. It is RECOMMENDED that users use a Agents to resolve mobility issues. It is RECOMMENDED that users use a
SIP address, resolved by a SIP registrar, to enable basic user SIP address, resolved by a SIP registrar, to enable basic user
skipping to change at page 23, line 34 skipping to change at page 23, line 34
is not degraded unfavourably in comparison to voice performance in is not degraded unfavourably in comparison to voice performance in
congested situations. congested situations.
8. IANA Considerations 8. IANA Considerations
There are no IANA considerations for this specification. There are no IANA considerations for this specification.
9. Security Considerations 9. Security Considerations
User confidentiality and privacy need to be met as described in SIP User confidentiality and privacy need to be met as described in SIP
[3]. For example, nothing should reveal the fact that the ToIP user [2]. For example, nothing should reveal in an obvious way the fact
might be a person with a hearing or speech impairment. ToIP is after that the ToIP user might be a person with a hearing or speech
all a mainstream communication medium for all users. It is up to the impairment. It is up to the ToIP user to make his or her hearing or
ToIP user to make his or her hearing or speech impairment public. If a speech impairment public. If a transcoding server is being used,
transcoding server is being used, this SHOULD be transparent. this SHOULD be as transparent as possible. However, it might still be
possible to discern that a user might be hearing or speech impaired
based on the attributes present in SDP, although the intention is
that mainstream users might also choose to use ToIP.
Encryption SHOULD be used on end-to-end or hop-by-hop basis as Encryption SHOULD be used on end-to-end or hop-by-hop basis as
described in SIP [3] and SRTP [24]. described in SIP [2] and SRTP [20].
Authentication MUST be provided for users in addition to message Authentication MUST be provided for users in addition to message
integrity and access control. integrity and access control.
Protection against Denial-of-service (DoS) attacks needs to be Protection against Denial-of-service (DoS) attacks needs to be
provided considering the case that the ToIP users might need provided considering the case that the ToIP users might need
transcoding servers. transcoding servers.
10. Authors' Addresses 10. Authors' Addresses
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
Email: guido.gybels@rnid.org.uk Email: guido.gybels@rnid.org.uk
Tel +44-20-7294 3713 Tel +44-20-7294 3713
Txt +44-20-7608 0511 Txt +44-20-7296 8001 Ext 3713
Fax +44-20-7296 8069 Fax +44-20-7296 8069
Arnoud A. T. van Wijk Arnoud A. T. van Wijk
Foundation for an Information and Communication Network for the Deaf RealTimeText.org
and Hard of Hearing http://www.realtimetext.org
"AnnieS" Email: arnoud@realtimetext.org
http://www.annies.nl/
Email: arnoud@annies.nl
11. Contributors 11. Contributors
The following people contributed to this document: Willem Dijkstra, The following people contributed to this document: Willem Dijkstra,
Barry Dingle, Gunnar Hellstrom, Radhika R. Roy, Henry Sinnreich and Barry Dingle, Gunnar Hellstrom, Radhika R. Roy, Henry Sinnreich and
Gregg C Vanderheiden. Gregg C Vanderheiden.
The content and concepts within are a product of the SIPPING Working The content and concepts within are a product of the SIPPING Working
Group. Tom Taylor (Nortel) acted as independent reviewer and Group. Tom Taylor (Nortel) acted as independent reviewer and
contributed significantly to the structure and content of this contributed significantly to the structure and content of this
document. document.
12. References 12. References
12.1 Normative references 12.1 Normative references
1. S. Bradner, "Intellectual Property Rights in IETF Technology", 1. S. Bradner, "Intellectual Property Rights in IETF Technology",
BCP 79, RFC 3979, IETF, March 2005. BCP 79, RFC 3979, IETF, March 2005.
2. Charlton, Gasson, Gybels, Spanner, van Wijk, "User Requirements 2. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J.
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.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session
Initiation Protocol", RFC 3621, IETF, June 2002. Initiation Protocol", RFC 3621, IETF, June 2002.
4. H. Schulzrinne, S.Casner, R. Frederick, V. Jacobsone, "RTP: A 3. H. Schulzrinne, S.Casner, R. Frederick, V. Jacobsone, "RTP: A
Transport Protocol for Real-Time Applications", RFC 3550, IETF, Transport Protocol for Real-Time Applications", RFC 3550, IETF,
July 2003. July 2003.
5. G. Hellstrom, P. Jones, "RTP Payload for Text Conversation", 4. G. Hellstrom, P. Jones, "RTP Payload for Text Conversation",
RFC 4103, IETF, June 2005. RFC 4103, IETF, June 2005.
6. ITU-T Recommendation F.703,"Multimedia Conversational Services", 5. ITU-T Recommendation F.703,"Multimedia Conversational Services",
November 2000. November 2000.
7. S. Bradner, "Key words for use in RFCs to Indicate Requirement 6. S. Bradner, "Key words for use in RFCs to Indicate Requirement
8. 3GPP TS 26.226 "Cellular Text Telephone Modem Description" (CTM). 7. 3GPP TS 26.226 "Cellular Text Telephone Modem Description" (CTM).
9. ITU-T Recommendation T.140, "Protocol for Multimedia Application 8. ITU-T Recommendation T.140, "Protocol for Multimedia Application
Text Conversation" (February 1998) and Addendum 1 (February 2000). Text Conversation" (February 1998) and Addendum 1 (February 2000).
10. M. Handley, V. Jacobson, C. Perkins, "SDP: Session Description 9. M. Handley, V. Jacobson, C. Perkins, "SDP: Session Description
Protocol", RFC 4566, IETF, July 2006. Protocol", RFC 4566, IETF, July 2006.
11. J. Rosenberg, H. Schulzrinne, P. Kyzivat, "Indicating User Agent 10. J. Rosenberg, H. Schulzrinne, P. Kyzivat, "Indicating User Agent
Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, Capabilities in the Session Initiation Protocol (SIP)", RFC 3840,
IETF, August 2004 IETF, August 2004
12. J. Rosenberg, H. Schulzrinne, P. Kyzivat, "Caller Preferences for 11. J. Rosenberg, H. Schulzrinne, P. Kyzivat, "Caller Preferences for
the Session Initiation Protocol (SIP)", RFC 3841, IETF, the Session Initiation Protocol (SIP)", RFC 3841, IETF,
August 2004 August 2004
13. J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the 12. J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the
Session Description Protocol (SDP)", RFC 3624, IETF, June 2002. Session Description Protocol (SDP)", RFC 3624, IETF, June 2002.
14. G. Camarillo, "Framework for Transcoding with the Session 13. G. Camarillo, H. Schulzrinne, E. Burger, and A. van Wijk,
Initiation Protocol" IETF May 2006 - 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.
16. G. Camarillo, "The SIP Conference Bridge Transcoding Model," IETF, 14. Yergeau, F., "UTF-8, a transformation format of ISO 10646",
January 2006 - Work in Progress.
17. Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 3629, IETF,November 2003. RFC 3629, IETF,November 2003.
18. "XHTML 1.0: The Extensible HyperText Markup Language: A 15. "XHTML 1.0: The Extensible HyperText Markup Language: A
Reformulation of HTML 4 in XML 1.0", W3C Recommendation. Available Reformulation of HTML 4 in XML 1.0", W3C Recommendation. Available
at http://www.w3.org/TR/xhtml1. at http://www.w3.org/TR/xhtml1.
19. ITU-T Recommendation V.18,"Operational and Interworking 16. ITU-T Recommendation V.18,"Operational and Interworking
Requirements for DCEs operating in Text Telephone Mode", Requirements for DCEs operating in Text Telephone Mode",
November 2000. November 2000.
20. TIA/EIA/IS-823-A "TTY/TDD Extension to TIA/EIA-136-410 Enhanced 17. TIA/EIA/IS-823-A "TTY/TDD Extension to TIA/EIA-136-410 Enhanced
Full Rate Speech Codec (must used in conjunction with Full Rate Speech Codec (must used in conjunction with
TIA/EIA/IS-840)" TIA/EIA/IS-840)"
21. TIA/EIA/IS-127-2 "Enhanced Variable Rate Codec, Speech Service 18. TIA/EIA/IS-127-2 "Enhanced Variable Rate Codec, Speech Service
Option 3 for Wideband Spread Spectrum Digital Systems. Option 3 for Wideband Spread Spectrum Digital Systems.
Addendum 2." Addendum 2."
22. "IP Multimedia default codecs". 3GPP TS 26.235 19. "IP Multimedia default codecs". 3GPP TS 26.235
23. H. Sinnreich, S. Lass, and C. Stredicke, " SIP Telephony Device
Requirements and Configuration" RFC 4504, IETF, May 2006.
24. Baugher, McGrew, Carrara, Naslund, Norrman, "The Secure Real Time 20. Baugher, McGrew, Carrara, Naslund, Norrman, "The Secure Real Time
Transport Protocol (SRTP)", RFC 3711, IETF, March 2004. Transport Protocol (SRTP)", RFC 3711, IETF, March 2004.
25. ITU-T Recommendation F.700,"Framework Recommendation for 21. ITU-T Recommendation F.700,"Framework Recommendation for
Multimedia Services", November 2000. Multimedia Services", November 2000.
12.2 Informative references 12.2 Informative references
I. European Telecommunications Standards Institute (ETSI), "Human I. Charlton, Gasson, Gybels, Spanner, van Wijk, "User Requirements
for the Session Initiation Protocol (SIP) in Support of Deaf,
Hard of Hearing and Speech-impaired Individuals", RFC 3351,
IETF, August 2002.
II. H. Sinnreich, S. Lass, and C. Stredicke, "SIP Telephony Device
Requirements and Configuration" RFC 4504, IETF, May 2006.
III. G. Camarillo, "Framework for Transcoding with the Session
Initiation Protocol", IETF, May 2006 - Work in progress.
IV. G. Camarillo, "The SIP Conference Bridge Transcoding Model",
IETF, January 2006 - Work in Progress.
V. European Telecommunications Standards Institute (ETSI), "Human
Factors (HF); Guidelines for Telecommunication Relay Services for Factors (HF); Guidelines for Telecommunication Relay Services for
Text Telephones". TR 101 806, June 2000. Text Telephones". TR 101 806, June 2000.
II. TIA/EIA/825 "A Frequency Shift Keyed Modem for Use on the Public VI. TIA/EIA/825 "A Frequency Shift Keyed Modem for Use on the Public
Switched Telephone Network." (The specification for 45.45 and 50 Switched Telephone Network." (The specification for 45.45 and 50
bit/s TTY modems.) bit/s TTY modems.)
III. International Telecommunication Union (ITU), "300 bits per second VII. International Telecommunication Union (ITU), "300 bits per second
duplex modem standardized for use in the general switched duplex modem standardized for use in the general switched
telephone network". ITU-T Recommendation V.21, November 1988. telephone network". ITU-T Recommendation V.21, November 1988.
IV. International Telecommunication Union (ITU), "600/1200-baud modem VIII.International Telecommunication Union (ITU), "600/1200-baud modem
standardized for use in the general switched telephone network". standardized for use in the general switched telephone network".
ITU-T Recommendation V.23, November 1988. ITU-T Recommendation V.23, November 1988.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be found on the procedures with respect to rights in RFC documents can be
in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this specification such proprietary rights by implementers or users of this
can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA). Administrative Support Activity (IASA).
 End of changes. 109 change blocks. 
151 lines changed or deleted 161 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/