Subject: [Sipping] Hearing and Speech Impaired User Requirements for SIP Communications

From: "Julian Branston" <[email-masked]>
Date: Wed, 19 Sep 2001 18:13:01 +0100

This message is with reference to the Internet draft draft-vanwijk-sipping-deaf-req-00.txt which discusses the potential of SIP communications over the Internet for hearing and speech impaired people, and raises various issues for this user group. 

Sections 7 and 8 of the draft listed a set of requirements for hearing and speech impaired people, readily implemented through SIP. 

At IETF 51 in London, it was decided to extract these statements and synthesise them into a set of user requirements. I am now submitting these to the SIP discussion lists for comments on clarity and robustness, with the aim of using the results as the basis for a separate internet draft.

Here are the user requirements as mentioned, supported with examples as appropriate.

Comments are sought and would be appreciated.

Best regards,

Julian Branston
___________________________________________________________
1. Seamless Connection
Requirement: 
Whatever the preferences and abilities of the caller and call-recipient, their connection MUST be seamless, that is, readily established across different communication routes, including through a Relay Service, and supporting multiple media streams. 

This means that the caller should be able to add or remove media streams (for example, add subtitling or re-route a stream through a relay service) at any point during the session without interrupting the call.

2. User Preferences
Requirement:
The User Preferences of a hearing and speech impaired caller and call-recipient SHOULD be easy to set up and SHOULD determine the rules of the connection.

The User Preferences for a hearing and speech-impaired person might include:
· Roaming (for example, a deaf person accessing their User Preferences from a web-interface at an internet café)
· Anonymity (that is, not revealing that a deaf person is calling, even through a relay service)
· Mode of communication (text, voice, video, or any combination)
· Redirecting specific media streams through a relay service.

User Preferences should belong to the user, that is, are proprietary, with full rights of the user to withhold or release these preferences.

3. Intelligent Gateways
Requirement:
SIP SHOULD support a class of User Agents to perform as gateways for legacy systems.

For example, the user could have a SIP User Agent acting as a gateway to a PSTN legacy text phone (V18).

4. Inclusive Design
Requirement:
Where applicable, design concepts for communications (devices, applications, etc.) SHOULD include the needs of the deaf, hard of hearing, and those with speech impairment.

Relay services and terminals must be able to connect with each other regardless of the provider or manufacturer. This means that new terminals should be able to support legacy protocols through appropriate gateways.

5. Resource Management
Requirement:
User Agents should be able to query relay and similar services about what they provide (for example, whether a relay service accepts a particular media stream) and the rules around their service (for example, cost), while these services should be able to feed this information back to User Agents. Relay services and User Agents should be able to identify the content of particular media streams. 

For example, a caller wishing to listen to a radio program (Radio 4) would be re-directed from the TypeTalk relay service, and the radio station would provide information about the availability of the audio stream through a text stream.

This means that relay services and User Agents will ensure Quality of Service by determining whether to accept or reject a service, based on speed, quality, and cost.

6. Confidentiality and Security
Requirement:
All communications involving interpreters, translators, and relay services with deaf and speech-impaired users MUST be confidential and secure.

This means that Interpretation, Translation and Relay Services MUST publish their security and confidentiality policies.

************************************************************************
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

---

From: "David R. Oran" <[email-masked]>
Date: Tue, 25 Sep 2001 11:24:18 -0400

The intent of these requirements is great, and I have no argument with
any of the underlying motivations. However, since these requirements are
meant to motivate engineering tradeoffs and the specification of
protocol machinery and possibly usage standards, I find myself wanting
to be a bit anal about the actual words.

I've interspersed some comments and suggested wording changes.

[snip]
> Whatever the preferences and abilities of the caller and 
> call-recipient, their connection MUST be seamless, that is, 
> readily established across different communication routes, 
> including through a Relay Service, and supporting multiple 
> media streams. 
>
I don't like the word "seamless" since I have no idea what it means.
Similarly for words like "transparent". Saying this tends eliminate
valid engineering tradeoffs in which the differences are noticeable by
the hearing/speech impaired, but not inconvenient or limiting. I'd just
lose the word and use the definition of what you actually want, which
starts after the "that is". My suggested wording would be:

"Useful sessions must be establishable via SIP with any combination of
hearing/speech impaired users and non-impaired users. The establishment
and maintenance of such SIP sessions must allow for multiple proxies
making call routing decisions, as well as the use of relay services
which perform transcoding and other forms of media processing. Sessions
using multiple simultaneous or alternative media streams must not be
precluded.
 
> This means that the caller should be able to add or remove 
> media streams (for example, add subtitling or re-route a 
> stream through a relay service) at any point during the 
> session without interrupting the call.
>
Why can't the callee do this? I suspect that was just an oversight in
the wording. Also, I don't think the words "interrupting the call" have
any useful technical meaning, since it could be anything between a 200ms
glitch and a complete drop/re-establish cycle. I'm not sure anything
needs to be said here since SIP already handles re-invite which does
media-stream addition/deletion, but if it's important to drive the point
home, I'd suggest something along the lines of:

