Subject: [Slim] Relative preference between media

From: Gunnar Hellström <[email-masked]>
Date: Sun, 4 Oct 2015 12:27:32 +0200

A feature lacking from the current real-time slim draft is to specify 
relative preference between media. Only relative preference between 
different languages in the same modality is currently possible.

The lack of that feature makes it not possible to specify combinations as:
"I prefer to use sign language but can accept to communicate in text",
"I prefer to use speech, but have some sign language competence",
"I prefer to speak, and receive text, but can as last resort use hearing 
for reception".
etc.

Some of these are quite essential for the usefulness of our indications.

I have requested earlier that we should assign an indication of a simple 
absolute preference per language tag, e.g. in three levels. "stongly 
preferred", "can use" and "may use with low preference".

I have now realized that by introducing a possibility to use the 
language tags on the session level and have references to labels in 
m-lines to show what medium they refer to, we can solve both the need 
for relative preference between modalities, and get a well condensed 
language indication block that is easy to parse for negotiating and 
gatewaying.
However, it does not enable any absolute grading of preference, and will 
sometimes imply a false grading of preference when the preferences are 
equal between alternatives. Anyway it is a useful alternative to the 
absolute preference grading, so this is the proposal:

Allow use of the humintlang attribute on SDP session level, and let the 
order of the attributes show a relative preference to use that language.
Define a parameter to the humintlang attribute for a label, referring to 
a media specification in the SDP, e.g. in this way:

a=humintlang-send:<language tag> mstrm:<label1>
a=humintlang-recv:<language tag> mstrm:<label2>

m=audio ...
a=label:<label1>
...
m=text ...
a=label:<label2>

The intention is to use labels defined in RFC 4574 in a similar way as in RFC 4583.

We would then also need to define how a mix of lang= and humintlang=   attributes shall be handled,
and discuss if we can make it possible to also use the label parameter on lang= attributes.

/Gunnar