Re: [MMUSIC] Notes from Orlando human language draft discussion

[Hadriel Kaplan <[e-mail]>]

Preface note: I am not against the needs of hearing-impaired or visually-impaired people - I'm asking the questions because I think the simpler the mechanism is, the more likely it will be to actually work and be deployed, and thus not hinder such cases.

I may be very very wrong, and I'd certainly defer to those who know for sure, but I would think they'd want the call to succeed for the media types they need to use, rather than only succeed if the specific directionality traits of those media lines are supported by the other side.

For the below comments, I'll use 'sign-language' as a token, although I assume there must actually be many tokens since there are many sign languages.

Other comments inline...


On Mar 16, 2013, at 5:32 PM, Gunnar Hellstrom <[e-mail]> wrote:

> On 2013-03-16 20:54, Hadriel Kaplan wrote:
>> What's the use-case when the two directions are not identical?  I.e., when does it make sense to receive Latin but send Swahili for the same media?
>> I ask because this separation complicates things quite a bit in code/testing/error-handling, obviously.
> Examples are:
> 
> 1. Deaf-blind person who want to use sign language in video out, but cannot see it in reception and therefore declare language in video only for send video.
> ( also declaring preference for reading text and acceptance for typing text )

So just indicate 'sign-language' for video media, and have a text media line.
It will be very clear to the far-end when they see the caller is blind that they can only see sign language but not send it.  Or if you want to make it one-way video on the wire, that's what the 'a=sendonly' is for. (same goes for text media line)

The important thing is that you need to reach someone who can understand your sign language.


> 2. Hard-of-hearing person who want to talk in audio channel, but cannot hear answers , and therefore declare languge for audio only in send audio
> ( also declaring preference for reading text and acceptance for typing text )

If you literally only want to send audio but not receive, use 'a=sendonly' for the audio line, and have a text media line.  If, however, you mean they want bi-directional audio but a preference to reach someone who can also do text, or video for sign-language, send normal audio and text media lines, or with a 'sign-language' video line.

The important thing is that you reach someone who can hear you, and can type text back to you (or do sign language).


> 3. Person with speech disabilities who want to hear in audio channel, but cannot use audio for talking
> ( also declaring preference for typing text and acceptance for reading text )

Same as above, but with 'a=recvonly' if you literally want one-way on the wire.
The important thing is you reach someone who can talk to you, but also can read text from you or see your sign language.


> By the way, here we have a tricky case:
> 4. Person with speech disabilities who want to hear in audio channel, and talks unclearly, so that he want a speech relay service to listen to the call and clarify what got hard to understand for the other party.
> Maybe that service needs to be requested with an explicit service request instead of language and modality matching?

I have not looked into how such relay services work, for example VRS.  It would be good to know how they're used in practice. (I can imagine several ways they could be done)

-hadriel