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

[Christian Groves <[e-mail]>]

Hello,

One thing that doesn't seem to be noted is an overlap with the work of 
the CLUE WG. There has been some discussion in the CLUE working group 
about adding attributes to captures to describe the language, whether 
sub-titles are used, whether a stream comes from an interpreter, etc. 
Where multiple streams are used I would expect any work in this area 
should be aligned.

Regards, Christian

On 17/03/2013 6:37 PM, Gunnar Hellstrom wrote:
> 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
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>