Subject: Re: [Sipping] RE: Hearing and Speech Impaired UserRequirements for SIP Communications (Mike Hammer)

From: "Guido Gybels" <[email-masked]>
Date: Thu, 27 Sep 2001 09:32:40 +0100

Mike,

you wrote:

<<Could you clarify:>>

<<Guido: For instance: when a UA connects to the UA of a radio broadcastingc
 ompany, the radio UA might tell the listener's UA that it provides both 
an audio and a text stream. In case the listener is a deaf person, he/shew
 ill have set up his preferences to receive incoming audio as text (for ar
 egular voice call this means that the incoming speech stream will have tob
 e rerouted through a relay service). So, in that case, the listener's UAw
 ill connect to the radio station's *text* stream, rather than the audio 
stream.>>

<<Mike: Why would the listener want to expend resources (both network and relay) to 
translate what is already provided in text form at the source?  Would thisr
 esult in two different versions of the text?  Wouldn't the user just tellt
 he source, send me only the text stream?>>

I'm not sure I understand what you are asking here. Where did I say I wanted both the network and the relay to perform translation?? In a SIP world, the relay service (like TypeTalk) is just another SIP agent. It is inlcuded as a third party in the conversation. As far as I can see, the current SIP protocol will have no trouble whatsoever in setting up that kind of conversation,.
Let's take an example: a deaf person that wants to engage in a communication with a hearing person. The deaf person will have his preferences stating that he will be sending out text, but no audio (voice if you prefer) and that he wants to receive text, and no audio. The hearing person however will be able to send and receive audio.
In this scenario, the text output from the deaf person will be relayed to a third party, like TypeTalk. They will receive text and transform it into speech (currently using a human operator, but in the future we might get text-to-speech technology for this) and transmit that speech to the hearing person. In the other direction, audio coming from the hearing person will be relayed through TypeTalk where it will be transformed into text and sent to the deaf person.
Now, if a deaf person connects to a radio source, the relay service (TypeTalk) might not want to receive this for transformation into text (because there is a resource management issue, obviously, if deaf people are going to use relay services like TypeTalk for listening to radio broadcasts). That is why the relay service, TypeTalk, wants to signal that to the deaf person while the radio station should be able to signal that it provides a text stream as an alternative to the audio stream.
In that case, since the deaf user sets his/her preferences to indicate that audio streams should be received as *text*, at some point the network (?) should decide what to do. In the case of a "voice" communication to a hearing party, it will have to reroute "seamlessly" (yeah, yeah, I know <g>) through TypeTalk while in case of the radio station, it should simply connect to the text output of the station, rather than to the audio stream. In case of radio, if *no* text stream is available (i.e. the service provider does not supply a text equivalent of its audio output), the deaf person will be unable to connect to it and the connection fails (because the alternative like TypeTalk refuses this kind of connection).
I hope this also illustrates the importance of describing content and character of media streams. I'm not *deciding* what should go where (i.e. whether this is a network issue or a service provider topic, or both). That is why we have this discussion! To get input from the entire community on this!
I would however, appreciate it very much if people could come up with a clear solution for the situation I described as well as for other possible scenarios that might come out of this.
Oh, and BTW: yes, text output (like for instance subtitling) might be different for a deaf person when compared to a hearing party that uses text as support or for translation issues (for deaf persons, you will intersperse clues about the kind of music, background noises, etc that for instance translation-subtitles for hearing people will not include).

Guido

Guido Gybels
RNID, Head of ICT
[email-masked]
Tel +44(0)20-7294 3713
Fax +44(0)20-7296 8069
---
Royal National Institute for Deaf People
19-23 Featherstone Street
LONDON EC1Y 8 SL
Phone 020-7296 8000
TextPhone 020-7296 8001
Fax 020-7296 8199

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