< draft-ietf-sipping-toip-08.txt   draft-ietf-sipping-toip-09.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 October 19, 2007 Category: Informational April 4, 2008
Expires: April 21, 2008 Expires: October 1, 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-08.txt draft-ietf-sipping-toip-09.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 April 21, 2008. This Internet-Draft will expire on October 1, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
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.....................................................4
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
van Wijk, et al. Expires April 21, 2008 [Page 1] van Wijk, et al. Expires October 1, 2008 [Page 1]
5.2 Detailed requirements for ToIP...............................7 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
6.2 Detailed implementation framework...........................13 6.2 Detailed implementation framework...........................13
6.2.1 Session control and set-up..............................13 6.2.1 Session control and set-up..............................13
6.2.1.1 Pre-session set-up..................................13 6.2.1.1 Pre-session set-up..................................13
6.2.1.2 Session Negotiations................................14 6.2.1.2 Session Negotiations................................14
6.2.2 Transport...............................................15 6.2.2 Transport...............................................15
6.2.3 Transcoding services....................................15 6.2.3 Transcoding services....................................16
6.2.4 Presentation and User control functions.................16 6.2.4 Presentation and User control functions.................16
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........................................17
6.2.5 Interworking functions..................................16 6.2.5 Interworking functions..................................17
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"..........................20
6.2.5.2.4 Mobile data channel mode........................20 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
skipping to change at page 10, line ? skipping to change at page 10, line ?
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
van Wijk, et al. Expires April 21, 2008 [Page 2] van Wijk, et al. Expires October 1, 2008 [Page 2]
from messaging and semi-interactive solutions like Instant Messaging 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 document describes
specifically designed to be compatible with Voice-over-IP (VoIP), therefore how to use a set of existing components and protocols and
Video-over-IP and Multimedia-over-IP (MoIP) environments. This ToIP provides the requirements and rules for that resulting structure,
framework also builds upon, and is compatible with, the high-level which is why it is called a "framework", fitting commonly accepted
user requirements of deaf, hard of hearing and speech-impaired users dictionary definitions of that term.
as described in RFC3351 [I]. It also meets real-time text
requirements of mainstream users. This ToIP framework is specifically designed to be compatible with
Voice-over-IP (VoIP), Video-over-IP and Multimedia-over-IP (MoIP)
environments. This ToIP framework also builds upon, and is compatible
with, the high-level 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) [2] 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) [3] is the protocol of choice The Real-Time Transport Protocol (RTP) [3] is the protocol of choice
skipping to change at page 10, line ? skipping to change at page 10, line ?
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 [5]. 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.
van Wijk, et al. Expires October 1, 2008 [Page 3]
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
van Wijk, et al. Expires April 21, 2008 [Page 3]
RFC 2119 [6] and indicate requirement levels for compliant RFC 2119 [6] and indicate requirement levels for compliant
implementations. 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 [3]. function as defined in RFC 3550 [3].
skipping to change at page 10, line ? skipping to change at page 10, line ?
communication functions for simultaneous or alternating use of text communication functions for simultaneous or alternating use of text
and voice in a call. and voice in a call.
Text bridging: a function of the text media bridge server, gateway Text bridging: a function of the text media bridge server, gateway
(including transcoding gateways) or relay service analogous to that of (including transcoding gateways) or relay service analogous to that of
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
van Wijk, et al. Expires October 1, 2008 [Page 4]
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
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" [5].) 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
skipping to change at page 10, line ? skipping to change at page 10, line ?
PSTN Public Switched Telephone Network PSTN Public Switched Telephone Network
RTP Real Time Transport Protocol RTP Real Time Transport Protocol
SDP Session Description Protocol SDP Session Description Protocol
SIP Session Initiation Protocol SIP Session Initiation Protocol
SRTP Secure Real Time Transport Protocol SRTP Secure Real Time Transport Protocol
TDD Telecommunication Device for the Deaf TDD Telecommunication Device for the Deaf
TDMA Time Division Multiple Access TDMA Time Division Multiple Access
TTY Analog textphone (Teletypewriter) TTY Analog textphone (Teletypewriter)
ToIP Real-time Text over Internet Protocol ToIP Real-time Text over Internet Protocol
URI Uniform Resource Identifier URI Uniform Resource Identifier
UTF-8 Universal Transfer Format-8
van Wijk, et al. Expires October 1, 2008 [Page 5]
UTF-8 UCS/Unicode Transformation 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 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 derived from the requirements of Any framework for ToIP must be derived from the requirements of
skipping to change at page 10, line ? skipping to change at page 10, line ?
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 [5]. 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:
van Wijk, et al. Expires October 1, 2008 [Page 6]
- 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 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.
skipping to change at page 10, line ? skipping to change at page 10, line ?
- interworking. - interworking.
5.2.1 Session set-up and control requirements 5.2.1 Session set-up and control requirements
Conversations could be started using a mode other than real-time text. Conversations could be started using a mode other than real-time text.
Simultaneous or alternating voice and real-time text is used by a Simultaneous or alternating voice and real-time text is used by a
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).
van Wijk, et al. Expires October 1, 2008 [Page 7]
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.
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
skipping to change at page 10, line ? skipping to change at page 10, line ?
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
van Wijk, et al. Expires October 1, 2008 [Page 8]
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
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.
skipping to change at page 10, line ? skipping to change at page 10, line ?
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.
van Wijk, et al. Expires October 1, 2008 [Page 9]
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.
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 SHOULD include
language specifier. a 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
and use of relay services as easy as possible. and use of relay services as easy as possible.
5.2.4 Presentation and User control requirements 5.2.4 Presentation and User control requirements
skipping to change at page 15, line 30 skipping to change at page 15, line 34
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 [8]. in T.140 Addendum 1 [8].
The redundancy method of RFC 4103 [4] 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.
In order to avoid exceeding the capabilities of sender, receiver or
network (congestion), the transmission rate SHOULD be kept at or
below 30 characters per second, which is the default maximum rate as
specified in RFC 4103 [4]. Lower rates MAY be negotiated when needed
through the "cps" parameter as specified in RFC 4103 [4].
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
skipping to change at page 24, line 15 skipping to change at page 24, line 19
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-7296 8001 Ext 3713 Txt +44-20-7296 8001 Ext 3713
Fax +44-20-7296 8069 Fax +44-20-7296 8069
www.ictrnid.org.uk
Arnoud A. T. van Wijk Arnoud A. T. van Wijk
RealTimeText.org Real-Time Text Taskforce (R3TF)
http://www.realtimetext.org www.realtimetext.org
Email: arnoud@realtimetext.org Email: arnoud@realtimetext.org
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
skipping to change at page 26, line 39 skipping to change at page 26, line 42
VII. 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.
VIII.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 IETF Trust (2007). Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST, OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
 End of changes. 30 change blocks. 
35 lines changed or deleted 47 lines changed or added

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