Subject: [Sipping] Preliminary draft of User Requiremens for Hearing & Speech Impaired

From: "Julian Branston" <[email-masked]>
Date: Tue, 02 Oct 2001 17:10:54 +0100

First, a thank-you to all those who contributed their comments on the User requirements for deaf, hard of hearing and speech impaired users recently posted on the SIP list. 

I've attached a preliminary draft of the User Requirements for Deaf, Hard of Hearing & Speech Impaired for review and comment.

As you are all probably aware, the draft is due for formal release no later than the October 10th. 

Please help with your comments on this preliminary version if you can, by the end of this week.

With best regards,

Julian Branston
On behalf of the RNID 

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. These user requirements in turn as presented here have raised a number of issues which are further discussed in this document. 

More technically based requirements, aimed at both communications devices, termed in this document as User Agents, and transcoding services (e.g., relay services), are also included. If the user requirements are sound, then these more low level requirements should be fully represented on the concept-level.

2. Conventions and Glossary
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[ ] and indicate requirement levels for compliant SIP implementations. 

Additionally, the following terms are considered to have the following meaning:

Abilities: The user'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: The user's choice of communication mode. This could include any combination of streams like text, audio, video etc. The terms Abilities and Preferences apply to both caller and call-recipient. 

Relay Service: A third party service for deaf, hard of hearing and speech impaired individuals, acting as an intermediary in any session between two other User Agents (being a User Agent itself), transcoding one stream into another (e.g., voice to text or vice versa), and either implemented by a human operator or by an automated system. 

Terminal: Equipment used by a deaf, hard of hearing or speech impaired individual, for example, a textphone (TTY), PC, PDA (Personal Digital Assistant), mobile phone or video phone, a SIP User Agent, etc. 

Transcoding Services: A term that denotes a third-party or intermediary in deaf, hard of hearing and speech impaired communications. This intermediary could be automated or human, and provide translation, interpretation, or call-facilitation services (e.g., such as the RNID TypeTalk). 

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 the varied textphone communication protocols used around the world.
U
 ser: For the purposes of this document, a deaf, hard of hearing or speech impaired individual. 

3. Introduction
The background for this document is the recent developments of SIP and SIP-based communications, and a growing awareness in the technical community of deaf, hard of hearing and speech impaired issues. The specific parent of this document is the Internet draft vanwijk-sipping-deaf-req-00[ ] and the consensus decision by the SIPPING WG to generate user requirements for deaf, hard of hearing and speech impaired people. 

Because SIP simplifies setting up, managing and tearing down communication sessions between all kinds of UAs, there are specific implications for deaf, hard of hearing and speech-impaired individuals. 

As the development of SIP and its application to communications technologies continues to advance, the need for matching a relatively disadvantaged user group requirements to SIP has become more of a priority. 

This does not imply any hindrance to the effectiveness of SIP. Nor do these requirements set out to 'change the world' or assert an overly political message. Just as SIP enables multiple user sessions with translation between multiple types of media, so 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 users. 

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 followed by a discussion on various issues that these requirements raise. 

As this document aims at requirements at a high-concept level, the distinction has to be made between requirements that are addressed to the employment of SIP itself, and where requirements apply to third-party and intermediary (transcoding) services for deaf, hard of hearing and speech impaired people.

As simple statements, these user requirements are intended to synthesise at a high level the varied and sometimes unrelated user requirements, and which are often addressed in technical, hardware or communication system solutions. 

These recommendations make explicit the needs of a relatively disadvantaged user-group and attempts to match them with the capacity of SIP, without making the requirements too provocative and without alienating the source of technical solutions that can actualise them. It is also not the intention here to prioritise the needs of the deaf, hard of hearing and speech impaired in a way that penalises non-impaired users. 

However, it should be made clear that these requirements do not only relate to SIP-enabled communications, but rather address a broader forum including transcoding service providers of all kinds and equipment manufacturers.
T
 hese requirements aim to encourage developers and manufacturers all over the world to consider the specific needs of deaf, hard of hearing and speech impaired individuals. It presents a vision of a world where deafness or speech impairment need no longer be a barrier to communication. 

5. Background
The limitations for the hearing impaired in using communication devices is well documented[ref], although this does not mean that developers or manufacturers are well aware of them. Communication devices for the deaf, hard of hearing and speech impaired are often primitive in design, expensive, and non-compatible with progressively-designed, cheaper and more adaptable communication devices for the non-impaired user. 

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 sometimes limited, although it must be added that existing transcoding services provide communications that were previously unavailable.

