Internet DRAFT - draft-charlton-deaf-req
draft-charlton-deaf-req
Internet Engineering Task Force SIPPING WG
Internet Draft Charlton/Gasson/
Document: draft-charlton-deaf-req-00.txt Gybels/Spanner/
van Wijk
October 2001 RNID/Ericsson
Expires: April 2002
Category: Informational
User Requirements for SIP in support of deaf, hard of hearing
and speech-impaired individuals
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026[1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Table of Contents
1. Abstract........................................................2
2. Terminology and Conventions Used in this Document...............2
3. Introduction....................................................3
4. Purpose and Scope...............................................3
5. Background......................................................4
6. Deaf, Hard of Hearing and Speech-impaired Requirements
for SIP.........................................................4
Introduction....................................................4
6.1. Connection without Difficulty..............................4
6.2 User Profile................................................5
6.3 Intelligent Gateways........................................5
6.4 Inclusive Design............................................5
6.5 Resource Management.........................................6
6.6 Confidentiality and Security................................6
7. Some Real World Scenarios.......................................6
7.1 Transcoding Service.........................................7
7.2 Media Service Provider......................................7
7.3 Sign Language Interface.....................................8
7.4 Synface Support for Voice Calls.............................8
8. Some Suggestions for Service Providers and User Agent
Manufacturers...................................................8
9. Acknowledgements................................................9
10. Author's Addresses..............................................9
References and Notes...............................................10
Charlton/Gasson/Gybels/Spanner/van Wijk [Page 1 of 10] SIP for deaf, hard of hearing and speech-impaired October 2001
1. Abstract
This document aims to present a set of SIP user requirements that
support communications for deaf, hard of hearing and speech-impaired
individuals. These user requirements address the current difficulties
of deaf, hard of hearing and speech-impaired individuals in using
communications facilities, while acknowledging the multi-functional
potential of SIP-based communications.
A number of issues related to these user requirements are further
raised in this document.
Also included are some real world scenarios and some technical
requirements to show the robustness of these requirements on a
concept-level.
2. Terminology and Conventions Used in this Document
In this document, the key words "MUST", "MUST NOT","REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC2119[2] and
indicate requirement levels for compliant SIP implementations.
For the purposes of this document, the following terms are considered
to have these meanings:
Abilities: A person's capacity for communicating which could include
a hearing or speech impairment or not. The terms Abilities and
Preferences apply to both caller and call-recipient.
Preferences: A person's choice of communication mode. This could
include any combination of media stream, e.g., text, audio, video.
The terms Abilities and Preferences apply to both caller and
call-recipient.
Relay Service: A third-party or intermediary in deaf, hard of hearing
and speech-impaired communications. See the definition for
Transcoding Services.
Transcoding Services: A human or automated third party acting as an
intermediary in any session between two other User Agents (being a
User Agent itself), and transcoding one stream into another (e.g.,
voice to text or vice versa).
Textphone: Sometimes called a TTY (teletypewriter), TDD
(telecommunications device for the deaf) or a minicom, a textphone
enables a deaf, hard of hearing or speech-impaired person to place a
call to a telephone or another textphone. Some textphones use the V18
protocol as a standard for communication with other textphone
communication protocols world-wide.
Charlton/Gasson/Gybels/Spanner/van Wijk [Page 2 of 10] SIP for deaf, hard of hearing and speech-impaired October 2001
User: A deaf, hard of hearing or speech-impaired individual. A user
is otherwise referred to as a person or individual, and users
referred to as people.
Note: For the purposes of this document, a deaf, hard of hearing, or
speech-impaired person is an individual who chooses to use SIP
because it can minimize or eliminate constraints in using common
communication devices. As SIP promises a total communication solution
for any kind of person, regardless of ability and preference,
therefore there is no attempt to specifically define deaf, hard of
hearing or speech-impaired in this document.
3. Introduction
The background for this document is the recent developments of SIP
and SIP-based communications, and a growing awareness of deaf, hard
of hearing and speech-impaired issues in the technical community.
The SIP capacity to simplify setting up, managing and tearing down
communication sessions between all kinds of User Agents has specific
implications for deaf, hard of hearing and speech-impaired
individuals.
As SIP enables multiple sessions with translation between multiple
types of media, these requirements aim to provide the standard for
recognising and enabling these interactions, and for a communications
model that includes any and all types of SIP-networking abilities and
preferences.
4. Purpose and Scope
The scope of this document is to first present a current set of user
requirements for deaf, hard of hearing and speech-impaired
individuals through SIP-enabled communications. These are then
followed some real world scenarios in SIP-communications that could
be used in a test environment, and some concepts on how these
requirements can be developed by service providers and User Agent
manufacturers.
These recommendations make explicit the needs of a currently often
disadvantaged user-group and attempts to match them with the capacity
of SIP. It is also not the intention here to prioritise the needs of
the deaf, hard of hearing and speech-impaired in a way that would
penalise other individuals.
These requirements aim to encourage developers and manufacturers
worldwide to consider the specific needs of deaf, hard of hearing and
speech-impaired individuals. This document presents a world-vision
where deafness, hard of hearing or speech impairment are no longer a
barrier to communication.
Charlton/Gasson/Gybels/Spanner/van Wijk [Page 3 of 10] SIP for deaf, hard of hearing and speech-impaired October 2001
5. Background
Deaf, hard of hearing and speech-impaired people are currently
sometimes unable to use commonly available communication devices.
Although this is documented[3], this does not mean that developers or
manufacturers are always aware of this. Communication devices for the
deaf, hard of hearing and speech-impaired are currently often
primitive in design, expensive, and non-compatible with progressively
designed, cheaper and more adaptable communication devices for other
individuals.
Additionally, non-technical human communications for the deaf, hard
of hearing and speech-impaired (sign languages, lip reading) are
non-standard around the world.
Intermediary or third-party services (e.g. transcoding services) for
enabling the hearing impaired full access to modern facilities and
services are currently sometimes limited, although their value is
undeniable as compared to the previous complete unavailability of
such transcoding services.
Yet communication methods in recent decades have proliferated: email,
mobile phones, video streaming, etc. These methods are an advance in
the development of data transfer technologies between devices.
Developers and advocates of SIP agree that this is a protocol that
not only anticipates the growth in communications between convergent
networks in real time, but also fulfils the potential of the Internet
as a communications and information forum. Further, that these
developments allow a standard of communication that can be applied
throughout all networking communities, regardless of abilities and
preferences.
6. Deaf, Hard of Hearing and Speech-impaired Requirements for SIP
Introduction
The user requirements in this section are provided for the benefit of
service providers, User Agent manufacturers and any other interested
party in the development of products and services for the deaf, hard
of hearing and speech-impaired.
The user requirements are as follows:
6.1 Connection without Difficulty
This requirement states:
Whatever the preferences and abilities of the user and User Agent,
there SHOULD be no difficulty in setting up SIP sessions. These
sessions could include multiple proxies, call routing decisions,
transcoding services, e.g., TypeTalk[4] or other media processing,
and could include multiple simultaneous or alternative media streams.
Charlton/Gasson/Gybels/Spanner/van Wijk [Page 4 of 10] SIP for deaf, hard of hearing and speech-impaired October 2001
This means that any User Agent in the conversation space (including
transcoding services) SHOULD be able to add or remove a media stream
from the call without having to tear it down and re-establish it.
6.2 User Profile
This requirement states:
Deaf, hard of hearing and speech-impaired user abilities and
preferences (i.e., user profile) MUST be communicable by SIP, and
these abilities and preferences MUST determine the handling of the
session.
The User Profile for a deaf, hard of hearing and speech-impaired
person might include:
- How media streams are received and transmitted (text, voice, video,
or any combination)
- Redirecting specific media streams through a transcoding service
(e.g., TypeTalk)
- Roaming (for example, a deaf person accessing their User Profile
from a web-interface at an Internet café)
- Anonymity, that is, not revealing that a deaf person is calling,
even through a transcoding service (for example, TextDirect informs
the call-recipient that there is an incoming text call without saying
that a deaf person is calling).
Part of this requirement is to ensure that deaf, hard of hearing and
speech-impaired people can keep their preferences and abilities
confidential from others, to avoid possible discrimination or
prejudice, while still being able to establish a SIP session.
6.3 Intelligent Gateways
This requirement states:
SIP SHOULD support a class of User Agents to perform as gateways for
legacy systems designed for deaf, hard of hearing and speech-impaired
people.
For example, an individual could have a SIP User Agent acting as a
gateway to a PSTN legacy textphone.
6.4 Inclusive Design
This requirement states:
Where applicable, design concepts for communications (devices,
applications, etc.) MUST include the abilities and preferences of
deaf, hard of hearing and speech-impaired people.
Charlton/Gasson/Gybels/Spanner/van Wijk [Page 5 of 10] SIP for deaf, hard of hearing and speech-impaired October 2001
Transcoding services and User Agents MUST be able to connect with
each other regardless of the provider or manufacturer. This means
that new User Agents MUST be able to support legacy protocols through
appropriate gateways.
6.5 Resource Management
This requirement states:
User Agents SHOULD be able to identify the content of a media stream
in order to obtain such information as the cost of the media stream,
if a transcoding service can support it, etc.
User Agents SHOULD be able to choose among transcoding services and
similar services based on their capabilities (e.g., whether a
transcoding service carries a particular media stream), and any
policy constraints they impose (e.g., charging for use). It SHOULD be
possible for User Agents to discover the availability of alternative
media streams and to choose from them.
6.6 Confidentiality and Security
This requirement states:
All third-party or intermediaries (transcoding services) employed in
a session for deaf, hard of hearing and speech-impaired people MUST
offer a confidentiality policy. All information exchanged in this
type of session MUST be secure, that is, erased before
confidentiality is breached, unless otherwise required by legal
intercept[5].
This means that transcoding services (e.g., interpretation,
translation) MUST publish their confidentiality and security
policies.
7. Some Real World Scenarios
These scenarios are intended to show some of the various types of
media streams that would be initiated, managed, directed, and
terminated in a SIP-enabled network, and shows how some resources
might be managed between SIP-enabled networks, transcoding services
and service providers.
To illustrate the communications dynamic of these kinds of scenarios,
each one specifically mentions the kind of media streams transmitted,
and whether User Agents and Transcoding Services are involved.
Charlton/Gasson/Gybels/Spanner/van Wijk [Page 6 of 10] SIP for deaf, hard of hearing and speech-impaired October 2001
7.1 Transcoding Service
In this scenario, a hearing person calls the household of a deaf
person and a hearing person.
1. A voice conversation is initiated between the hearing
participants:
( Phone A) <-----Voice ---> ( Phone B)
2. During the conversation, the hearing person asks to talk with the
deaf person, while keeping the voice connection open so that voice to
voice communications can continue if required.
3. A Relay Service is invited into the conversation.
4. The Relay Service transcodes the hearing person's words into text.
5. Text from the hearing person's voice appears on the display of the
deaf person's User Agent.
6. The deaf person types a response.
7. The Relay Service receives the text and reads it to the hearing
person:
( ) <------------------Voice----------------> ( )
(Phone A ) -----Voice---> (Voice To Text ) -Text-> (Phone B )
( ) <----Voice---- (Service Provider) <-Text- ( )
8. The hearing person asks to talk with the hearing person on the
other side.
9. The Relay Service withdraws from the call.
7.2 Media Service Provider
In this scenario, a deaf person wishes to listen to a Radio program
through a text stream of the program's audio stream.
1. The deaf person attempts to establish a connection to the radio
broadcast, with User Agent preferences set to receiving audio stream
as text.
2. The User Agent of the deaf person queries the radio station User
Agent on whether a text stream is available, other than the audio
stream.
3. However, the radio station has no text stream available for a deaf
listener, and responds in the negative.
4. As no text stream is available, the deaf person's User Agent
requests a Voice-To-Text transcoding service (e.g., TypeTalk) to come
into the conversation space.
5. The transcoding service User Agent identifies the audio stream as
a radio broadcast. However, the policy of the transcoding service is
that it does not accept radio broadcasts because it would overload
their resources far too quickly.
6. In this case, the connection fails.
Alternatively, continuing from 2 above:
3. The radio station does provide text with their audio streams.
4. The deaf person receives a text stream of the radio program.
Note: To support deaf, hard of hearing and speech-impaired, service
providers are encouraged to provide text with audio streams.
Charlton/Gasson/Gybels/Spanner/van Wijk [Page 7 of 10] SIP for deaf, hard of hearing and speech-impaired October 2001
7.3 Sign Language Interface
In this scenario, a deaf person enables a VisiCAST Avatar by setting
up a User Agent to receive audio streams as XML data that will
operate an avatar for sign-language. For outgoing communications,
the deaf person types text that is transcoded into an audio stream
for the other conversation participant.
For example:
( ) --Voice--> ( VoiceToVisiCast ) --XMLData--> ( )
( hearing ) ( deaf )
( Party A ) <--Voice-- ( Text To Voice ) <---Text--- ( Party B )
( ) ( Service Provider ) ( )
7.4 Synface Support for Voice Calls
In order to receive voice calls, a hard of hearing person uses the
Synface Avatar software on a PC. Synface software processes voice
(audio) stream data and displays an animated face that a hard of
hearing person can lip read. During a conversation, the hard of
hearing person uses Synface as support for understanding the audio
stream.
For example:
( ) <-----Voice-----> ( hard of ) -Voice-> ( PC with )
( hearing ) ( hearing ) ( Synface )
( Party A ) ( party B ) ( software)
( ) ( ) ( )
8. Some Suggestions for Service Providers and User Agent Manufacturers
This section is included to encourage service providers and user
agent manufacturers in developing products and services that can be
used by as wide a range of individuals as possible, including the
deaf, hard of hearing and speech-impaired.
- Service providers and User Agent manufacturers can offer to a deaf,
hard of hearing and speech-impaired person the possibility of being
able to hide their specific preferences and abilities from being
made public in any transaction.
- If a User Agent performs auditory signalling, for example a pager,
it could also provide another signalling method, for example,
visual or sensory.
- Service providers who allow the user to store specific setting or
preferences and abilities (i.e., user profile) might consider
storing these setting in a central repository, accessible no matter
the location of the user and regardless of the User Agent used at
that time or location.
- If there are several transcoding services available, the User Agent
can be set to select the most economical/highest quality service.
- The service provider can show the cost per minute and any minimum
charge of a transcoding service call before a session starts,
allowing the user a choice of engaging in the service or not.
Charlton/Gasson/Gybels/Spanner/van Wijk [Page 8 of 10] SIP for deaf, hard of hearing and speech-impaired October 2001
- Service providers are encouraged to offer an alternative stream
with audio streams, for example, text or data streams that operate
avatars, etc.
- All services for interpreting, transliterating, or facilitating
communications for deaf, hard of hearing and speech-impaired people
are required to:
- Keep information exchanged during the transaction strictly
confidential
- Enable information exchange literally and simply, without
deviating and compromising the content
- Facilitate communication without bias, prejudice or opinion
- Match skill sets to the requirement of the individual
- Behave in a professional and appropriate manner
- Be fair in claiming compensation for services
- Strive to improve the skill-sets used for their services.
9. Acknowledgements
The authors would like to thank the following individuals for their
contributions to this draft:
Arnoud van Wijk, Ericsson
David R. Oran, Cisco
Mark Watson, Nortel Networks
Brian Grover, RNID
Anthony Rabin, RNID
Michael Hammer, Cisco
Henry Sinnreich, Worldcom
Rohan Mahy, Cisco
Julian Branston, Cedalion Hosting Services
10. Author's Addresses
Nathan Charlton, RNID, nathan.charlton@rnid.org.uk
Mick Gasson, RNID, mike.gasson@rnid.org.uk
Guido Gybels, RNID, Guido.Gybels@rnid.org.uk
Mike Spanner, RNID, mike.spanner@rnid.org.uk
19-23 Featherstone Street
London EC1Y 8SL
Tel: +44-20 7296 8000
Textphone: +44-20 7296 8001
Fax: +44-20 7296 8199
Arnoud van Wijk
Ericsson EuroLab Netherlands BV
P.O. Box 8
5120 AA Rijen
The Netherlands
Fax: +31-161-247569
Email: Arnoud.van.Wijk@eln.ericsson.se
Comments can be sent to the SIPPING mailing list.
Charlton/Gasson/Gybels/Spanner/van Wijk [Page 9 of 10] SIP for deaf, hard of hearing and speech-impaired October 2001
References and Notes
1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP9,
RFC 2026, October 1996.
2. S. Bradner, "Key words for use in RFCs to indicate requirement
levels". Request for Comments 2119, Internet Engineering Task Force.
March 1997.
3. Moore, Matthew, et al. "For Hearing People Only: Answers to Some
of the Most Commonly Asked Questions About the Deaf Community, Its
Culture, and the Deaf Reality". MSM Productions Ltd., 2nd Edition,
September 1993.
4. TypeTalk is a UK based Relay Service with human operators
performing text to voice and voice to text transcoding services.
5. This requirement recognises emerging regulatory conditions
world-wide that allow for the surveillance and interception of
electronic mail by legal authorities.
Full Copyright Statement
"Copyright (C) The Internet Society 2001. All Rights Reserved. This
document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English. The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Expires: April 2002
Charlton/Gasson/Gybels/Spanner/van Wijk [Page 10 of 10]
