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

From: Michael Hammer <[email-masked]>
Date: Mon, 01 Oct 2001 11:03:25 -0400

Guido,

This may be simply a misunderstanding of words used.  See inline.

Mike

At 09:32 AM 9/27/2001 +0100, Guido Gybels wrote:
>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.<<<<<

Here, both are provided by the source.

>In case the listener is a deaf person, he/shew
>  ill have

>set up his preferences >>>>> to receive incoming audio as text <<<<<

Here it says to me that the audio stream is translated.

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

The above seems to say that translation may be needed in only some 
cases.  Below, you indicate that there are possibly differences, leading me 
to believe that you would intend for both the original text stream and a 
text stream interpreted from the audio stream to be provided.

My only observation at this point is that the content of the two stream 
could be different and that the interpreter may in fact inject error or 
"noise" into the situation.

I think that the usage of these type of services is the choice of the 
requesting user and how is an implementation detail, so long as the session 
setup can be done.

>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