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

[Gunnar Hellstrom <[e-mail]>]

These seem to be good conclusions.

You say about directionality, for the lang-parameters in the different 
directions:
In most cases these are expected to have the same value, because 
otherwise it is harder to match desired resources.

I do not think that should be expected.

Examples:
1. Many deafblind persons prefer to sign for sending, but require text 
reception.

2. Many hard-of-hearing persons want to talk but receive text back.

3. Many persons with speech disabilities want to send text but receive 
speech


The conclusion to develop specifications for both the SIP level and the 
SDP level seems a bit complex, but can provide the desired resulting 
functionality.

Good.

/Gunnar




On 2013-03-15 19:49, Randall Gellens wrote:
> Hi everyone,
>
> Thanks very much for the productive discussion.  Here are my notes:
>
> SDP or SIP:
> - Use SDP for actual negotiation, but use SIP header to provide a hint
> - Emergency services use case can use SDP for policy routing/handling 
> decisions
> - Other use cases may or may not have ability/desire to use SDP for 
> this and can use the SIP header hint
> - SDP useful in protocols other than SIP
> - SIP header with hint is either a new header or caller preferences 
> (RFC 3841), presumably Accept-Contact; caller sets media and language 
> and optionally required; not clear if this matches our desired semantics
> - SIP header is just a hint; it is not required to be sent or to be 
> used on receipt; it is recommended to be sent
>
> New SDP attribute(s) vs re-use of existing 'lang' attribute:
> - Existing attribute semantics are unclear so should be avoided
> - Minting new attributes is cheap
>
> Directionality of SDP attributes:
> - Define two new SDP media-level attributes: 'send-lang' and 
> 'recv-lang'.  In an offer, send-lang is a list in preference order of 
> the languages the offerer wishes to send and recv-lang is a list in 
> preference order of the languages the offerer wishes to receive.  In 
> most cases these are expected to have the same value, because 
> otherwise it is harder to match desired resources.  In an answer, 
> send-lang is the accepted language the answerer will send (which in 
> most cases should be one of the languages in the offer's recv-lang) 
> and recv-lang is the accepted language the answerer expects to receive 
> (which in most cases should be one of the languages in the offer's 
> send-lang).
>
> Advisory vs Required:
> - Does call fail if no common language?
> - Define token for use in offer to indicate caller's preference to 
> fail call or not if no common language.
> - One choice is to say that if the last character of the send-lang or 
> recv-lan value an asterisk, this indicates a request to not fail the 
> call (similar to SIP Accept-Language syntax).  Either way, the called 
> party may ignore this, e.g., for the emergency services use case, a 
> PSAP will likely not fail the call.
>
> Other changes (from additional side discussions):
> - Add advice that the value of the parameters should stick to the 
> largest granularity of language tags, that is, it is recommended not 
> to add subtags (e.g., for region or dialect) unless the languages 
> might be mutually incomprehensible without them.
> - Expand Introduction to be more clear about purpose of document and 
> problem being solved
> - Add more detailed use case descriptions
>