Yet communication methods in recent decades have proliferated: email, mobile phones, video streaming, etc. These methods are an advance in the development of simple, data transfer between devices. With SIP, a simple protocol can intelligently recognise a device and arranges the communication of different media streams according to the user's preference. 

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 preference, disadvantage, or impairment.

This draft is preceded by review comments of user requirements as posted on SIP-related discussion lists. The authors of this draft also attempted to establish a common terminology for this and further discussions, as identified in Conventions and Glossary on page 3.

Further comments can be sent to RNID at: [email-masked]

6. Deaf, Hard of Hearing and Speech Impaired Requirements for SIP
6.1. Introduction
After the posting of the Internet draft SIP Support for Hearing and Speech Impaired Users from the SIPPING WG, and discussions at IETF 51, it was decided to use the above draft as a launching point for discussion, followed by analysis, peer review and the writing of a new draft.

These requirements were developed from a 'brainstorming' session in RNID, and then posted on the SIP lists for comments.

Prior to this, a communications matrix was developed to show the different abilities and preferences of callers and call-recipients, and how these connections are facilitated through a SIP-enabled network. 

The user requirements are as follows:

6.2. Connection without Hindrance
This requirement states: 
Whatever the preferences and abilities of the user and User Agent, these should be no hindrance to setting up SIP sessions. These sessions could include multiple proxies, call routing decisions, transcoding services (e.g., TypeTalk) or other media processing, and could include multiple simultaneous or alternative media streams.

This means that any User Agent in the session (including transcoding services) should be able to add or remove a media stream from the session without having to tear down the session and re-establish it.

6.3. User Profile
This requirement states:
Deaf, hard of hearing and speech impaired user abilities and preferences MUST be communicable by SIP and these user 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:
· Mode of communication that can be received and that can be 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 relay service (for example, the message from TextDirect states 'incoming text call' without saying that a deaf person is calling)

It MUST be possible for deaf, hard of hearing and speech impaired people to hide their preferences and abilities from other users (for reasons of confidentiality, e.g., to not incur discrimination or prejudice) and still be able to establish a SIP session.

Note: These requirements are addressed to existing attributes of SIP, and are not intended to suggest SIP code changes.

Further specific user preferences, organised into category, are listed in Examples of User Requirements on page 12.

6.4. 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, the user could have a SIP User Agent acting as a gateway to a PSTN legacy textphone.

For further discussion, see User Agents and Gateways on page 17.

6.5. 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.

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.

For a short discussion on the issues raised by this requirement, see Inclusive Design Issues on page 17.

6.6. Resource Management
This requirement states:
User Agents should be able to identify the content of a media stream in a session and provide this information to the user, including 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 (for example, whether a transcoding service carries a particular media stream), and any policy constraints they impose (for example, charging for use). It should further be possible for User Agents to discover what alternative media are available and to choose among them. 

A further discussion on Resource Management Issues is continued on page 18.

6.7. 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 users 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. 

This means that transcoding services (e.g., interpretation, translation) MUST publish their confidentiality and security policies.

Note: This requirement recognises emerging regulatory conditions world-wide that allow for the surveillance and interception of electronic mail by legal authorities.

For a further discussion on confidentiality and security issues, see Confidentiality and Security on page 20.

Examples of User Requirements
The requirements below were extracted from draft-vanwijk-sipping-deaf-req-00, edited where appropriate and organised into the categories of User Agent, Transcoding Service Requirements, and Other.

User Agent Requirements
A User Agent MUST be able to:
1. Provide signalling information to the user in visual as well as audio format, which means, for example, that an engaged tone would have a visual graphic or symbol.
2. Receive transcoding service calls any time and from any location. User preferences in the REGISTER will indicate the requirements of a transcoding service (support for text must be a minimum requirement). Upon logging in, the User Agent should be able to automatically download all user settings from a user-specified location.
3. Activate or disable a transcoding service during a call without interrupting the call. 
4. Allow the configuration of a wide variety of user preferences, for example, spoken language (English to Spanish), mode (video to speech), etc. Commonly available settings can be pre-configured but it should be easy to over-ride them. User Agents and transcoding service providers should be able to enable and deliver services like a "real-time closed captioning" where the User Agent receives the video/audio of a caller/call-recipient, and the transcoding service translates the audio and displays the text in subtitles.N
 ote: This offers possibilities for commercial translation services (via voice-over or text).
