Re: [Slim] Extended functionality for the real-time language negotiation

[Arnoud van Wijk <[e-mail]>]

Hi Gunnar,

I also prefer solution 1.2 and 2.2

I like the use of q values here. I think that is better then adding a 
new attribute.


Good proposal.


/Arnoud



On 07/03/2017 14:01, Gunnar Hellström wrote:
>
> This is a slightly improved extract from the summary of the LC period 
> for the real-time SLIM draft about two discussed functionality 
> extensions. (Some of the examples had copy-paste errors.)
>
> The intention is to discuss this topic as far as needed to decide if 
> any or both these functionality enhancements could go into the current 
> draft before publication, and if not included then decide if any 
> changes are required in the current draft in order to accommodate for 
> the extensions.
>
> (see the summary sent on March 4 for e.g. references to the other 
> summary points.
>
> ----------------------------------------------------------------------------------------------------------
>
> *n). Indication of preference between media, and of simultanous versus 
> alternative languages.*
>
> This is a summary of the remaining issues related to items e), f), j) 
> and m) above.
>
> Issue e) proposes changes to enable indication of preference for 
> language in different media.
> Issue f) requests possibility to indicate request or offering of text 
> captions of spoken language.
> Issue j) proposes use of the Accept-Language syntax, that could both 
> solve the functional needs
> of e) and f) and sort out the syntax and semantics problems of the 
> asterisk parameter.
> Issue m) just indicates that issue e) is not yet resolved.
>
> Randall has proposed to resolve the functional needs in a new draft, 
> and not accept the Accept-Language syntax.
> I have proposed a simple way to resolve issue e) - the preference 
> between media, at the same time improving the definition of the 
> semantics of the asterisk parameter.
> No real solution to issue f) - the simultaneity indication  has been 
> discussed.
> Issue j) - the proposal to use the Accept-Language syntax can 
> potentially be used to resolve issues e) and f).
>
>  Discussion:
> Issue e) says that there is a need to be able indicate which of a set 
> of language/media indications are more preferred alternatives than others.
> Examples are:
> 1. A want to get written English in text, A can as a less preferred 
> alternative accept to get spoken English.  An answering party B who 
> can use text will then respond with written text and get good 
> satisfaction, while another answering user C without text capability 
> will answer in spoken English and have a possibility for a reasonably 
> successful call.
> Without this indication, the first answering party B may have seen the 
> spoken and written alternatives as true equal preference alternatives 
> and answered with spoken English that will result in less satisfied 
> users.
> 2. A Prefer to receive spoken language, and can accept to receive 
> text.   When answering party B can use spoken language, that will be 
> satisfied, otherwise written language will be used.
> 3. A Prefer to use spoken language in both directions, and can accept 
> to use sign language in video in both directions. Answering party B 
> has a clear indication of why both signed and written is indicated and 
> can answer according to its capabilities trying to satisfy the 
> preference for spoken language.
> 4. A Prefer to use  sign language in both directions and can accept to 
> use written language in both directions. Sign language users will use 
> sign language, others will use text.
> 5. Prefer to send sign language and receive text (deaf-blind user), 
> can accept to send text.  In a call with a person with similar 
> prefeences, text will be used both ways, otherwise sign one way and 
> text the other.
>
> etc.
>
> Issue f) requires a way to indicate use of captioning and other 
> situations where use of simultaneous languages in different modalities 
> are needed:
>
> 1. Preference for hearing spoken language and simultaneously read 
> written language in text. ( captioning) .   The time is here when this 
> can be provided automatically in some settings, but also traditionally 
> by a manned service.
> 2. Preference for hearing spoken language and simultaneously seeing 
> the speaker in video.   (lip-reading).  Easily and naturally provided 
> once the need is known.
> 3. Preference for seeing sign language and simultaneously hear spoken 
> language in audio.  ( for multiple users at the terminal )    One of 
> the streams is provided by an interpreter.
> 4. Preference for hearing spoken language and simultaneously view 
> written language in video. (captioning if we accept to specify text as 
> overlay on video, otherwise it is same as number 1.)
>
> Some of these can be acceptable also if just one of the language/media 
> combinations can be provided, but is much more preferred if both can 
> be provided together. In other cases it is essential to get both 
> simultaneously. There is a need to differentiate in the indication 
> that this preference for getting the languages together is preferred.
>
> Alternative coding proposals:
> 1. Preference between language/modality
> 1.1 Based on draft -08, add the coding of an asterisk last in an 
> attribute to mean lower preference for a lanugage/media combination 
> than the one(s) without an asterisk.
> example
> m=audio
> a=hlang-recv:en*
> m=text
> a=hlang-recv:en
>
> Audio and text are alternatives and text preferred
>
> 1.2. Change to the Accept-Language syntax and let the q-values have 
> scope over the whole SDP.
>
>   m=video 51372 RTP/AVP 31 32
>   a=hlang-recv:ase;q=0.9
>   a=hlang-send:ase;q=0.9
>
>
>   m=text 49250 RTP/AVP 98,99
>   a=hlang-send:en;q=0.5,*;q=0.1
>   a=hlang-recv:en;q=0.5,*;q=0.1
>
> Sign language is higher preferred than text.
>
>   
>
>
>
> 1.3. Introduce a new a=modality attribute on media level, with 
> parameters: <modality>, <direction>, <preference>
> example:
>
> m=text
> a=modality:written,recv,hi
> a=hlang-recv:en*
> m=audio
> a=modality:spoken,recv,med
> a=hlang-recv:en*
>
>
>
> 2. Preference for simultaneous languages vs alternative languages:
>
> 2.1. Based on draft -08, add another notation to the use of the 
> asterisk, e.g. an optional character to be used together with the 
> asterisk to mark media that are wanted together. (ugly) example:
>
> m=audio
> a=hlang-recv:en*$c
> m=text
> a=hlang-recv:en$c
>
> The $ is a simultaneity indication, the c is a groouping indicator 
> telling that all modalities marked with the $c are wanted together. 
> (we might be able to restrict the indication to just one set of 
> languages that are wanted simultaneously.
>
>
> 2.2. Use the Accept-Language syntax and add the usage rules that 
> q-values with less than .1 difference mean languages with a preference 
> to be used together. Higher differences indicate that they are 
> alternatives.  Thereby it is both possible to indicate simultaneity 
> and preference if the simultaneity cannot be satisfied.
>
>   m=audio 51372 RTP/AVP 0
>   a=hlang-recv:ase;q=0.5
>   a=hlang-send:ase;q=0.5
>
>
>   m=text 49250 RTP/AVP 98,99
>   a=hlang-send:en;q=0.51,*;q=0.1
>   a=hlang-recv:en;q=0.51,*;q=0.1
>
> The q-values differences are within 0.1 so it is a preference for getting both together, but if that is not possible, text is preferred.
>
>
> 2.3. Add to the new a=modality attribute a fourth, optional parameter 
> [simultaneity]   with value any single letter, indicating a preference 
> for having that modality simultaneously with another modality 
> indicated with the same value in the [simultaneity] parameter.   
> Without this parameter, the modalities are alternatives.
>
> m=text
> a=modality:written,recv,hi,d
> a=hlang-recv:en*
> m=audio
> a=modality:spoken,recv,hi,d
> a=hlang-recv:en*
>
>
> *
> *
>
> ***Status: Not solved. Conclusion needed on how to handle these issues 
> e, f, and j,  both regarding which solution and what procedure to take 
> to apply it.*
>
> I have a slight preference for solution 1.2 and 2.2 ,
>
> Your views?
>
> Regards
> Gunnar
> -- 
> -----------------------------------------
> Gunnar Hellström
> Omnitor
> [e-mail]
> [phone]
>
>
> _______________________________________________
> SLIM mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/slim