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

[Gunnar Hellstrom <[e-mail]>]

On 2013-03-17 01:21, Hadriel Kaplan wrote:
> 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.
Yes, we said so yesterday:
Other media and media directions than the ones you declare preference 
for are usually also appreciated, and sometimes important.
You said some time ago that a medium-direction with no language 
indication just means that there is no preferred language use of it, but 
it may very well be desired in the call and should be connected if 
supported. That was why the a=sendonly and a=recvonly attributes cannot 
be used for preference indications.
>
> 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.
The need came from the relay service examples.
But let us try to fancy a need from the spoken language side:
A high level conference is held with English as main language but 
possibility to get interpreting to and from other languages.

A delegate from Kenya feel well confident in listening directly in 
English, not risking delays and dropouts through interpreters, but feel 
much more confident in expressing herself in Swahili when she speaks. 
Therefore she selects that combination and the remote conference is set 
up so that she get the Swahili interpretation when she talks.
>> 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.
No, the important thing is to have a chance to rapidly evaluate either 
how to route the call to someone who match the preferences, or to add 
services doing translations so that the preferences are fulfilled.

It is not good to let the deaf-blind user be connected with a person who 
has only video enabled.
>
>
>> 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.
We said yesterday that that is not the case, we are not discussing 
sendonly etc.  It is use of the media we are discussing.  Support of the 
media is another thing, already well covered in both SDP and SIP.
>   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)
Read
http://www.etsi.org/deliver/etsi_es/202900_202999/202975/01.02.01_60/es_202975v010201p.pdf

>
> -hadriel
>
/Gunnar