5. Recognise the caller IDs of deaf, hard of hearing or speech impaired users routed through a transcoding service, rather than ID of the transcoding service. 
Note: This refers to the caller ID and not the SIP ID.
6. Identify calls that need to be routed through a transcoding service apart from direct calls (textphone to textphone for text, video to video for sign language).
7. Download and upload user information from a central repository (preferably a database or centrally located server maintained by the transcoding service- or home- provider).
8. Distinguish regular calls from transcoding service and direct textphone calls when the number is NOT listed in the address book. 
9. Allow calls to be placed anonymously, so that the call-recipient cannot identify the person calling or their telephone number.
10. Place calls without hindrance, allowing the User Agent to connect to the transcoding service and connect to the call-recipient automatically.
11. When recalled, poll for the nearest transcoding service provider, reducing data traffic and the cost of using the network, and change transcoding service providers at any time (preferably through a menu list of transcoding service providers).
12. Provide a transcoding service provider list in order of preference, for example, priority calls, etc.

Transcoding Service Requirements
Transcoding services MUST be able to:

1. Allow calls to be placed anonymously, so that the call-recipient does not know who is calling. This means keeping the identity of the caller confidential.
2. Show the cost per minute and any minimum charge of a transcoding service call before a session begins, so that the user can refuse the service if charges are too high, or change to a cheaper service (for example, text instead of video).
3. Translate voice messages into the format designated by the user (email, video, etc.), and transmit this to the user's User Agent, either when it registers or on demand. 
4. Advertise their services (either through a central voluntary registration or through a dialled information number), including information on new services. 
Note: This would stimulate competition between transcoding service providers, and lead to lower service prices and/or more different kind of services.
5. Provide answering machine message services so that the User Agent can retrieve messages. The User Agent should have a pre-configured setting for automatically connecting the caller to the answering machine service of a transcoding service provider when the user does not want to receive incoming calls. This should be implemented without extra handling of the call (assuming that the call-recipient has subscribed to this service). 
Note: An "answering service" could also be a commercial service for hearing users. If a third party unified messaging service is used by the hearing impaired user, a specific transcoding service provider should be authorised to access the unified message box and translate all audio messages into a pre-selected form. For example, voice to text or voice to video for sign language.
6. Operate in STEALTH mode, that is, provide an invisible transcoding service for the caller so that they can conceal if they are deaf. This could be a separate service, with an additional charge to cover the speed of accepting the call (minimal delay on picking-up) and of making the caller anonymous to the call-recipient. Special hardware and software may be required for a computer to perform speech to text conversion (this may require specialised transcoding service providers). 
7. Additionally, the transcoding service provider MAY also offer remote interpreting, and the User Agent MAY be modified to use this service. This would help in countries experiencing a shortage of interpreter or situations which only require a short time of interpreting.

Other User Requirements
A User should be able to:
1. Store user preferences and settings on the web (e.g., Yahoo), or in the case of a mobile user, a wireless web service, so that a user can access a personal profile from any web-enabled device.
2. Use an independent payment service provider, so that transcoding service providers can be assured of payment for charges. Users can pay in the form of subscriptions for any of the additional features of a transcoding service. 
3. Additionally, wireless telephony systems (GSM, cellular systems, etc.) MUST enable wireless phones to connect to transcoding service providers. This can be done directly via wireless IP connections OR via a special node, effectively translating circuit switched (GSM, etc.) relay into IP relay.
4. Automatically poll for media services providers that are locally available.

User Agents and Gateways
This is a continuation of the various discussion threads on this subject on the SIPPING list. 

Basically, the architecture of a SIP-enabled network would be intelligent User Agents on a dumb network, with the User Agents able to hold multiple media streams, and able to delegate nodes on the network periphery to act as gateways for non-IP devices and communications. User Agents can reside in transcoding services, media providers, users, etc., and not necessarily in the user end-equipment. 

While the user requirements listed in this document are addressed in the most part to device configuration and design, that is, facilitating communications outside a SIP-enabled network, the requirements in this document are intended to focus communications standards at a high level for a SIP-enabled network. 

The intention of this document is to provide a set of user requirements that will readily connect the deaf, hard of hearing and speech impaired community to an IP-based network, using the mode and device of their choice. 

Inclusive Design Issues
In relation to user requirements for SIP-enabled communications, SIP User Agents acting as intelligent gateways would facilitate any required connection to a legacy system device.

Voice-based telephony connections to transcoding service providers would not be a factor in SIP-enabled communications. However, as a user might require voice-based telephony communications, this could be accepted in the user requirement of User Agents as intelligent gateways.

Resource Management Issues
This requirement has stimulated a lot of discussion because it involves the inter-operability of various service groups, services on offer, communication abilities and preferences, and because the requirement addresses the current state of transcoding service or intermediary services on offer. 