"Any of the session participants (including a relay service) should be
able to add or remove a media stream from the session without having to
tear down the session and re-establish it."

> 2. User Preferences
> Requirement:
> The User Preferences of a hearing and speech impaired caller 
> and call-recipient SHOULD be easy to set up and SHOULD 
> determine the rules of the connection.
>
I'm not sure either the SIP or SIPPING WGs have any charter which would
affect the ease with which user preferences are set up. All we can do is
make sure the user preferences can be communicated properly in the
protocol and that these preferences govern the session where the parties
agree. I would restate this as:

"User preferences related to session handling for hearing/speech
impaired  users MUST be communicable in the SIP protocol. Subject to the
policies of the session participants, these preferences SHOULD, where
feasible, determine the handling of the session".

> The User Preferences for a hearing and speech-impaired person 
> might include: · Roaming (for example, a deaf person 
> accessing their User Preferences from a web-interface at an 
> internet café) · Anonymity (that is, not revealing that a 
> deaf person is calling, even through a relay service) · Mode 
> of communication (text, voice, video, or any combination) · 
> Redirecting specific media streams through a relay service.
>
These are fine.
 
> User Preferences should belong to the user, that is, are 
> proprietary, with full rights of the user to withhold or 
> release these preferences.
>
I'm not sure I understand what this means from a technical perspective.
Does it mean that a hearing/speech impaired must be able to use
intermediaries he trusts to hide these preferences from other end users,
or only that the speech/hearing impaired user's UA should be
controllable by the user to tradeoff the communication of the
preferences in exchange for the possibility that the wrong kind of
session gets set up? I suspect you mean the former. If so, perhaps the
following captures this better:

"It must be possible for hearing/speech impaired users to employ either
user agent policies or trusted intermediaries to hide their preferences
from other users while still being able to establish useful sessions".
 
> For example, the user could have a SIP User Agent acting as a 
> gateway to a PSTN legacy text phone (V18).
> 
This one's fine as is.

> 4. Inclusive Design
> Requirement:
> Where applicable, design concepts for communications 
> (devices, applications, etc.) SHOULD include the needs of the 
> deaf, hard of hearing, and those with speech impairment.
> 
> Relay services and terminals must be able to connect with 
> each other regardless of the provider or manufacturer. This 
> means that new terminals should be able to support legacy 
> protocols through appropriate gateways.
> 
I don't see what SIP or SIPPING can do about this requirement, but I
also don't see a way of changing the words so this requirement is
actionable.

> 5. Resource Management
> Requirement:
> User Agents should be able to query relay and similar 
> services about what they provide (for example, whether a 
> relay service accepts a particular media stream) and the 
> rules around their service (for example, cost), while these 
> services should be able to feed this information back to User 
> Agents. Relay services and User Agents should be able to 
> identify the content of particular media streams. 
> 
This is going beyond requirements and starting to get into mechanism,
since it talks about "querying", and later, about "redirecting". I'm not
100% certain what you're getting at here, but my stab at what the actual
requirement is would be:

"User agents should be able to choose among relay and similar services
based on their capabilities (for example, whether a relay service
accepts 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.

Further, I'm afraid I don't understand what it means to "be able to
identify the content of particular media streams" - this sounds like
legal intercept. Do you instead mean the user agents and relay services
have to have a common description language for identifying the kind of
payload carried by a particular stream? If so, isn't this just SDP? If
not, could you elaborate?

> For example, a caller wishing to listen to a radio program 
> (Radio 4) would be re-directed from the TypeTalk relay 
> service, and the radio station would provide information 
> about the availability of the audio stream through a text stream.
> 
This example, while valid, is a poor one for SIP, since this application
would be much better done with RTSP. Have you made these requirements
known to the MMUSIC WG so they can ascertain whether any additional work
is needed on RTSP to accommodate examples such as this (I suspect RTSP
in fact already can do exactly what you propose here, but I'm not sure).

> This means that relay services and User Agents will ensure 
> Quality of Service by determining whether to accept or reject 
> a service, based on speed, quality, and cost.
> 
I'm quite nervous about this part of the requirement, since we don't do
it for any other preference. On the other hand, I don't see a problem
with asking for such capabilities.

> All communications involving interpreters, translators, and 
> relay services with deaf and speech-impaired users MUST be 
> confidential and secure.
> 
Ummmm...I don't think we can mandate this, especially in light of
conflicting requirements for legal intercept. In fact, doing so requires
a trust analysis of the communicating parties, which is clearly beyond
the scope of what a protocol can do. I think this needs to be restated
as something like:

"Employing intermediaries such as interpreters, translators, and relay
services which are trusted MUST not reduce the confidentiality and
integrity of communication compared with a direct user-to-user session".

> This means that Interpretation, Translation and Relay 
> Services MUST publish their security and confidentiality policies.
>
This doesn't necessarily follow. If a speech/hearing impaired user puts
up his own relay service, there should be no requirement for him to
publish its policy. Furthermore, this requirement is not actionable by
either the SIP or SIPPING WG in any case. I don't have suggested
replacement wording here.

Hope you found these comments helpful.
Cheers, Dave.