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

[Gunnar Hellström <[e-mail]>]

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]