The current availability of media streams, specifically in the United Kingdom, is somewhat restricted because of:
· The limitations of a national sponsored transcoding service
· Legacy communication devices for deaf, hard of hearing and speech impaired people
· Media service companies (Radio, TV, etc.) in the process of advancing their technologies to include media streams across the Internet. 

However, the requirement solicits an improvement in the services of media stream providers. This means that when a media stream is available, it would have the cost of receiving it, the speed of transmission, etc., and whether a transcoding service can support it or not, and whether the stream can be redirected if there is no support for it.

Perhaps it is best to present an example scenario that illustrates the requirement and presents a solution of how multiple sessions involving users, transcoding service providers and media streams would be intelligently handled by SIP. 

Resource Management Scenario
1. A deaf person employs a User Agent in order to listen to a radio program. 
2. The deaf person's user preferences specify that for audio streams, text is the format required.
3. The radio station in this case does not have the capacity for providing text with their audio stream, and the User Agent then forwards the request for text to a transcoding service.
4. But although the transcoding service supports audio streams, in this case it does not have the resources to support a Radio broadcast stream without becoming overloaded. The transcoding service User Agent then has to refuse the interaction and inform the caller.

Of course, there are other scenarios in which the radio station DOES provide text with the audio stream, or that the transcoding service DOES have the resources to support radio broadcasts with other audio streams.

However, the example and the requirement needs a technical solution in which the caller's User Agent can go anywhere in the SIP universe, select a media stream and identify whether it suits the abilities and preferences of the caller, its cost and other rules of access, choose if these rules are acceptable, and if not, whether there are other options.

Confidentiality and Security
Issues
This section summarises the security and confidentiality issues of all interactions on the behalf of a deaf, hard of hearing and speech-impaired person that require the assistance of a third party, including:
· Transcoding services (e.g., relay services)
· Translators
· Interpreters.

Security in this case is defined as the mode of communication (e.g. telephone) which is only open to the call participants, including any intermediary (interpreter) that has been invited by a call participant to take part.

The definition of confidentiality is that the contents of any communication are not disclosed by the intermediary to anyone other than the call participants. Intermediaries are bound to a non-disclosure clause through the ethical standards of the organisation that they represent and through their training. Any records of the communication must be destroyed. 

The essential requirement for a user is that any interaction through an intermediary or third-party must be confidential to protect the user from disadvantage, prejudice or discrimination. 

However, it must also be considered that confidentiality is applied through an agreement of trust and this is difficult to enforce. The main guarantee of confidentiality in this kind of interaction is the reputation of the interpreter and interpretation service and the evidence of a published code of conduct. 

The issue can become further complicated if the need for confidentiality is required of a third-party that does not usually handle communications for deaf people, or that confidentiality cannot be guaranteed because of the intervention of a legal authority (that is, legal intercept in an electronic mail service). 

Professional and Ethical Standards
The main discussion point of this section is to re-emphasise the need for a common set of standards and professional ethics by service groups and organisations, which act as a third party or intermediary, in communications for the deaf, hard of hearing and speech impaired. 

Although necessary, ethical standards are difficult to implement. However, it is possible for various groups, already established in the role of third party intermediary in deaf, hard of hearing and speech-impaired communications, to recognise the validity, and if necessary, adjust local or regional professional and ethical standards to a more globally acceptable focus. 

There are several well established and respected service organisations acting as third party intermediaries in speech and hearing impaired communications. For example, the National Association of the Deaf (NAD) and the Registry of Interpreters for the Deaf (RID) in the US, along with The Royal National Institute for Deaf People (RNID) in the UK. 

Generic Ethical Statements
The following are a consensus of basic standards of conduct employed by a variety of services and organisations dedicated to deaf, hard of hearing and speech impaired, both in the UK and the USA.

All personnel working with interpreting, transliterating, or facilitating communications for deaf, hard of hearing and speech impaired people are required to:
1. Keep information exchanged during the transaction strictly confidential
2. Facilitate information exchange literally and simply, without deviating and compromising the content
3. Facilitate communication without bias, prejudice or opinion
4. Match skill sets to the requirement of the user
5. Behave in a professional and appropriate manner
6. Be fair in claiming compensation for services
7. Strive to improve the skill-sets used for their services.

************************************************************************
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to
whom they are addressed. Any views or opinions expressed
are solely those of the author and do not necessarily represent
RNID policy.

If you are not the intended recipient you are advised that any
use, dissemination, forwarding, printing or copying of this
email is strictly prohibited.

If you have received this email in error please notify the RNID
network manager by telephone on: +44 (0) 207 296 8098.
************************************************************************

_______________________________________________
Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP